From nobody Sat Apr 1 16:26:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054A21201F2 for ; Sat, 1 Apr 2017 16:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 xiwIK_BJ1tyn for ; Sat, 1 Apr 2017 16:26:25 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2405E12025C for ; Sat, 1 Apr 2017 16:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491089183; bh=Eg7rkbwBepE2JS0i9v6J/twK+JDZ4I8Z0Shi+vxbt78=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=COmANoc3cAAdYXums6OmqMbQbNFWmP7ctgDNMozMGwaYM6mMpnobIuB2re94NtyJJ4BCJJ2hLCcDxFQAFjF+LO4q1b+pjOOTw5nm7+ed6TNAmkTwQAN96Vx1ERD7Zi+YbyEiTZTS0KQZg+dqZhclN60jJ23lwy+WnBcJUg3Fj5M= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0083.outbound.protection.outlook.com [94.245.120.83]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-37-Rt_iW-xVOOqs7eFDPzX0iw-1; Sun, 02 Apr 2017 00:26:18 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Sat, 1 Apr 2017 23:26:15 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Sat, 1 Apr 2017 23:26:14 +0000 From: Tim Chown To: Jan Zorz - Go6 CC: RFC Errata System , "kawamucho@mesh.ad.jp" , "kawashimam@vx.jp.nec.com" , Suresh Krishnan , Terry Manderson , =?iso-8859-1?Q?Ole_Tr=F8an?= , Bob Hinden , "julianedprado@gmail.com" , "ipv6@ietf.org" Subject: Re: [Editorial Errata Reported] RFC5952 (4986) Thread-Topic: [Editorial Errata Reported] RFC5952 (4986) Thread-Index: AQHSqjbc6gQLScszX0+wuauxdXWvOqGvHVcAgAIM74A= Date: Sat, 1 Apr 2017 23:26:14 +0000 Message-ID: <8C64BAFE-D014-40F3-A3B6-956F937B4BB7@jisc.ac.uk> References: <20170331155211.7C444B81110@rfc-editor.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:20f3:cb50:43dc:997a] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:E7MWvqhaOjeBdSTEoGaP5VU3bfhAUf61+ssHvSe/2HSC+DZO0bNO6eDv/leC9EHFZ24I6NfsveOq7kHAnjoIPh+k/R2giQKAduocJmtRgyT3qpW0gIcyhFDyjAg5w2RTDJkzM7os9WwXUNYzJOtUjMph3rWxwpYG0aTWYIsqj3Aq4i+QC2w0RYfwcpXQN2IYzpKGUhRjyhoppQPU32A5ydGgOWA1wuZJUaRnzyjBOkMQEW57o1M0pnmmJ13xZHKCAvxjHlxUl/zfxJ0D/xeW2yj0xpAGZzemPvcoS2OSs/q36nXIjnLkwUd4iEcPox8QC5wHYFYFf3NSgFljZ7pPbQ==; 20:QEUI79o7dfDbCSYxBqI764RYIncuX9bk2jUBFcg3UFv0+Jc014ejWM4qVcVBEEoAjv78s072g/MZiDFeNyqHVnyz3sMCYeSIqwK2YDhyCE26U1pGLBRcxLlCdUMs1I/2a8nd7G2/PX/6KQRt4miiSbTtd472qQ3WsGyLCMzMe7w= x-ms-office365-filtering-correlation-id: 888fd0cf-422b-4610-f669-08d479567db6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(24454002)(82746002)(7416002)(102836003)(2906002)(3660700001)(6116002)(33656002)(189998001)(2950100002)(42882006)(6916009)(229853002)(74482002)(3280700002)(76176999)(36756003)(86362001)(50986999)(5250100002)(5660300001)(2900100001)(7736002)(53936002)(83716003)(39060400002)(6512007)(6306002)(305945005)(4326008)(8676002)(25786009)(53546009)(81166006)(8936002)(6486002)(110136004)(38730400002)(6246003)(54906002)(99286003)(50226002)(6506006)(57306001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <137CD19F08640246B5A4B2BA73B20570@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2017 23:26:14.7810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: Rt_iW-xVOOqs7eFDPzX0iw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:26:28 -0000 Hi Jan, > On 31 Mar 2017, at 17:07, Jan Zorz - Go6 wrote: >=20 > On 31/03/2017 17:52, RFC Errata System wrote: >> Original Text >> ------------- >> 'A special syntax is available to compress the zeros. The use of >> "::" indicates one or more groups of 16 bits of zeros.' >>=20 >>=20 >> Corrected Text >> -------------- >> 'A special syntax is available to compress the zeros. The use of >> "::" indicates two or more groups of 16 bits of zeros.' >>=20 >>=20 >>=20 >> Notes >> ----- >> "indicates one" should be written as "indicates two" >>=20 >> for example: >> 'A special syntax is available to compress the zeros. The use of >> "::" indicates two or more groups of 16 bits of zeros.' >>=20 >> 2001:db8:aaaa:bbbb:cccc::1 >>=20 >> 2001:db8:aaaa:bbbb:cccc:0:0:1 >=20 > Hi, >=20 > I don't agree with errata entirely. >=20 > 2001:db8:aaaa:bbbb:cccc:dddd::1 expands to 2001:db8:aaaa:bbbb:cccc:dddd:0= :1 >=20 > So it's one or more groups of 16 bits of zeros. Note you cannot reduce just one group of zeroes with ::, so the above examp= le of 2001:db8:aaaa:bbbb:cccc:dddd::1 must be written 2001:db8:aaaa:bbbb:cc= cc:dddd:0:1 (see 4.2.2 of RFC5952). Tim > Cheers, Jan Zorz >=20 >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5952 (draft-ietf-6man-text-addr-representation-07) >> -------------------------------------- >> Title : A Recommendation for IPv6 Address Text Representat= ion >> Publication Date : August 2010 >> Author(s) : S. Kawamura, M. Kawashima >> Category : PROPOSED STANDARD >> Source : IPv6 Maintenance >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sat Apr 1 16:30:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2B21252BA for ; Sat, 1 Apr 2017 16:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 hCXm0elK1zZI for ; Sat, 1 Apr 2017 16:30:09 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACE6124B0A for ; Sat, 1 Apr 2017 16:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491089408; bh=TDhpfi+ZrPRQJ5/ykHVQM0vB2asIFjLCAcqEb1vF3k0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DhMrU2ieySNey3MZGH+qOGTIZ/yJANut3Iin5s6KoG0WPClECwyLuIPPUE2R/NEo6LBm0ozAgHKUFY63Es5w8g13eCVvIPk6Dbdgma0MRlw6KEJMgj6aIC7hUBXnJWeW4CN+WBKAQ/Mm+F5OSbDP6ku0K2ITRW6lgx9akiGuKGQ= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0081.outbound.protection.outlook.com [94.245.120.81]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-ZfOfa2kjMvmnOL7_XN2PWA-1; Sun, 02 Apr 2017 00:30:03 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Sat, 1 Apr 2017 23:30:00 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.009; Sat, 1 Apr 2017 23:30:00 +0000 From: Tim Chown To: Jan Zorz - Go6 CC: RFC Errata System , "kawamucho@mesh.ad.jp" , "kawashimam@vx.jp.nec.com" , Suresh Krishnan , Terry Manderson , =?iso-8859-1?Q?Ole_Tr=F8an?= , Bob Hinden , "julianedprado@gmail.com" , "ipv6@ietf.org" Subject: Re: [Editorial Errata Reported] RFC5952 (4986) Thread-Topic: [Editorial Errata Reported] RFC5952 (4986) Thread-Index: AQHSqjbc6gQLScszX0+wuauxdXWvOqGvHVcAgAIM74CAAAEMAA== Date: Sat, 1 Apr 2017 23:30:00 +0000 Message-ID: <55236100-3099-4B1C-AE58-FC6DC3B571CE@jisc.ac.uk> References: <20170331155211.7C444B81110@rfc-editor.org> <8C64BAFE-D014-40F3-A3B6-956F937B4BB7@jisc.ac.uk> In-Reply-To: <8C64BAFE-D014-40F3-A3B6-956F937B4BB7@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:20f3:cb50:43dc:997a] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:V+OttMFn6JbqravB2utkMMifGVUln4Wr/H0ogU+70uGoTLxVO+UO0C9JdIY3lmQnlMm0Csiq7a/4S7r3ZNkiqhBQEVNu49XX8GyLbRuZs53QaU9SmhvbwkMXKMQl6BOd/UHtPd3KIBolt7+TSAalk8YrLMwAJV8+EQo0kCKnbwlOI7vdjPyq6zqS71OZYNkKIJ9JihGzg/RQbvyx6nv4kYqpPkCY4ezwcC+63i/Q7TnBB8limq3p/Hbc7KpZAZgNXoP8q2LpBg7gMYHcQMb39DZkwHzJZVmAMiVotTrahD/SZEDqQKJn8yfFkTnGMrauD1QyUPtBZ06O2qRQF1Ew/g==; 20:XtA7ZnTFiXZTEaT7JH2ZXp5El9z/tGWMrnJLv0yDE3kY+qdoSMJp/fJYPlPcN5flY6pk91+MV39Xrqha7lu1muOC7/bv6aJWTReLLU4aH1DJ9KN7ZPgRumLnxGvAb5HT6r1VZ/2Ectqe4uvDZ6OOVYQuUJ4Yec1FJs+K6Y0jWfY= x-ms-office365-filtering-correlation-id: 80440589-95fe-4de8-7909-08d47957040b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201703061421075)(201703161042075)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6042181)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(82746002)(7416002)(102836003)(2906002)(3660700001)(6116002)(33656002)(189998001)(2950100002)(42882006)(6916009)(229853002)(74482002)(3280700002)(76176999)(36756003)(86362001)(50986999)(5250100002)(5660300001)(2900100001)(7736002)(53936002)(83716003)(39060400002)(6512007)(6306002)(305945005)(4326008)(8676002)(25786009)(53546009)(81166006)(8936002)(6486002)(110136004)(38730400002)(6246003)(54906002)(99286003)(50226002)(6506006)(57306001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6A8D0332567A5441927E2A99099EA732@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2017 23:30:00.1808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: ZfOfa2kjMvmnOL7_XN2PWA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 23:30:12 -0000 Hi again (hit send too soon!), > On 2 Apr 2017, at 00:26, Tim Chown wrote: >=20 > Hi Jan, >=20 >> On 31 Mar 2017, at 17:07, Jan Zorz - Go6 wrote: >>=20 >> On 31/03/2017 17:52, RFC Errata System wrote: >>> Original Text >>> ------------- >>> 'A special syntax is available to compress the zeros. The use of >>> "::" indicates one or more groups of 16 bits of zeros.' >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> 'A special syntax is available to compress the zeros. The use of >>> "::" indicates two or more groups of 16 bits of zeros.' >>>=20 >>>=20 >>>=20 >>> Notes >>> ----- >>> "indicates one" should be written as "indicates two" >>>=20 >>> for example: >>> 'A special syntax is available to compress the zeros. The use of >>> "::" indicates two or more groups of 16 bits of zeros.' >>>=20 >>> 2001:db8:aaaa:bbbb:cccc::1 >>>=20 >>> 2001:db8:aaaa:bbbb:cccc:0:0:1 >>=20 >> Hi, >>=20 >> I don't agree with errata entirely. >>=20 >> 2001:db8:aaaa:bbbb:cccc:dddd::1 expands to 2001:db8:aaaa:bbbb:cccc:dddd:= 0:1 >>=20 >> So it's one or more groups of 16 bits of zeros. >=20 > Note you cannot reduce just one group of zeroes with ::, so the above exa= mple of 2001:db8:aaaa:bbbb:cccc:dddd::1 must be written 2001:db8:aaaa:bbbb:= cccc:dddd:0:1 (see 4.2.2 of RFC5952). So this might be the point the filer of the erratum is making, when referri= ng to the recommendation of section 4 as a whole? Tim >=20 > Tim >=20 >> Cheers, Jan Zorz >>=20 >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC5952 (draft-ietf-6man-text-addr-representation-07) >>> -------------------------------------- >>> Title : A Recommendation for IPv6 Address Text Representa= tion >>> Publication Date : August 2010 >>> Author(s) : S. Kawamura, M. Kawashima >>> Category : PROPOSED STANDARD >>> Source : IPv6 Maintenance >>> Area : Internet >>> Stream : IETF >>> Verifying Party : IESG >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 From nobody Sun Apr 2 14:05:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46591294C1 for ; Sun, 2 Apr 2017 14:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=dougbarton.us 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 kfY4EM06_qec for ; Sun, 2 Apr 2017 14:05:53 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A2F129329 for ; Sun, 2 Apr 2017 14:05:53 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id EC51685 for ; Sun, 2 Apr 2017 14:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491167156; bh=T2nPwgZMtaaI8TCzGS3ze7NnJxekYWMDvB8je9KX3tY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qZaJ5JxQvewITb6u16TxM1EzrpHz6C9oH/kj5hBGZ9g1kt8ynqxRc3W8wxUvf1vVw p1JbHenIMXKWyF3RsAXMdgZn/uzB9Y93SqHttHbErBr6vS9X46FfdJzM7zdY625JOG c1daHjo9KSW3OS/YsI6xwAaXUNU13S9SAoK25rr0= Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: ipv6@ietf.org References: <20170331155211.7C444B81110@rfc-editor.org> From: Doug Barton Message-ID: <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> Date: Sun, 2 Apr 2017 14:05:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:05:55 -0000 On 03/31/2017 09:21 AM, Bob Hinden wrote: > Hi, > >> On Mar 31, 2017, at 10:52 AM, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC5952, >> "A Recommendation for IPv6 Address Text Representation". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4986 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Julian de Prado >> >> Section: 2.2 >> >> Original Text >> ------------- >> 'A special syntax is available to compress the zeros. The use of >> "::" indicates one or more groups of 16 bits of zeros.' >> >> >> Corrected Text >> -------------- >> 'A special syntax is available to compress the zeros. The use of >> "::" indicates two or more groups of 16 bits of zeros.' >> >> > > That is not correct. RFC4291, where the “::” syntax is defined, says in Section 2.2: > > 2. Due to some methods of allocating certain styles of IPv6 > addresses, it will be common for addresses to contain long strings > of zero bits. In order to make writing addresses containing zero > bits easier, a special syntax is available to compress the zeros. > The use of "::" indicates one or more groups of 16 bits of zeros. > The "::" can only appear once in an address. The "::" can also be > used to compress leading or trailing zeros in an address. > > Bob +1 From nobody Sun Apr 2 14:11:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8601294C1 for ; Sun, 2 Apr 2017 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=dougbarton.us 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 IOMTLpn_xUcv for ; Sun, 2 Apr 2017 14:11:05 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C0A1292FC for ; Sun, 2 Apr 2017 14:11:05 -0700 (PDT) Received: from [IPv6:2001:470:d:c12::cb6] (unknown [IPv6:2001:470:d:c12::cb6]) by dougbarton.us (Postfix) with ESMTPSA id 0B33185 for ; Sun, 2 Apr 2017 14:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491167468; bh=F3I8y6zX5jR3E+3WIrGmI/xtOjVnHVK9H10ufzp3rsA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oRvz8e2AH9vzWfC+9kwZhjDyHPbVBFU6/CdpAEARgKg898PQ2Lp31wCx36uYjIe/7 3WVd6Go4wqvO7y+ZiUd6dyZ6vziOvzk8y7xSElohER/KZiyid7pJWJb/HxnIE4rjfA NtoOBg2RMGNCvn6jxuVufsbfHezi5dEknUO6IyXA= Subject: Re: [Technical Errata Reported] RFC5952 (4985) To: ipv6@ietf.org References: <20170331152051.C11DFB80E34@rfc-editor.org> From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 14:11:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170331152051.C11DFB80E34@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:11:07 -0000 See Bob's reply to the 5952 Errata by the same person which mentions the relevant section of 4291. Doug On 03/31/2017 08:20 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC5952, > "A Recommendation for IPv6 Address Text Representation". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4985 > > -------------------------------------- > Type: Technical > Reported by: Julian de Prado > > Section: 2.2 > > Original Text > ------------- > In cases where there is more than one field of only zeros, there is a > choice of how many fields can be shortened. > > 2001:db8:0:0:0::1 > 2001:db8:0:0::1 > 2001:db8:0::1 > 2001:db8::1 > > Corrected Text > -------------- > In cases where there is more than one field of only zeros,there is a > choice of how many fields can be shortened, but must be shortened to > its maximum capability. > > 2001:db8:0:0:0::1 is NOT acceptable > 2001:db8:0:0::1 is NOT acceptable > 2001:db8:0::1 is NOT acceptable > 2001:db8::1 is CORRECT > > > Notes > ----- > Applying section 4.2.1 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5952 (draft-ietf-6man-text-addr-representation-07) > -------------------------------------- > Title : A Recommendation for IPv6 Address Text Representation > Publication Date : August 2010 > Author(s) : S. Kawamura, M. Kawashima > Category : PROPOSED STANDARD > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sun Apr 2 14:52:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A901292F4 for ; Sun, 2 Apr 2017 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=jisc.ac.uk 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 NJHerGlelO5I for ; Sun, 2 Apr 2017 14:52:30 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08285127F0E for ; Sun, 2 Apr 2017 14:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491169947; bh=6jPOO2+Rp4j/MFbjV4J31i3GtY6Dx0I5qZpRILGiqaw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=EnKC7DKLzl6WLETNSIin3D3tSFJXmTSJnNxA1oAQQjo7ujHy4XCF8bRiva44bI47fhoRMhOyNr8sIgnbi8kKP6HEwl9GFqAAukwKJdT5tX13aE9gVVxAAeetJ4wX6gXeYFg77bpQgfhXz9Ft05faPsEBl3WZatoPNBraiciAx18= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-LcR6b6SHOFu9Pan96VJG9g-1; Sun, 02 Apr 2017 22:52:23 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Sun, 2 Apr 2017 21:52:22 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Sun, 2 Apr 2017 21:52:22 +0000 From: Tim Chown To: Doug Barton CC: "ipv6@ietf.org" Subject: Re: [Editorial Errata Reported] RFC5952 (4986) Thread-Topic: [Editorial Errata Reported] RFC5952 (4986) Thread-Index: AQHSqjbc6gQLScszX0+wuauxdXWvOqGvIUUAgAN0HwCAAAz7gA== Date: Sun, 2 Apr 2017 21:52:22 +0000 Message-ID: <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> In-Reply-To: <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:2c40:904f:2602:55e7] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:MaZApxtH67/fvUZtxfQDow0qYbm2P/IU1M9Cj2LwiiR9KV4WOkWnn4WvDwZobvjWv4HcVTzCxB84HgcIuf3Zy0DQ14YzgF3lc7tVEUdES7yAbgDMi3pMlTB6TGIh29bph5DkhSfSSacpMg8+Wk7H/Hsofm7VofCynGaPycGW+jIjw6dlIcJ/JG9lmsqO5Ud4sKE8NLBC4V7QObF6BkHjEfpGmZM/zltbg6E5bRke1mxtjaakT80aypheEZkvXS2K/ndrytOUbsySERG92TP7iAfS/EwDkp9fAGkuvekudeqYqpsWuXg4+AJfQWRpes+vc9R+8TbIA+TZmobcrRN8zA==; 20:aId28zHZUwtolAlzQbw5mD90z9+e+fjyPfA9lRiY4TuSnbg4Z9fZbgcqVVwUbtGQ6xMRAkcbhnYn70csKmfkjmHzsq2AvPUgkPy2oIcE9kl69dE/SnXd8uuVia8BaU8Ik5GMxbqXH/LzNdff/Zw0lAV/3hMVlSP8P8efw7HX9cw= x-ms-office365-filtering-correlation-id: 56b7a171-73ec-48b2-fcb4-08d47a128b13 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39410400002)(39400400002)(377454003)(24454002)(25786009)(53546009)(50226002)(33656002)(189998001)(81166006)(2906002)(2900100001)(6486002)(3280700002)(76176999)(50986999)(36756003)(8676002)(102836003)(6116002)(99286003)(16799955002)(5660300001)(6246003)(3660700001)(110136004)(38730400002)(53936002)(966004)(74482002)(236005)(8936002)(6916009)(2950100002)(42882006)(54896002)(6306002)(15188155005)(6512007)(6436002)(86362001)(7736002)(606005)(6506006)(4326008)(7906003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2017 21:52:22.6644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: LcR6b6SHOFu9Pan96VJG9g-1 Content-Type: multipart/alternative; boundary="_000_6196E2F1CC144FA381B6E83B0F09B278jiscacuk_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 21:52:33 -0000 --_000_6196E2F1CC144FA381B6E83B0F09B278jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMiBBcHIgMjAxNywgYXQgMjI6MDUsIERvdWcgQmFydG9uIDxkb3VnYkBkb3VnYmFydG9uLnVz PG1haWx0bzpkb3VnYkBkb3VnYmFydG9uLnVzPj4gd3JvdGU6DQoNCk9uIDAzLzMxLzIwMTcgMDk6 MjEgQU0sIEJvYiBIaW5kZW4gd3JvdGU6DQpIaSwNCg0KT24gTWFyIDMxLCAyMDE3LCBhdCAxMDo1 MiBBTSwgUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8bWFpbHRv OnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+PiB3cm90ZToNCg0KVGhlIGZvbGxvd2luZyBlcnJh dGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTk1MiwNCiJBIFJlY29tbWVuZGF0 aW9uIGZvciBJUHY2IEFkZHJlc3MgVGV4dCBSZXByZXNlbnRhdGlvbiIuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJl bG93IGFuZCBhdDoNCmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/ cmZjPTU5NTImZWlkPTQ5ODYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClR5cGU6IEVkaXRvcmlhbA0KUmVwb3J0ZWQgYnk6IEp1bGlhbiBkZSBQcmFkbyA8anVsaWFu ZWRwcmFkb0BnbWFpbC5jb20+DQoNClNlY3Rpb246IDIuMg0KDQpPcmlnaW5hbCBUZXh0DQotLS0t LS0tLS0tLS0tDQonQSBzcGVjaWFsIHN5bnRheCBpcyBhdmFpbGFibGUgdG8gY29tcHJlc3MgdGhl IHplcm9zLiBUaGUgdXNlIG9mDQoiOjoiIGluZGljYXRlcyBvbmUgb3IgbW9yZSBncm91cHMgb2Yg MTYgYml0cyBvZiB6ZXJvcy4nDQoNCg0KQ29ycmVjdGVkIFRleHQNCi0tLS0tLS0tLS0tLS0tDQon QSBzcGVjaWFsIHN5bnRheCBpcyBhdmFpbGFibGUgdG8gY29tcHJlc3MgdGhlIHplcm9zLiBUaGUg dXNlIG9mDQoiOjoiIGluZGljYXRlcyB0d28gb3IgbW9yZSBncm91cHMgb2YgMTYgYml0cyBvZiB6 ZXJvcy4nDQoNCg0KDQpUaGF0IGlzIG5vdCBjb3JyZWN0LiAgUkZDNDI5MSwgd2hlcmUgdGhlIOKA nDo64oCdIHN5bnRheCBpcyBkZWZpbmVkLCBzYXlzIGluIFNlY3Rpb24gMi4yOg0KDQogIDIuIER1 ZSB0byBzb21lIG1ldGhvZHMgb2YgYWxsb2NhdGluZyBjZXJ0YWluIHN0eWxlcyBvZiBJUHY2DQog ICAgIGFkZHJlc3NlcywgaXQgd2lsbCBiZSBjb21tb24gZm9yIGFkZHJlc3NlcyB0byBjb250YWlu IGxvbmcgc3RyaW5ncw0KICAgICBvZiB6ZXJvIGJpdHMuICBJbiBvcmRlciB0byBtYWtlIHdyaXRp bmcgYWRkcmVzc2VzIGNvbnRhaW5pbmcgemVybw0KICAgICBiaXRzIGVhc2llciwgYSBzcGVjaWFs IHN5bnRheCBpcyBhdmFpbGFibGUgdG8gY29tcHJlc3MgdGhlIHplcm9zLg0KICAgICBUaGUgdXNl IG9mICI6OiIgaW5kaWNhdGVzIG9uZSBvciBtb3JlIGdyb3VwcyBvZiAxNiBiaXRzIG9mIHplcm9z Lg0KICAgICBUaGUgIjo6IiBjYW4gb25seSBhcHBlYXIgb25jZSBpbiBhbiBhZGRyZXNzLiAgVGhl ICI6OiIgY2FuIGFsc28gYmUNCiAgICAgdXNlZCB0byBjb21wcmVzcyBsZWFkaW5nIG9yIHRyYWls aW5nIHplcm9zIGluIGFuIGFkZHJlc3MuDQoNCkJvYg0KDQorMQ0KDQpTbyBzaG91bGQgU2VjdGlv biA0LjIuMiBzdGFuZCwgb24gbm90IHNob3J0ZW5pbmcgb25lIDE2LWJpdCBmaWVsZCBvZiB6ZXJv cz8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTUyI3NlY3Rpb24tNC4yLjINCg0K VGhlIHJhdGlvbmFsZSBmb3IgdGhhdCBzZWN0aW9uIGdpdmVuIGluIGVhcmxpZXIgdmVyc2lvbnMg b2YgdGhlIGRyYWZ0IHVwIHVudGlsIC0wNCBzYXlzICIiOjoiIHNob3VsZCBub3QgYmUgdXNlZCB0 byBzaG9ydGVuIGp1c3Qgb25lIDE2IGJpdCAwIGZpZWxkIGZvciBpdCB3b3VsZCB0ZW5kIHRvIG1p c2xlYWQgdGhhdCB0aGVyZSBhcmUgbW9yZSB0aGFuIG9uZSAxNiBiaXQgZmllbGQgdGhhdCBpcyBz aG9ydGVuZWTigJ0sIHdoaWNoIHNlZW1zIGEgYml0IHdlYWssIGFuZCBhdCBvZGRzIHdpdGggUkZD NDI5MSBhcyBhYm92ZT8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZt YW4tdGV4dC1hZGRyLXJlcHJlc2VudGF0aW9uLTA0I3NlY3Rpb24tNC4yLjINCg0KVGltDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBp ZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0K --_000_6196E2F1CC144FA381B6E83B0F09B278jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <8DAA1EA2234A834B892DCD097E3633F1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KT24gMiBBcHIgMjAxNywgYXQgMjI6 MDUsIERvdWcgQmFydG9uICZsdDs8YSBocmVmPSJtYWlsdG86ZG91Z2JAZG91Z2JhcnRvbi51cyIg Y2xhc3M9IiI+ZG91Z2JAZG91Z2JhcnRvbi51czwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24g MDMvMzEvMjAxNyAwOToyMSBBTSwgQm9iIEhpbmRlbiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5IaSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBNYXIgMzEsIDIwMTcsIGF0 IDEwOjUyIEFNLCBSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0 b3JAcmZjLWVkaXRvci5vcmciIGNsYXNzPSIiPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+ Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgZm9sbG93aW5nIGVy cmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM1OTUyLDxiciBjbGFzcz0iIj4N CiZxdW90O0EgUmVjb21tZW5kYXRpb24gZm9yIElQdjYgQWRkcmVzcyBUZXh0IFJlcHJlc2VudGF0 aW9uJnF1b3Q7LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KWW91IG1heSByZXZpZXcgdGhlIHJl cG9ydCBiZWxvdyBhbmQgYXQ6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NTk1MiZhbXA7ZWlkPTQ5ODYiIGNsYXNz PSIiPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTU5NTIm YW1wO2VpZD00OTg2PC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KVHlwZTogRWRpdG9yaWFs PGJyIGNsYXNzPSIiPg0KUmVwb3J0ZWQgYnk6IEp1bGlhbiBkZSBQcmFkbyAmbHQ7anVsaWFuZWRw cmFkb0BnbWFpbC5jb20mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbjog Mi4yPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT3JpZ2luYWwgVGV4dDxiciBjbGFzcz0i Ij4NCi0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQonQSBzcGVjaWFsIHN5bnRheCBpcyBhdmFp bGFibGUgdG8gY29tcHJlc3MgdGhlIHplcm9zLiBUaGUgdXNlIG9mPGJyIGNsYXNzPSIiPg0KJnF1 b3Q7OjomcXVvdDsgaW5kaWNhdGVzIG9uZSBvciBtb3JlIGdyb3VwcyBvZiAxNiBiaXRzIG9mIHpl cm9zLic8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDb3JyZWN0 ZWQgVGV4dDxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KJ0Egc3Bl Y2lhbCBzeW50YXggaXMgYXZhaWxhYmxlIHRvIGNvbXByZXNzIHRoZSB6ZXJvcy4gVGhlIHVzZSBv ZjxiciBjbGFzcz0iIj4NCiZxdW90Ozo6JnF1b3Q7IGluZGljYXRlcyB0d28gb3IgbW9yZSBncm91 cHMgb2YgMTYgYml0cyBvZiB6ZXJvcy4nPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhhdCBpcyBub3QgY29y cmVjdC4gJm5ic3A7UkZDNDI5MSwgd2hlcmUgdGhlIOKAnDo64oCdIHN5bnRheCBpcyBkZWZpbmVk LCBzYXlzIGluIFNlY3Rpb24gMi4yOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOzIuIER1ZSB0byBzb21lIG1ldGhvZHMgb2YgYWxsb2NhdGluZyBjZXJ0YWluIHN0eWxl cyBvZiBJUHY2PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWRk cmVzc2VzLCBpdCB3aWxsIGJlIGNvbW1vbiBmb3IgYWRkcmVzc2VzIHRvIGNvbnRhaW4gbG9uZyBz dHJpbmdzPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgemVy byBiaXRzLiAmbmJzcDtJbiBvcmRlciB0byBtYWtlIHdyaXRpbmcgYWRkcmVzc2VzIGNvbnRhaW5p bmcgemVybzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JpdHMg ZWFzaWVyLCBhIHNwZWNpYWwgc3ludGF4IGlzIGF2YWlsYWJsZSB0byBjb21wcmVzcyB0aGUgemVy b3MuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIHVzZSBv ZiAmcXVvdDs6OiZxdW90OyBpbmRpY2F0ZXMgb25lIG9yIG1vcmUgZ3JvdXBzIG9mIDE2IGJpdHMg b2YgemVyb3MuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhl ICZxdW90Ozo6JnF1b3Q7IGNhbiBvbmx5IGFwcGVhciBvbmNlIGluIGFuIGFkZHJlc3MuICZuYnNw O1RoZSAmcXVvdDs6OiZxdW90OyBjYW4gYWxzbyBiZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3VzZWQgdG8gY29tcHJlc3MgbGVhZGluZyBvciB0cmFpbGluZyB6 ZXJvcyBpbiBhbiBhZGRyZXNzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJvYjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCiYjNDM7MTxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KU28gc2hvdWxkIFNlY3Rpb24gNC4yLjIgc3RhbmQsIG9uIG5vdCBzaG9ydGVuaW5nIG9u ZSAxNi1iaXQgZmllbGQgb2YgemVyb3M/PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTUyI3NlY3Rpb24tNC4yLjIiIGNsYXNzPSIiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1OTUyI3NlY3Rpb24tNC4yLjI8L2E+PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgd2lkb3dzOiAy OyI+VGhlIHJhdGlvbmFsZSBmb3IgdGhhdCBzZWN0aW9uIGdpdmVuIGluIGVhcmxpZXIgdmVyc2lv bnMgb2YgdGhlIGRyYWZ0IHVwIHVudGlsIC0wNCBzYXlzICZxdW90OzxzcGFuIHN0eWxlPSJvcnBo YW5zOiAyOyB3aWRvd3M6IDI7IiBjbGFzcz0iIj4mcXVvdDs6OiZxdW90OyBzaG91bGQgbm90IGJl IHVzZWQgdG8gc2hvcnRlbiBqdXN0IG9uZSAxNiBiaXQgMCBmaWVsZCBmb3IgaXQmbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNsYXNzPSIiPndvdWxkDQog dGVuZCB0byBtaXNsZWFkIHRoYXQgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgMTYgYml0IGZpZWxk IHRoYXQmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im9ycGhhbnM6IDI7IHdpZG93czogMjsiIGNs YXNzPSIiPmlzIHNob3J0ZW5lZOKAnSwgd2hpY2ggc2VlbXMgYSBiaXQgd2VhaywgYW5kIGF0IG9k ZHMgd2l0aCBSRkM0MjkxIGFzIGFib3ZlPzwvc3Bhbj48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi10ZXh0LWFkZHItcmVwcmVz ZW50YXRpb24tMDQjc2VjdGlvbi00LjIuMiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtNm1hbi10ZXh0LWFkZHItcmVwcmVzZW50YXRpb24tMDQjc2VjdGlv bi00LjIuMjwvYT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyIGNsYXNzPSIiPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIGNsYXNzPSIiPmlwdjZA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjxiciBjbGFzcz0iIj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6196E2F1CC144FA381B6E83B0F09B278jiscacuk_-- From nobody Sun Apr 2 15:09:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AB9129441 for ; Sun, 2 Apr 2017 15:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=dougbarton.us 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 80eE67vY1ujf for ; Sun, 2 Apr 2017 15:09:09 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280B4129421 for ; Sun, 2 Apr 2017 15:09:09 -0700 (PDT) Received: from [192.168.10.179] (rrcs-69-75-212-158.west.biz.rr.com [69.75.212.158]) by dougbarton.us (Postfix) with ESMTPSA id A1A509A; Sun, 2 Apr 2017 15:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1491170951; bh=nwfitYzKkoROX+SM0gn67OEH3JOQqanVQ6P7lAv7WWo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dh4ehsutP9y9J0kCOPpXOihlwoLs4PN1LeKi8p3azoKWRSkzFBYQErGFJCfg+j4sY O1Rxz0Y3mVEPZ2uZ75fs+jfbxirzyZ4C57bbu6qESqg3MUTEkeMGhiJA9g4pmwA1f9 Qz9SvJoikGU2Ao2jZZVKZxyVsux+oVv27/S7dtMU= Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Tim Chown References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: "ipv6@ietf.org" From: Doug Barton Message-ID: Date: Sun, 2 Apr 2017 15:09:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 22:09:11 -0000 On 04/02/2017 02:52 PM, Tim Chown wrote: > On 2 Apr 2017, at 22:05, Doug Barton > wrote: >> >> On 03/31/2017 09:21 AM, Bob Hinden wrote: >>> Hi, >>> >>>> On Mar 31, 2017, at 10:52 AM, RFC Errata System >>>> > wrote: >>>> >>>> The following errata report has been submitted for RFC5952, >>>> "A Recommendation for IPv6 Address Text Representation". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4986 >>>> >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Julian de Prado >>>> >>>> Section: 2.2 >>>> >>>> Original Text >>>> ------------- >>>> 'A special syntax is available to compress the zeros. The use of >>>> "::" indicates one or more groups of 16 bits of zeros.' >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> 'A special syntax is available to compress the zeros. The use of >>>> "::" indicates two or more groups of 16 bits of zeros.' >>>> >>>> >>> >>> That is not correct. RFC4291, where the “::” syntax is defined, says >>> in Section 2.2: >>> >>> 2. Due to some methods of allocating certain styles of IPv6 >>> addresses, it will be common for addresses to contain long strings >>> of zero bits. In order to make writing addresses containing zero >>> bits easier, a special syntax is available to compress the zeros. >>> The use of "::" indicates one or more groups of 16 bits of zeros. >>> The "::" can only appear once in an address. The "::" can also be >>> used to compress leading or trailing zeros in an address. >>> >>> Bob >> >> +1 > > So should Section 4.2.2 stand, on not shortening one 16-bit field of zeros? > https://tools.ietf.org/html/rfc5952#section-4.2.2 I wasn't involved in the 5952 discussion, so it would be hard for me to comment. On principle though I would say no, because ... > The rationale for that section given in earlier versions of the draft up > until -04 says ""::" should not be used to shorten just one 16 bit 0 > field for it would tend to mislead that there are more than one 16 bit > field that is shortened”, which seems a bit weak, and at odds with > RFC4291 as above? > https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04#section-4.2.2 ... I find it sad that A) people could think that this is a problem, and B) that people who are confused about how many 16 bit fields make up an IPv6 address could possibly get more confused by how many fields are being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? Seriously?) So if updating 4.2.2 of 5952 will make things more clear for people, it should probably be done. Doug From nobody Sun Apr 2 16:03:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC4127077 for ; Sun, 2 Apr 2017 16:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=go6.si 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 4pOgoGGVK2Op for ; Sun, 2 Apr 2017 16:03:48 -0700 (PDT) Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F1512702E for ; Sun, 2 Apr 2017 16:03:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 6EDF863E63; Mon, 3 Apr 2017 01:03:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at go6.si Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id hJzT6Q3MxDrm; Mon, 3 Apr 2017 01:03:45 +0200 (CEST) Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id DC217613D2; Mon, 3 Apr 2017 01:03:44 +0200 (CEST) Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:5::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 8218883722; Mon, 3 Apr 2017 01:03:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1491174222; bh=MXrl642WVYBTica7MDoae1YSkFxfkUnQ1ZNzY6jg/J8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RoM28Ff8vBzS+Q+b78IQ2iKJ2E4IBZLW006oYyKZ2054s0ZmgVdXR+A2Wzj6in/cG qrg5w6Un8uHAVBDj3kDhvYg0gXkjsUBEymEPxtVxD5U03EvaEV4DJWsc9FT332Tr1A dpLUsFTVUTkiV8NNnSYRTSBpc+7ouJZDG0GFqnVI= Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Doug Barton , Tim Chown References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: "ipv6@ietf.org" From: Jan Zorz - Go6 Message-ID: Date: Mon, 3 Apr 2017 01:03:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 23:03:51 -0000 On 03/04/2017 00:09, Doug Barton wrote: > ... I find it sad that A) people could think that this is a problem, and > B) that people who are confused about how many 16 bit fields make up an > IPv6 address could possibly get more confused by how many fields are > being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? > Seriously?) In real world - compression and decompression of just 16 bits between the :: simply works. Cheers, Jan > > So if updating 4.2.2 of 5952 will make things more clear for people, it > should probably be done. > > Doug > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Apr 2 23:00:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62132124B0A for ; Sun, 2 Apr 2017 23:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 BoMcsJ6RUM77 for ; Sun, 2 Apr 2017 23:00:20 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6267B126C23 for ; Sun, 2 Apr 2017 23:00:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1C7D9A2; Mon, 3 Apr 2017 08:00:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491199217; bh=CqFMgSCXXx/pcz4Xp0XcRb4Ekc++2eFBVwbvNn093/c=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Zq8FfcxWo7ITk2CNnceu2h0YDmbFjbXGGpnO5kCNgCbDAbFdZOKanRQe9chcRPEPL gk0WpunuDhjTjCzS+tcMO8EzRolhYee0nR368dC1J/fVmedhY3qXd3rmBOBxl40hNS KqJ0nYMM5onbP3hqe2jxVKUnfqMnUaLrSJeTuPcM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0314A88; Mon, 3 Apr 2017 08:00:17 +0200 (CEST) Date: Mon, 3 Apr 2017 08:00:16 +0200 (CEST) From: Mikael Abrahamsson To: Jan Zorz - Go6 cc: Doug Barton , Tim Chown , "ipv6@ietf.org" Subject: Re: [Editorial Errata Reported] RFC5952 (4986) In-Reply-To: Message-ID: References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:00:23 -0000 On Mon, 3 Apr 2017, Jan Zorz - Go6 wrote: > On 03/04/2017 00:09, Doug Barton wrote: >> ... I find it sad that A) people could think that this is a problem, and >> B) that people who are confused about how many 16 bit fields make up an >> IPv6 address could possibly get more confused by how many fields are >> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? >> Seriously?) > > In real world - compression and decompression of just 16 bits between the :: > simply works. Saying that 1:2:3:4:5:6::8 is invalid fails the "rule of least astonishment" test. $ ping6 1:2:3:4:5:6::8 PING 1:2:3:4:5:6::8(1:2:3:4:5:6:0:8) 56 data bytes Agreed that this just works, and I don't understand why we would have text that says it's not allowed? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Apr 2 23:36:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEC8129571 for ; Sun, 2 Apr 2017 23:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si 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 t6i_yugJqc6S for ; Sun, 2 Apr 2017 23:36:41 -0700 (PDT) Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98FC120046 for ; Sun, 2 Apr 2017 23:36:40 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 63EA863D0C; Mon, 3 Apr 2017 08:36:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at go6.si Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id SCWd1nlR1b-s; Mon, 3 Apr 2017 08:36:37 +0200 (CEST) Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 68C206064A; Mon, 3 Apr 2017 08:36:37 +0200 (CEST) Received: from ISOC-BMDKQ4.local (unknown [IPv6:2001:67c:27e4:5::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 832A181B85; Mon, 3 Apr 2017 08:36:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1491201397; bh=xpeI1jICsc/jaoi7VKVL81rKfb6X1PKphVoCPTsm4cA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ILNfZxEY+cPc4SH5JxB8XoDWj3ayWMEDBAERQpwRoVm/Pu2A+ZjYCbLpJJm2a1et2 FPtytou95Gw0wZZ7dYg3lP4fF9M9qgDnBL8njMRw/wMBBvf90JQxTE3K0E+UrxG5fj 9HJEdunZ6I/EP++RaCJVK322OB9s5ihEEW/txXBI= Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Mikael Abrahamsson References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: Doug Barton , Tim Chown , "ipv6@ietf.org" From: Jan Zorz - Go6 Message-ID: Date: Mon, 3 Apr 2017 08:36:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:36:43 -0000 On 03/04/2017 08:00, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Jan Zorz - Go6 wrote: > >> On 03/04/2017 00:09, Doug Barton wrote: >>> ... I find it sad that A) people could think that this is a problem, and >>> B) that people who are confused about how many 16 bit fields make up an >>> IPv6 address could possibly get more confused by how many fields are >>> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? >>> Seriously?) >> >> In real world - compression and decompression of just 16 bits between >> the :: simply works. > > Saying that 1:2:3:4:5:6::8 is invalid fails the "rule of least > astonishment" test. > > $ ping6 1:2:3:4:5:6::8 > PING 1:2:3:4:5:6::8(1:2:3:4:5:6:0:8) 56 data bytes > > Agreed that this just works, and I don't understand why we would have > text that says it's not allowed? In theory, there is no difference between theory and practice. But, in practice, there is. ;) Cheers, Jan From nobody Mon Apr 3 04:20:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A226D1275AB for ; Mon, 3 Apr 2017 04:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 7uZRXAaFha8e for ; Mon, 3 Apr 2017 04:20:53 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455891250B8 for ; Mon, 3 Apr 2017 04:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491218451; bh=RsIzkzBiuZEw+BhpGZ9t/1Vn046uyEpzrWvZy/ERP8c=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M6upQ04wFmWIR+AqdR21HGFc4ZYJW22AhwfrRF82zgpTIpN50STfs0/wv+YGONytbCcTeJlgAx/TFlucXqkQKugmJgTWKANpAWQoB+7R+vKJ823zLK/wAkCEFLZcxQOMUpS7TSAJvLesLOAUlB3Q+XCFJPge2fM0xeoOVjNgENU= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0049.outbound.protection.outlook.com [213.199.154.49]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-f_Wt9AHeNgy4hij59g_HgQ-1; Mon, 03 Apr 2017 12:20:44 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 3 Apr 2017 11:20:43 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Mon, 3 Apr 2017 11:20:43 +0000 From: Tim Chown To: Bob Hinden CC: IPv6 List Subject: Re: Thread-Topic: Thread-Index: AQHSqjQFlm9a0D1j6kmStW+gnja+pKGzhEAA Date: Mon, 3 Apr 2017 11:20:43 +0000 Message-ID: <55EC16DF-F4F0-4DAA-8AB6-382DAE8752E9@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:f14f:15a4:6a00:cc70] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:VTq6UJ78YqUnExCe1IDodjk3xe+cdSW7hO9TV5ZdlHypweELU3lq6AAAXQiKeEYzKYHstBTdYtKTC1ehIM4hW1wDkuTm/qLLSgeTHnirz4kHFPAS3qCzLc4IkVJiHshvZONFiPTluez5jpjjwPrml2y4s7z3kH1V/o0jXGl+keOtmpJi/ujD6aVFoyPXnFKXLZeXr9mfsLOB6joNtZNUIT57zoiPsxU5zkcZRvpZ0o/O8rBK37OlxJxUp9RHVcbZCBPsMzNATp7RcACQQZ6s9ZNTFjzIDGdHJ7P1WenVufjTfk6KEIirfGweNcNRvMAQipbqGudLIfOFMisi7W7STQ==; 20:UTPyKZA6eau4mtezrTNV7fUUy1Mo4UM4y7EwBMJ0R31zUGJnmmicpTnpl3yW0rOU72ITjWeQ0OYvbnLyP8L/QU1UyoWLZThiwIRuzg52rsPXT5MS4wO/SdSVA/Drd4ADor3XRo/8Y/Fm+vQf62boRv0XuK/q+XwuVxwpx8jjKnY= x-ms-office365-filtering-correlation-id: 2f14a40d-5b98-4515-d7af-08d47a8377c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(24454002)(377424004)(5250100002)(36756003)(6306002)(2906002)(82746002)(38730400002)(3660700001)(110136004)(3280700002)(86362001)(97736004)(102836003)(6116002)(6486002)(5660300001)(99286003)(229853002)(6506006)(6512007)(6436002)(53936002)(83716003)(4326008)(50226002)(8936002)(6916009)(76176999)(42882006)(74482002)(50986999)(2950100002)(53546009)(25786009)(81166006)(8676002)(6246003)(39060400002)(189998001)(2900100001)(305945005)(57306001)(230783001)(7736002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <8262B97043538644BA33AE5AD1797D34@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 11:20:43.3954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: f_Wt9AHeNgy4hij59g_HgQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 11:20:56 -0000 SGkgQm9iLA0KDQpUaGVzZSBnZW5lcmFsbHkgbG9vayBnb29kLCBhIGZldyBjb21tZW50cyBpbi1s aW5lLi4uDQoNCj4gT24gMzEgTWFyIDIwMTcsIGF0IDE2OjMyLCBCb2IgSGluZGVuIDxib2IuaGlu ZGVuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IEkgcHVibGlzaGVkIGEgbmV3 IHZlcnNpb24gb2YgcmZjMTk4MWJpcyAoLTA1KS4gIExpbmtzIHRvIHRoZSBkb2N1bWVudCBiZWxv dy4NCj4gDQo+IFRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiBhcmUgYmFzZWQgb24gY29tbWVu dHMgaW4gSUVURiBsYXN0IGNhbGwgcmV2aWV3cyBieSBHb3JyeSBGYWlyaHVyc3QsIEpvZSBUb3Vj aCwgU3VzYW4gSGFyZXMsIFN0ZXdhcnQgQnJ5YW50LCBSaWZhYXQgU2hla2gtWXVzZWYsIGFuZCBE b25hbGQgRWFzdGxha2UuICBNYW55IHRoYW5rIHRvIHRoZSByZXZpZXdlcnMgYXMgSSB0aGluayB0 aGUgZG9jdW1lbnQgaXMgc2lnbmlmaWNhbnRseSBpbXByb3ZlZCwgaXQgaXMgbXVjaCBiZXR0ZXIg YWxpZ25lZCB3aXRoIGN1cnJlbnQgdHJhbnNwb3J0IHByYWN0aWNlLg0KPiANCj4gVGhlIGNoYW5n ZXMgaW5jbHVkZToNCj4gDQo+ICAgbyAgQ2xhcmlmeSB0aGF0IHRoZSBwdXJwb3NlIG9mIFBNVFVE IGlzIHRvIHJlZHVjZSB0aGUgbmVlZA0KPiAgICAgIGZvciBJUHY2IEZyYWdtZW50YXRpb24uDQo+ IA0KPiAgIG8gIEFkZGVkIHRleHQgdG8gSW50cm9kdWN0aW9uIGFib3V0IGVmZmVjdHMgb24gUE1U VUQgd2hlbg0KPiAgICAgIElDTVB2NiBtZXNzYWdlcyBhcmUgYmxvY2tlZC4NCg0KSSB0aGluayAi YXJlIHN1c2NlcHRpYmxlIHRvIGxvc3MgaWYiIHNob3VsZCByZWFkIOKAnGFyZSBzdXNjZXB0aWJs ZSB0byBwYWNrZXQgbG9zcyBpZuKAnSBvciBwZXJoYXBzICJhcmUgc3VzY2VwdGlibGUgdG8gcHJv YmxlbWF0aWMgY29ubmVjdGl2aXR5IGlmIOKAnA0KDQpJIG5vdGljZSB0aGF0IHNvbWUgdGV4dCBp biBSRkMxOTgxYmlzIHVzZXMgUkZDMjExOS1zdHlsZSBNVVNUL1NIT1VMRC9ldGMgdGV4dCwgYnV0 IHRoZSBkb2N1bWVudCBkb2VzbuKAmXQgaW5jbHVkZSB0aGUgMjExOSDigJxib2lsZXJwbGF0ZeKA nS4gIFNob3VsZCB0aGlzIGJlIGFkZGVkPyAgQW5kIHNob3VsZCB0aGUgdXNlIG9mIHNob3VsZC9T SE9VTEQsIG11c3QvTVVTVCwgZXRjIGJlIHJldmlld2VkIHRocm91Z2ggdGhlIGRvY3VtZW50Pw0K DQpUaGVyZeKAmXMgYSBkaXNjcmVwYW5jeSBiZXR3ZWVuIDE5ODFiaXMgYW5kIDI0NjBiaXMgb24g UE1UVUQgaW1wbGVtZW50YXRpb24uICAxOTgxYmlzIHNheXMgU0hPVUxEIGltcGxlbWVudCwgMjQ2 MGJpcyBzYXlzIGltcGxlbWVudGF0aW9uIGlzIOKAnHN0cm9uZ2x5IHJlY29tbWVuZGVk4oCdIC0g cGVyaGFwcyBiZSBjb25zaXN0ZW50Pw0KDQo+ICAgbyAgQ2xhcmlmaWVkIGluIFNlY3Rpb24gNC4g dGhhdCBub2RlcyBzaG91bGQgdmFsaWRhdGUgdGhlDQo+ICAgICAgcGF5bG9hZCBvZiBJQ01QdjYg UFRCIG1lc3NhZ2VzIHBlciBSRkM0NDQzLg0KPiANCj4gICBvICBSZW1vdmVkIHRleHQgaW4gU2Vj dGlvbiA1LjIgYWJvdXQgdGhlIG51bWJlciBvZiBwYXRocyB0byBhDQo+ICAgICAgZGVzdGluYXRp b24uDQo+IA0KPiAgIG8gIENoYW5nZWQgdGl0bGUgb2YgU2VjdGlvbiA1LjQgdG8gIlBhY2tldGl6 YXRpb24gbGF5ZXINCj4gICAgICBhY3Rpb25zIi4NCj4gDQo+ICAgbyAgQ2xhcmlmaWVkIGZpcnN0 IHBhcmFncmFwaCBpbiBTZWN0aW9uIDUuNCB0byB0byBjb3ZlciBhbGwNCj4gICAgICBwYWNrZXRp emF0aW9uIGxheWVycywgbm90IGp1c3QgVENQLg0KPiANCj4gICBvICBDbGFyaWZpZWQgdGV4dCBp biBTZWN0aW9uIDUuNCB0byB1c2Ugbm9ybWFsIHJldHJhbnNtaXNzaW9uDQo+ICAgICAgbWV0aG9k cy4NCj4gDQo+ICAgbyAgQWRkIGNsYXJpZmljYXRpb24gdG8gTm90ZSBpbiBTZWN0aW9uIDUuNCBh Ym91dA0KPiAgICAgIHJldHJhbnNtaXNzaW9ucy4NCj4gDQo+ICAgbyAgUmVtb3ZlZCB0ZXh0IGlu IFNlY3Rpb24gNS40IHRoYXQgZGVzY3JpYmVkIDQuMkJTRCBhcyBpdCBpcw0KPiAgICAgIG5vdyBv YnNvbGV0ZS4NCj4gDQo+ICAgbyAgUmVtb3ZlZCByZWZlcmVuY2UgdG8gVFA0IGluIFNlY3Rpb24g NS41Lg0KPiANCj4gICBvICBVcGRhdGVkIHRleHQgaW4gU2VjdGlvbiA1LjUgYWJvdXQgTkZTIGlu Y2x1ZGluZyBhZGRpbmcgYQ0KPiAgICAgIGN1cnJlbnQgcmVmZXJlbmNlIHRvIE5GUyBhbmQgcmVt b3Zpbmcgb2Jzb2xldGUgdGV4dC4NCj4gDQo+ICAgbyAgUmV2aXNlZCB0ZXh0IGluIFNlY3Rpb24g NiB0byBjbGFyaWZ5IGZpcnN0IGF0dGFjaw0KPiAgICAgIHJlc3BvbnNlLg0KPiANCj4gICBvICBB ZGRlZCBuZXcgdGV4dCBpbiBTZWN0aW9uIDYgdG8gY2xhcmlmeSB0aGUgZWZmZWN0IG9mDQo+ICAg ICAgSUNNUHY2IGZpbHRlcmluZyBvbiBQTVRVRC4NCg0KUGVyaGFwcyByZWZlcmVuY2UgUkZDNDg5 MCBoZXJlPw0KDQo+ICAgbyAgQWxpZ25lZCB0ZXJtaW5vbG9neSBmb3IgdGhlIHBhY2tldGl6YXRp b24gbGF5ZXINCj4gICAgICB0ZXJtaW5vbG9neS4NCj4gDQo+ICAgbyAgRWRpdG9yaWFsIGNoYW5n ZXMuDQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBjYW4gYmUgZm91bmQg YXQ6DQo+IA0KPiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtNm1hbi1yZmMxOTgxYmlzLTA1LnR4dA0KPiANCj4gUGxlYXNlIHJldmlldy4NCj4gDQo+IFRo aXMgaXMgcGFydCBvZiB0aGUgcHJvamVjdCB0byBtb3ZlIHRoZSBjb3JlIElQdjYgc3BlY2lmaWNh dGlvbnMgdG8gSW50ZXJuZXQgU3RhbmRhcmQuDQoNCkJlc3Qgd2lzaGVzLA0KVGltDQoNCj4gDQo+ IFRoYW5rcywNCj4gQm9iDQo+IA0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYt Nm1hbi1yZmMxOTgxYmlzLTA1LnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBSb2JlcnQgTS4gSGluZGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQo+PiBJRVRGIHJlcG9zaXRv cnkuDQo+PiANCj4+IE5hbWU6CQlkcmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcw0KPj4gUmV2aXNp b246CTA1DQo+PiBUaXRsZToJCVBhdGggTVRVIERpc2NvdmVyeSBmb3IgSVAgdmVyc2lvbiA2DQo+ PiBEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTMxDQo+PiBHcm91cDoJCTZtYW4NCj4+IFBhZ2VzOgkJ MTgNCj4+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMtMDUudHh0DQo+PiBTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFi aXMvDQo+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtNm1hbi1yZmMxOTgxYmlzLTA1DQo+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcy0wNQ0K Pj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLTZtYW4tcmZjMTk4MWJpcy0wNQ0KPj4gDQo+PiBBYnN0cmFjdDoNCj4+ICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBQYXRoIE1UVSBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNi4gIEl0 IGlzDQo+PiAgbGFyZ2VseSBkZXJpdmVkIGZyb20gUkZDIDExOTEsIHdoaWNoIGRlc2NyaWJlcyBQ YXRoIE1UVSBEaXNjb3ZlcnkgZm9yDQo+PiAgSVAgdmVyc2lvbiA0LiAgSXQgb2Jzb2xldGVzIFJG QzE5ODEuDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo= From nobody Mon Apr 3 04:27:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C7F127BA3 for ; Mon, 3 Apr 2017 04:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 2Jtb0np3RYND for ; Mon, 3 Apr 2017 04:27:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB511250B8 for ; Mon, 3 Apr 2017 04:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491218864; bh=3h2/DV1xVDxN2PYXqd9K86lHJFJZnWLLJqkcUtNo2es=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:MIME-Version:Content-Type; b=LalC9chS7LwtUAXtDx6uRzqlqGVsyGFgHlOoo0CSIiCSYaKd4A5NdfcSC1faSxfCXhRWq8FyMlpOlSJA8H9qslr+Wb4yVhiHvjUYaBDkuILFJaeLUxRFd5f1tWiTSFDyTCFw2Z6D91nCGxlH+qrvQ0xuOd45KE8P/MuGKZjK5es= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0242.outbound.protection.outlook.com [213.199.154.242]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-90-DDHlOMncNyK7l4jKTRSc9Q-1; Mon, 03 Apr 2017 12:27:38 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 3 Apr 2017 11:27:37 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1019.014; Mon, 3 Apr 2017 11:27:37 +0000 From: Tim Chown To: Jan Zorz - Go6 CC: Doug Barton , "ipv6@ietf.org" Subject: Re: [Editorial Errata Reported] RFC5952 (4986) Thread-Topic: [Editorial Errata Reported] RFC5952 (4986) Thread-Index: AQHSqjbc6gQLScszX0+wuauxdXWvOqGvIUUAgAN0HwCAAAz7gIAABLGAgAAPOoCAAM/eAA== Date: Mon, 3 Apr 2017 11:27:37 +0000 Message-ID: References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:f14f:15a4:6a00:cc70] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:+kiEORjnKRFwNlhzE9y/aV/xAEWUXXb6kQSPfyj6HPxMU2dBjuqCpIh/pdbtIrkM6THU1dtn2WQGmqKA8viszaAvWT1kpun2zBZB34G/lDRaCJK4Rcn3tqbkvinN6mTiBoKcUgPT2DCX/kuyTdjJ6KkDQV0D4DQSXbNVB7Fm73F6e7+Ld8HaB8qDRfNFOq6dlI2L0mpkNdUG9yx9SrkiAtt8shlgqehzPGSdiWJlVahgtL9iX2tbAaf27s7Fj0ht2r6xxj2/bcLHcXidLN0pcEdOyl5/a+r0yQXncTgFsVjka8rWlHoJfuwoFjGD2CrLBKdbyXfJ1Bwl8VNCGKcODg==; 20:O8YqKQ44ZWezmcMJgrgAZWZdSWw6RSgLh2sHucRqEPhb7mSb6bnB4DKdB/oORo1vNEyBcn5R4Akuy74lVF+6EXUrHVQlWrXJthjM4U4uuqMT+60b3lNjvFnonW9oUj9tdlEcjKzo78z4GbFb5wxrM2mkto+bSGszKrq/EdU+qOE= x-ms-office365-filtering-correlation-id: ede889e1-e2bf-486c-7f2c-08d47a846e5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39400400002)(39450400003)(24454002)(38730400002)(110136004)(189998001)(83716003)(86362001)(57306001)(6246003)(53936002)(53546009)(8936002)(8676002)(4326008)(33656002)(5660300001)(229853002)(50226002)(81166006)(36756003)(25786009)(6512007)(2906002)(5250100002)(6916009)(6116002)(7906003)(42882006)(102836003)(2950100002)(82746002)(6306002)(7736002)(54896002)(54906002)(99286003)(236005)(16799955002)(76176999)(2900100001)(6506006)(606005)(50986999)(6486002)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 11:27:37.0060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: DDHlOMncNyK7l4jKTRSc9Q-1 Content-Type: multipart/alternative; boundary="_000_EAB1A38E4E164D10A4B077F3DD8B2670jiscacuk_" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 11:27:49 -0000 --_000_EAB1A38E4E164D10A4B077F3DD8B2670jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMyBBcHIgMjAxNywgYXQgMDA6MDMsIEphbiBab3J6IC0gR282IDxqYW5AZ282LnNpPG1haWx0 bzpqYW5AZ282LnNpPj4gd3JvdGU6DQoNCk9uIDAzLzA0LzIwMTcgMDA6MDksIERvdWcgQmFydG9u IHdyb3RlOg0KLi4uIEkgZmluZCBpdCBzYWQgdGhhdCBBKSBwZW9wbGUgY291bGQgdGhpbmsgdGhh dCB0aGlzIGlzIGEgcHJvYmxlbSwgYW5kDQpCKSB0aGF0IHBlb3BsZSB3aG8gYXJlIGNvbmZ1c2Vk IGFib3V0IGhvdyBtYW55IDE2IGJpdCBmaWVsZHMgbWFrZSB1cCBhbg0KSVB2NiBhZGRyZXNzIGNv dWxkIHBvc3NpYmx5IGdldCBtb3JlIGNvbmZ1c2VkIGJ5IGhvdyBtYW55IGZpZWxkcyBhcmUNCmJl aW5nIHJlcGxhY2VkIGJ5IGFsbC16ZXJvcy4gKElzIDE6MjozOjQ6NTo2Ojo4IHJlYWxseSBhbWJp Z3VvdXM/DQpTZXJpb3VzbHk/KQ0KDQpJbiByZWFsIHdvcmxkIC0gY29tcHJlc3Npb24gYW5kIGRl Y29tcHJlc3Npb24gb2YganVzdCAxNiBiaXRzIGJldHdlZW4gdGhlIDo6IHNpbXBseSB3b3Jrcy4N Cg0KSW5kZWVkLg0KDQpJIHNlYXJjaGVkIC0gaXQgc2VlbXMgdGhlcmXigJlzIGFscmVhZHkgYW4g ZXJyYXR1bSBmaWxlZCBhZ2FpbnN0IHNlY3Rpb24gNC4yLjIgdG8gcmVtb3ZlIHRoZSBNVVNUIE5P VCBvbiB1c2luZyA6OiBmb3IganVzdCBvbmUgc2V0IG9mIHplcm9zLg0KDQpodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9laWQ9NDkwMA0KDQpXaGljaCBJIGFncmVl IHdpdGgsIGFzIDU5NTIgaXMgdGhlbiBjb21wbGlhbnQgYWdhaW4gd2l0aCBSRkM0MjkxLCB3aXRo IOKAnDo6IGNhbiByZXBsYWNlIG9uZSBvciBtb3JlIHNldHMgb2YgemVyb3PigJ0uDQoNClRpbQ0K DQpDaGVlcnMsIEphbg0KDQoNClNvIGlmIHVwZGF0aW5nIDQuMi4yIG9mIDU5NTIgd2lsbCBtYWtl IHRoaW5ncyBtb3JlIGNsZWFyIGZvciBwZW9wbGUsIGl0DQpzaG91bGQgcHJvYmFibHkgYmUgZG9u ZS4NCg0KRG91Zw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg== --_000_EAB1A38E4E164D10A4B077F3DD8B2670jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <635FBEA1087F4044864DC1C70B263893@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAzIEFwciAyMDE3LCBhdCAwMDow MywgSmFuIFpvcnogLSBHbzYgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW5AZ282LnNpIiBjbGFzcz0i Ij5qYW5AZ282LnNpPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMDMvMDQv MjAxNyAwMDowOSwgRG91ZyBCYXJ0b24gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+Li4uIEkgZmluZCBpdCBzYWQgdGhhdCBBKSBwZW9wbGUgY291 bGQgdGhpbmsgdGhhdCB0aGlzIGlzIGEgcHJvYmxlbSwgYW5kPGJyIGNsYXNzPSIiPg0KQikgdGhh dCBwZW9wbGUgd2hvIGFyZSBjb25mdXNlZCBhYm91dCBob3cgbWFueSAxNiBiaXQgZmllbGRzIG1h a2UgdXAgYW48YnIgY2xhc3M9IiI+DQpJUHY2IGFkZHJlc3MgY291bGQgcG9zc2libHkgZ2V0IG1v cmUgY29uZnVzZWQgYnkgaG93IG1hbnkgZmllbGRzIGFyZTxiciBjbGFzcz0iIj4NCmJlaW5nIHJl cGxhY2VkIGJ5IGFsbC16ZXJvcy4gKElzIDE6MjozOjQ6NTo2Ojo4IHJlYWxseSBhbWJpZ3VvdXM/ PGJyIGNsYXNzPSIiPg0KU2VyaW91c2x5Pyk8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 YnIgY2xhc3M9IiI+DQpJbiByZWFsIHdvcmxkIC0gY29tcHJlc3Npb24gYW5kIGRlY29tcHJlc3Np b24gb2YganVzdCAxNiBiaXRzIGJldHdlZW4gdGhlIDo6IHNpbXBseSB3b3Jrcy48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCkluZGVlZC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2Pkkgc2VhcmNoZWQgLSBpdCBzZWVtcyB0aGVyZeKAmXMgYWxyZWFkeSBhbiBlcnJhdHVtIGZp bGVkIGFnYWluc3Qgc2VjdGlvbiA0LjIuMiB0byByZW1vdmUgdGhlIE1VU1QgTk9UIG9uIHVzaW5n IDo6IGZvciBqdXN0IG9uZSBzZXQgb2YgemVyb3MuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLnBocD9laWQ9NDkwMCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv ZXJyYXRhX3NlYXJjaC5waHA/ZWlkPTQ5MDA8L2E+PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5XaGljaCBJIGFncmVlIHdpdGgsIGFzIDU5NTIgaXMgdGhlbiBjb21wbGlh bnQgYWdhaW4gd2l0aCBSRkM0MjkxLCB3aXRoIOKAnDo6IGNhbiByZXBsYWNlIG9uZSBvciBtb3Jl IHNldHMgb2YgemVyb3PigJ0uPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5UaW08L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsIEphbjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NClNvIGlmIHVwZGF0aW5nIDQuMi4yIG9mIDU5NTIgd2lsbCBtYWtlIHRo aW5ncyBtb3JlIGNsZWFyIGZvciBwZW9wbGUsIGl0PGJyIGNsYXNzPSIiPg0Kc2hvdWxkIHByb2Jh Ymx5IGJlIGRvbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRG91ZzxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIi Pg0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIGNsYXNzPSIiPmlwdjZAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2NjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EAB1A38E4E164D10A4B077F3DD8B2670jiscacuk_-- From nobody Mon Apr 3 05:47:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DE71295EA for ; Mon, 3 Apr 2017 05:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 eLp5C9rgYdVY for ; Mon, 3 Apr 2017 05:46:58 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 EDA0C128768 for ; Mon, 3 Apr 2017 05:46:57 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id 68so11920843ioh.3 for ; Mon, 03 Apr 2017 05:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GUF2lEVVDeS3Z4Lqejzf+Ov9ytenrpmXGyczRzbi2j0=; b=Nw5Ij8HUGGz32YFDKLb7c/gvU/wnhXW5rzpmgxt/ZMTS0K3Tn0j1MQlGzMTqoHJZlA fJZVKz4nLkjDU6dmvdcfiWNJJ/IXbIZ6dNX9vrLpZMwIJvji7TkzLp8LCSRSZUyYS21Q jAY7QAdfWEPXVke+XhUo3Gn/+QVcVzHCS6TlI2UwAo31z9MtVsEen6Jp3eSZUKkJ6WjI bAzUPmUZEBFeG4kC/NSS/YJ2OVkc9xksA4lmh0TVfYIV/aEdIYnulcZfBm4qBjMgZT2m t5kct84xONp0Ryn0HRPSqjAbBunIIhNvkhMD+T0pBWIyOWqz6B/qi+56NTtmLam3P19x yD0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GUF2lEVVDeS3Z4Lqejzf+Ov9ytenrpmXGyczRzbi2j0=; b=VL6W1NRDizS6bqCLpaOqOkqojLpVeZoxvNL8du6YYHr7DkLiJoDqvfwppXi/IrO0HW 1DX4Rbh51IMt52MJeAEfMhuoJ2fFj3GiJOK7ewZEb0vtNr3A05Wrj8Ek5ZVAKd04/kZ1 xk2A8305xnVhH0WTC1OEoByVp/5y/y60h8TRVl2d+uBnd3jweSy/y/OgB34QIBZBHV8P de6qVX/fYVIdslNE/QRJRNRc12f7ikKiklJKBysvhyEEJXufNo1jBGqOeHJqGrsra6vT BAmVd+4clKlasqOdgaCvyNvFBkcC2xAK7w31mOC4JSE6bH1mrE18lSPOFHNSLxBOKK9B Hm1Q== X-Gm-Message-State: AFeK/H0Gj27j/9FPZPQsCAh7dJ6A7g5u2bD0s0NTnIb+13fpdMDrexYHakS5l2T2rC2XQw== X-Received: by 10.107.150.201 with SMTP id y192mr17965504iod.33.1491223617012; Mon, 03 Apr 2017 05:46:57 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id p6sm7610187iof.12.2017.04.03.05.46.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 05:46:56 -0700 (PDT) Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Mikael Abrahamsson , Jan Zorz - Go6 References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: "ipv6@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: <080f9cab-c5be-56a2-7a18-c4cb674e8db8@gmail.com> Date: Tue, 4 Apr 2017 00:47:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 12:47:00 -0000 On 03/04/2017 18:00, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Jan Zorz - Go6 wrote: > >> On 03/04/2017 00:09, Doug Barton wrote: >>> ... I find it sad that A) people could think that this is a problem, and >>> B) that people who are confused about how many 16 bit fields make up an >>> IPv6 address could possibly get more confused by how many fields are >>> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? >>> Seriously?) >> >> In real world - compression and decompression of just 16 bits between the :: >> simply works. > > Saying that 1:2:3:4:5:6::8 is invalid fails the "rule of least > astonishment" test. > > $ ping6 1:2:3:4:5:6::8 > PING 1:2:3:4:5:6::8(1:2:3:4:5:6:0:8) 56 data bytes > > Agreed that this just works, and I don't understand why we would have text > that says it's not allowed? Sigh. RFC4291 defines the valid representations. RFC5952 defines the canonical representation. 1:2:3:4:5:6::8 is valid 1:2:3:4:5:6:0:8 is valid and canonical. This is not a problem. Brian From nobody Mon Apr 3 08:17:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E01270A0 for ; Mon, 3 Apr 2017 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Y5ghF6XSUT31 for ; Mon, 3 Apr 2017 08:17:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999F4128D44 for ; Mon, 3 Apr 2017 08:17:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 039722009E; Mon, 3 Apr 2017 11:41:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4722636BB; Mon, 3 Apr 2017 11:17:42 -0400 (EDT) From: Michael Richardson To: IETF IPv6 Mailing List cc: Erik Kline Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 In-Reply-To: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:17:45 -0000 --=-=-= Content-Type: text/plain Erik Kline wrote: > If the client doesn't understand the X flag then it can still process > the PIO according to its existing code. That's all. No conflict with > PD, really. So, a client that doesn't understand the X bit will just think it's sharing the link with other non-existant nodes, and will waste energy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljiZ5YACgkQgItw+93Q 3WUbXwgAhyruiI7HKDV+f3FXK8qH7A79f6cinqpuv5nXfy31x3YI9KgdwGh5SKnz xmj7VgRctaeAriZRhv7+4w6BsMDildlLHkqfPVUJNOEj6aqFKYeLN0KRCfSZzhEx 1hxAxYjliU5MRLa5KgbS+JGlhFFtSbZ6OTx9FF2ZeVq28l9BFgazcbFEj59bUs/r KXzv78SwrkbvdxNjS4hC2OaCJ9YxdCKBw0mq9ZFF5RMP7s5TUCH1FKyKyeM+G3xO KRe2FAmAAYTre1T1MkzjDkuS0pquZSd537yojauAGYAXDZWEdAWJZ2GL1EwG9Sag skjAluHpy/rrt2dpXqeOLm3yT98KbA== =bxNY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 3 09:50:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BD6129479 for ; Mon, 3 Apr 2017 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 gI31k_AphkiD for ; Mon, 3 Apr 2017 09:50:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA22D12709D for ; Mon, 3 Apr 2017 09:50:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 029B42055A; Mon, 3 Apr 2017 13:15:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9D184636BB; Mon, 3 Apr 2017 12:50:47 -0400 (EDT) From: Michael Richardson to: IETF IPv6 Mailing List CC: Erik Kline Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 In-Reply-To: <865.1491232662@obiwan.sandelman.ca> References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:50:51 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: >> If the client doesn't understand the X flag then it can still process >> the PIO according to its existing code. That's all. No conflict with >> PD, really. > So, a client that doesn't understand the X bit will just think it's > sharing > the link with other non-existant nodes, and will waste energy. I remembered what was bothering me: a client that doesn't understand the X bit might be surprised that there is no router on the link with that prefix. Generally, clients configure default routes via LL addresses, so I think that we are okay. You say in section 5.3 that L=0, A=1 as SHOULD. Is there a reason you wouldn't make that a MUST? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljifWcACgkQgItw+93Q 3WUnwQgAwtx/wc8zmqMoXgD7u7seFHrtLHP6BrHJ+KPnv6VyomPYcPyzBkRxOB72 W2p9g41Ha+C1Y537PtZIKUEmxwnah2ssjH9gIwy0P2fyy5oDj8xqECfyLlUw5Dr8 cxrZ8IZBJ/fsnDWL9VcBySMbwWd805Zddk/fONDKvTq2Ao6esB38xI/+aKSFVy8n 9Uv3Y/0ahYFFjgMBpJJZ3Ch4XE+aTOhjgkguS6yJdABX9zaXGmxdfzwNB69zXNzb cDZYOGDX6JjDPY6bApH39T/oEyYpXAjtevQwA5HTy6sPxAMsSrap7nbtp0PaQAiB xmIpGV5Qa1yFuJ4Y5PdosVxr6P3ujg== =nG06 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 3 09:56:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CD6129477 for ; Mon, 3 Apr 2017 09:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 iANSYL8388Ry for ; Mon, 3 Apr 2017 09:56:17 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73343127A90 for ; Mon, 3 Apr 2017 09:56:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7F62AA2; Mon, 3 Apr 2017 18:56:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1491238575; bh=jq76cvcpsMRCfGGbsFdA5P4iJXA/UVmfB4wxHjYz9Rw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vTtUXFBjMYNnVXQVb+ya3jfggm1t/hYLY2+m8lHH+EhoKA0VVmZt0kCGShY3qz86j HVH1zsOUDJU+vdEKdYLeNBW1TpoNHVVlVc/WIaxGX5brXnDqP/UQ+I6XcpbGNh/ori 7KgXevrO/rEwWmzR8Qr7LhDRPi119D3LratygKAE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6600888; Mon, 3 Apr 2017 18:56:15 +0200 (CEST) Date: Mon, 3 Apr 2017 18:56:15 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson cc: IETF IPv6 Mailing List , Erik Kline Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 In-Reply-To: <21708.1491238247@obiwan.sandelman.ca> Message-ID: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:56:20 -0000 On Mon, 3 Apr 2017, Michael Richardson wrote: > I remembered what was bothering me: a client that doesn't understand > the X bit might be surprised that there is no router on the link with > that prefix. Generally, clients configure default routes via LL > addresses, so I think that we are okay. I have never seen a default route learnt by RA point to anything apart than the router LL address. https://tools.ietf.org/html/rfc4861#page-19 4.2. Router Advertisement Message Format ... Source Address MUST be the link-local address assigned to the interface from which this message is sent. So this can't happen any other way, right? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 3 10:24:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97834129495 for ; Mon, 3 Apr 2017 10:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 sgJZiRBuNw7J for ; Mon, 3 Apr 2017 10:24:43 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D09129469 for ; Mon, 3 Apr 2017 10:24:43 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8C53E85F83 for ; Mon, 3 Apr 2017 13:24:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=5oBVza jq6i7FdFMTiOKYrhdOD40=; b=gHXncvOtpwJShy5QTSevHxamBaQ7SbIwjml74D kQXWXpW6f8ZuI3N7Go3sSsXDU7Qy8HaGhRCpBGdZQCQM8ARfy1I24BYVxmhJexWY MKjDcjRWCaLJMGc6g+PighP3Q5RnD2rUImZIbtnEeQueQxGsV4uZy1BUHenhC1oC 3qqPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= gHPdfUKvqVseT3zjKy1+Pt/6oQ5jIkyRM7oEqJt7XOwwqWVZa+zjgvj+k6uosVNH 4/O44ro595XAuMpW2f6/+5HP2oHENwqkHfiK60gJi/h+HAHjhEFbEujTZIcHVgey BZI0IRyGD03XjJ2sLuGkho6zRAv7nSqkGv8GDCkSmRw= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8363A85F82 for ; Mon, 3 Apr 2017 13:24:41 -0400 (EDT) Received: from mail-qk0-f169.google.com (unknown [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id EB3FE85F80 for ; Mon, 3 Apr 2017 13:24:40 -0400 (EDT) Received: by mail-qk0-f169.google.com with SMTP id p22so120559502qka.3 for ; Mon, 03 Apr 2017 10:24:40 -0700 (PDT) X-Gm-Message-State: AFeK/H2dyFjD6BAjkVNQ2aZOGrjwwbP5mhd5QeGX1g5LqEungazNd9h94EU468INgkmCGct6IHXbJpmQrvdMQQ== X-Received: by 10.55.66.65 with SMTP id p62mr16205405qka.191.1491240280380; Mon, 03 Apr 2017 10:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Mon, 3 Apr 2017 10:24:20 -0700 (PDT) From: "C. M. Heard" Date: Mon, 3 Apr 2017 10:24:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: To: Bob Hinden , IPv6 List Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 6BBA9D76-1892-11E7-A5F8-97B1B46B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:24:46 -0000 Greetings, 1.) In Section 5.3, the fourth paragraph up from the bottom of Page 9 would, in my opinion, be clearer with the following change: OLD: The node then uses the value in the MTU field in the Packet Too Big message as a tentative PMTU value or the minimum IPv6 next hope MTU if that is larger, and compares the tentative PMTU to the existing PMTU. NEW: The node then uses the value in the MTU field in the Packet Too Big message as a tentative PMTU value or the IPv6 minimum link MTU if that is larger, and compares the tentative PMTU to the existing PMTU. In other words, s/minimum IPv6 next hope MTU/IPv6 minimum link MTU/. That will make the terminology consistent with the rest of the document. 2.) It is difficult to tell from Appendix B what has actually changed since RFC 1981. The detailed account of what was changed from one draft to the next has been very useful to the working group but will not be particularly helpful to readers of an archival document. I would therefore suggest that prior to publication as an RFC this Appendix should be replaced with an actual summary of the changes since RFC 1981. I might note that this same point was made by Robert Sparks in his GEN-ART review of companion document draft-ietf-6man-rfc4291bis (see https://www.ietf.org/mail-archive/web/ipv6/current/msg26035.html): > Appendix B looks like something groups normally ask the RFC Editor > to delete. If that was your intent, please add instructions to the > RFC Editor so they don't have to ask. If you planned to leave it, a > summary of the changes rather than a chronolog of what draft version > changes were made in would be much more useful to future readers. > (Such a summary would be welcome in any case.) I am aware that preparing such a summary is a significant amount of work, and I am willing to send text should the editor so desire. Thanks and regards, Mike Heard On Fri, 31 Mar 2017 10:32:02 -0500, Bob Hinden wrote: > Hi, > > I published a new version of rfc1981bis (-05). Links to the document below. > > The changes in this version are based on comments in IETF last call reviews > by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, Rifaat > Shekh-Yusef, and Donald Eastlake. Many thank to the reviewers as I think > the document is significantly improved, it is much better aligned with > current transport practice. > > The changes include: > > o Clarify that the purpose of PMTUD is to reduce the need > for IPv6 Fragmentation. > > o Added text to Introduction about effects on PMTUD when > ICMPv6 messages are blocked. > > o Clarified in Section 4. that nodes should validate the > payload of ICMPv6 PTB messages per RFC4443. > > o Removed text in Section 5.2 about the number of paths to a > destination. > > o Changed title of Section 5.4 to "Packetization layer > actions". > > o Clarified first paragraph in Section 5.4 to to cover all > packetization layers, not just TCP. > > o Clarified text in Section 5.4 to use normal retransmission > methods. > > o Add clarification to Note in Section 5.4 about > retransmissions. > > o Removed text in Section 5.4 that described 4.2BSD as it is > now obsolete. > > o Removed reference to TP4 in Section 5.5. > > o Updated text in Section 5.5 about NFS including adding a > current reference to NFS and removing obsolete text. > > o Revised text in Section 6 to clarify first attack > response. > > o Added new text in Section 6 to clarify the effect of > ICMPv6 filtering on PMTUD. > > o Aligned terminology for the packetization layer > terminology. > > o Editorial changes. > > A diff from the previous version can be found at: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-05.txt > > Please review. > > This is part of the project to move the core IPv6 specifications to Internet > Standard. > > Thanks, > Bob > >> A new version of I-D, draft-ietf-6man-rfc1981bis-05.txt >> has been successfully submitted by Robert M. Hinden and posted to the >> IETF repository. >> >> Name: draft-ietf-6man-rfc1981bis >> Revision: 05 >> Title: Path MTU Discovery for IP version 6 >> Document date: 2017-03-31 >> Group: 6man >> Pages: 18 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-05.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-05 >> >> Abstract: >> This document describes Path MTU Discovery for IP version 6. It is >> largely derived from RFC 1191, which describes Path MTU Discovery for >> IP version 4. It obsoletes RFC1981. From nobody Mon Apr 3 12:54:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4C126D74 for ; Mon, 3 Apr 2017 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 p7UFIF-LVnOl for ; Mon, 3 Apr 2017 12:54:07 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 53C741294F5 for ; Mon, 3 Apr 2017 12:54:07 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id y18so49070356itc.1 for ; Mon, 03 Apr 2017 12:54:07 -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=WTOE5f9GecoxC3HkUTua5iV21fB+xCzuJsOpA0ws4W8=; b=rsF9bYyEV2p8XnBhIYIH52QA0j6tqPSuGMNNqDr5kw+CeaDUqXMxExUHuE1bsW6CiH yigla2s5Hd9WmL0vx10SXaSjNIRsWmxr6QfmIXlzXvgjv62BJxaWevdGHGtbf6BDlpWA JtNyJe3Gf5IftAeHL7Gy5KsFcP8czAkgRbOxoJqaixkfEY38cVfU3xBlI9YbQ5/wLco2 aeq6NS+Xg/kQhmkNBU7czyJU6OpDMX3d2I3gxJOau+jiMn2oQC0ko5py9O8IrKdHXMgW KcjHngzOXWa7KhZxH61XSD4CUOlq21S0ChgoLgfoZsf3UAMbQLvUdDDCoEvE4aoRHE3K PT5A== 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=WTOE5f9GecoxC3HkUTua5iV21fB+xCzuJsOpA0ws4W8=; b=O+Y9H6zcxM/CttVB0LHIvBRCRRwJ6h/GlcOCIR5O2h7eYBQg5kWV1Q2Lh1F5zF0bPf 5f73AUaCei5IFcjaeohPhZdKBwfi4/rBKyScLVGck3FOVlIfa1utjUZvNFvZ31z31uwc SMWik9/ERUGri/1pZKyPPEFhLSGI7uGOxxZ1EzDzcV/r8nJZVRSdagFN/fXk+WJaD3os j1h90c0hhpQVOirsg2vJeewP7XGSGM3Q8yN+K5ac/GaRDDRYu/1AXU8hX7gs2BZgxIsJ L5mZqYEj46hNTx3wrfRSRI4bXnAXC8UmXBA7Jcx0tyRYqwySR/65976clts1GArIml3r Rdvg== X-Gm-Message-State: AFeK/H3pYvV3DOnvRDyVHcFTI0cbHE0lYtG6QqMtfPVGjndvJZN2w0p5rbmq9f6V4pyBNg== X-Received: by 10.36.131.201 with SMTP id d192mr12710332ite.60.1491249246690; Mon, 03 Apr 2017 12:54:06 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id v136sm6213643ita.0.2017.04.03.12.54.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 12:54:05 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6193E711-DF58-42BE-AD7D-CFCEE5EA83B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Date: Mon, 3 Apr 2017 12:54:03 -0700 In-Reply-To: <55EC16DF-F4F0-4DAA-8AB6-382DAE8752E9@jisc.ac.uk> Cc: Bob Hinden , IPv6 List To: Tim Chown References: <55EC16DF-F4F0-4DAA-8AB6-382DAE8752E9@jisc.ac.uk> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 19:54:09 -0000 --Apple-Mail=_6193E711-DF58-42BE-AD7D-CFCEE5EA83B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tim, > On Apr 3, 2017, at 4:20 AM, Tim Chown wrote: >=20 > Hi Bob, >=20 > These generally look good, a few comments in-line=E2=80=A6 Thanks. Comments below. Bob >=20 >> On 31 Mar 2017, at 16:32, Bob Hinden wrote: >>=20 >> Hi, >>=20 >> I published a new version of rfc1981bis (-05). Links to the document = below. >>=20 >> The changes in this version are based on comments in IETF last call = reviews by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, = Rifaat Shekh-Yusef, and Donald Eastlake. Many thank to the reviewers as = I think the document is significantly improved, it is much better = aligned with current transport practice. >>=20 >> The changes include: >>=20 >> o Clarify that the purpose of PMTUD is to reduce the need >> for IPv6 Fragmentation. >>=20 >> o Added text to Introduction about effects on PMTUD when >> ICMPv6 messages are blocked. >=20 > I think "are susceptible to loss if" should read =E2=80=9Care = susceptible to packet loss if=E2=80=9D or perhaps "are susceptible to = problematic connectivity if =E2=80=9C I prefer the latter. I will hold that for the next update. >=20 > I notice that some text in RFC1981bis uses RFC2119-style = MUST/SHOULD/etc text, but the document doesn=E2=80=99t include the 2119 = =E2=80=9Cboilerplate=E2=80=9D. Should this be added? And should the = use of should/SHOULD, must/MUST, etc be reviewed through the document? That style was inherited from RFC1981, which was written before RFC2119. = I am hesitant to add RFC2119 and then have to do a review of all = RFC2119 words and not break interoperability. >=20 > There=E2=80=99s a discrepancy between 1981bis and 2460bis on PMTUD = implementation. 1981bis says SHOULD implement, 2460bis says = implementation is =E2=80=9Cstrongly recommended=E2=80=9D - perhaps be = consistent? SHOULD and =E2=80=9Cstrongly recommended=E2=80=9D are very close if not = equivalent. >=20 >> o Clarified in Section 4. that nodes should validate the >> payload of ICMPv6 PTB messages per RFC4443. >>=20 >> o Removed text in Section 5.2 about the number of paths to a >> destination. >>=20 >> o Changed title of Section 5.4 to "Packetization layer >> actions". >>=20 >> o Clarified first paragraph in Section 5.4 to to cover all >> packetization layers, not just TCP. >>=20 >> o Clarified text in Section 5.4 to use normal retransmission >> methods. >>=20 >> o Add clarification to Note in Section 5.4 about >> retransmissions. >>=20 >> o Removed text in Section 5.4 that described 4.2BSD as it is >> now obsolete. >>=20 >> o Removed reference to TP4 in Section 5.5. >>=20 >> o Updated text in Section 5.5 about NFS including adding a >> current reference to NFS and removing obsolete text. >>=20 >> o Revised text in Section 6 to clarify first attack >> response. >>=20 >> o Added new text in Section 6 to clarify the effect of >> ICMPv6 filtering on PMTUD. >=20 > Perhaps reference RFC4890 here? Thanks. I think that makes sense. >=20 >> o Aligned terminology for the packetization layer >> terminology. >>=20 >> o Editorial changes. >>=20 >> A diff from the previous version can be found at: >>=20 >> = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05.txt >>=20 >> Please review. >>=20 >> This is part of the project to move the core IPv6 specifications to = Internet Standard. >=20 > Best wishes, > Tim >=20 >>=20 >> Thanks, >> Bob >>=20 >>> A new version of I-D, draft-ietf-6man-rfc1981bis-05.txt >>> has been successfully submitted by Robert M. Hinden and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-ietf-6man-rfc1981bis >>> Revision: 05 >>> Title: Path MTU Discovery for IP version 6 >>> Document date: 2017-03-31 >>> Group: 6man >>> Pages: 18 >>> URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-05.txt >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>> Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05 >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05 >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05 >>>=20 >>> Abstract: >>> This document describes Path MTU Discovery for IP version 6. It is >>> largely derived from RFC 1191, which describes Path MTU Discovery = for >>> IP version 4. It obsoletes RFC1981. >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 --Apple-Mail=_6193E711-DF58-42BE-AD7D-CFCEE5EA83B6 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY4qhcAAoJEK7rdBF357uokkYH/ArvkK5X40M8Vyz6Z46OEnoS xBZt5w3SJ6gjVmrU3voR+Ls5O2Jzo/s7SsTrQd55HRuYYvG8QTZ9nAa6HJlXO5F9 zRMJn08rexXwd+LlpInrM1REbztoaf+l3s5WYcykP/PDN9bq1i2UVNAYGPJs67wx 4+438UkiGNjhYcS44VKmYEzosyfyp9CQyJm5CN55XOA04IaxdBaUFFiQTLtNV4NH tiH+t2lVUbA49lQ6INOt35xj5WWheCbMNJJlM3iY9vBXM3z+HowD07TUc2XKKi8J kfL//fvLnN/pDiA5hWiMKAHugtYlK/SFeOcnqLOK6KfBQqEKh6+EmmOCBRwzbRs= =5jUf -----END PGP SIGNATURE----- --Apple-Mail=_6193E711-DF58-42BE-AD7D-CFCEE5EA83B6-- From nobody Mon Apr 3 13:10:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074701294FB for ; Mon, 3 Apr 2017 13:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 byySyBLtExAx for ; Mon, 3 Apr 2017 13:10:44 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 67C93120726 for ; Mon, 3 Apr 2017 13:10:44 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id a140so17527675ita.0 for ; Mon, 03 Apr 2017 13:10:44 -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=dOIFzQy4Ovc1NU/ZnrctJA/J6VokgWs1nnF1/WMpWnc=; b=gKFkB47cKcHrXn3baBdlTNE9vgibK9moPXZmG5X/7oJ0+LenNjDrKbhPaCM3NEbqWV Kkn6k9+KfXxrsYXwJkZwBcgJiQBkcKWQgbjKJBjAk/hxfGhzrW89dFdZ5R9gRTU17bA5 qODrCRNQyKEV2gECdzCGvLinOFduIKy47259nx79FT4P+gVx6nUA3OrjLnyytJ1OZcVn iZs2UIGEJhmmjSci3Kge/Er+gnIya/w8VaSQwYlWBWpt3oPXKAlBsxuTd925sAZQiBCt OME4VFjuvodOvC8DaMpPLotMffVu6hgK2/c25WbMfBcc6/u2E4KP5MGK/d1OwQjP26N9 0psw== 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=dOIFzQy4Ovc1NU/ZnrctJA/J6VokgWs1nnF1/WMpWnc=; b=lyJR62c+F+Wa5KGCGYhzXH8EUFoTdbbRG19e9/pRe+ZVScEuQt0EBkoVO36lj/iwB7 BH8c6uAcTl2bh3BqEGlY7hMf2ximcOMCdYNe8oJHPLPAWUqIEg7osgwSqYRWpOjD+IfU 1/wDV03tgxl3Unieqyarca2xxGLzXyH1dSicYiwZSDPc1uPGTUL6lhJ/AQFVvSQaBzrI VTK0t/jJpi4iq8Gm4nY4TjT+gern//0/NrDLp1QeJd4/6VhGGaTu4lMs5Vb44h8MilaU D9rHFc6KO4RbhwJIuzF5os9EyU5wsuDeYIU6o+Fl/VhokD84W6UcddfVZlX4ElLw9K7N fDvA== X-Gm-Message-State: AFeK/H2cyN4DKKN+FoIUTf0IU5TbFxDWJyBjpN6A8nvOuvr+PtI0VVb0L8c46yLPLFvHSA== X-Received: by 10.36.7.3 with SMTP id f3mr3150110itf.27.1491250243710; Mon, 03 Apr 2017 13:10:43 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r85sm6231058itc.13.2017.04.03.13.10.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 13:10:43 -0700 (PDT) From: Bob Hinden Message-Id: <062B4D05-231E-4D9C-B3E6-F78E1660561A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B9A192A4-1E14-49F6-A3B9-D9F92ABB0EE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Date: Mon, 3 Apr 2017 13:10:39 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List To: "C. M. Heard" References: X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:10:47 -0000 --Apple-Mail=_B9A192A4-1E14-49F6-A3B9-D9F92ABB0EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, > On Apr 3, 2017, at 10:24 AM, C. M. Heard wrote: >=20 > Greetings, >=20 > 1.) In Section 5.3, the fourth paragraph up from the bottom of Page 9 > would, in my opinion, be clearer with the following change: >=20 > OLD: > The node then uses the value in the MTU field in the Packet Too Big > message as a tentative PMTU value or the minimum IPv6 next hope MTU > if that is larger, and compares the tentative PMTU to the existing > PMTU. >=20 > NEW: > The node then uses the value in the MTU field in the Packet Too Big > message as a tentative PMTU value or the IPv6 minimum link MTU > if that is larger, and compares the tentative PMTU to the existing > PMTU. >=20 > In other words, s/minimum IPv6 next hope MTU/IPv6 minimum link MTU/. > That will make the terminology consistent with the rest of the = document. Yes, I agree. Also removes the misspelled =E2=80=9Chop=E2=80=9D. >=20 > 2.) It is difficult to tell from Appendix B what has actually changed > since RFC 1981. The detailed account of what was changed from one = draft > to the next has been very useful to the working group but will not be > particularly helpful to readers of an archival document. I would > therefore suggest that prior to publication as an RFC this Appendix > should be replaced with an actual summary of the changes since RFC = 1981. >=20 > I might note that this same point was made by Robert Sparks in his > GEN-ART review of companion document draft-ietf-6man-rfc4291bis (see > https://www.ietf.org/mail-archive/web/ipv6/current/msg26035.html): >=20 >> Appendix B looks like something groups normally ask the RFC Editor >> to delete. If that was your intent, please add instructions to the >> RFC Editor so they don't have to ask. If you planned to leave it, a >> summary of the changes rather than a chronolog of what draft version >> changes were made in would be much more useful to future readers. >> (Such a summary would be welcome in any case.) >=20 > I am aware that preparing such a summary is a significant amount of > work, and I am willing to send text should the editor so desire. Thanks, I agree it=E2=80=99s a good idea. I did that for rfc2460bis = recently, and will work on that for rfc1981bis too. I will send a draft = copy to you to review prior publishing. Thanks, Bob >=20 > Thanks and regards, >=20 > Mike Heard >=20 > On Fri, 31 Mar 2017 10:32:02 -0500, Bob Hinden wrote: >> Hi, >>=20 >> I published a new version of rfc1981bis (-05). Links to the document = below. >>=20 >> The changes in this version are based on comments in IETF last call = reviews >> by Gorry Fairhurst, Joe Touch, Susan Hares, Stewart Bryant, Rifaat >> Shekh-Yusef, and Donald Eastlake. Many thank to the reviewers as I = think >> the document is significantly improved, it is much better aligned = with >> current transport practice. >>=20 >> The changes include: >>=20 >> o Clarify that the purpose of PMTUD is to reduce the need >> for IPv6 Fragmentation. >>=20 >> o Added text to Introduction about effects on PMTUD when >> ICMPv6 messages are blocked. >>=20 >> o Clarified in Section 4. that nodes should validate the >> payload of ICMPv6 PTB messages per RFC4443. >>=20 >> o Removed text in Section 5.2 about the number of paths to a >> destination. >>=20 >> o Changed title of Section 5.4 to "Packetization layer >> actions". >>=20 >> o Clarified first paragraph in Section 5.4 to to cover all >> packetization layers, not just TCP. >>=20 >> o Clarified text in Section 5.4 to use normal retransmission >> methods. >>=20 >> o Add clarification to Note in Section 5.4 about >> retransmissions. >>=20 >> o Removed text in Section 5.4 that described 4.2BSD as it is >> now obsolete. >>=20 >> o Removed reference to TP4 in Section 5.5. >>=20 >> o Updated text in Section 5.5 about NFS including adding a >> current reference to NFS and removing obsolete text. >>=20 >> o Revised text in Section 6 to clarify first attack >> response. >>=20 >> o Added new text in Section 6 to clarify the effect of >> ICMPv6 filtering on PMTUD. >>=20 >> o Aligned terminology for the packetization layer >> terminology. >>=20 >> o Editorial changes. >>=20 >> A diff from the previous version can be found at: >>=20 >> = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05.txt >>=20 >> Please review. >>=20 >> This is part of the project to move the core IPv6 specifications to = Internet >> Standard. >>=20 >> Thanks, >> Bob >>=20 >>> A new version of I-D, draft-ietf-6man-rfc1981bis-05.txt >>> has been successfully submitted by Robert M. Hinden and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-ietf-6man-rfc1981bis >>> Revision: 05 >>> Title: Path MTU Discovery for IP version 6 >>> Document date: 2017-03-31 >>> Group: 6man >>> Pages: 18 >>> URL: >>> = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-05.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>> Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-05 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-05 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-05 >>>=20 >>> Abstract: >>> This document describes Path MTU Discovery for IP version 6. It is >>> largely derived from RFC 1191, which describes Path MTU Discovery = for >>> IP version 4. It obsoletes RFC1981. --Apple-Mail=_B9A192A4-1E14-49F6-A3B9-D9F92ABB0EE1 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY4qxBAAoJEK7rdBF357uozW8H/ioQYaqeranSjq2xyRKfJZRE +MKNkZ5COb8t4Tu0BLxy32WmNVuTnEsx7Sfyy+RsepTdQlyPgq5KEYoic7MSU8N6 Beeu6hqTAGfmI/fBV84zRDbi6xxMUwBXFYj54T3yPkNtIRzrtDau7zTgkQ52DzDE Db52WjXS+vkEMvM1+lzs/2zUtzDposzJ+1JCXx1RDz/Qr1JEl0YiWba3ikIoTsbf JgxcrS4r6t8KQdkBVxuHqpgq5t6xyJPO1AdqEJfXIbIxSjASZZW03Qw32XecjPAy 9NjxtxT7g7eylPcaF0SRo9LStAQv/I4ubPn7ULWfDaydQRhLISpyh1nIwQtw43M= =gaCR -----END PGP SIGNATURE----- --Apple-Mail=_B9A192A4-1E14-49F6-A3B9-D9F92ABB0EE1-- From nobody Mon Apr 3 13:34:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CFA1294AC for ; Mon, 3 Apr 2017 13:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LgAuWYJeZ2_x for ; Mon, 3 Apr 2017 13:34:06 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 090CC1294FB for ; Mon, 3 Apr 2017 13:34:02 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z204so153425182vkd.1 for ; Mon, 03 Apr 2017 13:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oVOsZJwokO6FAmmE2KTdNTIXYQ1Im/HltaxmdtUf1N0=; b=utfxDQRjqvAa38G06uFaMruLUqkbxJMm85hFfqnlKU+w6KXNufFMgvKEWNZFjRd48F fzs+Jl1vahva3BqxVN2VE0dt2XpgNLOOMh6zEjl8Em2jQqBi3HZgvzyFOsVMLAg/7h/Z I0EDYrRVKLS84mXGrCo7upJLXNRnnlwnWidcDmtZiqafs3vFdiqrzGkt+3udObOY5cDj 78eYRONwwwYArDSemtzXZwC5mrW3w29b3DKfWDRHHA8Xmij1C9fmg88M6zNc6ftX06N/ b5zgGXgoTlSME8tz+0zrnC2ZLw2yPAbGI32MLyJk9f76Mj5vOrRlRLDwxtgSWNQmB55C YEYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oVOsZJwokO6FAmmE2KTdNTIXYQ1Im/HltaxmdtUf1N0=; b=i60osQNacO8K6HEhbaREZrtsVPJrkLSK5Vu/7B69eou8xsJL9t78L0tRFgIjTQMuym KdsraQEZqYP0vsn2QwZkfA5Cp2XhQs3j9lXatmkJuuGIENVpwgIV07yWJhEl4EFDGump PS3QilQZXbFoof3D50IAMUD/fZPBjZl6Ham6PBuHz6/WXzLT8cNwJUsWzGlXMGaJs/7v UP4cUFXrcMeYTb4eta9NsgOmRpmSRcDFTYhrmXySIDbjqsdFhJD+KHrN31RZI3va8HX4 8ZUssc+Jpo52BTptZaP5SpZrLu57wazl9lD+ZVFfL6YNHLBltzClPyQomt3zPUf9bpyW EoWA== X-Gm-Message-State: AFeK/H3imjT3p5GBXxv60MzlkIP9QsPzFcQJmG2GYGhHwSumVooly7HQX9/lzC6N5g2eoGT8Vd/Ai3uLZYZsgw== X-Received: by 10.31.106.198 with SMTP id f189mr7090634vkc.149.1491251640936; Mon, 03 Apr 2017 13:34:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 13:34:00 -0700 (PDT) Received: by 10.159.55.177 with HTTP; Mon, 3 Apr 2017 13:34:00 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 4 Apr 2017 06:34:00 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Dirk Steinberg Cc: 6man WG Content-Type: multipart/alternative; boundary=94eb2c09506a543006054c491485 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:34:10 -0000 --94eb2c09506a543006054c491485 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 31 Mar. 2017 01:34, "Dirk Steinberg" wrote: > Am 29.03.2017 um 22:08 schrieb Mark Smith : > > On 30 March 2017 at 06:58, Mark Smith wrote: >> So having further about this, I have fundamental question that it >> isn't answering. >> >> Why can't IPv6-in-IPv6 encapsulation be used for this? What is missing >> from IPv6 that "requires" that EH insertion is used instead of much >> simpler, off-the-shelf encapsulation/decapsulation? >> >> >> >> For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH is >> needed at all in the "2. Source Domain and Packet Journey" example. >> >> When node 2 realises that the link between itself and 3 has failed, it >> encapsulates the original SA=3D1, DA=3D9 packet in a new IPv6 header >> ("tunnelling" it). The new IPv6 header has an SA=3D2, DA=3D5, and is sen= t >> towards node 4. >> >> Node 4 forwards the packet onto node 5 using conventional destination >> address based IPv6 forwarding. >> >> Node 5 receives the packet, and as it is DA=3D5, decapsulates the inner >> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the standard >> IPv6 forwarding table, resulting in it being forwarded to Node 3, >> which then forwards it to Node 9. All of this is happening using >> conventional IPv6 destination based forwarding. >> >> Encapsulation is solving this problem by effectively creating a >> on-demand virtual link or tunnel between Node 2 and Node 5, getting >> the original packet past the failure point to a point along the >> original packet's forwarding path. Once there, it pops out of the >> virtual link and is sent along its way. I don't think the insertion of >> the EH and DA swapping method could be described the same way or could >> be described as simply. >> >> I think this IP-in-IPv6 encapsulation solution to the above example is >> better because: >> >> - there is no need for an additional header of any type - the path >> information is inherent in the DA of the outer IPv6 header when sent >> to node 5, and in the DA of the inner IPv6 packet (now "the packet") >> when being sent by node 5 to node 9. > > To clarify, what I mean by "no need for an additional header of any > type" is no additional header beyond the IPv6 encapsulation header > i.e. no SRH EH or similar between the outer and inner IPv6 packets. It > is the original IPv6 packet inside a vanilla IPv6 packet with the > outer IPv6 packet=E2=80=99s next header field set to 41. Following this logic of not using =E2=80=9Ean additional header of any type= =E2=80=9C leads to the conclusion that for every entry in an SR policy represented by the SID list of an SRH, you would instead use one more nested IPv6 encapsulation header. In the simple example of section 2 the TI-LFA policy only needs to specify one additional node, namely 5 (9 being the original destination), but conceivably the backup policy could be more complex including 3, 4, 5, or more SIDs. Would you really want to propose that the PLR should impose, say 4 nested IPv6 encapsulation headers at the same time while still claiming this to be simpler and/or more efficient? Let=E2=80=99s face the reality: the cost of adding an IPv6 encapsulation he= ader is fairly high and while doing this once may be acceptable in certain situations doing this N times nested is prohibitive both in terms of the burden on the forwarding hardware and in terms of MTU growth. One more entry in the SID list is just so much more efficient. That is ignoring the complexity and cost of processing introduced at each hop. The current (and decades old) IPv6 forwarding model involves hop-by-hop destination address matching and hop-by-hop link-layer endcap/decap to get the packet to its destination. MPLS too follows this model. Labels aren't inserted into the IPv6 packet, they're added to the outside of it. EH insertion is fundamentally changing this forwarding model, because forwarding devices have to do more complicated processing of EH chain processing to forward IPv6 packets. SR will be a compelling replacement for MPLS if it leverages existing commodity IPv6 methods and hardware. If it requires a fork lift upgrade of all devices in the network, then it's much less attractive compared to MPLS= . This is why in general the recurring argument to just use IPv6 encaps whenever all you really need is one more entry in the SRH SID list is completely missing the point. I haven't gone through all examples to determine what the implications of IPv6-in-IPv6 encapsulation are, and I acknowledge that the per-packet overheard is high. What I have done though is proven that EH insertion is not required or essential to solve the problem presented in the example. That is the claim that is being made in this draft. So please do not make that claim, please do not use giant lists of authors that could not have contributed enough to the document to have earned it, effectively making an appeal to authority, and please look to leverage existing IPv6 processing models and methods to avoid invalidating existing, well known and widely deployed and used IPv6 devices and techniques. The bigger and more different the claim from the norm, the more effort you have to put into proving it. Regards, Mark. /Dirk >> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is >> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now >> nearly 20 years old. >> >> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6 >> devices that support conventional IPv6 forwarding and conventional >> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling"). >> >> - Encapsulation/decapsulation is a simpler, universal and proven >> operation (literally being done every time an IPv6 packet is being >> sent and received over any and all layer 2 links) compared to the DA >> address swapping that occurs at Nodes 2 and Nodes 5 in the described >> method. >> >> More complicated examples would may require more information to be >> carried about the path between the inner and outer IPv6 headers >> (although encapsulation inside encapsulation/tunnelling inside >> tunnelling probably be used at a greater packet overhead host, with >> simpler per-hop processing), however I don't think this example >> demonstrates why EH insertion is required. >> >> >> Regards, >> Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c09506a543006054c491485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 Mar. 2017 01:34, "Dirk Steinberg" <dws@steinbergnet.net> wrote:

> Am 29.03.2017 um 22:08 schrieb Mark Smith <markzzzsmith@gmail.com>:
>
> On 30 March 2017 at 06:58, Mark Smith <markzzzsmith@gmail.com> wrote:
>> So having further about this, I have fundamental question that it<= br> >> isn't answering.
>>
>> Why can't IPv6-in-IPv6 encapsulation be used for this? What is= missing
>> from IPv6 that "requires" that EH insertion is used inst= ead of much
>> simpler, off-the-shelf encapsulation/decapsulation?
>>
>>
>>
>> For example, using IPv6-in-IPv6 encapsulation, I don't think a= n SRH is
>> needed at all in the "2. Source Domain and Packet Journey&quo= t; example.
>>
>> When node 2 realises that the link between itself and 3 has failed= , it
>> encapsulates the original SA=3D1, DA=3D9 packet in a new IPv6 head= er
>> ("tunnelling" it). The new IPv6 header has an SA=3D2, DA= =3D5, and is sent
>> towards node 4.
>>
>> Node 4 forwards the packet onto node 5 using conventional destinat= ion
>> address based IPv6 forwarding.
>>
>> Node 5 receives the packet, and as it is DA=3D5, decapsulates the = inner
>> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the stan= dard
>> IPv6 forwarding table, resulting in it being forwarded to Node 3,<= br> >> which then forwards it to Node 9. All of this is happening using >> conventional IPv6 destination based forwarding.
>>
>> Encapsulation is solving this problem by effectively creating a >> on-demand virtual link or tunnel between Node 2 and Node 5, gettin= g
>> the original packet past the failure point to a point along the >> original packet's forwarding path. Once there, it pops out of = the
>> virtual link and is sent along its way. I don't think the inse= rtion of
>> the EH and DA swapping method could be described the same way or c= ould
>> be described as simply.
>>
>> I think this IP-in-IPv6 encapsulation solution to the above exampl= e is
>> better because:
>>
>> - there is no need for an additional header of any type - the path=
>> information is inherent in the DA of the outer IPv6 header when se= nt
>> to node 5, and in the DA of the inner IPv6 packet (now "the p= acket")
>> when being sent by node 5 to node 9.
>
> To clarify, what I mean by "no need for an additional header of a= ny
> type" is no additional header beyond the IPv6 encapsulation heade= r
> i.e. no SRH EH or similar between the outer and inner IPv6 packets. It=
> is the original IPv6 packet inside a vanilla IPv6 packet with the
> outer IPv6 packet=E2=80=99s next header field set to 41.

Following this logic of not using =E2=80=9Ean additional header of an= y type=E2=80=9C leads to
the conclusion that for every entry in an SR policy represented by the
SID list of an SRH, you would instead use one more nested IPv6
encapsulation header.

In the simple example of section 2 the TI-LFA policy only needs to specify<= br> one additional node, namely 5 (9 being the original destination), but
conceivably the backup policy could be more complex including 3, 4, 5,
or more SIDs. Would you really want to propose that the PLR should
impose, say 4 nested IPv6 encapsulation headers at the same time
while still claiming this to be simpler and/or more efficient?

Let=E2=80=99s face the reality: the cost of adding an IPv6 encapsulation he= ader
is fairly high and while doing this once may be acceptable in certain situa= tions
doing this N times nested is prohibitive both in terms of the burden on the=
forwarding hardware and in terms of MTU growth. One more entry in
the SID list is just so much more efficient.

That is ignoring the comp= lexity and cost of processing introduced at each hop.=C2=A0

The current (and decades old) IPv6 fo= rwarding model involves hop-by-hop destination address matching and hop-by-= hop link-layer endcap/decap to get the packet to its destination.

MPLS too follows this model. Labe= ls aren't inserted into the IPv6 packet, they're added to the outsi= de of it.

EH insertion i= s fundamentally changing this forwarding model, because forwarding devices = have to do more complicated processing of EH chain processing to forward IP= v6 packets.

SR will be a= compelling replacement for MPLS if it leverages existing commodity IPv6 me= thods and hardware. If it requires a fork lift upgrade of all devices in th= e network, then it's much less attractive compared to MPLS.



This is why in general the recurring argument to just use IPv6 encaps
whenever all you really need is one more entry in the SRH SID list
is completely missing the point.

I haven't gone through all exampl= es to determine what the implications of IPv6-in-IPv6 encapsulation are, an= d I acknowledge that the per-packet overheard is high.

What I have done though is proven that EH in= sertion is not required or essential to solve the problem presented in the = example. That is the claim that is being made in this draft.

So please do not make that claim, ple= ase do not use giant lists of authors that could not have contributed enoug= h to the document to have earned it, effectively making an appeal to author= ity, and please look to leverage existing IPv6 processing models and method= s to avoid invalidating existing, well known and widely deployed and used I= Pv6 devices and techniques.

The bigger and more different the claim from the norm, the more effort = you have to put into proving it.

Regards,
Mark.

=

/Dirk

>> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is<= br> >> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now=
>> nearly 20 years old.
>>
>> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6 >> devices that support conventional IPv6 forwarding and conventional=
>> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling&q= uot;).
>>
>> - Encapsulation/decapsulation is a simpler, universal and proven >> operation (literally being done every time an IPv6 packet is being=
>> sent and received over any and all layer 2 links)=C2=A0 compared t= o the DA
>> address swapping that occurs at Nodes 2 and Nodes 5 in the describ= ed
>> method.
>>
>> More complicated examples would may require more information to be=
>> carried about the path between the inner and outer IPv6 headers >> (although encapsulation inside encapsulation/tunnelling inside
>> tunnelling probably be used at a greater packet overhead host, wit= h
>> simpler per-hop processing), however I don't think this exampl= e
>> demonstrates why EH insertion is required.
>>
>>
>> Regards,
>> Mark.
>
> -----------------------------------------------------------= ---------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------



--94eb2c09506a543006054c491485-- From nobody Mon Apr 3 14:41:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD693128C84 for ; Mon, 3 Apr 2017 14:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=google.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 Fm-qkW2_5d_9 for ; Mon, 3 Apr 2017 14:41:15 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 EA1A212878D for ; Mon, 3 Apr 2017 14:41:14 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id g2so130827848pge.3 for ; Mon, 03 Apr 2017 14:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JK0HbLVOg4oxFylHC61+fUTCbZvLKBUAtxDrVY6GMpQ=; b=LekTwJWkulgZNEE+EMUBh+0Qu7tax6GJhN69V1g4KVFrXFELOeySESJh3cdOhwTFnK gWjyLgkGE1G1f4hGs+XikCNKYrmE6IhtmUIrYSQKitwu0P8sIFZ9Ncr2PR0cLnmsYyWh dOT27g66gYT94oKc9utflEVYSdWFfiMiTXhxkmNX9T/PSQqTkr/G3HB/MKF2GhhC+P2c Ji22rNcCT03ifpL4Kyy1NA58Oez0U37EilrIrxsDaVm29tD83V3kRbWwjoyfBMytuBbC j8lkK+aTwMFAHbAgyGbAUdBU6U1c6rroKab8DxtCRC5ESOoeE2+9I9ROCGVBxxZ+ow1N Lkyg== 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=JK0HbLVOg4oxFylHC61+fUTCbZvLKBUAtxDrVY6GMpQ=; b=Ja4KKeyqfkNlQVSHt+qFfsFzLVsTZ435YTKXJdmn+Rx7ZrVW/z0G1/Aph8qauMlELY 5gmVhu1EIUTo9+GRryjyR7DjJSw3smKGkXZ1wmRLF8V55uEPLw2qZjuiAAgtpQhJe00i BjepA2ZWr37G2xrEq26X7qwK45KiK7/p/Y/9scwmd1NJo/lPx4kSu9DcIlN1wvzzXpGC jn9QzfvYo5uIdC7d1MJ8VZK2/xVn3dyovNqqELNt9n8ML2sL0cxXGRMk0nakWnfcgGYZ 9ANgBfwCw4XZg9rKwuy/61ny+l/HaIw6pIIj8bfl2rXjT+eLVc6ewri/66tUP30gBx2e 1vzg== X-Gm-Message-State: AFeK/H1L+84uKtCU4h1V8sRGxYmEtxzg8kLmhUaL5LtOrM7og53/WbzS0soavoC4d8V3AJQa X-Received: by 10.99.120.74 with SMTP id t71mr20156771pgc.184.1491255674259; Mon, 03 Apr 2017 14:41:14 -0700 (PDT) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id 74sm13780765pfn.102.2017.04.03.14.41.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 14:41:13 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4394CADE-0E1D-42BC-8925-25A9200E1556" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 Date: Mon, 3 Apr 2017 14:41:12 -0700 In-Reply-To: <21708.1491238247@obiwan.sandelman.ca> Cc: Erik Kline To: IETF IPv6 Mailing List References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 21:41:17 -0000 --Apple-Mail=_4394CADE-0E1D-42BC-8925-25A9200E1556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 3, 2017, at 09:50, Michael Richardson = wrote: > Michael Richardson wrote: >>> If the client doesn't understand the X flag then it can still = process >>> the PIO according to its existing code. That's all. No conflict with >>> PD, really. >=20 >> So, a client that doesn't understand the X bit will just think it's >> sharing >> the link with other non-existant nodes, and will waste energy. >=20 > I remembered what was bothering me: a client that doesn't understand = the X > bit might be surprised that there is no router on the link with that > prefix. Generally, clients configure default routes via LL = addresses, > so I think that we are okay. The draft makes no mention of it, but section 2.8 of RFC 4291 requires = all routers to recognize the Subnet-Router anycast address for every = subnet prefix it has advertised on the link. One imagines that a router = sending PIO-X subnet prefixes to hosts would be therefore required to = recognize the Subnet-Router anycast address for each one. --james woodyatt > --Apple-Mail=_4394CADE-0E1D-42BC-8925-25A9200E1556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 3, 2017, at 09:50, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Michael Richardson = <mcr+ietf@sandelman.ca> wrote:
If the client doesn't = understand the X flag then it can still process
the PIO = according to its existing code. That's all. No conflict with
PD, really.

So, a client that = doesn't understand the X bit will just think it's
sharingthe link with other non-existant nodes, and will waste = energy.

I remembered what was = bothering me:  a client that doesn't understand the X
bit might be surprised that there is no router on the link = with that
prefix.    Generally, clients = configure default routes via LL addresses,
so I think that = we are okay.

The draft makes no mention of it, but section 2.8 = of RFC 4291 requires all routers to recognize the Subnet-Router anycast = address for every subnet prefix it has advertised on the link. One = imagines that a router sending PIO-X subnet prefixes to hosts would be = therefore required to recognize the Subnet-Router anycast address for = each one.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_4394CADE-0E1D-42BC-8925-25A9200E1556-- From nobody Mon Apr 3 15:48:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10547129450 for ; Mon, 3 Apr 2017 15:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=umn.edu 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 gvd9jrJIiIDW for ; Mon, 3 Apr 2017 15:48:07 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8B912714F for ; Mon, 3 Apr 2017 15:48:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 80B8E9C3 for ; Mon, 3 Apr 2017 22:48:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fMc2yp_RL8x for ; Mon, 3 Apr 2017 17:48:06 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 5375E9CB for ; Mon, 3 Apr 2017 17:48:06 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id d188so55982271vka.2 for ; Mon, 03 Apr 2017 15:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=6eGqYe8BFtq7blfRjlaE6NRWvK0DJ0K0PRvtJzUqWtY=; b=XOksb+iEhSJzkL5cHX578PD2Yhy51LdWM50Xx1RrukFQtYWsu1J8YoiAiLERqnf90l kNs8ySLnOOABTRWXDSif0xZVxy0S+cm+q4lo0id1rbNlRZueOfbH1C4ZwhQ6Qjn4H6uG zfdx75jzZJQ5eOLJg8sQcZTmBGdx8peEqTCgdy7rmIoAFqjS6DB4S6t8SOZj2wDigMJK X6rbDLlFEQxG4PkKxz6xjeYtCcJug8NLnIZN15t4ZJdKWwpIZcKzQ4oPafHvSSESzyZ1 ZuCTEKxcS2xnzt6Zk3nZqDpoDL+oL29eZoxFnWqINUJUrcpSk0J0v8eNDMf7McFr5ZIu nkfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6eGqYe8BFtq7blfRjlaE6NRWvK0DJ0K0PRvtJzUqWtY=; b=EqGN7T/ZVOsnz0zZijA+3W8EjNF+j9WTM9mAxLtUVuPCNt4f9Wyp2VnkmqGJ2SJu59 0wckV2DZZTXnL1JN3fmGGl4Vt+LrCQZMOAd+lpfBECmDk9qW9VDKpt+qVu9Qy2D7NO6s ByXHRX6z5n5R5RQ4KApus7tJuq2hhDVs1vC3F68q9jWcynvh+r8unx34YB4Ce0kFMgDe USF5QWPsOM4MjbhlD9EP2RT42Ki53IWa2HibhMwrbyRnF6Gg6o9x7Jg1ALRZ1VtWfLXZ ysk25t8VIx9zFAaagWuzaDK5pL7wG908yY8mhzJYamdJMBh8Y6CNtmgmL7aak07OuhE9 Sy8Q== X-Gm-Message-State: AFeK/H2kiuDP1Hi0Fm1FUyQ1ozsNDvk16a/yZrHrlRJcqczJTxICh4G3MFHdGddrlU1OHA2tLZDnLSzE5UZlcr8GnrVGNOEwMTSxmuZmtaFejgzJMbn8UQA3wtPPbkH4ajQnNe4KaQf5Q3Iy8bw= X-Received: by 10.31.169.17 with SMTP id s17mr8982193vke.31.1491259685741; Mon, 03 Apr 2017 15:48:05 -0700 (PDT) X-Received: by 10.31.169.17 with SMTP id s17mr8982180vke.31.1491259685490; Mon, 03 Apr 2017 15:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.144.27 with HTTP; Mon, 3 Apr 2017 15:48:05 -0700 (PDT) From: David Farmer Date: Mon, 3 Apr 2017 17:48:05 -0500 Message-ID: Subject: RFC4890 status was: RE: To: Bob Hinden Cc: Tim Chown , IPv6 List Content-Type: multipart/alternative; boundary=001a114260b6d26b2a054c4af36d Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 22:48:09 -0000 --001a114260b6d26b2a054c4af36d Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 2:54 PM, Bob Hinden wrote: > > > On Apr 3, 2017, at 4:20 AM, Tim Chown wrote: > > >> On 31 Mar 2017, at 16:32, Bob Hinden wrote: > ... > >> o Added new text in Section 6 to clarify the effect of > >> ICMPv6 filtering on PMTUD. > > > > Perhaps reference RFC4890 here? > > Thanks. I think that makes sense. > I had a similar thought, but Tim beat me to it. However when reviewing RFC4890, I noticed that it's status is only Informational. At this point can anyone tell we why we shouldn't consider advancing RFC4890 to BCP? Personally, I was a little shocked it was only Informational. I'm not sure advancing it will really fix anything, but I don't see what it could hurt, maybe more people would take it more seriously. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a114260b6d26b2a054c4af36d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Apr 3, 2017 at 2:54 PM, Bob Hinden <bob.hinden@gmail.com>= ; wrote:

> On Apr 3, 2017, at 4:20 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

>> On 31 Mar 2017, at 16:32, Bob Hinden <bob.hinden@gmail.com> wrote:
...
>>=C2=A0 o=C2=A0 Added new text in Section 6 to clarify the effect of=
>>=C2=A0 =C2=A0 =C2=A0ICMPv6 filtering on PMTUD.
>
> Perhaps reference RFC4890 here?

Thanks.=C2=A0 I think that makes sense.

I had a s= imilar thought, but Tim beat me to it. =C2=A0

However when reviewing RFC4890, I n= oticed that it's status is only Informational. At this point can anyone= tell we why we shouldn't consider advancing RFC4890 to BCP?=C2=A0

Personally= , I was a little shocked it was only Informational.=C2=A0 I'm not sure = advancing it will really fix anything, but I don't see what it could hu= rt, maybe more people would take it more seriously.

Thanks.

--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--001a114260b6d26b2a054c4af36d-- From nobody Mon Apr 3 16:05:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD74129455 for ; Mon, 3 Apr 2017 16:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 r12YrdxC3Iz8 for ; Mon, 3 Apr 2017 16:04:57 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 32624124D6C for ; Mon, 3 Apr 2017 16:04:57 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id f103so13576770ioi.2 for ; Mon, 03 Apr 2017 16:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XGszZ9S4w+a5CRlIri++wBFbv8PaI64n01daEy1+Pks=; b=qmMJm+Y4iVkLbVpNRz28Apf881arO21GGkRYDg6HDBV+LbFpF3TKCcbuL7yF2BHBbr nY+66LMJPPrlGWqN5PdRIPlcFEQu46kJdCvDdFgcOoN8kElcXFz6eyfgf7VOoy3c/RYS SoqeG9n5dR5oM+Qir1HJy/39BJu0VDP0kvrPsXNvbN6MjawxBUZk903YqQD4wagSUnAr sgudXiwYSbgBgTPCLDPsF0VR74kqiD3ykZm1HEHNkUEfIDMvbly8R4Zx/W8+Aj6iTVWD rOnmeWCkSXu7iJcq1rrq/lNTts3FZJ5ZYfrsh2omSQBW+/OUf4QA1HTdJtLb9yVHx2lK FSyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XGszZ9S4w+a5CRlIri++wBFbv8PaI64n01daEy1+Pks=; b=Wq6fOgZ32JaT9EwwNWtmSb3nhAggBVfopK6QhhW6BtT+xrGWXTgs9mfstjjw7sliaS nEjxNw8UCokimqo2NMp4GVBHS3Awfg1KtVG/D5uS3F5PU+m1UpMkEKjGfLYVBqPGlKfX mh5cLXqPVNnOpVWplL45MtuwOKy1kaz0BqysokAWLN6MtqXPxc7E1w9RcDNIyjZ6Opq/ wVoIkqTFK6tSRtKvXNhZYVkLwPpr2uQaajr1B/hScch9DQT55JvVS4emdV49rL6wGTlf opKgl5foRaJNmFnSRSuSGSJzPTWoVzWElVw5oA+sLg/o8DrswgLdJ3s7aOpqjX4Vohan Ucjg== X-Gm-Message-State: AFeK/H3fyRd8NJvIji3iZj5fjTStfp+0VxK6EPv91Tkpvhm9/vEzyoFJVBFR1h8+63dcJw== X-Received: by 10.107.185.135 with SMTP id j129mr17963459iof.3.1491260696430; Mon, 03 Apr 2017 16:04:56 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id w188sm6435473itc.6.2017.04.03.16.04.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Apr 2017 16:04:55 -0700 (PDT) Subject: Re: RFC4890 status was: RE: To: David Farmer , 6man References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 4 Apr 2017 11:04:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 23:04:59 -0000 On 04/04/2017 10:48, David Farmer wrote: > On Mon, Apr 3, 2017 at 2:54 PM, Bob Hinden wrote: > >> >>> On Apr 3, 2017, at 4:20 AM, Tim Chown wrote: >> >>>> On 31 Mar 2017, at 16:32, Bob Hinden wrote: >> ... >>>> o Added new text in Section 6 to clarify the effect of >>>> ICMPv6 filtering on PMTUD. >>> >>> Perhaps reference RFC4890 here? >> >> Thanks. I think that makes sense. >> > > I had a similar thought, but Tim beat me to it. > > However when reviewing RFC4890, I noticed that it's status is only > Informational. At this point can anyone tell we why we shouldn't consider > advancing RFC4890 to BCP? > > Personally, I was a little shocked it was only Informational. I'm not sure > advancing it will really fix anything, but I don't see what it could hurt, > maybe more people would take it more seriously. I think that needs to be considered along with https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6 which is also Informational so far, and cites RFC 4890. In any case it's an Ops Area thing. Brian From nobody Mon Apr 3 18:53:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7012953B for ; Mon, 3 Apr 2017 18:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b0V6k4mK_21q for ; Mon, 3 Apr 2017 18:53:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED1B12953A for ; Mon, 3 Apr 2017 18:53:36 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.33.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 951E480ABA; Tue, 4 Apr 2017 03:53:33 +0200 (CEST) Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Tim Chown , Jan Zorz - Go6 References: <20170331155211.7C444B81110@rfc-editor.org> <8C64BAFE-D014-40F3-A3B6-956F937B4BB7@jisc.ac.uk> <55236100-3099-4B1C-AE58-FC6DC3B571CE@jisc.ac.uk> Cc: "ipv6@ietf.org" , Bob Hinden , Suresh Krishnan , "julianedprado@gmail.com" , "kawamucho@mesh.ad.jp" , RFC Errata System , Terry Manderson From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <9e650c5e-2786-32f8-700c-6c134f961902@si6networks.com> Date: Tue, 4 Apr 2017 01:05:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <55236100-3099-4B1C-AE58-FC6DC3B571CE@jisc.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:53:39 -0000 On 04/02/2017 01:30 AM, Tim Chown wrote: > Hi again (hit send too soon!), > >> On 2 Apr 2017, at 00:26, Tim Chown wrote: >> >> Hi Jan, >> >>> On 31 Mar 2017, at 17:07, Jan Zorz - Go6 wrote: >>> >>> On 31/03/2017 17:52, RFC Errata System wrote: >>>> Original Text >>>> ------------- >>>> 'A special syntax is available to compress the zeros. The use of >>>> "::" indicates one or more groups of 16 bits of zeros.' >>>> >>>> >>>> Corrected Text >>>> -------------- >>>> 'A special syntax is available to compress the zeros. The use of >>>> "::" indicates two or more groups of 16 bits of zeros.' >>>> >>>> >>>> >>>> Notes >>>> ----- >>>> "indicates one" should be written as "indicates two" >>>> >>>> for example: >>>> 'A special syntax is available to compress the zeros. The use of >>>> "::" indicates two or more groups of 16 bits of zeros.' >>>> >>>> 2001:db8:aaaa:bbbb:cccc::1 >>>> >>>> 2001:db8:aaaa:bbbb:cccc:0:0:1 >>> >>> Hi, >>> >>> I don't agree with errata entirely. >>> >>> 2001:db8:aaaa:bbbb:cccc:dddd::1 expands to 2001:db8:aaaa:bbbb:cccc:dddd:0:1 >>> >>> So it's one or more groups of 16 bits of zeros. >> >> Note you cannot reduce just one group of zeroes with ::, so the above example of 2001:db8:aaaa:bbbb:cccc:dddd::1 must be written 2001:db8:aaaa:bbbb:cccc:dddd:0:1 (see 4.2.2 of RFC5952). > > So this might be the point the filer of the erratum is making, when referring to the recommendation of section 4 as a whole? I'd assume so. FWIW, while (recently) reading RFC5952, the section you referred to somehow came as a "surprise" to me. I guess that if rfc4291bis is still pursued, this should be incorporated into it such the the bis RFC does not contradict with RFC5952? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 3 18:53:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC61294DC for ; Mon, 3 Apr 2017 18:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Jhp5yVFHf9Rq for ; Mon, 3 Apr 2017 18:53:39 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15FC12953A for ; Mon, 3 Apr 2017 18:53:38 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.33.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 17ECC8012F; Tue, 4 Apr 2017 03:53:36 +0200 (CEST) Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Doug Barton , Tim Chown References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: "ipv6@ietf.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 4 Apr 2017 01:12:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:53:41 -0000 On 04/03/2017 12:09 AM, Doug Barton wrote: [....] >> >> So should Section 4.2.2 stand, on not shortening one 16-bit field of >> zeros? >> https://tools.ietf.org/html/rfc5952#section-4.2.2 > > I wasn't involved in the 5952 discussion, so it would be hard for me to > comment. On principle though I would say no, because ... > >> The rationale for that section given in earlier versions of the draft up >> until -04 says ""::" should not be used to shorten just one 16 bit 0 >> field for it would tend to mislead that there are more than one 16 bit >> field that is shortened”, which seems a bit weak, and at odds with >> RFC4291 as above? >> https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04#section-4.2.2 >> > > ... I find it sad that A) people could think that this is a problem, and > B) that people who are confused about how many 16 bit fields make up an > IPv6 address could possibly get more confused by how many fields are > being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? > Seriously?) I agree with you on this one. That said, RFC5952 did update RFC4291. > So if updating 4.2.2 of 5952 will make things more clear for people, it > should probably be done. RFC5952 updated RFC4291 in this respect. Having another document update RFC5952 on this respect would be a kind of spaghetti kind of hard to parse. At this point, and given the recent discussion regarding rfc4291bis, I'm wondering if it might make sense to publish rfc4291bis such that lots of things get cleared up, and move/postpone the "rfc4291bis to IS" to a later stage? (me thinking out loud) Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 3 18:53:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8EA12953F for ; Mon, 3 Apr 2017 18:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 eH19Hul2ak_9 for ; Mon, 3 Apr 2017 18:53:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A72612953B for ; Mon, 3 Apr 2017 18:53:41 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.37.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 889BF80A75; Tue, 4 Apr 2017 03:53:38 +0200 (CEST) Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Mikael Abrahamsson , Jan Zorz - Go6 References: <20170331155211.7C444B81110@rfc-editor.org> <69cb6347-3644-c342-aec0-42d2ef32cd8f@dougbarton.us> <6196E2F1-CC14-4FA3-81B6-E83B0F09B278@jisc.ac.uk> Cc: "ipv6@ietf.org" From: Fernando Gont Message-ID: Date: Tue, 4 Apr 2017 01:13:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 01:53:44 -0000 On 04/03/2017 08:00 AM, Mikael Abrahamsson wrote: > On Mon, 3 Apr 2017, Jan Zorz - Go6 wrote: > >> On 03/04/2017 00:09, Doug Barton wrote: >>> ... I find it sad that A) people could think that this is a problem, and >>> B) that people who are confused about how many 16 bit fields make up an >>> IPv6 address could possibly get more confused by how many fields are >>> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous? >>> Seriously?) >> >> In real world - compression and decompression of just 16 bits between >> the :: simply works. > > Saying that 1:2:3:4:5:6::8 is invalid fails the "rule of least > astonishment" test. > > $ ping6 1:2:3:4:5:6::8 > PING 1:2:3:4:5:6::8(1:2:3:4:5:6:0:8) 56 data bytes > > Agreed that this just works, and I don't understand why we would have > text that says it's not allowed? +1 As noted, this was a surprise for me as well, when recently reading RFC5952. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 3 19:01:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE512953B; Mon, 3 Apr 2017 19:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jMLhRh2XBAzp; Mon, 3 Apr 2017 19:01:46 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF4D129536; Mon, 3 Apr 2017 19:01:45 -0700 (PDT) Received: from [10.0.0.194] (unknown [80.12.33.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ECEE180ACC; Tue, 4 Apr 2017 03:53:40 +0200 (CEST) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Robert Raszuk , Brian E Carpenter References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> Cc: "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" From: Fernando Gont Message-ID: <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> Date: Tue, 4 Apr 2017 01:15:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 02:01:47 -0000 On 03/31/2017 04:11 PM, Robert Raszuk wrote: > I do not understand how 2460bis makes it "easier" if proposed change to > the text directly tries to prohibit what is described in a document > already long time back accepted as a 6man working group draft. This is incorrect. For instance, the condition to accepting such I-D as a wg items was indeed that EH insertion was removed, and that encapsulation be used instead. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 3 23:12:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723F9129522; Mon, 3 Apr 2017 23:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HBWRWAHKTm5y; Mon, 3 Apr 2017 23:12:05 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 CAC4D1274D2; Mon, 3 Apr 2017 23:12:03 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id a140so23150995ita.0; Mon, 03 Apr 2017 23:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=A04AZGXnc0nwdH7Q/VkrNepyLWytWL9haOmEDxsjpN4=; b=DZEmx8DoGINV3IYZaGhVsB0UFw6L0cgjiQXanqx9paUbxoV41V5AigYSVPrgvt4HYI 8WyWSAxLsQ541uiHYgQd7eyrKFmFHAOfypBwXyCo6XHsI4IMOYYb20snoJEb/DWcRAig HTsDv4qfwahvM0fOslnT7owxklxItifqEIgPTcCm8TyAKir5yLAmcNPB+LSAp1QZj43O S3hN5hY/oUO69HxvOztHraRj8dIxJnAUqGmGVUWEitvECMU3fyoEeYHiP86JbA0ivM5U 7NjJpEdeSwYMXGclSQzup+ITS4iM21xjSvJOYGiS86luqe9zMK02gRRn4/BNU5sDy69s oIUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=A04AZGXnc0nwdH7Q/VkrNepyLWytWL9haOmEDxsjpN4=; b=f+KRRkvmZSUhePihZTfkl022iWABdQ1rtGKzw6gWH/MRqI4X/iNKG0VqNTWko0E/j+ 1ChtwPGnocz5lHRUbq1riCko97QEzp0SFWqp54yoRpAIEiyN3cqndMM0p3Vdm/Fet90X eAQn799d/E20plZuURbDObyBGWEAmpoBlyCx12tjLPs8tyyNH+n3mLsrhHVPkO8gtDzB 7cDjqD7YxKr8+bjz0cnxdoS2VlvftH/tMdvXPHGck67GYESuMWm6U70llUhJFUbyHXlF rwyWG1a3Ov1HvxZ7Un89DEiHuq4+OjFf4uR7UKxp6yNkKlZ1OXBbxwTNAV7aN7BkCISW jtIA== X-Gm-Message-State: AFeK/H0wX0bgPx/kQQ9iJ2s/perF8tVFYS0vN3U9pmK3ixvRmLss7aH/o6N22teCQxn/5/SS1WEUP97ChkCgJw== X-Received: by 10.36.115.12 with SMTP id y12mr8041129itb.24.1491286323043; Mon, 03 Apr 2017 23:12:03 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Mon, 3 Apr 2017 23:12:02 -0700 (PDT) In-Reply-To: <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> From: Robert Raszuk Date: Tue, 4 Apr 2017 08:12:02 +0200 X-Google-Sender-Auth: C20EmhPWFEbnqTVcvAnYj28zJK4 Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Fernando Gont Cc: Brian E Carpenter , "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" Content-Type: multipart/alternative; boundary=001a11444dca8b2c72054c512764 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 06:12:07 -0000 --001a11444dca8b2c72054c512764 Content-Type: text/plain; charset=UTF-8 Hi Fernando, The WG document talks about two cases ... * EH insertion at the host (src of packet) * IPv6 new encapsulation + EH insertion on the ingress to SR domain followed by decapsulation at the egress of SR domain. I hope we can agree on that. However is it wise to expect any time within SR domain for a packet (v6 encapsulated on ingress) to get steered differently (say coming out of service chain) to decapsulate and encapsulate again ? Seems to me like quite local box decision anyway. Hence my comment about implicit insertion. In any case if we see this entire thread the only technical concern with EH insertion was MTU. And how that issue is solved when you do additional IPv6 header encap ? Or maybe encap is allowed simply as it can not be forbidden :)) Cheers, Robert. On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont wrote: > On 03/31/2017 04:11 PM, Robert Raszuk wrote: > > I do not understand how 2460bis makes it "easier" if proposed change to > > the text directly tries to prohibit what is described in a document > > already long time back accepted as a 6man working group draft. > > This is incorrect. For instance, the condition to accepting such I-D as > a wg items was indeed that EH insertion was removed, and that > encapsulation be used instead. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a11444dca8b2c72054c512764 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fernando,
The WG document talks about two cases ...=C2=A0<= /div>

* EH insertion at the = host (src of packet)=C2=A0

* IPv6 new encapsulation + EH insertion on the ingress to SR domain fo= llowed by decapsulation at the egress of SR domain.

I hope we can agree on that.=C2=A0

However is it wise to expect any= time within SR domain for a packet (v6 encapsulated on ingress) to get ste= ered differently (say coming out of service chain) to decapsulate and encap= sulate again ? Seems to me like quite local box decision anyway.=C2=A0

Hence my comment about imp= licit insertion.

In an= y case if we see this entire thread the only technical concern with EH inse= rtion was MTU. And how that issue is solved when you do additional IPv6 hea= der encap ?=C2=A0

Or m= aybe encap is allowed simply as it can not be forbidden :))

Cheers,
Robert.


On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont <fgont@si6networks.= com> wrote:
On 03/31/2017 04:11 PM, Robert Raszuk wrote:
> I do not understand how 2460bis makes it "easier" if propose= d change to
> the text directly tries to prohibit what is described in a document > already long time back accepted as a 6man working group draft.

This is incorrect. For instance, the condition to accepting such I-D= as
a wg items was indeed that EH insertion was removed, and that
encapsulation be used instead.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a11444dca8b2c72054c512764-- From nobody Mon Apr 3 23:42:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6C3129566 for ; Mon, 3 Apr 2017 23:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EnpVZkXK9M2g for ; Mon, 3 Apr 2017 23:42:03 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 9363F120727 for ; Mon, 3 Apr 2017 23:42:03 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id l7so89468196ioe.3 for ; Mon, 03 Apr 2017 23:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+8hntoQs7fCdouNb45rnj2qA05wd/LHIaJeBIPbq/Xk=; b=cENo8KQWAq9oCvXqdGJ2zSqiH7FH2UP2K43exq6KaP4ZjrausGjrrgaPPQmKeIefAb +xlSTMzdoDjU0PQuKJh5Nan5J55K6zn326jLpyYwxMkx4k8xcCQzO3ti2VOGXsDgwp0M fgij2ZmPV0eU+m1kkxvVdjtNffn6wHYwrD4dy7y0quYgxJpufkhAHI2gKMPKsnbdS++E ML6rmA7Tdr8x1o0uhdrkSbuuAp/ThPiAxUPqJnhaLQTlaBp0bFLc+rSBLubhM8V9xI1r LwZxRR3r6BYQi3Uq/Y3bOL5AS+MmmAYXYW0bQszKDRe6RCpw3BFr2P+pAFUdiGPmOy7/ DyCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+8hntoQs7fCdouNb45rnj2qA05wd/LHIaJeBIPbq/Xk=; b=i/OqSz6VrKeLRFrkMFz4mMtHT6BwRBPsynl2TFJlJllxvup26Ha63Gqk1IA7lFkagv BNuT65kFyErxseueLqqJI3xdAw3799lIGhJhLssoEQCkkTzg3e5souhs7m2f0dBMBiTT uB/2CXFqXrv9V3YJNQiZoFu+pwIdfjAT4a/0ZsLjO0+QN5Kh0BZivt05JRIn/feHkbOx y8ofItJOgwOpf9ja2+v7nz+6jaVfu0hVMDQH8zuR17bnk5pfQIKObHa/XX3Ot5wuPvD2 JqSh8Wwiz+PBFJOf6pA45buG1QqStMsMfMwxHwyJFtFGUlQvrHdWhmrrczZs4gfTFH+b qNiQ== X-Gm-Message-State: AFeK/H3WfoQYCia4OhiNckGPVZiX24r+KyR2cRCYzEU/kJv5h/A1bEK19cl0K86eIFGomk0IIJdAJi1j92wqTw== X-Received: by 10.107.10.21 with SMTP id u21mr22326646ioi.139.1491288122914; Mon, 03 Apr 2017 23:42:02 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Mon, 3 Apr 2017 23:42:02 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Tue, 4 Apr 2017 08:42:02 +0200 X-Google-Sender-Auth: 07CucREArtzEVvPxTWvIxgmRxDw Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Mark Smith Cc: Dirk Steinberg , 6man WG Content-Type: multipart/alternative; boundary=001a113ed766d3264e054c5192fb Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 06:42:05 -0000 --001a113ed766d3264e054c5192fb Content-Type: text/plain; charset=UTF-8 Hi Mark, > EH insertion is fundamentally changing this forwarding model, because forwarding devices > have to do more complicated processing of EH chain processing to forward IPv6 packets. Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents as long as src hosts do it ? If so how does it change your above assertion on the "complicated processing of EH chain" ? So if hosts do it - it is all great, but if network element dares to do it - it is now just a disaster ? Are all IPv6 implementations implicitly assume that src host will be too stupid to ever do header insertion ;) ? Well surprise ... linux kernel 4.10 can do it. Best, Robert. --001a113ed766d3264e054c5192fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mark,

&= gt; EH insertion is fundamentally changing this forwarding model, because f= orwarding devices=C2=A0
> have to do more complicated = processing of EH chain processing to forward IPv6 packets.
=

Oh really ? Isn't EH in= sertion explicitly allowed by *all* IPv6 documents as long as src hosts do = it ?

If so how does = it change your above assertion on the "complicated processing of EH ch= ain" ?=C2=A0

So i= f hosts do it - it is all great, but if network element dares to do it - it= is now just a disaster ?

Are all IPv6 implementations implicitly assume that src host will be to= o stupid to ever do header insertion ;) ?=C2=A0
Wel= l surprise ... linux kernel 4.10 can do it.=C2=A0
<= br>
Best,
Robert.=C2=A0

--001a113ed766d3264e054c5192fb-- From nobody Tue Apr 4 00:30:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DBC12949A for ; Tue, 4 Apr 2017 00:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UArThkmsBBg7 for ; Tue, 4 Apr 2017 00:29:55 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 73CB312420B for ; Tue, 4 Apr 2017 00:29:55 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id s68so165304987vke.3 for ; Tue, 04 Apr 2017 00:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=893u3+39CUhbyfsKDVw+LNb6WK4fI4/Am6DrUoLmbJ4=; b=i7+RlI6OTd7bouYEs3nfaWE1La2uu6JTT5G8XM6FU7cIQjqsadPSGqGh/aNZFbo8kG /6huX2lQJUecYdGXZTaN7W+ydcJ3E+IKk9bWxpxL/ezseD3EIGE2wFJLqypl2SiGWswD PnoJkxCYxpvOljaBxHMXWEu5DjUliHgzOTR3VnIn6kguIS64qeJNVuJOYEuboFSMRp4V qXrjuAUoKWM79jQKGw630Hrqeq3ixR99phXHCSofcCOOHOGmmqVS+1PCTX8TAWQpY2Bh iJykti3TUtrv3NwVxwtqX6SRrqsPrULNLVS5ZUceJNgu2D/PeGn5HDECmCB/b5AOfPzl pOOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=893u3+39CUhbyfsKDVw+LNb6WK4fI4/Am6DrUoLmbJ4=; b=KsYt2BRkgAQMcbb8tn0PknUj2ONmYfaEgJnSaOWmhjv7g5T8VlIntaUb5KrKQY0UF9 1bSpuyDiRYbCn+1us0vwmAZ8pM1Rn6djMdaSRZ07iQRdRMBw+o7T9twaNvELJLxCQSRb MQ/100D0S8xLjBsojedDYHYFp52tBE6Js4oFQgJaSciAWkSExL/wpXKQtei95nI516kc DQuVBBVF1Jp7CYy3l4Ib/w7YaRyQ09NyBDBlvhmuYwFXOvPZbuymDX3TbqpP4N0yzMoM aduL39dm6rJUf1FSYTFZd9oD1B/shJGHMy2uRRyArhC/KcSKnuP9r0SHC9Q7cuYha6hP g+gA== X-Gm-Message-State: AFeK/H2gqyoADR3VxOGk8Z/QvpB/0sY6ZprUnqMnRdE5dnGw6Ti4yOnIZBw76XD6DbQg0ub9ChUbIvXL+B1hFA== X-Received: by 10.159.49.87 with SMTP id n23mr10760819uab.157.1491290994419; Tue, 04 Apr 2017 00:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 00:29:24 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 4 Apr 2017 17:29:24 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Robert Raszuk Cc: Dirk Steinberg , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 07:29:59 -0000 If you think fiddling with packet structure and size in the network is perfectly fine, then I wonder if you've had any operational experience with troubleshooing NAT, implementation bugs or devices that partially failure such that they partially corrupt packets. I don't appreciate the condescending sarcasm either. On 4 April 2017 at 16:42, Robert Raszuk wrote: > Hi Mark, > >> EH insertion is fundamentally changing this forwarding model, because >> forwarding devices >> have to do more complicated processing of EH chain processing to forward >> IPv6 packets. > > Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents as > long as src hosts do it ? > > If so how does it change your above assertion on the "complicated processing > of EH chain" ? > > So if hosts do it - it is all great, but if network element dares to do it - > it is now just a disaster ? > > Are all IPv6 implementations implicitly assume that src host will be too > stupid to ever do header insertion ;) ? > Well surprise ... linux kernel 4.10 can do it. > > Best, > Robert. > From nobody Tue Apr 4 00:45:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0313A129405 for ; Tue, 4 Apr 2017 00:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 j-gWxrRfWxkT for ; Tue, 4 Apr 2017 00:45:28 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 B3AB4129571 for ; Tue, 4 Apr 2017 00:45:25 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id s68so165657117vke.3 for ; Tue, 04 Apr 2017 00:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cgytCGJSOETBjjbaXWjFfc8UsOv+GrI/Lm2s16W+dy0=; b=ONVSlXzeyDgL+gHI5JG5rG5V8Ty00chGgCloapWjT7ng4uu+4vGtZT+3krxej7uXL8 mCDxRZfEi1np/ewrf+xe3AUWvECmSXJMEx2JhNNxUcF594dht0L4gjs1GzR6uyyS3Cl/ Fq8nBq2RVM7SKV1dJXxMdt9tyorIlaoy9N2XXtuqhpVgf1PyQisH+xIzXOBw5lS0BAuN o+eZnTs8HwUo35pt/+f8OLN9GJf2kklpwUBU+leziBL02we1AJX09uUTGeuYRf0r84MF FK5CUH8xXbBSCApwkwq/EFg0dEueDw+yDOE3m1ovIawM00LzYBwUqiRK0cQj834cJH+V 5CDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cgytCGJSOETBjjbaXWjFfc8UsOv+GrI/Lm2s16W+dy0=; b=Vo0Rc/5I6nSGruEAylME8er4GE/DF+Dwa4LjBH3qhIFZP5BQjg3umtimDWMvu3tcUk 7xqJWur4tFaK4tHaAEx3D7GCUq9e5h4b8usoR0MS40Te0qkzjLaSGylSELBvzeOMnUph V5z+AueNx8uBRY6Uwhvo4zUEDEiaZ1mgUv0CAjQhVk2i4eHDlU8g1uAdjgRE9aQlFeeJ xH2tiyS5DJqS6g9H/iK5TvHcycnPopjO2mDZs6GbFNleiMAOLsCUECvYchD/31kpPvsq YFQaPjENJ5aV6886AyUEuKrmihnVdZGBg1LVnO43zR5nqojtP0fVS5dc+Whes5IzjWW0 Iz2Q== X-Gm-Message-State: AFeK/H0/DYdzox3cDEayWA06+B0ng3ggrv8ZEMwVL5/Jh+lNd34/grPG4NZX3Dz30wstZlRZ7o+qNRuk6qomAQ== X-Received: by 10.176.83.124 with SMTP id y57mr9490501uay.141.1491291924758; Tue, 04 Apr 2017 00:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 00:44:54 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Tue, 4 Apr 2017 17:44:54 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Robert Raszuk Cc: Dirk Steinberg , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 07:45:30 -0000 On 4 April 2017 at 17:29, Mark Smith wrote: > If you think fiddling with packet structure and size in the network is > perfectly fine, then I wonder if you've had any operational experience > with troubleshooing NAT, implementation bugs or devices that partially > failure such that they partially corrupt packets. > You may also want to read RFC7045, " Transmission and Processing of IPv6 Extension Headers", which says, among other related things, "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour." > I don't appreciate the condescending sarcasm either. > > > On 4 April 2017 at 16:42, Robert Raszuk wrote: >> Hi Mark, >> >>> EH insertion is fundamentally changing this forwarding model, because >>> forwarding devices >>> have to do more complicated processing of EH chain processing to forward >>> IPv6 packets. >> >> Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents as >> long as src hosts do it ? >> >> If so how does it change your above assertion on the "complicated processing >> of EH chain" ? >> >> So if hosts do it - it is all great, but if network element dares to do it - >> it is now just a disaster ? >> >> Are all IPv6 implementations implicitly assume that src host will be too >> stupid to ever do header insertion ;) ? >> Well surprise ... linux kernel 4.10 can do it. >> >> Best, >> Robert. >> From nobody Tue Apr 4 01:38:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED11129577 for ; Tue, 4 Apr 2017 01:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 VUgQ_yvtLwjs for ; Tue, 4 Apr 2017 01:38:17 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 F07A2129573 for ; Tue, 4 Apr 2017 01:38:13 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id 81so145981934pgh.2 for ; Tue, 04 Apr 2017 01:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HPAqyBhPhyTLUdW89IH9F2TztwiVAfu0+5WML3qf9ww=; b=Cg+AG7V3plZ1CGBgasXCIBbxI2Ce7yqv2Vy5JEKG05N4Jrm3Ekr5AXGTcB4ENKLOZl omsQFXjMLKxUSdT7cSQsW8Wogk62+0gsmyl/TaIojwr/AFkyENYOTHgl/ZVNp7Jj3JxS pQV+FNcDHwfC/PuWFZ8VLSNaijOXYbFvj23kVylNEunbyAVHTUJ9yAAe2uJG75IU9Ru6 8+yfJ4wAaEPEt2T0FxM+FI1SaXsaSmPb4Va0tOLlj1eWGnUvHHIZzAfXWP/ziroywVwL 12gz9xyR00bgGJmp9nOsuJZxRA4SIny8kOlkTEnm5OhRgaJhRUpBJaOJ/1htrOz5j87Y Z3Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HPAqyBhPhyTLUdW89IH9F2TztwiVAfu0+5WML3qf9ww=; b=fyb0AYAg/X2FKXOTeTnzXlBfPxr8VlRuMTURevpTS8RLEa3hyf/FriXsPT+i62USkS LzCpqhUqnbxPnqCQwU5fpoTj+QKK+RV82OlgSdVJLLRapMCDYnc58vcCKRfHSt1tTCDY sQUh7ZYuhQEldFzZZNEI+CJjcY7B8iqBiPQVuHKqcFUDUdwelOBFQ337XtcAdmw1aGgG 5GEtX5jrM8YAM8PPzhxTrfs6elpTfyZpIYOjK+0O982c2HXTPd3wOl5466lHVU2VmP54 dWXB73vgUXF3iQAzX4Qw0sNijTk5w+JG0mvLAK2N3/HIOz1awlUd6On7TUwAmlJUIRdj 7nJg== X-Gm-Message-State: AFeK/H2TGO7uahZ0hEBrXaYOTSu2Cu3pEC86pvJTutuPXzhkc9KpN2b+754fE6bYsXuIKQ== X-Received: by 10.98.192.217 with SMTP id g86mr21796708pfk.170.1491295093529; Tue, 04 Apr 2017 01:38:13 -0700 (PDT) Received: from [10.207.113.167] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id l76sm30199494pfj.94.2017.04.04.01.38.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 01:38:12 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: Date: Tue, 4 Apr 2017 17:38:10 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 08:38:19 -0000 Hello Mark, Thank you, it looks very interesting discussion. I=E2=80=99d clarify a = bit to your following point: > [...] > Node 5 receives the packet, and as it is DA=3D5, decapsulates the = inner > SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the standard > IPv6 forwarding table, resulting in it being forwarded to Node 3, > which then forwards it to Node 9. All of this is happening using > conventional IPv6 destination based forwarding. This behavior of node 5 assumes that there=E2=80=99s on-demand virtual = tunnel between node 2 and node 5 prior to the failure. Is that correct? >=20 > Encapsulation is solving this problem by effectively creating a > on-demand virtual link or tunnel between Node 2 and Node 5, getting > the original packet past the failure point to a point along the > original packet's forwarding path. Once there, it pops out of the > virtual link and is sent along its way. I don't think the insertion of > the EH and DA swapping method could be described the same way or could > be described as simply. So that looks node 9 should define DA=3D9 semantics which the node pops = an outer header and then forward the payload to the inner IPv6 = destination based on the routing table. Basically an IP address of a = node represents the node itself and receiving packets will be punt to = the control-plane. So it seems that the node behavior doesn't work for = conventional nodes. To that behavior works, I think that it requires additional spec to = define such semantics and some control-plane to signal that semantics to = other node. If I comment to that it would be a certain volume of load = for signaling and maintaining the states to the control-planes, even the = data-plane behavior can be kept in conventional. And it would also = require tunnel configurations to the all nodes in each node which I = don=E2=80=99t want to do in our operations. I have to admit my ignorant, but I=E2=80=99m really appreciate if you = let me know about that kind of on-demand tunneling technologies without = bunch of signaling to maintain states and configuration burdens. Best regards, --satoru From nobody Tue Apr 4 01:41:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD02129573 for ; Tue, 4 Apr 2017 01:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 LOL7NlHIvluM for ; Tue, 4 Apr 2017 01:41:46 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 1E1ED12778D for ; Tue, 4 Apr 2017 01:41:46 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id x125so145930508pgb.0 for ; Tue, 04 Apr 2017 01:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wVH8prmvJwEe6jkxXybX2bweCNyhrvoW59op5t8RJCY=; b=HI2zY4d9xEb3NBxTrBJwOqB8f97wTI7wczfUQklJAkSMlxox7v0nmUCmd+ZT3/gFrE w+R5ozU0Fy4qVNDEhFZW1/NAHkCnRu7nmSCpm1GtWmT38L4QdCHAAqLJCBOQkudkEHPk KYyr6SCYW4hmFBj11RQy2YzRdFTYtokswkSoozS6bCb/6zd/01NViNmRBCvqfj0If9cd 5auvMn1CwKWCS0cu166RNze9k4hL0Si3u7NtzQwxt0pGaQze2W54AFVtb/amE/SQLM6y NILfrLEWQ6JKJhSOr2H5Xkp/VA+S5ra/zJm2gJLv8SPDrhfZctj7uOy2AdD2N0UZEZX/ qB8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wVH8prmvJwEe6jkxXybX2bweCNyhrvoW59op5t8RJCY=; b=alW1jPRIJYT/Ve2+OBNZ5Kj6iqB6GSnNZOCLTrsuq4RgGb3BmX9OU2muybtHrjU2SB DdmzANC9NMMv46Wjv+Ci5nmlTMYIOU1PG47CSi28eExSkJigms8nzhKcM6+DQUA5Ujyu djK72ek/t/9TvLsEyqpbVWmgGh6PKGfKk9CRt8wIasJ66tbySvtPU7kl/UyB4nl3+bA8 wblR/OZZixbEV2QVvFutwnir7UEM3p9H1Xypwfc4c/EZlTl8l3DT3y/AsJn5IUajQ7Ib fs/4hPi/uSan4hlijozO9jmPkSgz+cfizs6g+366SDbXTNpu8fKwz2XECdKfGAoBH+mZ T2XQ== X-Gm-Message-State: AFeK/H1n+Vz6jK8exkFF7IFUWpPlFh5PQmG24MGzqsDocLXOHL1KI21pDXYKz4IhMRTC1Q== X-Received: by 10.98.196.142 with SMTP id h14mr21217406pfk.265.1491295305757; Tue, 04 Apr 2017 01:41:45 -0700 (PDT) Received: from [10.207.113.167] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id 201sm23402039pfc.126.2017.04.04.01.41.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 01:41:44 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Tue, 4 Apr 2017 17:41:42 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <61B1B02B-A255-4704-AAC9-2301E54B285A@gmail.com> References: To: Mark Smith X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 08:41:48 -0000 Oops, please s/9/5/; to the following sentence: > So that looks node 9 should define DA=3D9 semantics which the node = pops an outer header and then forward the payload to the inner IPv6 = destination based on the routing table. Best regards, --satoru=01= From nobody Tue Apr 4 01:51:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D423127058 for ; Tue, 4 Apr 2017 01:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 d0ZEAgTGEoMo for ; Tue, 4 Apr 2017 01:51:18 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17839126BFD for ; Tue, 4 Apr 2017 01:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4750; q=dns/txt; s=iport; t=1491295878; x=1492505478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=omhDt8+b8WH7enqfL1LugMHKeagyvNXm4xfz7v1nTkU=; b=basa2aPijYFAsodnhsyE7fvN65RFZ2yX0l57tsOMQOfbKToy9TerYGL0 D0fUMAf8R7/q7czFxOpb6ByXuZX8lDWtiMCQtCkehZPUBhqbYAikTy9VD IBd2/W9YiYRWjIguziasqcHJpM+kw53ysSOclIDSihbGy+MMbzV4PKwQQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgAjXuNY/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1yKEpE6H4gajTiCDh8LhXgCGoMePxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhEToLBQsCAQgYAgImAgICHwYLFRACBA4FiXYDDQgOrU2CJ?= =?us-ascii?q?ocpDYMkAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggUIgmKCUYUJLoIxBYk?= =?us-ascii?q?jkw87AY4XhDiBfYUug1mGOIp4iHwBHziBBVsVQREBhkd1iAeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,274,1486425600"; d="scan'208";a="403340132" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2017 08:51:17 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v348pGk4024928 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 08:51:17 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 04:51:16 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 04:51:16 -0400 From: "Stefano Previdi (sprevidi)" To: Satoru Matsushima CC: Mark Smith , 6man WG Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Topic: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Index: AQHSrSCeojOuXsnI50mtNu1e1taQ3w== Date: Tue, 4 Apr 2017 08:51:15 +0000 Message-ID: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.221.88] Content-Type: text/plain; charset="utf-8" Content-ID: <114AF39FD55FF54FAA7760429460B462@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 08:51:20 -0000 DQo+IE9uIEFwciA0LCAyMDE3LCBhdCAxMDozOCBBTSwgU2F0b3J1IE1hdHN1c2hpbWEgPHNhdG9y dS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIZWxsbyBNYXJrLA0KPiANCj4g VGhhbmsgeW91LCBpdCBsb29rcyB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24uIEnigJlkIGNs YXJpZnkgYSBiaXQgdG8geW91ciBmb2xsb3dpbmcgcG9pbnQ6DQo+IA0KPj4gWy4uLl0NCj4gDQo+ PiBOb2RlIDUgcmVjZWl2ZXMgdGhlIHBhY2tldCwgYW5kIGFzIGl0IGlzIERBPTUsIGRlY2Fwc3Vs YXRlcyB0aGUgaW5uZXINCj4+IFNBPTEsIERBPTkgcGFja2V0LiBOb2RlIDUgdGhlbiBzdWJtaXRz IHRoYXQgcGFja2V0IHRvIHRoZSBzdGFuZGFyZA0KPj4gSVB2NiBmb3J3YXJkaW5nIHRhYmxlLCBy ZXN1bHRpbmcgaW4gaXQgYmVpbmcgZm9yd2FyZGVkIHRvIE5vZGUgMywNCj4+IHdoaWNoIHRoZW4g Zm9yd2FyZHMgaXQgdG8gTm9kZSA5LiBBbGwgb2YgdGhpcyBpcyBoYXBwZW5pbmcgdXNpbmcNCj4+ IGNvbnZlbnRpb25hbCBJUHY2IGRlc3RpbmF0aW9uIGJhc2VkIGZvcndhcmRpbmcuDQo+IA0KPiBU aGlzIGJlaGF2aW9yIG9mIG5vZGUgNSBhc3N1bWVzIHRoYXQgdGhlcmXigJlzIG9uLWRlbWFuZCB2 aXJ0dWFsIHR1bm5lbCBiZXR3ZWVuIG5vZGUgMiBhbmQgbm9kZSA1IHByaW9yIHRvIHRoZSBmYWls dXJlLiBJcyB0aGF0IGNvcnJlY3Q/DQoNCg0KdGhpcyBpcyBwYXJ0IG9mIFRJLUxGQSAoYW5kIG1v cmUgZ2VuZXJhbCBmYXN0IHJlLXJwb3V0ZSkgdGVjaG5vbG9neS4NCg0KeWVzLCB0aGUgcmVwYWly IHBhdGggaXMgcHJlLWNvbXB1dGVkIGluIHRoZSBmb3JtIG9mIGEgc2VnbWVudCBsaXN0Lg0KDQoN Cj4+IEVuY2Fwc3VsYXRpb24gaXMgc29sdmluZyB0aGlzIHByb2JsZW0gYnkgZWZmZWN0aXZlbHkg Y3JlYXRpbmcgYQ0KPj4gb24tZGVtYW5kIHZpcnR1YWwgbGluayBvciB0dW5uZWwgYmV0d2VlbiBO b2RlIDIgYW5kIE5vZGUgNSwgZ2V0dGluZw0KPj4gdGhlIG9yaWdpbmFsIHBhY2tldCBwYXN0IHRo ZSBmYWlsdXJlIHBvaW50IHRvIGEgcG9pbnQgYWxvbmcgdGhlDQo+PiBvcmlnaW5hbCBwYWNrZXQn cyBmb3J3YXJkaW5nIHBhdGguIE9uY2UgdGhlcmUsIGl0IHBvcHMgb3V0IG9mIHRoZQ0KPj4gdmly dHVhbCBsaW5rIGFuZCBpcyBzZW50IGFsb25nIGl0cyB3YXkuIEkgZG9uJ3QgdGhpbmsgdGhlIGlu c2VydGlvbiBvZg0KPj4gdGhlIEVIIGFuZCBEQSBzd2FwcGluZyBtZXRob2QgY291bGQgYmUgZGVz Y3JpYmVkIHRoZSBzYW1lIHdheSBvciBjb3VsZA0KPj4gYmUgZGVzY3JpYmVkIGFzIHNpbXBseS4N Cj4gDQo+IFNvIHRoYXQgbG9va3Mgbm9kZSA5IHNob3VsZCBkZWZpbmUgREE9OSBzZW1hbnRpY3Mg d2hpY2ggdGhlIG5vZGUgcG9wcyBhbiBvdXRlciBoZWFkZXIgYW5kIHRoZW4gZm9yd2FyZCB0aGUg cGF5bG9hZCB0byB0aGUgaW5uZXIgSVB2NiBkZXN0aW5hdGlvbiBiYXNlZCBvbiB0aGUgcm91dGlu ZyB0YWJsZS4gQmFzaWNhbGx5IGFuIElQIGFkZHJlc3Mgb2YgYSBub2RlIHJlcHJlc2VudHMgdGhl IG5vZGUgaXRzZWxmIGFuZCByZWNlaXZpbmcgcGFja2V0cyB3aWxsIGJlIHB1bnQgdG8gdGhlIGNv bnRyb2wtcGxhbmUuIFNvIGl0IHNlZW1zIHRoYXQgdGhlIG5vZGUgYmVoYXZpb3IgZG9lc24ndCB3 b3JrIGZvciBjb252ZW50aW9uYWwgbm9kZXMuDQoNCg0KY29ycmVjdC4gUGxlYXNlIHJlYWQgZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNydjYtbmV0d29yay1wcm9ncmFtbWluZyBhbmQgeW914oCZbGwg c2VlIHdlIGRlZmluZWQgYW4gZXhwbGljaXQgYmVoYXZpb3IgZm9yIHRoYXQuDQoNClN1YyBiZWhh dmlvciBpcyBzaWduYWxlZCBpbiB0aGUgY29udHJvbCBwbGFuZSBvZiB0aGUgaW5mcmFzdHJ1Y3R1 cmUgKGlzaXMsIG9zcGYpLiBTZWUgZXh0ZW5zaW9ucyBkZXNjcmliZWQgaW4gZHJhZnQtYmFzaGFu ZHktaXNpcy1zcnY2LWV4dGVuc2lvbnMuDQoNCg0KPiBUbyB0aGF0IGJlaGF2aW9yIHdvcmtzLCBJ IHRoaW5rIHRoYXQgaXQgcmVxdWlyZXMgYWRkaXRpb25hbCBzcGVjIHRvIGRlZmluZSBzdWNoIHNl bWFudGljcyBhbmQgc29tZSBjb250cm9sLXBsYW5lIHRvIHNpZ25hbCB0aGF0IHNlbWFudGljcyB0 byBvdGhlciBub2RlLg0KDQoNCmNvcnJlY3QuIFNlZSBhYm92ZS4NCg0KDQo+IElmIEkgY29tbWVu dCB0byB0aGF0IGl0IHdvdWxkIGJlIGEgY2VydGFpbiB2b2x1bWUgb2YgbG9hZCBmb3Igc2lnbmFs aW5nIGFuZCBtYWludGFpbmluZyB0aGUgc3RhdGVzIHRvIHRoZSBjb250cm9sLXBsYW5lcywgZXZl biB0aGUgZGF0YS1wbGFuZSBiZWhhdmlvciBjYW4gYmUga2VwdCBpbiBjb252ZW50aW9uYWwuIEFu ZCBpdCB3b3VsZCBhbHNvIHJlcXVpcmUgdHVubmVsIGNvbmZpZ3VyYXRpb25zIHRvIHRoZSBhbGwg bm9kZXMgaW4gZWFjaCBub2RlIHdoaWNoIEkgZG9u4oCZdCB3YW50IHRvIGRvIGluIG91ciBvcGVy YXRpb25zLg0KDQoNCmdvb2QgcG9pbnQsIGJ1dCBJ4oCZbSBhZnJhaWQgeW914oCZcmUgbm90IGZh bWlsaWFyIHdpdGggVEktTEZBLiBUaGVyZeKAmXMgdmVyeSBsaXR0bGUgc3RhdGUgdG8ga2VlcCBh bmQgdGhlcmXigJlzIG5vIHR1bm5lbCBwcm92aXNpb25pbmcuIFRoaXMgaXMgdHJhZGl0aW9uYWwg TEZBL0lQRlJSLg0KDQoNCj4gSSBoYXZlIHRvIGFkbWl0IG15IGlnbm9yYW50LCBidXQgSeKAmW0g cmVhbGx5IGFwcHJlY2lhdGUgaWYgeW91IGxldCBtZSBrbm93IGFib3V0IHRoYXQga2luZCBvZiBv bi1kZW1hbmQgdHVubmVsaW5nIHRlY2hub2xvZ2llcyB3aXRob3V0IGJ1bmNoIG9mIHNpZ25hbGlu ZyB0byBtYWludGFpbiBzdGF0ZXMgYW5kIGNvbmZpZ3VyYXRpb24gYnVyZGVucy4NCg0KDQpkcmFm dC1maWxzZmlscy1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nIA0KZHJhZnQtYmFzaGFu ZHktaXNpcy1zcnY2LWV4dGVuc2lvbnMNClJGQzc4NTUNCmRyYWZ0LWlldGYtc3ByaW5nLXJlc2ls aWVuY3ktdXNlLWNhc2UNCmRyYWZ0LWZyYW5jb2lzLXJ0Z3dnLXNlZ21lbnQtcm91dGluZy10aS1s ZmENCg0KS2VlcCBpbiBtaW5kIHRoYXQgTEZBIHRlY2hub2xvZ2llcyBoYXZlIGJlZW4gZGVwbG95 ZWQgZm9yIGEgZmV3IHllYXJzIGFscmVhZHkgYW5kIFRJLUxGQSBpcyBiZWluZyBkZXBsb3llZCBh cyB3ZSBzcGVhay4NCg0Kcy4NCg0KDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gLS1zYXRvcnUN Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Tue Apr 4 02:18:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14EB1273B1 for ; Tue, 4 Apr 2017 02:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 7ugDV5Yg7ZlN for ; Tue, 4 Apr 2017 02:18:51 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 16F9A126BFD for ; Tue, 4 Apr 2017 02:18:51 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id x125so146803093pgb.0 for ; Tue, 04 Apr 2017 02:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=auR4A9v/2+wQbnqgUOqwA59DWYyoBPX9RY7FNpMcIas=; b=u0Ptfsr61uspoqnXpX/KHuYPvsCAGf+vv4RNoexR65CcAMSXEvE4Hol6HtbKArgDk2 QI+NkxhA+YzkOX/dsAg72Za2FDpB4QtEGNi98yrWm+D01AwzWF314OOk7EuJs/Z/VzlI ikrQcExqkkDBNHl1cUP+gyhkaoMU4aOKw5Osu2upVr15Ja7u6nLbz/Z4DphXe64tpYz9 SU9oi/Hjb6s5PJ/JBPYKv2Vb9/gMLLO99t+RSJ74mzqO/i0AJikQrtupIWYoPcXiMuoz 0YHSV8XPjZZBvcXAjuV8FkKSDFX4iJpCxcvr4K/K/BV6IpozR7bPBzxUvOATjkMjKiob n4cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=auR4A9v/2+wQbnqgUOqwA59DWYyoBPX9RY7FNpMcIas=; b=UMMGCwsG/w5S7TuvtJesilM8M9qIIeUYrDDn1anASGKsVWG1rFuHLTiMysy/z9e3r/ hhiSykhElYCpSmbLkwGQ64Wadl2yRg7iCES15/M9gWtht621ds8tJTQn6UouUCMT+64C a/TxZkoyIrDtYWo13kCd/BUY29Y5zVliuW2/Pq7JeAs1ezTtxLNdnGQQJxUFtzT4luEz dpg5uxOMh8Z8k+4TGf5/aSaCXywX8JgEhYrbpSFVVjzhw1utqH55U6DCMy7nD+C9q5uf NLaDELz5QuxBZm/tWJtCE7bigXLzWJ51wiQIP+2VfjXuadqxqHlXcjiuZIceojJGaja2 Ri+g== X-Gm-Message-State: AFeK/H0ggccEf32dFkDL3aiOCGeRiUW7qVaGN6Mfi8lnUGw8bohpfKzQA2Q8D1/JVHtsIQ== X-Received: by 10.98.218.76 with SMTP id w12mr21892789pfl.162.1491297530547; Tue, 04 Apr 2017 02:18:50 -0700 (PDT) Received: from [10.207.113.167] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id k2sm30549802pga.47.2017.04.04.02.18.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 02:18:49 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> Date: Tue, 4 Apr 2017 18:18:46 +0900 Cc: Mark Smith , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <7A6DA9C6-9668-4AA1-A28A-A11069EA2370@gmail.com> References: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:18:53 -0000 Hello Stefano, Thank you for pointing the references in your prompt response. That = seems SRv6 can define all the forwarding semantics to support TI-LFA, a = fast protection technology without signaling and configuration burdens. = So my question here is do you think it is possible to achieve that with = whether purely IPv6-in-IPv6 tunneling without the burdens same as SRv6. = As Mark said, if it is possible with IPv6-in-IPv6 tunneling only, what = else required to do that seems to me is bunch of signaling and = configuration burdens. If SRv6 is a good choice, or only choice for that without the burdens, = SRH processing capability must be required to the nodes. I think it = would be obvious. So my second question here is that: do we really need = to put additional outer IPv6 header just to place the SRH for TI-LFA = even all the nodes are fully SRv6 capable nodes which are able to insert = SRH to the packets. Best regards, --satoru > 2017/04/04 17:51=E3=80=81Stefano Previdi (sprevidi) = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >=20 >> On Apr 4, 2017, at 10:38 AM, Satoru Matsushima = wrote: >>=20 >> Hello Mark, >>=20 >> Thank you, it looks very interesting discussion. I=E2=80=99d clarify = a bit to your following point: >>=20 >>> [...] >>=20 >>> Node 5 receives the packet, and as it is DA=3D5, decapsulates the = inner >>> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the = standard >>> IPv6 forwarding table, resulting in it being forwarded to Node 3, >>> which then forwards it to Node 9. All of this is happening using >>> conventional IPv6 destination based forwarding. >>=20 >> This behavior of node 5 assumes that there=E2=80=99s on-demand = virtual tunnel between node 2 and node 5 prior to the failure. Is that = correct? >=20 >=20 > this is part of TI-LFA (and more general fast re-rpoute) technology. >=20 > yes, the repair path is pre-computed in the form of a segment list. >=20 >=20 >>> Encapsulation is solving this problem by effectively creating a >>> on-demand virtual link or tunnel between Node 2 and Node 5, getting >>> the original packet past the failure point to a point along the >>> original packet's forwarding path. Once there, it pops out of the >>> virtual link and is sent along its way. I don't think the insertion = of >>> the EH and DA swapping method could be described the same way or = could >>> be described as simply. >>=20 >> So that looks node 9 should define DA=3D9 semantics which the node = pops an outer header and then forward the payload to the inner IPv6 = destination based on the routing table. Basically an IP address of a = node represents the node itself and receiving packets will be punt to = the control-plane. So it seems that the node behavior doesn't work for = conventional nodes. >=20 >=20 > correct. Please read draft-filsfils-spring-srv6-network-programming = and you=E2=80=99ll see we defined an explicit behavior for that. >=20 > Suc behavior is signaled in the control plane of the infrastructure = (isis, ospf). See extensions described in = draft-bashandy-isis-srv6-extensions. >=20 >=20 >> To that behavior works, I think that it requires additional spec to = define such semantics and some control-plane to signal that semantics to = other node. >=20 >=20 > correct. See above. >=20 >=20 >> If I comment to that it would be a certain volume of load for = signaling and maintaining the states to the control-planes, even the = data-plane behavior can be kept in conventional. And it would also = require tunnel configurations to the all nodes in each node which I = don=E2=80=99t want to do in our operations. >=20 >=20 > good point, but I=E2=80=99m afraid you=E2=80=99re not familiar with = TI-LFA. There=E2=80=99s very little state to keep and there=E2=80=99s no = tunnel provisioning. This is traditional LFA/IPFRR. >=20 >=20 >> I have to admit my ignorant, but I=E2=80=99m really appreciate if you = let me know about that kind of on-demand tunneling technologies without = bunch of signaling to maintain states and configuration burdens. >=20 >=20 > draft-filsfils-spring-srv6-network-programming=20 > draft-bashandy-isis-srv6-extensions > RFC7855 > draft-ietf-spring-resiliency-use-case > draft-francois-rtgwg-segment-routing-ti-lfa >=20 > Keep in mind that LFA technologies have been deployed for a few years = already and TI-LFA is being deployed as we speak. >=20 > s. >=20 >=20 >=20 >>=20 >> Best regards, >> --satoru >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Apr 4 02:41:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4A129648 for ; Tue, 4 Apr 2017 02:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3NA-M0L1xfZ7 for ; Tue, 4 Apr 2017 02:41:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE8912955B for ; Tue, 4 Apr 2017 02:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8646; q=dns/txt; s=iport; t=1491298877; x=1492508477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+dBbHBKx6969cY0EyV4GTfDpHIYPg6MLJ+8BsdRvqlQ=; b=JrCsQvg3L/P9Gk6BuhUkEdfSmtiZK2/k00HC6rbG0xLldPzYQOk0LfKv 3mmPAGpq2q6/nfC5/5fISuTW5ieojvF5PxY/zRkASru1CKjZfM1FXQnfC fLBVmUcnx4iW8ZjFYPk/JFtghn2qMSI5w3PPSN51t5IBSS57gFiAlAly3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgAnaeNY/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYELB4NcihKROh+IGo04gg4fC4V4AhqDHz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CwULAgEGAhgCAiYCAgIfBgsVEAIEDgWJdgMNCA6QC?= =?us-ascii?q?p1cgiaHKQ2DJAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFQ4IFCIJiglGCAxe?= =?us-ascii?q?Cby6CMQWJI4x3hhg7AY4XhDiBfYUug1mGOIp4iHwBHziBBVsVQREBhEcdgWN1i?= =?us-ascii?q?AeBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,274,1486425600"; d="scan'208";a="226426021" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 09:41:16 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v349fGgm008383 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 09:41:16 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 05:41:15 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 05:41:15 -0400 From: "Stefano Previdi (sprevidi)" To: Satoru Matsushima CC: Mark Smith , 6man WG Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Topic: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Index: AQHSrSR2/6qlUOSo0EqKciWm+qM526G1N/YA Date: Tue, 4 Apr 2017 09:41:15 +0000 Message-ID: References: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> <7A6DA9C6-9668-4AA1-A28A-A11069EA2370@gmail.com> In-Reply-To: <7A6DA9C6-9668-4AA1-A28A-A11069EA2370@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.221.88] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 09:41:21 -0000 DQo+IE9uIEFwciA0LCAyMDE3LCBhdCAxMToxOCBBTSwgU2F0b3J1IE1hdHN1c2hpbWEgPHNhdG9y dS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIZWxsbyBTdGVmYW5vLA0KPiAN Cj4gVGhhbmsgeW91IGZvciBwb2ludGluZyB0aGUgcmVmZXJlbmNlcyBpbiB5b3VyIHByb21wdCBy ZXNwb25zZS4gVGhhdCBzZWVtcyBTUnY2IGNhbiBkZWZpbmUgYWxsIHRoZSBmb3J3YXJkaW5nIHNl bWFudGljcyB0byBzdXBwb3J0IFRJLUxGQSwgYSBmYXN0IHByb3RlY3Rpb24gdGVjaG5vbG9neSB3 aXRob3V0IHNpZ25hbGluZyBhbmQgY29uZmlndXJhdGlvbiBidXJkZW5zLiBTbyBteSBxdWVzdGlv biBoZXJlIGlzIGRvIHlvdSB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBhY2hpZXZlIHRoYXQgd2l0 aCB3aGV0aGVyIHB1cmVseSBJUHY2LWluLUlQdjYgdHVubmVsaW5nIHdpdGhvdXQgdGhlIGJ1cmRl bnMgc2FtZSBhcyBTUnY2Lg0KDQoNClRJLUxGQSBhcyBhbnkgb3RoZXIgdHJhZmZpYyBlbmdpbmVl cmluZyBhbmQvb3IgZmFzdC1yZXJvdXRlIHRlY2hub2xvZ3ksIHVzZXMgdGhlIGNvbmNlcHQgb2Yg YSBzb3VyY2Ugcm91dGVkIHBhdGguDQoNClRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvIGV4cHJl c3MgYSBzb3VyY2Ugcm91dGVkIHBhdGguDQoNCkluZGVlZCB5b3UgY291bGQgZXhwcmVzcyBhIHBh dGggYnkgc3RhY2tpbmcgaXB2NiBoZWFkZXJzIG9uIG9uIHRvcCBvZiBlYWNoIG90aGVyLiBUaGlz IG9wdGlvbiBpcyBjbGVhcmx5IHVucHJhY3RpY2FsLCBpbmVmZmljaWVudCBhbmQgbm9uLXNjYWxh YmxlLg0KDQpUaGUgYmVzdCBhcHByb2FjaCBpcyB0byBleHByZXNzIGEgc291cmNlIHJvdXRlZCBw YXRoIHdpdGggdGhlIHJpZ2h0IHRvb2w6IHRoZSByb3V0aW5nIGhlYWRlciwgYW5kIG1vcmUgcHJl Y2lzZWx5IHRoZSBzZWdtZW50IHJvdXRpbmcgaGVhZGVyIChTUkgpLg0KDQogDQo+IEFzIE1hcmsg c2FpZCwgaWYgaXQgaXMgcG9zc2libGUgd2l0aCBJUHY2LWluLUlQdjYgdHVubmVsaW5nIG9ubHks IHdoYXQgZWxzZSByZXF1aXJlZCB0byBkbyB0aGF0IHNlZW1zIHRvIG1lIGlzIGJ1bmNoIG9mIHNp Z25hbGluZyBhbmQgY29uZmlndXJhdGlvbiBidXJkZW5zLg0KDQoNCkkgdGhpbmsgZXZlcnlvbmUg aW4gdGhlIGluZHVzdHJ5IGFncmVlcyB0aGF0IHN0YWNraW5nIGlwdjYgaGVhZGVycyBhcyBhIHNv dXJjZSByb3V0aW5nIHRlY2huaXF1ZSBpcyByZWFsbHkgdW5wcmFjdGljYWwgYW5kIGl04oCZcyBy ZWFsbHkgYSBwb29yIGNob2ljZSBjb21wYXJlZCB0byB0aGUgZXhjZWxsZW50IHRvb2wgd2UgaGF2 ZSB3aXRoIGV4dGVuc2lvbnMgaGVhZGVycy4NCg0KSSBoYXZlIG5vdGhpbmcgYWdhaW5zdCBiaWN5 Y2xlcywgYnV0IElmIEkgaGF2ZSB0byB0cmFuc3BvcnQgZnJlaWdodCwgSSBjbGVhcmx5IHByZWZl ciBhIHRydWNrLi4uDQoNCg0KPiBJZiBTUnY2IGlzIGEgZ29vZCBjaG9pY2UsIG9yIG9ubHkgY2hv aWNlIGZvciB0aGF0IHdpdGhvdXQgdGhlIGJ1cmRlbnMsIFNSSCBwcm9jZXNzaW5nIGNhcGFiaWxp dHkgbXVzdCBiZSByZXF1aXJlZCB0byB0aGUgbm9kZXMuDQoNCg0KdG8gdGhlIG5vZGVzIHRoYXQg YXJlIHNlZ21lbnRzIGFuZCB0byB0aGUgbm9kZXMgdGhhdCBhcmUgVEktTEZBIFBMUiAocG9pbnQg b2YgbG9jYWwgcmVwYWlyKS4gVGhpcyBkb2VzIG5vdCBtZWFuIOKAnGFsbCBub2Rlc+KAnSBpbiB0 aGUgbmV0d29yay4NCg0KDQo+IEkgdGhpbmsgaXQgd291bGQgYmUgb2J2aW91cy4gU28gbXkgc2Vj b25kIHF1ZXN0aW9uIGhlcmUgaXMgdGhhdDogZG8gd2UgcmVhbGx5IG5lZWQgdG8gcHV0IGFkZGl0 aW9uYWwgb3V0ZXIgSVB2NiBoZWFkZXIganVzdCB0byBwbGFjZSB0aGUgU1JIIGZvciBUSS1MRkEg ZXZlbiBhbGwgdGhlIG5vZGVzIGFyZSBmdWxseSBTUnY2IGNhcGFibGUgbm9kZXMgd2hpY2ggYXJl IGFibGUgdG8gaW5zZXJ0IFNSSCB0byB0aGUgcGFja2V0cy4NCg0KDQp0aGF0IGlzIGFuIGV4Y2Vs bGVudCBxdWVzdGlvbi4NCg0KTm8sIHlvdSBkb27igJl0IG5lZWQgYW4gb3V0ZXIgZW5jYXBzdWxh dGlvbiBhbmQgaW4gbWFueSAoaWYgbm90IG1vc3QpIG9mIHRoZSBjYXNlcywgdGhlIFRJLUxGQSBQ TFIgbm9kZSB3aWxsIG5vdCBhZGQgYW4gb3V0ZXIgZW5jYXBzdWxhdGlvbi4NCg0KV2hhdCB3ZSBw cm9wb3NlIGluIGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24gaXMg dG8gYWRkIGFuIG91dGVyIGVuY2Fwc3VsYXRpb24gYXQgdGhlIGluZ3Jlc3Mgb2YgdGhlIGRvbWFp biBzbyB0aGF0LCB3aGVuIHRoZSBQTFIgbm9kZSBpbnNlcnRzIGFuIFNSSCwgaXQgZG9lcyBzbyB1 bmRlciB0aGUgb3V0ZXIgSVB2NiBoZWFkZXIgdGhhdCBoYXMgYmVlbiBhZGRlZCBhdCBpbmdyZXNz LiBUaGVyZWZvcmUsIHRoZSBpbnNlcnRpb24gb2YgdGhlIFNSSCBoYXBwZW5zIGludG8gYSBwYWNr ZXQgdGhhdCBoYXMgYmVlbiBzb3VyY2VkIHdpdGhpbiB0aGUgZG9tYWluLg0KDQpUaGFua3MuDQpz Lg0KDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gLS1zYXRvcnUNCj4gDQo+IA0KPj4gMjAxNy8w NC8wNCAxNzo1MeOAgVN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIDxzcHJldmlkaUBjaXNjby5j b20+IOOBruODoeODvOODq++8mg0KPj4gDQo+PiANCj4+PiBPbiBBcHIgNCwgMjAxNywgYXQgMTA6 MzggQU0sIFNhdG9ydSBNYXRzdXNoaW1hIDxzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+IHdy b3RlOg0KPj4+IA0KPj4+IEhlbGxvIE1hcmssDQo+Pj4gDQo+Pj4gVGhhbmsgeW91LCBpdCBsb29r cyB2ZXJ5IGludGVyZXN0aW5nIGRpc2N1c3Npb24uIEnigJlkIGNsYXJpZnkgYSBiaXQgdG8geW91 ciBmb2xsb3dpbmcgcG9pbnQ6DQo+Pj4gDQo+Pj4+IFsuLi5dDQo+Pj4gDQo+Pj4+IE5vZGUgNSBy ZWNlaXZlcyB0aGUgcGFja2V0LCBhbmQgYXMgaXQgaXMgREE9NSwgZGVjYXBzdWxhdGVzIHRoZSBp bm5lcg0KPj4+PiBTQT0xLCBEQT05IHBhY2tldC4gTm9kZSA1IHRoZW4gc3VibWl0cyB0aGF0IHBh Y2tldCB0byB0aGUgc3RhbmRhcmQNCj4+Pj4gSVB2NiBmb3J3YXJkaW5nIHRhYmxlLCByZXN1bHRp bmcgaW4gaXQgYmVpbmcgZm9yd2FyZGVkIHRvIE5vZGUgMywNCj4+Pj4gd2hpY2ggdGhlbiBmb3J3 YXJkcyBpdCB0byBOb2RlIDkuIEFsbCBvZiB0aGlzIGlzIGhhcHBlbmluZyB1c2luZw0KPj4+PiBj b252ZW50aW9uYWwgSVB2NiBkZXN0aW5hdGlvbiBiYXNlZCBmb3J3YXJkaW5nLg0KPj4+IA0KPj4+ IFRoaXMgYmVoYXZpb3Igb2Ygbm9kZSA1IGFzc3VtZXMgdGhhdCB0aGVyZeKAmXMgb24tZGVtYW5k IHZpcnR1YWwgdHVubmVsIGJldHdlZW4gbm9kZSAyIGFuZCBub2RlIDUgcHJpb3IgdG8gdGhlIGZh aWx1cmUuIElzIHRoYXQgY29ycmVjdD8NCj4+IA0KPj4gDQo+PiB0aGlzIGlzIHBhcnQgb2YgVEkt TEZBIChhbmQgbW9yZSBnZW5lcmFsIGZhc3QgcmUtcnBvdXRlKSB0ZWNobm9sb2d5Lg0KPj4gDQo+ PiB5ZXMsIHRoZSByZXBhaXIgcGF0aCBpcyBwcmUtY29tcHV0ZWQgaW4gdGhlIGZvcm0gb2YgYSBz ZWdtZW50IGxpc3QuDQo+PiANCj4+IA0KPj4+PiBFbmNhcHN1bGF0aW9uIGlzIHNvbHZpbmcgdGhp cyBwcm9ibGVtIGJ5IGVmZmVjdGl2ZWx5IGNyZWF0aW5nIGENCj4+Pj4gb24tZGVtYW5kIHZpcnR1 YWwgbGluayBvciB0dW5uZWwgYmV0d2VlbiBOb2RlIDIgYW5kIE5vZGUgNSwgZ2V0dGluZw0KPj4+ PiB0aGUgb3JpZ2luYWwgcGFja2V0IHBhc3QgdGhlIGZhaWx1cmUgcG9pbnQgdG8gYSBwb2ludCBh bG9uZyB0aGUNCj4+Pj4gb3JpZ2luYWwgcGFja2V0J3MgZm9yd2FyZGluZyBwYXRoLiBPbmNlIHRo ZXJlLCBpdCBwb3BzIG91dCBvZiB0aGUNCj4+Pj4gdmlydHVhbCBsaW5rIGFuZCBpcyBzZW50IGFs b25nIGl0cyB3YXkuIEkgZG9uJ3QgdGhpbmsgdGhlIGluc2VydGlvbiBvZg0KPj4+PiB0aGUgRUgg YW5kIERBIHN3YXBwaW5nIG1ldGhvZCBjb3VsZCBiZSBkZXNjcmliZWQgdGhlIHNhbWUgd2F5IG9y IGNvdWxkDQo+Pj4+IGJlIGRlc2NyaWJlZCBhcyBzaW1wbHkuDQo+Pj4gDQo+Pj4gU28gdGhhdCBs b29rcyBub2RlIDkgc2hvdWxkIGRlZmluZSBEQT05IHNlbWFudGljcyB3aGljaCB0aGUgbm9kZSBw b3BzIGFuIG91dGVyIGhlYWRlciBhbmQgdGhlbiBmb3J3YXJkIHRoZSBwYXlsb2FkIHRvIHRoZSBp bm5lciBJUHY2IGRlc3RpbmF0aW9uIGJhc2VkIG9uIHRoZSByb3V0aW5nIHRhYmxlLiBCYXNpY2Fs bHkgYW4gSVAgYWRkcmVzcyBvZiBhIG5vZGUgcmVwcmVzZW50cyB0aGUgbm9kZSBpdHNlbGYgYW5k IHJlY2VpdmluZyBwYWNrZXRzIHdpbGwgYmUgcHVudCB0byB0aGUgY29udHJvbC1wbGFuZS4gU28g aXQgc2VlbXMgdGhhdCB0aGUgbm9kZSBiZWhhdmlvciBkb2Vzbid0IHdvcmsgZm9yIGNvbnZlbnRp b25hbCBub2Rlcy4NCj4+IA0KPj4gDQo+PiBjb3JyZWN0LiBQbGVhc2UgcmVhZCBkcmFmdC1maWxz Zmlscy1zcHJpbmctc3J2Ni1uZXR3b3JrLXByb2dyYW1taW5nIGFuZCB5b3XigJlsbCBzZWUgd2Ug ZGVmaW5lZCBhbiBleHBsaWNpdCBiZWhhdmlvciBmb3IgdGhhdC4NCj4+IA0KPj4gU3VjIGJlaGF2 aW9yIGlzIHNpZ25hbGVkIGluIHRoZSBjb250cm9sIHBsYW5lIG9mIHRoZSBpbmZyYXN0cnVjdHVy ZSAoaXNpcywgb3NwZikuIFNlZSBleHRlbnNpb25zIGRlc2NyaWJlZCBpbiBkcmFmdC1iYXNoYW5k eS1pc2lzLXNydjYtZXh0ZW5zaW9ucy4NCj4+IA0KPj4gDQo+Pj4gVG8gdGhhdCBiZWhhdmlvciB3 b3JrcywgSSB0aGluayB0aGF0IGl0IHJlcXVpcmVzIGFkZGl0aW9uYWwgc3BlYyB0byBkZWZpbmUg c3VjaCBzZW1hbnRpY3MgYW5kIHNvbWUgY29udHJvbC1wbGFuZSB0byBzaWduYWwgdGhhdCBzZW1h bnRpY3MgdG8gb3RoZXIgbm9kZS4NCj4+IA0KPj4gDQo+PiBjb3JyZWN0LiBTZWUgYWJvdmUuDQo+ PiANCj4+IA0KPj4+IElmIEkgY29tbWVudCB0byB0aGF0IGl0IHdvdWxkIGJlIGEgY2VydGFpbiB2 b2x1bWUgb2YgbG9hZCBmb3Igc2lnbmFsaW5nIGFuZCBtYWludGFpbmluZyB0aGUgc3RhdGVzIHRv IHRoZSBjb250cm9sLXBsYW5lcywgZXZlbiB0aGUgZGF0YS1wbGFuZSBiZWhhdmlvciBjYW4gYmUg a2VwdCBpbiBjb252ZW50aW9uYWwuIEFuZCBpdCB3b3VsZCBhbHNvIHJlcXVpcmUgdHVubmVsIGNv bmZpZ3VyYXRpb25zIHRvIHRoZSBhbGwgbm9kZXMgaW4gZWFjaCBub2RlIHdoaWNoIEkgZG9u4oCZ dCB3YW50IHRvIGRvIGluIG91ciBvcGVyYXRpb25zLg0KPj4gDQo+PiANCj4+IGdvb2QgcG9pbnQs IGJ1dCBJ4oCZbSBhZnJhaWQgeW914oCZcmUgbm90IGZhbWlsaWFyIHdpdGggVEktTEZBLiBUaGVy ZeKAmXMgdmVyeSBsaXR0bGUgc3RhdGUgdG8ga2VlcCBhbmQgdGhlcmXigJlzIG5vIHR1bm5lbCBw cm92aXNpb25pbmcuIFRoaXMgaXMgdHJhZGl0aW9uYWwgTEZBL0lQRlJSLg0KPj4gDQo+PiANCj4+ PiBJIGhhdmUgdG8gYWRtaXQgbXkgaWdub3JhbnQsIGJ1dCBJ4oCZbSByZWFsbHkgYXBwcmVjaWF0 ZSBpZiB5b3UgbGV0IG1lIGtub3cgYWJvdXQgdGhhdCBraW5kIG9mIG9uLWRlbWFuZCB0dW5uZWxp bmcgdGVjaG5vbG9naWVzIHdpdGhvdXQgYnVuY2ggb2Ygc2lnbmFsaW5nIHRvIG1haW50YWluIHN0 YXRlcyBhbmQgY29uZmlndXJhdGlvbiBidXJkZW5zLg0KPj4gDQo+PiANCj4+IGRyYWZ0LWZpbHNm aWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcgDQo+PiBkcmFmdC1iYXNoYW5keS1p c2lzLXNydjYtZXh0ZW5zaW9ucw0KPj4gUkZDNzg1NQ0KPj4gZHJhZnQtaWV0Zi1zcHJpbmctcmVz aWxpZW5jeS11c2UtY2FzZQ0KPj4gZHJhZnQtZnJhbmNvaXMtcnRnd2ctc2VnbWVudC1yb3V0aW5n LXRpLWxmYQ0KPj4gDQo+PiBLZWVwIGluIG1pbmQgdGhhdCBMRkEgdGVjaG5vbG9naWVzIGhhdmUg YmVlbiBkZXBsb3llZCBmb3IgYSBmZXcgeWVhcnMgYWxyZWFkeSBhbmQgVEktTEZBIGlzIGJlaW5n IGRlcGxveWVkIGFzIHdlIHNwZWFrLg0KPj4gDQo+PiBzLg0KPj4gDQo+PiANCj4+IA0KPj4+IA0K Pj4+IEJlc3QgcmVnYXJkcywNCj4+PiAtLXNhdG9ydQ0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+Pj4gaXB2NkBpZXRmLm9y Zw0KPj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjYNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+IA0KDQo= From nobody Tue Apr 4 03:17:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE225129496 for ; Tue, 4 Apr 2017 03:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 s8_cGCIIdeUx for ; Tue, 4 Apr 2017 03:17:20 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 6EBB7129481 for ; Tue, 4 Apr 2017 03:17:18 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 81so148289768pgh.2 for ; Tue, 04 Apr 2017 03:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4KdvP4xt+2PguzBbUMrV2gPLKdE6r2wsGBZ5wC1hpw=; b=GRLptW8tU4aV1cN7i4U/eAbntcM/v54Chhc4EIjwX+oq05p++IDR98IMrXLVAPb4Eg AseowLtJrrxBW5iKth9MPHvK4o5m+T5O8DDSN3yMExoP++2TS2eVQHIUEI9WAYbE3A5c G2Aeug3PQ9eMswYWrtdfn++oI+pCn1gQvMjleCukCYEgwVPE5yP6kBZt8Z7e2Zgiubbe A8EXNqsORGFjco1pVNch8//HA29JOUoHDMY9UH7sgNo/DsgfG3DkQ8QIjR+naYYzWtuA gQ7OhDcP8xkyNVLN8coJBD07c+0LTAKhcKmTCQ/U0UZfWd5r1V5WiD+FF8X51i8gIiqk SjVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4KdvP4xt+2PguzBbUMrV2gPLKdE6r2wsGBZ5wC1hpw=; b=XigNeuINbfKb7aYM4+nZvm/F+4LnV+x2wdP64yNVarNBivzPKt1/cPoLOoloH7fw7v UCZIVw76DAZyfdBs9Rjmr81o+CNki1I0Uy5X6qAvYzsckVT8IJDMTCY8QseG4yWjpqLa ecNOBervUV5owvG4NzEwg4Fobi3YEQexGbJIDkwidBrLPpw0W8REYQYaOrTK+FbaqagN XuFfLZH3Fjq226HatxLtHEMO+vfrfiOAkaDSDyyY4oWnhw/R3AEcLOckbbZvYgfRo+G3 fZhKRMgsOsCwfQYGb7zNKzKyxHGSveqb0GASbZIGAw1plxlyxni8211kuQS5IUa7GkEa 1GPA== X-Gm-Message-State: AFeK/H2+IMwT0RpZLQoyTt6bsROzI4qd4iaRqYzKhiGyM84ibB7d9nKRvo9yiOuw6p3z+w== X-Received: by 10.99.172.84 with SMTP id z20mr22521515pgn.123.1491301037873; Tue, 04 Apr 2017 03:17:17 -0700 (PDT) Received: from [10.207.113.167] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id z185sm30860330pfb.6.2017.04.04.03.17.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 03:17:17 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: Date: Tue, 4 Apr 2017 19:17:12 +0900 Cc: Mark Smith , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> <7A6DA9C6-9668-4AA1-A28A-A11069EA2370@gmail.com> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:17:23 -0000 Hello Stefano, Thank you for the clear answer to my questions. I really appreciate it. > No, you don=E2=80=99t need an outer encapsulation and in many (if not = most) of the cases, the TI-LFA PLR node will not add an outer = encapsulation. >=20 > What we propose in draft-voyer-6man-extension-header-insertion is to = add an outer encapsulation at the ingress of the domain so that, when = the PLR node inserts an SRH, it does so under the outer IPv6 header that = has been added at ingress. Therefore, the insertion of the SRH happens = into a packet that has been sourced within the domain. I understand that. Adding outer header at the ingress of the domain = seems make sense to me because the incoming packets to the domain = include not only IPv6, but also IPv4 or L2 frames. My understanding is = that once the packets come into the domain, there=E2=80=99s no need to = put additional outer IPv6 header on somewhere within the domain when the = packets meet TI-LFA forwarding during a link or node failure. And then = the pushed SRH will be popped out at the MP (Merge Point?) of the = protection path with in the domain. It looks very clear and clean behavior, and also make sense to me. The = pushed SRH will be confined within the source domain of the SRH, which = does no impact to the end-to-end principle. Oh that's the source domain = concept you mentioned. Is that correct? Best regards, --satoru > 2017/04/04 18:41=E3=80=81Stefano Previdi (sprevidi) = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >=20 >> On Apr 4, 2017, at 11:18 AM, Satoru Matsushima = wrote: >>=20 >> Hello Stefano, >>=20 >> Thank you for pointing the references in your prompt response. That = seems SRv6 can define all the forwarding semantics to support TI-LFA, a = fast protection technology without signaling and configuration burdens. = So my question here is do you think it is possible to achieve that with = whether purely IPv6-in-IPv6 tunneling without the burdens same as SRv6. >=20 >=20 > TI-LFA as any other traffic engineering and/or fast-reroute = technology, uses the concept of a source routed path. >=20 > There are multiple ways to express a source routed path. >=20 > Indeed you could express a path by stacking ipv6 headers on on top of = each other. This option is clearly unpractical, inefficient and = non-scalable. >=20 > The best approach is to express a source routed path with the right = tool: the routing header, and more precisely the segment routing header = (SRH). >=20 >=20 >> As Mark said, if it is possible with IPv6-in-IPv6 tunneling only, = what else required to do that seems to me is bunch of signaling and = configuration burdens. >=20 >=20 > I think everyone in the industry agrees that stacking ipv6 headers as = a source routing technique is really unpractical and it=E2=80=99s really = a poor choice compared to the excellent tool we have with extensions = headers. >=20 > I have nothing against bicycles, but If I have to transport freight, I = clearly prefer a truck... >=20 >=20 >> If SRv6 is a good choice, or only choice for that without the = burdens, SRH processing capability must be required to the nodes. >=20 >=20 > to the nodes that are segments and to the nodes that are TI-LFA PLR = (point of local repair). This does not mean =E2=80=9Call nodes=E2=80=9D = in the network. >=20 >=20 >> I think it would be obvious. So my second question here is that: do = we really need to put additional outer IPv6 header just to place the SRH = for TI-LFA even all the nodes are fully SRv6 capable nodes which are = able to insert SRH to the packets. >=20 >=20 > that is an excellent question. >=20 > No, you don=E2=80=99t need an outer encapsulation and in many (if not = most) of the cases, the TI-LFA PLR node will not add an outer = encapsulation. >=20 > What we propose in draft-voyer-6man-extension-header-insertion is to = add an outer encapsulation at the ingress of the domain so that, when = the PLR node inserts an SRH, it does so under the outer IPv6 header that = has been added at ingress. Therefore, the insertion of the SRH happens = into a packet that has been sourced within the domain. >=20 > Thanks. > s. >=20 >=20 >>=20 >> Best regards, >> --satoru >>=20 >>=20 >>> 2017/04/04 17:51=E3=80=81Stefano Previdi (sprevidi) = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >>>=20 >>>=20 >>>> On Apr 4, 2017, at 10:38 AM, Satoru Matsushima = wrote: >>>>=20 >>>> Hello Mark, >>>>=20 >>>> Thank you, it looks very interesting discussion. I=E2=80=99d = clarify a bit to your following point: >>>>=20 >>>>> [...] >>>>=20 >>>>> Node 5 receives the packet, and as it is DA=3D5, decapsulates the = inner >>>>> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the = standard >>>>> IPv6 forwarding table, resulting in it being forwarded to Node 3, >>>>> which then forwards it to Node 9. All of this is happening using >>>>> conventional IPv6 destination based forwarding. >>>>=20 >>>> This behavior of node 5 assumes that there=E2=80=99s on-demand = virtual tunnel between node 2 and node 5 prior to the failure. Is that = correct? >>>=20 >>>=20 >>> this is part of TI-LFA (and more general fast re-rpoute) technology. >>>=20 >>> yes, the repair path is pre-computed in the form of a segment list. >>>=20 >>>=20 >>>>> Encapsulation is solving this problem by effectively creating a >>>>> on-demand virtual link or tunnel between Node 2 and Node 5, = getting >>>>> the original packet past the failure point to a point along the >>>>> original packet's forwarding path. Once there, it pops out of the >>>>> virtual link and is sent along its way. I don't think the = insertion of >>>>> the EH and DA swapping method could be described the same way or = could >>>>> be described as simply. >>>>=20 >>>> So that looks node 9 should define DA=3D9 semantics which the node = pops an outer header and then forward the payload to the inner IPv6 = destination based on the routing table. Basically an IP address of a = node represents the node itself and receiving packets will be punt to = the control-plane. So it seems that the node behavior doesn't work for = conventional nodes. >>>=20 >>>=20 >>> correct. Please read draft-filsfils-spring-srv6-network-programming = and you=E2=80=99ll see we defined an explicit behavior for that. >>>=20 >>> Suc behavior is signaled in the control plane of the infrastructure = (isis, ospf). See extensions described in = draft-bashandy-isis-srv6-extensions. >>>=20 >>>=20 >>>> To that behavior works, I think that it requires additional spec to = define such semantics and some control-plane to signal that semantics to = other node. >>>=20 >>>=20 >>> correct. See above. >>>=20 >>>=20 >>>> If I comment to that it would be a certain volume of load for = signaling and maintaining the states to the control-planes, even the = data-plane behavior can be kept in conventional. And it would also = require tunnel configurations to the all nodes in each node which I = don=E2=80=99t want to do in our operations. >>>=20 >>>=20 >>> good point, but I=E2=80=99m afraid you=E2=80=99re not familiar with = TI-LFA. There=E2=80=99s very little state to keep and there=E2=80=99s no = tunnel provisioning. This is traditional LFA/IPFRR. >>>=20 >>>=20 >>>> I have to admit my ignorant, but I=E2=80=99m really appreciate if = you let me know about that kind of on-demand tunneling technologies = without bunch of signaling to maintain states and configuration burdens. >>>=20 >>>=20 >>> draft-filsfils-spring-srv6-network-programming=20 >>> draft-bashandy-isis-srv6-extensions >>> RFC7855 >>> draft-ietf-spring-resiliency-use-case >>> draft-francois-rtgwg-segment-routing-ti-lfa >>>=20 >>> Keep in mind that LFA technologies have been deployed for a few = years already and TI-LFA is being deployed as we speak. >>>=20 >>> s. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Best regards, >>>> --satoru >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>=20 >>=20 >=20 From nobody Tue Apr 4 05:44:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBA712968F for ; Tue, 4 Apr 2017 05:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DoZrKAWI9Oaz for ; Tue, 4 Apr 2017 05:44:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0A1129680 for ; Tue, 4 Apr 2017 05:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11594; q=dns/txt; s=iport; t=1491309873; x=1492519473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EiHh0RzA3MRbLXvkQ/IMwTCO34eJYcVJkU3iAevaH9Y=; b=FYIOKI1jQxUvSzp/h2DAMmwixLWrz9hLdMYoZOeoRZZBxwHqRfBVkH7M pJLDOv2ho+am78IUcbkD6ewf6S2McM3Lbwr4zzZmwEXn2wIWbEicQEU1l st/0KRJFMt4Uehyry412FKwqKasM8zzF0WzXQl5bkHChqXnW7buQrwknE A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQDxlONY/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1yKEpFaiBqNOYIOHwuFeAIagyI/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASEROgsFCwIBBgIYAgImAgICHwYLFRACBA4FiXYDDQgOkCGdX?= =?us-ascii?q?IImhygNgyQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYFhgQmCUYIDF4J?= =?us-ascii?q?vLoIxBYkjjHeGGDsBjheEOIF9hS6DWYY4iniIfAEfOIEFWxVBEQGERx2BY3WID?= =?us-ascii?q?oENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="scan'208";a="226797018" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 12:44:32 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v34CiVq1005357 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 12:44:32 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 08:44:31 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 08:44:31 -0400 From: "Stefano Previdi (sprevidi)" To: Satoru Matsushima CC: Mark Smith , 6man WG Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Topic: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Thread-Index: AQHSrSR2/6qlUOSo0EqKciWm+qM526G0/wA/gABsKgA= Date: Tue, 4 Apr 2017 12:44:31 +0000 Message-ID: <78D0F97A-D7EC-41FD-AF6D-22E422DA67C3@cisco.com> References: <02ED9F8A-ECB2-4005-86A5-AFC1FB42AC6F@cisco.com> <7A6DA9C6-9668-4AA1-A28A-A11069EA2370@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.102.152] Content-Type: text/plain; charset="utf-8" Content-ID: <59033490F433374581FD97D81FE3C878@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:44:47 -0000 DQo+IE9uIEFwciA0LCAyMDE3LCBhdCAxMjoxNyBQTSwgU2F0b3J1IE1hdHN1c2hpbWEgPHNhdG9y dS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIZWxsbyBTdGVmYW5vLA0KPiAN Cj4gVGhhbmsgeW91IGZvciB0aGUgY2xlYXIgYW5zd2VyIHRvIG15IHF1ZXN0aW9ucy4gSSByZWFs bHkgYXBwcmVjaWF0ZSBpdC4NCj4gDQo+PiBObywgeW91IGRvbuKAmXQgbmVlZCBhbiBvdXRlciBl bmNhcHN1bGF0aW9uIGFuZCBpbiBtYW55IChpZiBub3QgbW9zdCkgb2YgdGhlIGNhc2VzLCB0aGUg VEktTEZBIFBMUiBub2RlIHdpbGwgbm90IGFkZCBhbiBvdXRlciBlbmNhcHN1bGF0aW9uLg0KPj4g DQo+PiBXaGF0IHdlIHByb3Bvc2UgaW4gZHJhZnQtdm95ZXItNm1hbi1leHRlbnNpb24taGVhZGVy LWluc2VydGlvbiBpcyB0byBhZGQgYW4gb3V0ZXIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgaW5ncmVz cyBvZiB0aGUgZG9tYWluIHNvIHRoYXQsIHdoZW4gdGhlIFBMUiBub2RlIGluc2VydHMgYW4gU1JI LCBpdCBkb2VzIHNvIHVuZGVyIHRoZSBvdXRlciBJUHY2IGhlYWRlciB0aGF0IGhhcyBiZWVuIGFk ZGVkIGF0IGluZ3Jlc3MuIFRoZXJlZm9yZSwgdGhlIGluc2VydGlvbiBvZiB0aGUgU1JIIGhhcHBl bnMgaW50byBhIHBhY2tldCB0aGF0IGhhcyBiZWVuIHNvdXJjZWQgd2l0aGluIHRoZSBkb21haW4u DQo+IA0KPiANCj4gSSB1bmRlcnN0YW5kIHRoYXQuIEFkZGluZyBvdXRlciBoZWFkZXIgYXQgdGhl IGluZ3Jlc3Mgb2YgdGhlIGRvbWFpbiBzZWVtcyBtYWtlIHNlbnNlIHRvIG1lIGJlY2F1c2UgdGhl IGluY29taW5nIHBhY2tldHMgdG8gdGhlIGRvbWFpbiBpbmNsdWRlIG5vdCBvbmx5IElQdjYsIGJ1 dCBhbHNvIElQdjQgb3IgTDIgZnJhbWVzLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgb25jZSB0 aGUgcGFja2V0cyBjb21lIGludG8gdGhlIGRvbWFpbiwgdGhlcmXigJlzIG5vIG5lZWQgdG8gcHV0 IGFkZGl0aW9uYWwgb3V0ZXIgSVB2NiBoZWFkZXIgb24gc29tZXdoZXJlIHdpdGhpbiB0aGUgZG9t YWluIHdoZW4gdGhlIHBhY2tldHMgbWVldCBUSS1MRkEgZm9yd2FyZGluZyBkdXJpbmcgYSBsaW5r IG9yIG5vZGUgZmFpbHVyZS4gQW5kIHRoZW4gdGhlIHB1c2hlZCBTUkggd2lsbCBiZSBwb3BwZWQg b3V0IGF0IHRoZSBNUCAoTWVyZ2UgUG9pbnQ/KSBvZiB0aGUgcHJvdGVjdGlvbiBwYXRoIHdpdGgg aW4gdGhlIGRvbWFpbi4NCg0KDQppdCBkb2VzbuKAmXQgbmVlZCB0by4NCg0KVGhlIGluc2VydGVk IFNSSCB3aWxsIGFueXdheSBiZSByZW1vdmVkIGF0IHRoZSBzYW1lIHRpbWUgdGhlIG91dGVyIGVu Y2Fwc3VsYXRpb24gaXMgcmVtb3ZlZCBieSB0aGUgZWdyZXNzIG5vZGUgb2YgdGhlIGRvbWFpbi4N Cg0KDQo+IEl0IGxvb2tzIHZlcnkgY2xlYXIgYW5kIGNsZWFuIGJlaGF2aW9yLCBhbmQgYWxzbyBt YWtlIHNlbnNlIHRvIG1lLiBUaGUgcHVzaGVkIFNSSCB3aWxsIGJlIGNvbmZpbmVkIHdpdGhpbiB0 aGUgc291cmNlIGRvbWFpbiBvZiB0aGUgU1JILA0KDQoNCmNvcnJlY3QuDQoNCg0KPiB3aGljaCBk b2VzIG5vIGltcGFjdCB0byB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUuIA0KDQoNCmNvcnJlY3Qu DQoNCg0KPiAgT2ggdGhhdCdzIHRoZSBzb3VyY2UgZG9tYWluIGNvbmNlcHQgeW91IG1lbnRpb25l ZC4gSXMgdGhhdCBjb3JyZWN0Pw0KDQoNCnllcywgdGhhdCBpcyBjb3JyZWN0Lg0KDQpUaGFua3Mu DQpzLg0KDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gLS1zYXRvcnUNCj4gDQo+IA0KPj4gMjAx Ny8wNC8wNCAxODo0MeOAgVN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIDxzcHJldmlkaUBjaXNj by5jb20+IOOBruODoeODvOODq++8mg0KPj4gDQo+PiANCj4+PiBPbiBBcHIgNCwgMjAxNywgYXQg MTE6MTggQU0sIFNhdG9ydSBNYXRzdXNoaW1hIDxzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+ IHdyb3RlOg0KPj4+IA0KPj4+IEhlbGxvIFN0ZWZhbm8sDQo+Pj4gDQo+Pj4gVGhhbmsgeW91IGZv ciBwb2ludGluZyB0aGUgcmVmZXJlbmNlcyBpbiB5b3VyIHByb21wdCByZXNwb25zZS4gVGhhdCBz ZWVtcyBTUnY2IGNhbiBkZWZpbmUgYWxsIHRoZSBmb3J3YXJkaW5nIHNlbWFudGljcyB0byBzdXBw b3J0IFRJLUxGQSwgYSBmYXN0IHByb3RlY3Rpb24gdGVjaG5vbG9neSB3aXRob3V0IHNpZ25hbGlu ZyBhbmQgY29uZmlndXJhdGlvbiBidXJkZW5zLiBTbyBteSBxdWVzdGlvbiBoZXJlIGlzIGRvIHlv dSB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBhY2hpZXZlIHRoYXQgd2l0aCB3aGV0aGVyIHB1cmVs eSBJUHY2LWluLUlQdjYgdHVubmVsaW5nIHdpdGhvdXQgdGhlIGJ1cmRlbnMgc2FtZSBhcyBTUnY2 Lg0KPj4gDQo+PiANCj4+IFRJLUxGQSBhcyBhbnkgb3RoZXIgdHJhZmZpYyBlbmdpbmVlcmluZyBh bmQvb3IgZmFzdC1yZXJvdXRlIHRlY2hub2xvZ3ksIHVzZXMgdGhlIGNvbmNlcHQgb2YgYSBzb3Vy Y2Ugcm91dGVkIHBhdGguDQo+PiANCj4+IFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvIGV4cHJl c3MgYSBzb3VyY2Ugcm91dGVkIHBhdGguDQo+PiANCj4+IEluZGVlZCB5b3UgY291bGQgZXhwcmVz cyBhIHBhdGggYnkgc3RhY2tpbmcgaXB2NiBoZWFkZXJzIG9uIG9uIHRvcCBvZiBlYWNoIG90aGVy LiBUaGlzIG9wdGlvbiBpcyBjbGVhcmx5IHVucHJhY3RpY2FsLCBpbmVmZmljaWVudCBhbmQgbm9u LXNjYWxhYmxlLg0KPj4gDQo+PiBUaGUgYmVzdCBhcHByb2FjaCBpcyB0byBleHByZXNzIGEgc291 cmNlIHJvdXRlZCBwYXRoIHdpdGggdGhlIHJpZ2h0IHRvb2w6IHRoZSByb3V0aW5nIGhlYWRlciwg YW5kIG1vcmUgcHJlY2lzZWx5IHRoZSBzZWdtZW50IHJvdXRpbmcgaGVhZGVyIChTUkgpLg0KPj4g DQo+PiANCj4+PiBBcyBNYXJrIHNhaWQsIGlmIGl0IGlzIHBvc3NpYmxlIHdpdGggSVB2Ni1pbi1J UHY2IHR1bm5lbGluZyBvbmx5LCB3aGF0IGVsc2UgcmVxdWlyZWQgdG8gZG8gdGhhdCBzZWVtcyB0 byBtZSBpcyBidW5jaCBvZiBzaWduYWxpbmcgYW5kIGNvbmZpZ3VyYXRpb24gYnVyZGVucy4NCj4+ IA0KPj4gDQo+PiBJIHRoaW5rIGV2ZXJ5b25lIGluIHRoZSBpbmR1c3RyeSBhZ3JlZXMgdGhhdCBz dGFja2luZyBpcHY2IGhlYWRlcnMgYXMgYSBzb3VyY2Ugcm91dGluZyB0ZWNobmlxdWUgaXMgcmVh bGx5IHVucHJhY3RpY2FsIGFuZCBpdOKAmXMgcmVhbGx5IGEgcG9vciBjaG9pY2UgY29tcGFyZWQg dG8gdGhlIGV4Y2VsbGVudCB0b29sIHdlIGhhdmUgd2l0aCBleHRlbnNpb25zIGhlYWRlcnMuDQo+ PiANCj4+IEkgaGF2ZSBub3RoaW5nIGFnYWluc3QgYmljeWNsZXMsIGJ1dCBJZiBJIGhhdmUgdG8g dHJhbnNwb3J0IGZyZWlnaHQsIEkgY2xlYXJseSBwcmVmZXIgYSB0cnVjay4uLg0KPj4gDQo+PiAN Cj4+PiBJZiBTUnY2IGlzIGEgZ29vZCBjaG9pY2UsIG9yIG9ubHkgY2hvaWNlIGZvciB0aGF0IHdp dGhvdXQgdGhlIGJ1cmRlbnMsIFNSSCBwcm9jZXNzaW5nIGNhcGFiaWxpdHkgbXVzdCBiZSByZXF1 aXJlZCB0byB0aGUgbm9kZXMuDQo+PiANCj4+IA0KPj4gdG8gdGhlIG5vZGVzIHRoYXQgYXJlIHNl Z21lbnRzIGFuZCB0byB0aGUgbm9kZXMgdGhhdCBhcmUgVEktTEZBIFBMUiAocG9pbnQgb2YgbG9j YWwgcmVwYWlyKS4gVGhpcyBkb2VzIG5vdCBtZWFuIOKAnGFsbCBub2Rlc+KAnSBpbiB0aGUgbmV0 d29yay4NCj4+IA0KPj4gDQo+Pj4gSSB0aGluayBpdCB3b3VsZCBiZSBvYnZpb3VzLiBTbyBteSBz ZWNvbmQgcXVlc3Rpb24gaGVyZSBpcyB0aGF0OiBkbyB3ZSByZWFsbHkgbmVlZCB0byBwdXQgYWRk aXRpb25hbCBvdXRlciBJUHY2IGhlYWRlciBqdXN0IHRvIHBsYWNlIHRoZSBTUkggZm9yIFRJLUxG QSBldmVuIGFsbCB0aGUgbm9kZXMgYXJlIGZ1bGx5IFNSdjYgY2FwYWJsZSBub2RlcyB3aGljaCBh cmUgYWJsZSB0byBpbnNlcnQgU1JIIHRvIHRoZSBwYWNrZXRzLg0KPj4gDQo+PiANCj4+IHRoYXQg aXMgYW4gZXhjZWxsZW50IHF1ZXN0aW9uLg0KPj4gDQo+PiBObywgeW91IGRvbuKAmXQgbmVlZCBh biBvdXRlciBlbmNhcHN1bGF0aW9uIGFuZCBpbiBtYW55IChpZiBub3QgbW9zdCkgb2YgdGhlIGNh c2VzLCB0aGUgVEktTEZBIFBMUiBub2RlIHdpbGwgbm90IGFkZCBhbiBvdXRlciBlbmNhcHN1bGF0 aW9uLg0KPj4gDQo+PiBXaGF0IHdlIHByb3Bvc2UgaW4gZHJhZnQtdm95ZXItNm1hbi1leHRlbnNp b24taGVhZGVyLWluc2VydGlvbiBpcyB0byBhZGQgYW4gb3V0ZXIgZW5jYXBzdWxhdGlvbiBhdCB0 aGUgaW5ncmVzcyBvZiB0aGUgZG9tYWluIHNvIHRoYXQsIHdoZW4gdGhlIFBMUiBub2RlIGluc2Vy dHMgYW4gU1JILCBpdCBkb2VzIHNvIHVuZGVyIHRoZSBvdXRlciBJUHY2IGhlYWRlciB0aGF0IGhh cyBiZWVuIGFkZGVkIGF0IGluZ3Jlc3MuIFRoZXJlZm9yZSwgdGhlIGluc2VydGlvbiBvZiB0aGUg U1JIIGhhcHBlbnMgaW50byBhIHBhY2tldCB0aGF0IGhhcyBiZWVuIHNvdXJjZWQgd2l0aGluIHRo ZSBkb21haW4uDQo+PiANCj4+IFRoYW5rcy4NCj4+IHMuDQo+PiANCj4+IA0KPj4+IA0KPj4+IEJl c3QgcmVnYXJkcywNCj4+PiAtLXNhdG9ydQ0KPj4+IA0KPj4+IA0KPj4+PiAyMDE3LzA0LzA0IDE3 OjUx44CBU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgPHNwcmV2aWRpQGNpc2NvLmNvbT4g44Gu 44Oh44O844Or77yaDQo+Pj4+IA0KPj4+PiANCj4+Pj4+IE9uIEFwciA0LCAyMDE3LCBhdCAxMDoz OCBBTSwgU2F0b3J1IE1hdHN1c2hpbWEgPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbT4gd3Jv dGU6DQo+Pj4+PiANCj4+Pj4+IEhlbGxvIE1hcmssDQo+Pj4+PiANCj4+Pj4+IFRoYW5rIHlvdSwg aXQgbG9va3MgdmVyeSBpbnRlcmVzdGluZyBkaXNjdXNzaW9uLiBJ4oCZZCBjbGFyaWZ5IGEgYml0 IHRvIHlvdXIgZm9sbG93aW5nIHBvaW50Og0KPj4+Pj4gDQo+Pj4+Pj4gWy4uLl0NCj4+Pj4+IA0K Pj4+Pj4+IE5vZGUgNSByZWNlaXZlcyB0aGUgcGFja2V0LCBhbmQgYXMgaXQgaXMgREE9NSwgZGVj YXBzdWxhdGVzIHRoZSBpbm5lcg0KPj4+Pj4+IFNBPTEsIERBPTkgcGFja2V0LiBOb2RlIDUgdGhl biBzdWJtaXRzIHRoYXQgcGFja2V0IHRvIHRoZSBzdGFuZGFyZA0KPj4+Pj4+IElQdjYgZm9yd2Fy ZGluZyB0YWJsZSwgcmVzdWx0aW5nIGluIGl0IGJlaW5nIGZvcndhcmRlZCB0byBOb2RlIDMsDQo+ Pj4+Pj4gd2hpY2ggdGhlbiBmb3J3YXJkcyBpdCB0byBOb2RlIDkuIEFsbCBvZiB0aGlzIGlzIGhh cHBlbmluZyB1c2luZw0KPj4+Pj4+IGNvbnZlbnRpb25hbCBJUHY2IGRlc3RpbmF0aW9uIGJhc2Vk IGZvcndhcmRpbmcuDQo+Pj4+PiANCj4+Pj4+IFRoaXMgYmVoYXZpb3Igb2Ygbm9kZSA1IGFzc3Vt ZXMgdGhhdCB0aGVyZeKAmXMgb24tZGVtYW5kIHZpcnR1YWwgdHVubmVsIGJldHdlZW4gbm9kZSAy IGFuZCBub2RlIDUgcHJpb3IgdG8gdGhlIGZhaWx1cmUuIElzIHRoYXQgY29ycmVjdD8NCj4+Pj4g DQo+Pj4+IA0KPj4+PiB0aGlzIGlzIHBhcnQgb2YgVEktTEZBIChhbmQgbW9yZSBnZW5lcmFsIGZh c3QgcmUtcnBvdXRlKSB0ZWNobm9sb2d5Lg0KPj4+PiANCj4+Pj4geWVzLCB0aGUgcmVwYWlyIHBh dGggaXMgcHJlLWNvbXB1dGVkIGluIHRoZSBmb3JtIG9mIGEgc2VnbWVudCBsaXN0Lg0KPj4+PiAN Cj4+Pj4gDQo+Pj4+Pj4gRW5jYXBzdWxhdGlvbiBpcyBzb2x2aW5nIHRoaXMgcHJvYmxlbSBieSBl ZmZlY3RpdmVseSBjcmVhdGluZyBhDQo+Pj4+Pj4gb24tZGVtYW5kIHZpcnR1YWwgbGluayBvciB0 dW5uZWwgYmV0d2VlbiBOb2RlIDIgYW5kIE5vZGUgNSwgZ2V0dGluZw0KPj4+Pj4+IHRoZSBvcmln aW5hbCBwYWNrZXQgcGFzdCB0aGUgZmFpbHVyZSBwb2ludCB0byBhIHBvaW50IGFsb25nIHRoZQ0K Pj4+Pj4+IG9yaWdpbmFsIHBhY2tldCdzIGZvcndhcmRpbmcgcGF0aC4gT25jZSB0aGVyZSwgaXQg cG9wcyBvdXQgb2YgdGhlDQo+Pj4+Pj4gdmlydHVhbCBsaW5rIGFuZCBpcyBzZW50IGFsb25nIGl0 cyB3YXkuIEkgZG9uJ3QgdGhpbmsgdGhlIGluc2VydGlvbiBvZg0KPj4+Pj4+IHRoZSBFSCBhbmQg REEgc3dhcHBpbmcgbWV0aG9kIGNvdWxkIGJlIGRlc2NyaWJlZCB0aGUgc2FtZSB3YXkgb3IgY291 bGQNCj4+Pj4+PiBiZSBkZXNjcmliZWQgYXMgc2ltcGx5Lg0KPj4+Pj4gDQo+Pj4+PiBTbyB0aGF0 IGxvb2tzIG5vZGUgOSBzaG91bGQgZGVmaW5lIERBPTkgc2VtYW50aWNzIHdoaWNoIHRoZSBub2Rl IHBvcHMgYW4gb3V0ZXIgaGVhZGVyIGFuZCB0aGVuIGZvcndhcmQgdGhlIHBheWxvYWQgdG8gdGhl IGlubmVyIElQdjYgZGVzdGluYXRpb24gYmFzZWQgb24gdGhlIHJvdXRpbmcgdGFibGUuIEJhc2lj YWxseSBhbiBJUCBhZGRyZXNzIG9mIGEgbm9kZSByZXByZXNlbnRzIHRoZSBub2RlIGl0c2VsZiBh bmQgcmVjZWl2aW5nIHBhY2tldHMgd2lsbCBiZSBwdW50IHRvIHRoZSBjb250cm9sLXBsYW5lLiBT byBpdCBzZWVtcyB0aGF0IHRoZSBub2RlIGJlaGF2aW9yIGRvZXNuJ3Qgd29yayBmb3IgY29udmVu dGlvbmFsIG5vZGVzLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IGNvcnJlY3QuIFBsZWFzZSByZWFkIGRy YWZ0LWZpbHNmaWxzLXNwcmluZy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcgYW5kIHlvdeKAmWxs IHNlZSB3ZSBkZWZpbmVkIGFuIGV4cGxpY2l0IGJlaGF2aW9yIGZvciB0aGF0Lg0KPj4+PiANCj4+ Pj4gU3VjIGJlaGF2aW9yIGlzIHNpZ25hbGVkIGluIHRoZSBjb250cm9sIHBsYW5lIG9mIHRoZSBp bmZyYXN0cnVjdHVyZSAoaXNpcywgb3NwZikuIFNlZSBleHRlbnNpb25zIGRlc2NyaWJlZCBpbiBk cmFmdC1iYXNoYW5keS1pc2lzLXNydjYtZXh0ZW5zaW9ucy4NCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4g VG8gdGhhdCBiZWhhdmlvciB3b3JrcywgSSB0aGluayB0aGF0IGl0IHJlcXVpcmVzIGFkZGl0aW9u YWwgc3BlYyB0byBkZWZpbmUgc3VjaCBzZW1hbnRpY3MgYW5kIHNvbWUgY29udHJvbC1wbGFuZSB0 byBzaWduYWwgdGhhdCBzZW1hbnRpY3MgdG8gb3RoZXIgbm9kZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+ PiBjb3JyZWN0LiBTZWUgYWJvdmUuDQo+Pj4+IA0KPj4+PiANCj4+Pj4+IElmIEkgY29tbWVudCB0 byB0aGF0IGl0IHdvdWxkIGJlIGEgY2VydGFpbiB2b2x1bWUgb2YgbG9hZCBmb3Igc2lnbmFsaW5n IGFuZCBtYWludGFpbmluZyB0aGUgc3RhdGVzIHRvIHRoZSBjb250cm9sLXBsYW5lcywgZXZlbiB0 aGUgZGF0YS1wbGFuZSBiZWhhdmlvciBjYW4gYmUga2VwdCBpbiBjb252ZW50aW9uYWwuIEFuZCBp dCB3b3VsZCBhbHNvIHJlcXVpcmUgdHVubmVsIGNvbmZpZ3VyYXRpb25zIHRvIHRoZSBhbGwgbm9k ZXMgaW4gZWFjaCBub2RlIHdoaWNoIEkgZG9u4oCZdCB3YW50IHRvIGRvIGluIG91ciBvcGVyYXRp b25zLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IGdvb2QgcG9pbnQsIGJ1dCBJ4oCZbSBhZnJhaWQgeW91 4oCZcmUgbm90IGZhbWlsaWFyIHdpdGggVEktTEZBLiBUaGVyZeKAmXMgdmVyeSBsaXR0bGUgc3Rh dGUgdG8ga2VlcCBhbmQgdGhlcmXigJlzIG5vIHR1bm5lbCBwcm92aXNpb25pbmcuIFRoaXMgaXMg dHJhZGl0aW9uYWwgTEZBL0lQRlJSLg0KPj4+PiANCj4+Pj4gDQo+Pj4+PiBJIGhhdmUgdG8gYWRt aXQgbXkgaWdub3JhbnQsIGJ1dCBJ4oCZbSByZWFsbHkgYXBwcmVjaWF0ZSBpZiB5b3UgbGV0IG1l IGtub3cgYWJvdXQgdGhhdCBraW5kIG9mIG9uLWRlbWFuZCB0dW5uZWxpbmcgdGVjaG5vbG9naWVz IHdpdGhvdXQgYnVuY2ggb2Ygc2lnbmFsaW5nIHRvIG1haW50YWluIHN0YXRlcyBhbmQgY29uZmln dXJhdGlvbiBidXJkZW5zLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IGRyYWZ0LWZpbHNmaWxzLXNwcmlu Zy1zcnY2LW5ldHdvcmstcHJvZ3JhbW1pbmcgDQo+Pj4+IGRyYWZ0LWJhc2hhbmR5LWlzaXMtc3J2 Ni1leHRlbnNpb25zDQo+Pj4+IFJGQzc4NTUNCj4+Pj4gZHJhZnQtaWV0Zi1zcHJpbmctcmVzaWxp ZW5jeS11c2UtY2FzZQ0KPj4+PiBkcmFmdC1mcmFuY29pcy1ydGd3Zy1zZWdtZW50LXJvdXRpbmct dGktbGZhDQo+Pj4+IA0KPj4+PiBLZWVwIGluIG1pbmQgdGhhdCBMRkEgdGVjaG5vbG9naWVzIGhh dmUgYmVlbiBkZXBsb3llZCBmb3IgYSBmZXcgeWVhcnMgYWxyZWFkeSBhbmQgVEktTEZBIGlzIGJl aW5nIGRlcGxveWVkIGFzIHdlIHNwZWFrLg0KPj4+PiANCj4+Pj4gcy4NCj4+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+Pj4gLS1zYXRvcnUNCj4+Pj4+ IA0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KPj4+Pj4gaXB2NkBpZXRmLm9yZw0KPj4+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVz dHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+Pj4gDQo+Pj4gDQo+PiANCj4gDQoNCg== From nobody Tue Apr 4 05:57:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D795126BF7; Tue, 4 Apr 2017 05:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 7HSAmAxS_ZtP; Tue, 4 Apr 2017 05:57:24 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 B8C6F1272E1; Tue, 4 Apr 2017 05:57:24 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id f84so14941858ioj.0; Tue, 04 Apr 2017 05:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WWQfwUJPwpAcRz1apkb40APl7+n7NxiBjuS1xaIv7Zk=; b=Ko4fK2GIT8ecN+8U73CW71DXbd6jp4zQ0iPbmNwWzBlhxEEPksAGdazIc+Myjyn6D4 NSyYGYxj3Y6H/De2+AboUWGhdapulwOrbYZPWxiIEKsMOl1Zc2R2a9OXiocsBwHXosaf te2lpEda+qV3X352bfWlCQqjrO41Qd4HFEkUS0T+dHlA8SN95zsGWgCa0EzcVXD1xs7r 38Mltg2Pof7VDfH/1lNugA9ZNs2eOK/Qd6QDji3YAMa89itgctvwxn4lwLj5chQwNNxF TysBQUcNShltS43AAWLqSkgh0c8Xrn9IynAqTljAMn1jdFDpWCVCTS9XYeqJONympDPk 0ofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=WWQfwUJPwpAcRz1apkb40APl7+n7NxiBjuS1xaIv7Zk=; b=TD4S/igOZ1kp2UYCbtpDvc/aLIRzhbgHQOZtpTnTW1OIQJYIqV4FecHjuSiH5MmAnM 79Av2FsmRAL0IwB/K5fTTdzwwS69u1ND3XdcGX7zfCqXjobv3Tj0tf63+4ULaRlToKkU TkOYUS2/wuwaIVVriG56oTSmFaiZINM2900/LePvvn63irLg46MgswbX2mnjUlsP6Pze S3dDIOz/EDYNOrr8a7uimqi8Qce3T7++yCAUNUd9FcHrCEttsSjhNZ+C4C1Dxaz9+jHV pmo+1nqcQsdDJ1nh2+TSA5ZFQj0ezgLCn0kxBgNgdZ3Z2yxizxEvsydmq/U5IynSfhLC kpOg== X-Gm-Message-State: AFeK/H21SP4Z2kdP45Pl8McmYHbbTWJNBCa0xY6BGgAA/jy6GOaJJLkK67bXncgHo0yieg== X-Received: by 10.107.174.27 with SMTP id x27mr21260900ioe.35.1491310643940; Tue, 04 Apr 2017 05:57:23 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id v187sm8627663ith.18.2017.04.04.05.57.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 05:57:23 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Robert Raszuk , Fernando Gont References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> Cc: "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 5 Apr 2017 00:57:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:57:26 -0000 On 04/04/2017 18:12, Robert Raszuk wrote: > Hi Fernando, > > The WG document talks about two cases ... > > * EH insertion at the host (src of packet) > > * IPv6 new encapsulation + EH insertion on the ingress to SR domain > followed by decapsulation at the egress of SR domain. > > I hope we can agree on that. We can't, because neither of them is "insertion". They are simply packets created at their source (the encapsulator) that happen to contain SR headers, or any other kind of IPv6 extension header for that matter. > However is it wise to expect any time within SR domain for a packet (v6 > encapsulated on ingress) to get steered differently (say coming out of > service chain) to decapsulate and encapsulate again ? Seems to me like > quite local box decision anyway. Yes, they can decapsulate and re-encapsulate as often as they like and remain consistent with 2460bis. > Hence my comment about implicit insertion. > > In any case if we see this entire thread the only technical concern with EH > insertion was MTU. And how that issue is solved when you do additional IPv6 > header encap ? PMTUD applies to the path between source A (encapsulator) and destination B (decapsulator). If you decapsulate at B and the encapsulate again, PMTUD applies to the path between B (encapsulator) and C (decapsulator). They are completely independent; it's a new packet. PMTUD doesn't occur between A and C at all. Brian > > Or maybe encap is allowed simply as it can not be forbidden :)) > > Cheers, > Robert. > > > On Tue, Apr 4, 2017 at 1:15 AM, Fernando Gont wrote: > >> On 03/31/2017 04:11 PM, Robert Raszuk wrote: >>> I do not understand how 2460bis makes it "easier" if proposed change to >>> the text directly tries to prohibit what is described in a document >>> already long time back accepted as a 6man working group draft. >> >> This is incorrect. For instance, the condition to accepting such I-D as >> a wg items was indeed that EH insertion was removed, and that >> encapsulation be used instead. >> >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> > From nobody Tue Apr 4 06:22:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0155129574; Tue, 4 Apr 2017 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SsRXSgF1wxDH; Tue, 4 Apr 2017 06:22:34 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 74E28127BA3; Tue, 4 Apr 2017 06:22:34 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id b140so95204517iof.1; Tue, 04 Apr 2017 06:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Qw4cyhUsyuBzjahzoNrzCFKLxnM9UwLM4k4KhcpIWl0=; b=OPE64tGqzV8S70Hi92AS3AHS2OLT5l0dj2k5YTIffK/oZ0qyeI+c2BfeIL0nK//qma QnOR4jik95172jBG6g9Uk+djP1kJxyNsFmlAoZsVbSvD/FaNQbFx9QdPWXF0KAwqCdAu 9FQ1rB+nKOI3/6UXAsbZin6GalA5rBzSm35UlDcMAGUmYYdYJsc2+PZWdWfMsK4UZf1K d30ezUbIWziPB+Y3JX/axcChDjnkF5QD8Th8aqYOvq7NHKwN1j+UW7xOVEVZnSqmFnfH Y24RrG9H8nNQbHZgvm2M6A682ThitsJOGaGfzOumW2j6gZUg6PUHGStvw6eMB6pbgmvV xqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Qw4cyhUsyuBzjahzoNrzCFKLxnM9UwLM4k4KhcpIWl0=; b=mK7gSt9mYGEeHpae7Z9va+WLbQM1od77mcDIRyfgkxHyqfBPr9mrz1bIj0d2A90d+/ 76jQqZd+V32zxrj38TkzTSaB6m6rBj8BCcOJk3Emzapkwejm/caUvOVAN47UMTiqyWWy XNFWUn0NmwCttgr1j8oacF0sI0rFXTZdZRC/wXapAab8OgPfx2pM37BTjPs2jL1W7F8x mZYNAyIoYASTlbJy2wtKxqirPRwQ2AmG8chvKu6d4x+zII4v3rOrYikkmSm0SffsYeGP 1d9hv1Otwa2dqSJZLTr+t9KdRJPhIrlx37uUOCYzwRoC7nC/jxlZHH/NmGm74CU8xwVO DJMA== X-Gm-Message-State: AFeK/H2cmtDLaUXzD6q5dvFVdqibpvzRn0h4QHKH+qiGvdLRxfFNNENNO2ycSQQSdJRR9tx3av8X2+oxblbZIA== X-Received: by 10.107.16.217 with SMTP id 86mr22120729ioq.228.1491312153820; Tue, 04 Apr 2017 06:22:33 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Tue, 4 Apr 2017 06:22:32 -0700 (PDT) In-Reply-To: References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> From: Robert Raszuk Date: Tue, 4 Apr 2017 15:22:32 +0200 X-Google-Sender-Auth: 0rzdkcIfF7pHL8czRE0jvWMHiO0 Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Brian E Carpenter Cc: Fernando Gont , "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" Content-Type: multipart/alternative; boundary=001a113ecee82da7fc054c572bef Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:22:37 -0000 --001a113ecee82da7fc054c572bef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, > In any case if we see this entire thread the only technical concern with > EH > > insertion was MTU. And how that issue is solved when you do additional > IPv6 > > header encap ? > > PMTUD applies to the path between source A (encapsulator) and destination= B > (decapsulator). If you decapsulate at B and the encapsulate again, PMTUD > applies to the path between B (encapsulator) and C (decapsulator). They a= re > completely independent; it's a new packet. PMTUD doesn't occur between A > and C at all. > =E2=80=8BAre you saying that it is "legal" to fragment IPv6 packet by a rou= ter at the encapsulation point in the network ? That would be news to me. Many thx, Robert. --001a113ecee82da7fc054c572bef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

<= /div>
> In any case if we see this entire thre= ad the only technical concern with EH
> insertion was MTU. And how that issue is solved when you do additional= IPv6
> header encap ?

PMTUD applies to the path between source A (encapsulator) and destin= ation B
(decapsulator). If you decapsulate at B and the encapsulate again, PMTUD applies to the path between B (encapsulator) and C (decapsulator). They are=
completely independent; it's a new packet. PMTUD doesn't occur betw= een A
and C at all.


=E2=80=8BAre you saying that it is "legal" to fragment I= Pv6 packet by a router at the encapsulation point in the network ?=C2=A0

That would be news to me= .=C2=A0

Many thx,
Robert.

--001a113ecee82da7fc054c572bef-- From nobody Tue Apr 4 06:37:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5FC127599; Tue, 4 Apr 2017 06:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 aNKDZwr5qnz5; Tue, 4 Apr 2017 06:36:57 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 C7A1E127342; Tue, 4 Apr 2017 06:36:55 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id n76so15034793ioe.1; Tue, 04 Apr 2017 06:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bUPVykfyFdCqBRXvqE4Nuor2LA7ZNf9hFPB9foDs0GY=; b=SC0R6/eT5Q7TddBgVKW3IlbU656R2831Cc0QLiWli9NZqt9M+AxkdtSDqyYFLDDiiU VNczL1O50erfYq1jqylUwVDYprmzFmdLlMj7FlFElUV4A0prgDagXc/jUDP4rsRC5xIU NTrLd3LlCLQ86HlO4W8twZEYgNTwh0Haj+YvNHbLBJEblTP5UDJcchhUco/MYNEs5Qea s5X/7jBziSpzhTqXFyg4aV14mydk4y1nabd1Dhc8tdr9xCrZHSVQZ0xUqsj7KIOc4LEL x4HpCzU7l8Njwqgx7aejrHakJA67yjUSwBy3ZpSsejp2jSsrOQdsiZDKp3PQM88nDDAE uE3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=bUPVykfyFdCqBRXvqE4Nuor2LA7ZNf9hFPB9foDs0GY=; b=hQneZ8ZZ8pPlJQdQA9xE5tRADDY7x/eN0eXlQsGl9oouy1V8w242VPO4As8hdgyCBy /28ShvxE6DK9thuuSa/5xvak0KnYoKmgfxpsfwZK9zWt3FpTieuAFIscHBqg8dFQYBBi 1M8aBrJuRCosgweRY5IudP5JvDImZpb5fszpszhpjEdgWMKMm7ZYJ1cxXs1mC+yypAmT 0VMCtaWwUKk9FlH10M3Y+9BCulNL8JE/pkfveBhdxXh69a4SFfnzuH+tA2p9qGtPcjZI 5qbOKgkSAR4uyTGD1mHEULwPSIq3+vjDbFyQCek8+qqTBB3BYiDMUF6vXzoJHJhRCETM hgEg== X-Gm-Message-State: AFeK/H3/X4YiSuUBRXVrVHA79m8jG672T9nU5tc66aCMOJ4y255W9i6zomhy+REt95QgcA== X-Received: by 10.107.62.68 with SMTP id l65mr24996480ioa.213.1491313014869; Tue, 04 Apr 2017 06:36:54 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m77sm7240562ita.16.2017.04.04.06.36.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:36:54 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Robert Raszuk References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> Cc: Fernando Gont , "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: <0a74d9a6-24d3-ea00-07f2-61144f7725a4@gmail.com> Date: Wed, 5 Apr 2017 01:36:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:36:59 -0000 On 05/04/2017 01:22, Robert Raszuk wrote: > Hi Brian, >=20 >> In any case if we see this entire thread the only technical concern wi= th >> EH >>> insertion was MTU. And how that issue is solved when you do additiona= l >> IPv6 >>> header encap ? >> >> PMTUD applies to the path between source A (encapsulator) and destinat= ion B >> (decapsulator). If you decapsulate at B and the encapsulate again, PMT= UD >> applies to the path between B (encapsulator) and C (decapsulator). The= y are >> completely independent; it's a new packet. PMTUD doesn't occur between= A >> and C at all. >> >=20 >=20 > =E2=80=8BAre you saying that it is "legal" to fragment IPv6 packet by a= router at > the encapsulation point in the network ? I can't see any reason why the encapsulating packet couldn't be fragmente= d; it's just a packet (whose payload happens to be another packet). But I wo= uld hope that jumbo frames would make this unnecessary in the scenarios where= SR will be used. Also, assuming 2460bis is on its way through the IESG and RFC Editor soon= , I can't see any reason why draft-ietf-6man-segment-routing-header-06 couldn't proceed to WG Last Call. I'm not quite sure why we're having thi= s conversation. Brian From nobody Tue Apr 4 06:43:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0221296B3 for ; Tue, 4 Apr 2017 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 XUxBIjRpGHwX for ; Tue, 4 Apr 2017 06:43:38 -0700 (PDT) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::242]) (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 48D1A1296A3 for ; Tue, 4 Apr 2017 06:43:29 -0700 (PDT) Received: by mail-yb0-x242.google.com with SMTP id l201so6448868ybf.3 for ; Tue, 04 Apr 2017 06:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=6bZTP57y5nauTEa2zeXpIJ/O3cZ/0Ond2+JZsGNnkUs=; b=JcSGDsb7pFNcox7jy9JhXWttDtEmINeCygwJe3IzqUO93+HsyzZzN/wvKggiPS5US7 1dygxPDVgbiQ7NdZIX9mP0B5Jpyi0js+23NICcCLsZbVWZntUHapqNbY4/1ROJs19Var gJB1gJ/8VCeFaePalQjdeD7eUFzRpd0+afXmXjtVpl8lbmlyZKoISam1lV1YTlzTvBgv DlVjp9N/ZlZ/JyA4TycM/WGa3dOxUSKoedIgH6B9Rx/Y6QyosUgR6D4gpYqbDtrEiJwK qGmKK8hkHqdspftZfhPXuOqWgGnki/ZER3LE8IIlJgXJ3vVGEvJQTLRUEvDHUWYUlGe0 nFyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=6bZTP57y5nauTEa2zeXpIJ/O3cZ/0Ond2+JZsGNnkUs=; b=eeddkZoaUrF21dXgEg8YawwNXhiNO6pLkTb0o8elt63UsRdmYI4Sp2xMR/aH8alCS9 gSuTksoUnZ7S/iehbWjK8HxGIq+EK1P2hC1bpfztuZXH2REuWcamBHO3OrkVExd1rYdZ IZEoJKW4idbCDYGpeYzixeoHMWcSWxTau9Nu/lmhiZu48ciOQ8LFiFuEcfTfI+tSDQbs bp1dxIsK1I3AGx9z5UN2JRUnjrQ5lHL3ifJM51yqouAoIkwZLicMUb2LNV/7PAnORsqz iflXV2OIoNy5I/vFy28LhfTwXRTrBYFgVlZK9DvC99YG+50s+656nyzxAebSiLd/tbfs JipQ== X-Gm-Message-State: AFeK/H02PSA+JzJLVopGzmy9wp7Tw7cQ/9c/xWTq+E3OnIdXYTqwCHXDdDVdsS8Vu8DuAw== X-Received: by 10.37.220.2 with SMTP id y2mr13571062ybe.16.1491313408359; Tue, 04 Apr 2017 06:43:28 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id t3sm8068012ywe.19.2017.04.04.06.43.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:43:27 -0700 (PDT) To: 6man From: Brian E Carpenter Subject: Detail in draft-ietf-6man-segment-routing-header-06 Organization: University of Auckland Message-ID: Date: Wed, 5 Apr 2017 01:43:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:43:41 -0000 Hi, Unless I've missed it, draft-ietf-6man-segment-routing-header-06 doesn't actually specify the encapsulation mechanism mentioned in section 5.1 and elsewhere. Will it simply be IPv6-in-IPv6 using header type 41 [RFC2473]? Regards Brian Carpenter From nobody Tue Apr 4 06:49:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989AF1288B8 for ; Tue, 4 Apr 2017 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 hsui0tpmqmbK for ; Tue, 4 Apr 2017 06:49:18 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0991294D4 for ; Tue, 4 Apr 2017 06:49:11 -0700 (PDT) Received: from [10.0.0.11] (pD9F10B87.dip0.t-ipconnect.de [217.241.11.135]) by mx.zohomail.com with SMTPS id 1491313746229777.143100584819; Tue, 4 Apr 2017 06:49:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_65E0C509-645E-4C95-91DB-AA996F67F903" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain From: Dirk Steinberg In-Reply-To: Date: Tue, 4 Apr 2017 15:49:02 +0200 Cc: 6man WG Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3259) X-ZohoMailClient: External X-ZohoMail: Z_218543755 SPT_1 Z_218543754 SPT_1 SLF_D Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:49:21 -0000 --Apple-Mail=_65E0C509-645E-4C95-91DB-AA996F67F903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 03.04.2017 um 22:34 schrieb Mark Smith : >=20 > On 31 Mar. 2017 01:34, "Dirk Steinberg" > wrote: >=20 > > Am 29.03.2017 um 22:08 schrieb Mark Smith >: > > > > On 30 March 2017 at 06:58, Mark Smith > wrote: > >> So having further about this, I have fundamental question that it > >> isn't answering. > >> > >> Why can't IPv6-in-IPv6 encapsulation be used for this? What is = missing > >> from IPv6 that "requires" that EH insertion is used instead of much > >> simpler, off-the-shelf encapsulation/decapsulation? > >> > >> > >> > >> For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH = is > >> needed at all in the "2. Source Domain and Packet Journey" example. > >> > >> When node 2 realises that the link between itself and 3 has failed, = it > >> encapsulates the original SA=3D1, DA=3D9 packet in a new IPv6 = header > >> ("tunnelling" it). The new IPv6 header has an SA=3D2, DA=3D5, and = is sent > >> towards node 4. > >> > >> Node 4 forwards the packet onto node 5 using conventional = destination > >> address based IPv6 forwarding. > >> > >> Node 5 receives the packet, and as it is DA=3D5, decapsulates the = inner > >> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the = standard > >> IPv6 forwarding table, resulting in it being forwarded to Node 3, > >> which then forwards it to Node 9. All of this is happening using > >> conventional IPv6 destination based forwarding. > >> > >> Encapsulation is solving this problem by effectively creating a > >> on-demand virtual link or tunnel between Node 2 and Node 5, getting > >> the original packet past the failure point to a point along the > >> original packet's forwarding path. Once there, it pops out of the > >> virtual link and is sent along its way. I don't think the insertion = of > >> the EH and DA swapping method could be described the same way or = could > >> be described as simply. > >> > >> I think this IP-in-IPv6 encapsulation solution to the above example = is > >> better because: > >> > >> - there is no need for an additional header of any type - the path > >> information is inherent in the DA of the outer IPv6 header when = sent > >> to node 5, and in the DA of the inner IPv6 packet (now "the = packet") > >> when being sent by node 5 to node 9. > > > > To clarify, what I mean by "no need for an additional header of any > > type" is no additional header beyond the IPv6 encapsulation header > > i.e. no SRH EH or similar between the outer and inner IPv6 packets. = It > > is the original IPv6 packet inside a vanilla IPv6 packet with the > > outer IPv6 packet=E2=80=99s next header field set to 41. >=20 > Following this logic of not using =E2=80=9Ean additional header of any = type=E2=80=9C leads to > the conclusion that for every entry in an SR policy represented by the > SID list of an SRH, you would instead use one more nested IPv6 > encapsulation header. >=20 > In the simple example of section 2 the TI-LFA policy only needs to = specify > one additional node, namely 5 (9 being the original destination), but > conceivably the backup policy could be more complex including 3, 4, 5, > or more SIDs. Would you really want to propose that the PLR should > impose, say 4 nested IPv6 encapsulation headers at the same time > while still claiming this to be simpler and/or more efficient? >=20 > Let=E2=80=99s face the reality: the cost of adding an IPv6 = encapsulation header > is fairly high and while doing this once may be acceptable in certain = situations > doing this N times nested is prohibitive both in terms of the burden = on the > forwarding hardware and in terms of MTU growth. One more entry in > the SID list is just so much more efficient. >=20 > That is ignoring the complexity and cost of processing introduced at = each hop.=20 >=20 > The current (and decades old) IPv6 forwarding model involves = hop-by-hop destination address matching and hop-by-hop link-layer = endcap/decap to get the packet to its destination. >=20 > MPLS too follows this model. Labels aren't inserted into the IPv6 = packet, they're added to the outside of it. >=20 > EH insertion is fundamentally changing this forwarding model, because = forwarding devices have to do more complicated processing of EH chain = processing to forward IPv6 packets. There seems to be a fundamental misunderstanding: The normal forwarding = of=20 SRv6 packets still happens based on the dest address field in the IPv6 = header. The forwarding lookup (for intermediate nodes) does not involve looking = at the SRH=20 at all, if fact, such nodes do not need to support or know anything = about SRv6 at all. Only segment endpoint nodes, the nodes performing SR-specific functions = may have to look at the SRH and even then, for the common operation that is = analogous to=20 the POP operation in MPLS, only a new dest address needs to be copied = from the=20 SRH and a single counter needs to be decremented. Never is the = forwarding based directly on the SRH. A node that wants to do SRH insertion of course has to do some heavy = lifting,=20 that is understood. A 5 year old hardware engine may not be able to do = this. But then we are talking about highly sophisticated and desirable = functionality=20 (e.g. TI-LFA) and there is always a price: there is no such thing as a = free lunch. > SR will be a compelling replacement for MPLS if it leverages existing = commodity IPv6 methods and hardware. If it requires a fork lift upgrade = of all devices in the network, then it=E2=80=99s much less attractive = compared to MPLS. Again, no forklift upgrade, but where you want significant new = functionality, there you may have to pay a price, maybe a hardware upgrade of a line = card. And, BTW, when MPLS was introduced, it was not that any IP router could = be made to do MPLS by a simple software upgrade. On the contrary, the = situation was quite similar: where you wanted to deploy new capabilities such as = MPLS FRR, you most likely needed a hardware upgrade. So I do not see how MPLS is (has been) any better in this respect. = Especially=20 for the operation that is analogous to SRH insertion, namely MPLS PUSH, I vividly remember early hw platforms only being able to push 2 or 3 = labels at a time, limiting what you could do with MPLS. Only today, after more = than=20 15 years of MPLS have we come to a point where we can safely assume that=20= new hardware will be able to push =E2=80=9Eenough=E2=80=9C MPLS labels. /Dirk > This is why in general the recurring argument to just use IPv6 encaps > whenever all you really need is one more entry in the SRH SID list > is completely missing the point. >=20 > I haven't gone through all examples to determine what the implications = of IPv6-in-IPv6 encapsulation are, and I acknowledge that the per-packet = overheard is high. >=20 > What I have done though is proven that EH insertion is not required or = essential to solve the problem presented in the example. That is the = claim that is being made in this draft. >=20 > So please do not make that claim, please do not use giant lists of = authors that could not have contributed enough to the document to have = earned it, effectively making an appeal to authority, and please look to = leverage existing IPv6 processing models and methods to avoid = invalidating existing, well known and widely deployed and used IPv6 = devices and techniques. >=20 > The bigger and more different the claim from the norm, the more effort = you have to put into proving it. >=20 > Regards, > Mark. >=20 >=20 > /Dirk >=20 > >> - Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is > >> conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now > >> nearly 20 years old. > >> > >> - In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6 > >> devices that support conventional IPv6 forwarding and conventional > >> IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling"). > >> > >> - Encapsulation/decapsulation is a simpler, universal and proven > >> operation (literally being done every time an IPv6 packet is being > >> sent and received over any and all layer 2 links) compared to the = DA > >> address swapping that occurs at Nodes 2 and Nodes 5 in the = described > >> method. > >> > >> More complicated examples would may require more information to be > >> carried about the path between the inner and outer IPv6 headers > >> (although encapsulation inside encapsulation/tunnelling inside > >> tunnelling probably be used at a greater packet overhead host, with > >> simpler per-hop processing), however I don't think this example > >> demonstrates why EH insertion is required. > >> > >> > >> Regards, > >> Mark. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 = > > -------------------------------------------------------------------- --Apple-Mail=_65E0C509-645E-4C95-91DB-AA996F67F903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Am 03.04.2017 um 22:34 schrieb Mark Smith <markzzzsmith@gmail.com>:
On 31 Mar. 2017 01:34, "Dirk = Steinberg" <dws@steinbergnet.net> wrote:

> Am 29.03.2017 um 22:08 schrieb = Mark Smith <markzzzsmith@gmail.com>:
>
> On 30 March 2017 at 06:58, Mark Smith <markzzzsmith@gmail.com> wrote:
>> = So having further about this, I have fundamental question that it
>> isn't answering.
>>
>> Why can't IPv6-in-IPv6 encapsulation be used for = this? What is missing
>> from IPv6 that "requires" = that EH insertion is used instead of much
>> = simpler, off-the-shelf encapsulation/decapsulation?
>>
>>
>>
>> For example, using IPv6-in-IPv6 encapsulation, I = don't think an SRH is
>> needed at all in the "2. = Source Domain and Packet Journey" example.
>>
>> When node 2 realises that the link between itself = and 3 has failed, it
>> encapsulates the original = SA=3D1, DA=3D9 packet in a new IPv6 header
>> = ("tunnelling" it). The new IPv6 header has an SA=3D2, DA=3D5, and is = sent
>> towards node 4.
>>
>> Node 4 forwards the packet onto node 5 using = conventional destination
>> address based IPv6 = forwarding.
>>
>> Node 5 = receives the packet, and as it is DA=3D5, decapsulates the inner
>> SA=3D1, DA=3D9 packet. Node 5 then submits that = packet to the standard
>> IPv6 forwarding table, = resulting in it being forwarded to Node 3,
>> which = then forwards it to Node 9. All of this is happening using
>> conventional IPv6 destination based forwarding.
>>
>> Encapsulation is solving this = problem by effectively creating a
>> on-demand = virtual link or tunnel between Node 2 and Node 5, getting
>> the original packet past the failure point to a = point along the
>> original packet's forwarding = path. Once there, it pops out of the
>> virtual link = and is sent along its way. I don't think the insertion of
>> the EH and DA swapping method could be described the = same way or could
>> be described as simply.
>>
>> I think this IP-in-IPv6 = encapsulation solution to the above example is
>> = better because:
>>
>> - there is = no need for an additional header of any type - the path
>> information is inherent in the DA of the outer IPv6 = header when sent
>> to node 5, and in the DA of the = inner IPv6 packet (now "the packet")
>> when being = sent by node 5 to node 9.
>
> To = clarify, what I mean by "no need for an additional header of any
> type" is no additional header beyond the IPv6 = encapsulation header
> i.e. no SRH EH or similar = between the outer and inner IPv6 packets. It
> is the = original IPv6 packet inside a vanilla IPv6 packet with the
> outer IPv6 packet=E2=80=99s next header field set to = 41.

Following this logic of not using = =E2=80=9Ean additional header of any type=E2=80=9C leads to
the conclusion that for every entry in an SR policy = represented by the
SID list of an SRH, you would instead = use one more nested IPv6
encapsulation header.

In the simple example of section 2 the TI-LFA = policy only needs to specify
one additional node, namely 5 = (9 being the original destination), but
conceivably the = backup policy could be more complex including 3, 4, 5,
or = more SIDs. Would you really want to propose that the PLR should
impose, say 4 nested IPv6 encapsulation headers at the same = time
while still claiming this to be simpler and/or more = efficient?

Let=E2=80=99s face the reality: = the cost of adding an IPv6 encapsulation header
is fairly = high and while doing this once may be acceptable in certain = situations
doing this N times nested is prohibitive both = in terms of the burden on the
forwarding hardware and in = terms of MTU growth. One more entry in
the SID list is = just so much more efficient.

That is = ignoring the complexity and cost of processing introduced at each = hop. 

The current (and decades old) IPv6 forwarding model = involves hop-by-hop destination address matching and hop-by-hop = link-layer endcap/decap to get the packet to its destination.

MPLS too follows this model. Labels aren't inserted into the = IPv6 packet, they're added to the outside of it.

EH = insertion is fundamentally changing this forwarding model, because = forwarding devices have to do more complicated processing of EH chain = processing to forward IPv6 packets.

There seems to be a fundamental = misunderstanding: The normal forwarding of 
SRv6 packets = still happens based on the dest address field in the IPv6 = header.
The forwarding lookup (for intermediate nodes) does = not involve looking at the SRH 
at all, if fact, such = nodes do not need to support or know anything about SRv6 at = all.

Only segment endpoint nodes, = the nodes performing SR-specific functions may have
to look at = the SRH and even then, for the common operation that is analogous = to 
the POP operation in MPLS, only a new dest address = needs to be copied from the 
SRH  and a single = counter needs to be decremented. Never is the forwarding = based
directly on the SRH.

A= node that wants to do SRH insertion of course has to do some heavy = lifting, 
that is understood. A 5 year old hardware = engine may not be able to do this.
But then we are talking = about highly sophisticated and desirable = functionality 
(e.g. TI-LFA) and there is always a price: = there is no such thing as a free lunch.

SR = will be a compelling replacement for MPLS if it leverages existing = commodity IPv6 methods and hardware. If it requires a fork lift upgrade = of all devices in the network, then it=E2=80=99s much less attractive = compared to MPLS.

Again, no forklift upgrade, but where you want = significant new functionality,
there you may have to pay a = price, maybe a hardware upgrade of a line card.

And, BTW, when MPLS was introduced, it was not = that any IP router could be
made to do MPLS by a simple = software upgrade. On the contrary, the situation
was quite = similar: where you wanted to deploy new capabilities such as = MPLS
FRR, you most likely needed a hardware = upgrade.

So I do not see how MPLS is = (has been) any better in this respect. Especially 
for = the operation that is analogous to SRH insertion, namely MPLS = PUSH,
I vividly remember early hw platforms only being able to = push 2 or 3 labels
at a time, limiting what you could do with = MPLS. Only today, after more than 
15 years of MPLS have = we come to a point where we can safely assume that 
new = hardware will be able to push =E2=80=9Eenough=E2=80=9C MPLS = labels.

/Dirk

This is why in general the recurring argument to = just use IPv6 encaps
whenever all you really need is one = more entry in the SRH SID list
is completely missing the = point.

I haven't = gone through all examples to determine what the implications of = IPv6-in-IPv6 encapsulation are, and I acknowledge that the per-packet = overheard is high.

What I have done though is = proven that EH insertion is not required or essential to solve the = problem presented in the example. That is the claim that is being made = in this draft.

So please do not make that claim, please do not use = giant lists of authors that could not have contributed enough to the = document to have earned it, effectively making an appeal to authority, = and please look to leverage existing IPv6 processing models and methods = to avoid invalidating existing, well known and widely deployed and used = IPv6 devices and techniques.

The bigger and more = different the claim from the norm, the more effort you have to put into = proving it.

Regards,
Mark.


/Dirk

>> - = Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
>> conventional IPv6-in-IPv6 encapsulation, specified = in RFC2473, now
>> nearly 20 years old.
>>
>> - In this example, nodes 4, 5 = and 3 could be off-the-shelf IPv6
>> devices that = support conventional IPv6 forwarding and conventional
>> IPv6-in-IPv6 encapsulation/decapsulation (i.e., = "tunnelling").
>>
>> - = Encapsulation/decapsulation is a simpler, universal and proven
>> operation (literally being done every time an IPv6 = packet is being
>> sent and received over any and = all layer 2 links)  compared to the DA
>> = address swapping that occurs at Nodes 2 and Nodes 5 in the described
>> method.
>>
>> = More complicated examples would may require more information to be
>> carried about the path between the inner and outer = IPv6 headers
>> (although encapsulation inside = encapsulation/tunnelling inside
>> tunnelling = probably be used at a greater packet overhead host, with
>> simpler per-hop processing), however I don't think = this example
>> demonstrates why EH insertion is = required.
>>
>>
>> Regards,
>> Mark.
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> = --------------------------------------------------------------------

= --Apple-Mail=_65E0C509-645E-4C95-91DB-AA996F67F903-- From nobody Tue Apr 4 06:56:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92366126DEE; Tue, 4 Apr 2017 06:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3yCaJ_VXcXaq; Tue, 4 Apr 2017 06:56:40 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854E212869B; Tue, 4 Apr 2017 06:56:40 -0700 (PDT) X-AuditID: c6180641-417ff700000058cf-45-58e35fbd5744 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 8B.9C.22735.DBF53E85; Tue, 4 Apr 2017 10:56:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Tue, 4 Apr 2017 09:56:37 -0400 From: Suresh Krishnan To: Robert Raszuk CC: Brian E Carpenter , Fernando Gont , "Leddy, John" , 6man WG , IETF Discussion , "draft-ietf-6man-rfc2460bis.all@ietf.org" Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSnTZv86cghjjmGk6P6rsvHH5Q4qGssVmAgAD+BwCAAAesgIAAIVmAgAAFgwCAAASPgIAAEkGAgABB5oCAAAHpgIAAAteAgAACGICAAAp2gIABEiqAgAVOxgCAAHSFAIAAcTyAgAAHDACAAAmFgA== Date: Tue, 4 Apr 2017 13:56:37 +0000 Message-ID: <49627D61-E761-4739-A349-C9639F0D6350@ericsson.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_63BBCF24-C889-42DE-ABE0-68654718A7D1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUyuXRPlO7++McRBp8vslu0XdzHZPHq7TU2 iyer3rBZPNs4n8Xi5dn3TBZLFyxnsmha2MTswO5xvbOF2WPnrLvsHkuW/GTy2L1xAZPHh0M9 7AGsUVw2Kak5mWWpRfp2CVwZa1/1MBVs8a3Y1/2HrYHxk3sXIyeHhICJRFtrH2MXIxeHkMAG RomdS6+zQTjLGCX2zTjECFLFBlS1YednJhBbREBVovPEI2aQImaBmUwSj24fYAZJCAt4SEza dI0FoshTYt3GwywgRSIgky7f+g/UzcHBIqAi8fBGFojJK2AvsfSID8SyXxwSC3uugM3hFAiU +Hh9P9gcRgExie+n1oAtZhYQl7j1ZD4TxNkiEg8vnmaDsEUlXj7+xwphK0l8/D2fHeK4KYwS pxesByviFRCUODnzCcsERpFZSGbNQlY3C0kdRFGSxKkN/6FsbYllC18zQ9iaEvu7l2MR15Do /DaRFcI2lXh99CMjhG0tMePXQTYIW1FiSvdD9gWM3KsYOUqLC3Jy040MNzECo/6YBJvjDsa9 vZ6HGAU4GJV4eBVkH0UIsSaWFVfmHmJUAWp9tGH1BUYplrz8vFQlEd6YRY8jhHhTEiurUovy 44tKc1KLDzFKc7AoifO+K78QISSQnliSmp2aWpBaBJNl4uCUamAUWXi1eeu/5KmhzAe10xn8 D0xIcX60bg139MKcXQfqOfpVAl3tdq24pVTNXPj7K2OhAMvHtDyFivkh0W4frX9y2L+bxCJ1 /Nua5z8/Z68uCHG+YSGyY4aENtcel861j6wOzr1mlCJ2OdpfI6R86rdEmZVrF3aYl37gCpmQ MuPwu80OvsE37l5QYinOSDTUYi4qTgQAvaEWOgIDAAA= Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:56:42 -0000 --Apple-Mail=_63BBCF24-C889-42DE-ABE0-68654718A7D1 Content-Type: multipart/alternative; boundary="Apple-Mail=_CE5659DB-942D-49A9-A5F6-930E93C08D52" --Apple-Mail=_CE5659DB-942D-49A9-A5F6-930E93C08D52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, > On Apr 4, 2017, at 9:22 AM, Robert Raszuk wrote: >=20 > Hi Brian, >=20 > > In any case if we see this entire thread the only technical concern = with EH > > insertion was MTU. And how that issue is solved when you do = additional IPv6 > > header encap ? >=20 > PMTUD applies to the path between source A (encapsulator) and = destination B > (decapsulator). If you decapsulate at B and the encapsulate again, = PMTUD > applies to the path between B (encapsulator) and C (decapsulator). = They are > completely independent; it's a new packet. PMTUD doesn't occur between = A > and C at all. >=20 >=20 > =E2=80=8BAre you saying that it is "legal" to fragment IPv6 packet by = a router at the encapsulation point in the network ?=20 >=20 > That would be news to me.=20 Yes. It is legal. Please take a look at section 7 of RFC2473. Regards Suresh= --Apple-Mail=_CE5659DB-942D-49A9-A5F6-930E93C08D52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Robert,

On Apr 4, 2017, at 9:22 AM, = Robert Raszuk <robert@raszuk.net> wrote:

Hi = Brian,

> In any case if we see this entire thread the only = technical concern with EH
> insertion was MTU. And how that issue is solved when you do = additional IPv6
> header encap ?

PMTUD applies to the path between source A (encapsulator) and = destination B
(decapsulator). If you decapsulate at B and the encapsulate again, = PMTUD
applies to the path between B (encapsulator) and C (decapsulator). They = are
completely independent; it's a new packet. PMTUD doesn't occur between = A
and C at all.


=E2=80=8B= Are you saying that it is "legal" to fragment IPv6 packet by a router at = the encapsulation point in the network = ? 

That = would be news to = me. 

Yes. It is legal. Please take a look at section 7 of = RFC2473.

Regards
Suresh
= --Apple-Mail=_CE5659DB-942D-49A9-A5F6-930E93C08D52-- --Apple-Mail=_63BBCF24-C889-42DE-ABE0-68654718A7D1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA0MTM1NjM4WjAjBgkqhkiG9w0B CQQxFgQU2xsx4q0G1UkuF1+RzAWPYYxQHqgwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQCcS1rRq1tV+pO8gxJGwlDG1GdoHR0nGMvyG9n6vudIM50Gm+hamhdj+3tNJlYY FiBBSmFndT4cTgAbKUVZCrjLUpVgThlGA8TFn3ql2W9Ey1fWpJnf3WDHTEgMw2ymZexldgq5bTHS b6bIAC4fJh8eAJIX6AcKjTrVdoK0qiHIFoHsTpNpVed4GJ/dcxKzfj4csNPk280Eyjtm7k8y81LM lTpP7TbugVtrrMMmiF97Ft8Fad2NaCXpPU1pCesijcBkrAb+ydv7ooqcAtORJZBkoiJUL9/DOpBG 8iTMmVRujPNVTjayPgckp3bCSH/bjNFsic47Khf917XtA707NA/JAAAAAAAA --Apple-Mail=_63BBCF24-C889-42DE-ABE0-68654718A7D1-- From nobody Tue Apr 4 06:58:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4A1296BD for ; Tue, 4 Apr 2017 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 4L3VAs2f_C5r for ; Tue, 4 Apr 2017 06:58:38 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 C18D71296C3 for ; Tue, 4 Apr 2017 06:58:36 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id n76so15093417ioe.1 for ; Tue, 04 Apr 2017 06:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3oANkFIbHKtNiu3EVUwwkmXBQW4VItpQyC0bckZEcOs=; b=iD6mPH8UUyRJGkpEdZ3lKmWo2wNPXGcfq9jyvdQyLJP0/xql10BoeVq3Juw8ZqvWQl Rj4l4SUn+OMj3nub9ESZIbiDJP2aPhZIwDYWkHkJMco+O+7ITrgcpWZlQew6mTsp5h5g eCNF72xuPSAfyj4Gnaz/UYKnJp+oInd6nbZJDq7tTRGxAa9agi7NV/1DbE8xjFQyB6lj D/bMcudQsh8ouw3kWRmRAMmoaWMzw9+zMuSfmYB91h0dQ60QyZj2GsBttMWniwPAoaMs 1j4BsEFo3Ht0dHDG7kzd2b9eU7c80bkUY3Uxy5atRbU2hFmhYPyWq2Kizh3O9aJy0AdL vPwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3oANkFIbHKtNiu3EVUwwkmXBQW4VItpQyC0bckZEcOs=; b=PgpYSU2C7EWbnZ6Wuc/0fRn6quoxvSwsq4O5+EwizZwHhzNBzR3Dii0b/s09kwNRAn /lR3HFqXZslUL9QX4a3eLggj4P4l6qGb5AzHndPEPKT33P77dAQfQ/6Nsr51W8a0cJ9K 7nwM9rfo0c5tqKyRYbiSPlrGK0+tX+WoWk7151K5lEbDKHrUD75gZciZ2gWOKhFt34Vf 987r48EKG6u4PebDgxZGNOBkmnNkS4X6LDA1I6xwRIv6kJ4AnSMkWsBpC8B8fxXwLknp 7dY5+7c6l/JEGyIgGQRmQpwud18sM2BiER2/4Twa4+w9VbZFgZMn6zFzmTNaWVF3mQPy MiZg== X-Gm-Message-State: AFeK/H0ssRfcBRO6Ltbo9jOb0Dn5hRNhoXQz3dy/SZOZ8XjfViMvUHnt3bIWLDj9jgkfgQ== X-Received: by 10.107.129.75 with SMTP id c72mr24735228iod.23.1491314316159; Tue, 04 Apr 2017 06:58:36 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id v136sm7280137ita.0.2017.04.04.06.58.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 06:58:35 -0700 (PDT) Subject: Re: [Editorial Errata Reported] RFC5952 (4986) To: Fernando Gont , Tim Chown , Jan Zorz - Go6 References: <20170331155211.7C444B81110@rfc-editor.org> <8C64BAFE-D014-40F3-A3B6-956F937B4BB7@jisc.ac.uk> <55236100-3099-4B1C-AE58-FC6DC3B571CE@jisc.ac.uk> <9e650c5e-2786-32f8-700c-6c134f961902@si6networks.com> Cc: "ipv6@ietf.org" , Bob Hinden , Suresh Krishnan , "julianedprado@gmail.com" , "kawamucho@mesh.ad.jp" , Terry Manderson , RFC Errata System From: Brian E Carpenter Organization: University of Auckland Message-ID: <0892e34e-3e47-5e4c-876c-60057a122412@gmail.com> Date: Wed, 5 Apr 2017 01:58:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9e650c5e-2786-32f8-700c-6c134f961902@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:58:40 -0000 On 04/04/2017 11:05, Fernando Gont wrote: ... > FWIW, while (recently) reading RFC5952, the section you referred to > somehow came as a "surprise" to me. > > I guess that if rfc4291bis is still pursued, this should be incorporated > into it such the the bis RFC does not contradict with RFC5952? No, I don't think so. 4291(bis) defines what is valid. 5952 defines the canonical representation. Different animals. 1:2:3:4:5:6::B8 is valid. 1:2:3:4:5:6::b8 is valid. 1:2:3:4:5:6:0:B8 is valid 1:2:3:4:5:0006:0:B8 is valid 1:2:3:4:5:6:0:b8 is valid and canonical. Brian From nobody Tue Apr 4 07:02:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703941204DA for ; Tue, 4 Apr 2017 07:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Ao0BsKXpZVwm for ; Tue, 4 Apr 2017 07:02:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F7F127241 for ; Tue, 4 Apr 2017 07:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1470; q=dns/txt; s=iport; t=1491314543; x=1492524143; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RTrOsaE94YlJQkGrxYylYrfiPMJC/o5YMi1VaX2rrAU=; b=lewqCIPEFYgzw7YhKRRKwbsEABFZOs8fec6r7ggHH0Z49kpLAglvYJs7 cVXh6WILurtgopXvB8XkhWpKQZP+lDxs6DQVbv7UErVYtQ/AiklkkitdS dVWYE8YJYwJkx7JkQsYdPCkDnKyywGZ/A+lswUoahSDcuWMYZs2jDS0Y9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQDZpuNY/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1yKEpFbiBqNOYIOHwuFeAIagyI/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASEROgsFCwIBCBgCAiYCAgIfBgsVEAIEDgWJdgMNCA6tbYImh?= =?us-ascii?q?ysNgyQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOCBYJqglGCA4MGLoIxBYk?= =?us-ascii?q?jkw87AY4XhDiRPIp4iHwBHziBBVsVQREBhkd1AYgNgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="scan'208";a="403468069" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 14:02:23 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v34E2MhI023204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 14:02:23 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 10:02:22 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 10:02:22 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: 6man Subject: Re: Detail in draft-ietf-6man-segment-routing-header-06 Thread-Topic: Detail in draft-ietf-6man-segment-routing-header-06 Thread-Index: AQHSrUwUbUM73//6UUWhvvEMV/wvAw== Date: Tue, 4 Apr 2017 14:02:21 +0000 Message-ID: <12D80606-C8C2-47A2-A062-FF7EE95D776A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.102.152] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:02:25 -0000 dGhlIFNSSCBkcmFmdCBzcGVjaWZpZXMgdGhhdCB0aGUgU1JIIGlzIGFkZGVkIHRvIHRoZSBwYWNr ZXQgYnkgdGhlIHBhY2tldCBzb3VyY2U6DQoNCi4gYW4gaW5ncmVzcyByb3V0ZXIgcmVjZWl2ZXMg YW4gaW5jb21pbmcgaXB2NiBwYWNrZXQNCi4gc3VjaCBwYWNrZXQgaXMgZW5jYXBzdWxhdGVkIGlu dG8gYW4gb3V0ZXIgSVB2NiBoZWFkZXINCi4gYW4gU1JIIGlzIHRoZW4gYWRkZWQgdG8gdGhlIG91 dGVyIGVuY2Fwc3VsYXRpb24NCg0KdGhlIFNSSCBkcmFmdCBkb2VzbuKAmXQgZGVzY3JpYmUgdGhl IGNhc2Ugd2hlcmUgdGhlIFNSSCBpcyBpbnNlcnRlZCBieSBhIGNvcmUgdHJhbnNpdCBub2RlLiBT dWNoIHVzZS1jYXNlIGlzIGRlc2NyaWJlZCBpbiBkcmFmdC12b3llci02bWFuLWhlYWRlci1pbnNl cnRpb24uDQoNCnMuDQoNCg0KPiBPbiBBcHIgNCwgMjAxNywgYXQgMzo0MyBQTSwgQnJpYW4gRSBD YXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwN Cj4gDQo+IFVubGVzcyBJJ3ZlIG1pc3NlZCBpdCwgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXItMDYNCj4gZG9lc24ndCBhY3R1YWxseSBzcGVjaWZ5IHRoZSBlbmNhcHN1bGF0 aW9uIG1lY2hhbmlzbSBtZW50aW9uZWQNCj4gaW4gc2VjdGlvbiA1LjEgYW5kIGVsc2V3aGVyZS4N Cj4gDQo+IFdpbGwgaXQgc2ltcGx5IGJlIElQdjYtaW4tSVB2NiB1c2luZyBoZWFkZXIgdHlwZSA0 MSBbUkZDMjQ3M10/DQo+IA0KPiBSZWdhcmRzDQo+ICAgQnJpYW4gQ2FycGVudGVyDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Tue Apr 4 07:26:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7379F12894A; Tue, 4 Apr 2017 07:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3_fNoBGazkGi; Tue, 4 Apr 2017 07:26:17 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 91493129400; Tue, 4 Apr 2017 07:26:17 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e75so65307968itd.1; Tue, 04 Apr 2017 07:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ymh2yLWPu/elIQsYsOaDXNCvRDR0sOCc7Mq2Mng5ew4=; b=X/9lwM/zAIT6SMz+B1BMQ9FBA5/dSzQSX0lh40ouYTQPcTmGkV4AwqNg4VsQmBumrm 3NJfdcMkQ41f/xzUVsLzD47/U/M5tacpC9jbSA9QEVAkw3+Z3YQ5FiKHt0OC0zVbND3b JaKhCVCIys/hUeujLBGggYjCWRK8v3bDJSKv2Q9RnsrItrVhZmZKW9F0efmjupYRfAlK 39HvuY7PNdlMkFnPZosDElr98OPqG6Cfx5I1//c95iSMzaeANCEzgqdloKrTEJ+1Vnk4 q0/eWryPLO+/2LbWOXcfvrY8/6Ta2J4fybUnMfpLfYiur//tc2OwHJ66/2sfOtg1kcEq sYMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ymh2yLWPu/elIQsYsOaDXNCvRDR0sOCc7Mq2Mng5ew4=; b=Qj9B0vghgKFDTeNXqnXEbJ/Uc0TRnsAdkdvr7MA53U0XS7qBLzDbfHUIRUHxKVuSGz lFJN82EVqNN9tck4JCWKz7TqTZFcviug5tTlwnV528Eb7hLVwrNjl+uNlu3aAJ0KdGQG dV8MMcG4q+pZXujMup1+REKTIAoCgaXrNx2hhd+gbZRuFhB+1BFXUCrCFltl5fqJ8RLQ WxB5LDzweI3SsLyUSAElhIV4T5vnFn47eTsEuMT/HGNjQr9VRmz2oFeYDOxnPMEZiMQD 45jy9Zc1IsEmMekpgtJsJ79QhPOwER31fKWinC2Obszr8XrNq3iaIxc+CCRjhtvNcFOk dsDQ== X-Gm-Message-State: AFeK/H18BVhwEMCqmaPKaVcBMTAvEMd6TjMvcg9R9N7jT6mvs9SxLUEKnplpqRZnz2f3hkE8tnWghlR9UqZ09g== X-Received: by 10.36.115.12 with SMTP id y12mr10037900itb.24.1491315976818; Tue, 04 Apr 2017 07:26:16 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Tue, 4 Apr 2017 07:26:15 -0700 (PDT) In-Reply-To: <49627D61-E761-4739-A349-C9639F0D6350@ericsson.com> References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> <49627D61-E761-4739-A349-C9639F0D6350@ericsson.com> From: Robert Raszuk Date: Tue, 4 Apr 2017 16:26:15 +0200 X-Google-Sender-Auth: XB0Za5sH8loCh4ua2YS1IVB8WHU Message-ID: Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: Suresh Krishnan Cc: 6man WG , "draft-ietf-6man-rfc2460bis.all@ietf.org" Content-Type: multipart/alternative; boundary=001a11444dca0bd9ee054c580feb Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 14:26:20 -0000 --001a11444dca0bd9ee054c580feb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Suresh, Yes. It is legal. Please take a look at section 7 of RFC2473. > Well this section says only if =E2=80=8Byou reassemble during decapsulation= . That is going to be interesting at 100 GE port speeds especially if someone would like to use anycast SIDs to exit the SR domain via cluster of exit ASBRs. Kind regards, R. --001a11444dca0bd9ee054c580feb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Suresh,

Yes. It is legal. Please take a look at section 7 of RFC2473.


Well this section says only if =E2=80=8Byou reassemble during deca= psulation.=C2=A0

That = is going to be interesting at 100 GE port speeds especially if someone woul= d like to use anycast SIDs to exit the SR domain via cluster of exit ASBRs.= =C2=A0

Kind regards,
R.



--001a11444dca0bd9ee054c580feb-- From nobody Tue Apr 4 08:04:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584B12894E for ; Tue, 4 Apr 2017 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 MLD1phbfDZA6 for ; Tue, 4 Apr 2017 08:04:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AF188128C82 for ; Tue, 4 Apr 2017 08:04:49 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 023BB9096C5; Tue, 4 Apr 2017 11:04:49 -0400 (EDT) Date: Tue, 4 Apr 2017 11:04:48 -0400 From: John Leslie To: Mark Smith Cc: Robert Raszuk , 6man WG Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain Message-ID: <20170404150448.GA40162@verdi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:04:54 -0000 Mark Smith wrote: > > If you think fiddling with packet structure and size in the network is > perfectly fine, then I wonder if you've had any operational experience > with troubleshooing NAT, implementation bugs or devices that partially > failure such that they partially corrupt packets. I admit to no such experience within IPv6. Can you point out anyone publishing such experience? -- John Leslie From nobody Tue Apr 4 12:58:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349801294D4 for ; Tue, 4 Apr 2017 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 SvUjD92qbrK0 for ; Tue, 4 Apr 2017 12:58:34 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 930FB1294C2 for ; Tue, 4 Apr 2017 12:58:34 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id w11so12165501itb.0 for ; Tue, 04 Apr 2017 12:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=f54KhsWcqVJapP8NCumO1JIaeYDtOs8ZTdH3B7hN21A=; b=IRAciO7jTAau4NVw/WdZZcZ+JBJ2DEf21dfn5QbvwYR2Uy/6utC9FgPnNF9JKQ/4cV uA2iyl0j9ZYLIqvOyEO32yQTZVazdAx5CEmmbDp9eKrKQ5XFjnAn2dcIv8Q5x4cJRj1I wMj1uGrNYp+6zGUD7w3BkrSLIaPm8uJrZdKqq782O0Us2ss48BhM9Ct+7y1OUu+sOahD Y/NdUsgc5DilKyhg5bHLqLBTlUehX2gUVDlr5sNBtQabKKlwJMN8Cr/aIyp7RCVdNqVY dAddbmeI9/2HTOFILchYOGWHBEU0Hm2gK3ggggYdoRFANyHEcaqlwxyDcLWRqNqp7AZk hclQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=f54KhsWcqVJapP8NCumO1JIaeYDtOs8ZTdH3B7hN21A=; b=Qv/wIpN94E8vjIS9UTJiOBPizPKtCtUKwH9sEut1gQbtKNTBfE4ZnHIGczUtgCL1uM yr569StaAyfBCjDJsO2hHeZXldptkPPVO5zA88NHm3F6A1zwOYyp486PYC/icXxJh1XI GKgSpat9p0nhvw1sV8Vg9Aqp+3/P6TrasHIXXKvSI2R9YrUIo9M52TpeZchW664L9ff0 9InuSfhHHaRxtkQqhppu4n2HfYfpKuwJDm94JpQ9DSkhK6jqexUC/l4NkECRIQr3cdHa GmRMvTFuAmZLDr1j4xqb5J/ICexxyefUrKARrGKh1e/guPoqq8+EUHEY2MPM+K3dTJMg oU8A== X-Gm-Message-State: AFeK/H1b7EP8Eb2/E1dBIB72Blpq0rseYx3G397lCLv4+2XPIVQgo2gm CbwdF6jNTGukE+Qf X-Received: by 10.36.80.213 with SMTP id m204mr16935243itb.105.1491335913837; Tue, 04 Apr 2017 12:58:33 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id k16sm7688393itk.2.2017.04.04.12.58.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 12:58:32 -0700 (PDT) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 To: ipv6@ietf.org References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> <49627D61-E761-4739-A349-C9639F0D6350@ericsson.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 5 Apr 2017 07:58:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 19:58:36 -0000 On 05/04/2017 02:26, Robert Raszuk wrote: > Hi Suresh, >=20 > Yes. It is legal. Please take a look at section 7 of RFC2473. >> >=20 >=20 > Well this section says only if =E2=80=8Byou reassemble during decapsula= tion. >=20 > That is going to be interesting at 100 GE port speeds especially if som= eone > would like to use anycast SIDs to exit the SR domain via cluster of exi= t > ASBRs. That's why I mentioned jumbo frames. Obviously, you want to engineer your= SR domain such that fragmentation is never needed. Agreed, encapsulation adds an extra 40 bytes in that calculation. Brian From nobody Tue Apr 4 13:35:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9D012950E for ; Tue, 4 Apr 2017 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 EUfD-X4qJeOP for ; Tue, 4 Apr 2017 13:35:08 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 5A5C7126E3A for ; Tue, 4 Apr 2017 13:35:08 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id f103so16135397ioi.2 for ; Tue, 04 Apr 2017 13:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IuaM7aFpv+PV5F9xjKZMDWBy4/bs+4kHbbJYD/zL2Ik=; b=F2s2zVqFEsLuYaKJkOZidfJJKaq1SqMyE/0U9Z6IxUlQjbPMHIIx8QYVhK8XKKFdXi ZQ15myVbsp2+02jLv5my5pNtf47lgrrD4JvBWoTQrOM3XuntHENvHWObfMVm0zIWIhY5 Vkm6KjLRRbiIUeiAnXVet27bvqN7e6mIBWYk2ATy5NI1+rSdDkbKK3rzNXm/EXIu15F/ m6lrNhB2wolYiG8LImT9aiAb71143Nv0hYpWswGErFeARSsdW+ELVLTiQgkuJcVzTDaP PiYG6BmK+IQBWBHVj4rXTmviJOV2enIVEATLklKVz5lIjU56dBJMwpp1pBj1T9M5/U55 HfwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IuaM7aFpv+PV5F9xjKZMDWBy4/bs+4kHbbJYD/zL2Ik=; b=Miq4UiuB5CYRqON20eeFh7Hl9fB43xl1IbL7df/+Ku0rt0mATL27wbcoXKZW/MGIWL MCMAir3zu2gf1PE6S/bUdgXX66+8elih5ijiPPtGfQthYW3LalK3fKFPMPit1LDAmL/m SJzYsGFrDi/iCGaoNWx8gxpgqvHm48Nu2v0VNgBsWHO56DKz386aTpIiZHavLTq3Rcc8 gOlh3xz95oA4Dvp0YWNYgJTi9srzzGB3otJoTi31dEJQMB4EoSxlcP3QFcYD+OlHGq4E SrSP3y+hTA0mxCdXlN+PoRE3NrwCVoXlvI4P+52R6wZod95/ArjPAuUXtbFs1hzjzvXV GcAQ== X-Gm-Message-State: AFeK/H0KEoAFE3dWhq2ibjb6AKvHm4oDrOM9BzDP4DVNfrf68cJMDTyc9s3ktZTG/78mAw== X-Received: by 10.107.5.139 with SMTP id 133mr24564654iof.107.1491338107237; Tue, 04 Apr 2017 13:35:07 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id e20sm8924564itc.3.2017.04.04.13.35.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 13:35:06 -0700 (PDT) Subject: Re: Detail in draft-ietf-6man-segment-routing-header-06 To: "Stefano Previdi (sprevidi)" References: <12D80606-C8C2-47A2-A062-FF7EE95D776A@cisco.com> Cc: 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 5 Apr 2017 08:35:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <12D80606-C8C2-47A2-A062-FF7EE95D776A@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 20:35:10 -0000 Stefano, Yes. But the draft does not specify the encapsulation method. So if I was implementing this, I would have to guess. My guess is protocol 41 but I might be wrong. At the moment the draft is underspecified. Brian On 05/04/2017 02:02, Stefano Previdi (sprevidi) wrote: > the SRH draft specifies that the SRH is added to the packet by the pack= et source: >=20 > . an ingress router receives an incoming ipv6 packet > . such packet is encapsulated into an outer IPv6 header > . an SRH is then added to the outer encapsulation >=20 > the SRH draft doesn=E2=80=99t describe the case where the SRH is insert= ed by a core transit node. Such use-case is described in draft-voyer-6man= -header-insertion. >=20 > s. >=20 >=20 >> On Apr 4, 2017, at 3:43 PM, Brian E Carpenter wrote: >> >> Hi, >> >> Unless I've missed it, draft-ietf-6man-segment-routing-header-06 >> doesn't actually specify the encapsulation mechanism mentioned >> in section 5.1 and elsewhere. >> >> Will it simply be IPv6-in-IPv6 using header type 41 [RFC2473]? >> >> Regards >> Brian Carpenter >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Apr 4 14:47:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729B8129713 for ; Tue, 4 Apr 2017 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 iFXm0PvdADvP for ; Tue, 4 Apr 2017 14:47:44 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 69E881296FB for ; Tue, 4 Apr 2017 14:47:44 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id a140so6234960ita.3 for ; Tue, 04 Apr 2017 14:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=X5k4N/yl6nELv/8feHj1F2WX2eITL3dQTZKIsBLCeH8=; b=mrXgawzMt6aC+gCPEGcHx0Yjoju1+DUHcoTXkJ+6XexbNos3pdzdBeh80hGOLk2LRF ln5Dpmetrec7sodvVhPOe41gGjS4mIP9UFRhGkAmVhKNcHCA795Mm8GZiS5z3eXUx6bi QSXF2+bXmtTV9MXS5rpiphbx0WlPx2HIk438HuWcFuC4gnwACA75UzbGYX6epQM5TBmU YveQHWVvuL72tTWz7yjvAE1mzImeXH8Yehgs0g4zOBmHYFLBpO4OA7lFyEk+H4Rfv+oc wIFqtg5L1CRD0xCvsjggltZzFGu1+9AMjsp6Z0z5Di/ON+Iw/pQAZEtd8wchCyDRAoC4 7ZBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=X5k4N/yl6nELv/8feHj1F2WX2eITL3dQTZKIsBLCeH8=; b=H6x0H6mDXJX+XIqrBTwPBl5rVDyWn65JCI43dzxZ08Cx+GjI3Zv3BGxkI7zsnOE0UB dWyEd8OrGMiwQ2SDkEE9h3T/1i+HoRJV+bRRnVlmcJY1mHakZ6ziDR+GJ44tnUF+/6mL UlRIPnFikUbKaK35ZJYHiBVCLex0dibfnAZ5zzxEszk3z9B7T8msd4PxUTLnoTrx3/pT XTPV/QCV6ZS7llQeyXWhqM2EynajxjXMKewAptoXJIICdkaLuIMjKArrGoW+YVivkXO8 uu/Tsjn011xrrdeNYsFufSwxlzjb+A4BUL4UGpb2/CX2RLMz0CsmteJa1fjKFiMxrWfN bkLQ== X-Gm-Message-State: AFeK/H0V/Z68ZOCSgphlZ7ZllViNaGr0NZUJH0GYCQ2mASFEHsvqtndN fAoYLz2IlkaLbQ== X-Received: by 10.36.65.203 with SMTP id b72mr18365363itd.24.1491342463633; Tue, 04 Apr 2017 14:47:43 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id h11sm9665865ioa.43.2017.04.04.14.47.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 14:47:43 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Robert Raszuk , Mark Smith References: Cc: 6man WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> Date: Wed, 5 Apr 2017 09:47:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 21:47:46 -0000 Robert, On 04/04/2017 18:42, Robert Raszuk wrote: > Hi Mark, > >> EH insertion is fundamentally changing this forwarding model, because > forwarding devices >> have to do more complicated processing of EH chain processing to forward > IPv6 packets. > > Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents > as long as src hosts do it ? Then it's not *insertion*, which makes an existing packet longer on the fly. It's simply the creation of a packet that happens to include a particular extension header. Which is why draft-ietf-6man-segment-routing-header-06 is not problematic. > If so how does it change your above assertion on the "complicated > processing of EH chain" ? There's a problem described in RFC7045: what happens when an unknown new extension header type transits a middlebox that drops packets with unknown headers? But that applies regardless of whether the header was inserted on the fly, so I think Mark was wrong there. > So if hosts do it - it is all great, but if network element dares to do it > - it is now just a disaster ? Yes, because it changes the packet size mid-way, and that definitely breaks PMTUD, as has been discussed here often enough. Until the rules of how to configure the "controlled domain" are written in such a way as to avoid this being a problem, which I expect we'll see in later versions of draft-voyer-6man-extension-header-insertion. Regards Brian > Are all IPv6 implementations implicitly assume that src host will be too > stupid to ever do header insertion ;) ? > Well surprise ... linux kernel 4.10 can do it. > > Best, > Robert. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Apr 4 15:03:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C91293E0 for ; Tue, 4 Apr 2017 15:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 p8FDiwEbvrKG for ; Tue, 4 Apr 2017 15:03:25 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 F115E129409 for ; Tue, 4 Apr 2017 15:03:24 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id e75so72970054itd.1 for ; Tue, 04 Apr 2017 15:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KNz1Z4glJAFKoEQ0iaTnYuFfYkI7K7jdymAScdcZ4wk=; b=DjoFbQTSDfZQwc3ckgx5nJ+6uaWxa2ZjPrqziSstMYIVA/LTDbMhImrVRoIMszvLKE o5KGumm7XQ7DmpQtSoBRuzx8YnC6wKOEcU+Ro+fbNTl9567MJd3XhkGxeWZcnJTfWVKE x7KgnJ6jIs3DCWQ6bi7aMtpXtj/eev3UJCIthpqStiQfb3shw7Jp9su6d8CVp1bPvJik MkPKrlsPwMAPHJqL6g7jdjim3+kLcqNgAhvu7jthYnWTcvCFSMz4nQy2sDaYaYg5DQVP jzNRitmDLXDohqyeNU4t2K4M8S1CFtOD+qgT8bCy/CiveBIDIGfjZBdf4M7ZvSHa8fHY fzyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KNz1Z4glJAFKoEQ0iaTnYuFfYkI7K7jdymAScdcZ4wk=; b=rcskunsyEOQ0q8JdNYGUhIh/uAT/qObuRxHxtCziz8ozpUQM2oAeHwspcRNs4oxUd7 AeyTzIRAzYQz28x2OcAUetKejffGp8dVIs7TfLiZtyaEUdwnhDY8eJtLu1yyKx1GQzOA rCWIa62+1QXrill3cqim/9IpjOiHnZbO9o6OBX6/CaI33DGjxm9wKrXA7qOObbTaJzmY 9gLhQOympujqXQ/qsO6PnKfpuQLkb44xRWdTozJvpyzw4EXhudMm27zC5gVvx86zWUlB aelgzYbDNfuDRMmt3LKDvtprYwd4bl5BeGY6gYp54MTdL4yOe54Pao/YJtKkopO+ofja 3qlQ== X-Gm-Message-State: AFeK/H1cuScYWK42s6kGvhMZjOtJ49oOYWjBEGYHcdPWuyDbd0LkNbsT 2JxC1IJLNzClrAoJll5uYN9mSzdKiyZ1 X-Received: by 10.36.65.203 with SMTP id b72mr18423652itd.24.1491343404075; Tue, 04 Apr 2017 15:03:24 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.90.71 with HTTP; Tue, 4 Apr 2017 15:03:23 -0700 (PDT) In-Reply-To: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> References: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> From: Robert Raszuk Date: Wed, 5 Apr 2017 00:03:23 +0200 X-Google-Sender-Auth: --QJJnqliCeoF9sFAK2AQ8v2c-A Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Brian E Carpenter Cc: 6man WG Content-Type: multipart/alternative; boundary=001a1143f434d6c936054c5e711f Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:03:27 -0000 --001a1143f434d6c936054c5e711f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Brian, > So if hosts do it - it is all great, but if network element dares to do i= t > > - it is now just a disaster ? > > Yes, because it changes the packet size mid-way, and that definitely brea= ks > PMTUD, as has been discussed here often enough. Until the rules of how > to configure the "controlled domain" are written in such a way as to avoi= d > this being a problem, which I expect we'll see in later versions of > draft-voyer-6man-extension-header-insertion. > =E2=80=8BHow about alternative out of the box idea to accommodate expressed= above concern ?=E2=80=8B Would you and WG agree that is it legal to perform SID insertion, modification and deletion if source hosts add to the packet NULL SRH and NULL SIDs (marked as such in a well defined way) ? So packet size will *never be increased* while all flexibility and innovation provided by SRv6 could be easily accomplished regardless of the definition and boundaries of "controlled domain" ? SRv6 aware nodes would be free to use that space as it seems fit without any additional encapsulation anywhere as long as the original placeholder is sufficient for all network functions. Comments ? Opinions ? Kind regards, Robert Raszuk. PS. Flavor of the above would be to encapsulate only once when packet enters SR domain and leave enough NULL space in the SRH to accommodate what is expected to be needed during forwarding via given domain. But here the requirement to reassemble is a bit of a challenge for various reasons already stated. --001a1143f434d6c936054c5e711f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Brian,

> So if hosts do it - it i= s all great, but if network element dares to do it
> - it is now just a disaster ?

Yes, because it changes the packet size mid-way, and that definitely= breaks
PMTUD, as has been discussed here often enough. Until the rules of how
to configure the "controlled domain" are written in such a way as= to avoid
this being a problem, which I expect we'll see in later versions of
draft-voyer-6man-extension-header-insertion.

=

=E2=80=8BHow about alternative= out of the box idea to accommodate expressed above concern ?=E2=80=8B

Would you and WG agree tha= t is it legal to perform SID insertion, modification and deletion if source= hosts add to the packet NULL SRH and NULL SIDs (marked as such in a well d= efined way) ?=C2=A0

So= packet size will *never be increased* while all flexibility and innovation= provided by SRv6 could be easily accomplished regardless of the definition= and boundaries of "controlled domain" ?=C2=A0

SRv6 aware nodes would be free to use th= at space as it seems fit without any additional encapsulation anywhere as l= ong as the original placeholder is sufficient for all network functions.=C2= =A0

Comments ? Opinion= s ?=C2=A0

Kind regards= ,
Robert Raszuk.

PS. Flavor of the above would be to encapsulate only once when packet e= nters SR domain and leave enough NULL space in the SRH to accommodate what = is expected to be needed during forwarding via given domain. But here the r= equirement to reassemble is a bit of a challenge for various reasons alread= y stated.=C2=A0

--001a1143f434d6c936054c5e711f-- From nobody Tue Apr 4 15:18:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960212966F for ; Tue, 4 Apr 2017 15:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 HbdYPmWBVWAI for ; Tue, 4 Apr 2017 15:18:31 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 A7B2E1296C2 for ; Tue, 4 Apr 2017 15:18:31 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id a140so37048798ita.0 for ; Tue, 04 Apr 2017 15:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=J8RAde6PVlQ4DLcCDGBmKgDl/l7L33JhRxBnBndQ8Ew=; b=aMgE9q3KjT2Mm4+jG8kzPS7OJ0+kFjC10Gv1OmvYYWQ7/Cr7IaLniTTsfBJcDj1uRO fqgTIUZx+F2ZePZvdBdQ0vDRr773VXDMSAwJC5zh2l/QaZtHkZGPmmIT4Zmcp+MIAs+L xfwt3lW1l+GEqNeELcARUZVewn4acn3vLYDtTMzY3Vp0M6FstnNEw3scK3Pl9kpF3lEc j7QBTola0ylvG+WVc9vXiJ+mj+GlZoIy/+a1m09UaQUnmuklocUzzuUgX/ONKv1viaf5 0teEryEH9N5rwNEwoAGTJtQxGU5559ek1TUj2Dv0ZfgGr7BnESxYVYttcrvK/+dO8aUV 1vww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=J8RAde6PVlQ4DLcCDGBmKgDl/l7L33JhRxBnBndQ8Ew=; b=bM3MvpOhWTbLzE/g7K1S7ZAre+OT+u9EBD6Mpf8zVy12NQTxDkOWeCsPdix6CSdO5o hFPIFP4oEFPOIApcobrXpr62HIviyjTU4oGabDhTyan0hc/5IHE4NwNLbHawX8zwESFE tgG5JQltP9z39asMPR9ZpmAOsXES41f+PmktWmtEDahFpEQ0YyeDCw8b1+5QeWb8hj/6 RDfat9rBEj2Aau1EsNzTen9699mWfGeVG3Yg1wOufbY63MYxEcKB81s3rSiEkgMz/z7W j68U8w8FXY+KyO4cwabD2z5qVdDoAfW8FoQsp0OjKz0g2slTsQ6z1B/tx89hnEkS1hor j8Eg== X-Gm-Message-State: AFeK/H1QN9Uo8d/iJrFwaWSbOilw5sg4von7usAjzTWMKtfcV4SOIWhRU3djGNGdLw0H+g== X-Received: by 10.36.34.146 with SMTP id o140mr14011756ito.111.1491344310878; Tue, 04 Apr 2017 15:18:30 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id e137sm7873584ita.1.2017.04.04.15.18.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 15:18:30 -0700 (PDT) Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: 6man References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> Date: Wed, 5 Apr 2017 10:18:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149093611351.8864.5121956820429281359@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 22:18:34 -0000 As far as I can see this proposal makes sense and should work. But: > 1. The link-local address of the router in the new layer 2 domain > might be the same as the link-local address of the "old" router > (it's quite common to have link-local address on routers to be > explicitly configured, especially in VRRP-enabled environments) Wow. Shouldn't there also be an operational recommendation to configure non-clashing or at least highly-unlikely-to-clash addresses for such routers? Brian From nobody Tue Apr 4 16:07:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE37129514; Tue, 4 Apr 2017 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 5CaYNEcTGPpo; Tue, 4 Apr 2017 16:07:55 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 A4361129495; Tue, 4 Apr 2017 16:07:55 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d10so155932041qke.1; Tue, 04 Apr 2017 16:07:55 -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=0lUyrm5GecC/03QU2LvBNmJuxpW0bd/qRRTnSSNes7k=; b=lCWVrZnp5qNNmIe93BOhJwtVfpGBNTkxVT/C8xJoaIgBI/+JoeDzURzmuradfcq4Du +8tDvhzo3ExqUyU68gsBJsssIofNRlnZJOcEGpdu6NbwBxp1dB5iHhokTTvMU98dIUya S13JE7p5IymbO8wVkCCOY8w1KVZoXMME3zY7dSjOJm1YBcu70n1vbMyZRHxnSdKxdjgp TK7xcUlDW7VA0vWYNawBepURDcPVv9SrnV3bFlpyQGFtq/1bm8HqyFKC/GmWwJ3zRcRk DYfVoS1QmkjiUbGgE/wQwcvRjPmnWKt/D1jMEg5b9pCeacVlVoUWMXosSyr5+vSBd9y+ 4TvQ== 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=0lUyrm5GecC/03QU2LvBNmJuxpW0bd/qRRTnSSNes7k=; b=MVbtrh5X1RBp5q9foiErLxtr/tQINM62PMGqLcp2h/nkatyvtgW6n0zoz3Pw2Bf/t0 fFJoNaHzDn1Ep9OWN7IapCcJKzgYE1XsCj+Inxz1yNf0pHI40uiOE3xcw9Gm+ksV62V2 IkqRpJE+o+olgB1TjMPG4Gg6gBFG5H6nrteQdrCwyzJ4k+fcgIqGmiaq7x14A3zlt2HG xrVLdIh8NBDvEyz8To+hhsGae6ElAT41TMLijn3WBjtyWWgzudjY6uFzv5gj845xRDFP 5D3LTVm5bsmljDAhvcrR85x7KKBYDHWzwUhPDixu85tHUB+Pl3vycOHTH0G12apt9cW2 8cRw== X-Gm-Message-State: AFeK/H3wPCEctlw3Egc8ViLe55F5eJL2hjX8h8L4OWXmf9Gzxi6MWoYJkXestRgSdJ92hA== X-Received: by 10.55.111.197 with SMTP id k188mr24766123qkc.226.1491347274842; Tue, 04 Apr 2017 16:07:54 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f128sm12842288qkd.62.2017.04.04.16.07.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 16:07:53 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A0AD7B3B-FB23-487D-8961-6BA032476994"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 Date: Tue, 4 Apr 2017 16:07:50 -0700 In-Reply-To: Cc: Bob Hinden , Suresh Krishnan , IPv6 List , "draft-ietf-6man-rfc2460bis.all@ietf.org" To: Robert Raszuk References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <198e3116-5448-2fdf-4da7-4811a0133f05@gmail.com> <50E4A84C-F0ED-45ED-AA89-5713CBD8F9E0@gmail.com> <5aebc8ed-f873-94e9-1ae4-dab7b3a8ebef@gmail.com> <76ABEAE0-6A89-4C69-82ED-968F949A3B19@employees.org> <0ae6ba21-0529-e9ca-ab74-b18a85acad4a@gmail.com> <931f29e0-a029-2098-38c9-bc65e43ca0ab@si6networks.com> <49627D61-E761-4739-A349-C9639F0D6350@ericsson.com> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 23:07:57 -0000 --Apple-Mail=_A0AD7B3B-FB23-487D-8961-6BA032476994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 4, 2017, at 7:26 AM, Robert Raszuk wrote: >=20 > Hi Suresh, >=20 > Yes. It is legal. Please take a look at section 7 of RFC2473. >>=20 >=20 >=20 > Well this section says only if =E2=80=8Byou reassemble during = decapsulation Section 7.1 is titled "IPv6 Tunnel Packet Fragmentation=E2=80=9D. It = describes how to fragment at the entrance to a tunnel. Bob --Apple-Mail=_A0AD7B3B-FB23-487D-8961-6BA032476994 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY5CdHAAoJEK7rdBF357uo5GYIAMC2yTUe4n/1/qFHZbf868Bz tnt4MAAQHYOwph3bX0FGYPzx8YiQl/JW1altpI+opFlGf0iOLKJpmbB+5xlyxFYS 2Fcchtbdot0+I3pDZwo927OsJxKNzYbbBzP7ZUXx2zmBu+EfdyXgZM/ihLc1ny8e LzqYgni/DwsITIBmC9GTZ+078WbzWGS5mfxXg3UR1XX7zsZLRweUCF0ws8dewFhe GyKVGP1RjE4frJgAVzHRuq03oX8WF5O9d3IaMQncUMSEktYo336RV65c3y18Ltil wa04656L66aTSkiNZehMo4S4wjI7zh9GclFp1MnPcB8vVEGC3dXg/+xTCqkSD14= =4IuY -----END PGP SIGNATURE----- --Apple-Mail=_A0AD7B3B-FB23-487D-8961-6BA032476994-- From nobody Tue Apr 4 16:44:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9056712943D for ; Tue, 4 Apr 2017 16:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 nvVTUA5VTHzE for ; Tue, 4 Apr 2017 16:44:17 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 9679512944F for ; Tue, 4 Apr 2017 16:44:17 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id d64so18348536uad.2 for ; Tue, 04 Apr 2017 16:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KOSyX/Z9qXphXJnCuGwntYAlqRP2xBsIcZt5n0jqTys=; b=kNe0Cf6LpTisCvblJFNLNSSnMUiOYeGj8bjJeDG+zS+tBlC/0HhO5SdyKAnSRptlJ4 +wmJ7BZAgsKzUW/I1uHuEgn/EKRknwUI4kVnJB/XlrFUXUrB1lSp+rgFpSgirfmkRpu/ 5N8pnRC0CwPKt2E/tHMDzzrOurLF4fIMMJUOTCZomGCYhDkG+GPOx+5os1tosVy/4VpG e+bi6pcWbmw+BY25OTr6cbXXxjUXkbdlMsxl2EOBgDeY4dQAX2qWbR2/KAiJVJe/iJEb smA9ktlgn/e1z7FkEE8u27PEfnfea8kjpsPI8wl3nov+nfSPdLgmswFNoyJr71j0qyeJ padQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KOSyX/Z9qXphXJnCuGwntYAlqRP2xBsIcZt5n0jqTys=; b=iPCNaJYtbLtoekqkYYJ8y1RPWGRh5DOi8ekxPl1Pnmav4bje1JDZ5FblmXqb0Ewpc6 tk5CzBwD7Xi/rj7Sv04MelLoF0UFmDEo6K/pX37jVRzXlcecckiDpyDhda5CeSgcDFFO gPvjKPMU5uleYvQ/Jiwncro7h0KVAOd0dDiyWL7vv0hYxwbmzNAYeQRxJlNSty1ZiwSK YIaCo780cn4/6YSJC2D2VmWeQD05JCUF7GQcDEUx9nkp2yaDTJWQ9Wc1GG4r6CQ6cKMR +frSFkCUao3fqSe6STPT8X8DALi0DY35HuPYPOsnV0GcaddS7ZVisEmA7dGrnmFGF3JD C5fg== X-Gm-Message-State: AFeK/H2y9i4TKE9yNAEzpIvboDliEaNKwCkmaen6P/YH2dQBcGDWuzWWKONX98fa1zkrho8hJwyAv841IW/Vzg== X-Received: by 10.159.40.231 with SMTP id d94mr506105uad.98.1491349456473; Tue, 04 Apr 2017 16:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 16:43:46 -0700 (PDT) In-Reply-To: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> References: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> From: Mark Smith Date: Wed, 5 Apr 2017 09:43:46 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Brian E Carpenter Cc: Robert Raszuk , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 23:44:20 -0000 On 5 April 2017 at 07:47, Brian E Carpenter wrote: > Robert, > On 04/04/2017 18:42, Robert Raszuk wrote: >> Hi Mark, >> >>> EH insertion is fundamentally changing this forwarding model, because >> forwarding devices >>> have to do more complicated processing of EH chain processing to forward >> IPv6 packets. >> >> Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents >> as long as src hosts do it ? > > Then it's not *insertion*, which makes an existing packet longer on the fly. > It's simply the creation of a packet that happens to include a particular > extension header. Which is why draft-ietf-6man-segment-routing-header-06 > is not problematic. Exactly. Existing "insertion" is only permitted by the host that originates the packet. IPv6 packet origination is a host function (frame origination is too - routers encapsulating layer 3 packets in link-layer frames are hosts on the link at layer 2) In the network, nothing is currently splitting apart IPv6 packets and inserting something in them while in flight. 6PE doesn't do this - it encapsulates to add information to the packet, and it isn't adding IPv6 relevant information to the packet - MPLS labels are MPLS protocol information, not IPv6 protocol information, and the MPLS label information isn't inserted anywhere inside the IPv6 packet that is transported across the 6PE domain. > >> If so how does it change your above assertion on the "complicated >> processing of EH chain" ? > > There's a problem described in RFC7045: what happens when an unknown new > extension header type transits a middlebox that drops packets with > unknown headers? But that applies regardless of whether the header > was inserted on the fly, so I think Mark was wrong there. > I was using NAT as example of something that mangles packets in flight, beyond standard IP forwarding, and that if they don't work as expected, which can include because they've failed, they can be hard to troubleshoot because the mangling isn't expected or well defined, and in one direction (outside to inside), the NAT device's identity isn't recorded in the packet (in the inside to outside direction, the NAT device updates the source address, effectively making it a host on the outside network and effectively making it the originator of a new packet.) The complicated processing I was referring to was that insertion of EHs would involve processing going beyond the fixed IPv6 header, and the complexity of processing (examining, evaluating, skipping, inserting, deleting) a chain of one or more EHs. I wouldn't expect an SR domain to have middle boxes internally, so I don't think the unknown EH issue with middle boxes would be an issue. Current high speed IPv6 forwarding devices don't need to look past the IPv6 fixed header to perform their IPv6 forwarding function. If they happen to e.g., TCP/UDP ACLs, then they assume that the TCP/UDP header (EH) is directly after the IPv6 fixed header, with that information also in a fixed location in the packet. If it isn't there, they give up and either drop the packet or forward it regardless. >> So if hosts do it - it is all great, but if network element dares to do it >> - it is now just a disaster ? > > Yes, because it changes the packet size mid-way, and that definitely breaks > PMTUD, as has been discussed here often enough. Until the rules of how > to configure the "controlled domain" are written in such a way as to avoid > this being a problem, which I expect we'll see in later versions of > draft-voyer-6man-extension-header-insertion. I just don't believe this is possible to do, unless there is a statement such as the following: "SR domains MUST NOT be attached to the Internet or any other network where a inserted EH, when received, would be unexpected, due to the consequences of failure to remove inserted EHs as the domain boundary." Even if that was included, there would be no way to police this, and the victims of the failed EH removal may be far removed from the people who decided to insert them and who thought they were removing them. Regards, Mark. From nobody Tue Apr 4 17:25:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D46124D6C for ; Tue, 4 Apr 2017 17:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 NfT_j3JUxjnP for ; Tue, 4 Apr 2017 17:25:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD4C129495 for ; Tue, 4 Apr 2017 17:25:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6AC4203B5 for ; Tue, 4 Apr 2017 20:50:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AF03E636BB for ; Tue, 4 Apr 2017 20:25:47 -0400 (EDT) From: Michael Richardson To: IETF IPv6 Mailing List Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 In-Reply-To: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 00:25:51 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson wrote: >> I remembered what was bothering me: a client that doesn't understand the X >> bit might be surprised that there is no router on the link with that >> prefix. Generally, clients configure default routes via LL addresses, so I >> think that we are okay. > I have never seen a default route learnt by RA point to anything apart than > the router LL address. I believe I have, and I'm uncertain when/where; maybe they were statically configured. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljkOYsACgkQgItw+93Q 3WU25Af9ErqlBwcce6S2V6S2yBBCaIU1FHDn9rocMh/YU83xhdxe8zVgxZibhV2e hK9ITO3UwcJ8DsDNbz76+ImClPC8h65UCCahQhy76vUkU4glHiB81JhtYzdgvjA4 SUnZ/6IzSmQ1d4ZeS4oWuOXUg2ovem5hO+auJDwtctKSn8hVoxm0zi1WgzV+eUBx i+Rvtx0Ret+XrBd+ZGnFMzgKDhdUT4o9HTQCy83GkN8AGr0Bl0TrJhrSqCoO312M DPk3T4nF0VhjRczMb3cGNNCaWjJq1AVrEjXJdLPJ0JG0QHGHyOx2n3x0EkIljdZK xoqU60MSDqcLplgJCvNwizfndChI6w== =v8/y -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 4 17:40:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E803129459 for ; Tue, 4 Apr 2017 17:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JGKCOQotQ8oL for ; Tue, 4 Apr 2017 17:40:52 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 C8CA71204DA for ; Tue, 4 Apr 2017 17:40:51 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d188so190764019vka.0 for ; Tue, 04 Apr 2017 17:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RnlPNhT4Dx0omxPGQCnvbl9TtcR4wISTwDeZM0rkq8E=; b=bDGF9BGT5OKBcczEJW8WI7byfXuWRqEwTtfWif+AzTBzTtvObLtnbETyai9mmdB9Cy u/8jRar/4TAJEzXIxBHblIKv6cmwJY+9XgLWWK95RAB2UFh8ABdl0xTbkguRXsL7bsMH ep3MZoyso5foZGyjnMziGKeJlgypBudB0ZuHNYiit99zTyd+X/TXd+l5xbLZqn1PjOBw /Pu0PunOISCQj5t/T3IFrNnzYE9KRlBdbQWNRueyHRKXqrPCYgntoB3Czvn5udkjPVky WF1dEwI/r2xB4ele9z1D8SFvt19HpiH1ONbCNAV3tCoCSp7tR28yWcTOKL+3oyDfVP4I BnrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RnlPNhT4Dx0omxPGQCnvbl9TtcR4wISTwDeZM0rkq8E=; b=mUYJLDCziTZ38AeZ4KqLfVUol5uL3sk1EV+5N4DFw95vhTft818nBgpCj2Uh75Cm9n kYi0tE+WMYfH2Cn3xA85bBVXk7dTxUA+77W1CJlQXWNT4QcpMZj3z5WcmQWyymApO3pt dZI1oS2L+umtiS+No2+M6x+fjHX7+gdcacz3xwpUJwdjEygJWvgSn1GeBSsViDi6Vh7c 2jVAeOhddUO4LemcG5kWlWDGo3DVXwOmKK34oou2R2AgUA2cPljPP/oWv+Xu49+tnxzZ inpmig+3lsuIOCjaBrM0nwq/lMK98Ep/OFehOy+kZthf+pG/mCyKDMzhSXFvf74PjvQF GoXQ== X-Gm-Message-State: AFeK/H3iKxCtQhCwX24rFAUtcDHGgdevgghuAUw1xy27yi65+YgzJiKNzIUrgZ2V6NXLUOXo/5FTR2B3UYyjhw== X-Received: by 10.31.49.136 with SMTP id x130mr11833126vkx.82.1491352850744; Tue, 04 Apr 2017 17:40:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 17:40:20 -0700 (PDT) In-Reply-To: <20170404150448.GA40162@verdi> References: <20170404150448.GA40162@verdi> From: Mark Smith Date: Wed, 5 Apr 2017 10:40:20 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: John Leslie Cc: Robert Raszuk , 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 00:40:54 -0000 On 5 April 2017 at 01:04, John Leslie wrote: > Mark Smith wrote: >> >> If you think fiddling with packet structure and size in the network is >> perfectly fine, then I wonder if you've had any operational experience >> with troubleshooing NAT, implementation bugs or devices that partially >> failure such that they partially corrupt packets. > > I admit to no such experience within IPv6. > It's not an experience exclusive to IPv6. IPv6 implementations are not and are not going to be impervious to implementation bugs or partial device failures. The trouble with NAT is pretty well known, here is my recent presentation and writings on it (I think the difference from other presentations was that I used what I consider Network Critical Success Factors to be the NAT evaluation criteria): AusNOG 2016 Presentation - "The Trouble with NAT" "http://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_Mark_Smith_AusNOG2016.pdf APNIC series of 3 blog articles for the above presentation https://blog.apnic.net/author/mark-smith/ > Can you point out anyone publishing such experience? I have a number of first hand experiences with devices not behaving as specified or expected. "Residential IPv6 CPE - What Not To Do and Other Observations" http://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf In ~2008/2009 an organisation I was working for bought a mid-range router from a very well known vendor. It was using a 20+ year old code base that had been widely deployed. It suffered from a fault where it was leaking ethernet frames between the 3 physical interfaces, even though they'd been configured as separate layer 3 interfaces, causing a link to be taken off-line by the provider it was attached to due to MAC address limits. That was a significant failure to the business, as the money that was being saved by using it was going to pay for the router within less than a month. So when people say or effectively say that all implementations will follow specifications to the letter, or be configured 100% accurately in all cases, I know that won't be the case. A statement such as "An inserted SRH EH MUST be removed when the packet exits the SR domain" is a specification instruction on mandatory behaviour, but isn't a guarantee it will happen 100% of time when the specification is implemented or deployed. IPv6-in-Ipv6 encapsulation implementations will not behave be perfectly 100% of the time either, however the actions it is performing (encapsulation, tunnelling) are well known and widely deployed, and have known failure modes that are expected and can be handled with by hosts and routers that may receive those packets in error. Regards, Mark. From nobody Tue Apr 4 19:20:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7E11201F2 for ; Tue, 4 Apr 2017 19:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ISPxcl_8h8yb for ; Tue, 4 Apr 2017 19:20:23 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 48404120727 for ; Tue, 4 Apr 2017 19:20:23 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id d64so67816uad.2 for ; Tue, 04 Apr 2017 19:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0VWG2BQb05uje7upRlZ9odZTJA49zLlCdLORwi28KRw=; b=fgocRUmPKLU7CQVGBklAOeB3nTkX/zwfGcZbU5qHomOZSeYU4wjC85tf4tAQJo5Ucb gA83uLOn8B1q53+Ycwf52J0sYH7Q7c3U6vEpl6kfbKaQlzUpyaqsAvkaJUgXuIJVr4X8 wzrKKIklgfkOwOoEIpiVxch+wes3Dkj48pfk5ZdpikFgt0PbSI1TGCOoEKTH3vdWIL6o T6LZeSR2oYk4QzK7RmOYxmKtfv16QjZ83J/QwojSpAyrqv7ZG7sqZTwLn6m4MoThHekU pXlXEmqHBomkiAYFFUmngg5z9+KbNnEOAW61ybRu+xxqMGlShIQSA0D2fFolm528XSaJ rtTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0VWG2BQb05uje7upRlZ9odZTJA49zLlCdLORwi28KRw=; b=oW0WRa+D5rqXGFw2nINoKzYzxusmUt/UvkteyZZU0yiiA34XMuTIwi/t3rHwBids2b texEQuCylXsZ3/+D3h5N85DVBrFWdxq7CCU9Yb3Ab+TTjx3uJRs0N9SL8+ZvlB//ODnP rtb8GtMUHHSVdKUgl06o6SIwQYZDLi73taQOO64kGr/CyTeQTL2JIG0UoiGbsFqIzwwl hbwgNRruFEHQnZl7tMI8gXqxqZOZLxlG/n41gEUB+3TqgaBs26zt/SatirDilCOwmz5r EAEBgug0Vpr4dxu8/geGotw1yINIqh7E4reEQq572uRhNVy6OTrNjJFhwjGNC0+2ME7f WzFg== X-Gm-Message-State: AFeK/H1yOFfplykGl8nXX2f3604ma0hhuXWeDpwoVP4aZl6PObF1qkccK7b5DCxU5QLiuubp3LQHUMvHdbuVSw== X-Received: by 10.176.68.101 with SMTP id m92mr11419028uam.18.1491358822209; Tue, 04 Apr 2017 19:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 19:19:51 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 5 Apr 2017 12:19:51 +1000 Message-ID: Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Satoru Matsushima Cc: 6man WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 02:20:26 -0000 Hi, On 4 April 2017 at 18:38, Satoru Matsushima w= rote: > Hello Mark, > > Thank you, it looks very interesting discussion. I=E2=80=99d clarify a bi= t to your following point: > >> [...] > >> Node 5 receives the packet, and as it is DA=3D5, decapsulates the inner >> SA=3D1, DA=3D9 packet. Node 5 then submits that packet to the standard >> IPv6 forwarding table, resulting in it being forwarded to Node 3, >> which then forwards it to Node 9. All of this is happening using >> conventional IPv6 destination based forwarding. > > This behavior of node 5 assumes that there=E2=80=99s on-demand virtual tu= nnel between node 2 and node 5 prior to the failure. Is that correct? > No. I was using the term "virtual" to mean "conceptual", as they pretty much mean the same thing, although thinking about it "virtual" does have a more loaded meaning here in the IETF e.g., VLLs. "on-demand" was probably a mistake too, I didn't mean a tunnel was setup or signalled on demand, what I meant was there wasn't anything pre-existing that specifically needed to be be created prior to the packet being encapsulated and sent to node 5. So what is being created is a conceptual link or tunnel between node 2 and node 5 to bypass the failure, there is no configuration or signalling required for it, support for this is inherent in node 5 being able to receive and process an IPv6-in-IPv6 packet that node 2 sent to node 5 (i.e., match incoming DA, match on Next Header Type 41, decapsulate inner IPv6 packet and submit that packet to the standard IPv6 forwarding function for further forwarding.) >> >> Encapsulation is solving this problem by effectively creating a >> on-demand virtual link or tunnel between Node 2 and Node 5, getting >> the original packet past the failure point to a point along the >> original packet's forwarding path. Once there, it pops out of the >> virtual link and is sent along its way. I don't think the insertion of >> the EH and DA swapping method could be described the same way or could >> be described as simply. > > So that looks node 9 should define DA=3D9 semantics which the node pops a= n outer header and then forward the payload to the inner IPv6 destination b= ased on the routing table. I may not be understanding, however going by the example scenario, DA=3D9 is the final destination of the packet originated by SA=3D1. This SA=3D1, DA=3D9 packet is the one initially sent by Node 1. What ever is in it is what ever SA=3D1 intended for DA=3D9 to process, the example doesn't say. The goal of the example seems to be to demonstrate how the SA=3D1, DA=3D9 packet bypasses the failure of the link between node 2 and 3, reaching its final destination of DA=3D9. The example shows how it would be achieved via SRH EH insertion, I've shown how it could be achieved via IPv6-in-IPv6 encapsulation. This is in no way innovative on my part, a variety of things and experiences have made me realise the value in tunnels to get packets to other places in networks where the underlying network can't or won't: - IPsec VPNs over the Internet carrying RFC1918 addressed traffic - Many years of using a 6to4 tunnel to gain IPv6 Internet access over a residential IPv4 only service - IP-in-IP tunnels to transport AS transit traffic between iBGP peers where the underlying network doesn't carry the full route table, mentioned in "A.2.3 Encapsulation" of RFC1772, "Application of the Border Gateway Protocol in the Internet" - I think a draft briefly looked at a few years ago of RFC7490, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)" which mentions that IP-in-IP tunnels could be used. I like the idea of using tunnelling to "teleport" packets to somewhere else because the idea of doing so is at least as old as the earliest version of RFC1772, RFC1164 from 1990. > Basically an IP address of a node represents the node itself and receivin= g packets will be punt to the control-plane. So it seems that the node beha= vior doesn't work for conventional nodes. > > To that behavior works, I think that it requires additional spec to defin= e such semantics and some control-plane to signal that semantics to other n= ode. If I comment to that it would be a certain volume of load for signalin= g and maintaining the states to the control-planes, even the data-plane beh= avior can be kept in conventional. And it would also require tunnel configu= rations to the all nodes in each node which I don=E2=80=99t want to do in o= ur operations. > > I have to admit my ignorant, but I=E2=80=99m really appreciate if you let= me know about that kind of on-demand tunneling technologies without bunch = of signaling to maintain states and configuration burdens. > For IPv6, by my count there are at least 6, described in RFC7059, "A Comparison of IPv6-over-IPv4 Tunnel Mechanisms" namely, Automatic Tunneling IPv6 over IPv4 without Explicit Tunnels (6over4) Connection of IPv6 Domains via IPv4 Clouds (6to4) Intra-Site Automatic Tunnel Addressing (ISATAP) Tunneling IPv6 over UDP through NATs (Teredo) Peer-to-Peer IPv6 on Any Internetwork (6bed4) Regards, Mark. From nobody Tue Apr 4 19:36:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F97127ABE for ; Tue, 4 Apr 2017 19:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 emIonxwBw27g for ; Tue, 4 Apr 2017 19:36:23 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 37ACC12702E for ; Tue, 4 Apr 2017 19:36:20 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id r69so177070vke.2 for ; Tue, 04 Apr 2017 19:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uotNVBn0W9eP7HRPGCPtL73+mIs553SPIe23We9TisQ=; b=TZYb1kqecJsKN0blF9/6gGtQnHQM/qSAYs6Prt3/TNFhcreKp7/5cRMiSxLO6QURS2 YdeTlTGoyN2qnEHns9EjifQhb1E+Tu18EhxrFPgExxRYYfldsDXg9Flb5rgD1X0Orc2e Rf8ubYy3ZHK5ZEEWU2ug0DPFBDYrgZC/8NNZP2mtYSuf6uT+GFo6DIJohlYhWj+Wo+Qr 6T2VxnKIXz9P8XBFW5UT5Y6VqVGO50mPfYvcuuf2dJb6h+lFH0L7HKIGHH3cph05+nCj OCcWTdNYeI5c40yUkPox7rRQalZmB9qGJeTZoIeBmtyJFpSp2Ct+nuJp0Xu5o2Fs6qh+ F+sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uotNVBn0W9eP7HRPGCPtL73+mIs553SPIe23We9TisQ=; b=CJObdAF+nq/aCI3E/ae8sY16RxVdja/TvzmquC6majmTSXzIy/z0jwFY7eKmcn4T2X im4heNMnYC8xvS9JigdonRiMe4e9BW9bKRBGoxv5FgyLqA67p+7lD+BvWmP2UmAVa2wE Q7vzmCnoW3hPH5dq6YM0hwr5bMtBN6fpqvteaEat7d8PPEMt0trtTsK6mPk3laDhNHJa 6aVOqUGnZ7hI0qaJA52A1fzfcWunfkIO5hGuEnkkHzrByc/gU+gmdQH11QBC2b4wHI2s wAvzoAakfACXihvwxMn7QMRnZAFGIcHdRIdpMqtktwJYEKLzOTEKVgsCegSFl2QBoUzh KkiQ== X-Gm-Message-State: AFeK/H3wGbR1/7a11Gg+vX/ozwwh4wtHx3s6ggvVcti/U2+bfP2sRslKWmx2Jf3AIrLWZFArAsEsfzT4PZ9mWQ== X-Received: by 10.31.162.9 with SMTP id l9mr12341711vke.123.1491359779226; Tue, 04 Apr 2017 19:36:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 4 Apr 2017 19:35:48 -0700 (PDT) In-Reply-To: <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Mark Smith Date: Wed, 5 Apr 2017 12:35:48 +1000 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Brian E Carpenter Cc: 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 02:36:25 -0000 On 5 April 2017 at 08:18, Brian E Carpenter wrote: > As far as I can see this proposal makes sense and should work. But: > >> 1. The link-local address of the router in the new layer 2 domain >> might be the same as the link-local address of the "old" router >> (it's quite common to have link-local address on routers to be >> explicitly configured, especially in VRRP-enabled environments) > > Wow. Shouldn't there also be an operational recommendation to configure > non-clashing or at least highly-unlikely-to-clash addresses for > such routers? > I think RFC8064, "Recommendation on Stable IPv6 Interface Identifiers" is indirectly making that recommendation. One of the use cases of RFC7217 is for router interface's Link-Local addresses, and to not use use the interface's MAC address as the Net_Iface value (e.g., module/slot number, ifindex instead), so that the router's Link-Local IID is both unique and doesn't change if the physical interface module is replaced, which usually means an interface MAC address change too. Regards, Mark. From nobody Tue Apr 4 23:57:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C164912704A for ; Tue, 4 Apr 2017 23:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Pti4CsIg3oBR for ; Tue, 4 Apr 2017 23:57:05 -0700 (PDT) Received: from smtp.uniroma2.it (mysmtp.uniroma2.it [160.80.6.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8761E1242F7 for ; Tue, 4 Apr 2017 23:57:03 -0700 (PDT) Received: from smtpauth.uniroma2.it (smtpauth.uniroma2.it [160.80.6.47]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id v356ulvB009222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2017 08:56:53 +0200 Received: from [160.80.82.21] ([160.80.82.21]) (authenticated bits=0) by smtpauth.uniroma2.it (8.14.3/8.14.3/Debian-9.4) with ESMTP id v356uh74002948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2017 08:56:43 +0200 Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: ipv6@ietf.org References: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> From: Stefano Salsano Message-ID: Date: Wed, 5 Apr 2017 08:56:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2015 X-Virus-Status: Clean Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 06:57:09 -0000 Il 2017-04-05 01:43, Mark Smith ha scritto: > On 5 April 2017 at 07:47, Brian E Carpenter wrote: >> Robert, >> On 04/04/2017 18:42, Robert Raszuk wrote: >>> Hi Mark, >>> >>>> EH insertion is fundamentally changing this forwarding model, because >>> forwarding devices >>>> have to do more complicated processing of EH chain processing to forward >>> IPv6 packets. >>> >>> Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents >>> as long as src hosts do it ? >> >> Then it's not *insertion*, which makes an existing packet longer on the fly. >> It's simply the creation of a packet that happens to include a particular >> extension header. Which is why draft-ietf-6man-segment-routing-header-06 >> is not problematic. > > Exactly. Existing "insertion" is only permitted by the host that > originates the packet. IPv6 packet origination is a host function > (frame origination is too - routers encapsulating layer 3 packets in > link-layer frames are hosts on the link at layer 2) > > In the network, nothing is currently splitting apart IPv6 packets and > inserting something in them while in flight. 6PE doesn't do this - it > encapsulates to add information to the packet, and it isn't adding > IPv6 relevant information to the packet - MPLS labels are MPLS > protocol information, not IPv6 protocol information, and the MPLS > label information isn't inserted anywhere inside the IPv6 packet that > is transported across the 6PE domain. > >> >>> If so how does it change your above assertion on the "complicated >>> processing of EH chain" ? >> >> There's a problem described in RFC7045: what happens when an unknown new >> extension header type transits a middlebox that drops packets with >> unknown headers? But that applies regardless of whether the header >> was inserted on the fly, so I think Mark was wrong there. >> > > I was using NAT as example of something that mangles packets in > flight, beyond standard IP forwarding, and that if they don't work as > expected, which can include because they've failed, they can be hard > to troubleshoot because the mangling isn't expected or well defined, > and in one direction (outside to inside), the NAT device's identity > isn't recorded in the packet (in the inside to outside direction, the > NAT device updates the source address, effectively making it a host on > the outside network and effectively making it the originator of a new > packet.) > > The complicated processing I was referring to was that insertion of > EHs would involve processing going beyond the fixed IPv6 header, and > the complexity of processing (examining, evaluating, skipping, > inserting, deleting) a chain of one or more EHs. I wouldn't expect an > SR domain to have middle boxes internally, so I don't think the > unknown EH issue with middle boxes would be an issue. > > Current high speed IPv6 forwarding devices don't need to look past the > IPv6 fixed header to perform their IPv6 forwarding function. If they > happen to e.g., TCP/UDP ACLs, then they assume that the TCP/UDP header > (EH) is directly after the IPv6 fixed header, with that information > also in a fixed location in the packet. If it isn't there, they give > up and either drop the packet or forward it regardless. > >>> So if hosts do it - it is all great, but if network element dares to do it >>> - it is now just a disaster ? >> >> Yes, because it changes the packet size mid-way, and that definitely breaks >> PMTUD, as has been discussed here often enough. Until the rules of how >> to configure the "controlled domain" are written in such a way as to avoid >> this being a problem, which I expect we'll see in later versions of >> draft-voyer-6man-extension-header-insertion. > > I just don't believe this is possible to do, unless there is a > statement such as the following: > > "SR domains MUST NOT be attached to the Internet or any other network > where a inserted EH, when received, would be unexpected, due to the > consequences of failure to remove inserted EHs as the domain > boundary." Hi Mark, in the case discussed in draft-voyer-6man-extension-header-insertion the EH is inserted in a outer packet with a destination IPv6 address within the "controlled domain". The original packet will exit the controlled domain only when it is decapsulated by the exit node in the controlled domain. So actually, there is no an "EH removal" operation that a node may fail to execute: either the original packet is decapsulated and forwarded outside the domain (and for sure it will have no EH inside) or if there are problems they are confined in the controlled domain... as the outer packet has only IPv6 addresses belonging to the controlled domain regards, Stefano > > Even if that was included, there would be no way to police this, and > the victims of the failed EH removal may be far removed from the > people who decided to insert them and who thought they were removing > them. > > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Wed Apr 5 00:16:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879EA12783A for ; Wed, 5 Apr 2017 00:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AXtX3kxVjKyC for ; Wed, 5 Apr 2017 00:16:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F281293E0 for ; Wed, 5 Apr 2017 00:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2554; q=dns/txt; s=iport; t=1491376607; x=1492586207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KG1zBDRRqW2hPYuzVifNZNfGJvtUvizgpMt0gSXYi0c=; b=ASo9Y+zQdgOfIExJpsOXStUc5mnkvxcEMdwjTLOgc1B2Gs+VK2RW+Ew2 7/ybfqW5VhQ2fVg9ukAazVfbOgjPBb+caLKhiacXAYNsMqojRy7pWT9Wn iwDkWURFivW+TyId9tWKQdobfk4NE63oeRYYe+b+SOLP0kAE8DmlaJ7AL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAQDamORY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYELB4NcihKRV4gajTuCDh8LhXgCGoMrPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhEToLBQsCAQgYAgImAgICHwYLFRACBA4FiXYDDQgOqjiCJ?= =?us-ascii?q?ocpDYMxAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDggWCaoJRggMXgm8ugjE?= =?us-ascii?q?FiSWTEDsBjhiEOZE8inmIfAEfOIEFWxVBEQGGR3UBiDuBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,277,1486425600"; d="scan'208";a="407786990" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 07:16:47 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v357GkXp021085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 07:16:46 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 03:16:45 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 5 Apr 2017 03:16:45 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: 6man Subject: Re: Detail in draft-ietf-6man-segment-routing-header-06 Thread-Topic: Detail in draft-ietf-6man-segment-routing-header-06 Thread-Index: AQHSrYL3/vBMHcrP3Uy8oHuQPbr2a6G2oTUA Date: Wed, 5 Apr 2017 07:16:45 +0000 Message-ID: <9254E746-C466-4A3B-A416-085B52A59FF9@cisco.com> References: <12D80606-C8C2-47A2-A062-FF7EE95D776A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.254.64] Content-Type: text/plain; charset="utf-8" Content-ID: <6AD88DEB09F7D6408C1D1F4A71AEF3BB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:16:49 -0000 c2VjdGlvbiAyLjMNClsuLi5dDQogIG8gIEF0IHRoZSBpbmdyZXNzIG5vZGUgb2YgYW4gU1IgZG9t YWluIHdoZXJlIHRoZSBpbmdyZXNzIG5vZGUNCiAgICAgIHJlY2VpdmVzIGFuIElQdjYgcGFja2V0 IGFuZCBlbmNhcHN1bGF0ZXMgaXQgaW50byBhbiBvdXRlciBJUHY2DQogICAgICBoZWFkZXIgZm9s bG93ZWQgYnkgYSBTZWdtZW50IFJvdXRpbmcgaGVhZGVyLg0KWy4uLl0NCg0KeWVzLCDigJxvdXRl ciBpcHY2IGhlYWRlcuKAnSBpcyBpbnRlbmRlZCBhcyBwcm90b2NvbCA0MS4gSeKAmWxsIG1ha2Ug dGhpcyBtb3JlIHNwZWNpZmljLg0KDQpzLg0KDQoNCg0KPiBPbiBBcHIgNCwgMjAxNywgYXQgMTA6 MzUgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdy b3RlOg0KPiANCj4gU3RlZmFubywNCj4gDQo+IFllcy4gQnV0IHRoZSBkcmFmdCBkb2VzIG5vdCBz cGVjaWZ5IHRoZSBlbmNhcHN1bGF0aW9uIG1ldGhvZC4gU28gaWYNCj4gSSB3YXMgaW1wbGVtZW50 aW5nIHRoaXMsIEkgd291bGQgaGF2ZSB0byBndWVzcy4gTXkgZ3Vlc3MgaXMgcHJvdG9jb2wNCj4g NDEgYnV0IEkgbWlnaHQgYmUgd3JvbmcuIEF0IHRoZSBtb21lbnQgdGhlIGRyYWZ0IGlzIHVuZGVy c3BlY2lmaWVkLg0KPiANCj4gICAgQnJpYW4NCj4gT24gMDUvMDQvMjAxNyAwMjowMiwgU3RlZmFu byBQcmV2aWRpIChzcHJldmlkaSkgd3JvdGU6DQo+PiB0aGUgU1JIIGRyYWZ0IHNwZWNpZmllcyB0 aGF0IHRoZSBTUkggaXMgYWRkZWQgdG8gdGhlIHBhY2tldCBieSB0aGUgcGFja2V0IHNvdXJjZToN Cj4+IA0KPj4gLiBhbiBpbmdyZXNzIHJvdXRlciByZWNlaXZlcyBhbiBpbmNvbWluZyBpcHY2IHBh Y2tldA0KPj4gLiBzdWNoIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgaW50byBhbiBvdXRlciBJUHY2 IGhlYWRlcg0KPj4gLiBhbiBTUkggaXMgdGhlbiBhZGRlZCB0byB0aGUgb3V0ZXIgZW5jYXBzdWxh dGlvbg0KPj4gDQo+PiB0aGUgU1JIIGRyYWZ0IGRvZXNu4oCZdCBkZXNjcmliZSB0aGUgY2FzZSB3 aGVyZSB0aGUgU1JIIGlzIGluc2VydGVkIGJ5IGEgY29yZSB0cmFuc2l0IG5vZGUuIFN1Y2ggdXNl LWNhc2UgaXMgZGVzY3JpYmVkIGluIGRyYWZ0LXZveWVyLTZtYW4taGVhZGVyLWluc2VydGlvbi4N Cj4+IA0KPj4gcy4NCj4+IA0KPj4gDQo+Pj4gT24gQXByIDQsIDIwMTcsIGF0IDM6NDMgUE0sIEJy aWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+ IA0KPj4+IEhpLA0KPj4+IA0KPj4+IFVubGVzcyBJJ3ZlIG1pc3NlZCBpdCwgZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXItMDYNCj4+PiBkb2Vzbid0IGFjdHVhbGx5IHNwZWNp ZnkgdGhlIGVuY2Fwc3VsYXRpb24gbWVjaGFuaXNtIG1lbnRpb25lZA0KPj4+IGluIHNlY3Rpb24g NS4xIGFuZCBlbHNld2hlcmUuDQo+Pj4gDQo+Pj4gV2lsbCBpdCBzaW1wbHkgYmUgSVB2Ni1pbi1J UHY2IHVzaW5nIGhlYWRlciB0eXBlIDQxIFtSRkMyNDczXT8NCj4+PiANCj4+PiBSZWdhcmRzDQo+ Pj4gIEJyaWFuIENhcnBlbnRlcg0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+Pj4gaXB2NkBpZXRmLm9yZw0KPj4+ IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+IA0KDQo= From nobody Wed Apr 5 00:17:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AFC128B44 for ; Wed, 5 Apr 2017 00:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no 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 gTpuAeTa6Hc0 for ; Wed, 5 Apr 2017 00:17:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA0B12704A for ; Wed, 5 Apr 2017 00:17:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v357HSAJ027982 for ; Wed, 5 Apr 2017 09:17:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1FE85200BE9 for ; Wed, 5 Apr 2017 09:17:28 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0B6C4203CA3 for ; Wed, 5 Apr 2017 09:17:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v357HRBh003161 for ; Wed, 5 Apr 2017 09:17:27 +0200 Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 To: ipv6@ietf.org References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> <25302.1491351947@obiwan.sandelman.ca> From: Alexandre Petrescu Message-ID: <33726db3-0759-b99a-7c92-15e6dca6d15a@gmail.com> Date: Wed, 5 Apr 2017 09:17:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <25302.1491351947@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 07:17:34 -0000 Le 05/04/2017 ŕ 02:25, Michael Richardson a écrit : > > Mikael Abrahamsson wrote: >>> I remembered what was bothering me: a client that doesn't >>> understand the X bit might be surprised that there is no router >>> on the link with that prefix. Generally, clients configure >>> default routes via LL addresses, so I think that we are okay. > >> I have never seen a default route learnt by RA point to anything >> apart than the router LL address. > > I believe I have, and I'm uncertain when/where; maybe they were > statically configured. In my setting most manually configured default routes are to ULAs, not LLs, because these latter change each time the line cards change. For the default route learnt from RA - indeed - can only be LL, as there is no field in RA specifying the address to be used as default router (it's got from the src field). Maybe we want one(?) Alex > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Apr 5 01:12:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9131241FC for ; Wed, 5 Apr 2017 01:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 hmlalKJQ4V_P for ; Wed, 5 Apr 2017 01:12:06 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 C78881293E0 for ; Wed, 5 Apr 2017 01:12:05 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id s68so2976468vke.3 for ; Wed, 05 Apr 2017 01:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tHNoeIGTDLPJNmFXoQXIGRvYgc1geZB0i4qfyZW9v/I=; b=fOO4TpqHtRVh158RbaZcbBVLfV5VLKOjxblo3LYEEjv+5ciRk48FOhI2imo7Ig+L4G l+iFpu+CNKp3pF5ygqdcI3y4Bf32RocQb8BlqZS3PoFGTPGRNGUXEpI+fBETg4OPevZC 0zzHy0x+aoS3uL+xDILeY0QG4oEEfiRFmkp7gCIunfy+WqMlzjBIZmvyNGgz1HIV3qzH kFVTIIfFzOlYyZ4yup8jZPajLTfOPDXrLC3FCgU6v/m1fdHFq/TBvigujva+Yw5Gw3/z mU0Sb4d6QAd8jXSNpOVceBLYA9d8S8/jMaK2/HFGMJLwl2jtIydLFTRieRQ3M6Pwzb+W ig7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tHNoeIGTDLPJNmFXoQXIGRvYgc1geZB0i4qfyZW9v/I=; b=LECRVQCFCQPiD1fyp13IYnNDlQFKdkttGBIaUtnUieWiovhVUDMml79LGaPEL2oBhI sJmqNT8BuYWzrXlA5WEFM8JVOGmx1Ta91kJbTdFRsDQ/p9cPB7oT+YSzyHZHnUcd7DM6 bnXMBdY4lZZAijZMM+SETjAP9hB8pUdRVSiTyXEuE5YPmnYKHyn0VIUPk9xaoVfPrfrv rla1o/w2Hr/L86FsrN2Gl6/sPlAywX/QFanhQ+jV2/Fge7d+4+4Iqu8EnNuAWqVx58/b Pd6MizuTGe09XnmloJY9wN0H5v6ErEFS5keListCDluH59fQoHbID8QSi2F6rrTTwo9o yExA== X-Gm-Message-State: AFeK/H1xcFTHUCF+Hx6aUR0yT2lC9cIMxyOymmnPFNxN4dzpTStZwWWzwV4j80RiTSKTH+kB5IAhon1kM77KFf8z X-Received: by 10.31.107.93 with SMTP id g90mr12534037vkc.155.1491379924643; Wed, 05 Apr 2017 01:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 01:11:43 -0700 (PDT) In-Reply-To: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> From: Lorenzo Colitti Date: Wed, 5 Apr 2017 17:11:43 +0900 Message-ID: Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 To: james woodyatt Cc: IETF IPv6 Mailing List , Erik Kline Content-Type: multipart/alternative; boundary=001a11478dd0a299a8054c66f22b Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 08:12:08 -0000 --001a11478dd0a299a8054c66f22b Content-Type: text/plain; charset=UTF-8 On Tue, Apr 4, 2017 at 6:41 AM, james woodyatt wrote: > > The draft makes no mention of it, but section 2.8 of RFC 4291 requires all > routers to recognize the Subnet-Router anycast address for every subnet > prefix it has advertised on the link. One imagines that a router sending > PIO-X subnet prefixes to hosts would be therefore required to recognize the > Subnet-Router anycast address for each one. > No, the RFC requires that the router recognize "the Subnet-Router Anycast addresses for all interfaces for which it is configured to act as a router". Because the router MUST NOT form any addresses in the PIO-X subnet, there is no subnet-router anycast to configure in that subnet. The host receiving the PIO-X prefix should recognize it instead, if forwarding is turned on. --001a11478dd0a299a8054c66f22b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 4, 2017 at 6:41 AM, james woodyatt <jhw@google.com> wro= te:
The draft makes no mention of it, but section 2.8 of RFC= 4291 requires all routers to recognize the Subnet-Router anycast address f= or every subnet prefix it has advertised on the link. One imagines that a r= outer sending PIO-X subnet prefixes to hosts would be therefore required to= recognize the Subnet-Router anycast address for each one.

No, the RFC requires that the router recognize "the S= ubnet-Router Anycast addresses for all interfaces for which it is configure= d to act as a router". Because the router MUST NOT form any addresses = in the PIO-X subnet, there is no subnet-router anycast to configure in that= subnet. The host receiving the PIO-X prefix should recognize it instead, i= f forwarding is turned on.
--001a11478dd0a299a8054c66f22b-- From nobody Wed Apr 5 01:14:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E89129411 for ; Wed, 5 Apr 2017 01:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 Z8qZ457Ht-eH for ; Wed, 5 Apr 2017 01:14:07 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 B15D51243F6 for ; Wed, 5 Apr 2017 01:14:07 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s68so2998781vke.3 for ; Wed, 05 Apr 2017 01:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4LjjWmhWH0zhSo8+aElACFjafUW9TgklAK47XquhUtQ=; b=eyq1WD2tS93SF2xYXq7ptdE5tEEtNlU5lBsC8QR5eYiV7brH1SKH2tkn9Zyr5Wrdbs b0ruW+x88RzOWyfaWpo3KJLsjSe8CZA8KffG1pZfeSRW7GjY54+FiyrMki9qzx6uHJBi Sqn/uLXrFrOsivTQFHxdaZh4lsJBbMM+zbMa69u+Ns+A8Ui2VtFK+nh/N6+8pqW8nJSO 5kJH/0CuoWvTL2labfVYEEfTiLzUGN2CjTASWa5zhCEtIgjc4nnpGKQcsMTW1sRi4A8g QucJnSu9JXBtBguKRJGLo4p60v2B0w3UYIMhauFArxnVMNF/SvGHai++pH/D2KL3Zxkt iZAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4LjjWmhWH0zhSo8+aElACFjafUW9TgklAK47XquhUtQ=; b=f2l3GdpBlWmxtVr3QxKKiLy+VpT8YAUKa5EZI6S74SDzArK/6D8m+Z217JFXCfBab2 DnXAlDkhc0ZTvPPZ0DHWS2V4mB3OxlnWxRi2kPUU/SySrAV/MPbupycZ1IPAs9MQkA81 RBbrAGcxrDQEP00vdKl+nTPBVOSVWpABk8fwPRq8b1sbTwKZSLkX/O2f0FX3K2+57zl/ 1WE/VphfL4DiMihIRLfTdw29rBv3PMScVGpBZOuSbPk6qBphJkNG2ocS3HprMM48ZmFo bWNrkaK1sZykTQb7ScTGcbLAfTbqOO+X2ZvPzMmZfhB2tEHiw2BwRh8I3N9jw0uCQpNg HbkQ== X-Gm-Message-State: AFeK/H3679j8M4iCkiRrQtrIoj/ApdDD6obILHB+ARQyF7vS+7JpXsBhxQicp+XVIe5XyNZ3BoMQrU82l4/9F6oE X-Received: by 10.31.60.17 with SMTP id j17mr8088535vka.45.1491380046593; Wed, 05 Apr 2017 01:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Wed, 5 Apr 2017 01:13:46 -0700 (PDT) In-Reply-To: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> From: Lorenzo Colitti Date: Wed, 5 Apr 2017 17:13:46 +0900 Message-ID: Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 To: David Farmer Cc: Erik Kline , Alexandre Petrescu , IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary=001a11436e50e7656b054c66f9a8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 08:14:09 -0000 --001a11436e50e7656b054c66f9a8 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 31, 2017 at 9:36 PM, David Farmer wrote: > I would say "might be" or "can be" orthogonal; in my opinion, it would be > unfortunate and kind of pointless for a network to provide a /64 with PIO-X > and then only offer a /64 prefix through DHCPv6-PD, and in my opinion this > would be over-lapping, and not orthogonal. However, if a network provided > a /64 via PIO-X and offered a /60, /56, or larger, prefix via DHCPv6-PD > that would make a lot of sense to me and would be orthogonal. > Remember that the use case for this option is for networks that today provide an entire /64, such as 3GPP networks and IPv6-prefix-per-host networks. I agree that if the network already provides a /64 or more via DHCPv6 PD, and the clients use it, there is no need to use PIO-X. --001a11436e50e7656b054c66f9a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 31, 2017 at 9:36 PM, David Farmer <farmer@umn.edu> wrot= e:
I would say "mig= ht be" or "can be" orthogonal; =C2=A0in my opinion, it would= be unfortunate and kind of pointless for a network to provide a /64 with P= IO-X and then only offer a /64 prefix through DHCPv6-PD, and in my opinion = this would be over-lapping, and not orthogonal.=C2=A0 However, if a network= provided a /64 via PIO-X and offered a /60, /56, or larger, prefix via DHC= Pv6-PD that would make a lot of sense to me and would be orthogonal. =C2=A0=

Remember that the use case for this = option is for networks that today provide an entire /64, such as 3GPP netwo= rks and IPv6-prefix-per-host networks. I agree that if the network already = provides a /64 or more via DHCPv6 PD, and the clients use it, there is no n= eed to use PIO-X.
--001a11436e50e7656b054c66f9a8-- From nobody Wed Apr 5 06:29:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D95129489 for ; Wed, 5 Apr 2017 06:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 nsWO-XM50zNd for ; Wed, 5 Apr 2017 06:29:22 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 0A4C7128B38 for ; Wed, 5 Apr 2017 06:29:20 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id f103so1355610ioi.2 for ; Wed, 05 Apr 2017 06:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BlmNVTRCtAc+1TQ8xLPqk3BBhQnKsTqbC1JiLEanB44=; b=qTw0Nof2JtEMnEkZnc7YQeYZ7t+o4e9wEMkyUTmUHvDRbRZv7/9Lu6LSOxTeE8A3lK IfHoxVVHfH+vSKPt+7YK2AMmzPbSsj03kEEgSU2GZS2gtdTRPqwrHx7PY+rqDmuwGVVU 39LkbJrjB0ZVy/j7MGQH7pyl6qYt8qyhHMMo+BJv61UrXM4SPllBgsjhsNLs+Bs8zQRf pdQ7zasPFgdZZxGSeQlszdn1OZPSXwQs+XnpnhI6Rl01qkf1Ff0dkUdoCY+ApLqJNDcl UM7Xlcx7EmJgfLvAK2rthvC5TtiQrcoAlMdZzzCJkjaSczk8CZgGCcR34mNdE75Eic+z f56g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BlmNVTRCtAc+1TQ8xLPqk3BBhQnKsTqbC1JiLEanB44=; b=tqF1F/A5Je+23627mr+EAOTpatr33JHck4Sa28smnSfC3mAeLhj33wtv0287/LCQGt d1WUKRqWQCQYiI5Nkkzc5oiIwWNIG+cDSmBsn9VA0vhT8n3zFJxxm2feSVIYPWYZQ4+E G4wV5GM/XGaKTydNvvl5IFk+ldipb1xw/m/s/S+QXXYfH8azTmBAFbq+VfJkH4dcqy2C Sxq/Y7KJ9OL5rO6jbI8WNk97DWwnmRBVcsbvvfjqsevYkfFGDy5ghvG5HlyMJIhDplmS vFL9A67CndVtZinqMHlJoOjR1HxhYw5NDJUTsCH7kBbrwdQRWkwwgfb6qKr9O2pd5a+S uuFQ== X-Gm-Message-State: AFeK/H3QCkkt38MpdsIDrTb+/C0SPNjBk7rKLXvV3YANcm/rQ0A0FWr2sDQuJRuxlS9piA== X-Received: by 10.107.175.5 with SMTP id y5mr30426277ioe.7.1491398959140; Wed, 05 Apr 2017 06:29:19 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id i96sm10595127iod.46.2017.04.05.06.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 06:29:18 -0700 (PDT) Subject: Re: Insertion of IPv6 Segment Routing Headers in a Controlled Domain To: Stefano Salsano , ipv6@ietf.org References: <4e41e013-161f-defe-53f2-cf7ec8cd68b1@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 6 Apr 2017 01:29:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:29:32 -0000 On 05/04/2017 18:56, Stefano Salsano wrote: > Il 2017-04-05 01:43, Mark Smith ha scritto: >> On 5 April 2017 at 07:47, Brian E Carpenter wrote: >>> Robert, >>> On 04/04/2017 18:42, Robert Raszuk wrote: >>>> Hi Mark, >>>> >>>>> EH insertion is fundamentally changing this forwarding model, because >>>> forwarding devices >>>>> have to do more complicated processing of EH chain processing to forward >>>> IPv6 packets. >>>> >>>> Oh really ? Isn't EH insertion explicitly allowed by *all* IPv6 documents >>>> as long as src hosts do it ? >>> >>> Then it's not *insertion*, which makes an existing packet longer on the fly. >>> It's simply the creation of a packet that happens to include a particular >>> extension header. Which is why draft-ietf-6man-segment-routing-header-06 >>> is not problematic. >> >> Exactly. Existing "insertion" is only permitted by the host that >> originates the packet. IPv6 packet origination is a host function >> (frame origination is too - routers encapsulating layer 3 packets in >> link-layer frames are hosts on the link at layer 2) >> >> In the network, nothing is currently splitting apart IPv6 packets and >> inserting something in them while in flight. 6PE doesn't do this - it >> encapsulates to add information to the packet, and it isn't adding >> IPv6 relevant information to the packet - MPLS labels are MPLS >> protocol information, not IPv6 protocol information, and the MPLS >> label information isn't inserted anywhere inside the IPv6 packet that >> is transported across the 6PE domain. >> >>> >>>> If so how does it change your above assertion on the "complicated >>>> processing of EH chain" ? >>> >>> There's a problem described in RFC7045: what happens when an unknown new >>> extension header type transits a middlebox that drops packets with >>> unknown headers? But that applies regardless of whether the header >>> was inserted on the fly, so I think Mark was wrong there. >>> >> >> I was using NAT as example of something that mangles packets in >> flight, beyond standard IP forwarding, and that if they don't work as >> expected, which can include because they've failed, they can be hard >> to troubleshoot because the mangling isn't expected or well defined, >> and in one direction (outside to inside), the NAT device's identity >> isn't recorded in the packet (in the inside to outside direction, the >> NAT device updates the source address, effectively making it a host on >> the outside network and effectively making it the originator of a new >> packet.) >> >> The complicated processing I was referring to was that insertion of >> EHs would involve processing going beyond the fixed IPv6 header, and >> the complexity of processing (examining, evaluating, skipping, >> inserting, deleting) a chain of one or more EHs. I wouldn't expect an >> SR domain to have middle boxes internally, so I don't think the >> unknown EH issue with middle boxes would be an issue. >> >> Current high speed IPv6 forwarding devices don't need to look past the >> IPv6 fixed header to perform their IPv6 forwarding function. If they >> happen to e.g., TCP/UDP ACLs, then they assume that the TCP/UDP header >> (EH) is directly after the IPv6 fixed header, with that information >> also in a fixed location in the packet. If it isn't there, they give >> up and either drop the packet or forward it regardless. >> >>>> So if hosts do it - it is all great, but if network element dares to do it >>>> - it is now just a disaster ? >>> >>> Yes, because it changes the packet size mid-way, and that definitely breaks >>> PMTUD, as has been discussed here often enough. Until the rules of how >>> to configure the "controlled domain" are written in such a way as to avoid >>> this being a problem, which I expect we'll see in later versions of >>> draft-voyer-6man-extension-header-insertion. >> >> I just don't believe this is possible to do, unless there is a >> statement such as the following: >> >> "SR domains MUST NOT be attached to the Internet or any other network >> where a inserted EH, when received, would be unexpected, due to the >> consequences of failure to remove inserted EHs as the domain >> boundary." > > Hi Mark, > > in the case discussed in draft-voyer-6man-extension-header-insertion > the EH is inserted in a outer packet with a destination IPv6 address > within the "controlled domain". > > The original packet will exit the controlled domain only when it is > decapsulated by the exit node in the controlled domain. So actually, > there is no an "EH removal" operation that a node may fail to execute: > either the original packet is decapsulated and forwarded outside the > domain (and for sure it will have no EH inside) or if there are problems > they are confined in the controlled domain... as the outer packet has > only IPv6 addresses belonging to the controlled domain Also Mark - let's not prejudge the way the controlled domain might be defined and managed. And also let's not overstate the dangers of a rogue packet with an SR header escaping; in the end it will either be dropped by a paranoid firewall, or ignored by an uninterested destination. The rfc2460bis rule is to enable traffic that is *intended* to cross the Internet on an arbitrary path. Here we are talking about traffic that is in any case not intended to do so. Brian > > regards, > Stefano > >> >> Even if that was included, there would be no way to police this, and >> the victims of the failed EH removal may be far removed from the >> people who decided to insert them and who thought they were removing >> them. > > >> >> >> Regards, >> Mark. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From nobody Wed Apr 5 08:50:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960A91273E2 for ; Wed, 5 Apr 2017 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 LoC2OBDHe9II for ; Wed, 5 Apr 2017 08:50:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31234126CD8 for ; Wed, 5 Apr 2017 08:50:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 42D3E2009E for ; Wed, 5 Apr 2017 12:15:01 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 155F4636BB for ; Wed, 5 Apr 2017 11:50:42 -0400 (EDT) From: Michael Richardson To: IETF IPv6 Mailing List Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 In-Reply-To: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:50:46 -0000 --=-=-= Content-Type: text/plain Lorenzo Colitti wrote: > Remember that the use case for this option is for networks that today > provide an entire /64, such as 3GPP networks and IPv6-prefix-per-host > networks. I agree that if the network already provides a /64 or more > via DHCPv6 PD, and the clients use it, there is no need to use PIO-X. A problem is that: RFC7204 and https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf don't say a lot about what the upstream provider can expect from the CPE. Both say what the CPE should try, since they don't know what the provider provides. So it's unclear in the PPP(oE) case if we even need to number the PPP link *at all*. If the provider knew that the CPE would do DHCPv6 PD, and number itself from the result, then it could avoid putting any PIO into the RA on the PPP link. I think that PIOX provides a nice compromise: clueful CPEs can use the /64 for themselves (or for downstream tethering), and come back with DHCPv6PD if they need more, and unaware ones will just use it for the link. It seems that if a PD occurs, that it ought to overlap the prefix given out by PIOX, and use 6603. I think we should recommend this a BCP for some spaces. I think that on 3GPP, that it MAY be a bad idea, because the ISP has to reserve too much space for each customer (double to 16x the space), and they may never (or infrequently) ever need the PD. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljlElEACgkQgItw+93Q 3WWUQwf/fQVe7V/IZRAlRihPF1vLb3hmsykcUgnrkFIRkxhfj2BxAJ5IeYfxzgJc SWbBzs4XrggRWRd8Fi0+HZdRB3slFBZnTOVV5pNP4cki9NdZDh7MfxbHnsawO+QM /oU1FS4m0AASwZauNVh7SjjANYBBVcZnkUwpaCvBhzp/vNge6y+kmrtiG5v7OsWc 113qYoIqxRvOOnNZo3OpGEgOwTbNRvOXDzFn+qTxpSNgbEYNGoHZA1ElCLNPt759 +9lCNiyOA/OVtPCmav11JSNPl9uOkepLBh41WvH3R0TGreVjU6jaC+Dz+TwYH1Sd UVIkVnayOyNAfU2nu4TShW1UdbG3xw== =pUnz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 5 14:25:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0C126BF6 for ; Wed, 5 Apr 2017 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 HbWvC_BEiZ-a for ; Wed, 5 Apr 2017 14:25:56 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 BCCA9128B88 for ; Wed, 5 Apr 2017 14:25:45 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id 81so16003412pgh.2 for ; Wed, 05 Apr 2017 14:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtheFehZDCvv252Q8UVdWACMQLlAWS3eSj28X08us+4=; b=nzFroYU4W+6J8ubtxn86I+SDfw1meL1H8XP7LBRH398THaHTQjlbYbc+Oc8mo2oo4C naME37ENklcwORsyO4sMwz+pV7NT0Wyz5auW8hcB4w1S5/Zt/eHiFRsYpqLz3luJHc92 W2QuJJXLpCv77GUVVETNRlU+XxYMETIF1qrwgBI0qeHYldQI+yFe7T8DpWTQPUeD1w5M /uzV10BcD035SO3OIfW+1+B/xoc6LSwMjrDAzgXsnDtd+cBvJrKdrUR3urVMgVgGIvai 60jPOI3LAlPGQrs0YquNOpZda2+s0f/c3wbzUCC0cYjG0MeuVYtNPed4NPmietu9BcVE AdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtheFehZDCvv252Q8UVdWACMQLlAWS3eSj28X08us+4=; b=CISV6BY0V7me/q4EatJN51nZb2ygp4uXFeQUEgMao1NTj8cP4MlSaDxKohBZ18Qe35 Itjurtzs/5wTeby7wo1HCN9c+bJQ+ihe2/eE09JYy7QI6ZmSgazko7EIaaU9PIAcLFR7 3k1En7SvO83gpmQMsliYhK/zfC0Pm4frU1Hj6cm/PXOQ189TV5zcuYOM6yPn64Rs2PiU I6+GKJVQuSQfaco0JdCSfP9EoUH0g3tex1b/QdYMv7tNyX9zq+Q2PaZqRuHPxRLCB+dQ 9txTw0wQXQnRm1uEY0PYu3ojJfcMsU5bqQmkJ/niqTB+i76aXGtk8fXQyMmQBDq8Uk7P 3zDw== X-Gm-Message-State: AFeK/H3+LF1erWyJU5040oU4eb4CYRe60QkWXH2P8D2oHOzzWW38uVed1jbSjlr3XvI+4w== X-Received: by 10.84.224.198 with SMTP id k6mr38428073pln.15.1491427545432; Wed, 05 Apr 2017 14:25:45 -0700 (PDT) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id b128sm39249476pfg.54.2017.04.05.14.25.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 14:25:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 From: Fred Baker In-Reply-To: <33726db3-0759-b99a-7c92-15e6dca6d15a@gmail.com> Date: Wed, 5 Apr 2017 14:25:47 -0700 Cc: ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> <25302.1491351947@obiwan.sandelman.ca> <33726db3-0759-b99a-7c92-15e6dca6d15a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 21:25:57 -0000 > On Apr 5, 2017, at 12:17 AM, Alexandre Petrescu = wrote: >=20 > For the default route learnt from RA - indeed - can only be LL, as = there > is no field in RA specifying the address to be used as default router > (it's got from the src field). Maybe we want one(?) In that particular case, RFC 8028 suggests using the source address from = the IPv6 header.= From nobody Thu Apr 6 09:25:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8112954A for ; Thu, 6 Apr 2017 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no 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 gNgzR_1UVxnT for ; Thu, 6 Apr 2017 09:25:23 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDAE12954C for ; Thu, 6 Apr 2017 09:25:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v36GPGJ8176715; Thu, 6 Apr 2017 18:25:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F0F2A209D88; Thu, 6 Apr 2017 18:25:15 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA9F9209D5F; Thu, 6 Apr 2017 18:25:15 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v36GPFeF018617; Thu, 6 Apr 2017 18:25:15 +0200 Subject: Re: PIO-X in draft-pioxfolks-6man-pio-exclusive-bit-01 and earlier draft-kaiser-nd-pd-02 To: Fred Baker References: <8b0b8ece-c41b-910f-28e0-083e04073bf1@gmail.com> <865.1491232662@obiwan.sandelman.ca> <21708.1491238247@obiwan.sandelman.ca> <25302.1491351947@obiwan.sandelman.ca> <33726db3-0759-b99a-7c92-15e6dca6d15a@gmail.com> Cc: ipv6@ietf.org From: Alexandre Petrescu Message-ID: <07ab1a55-a701-8ff6-7960-afea4ca50783@gmail.com> Date: Thu, 6 Apr 2017 18:24:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:25:25 -0000 Le 05/04/2017 ŕ 23:25, Fred Baker a écrit : > >> On Apr 5, 2017, at 12:17 AM, Alexandre Petrescu wrote: >> >> For the default route learnt from RA - indeed - can only be LL, as there >> is no field in RA specifying the address to be used as default router >> (it's got from the src field). Maybe we want one(?) > > In that particular case, RFC 8028 suggests using the source address from the IPv6 header. But the src address of the IPv6 header of an RA can only be an LL address (can not be ULA or GUA), I think. Alex From nobody Fri Apr 7 05:54:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607D9126557 for ; Fri, 7 Apr 2017 05:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3Qycss5FHQgB for ; Fri, 7 Apr 2017 05:54:39 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 2062E129468 for ; Fri, 7 Apr 2017 05:54:32 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z13so48885050iof.2 for ; Fri, 07 Apr 2017 05:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=54yeR7zVa6stDseQajkcgOnxFNWqVjDIn4ryj8PZQos=; b=p1kVCeL1gtguboDGQYQ/PmXT2WuD+Ir+64bQu6597mVwkA8JQhHxj5IJmoCjRQdpSH PVtSBJqoKc3eu4PkVYAEZ+eQ5Ytuc9pKn6DpGpVrHCzDyonSulxV5bk7R4nTE+Lk2aZ4 4inBO20GkLnRqA8mXqdhqFv7WWlJ11mZsqFsQvm+dn9fPZIfX7GbZdtE+2CEAieYXLkT jY05h/HsWs+71asgfXXO3P3O/mEe0veXIh6wdR8RzSACFUYRm9LlHMrF7wGcbMDpUB41 aCXi8LTvnmtsHP/f7kxUhtum80E4zajhaakPFAY2p8HaHY7blcVJ2kznA4+6YhekNZp1 o5jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=54yeR7zVa6stDseQajkcgOnxFNWqVjDIn4ryj8PZQos=; b=OJYUnZD7yZPAO9iPMbUfALM9S+YYSfMgSXGmkmaH7AJ9/1ASsgGlTzXPwLi6ukqFrn /zg1l48zcLA3MutGYsltgRDyFEnY77QsLSCz071/2ISE1QOv20W93Sgvnb4moO18qY4l nvZMZEcPLeCh4X5VNdvWYT2/NOfzsI53ZRPXQsdENashqoZNQItTUvlOgDRZbcOqJY7x fhcQ9nRJggLz5CMADL1A4J7tFRtF/bvn3jKvtj2VP+g0ODg0h8jVeM7yoJLEUb7Pbv5I 0laLewTqZDChTEKYgrxzouGY8edQQgU7xLhYzZbAGFlFdbZ6SXBBDbkcjqTYHn3fLP3P zsew== X-Gm-Message-State: AFeK/H0fHY+NuMDtisQFNs+MhLSU2pkZL1qPVBAQInsKQ4PR/ryQvTz7y40SrOPrv1Y0yf4OQl4YpuOAxkjM7A== X-Received: by 10.107.136.96 with SMTP id k93mr37596999iod.20.1491569671485; Fri, 07 Apr 2017 05:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 05:54:10 -0700 (PDT) In-Reply-To: <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 14:54:10 +0200 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Brian E Carpenter Cc: 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:54:42 -0000 On Wed, Apr 5, 2017 at 12:18 AM, Brian E Carpenter wrote: > As far as I can see this proposal makes sense and should work. Thanks a lot for reviewing! >But: > >> 1. The link-local address of the router in the new layer 2 domain >> might be the same as the link-local address of the "old" router >> (it's quite common to have link-local address on routers to be >> explicitly configured, especially in VRRP-enabled environments) > > Wow. Shouldn't there also be an operational recommendation to configure > non-clashing or at least highly-unlikely-to-clash addresses for > such routers? Well, maybe we should write smth about it. However link-local addresses are meaningful and should be unique *on link*. I can not see how/why we shall require them to be unique among all interfaces on two (or more) routers. I do see people configure fe80::1 as a vrrp link-local-address and I'm afraid that even we try to convince the whole world that it's not a good idea, we might not achieve 100% success ;) -- SY, Jen Linkova aka Furry From nobody Fri Apr 7 06:04:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7CE12946C for ; Fri, 7 Apr 2017 06:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ACc4nLoCZOC1 for ; Fri, 7 Apr 2017 06:04:32 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 6A50A1200F1 for ; Fri, 7 Apr 2017 06:04:32 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l7so48689836ioe.3 for ; Fri, 07 Apr 2017 06:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n0mfrL+zu57pqyo+p0RkeK71qpBIkK2Fjb0xX/ixQOw=; b=rdgFmuCf8DjRQxL3DFqz76E9sVi4DprD0XroV1fnElTLGsSjkb2FMw6dG8VSOL/4s3 Xo47EOjzqogcMAtZtZig88YBBiYJiRhlKxtyJFgYsFP6yl9cwGRTGknTfwTP9Qmp2h03 VcLbMDOkWX0W1lCQnZSqBiWO9STX2sRmmO9OnzpudfIPdRozYQU2M5aCenyJvobV9V1m znPRLisZTKegqp4jqg8lUU/1esR85j1pZf44o2wb2iUo1ElD7ZdOZVayE9NFLUT8dBDR cETWKrYZzQfwo3FaEzUu2u5m3OxQTzO3f/XHuQlKxVvtIo/zRp5F0j8FXjUPIYHk6429 +PNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n0mfrL+zu57pqyo+p0RkeK71qpBIkK2Fjb0xX/ixQOw=; b=g8v1isXLbscAeq8YpRsJfDpbLJCZmweZxhGXsD2c4LXaEHj8vCyp9pWAWL0/KQAe4I Ubdhekh+z3WYsixc7Z49aZhLWZQdG8AOVu4jOkmhumXtRvg0RXyeehcEMDTVjnlI5THy mRaYkBb1Mmf1nm2CiePE1kbUi9COJ7XzhHSE5E4nfLb2ONAOwNPpitjZmtAVvlKEJrZh NvWwZ3WvYN/eXu4AXgwqbtjyrK2nYmyVZ9E1Kz3mr7KC+YOPHkF0T3wy2BYNr4r9yiQz ZqFbLWpRwhqXwQ6Q0BZeUoyQCZ0VSWfcnCssSaq5uH/OdqoKPn0L4gfxkT8nSIdB3+sq E5UQ== X-Gm-Message-State: AFeK/H0XUG2J7Rs+lLQyzgLMHd0MDc51LY9RDpvMXI2qEncDELLTP7lJveQINmM+Ve5G7tgqpflZQ2wHPyBKGQ== X-Received: by 10.107.136.96 with SMTP id k93mr37654793iod.20.1491570271744; Fri, 07 Apr 2017 06:04:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 06:04:11 -0700 (PDT) In-Reply-To: References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 15:04:11 +0200 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Mark Smith Cc: Brian E Carpenter , 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:04:34 -0000 On Wed, Apr 5, 2017 at 4:35 AM, Mark Smith wrote: > On 5 April 2017 at 08:18, Brian E Carpenter wrote: >> As far as I can see this proposal makes sense and should work. But: >> >>> 1. The link-local address of the router in the new layer 2 domain >>> might be the same as the link-local address of the "old" router >>> (it's quite common to have link-local address on routers to be >>> explicitly configured, especially in VRRP-enabled environments) >> >> Wow. Shouldn't there also be an operational recommendation to configure >> non-clashing or at least highly-unlikely-to-clash addresses for >> such routers? >> > > I think RFC8064, "Recommendation on Stable IPv6 Interface Identifiers" > is indirectly making that recommendation. > > One of the use cases of RFC7217 is for router interface's Link-Local > addresses, and to not use use the interface's MAC address as the > Net_Iface value (e.g., module/slot number, ifindex instead), so that > the router's Link-Local IID is both unique and doesn't change if the > physical interface module is replaced, which usually means an > interface MAC address change too. I probably need to make the text a bit more clear but the use case I've observed has nothing to do with SLAAC, so neither RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs manually (see http://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/virtual-link-local-address-edit-interfaces.html and http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/b_ipaddr_cg42crs_chapter_01010.html#task_96270599CAEE43DDB370F262D8C0722A for two random examples) and it's understandable that they do not want to generate an unique LLA for each interface (LLAs are supposed to be unique within a link, right? so it's perfectly fine to have fe80::1 configured on each interface). It's operational reality, it does make sense (or we shall stop pretending that LLAs have link scope...;( ) so I believe it would be nice to tweak the source address selection a bit to deal better with the real life..;) -- SY, Jen Linkova aka Furry From nobody Fri Apr 7 06:12:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8A127977 for ; Fri, 7 Apr 2017 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 CwLqLkaJ19ZL for ; Fri, 7 Apr 2017 06:12:07 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 3305E12946C for ; Fri, 7 Apr 2017 06:12:02 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id p77so34160973ywg.1 for ; Fri, 07 Apr 2017 06:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vrTNaU7w3h9JlXnlUf+IqvlRJxoRcY0qenbENHEDuo=; b=aPJtS7YPRN4GRRlqfwB0PZIxTFpEU7ETREJEfu8PFO2/ym+JcGFCcfjsnq9TDsid3s bhTivC7bMIvG7ABoqA+ghxMvCdGNlz+4nVKYN0X0lMM/Up1y0PDiy+Cu8anSxjOYS/4Z 5lPILyt2IoZ2WlQi27SMqKEJkRd7rkXbL9ux1IirgzeBlsV7BiYbbacrF1qIyB3O/whD OWnyzNSD6Xs5DONlyM4AUB4+wVO3kuz+ivjkxXJGWlKeNofKmOMDM4qQA7jOczD8WHn0 1yQGWZHK+AIcNMFas6pmqoYa2fLtjwTGQ1u4Xkbv9lGNA2lGn5TgIwSoL8Qw/L3NBkum l47Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vrTNaU7w3h9JlXnlUf+IqvlRJxoRcY0qenbENHEDuo=; b=tdJnnD6PNtcGKd60Jqm7b2Uz+DPvVXJJ77VKk3uOaMr1YqM3qvwa50HopOBhsON+Ny QKwUlNfkJBq4bPKN8q19aC3XBX8qjmfRPC0ZigxwG0NAoCtcHuG2y1oOx6W4aHgirejR rOKlrnZ9Ulf5n60IVYfwbavvQlypVB2wvZj6SMkQeZpuRfCKGJywmSXPdL+kPL5CKR+9 /HWXP5bQjlc+kai/ff1NCN2wwp2rfHzojTPKXzlunGdwEVNTEPAQbKn+r/Thgf86htRr ykdug5DJkstGygQVABaRzS8lTdTNMU1pvu4yG7asDzUQBZW7Kq+YIk66U3Kb3pZm5OX7 vBHA== X-Gm-Message-State: AFeK/H2n+i+1fKqU39ycVjrMMxbfjOmc/lhkn79F2goY2IhvDp2Nh8h3IhfzP4JZwfOG5xLyiUDtMToSOyI1eITs X-Received: by 10.13.242.198 with SMTP id b189mr25740567ywf.243.1491570721000; Fri, 07 Apr 2017 06:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.12 with HTTP; Fri, 7 Apr 2017 06:11:40 -0700 (PDT) In-Reply-To: References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Erik Kline Date: Fri, 7 Apr 2017 22:11:40 +0900 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Jen Linkova Cc: Mark Smith , 6man Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0356ec04637c054c935ffa" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:12:10 -0000 --94eb2c0356ec04637c054c935ffa Content-Type: multipart/alternative; boundary=94eb2c0356ecfc1d0f054c935e90 --94eb2c0356ecfc1d0f054c935e90 Content-Type: text/plain; charset=UTF-8 On 7 April 2017 at 22:04, Jen Linkova wrote: > On Wed, Apr 5, 2017 at 4:35 AM, Mark Smith wrote: > > On 5 April 2017 at 08:18, Brian E Carpenter > wrote: > >> As far as I can see this proposal makes sense and should work. But: > >> > >>> 1. The link-local address of the router in the new layer 2 domain > >>> might be the same as the link-local address of the "old" router > >>> (it's quite common to have link-local address on routers to be > >>> explicitly configured, especially in VRRP-enabled environments) > >> > >> Wow. Shouldn't there also be an operational recommendation to configure > >> non-clashing or at least highly-unlikely-to-clash addresses for > >> such routers? > >> > > > > I think RFC8064, "Recommendation on Stable IPv6 Interface Identifiers" > > is indirectly making that recommendation. > > > > One of the use cases of RFC7217 is for router interface's Link-Local > > addresses, and to not use use the interface's MAC address as the > > Net_Iface value (e.g., module/slot number, ifindex instead), so that > > the router's Link-Local IID is both unique and doesn't change if the > > physical interface module is replaced, which usually means an > > interface MAC address change too. > > I probably need to make the text a bit more clear but the use case > I've observed has nothing to do with SLAAC, so neither > RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs > manually > (see http://www.juniper.net/documentation/en_US/junos/topics/reference/ > configuration-statement/virtual-link-local-address-edit-interfaces.html > and http://www.cisco.com/c/en/us/td/docs/routers/crs/software/ > crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/b_ipaddr_cg42crs_ > chapter_01010.html#task_96270599CAEE43DDB370F262D8C0722A > for two random examples) > > and it's understandable that they do not want to generate an unique > LLA for each interface (LLAs are supposed to be unique within a link, > right? so it's perfectly fine to have fe80::1 configured on each > interface). > It's operational reality, it does make sense (or we shall stop > pretending that LLAs have link scope...;( ) so I believe it would be > nice to tweak the source address selection a bit to deal better with > the real life..;) > > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > It is a sad, but seemingly true, state of affairs that all of this blows up the core DNAv6 working assumption: https://tools.ietf.org/html/rfc6059#section-1.5 o The combination of the link-layer address and the link-local IPv6 address of a router is unique across links. --94eb2c0356ecfc1d0f054c935e90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 April 2017 at 22:04, Jen Linkova <furry13@gmail.com> wrote:
On Wed, Apr 5, 2017 at 4:35 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> On 5 April 2017 at 08:18, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> As far as I can see this proposal makes sense and should work. But= :
>>
>>>=C2=A0 =C2=A0 1.=C2=A0 The link-local address of the router in = the new layer 2 domain
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 might be the same as the link-local= address of the "old" router
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (it's quite common to have link= -local address on routers to be
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 explicitly configured, especially i= n VRRP-enabled environments)
>>
>> Wow. Shouldn't there also be an operational recommendation to = configure
>> non-clashing or at least highly-unlikely-to-clash addresses for >> such routers?
>>
>
> I think RFC8064, "Recommendation on Stable IPv6 Interface Identif= iers"
> is indirectly making that recommendation.
>
> One of the use cases of RFC7217 is for router interface's Link-Loc= al
> addresses, and to not use use the interface's MAC address as the > Net_Iface value (e.g., module/slot number, ifindex instead), so that > the router's Link-Local IID is both unique and doesn't change = if the
> physical interface module is replaced, which usually means an
> interface MAC address change too.

I probably need to make the text a bit more clear but the use case I've observed has nothing to do with SLAAC, so neither
RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs man= ually
(see http://www.juniper.net/docum= entation/en_US/junos/topics/reference/configuration-statement/virtual-link-local-address-edit-interfaces.html
and http://www.cisco.com/c/en/us/td/docs/routers/crs/softw= are/crs_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42crs/= b_ipaddr_cg42crs_chapter_01010.html#task_96270599CAEE43DDB370F262= D8C0722A
for two random examples)

and it's understandable that they do not want to generate an unique
LLA for each interface (LLAs are supposed to be unique within a link,
right? so it's perfectly fine to have fe80::1 configured on each
interface).
It's operational reality, it does make sense (or we shall stop
pretending that=C2=A0 LLAs have link scope...;( ) so I believe it would be<= br> nice to tweak the source address selection a bit to deal better with
the real life..;)


--
SY, Jen Linkova aka Furry

----------------= ----------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

It is a= sad, but seemingly true, state of affairs that all of this blows up the co= re DNAv6 working assumption:

=C2=A0 =C2=A0=C2=A0https://tools.ietf.org/html/rfc6059#section-1.5<= /a>

=C2=A0 =C2=A0o =C2=A0The combination of the link-l= ayer address and the link-local IPv6
=C2=A0= =C2=A0 =C2=A0 address of a router is unique across links.
--94eb2c0356ecfc1d0f054c935e90-- --94eb2c0356ec04637c054c935ffa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg2BK3mOCdF83DMN0dkjjgHcw8t7Ut49Mo EIdrxx5/AKUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA3 MTMxMjAxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAFVDG2KPOUdxKCUyIB/Q5NFvS+igMEWYix3eq8Wvx2xv799/Ky41 I3+ZtQDru0IldQ4eR1h0tyGySTBUY2JnUqfA90CnLUPh4xJiPCeXeV3NH3Yd2qPAdZvJglSZfuzL MVXNFOrfl5r8v065cCPRLqeSN40xdrcnXN2OLhU49vsfYxUQqKe6O9cKFCaRJgHYEn9vx9nH6fyd wAt9eggfvFpCw3sEMx8DorKRD+ywh3B9frBe1iiaoexxKjSB9v8736U8UySF2TrR4xQs0/5xGhH1 QX6OFaRAsNYGbTeYyNO0E2aRoFlQV4vMkSbbRXaazHGPXfYJNYL1xnJRqhA3Tp0= --94eb2c0356ec04637c054c935ffa-- From nobody Fri Apr 7 06:21:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337E7126557 for ; Fri, 7 Apr 2017 06:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WPd7EhvMEaec for ; Fri, 7 Apr 2017 06:21:28 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 0BB451242EA for ; Fri, 7 Apr 2017 06:21:23 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id y18so119025462itc.0 for ; Fri, 07 Apr 2017 06:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B19i5NJrV/iCx0UbJT95G6GtJefFfOPsdlm9tSi/Wr4=; b=i9RQe4d6oWhCHZCgcoXzuzPa7mVnwOyxezZM2CVlzt7ypK0JIJGr/wk2OS3QpAh6Ae Q+kGu8xy7KUFvhgpPC3geHp8/twuOXCNvv8JpPhigdns9HGUIfmKCJx1w4Zaq8pS0xtS +bB/coGmJodfADG1/nXGkpJhQ+3CH/OkA4c8saybK+cSNhfw6cnklW/BH3QheiKKo04G xWPiTkIcN+BcLfbSPTOatETnMSWfkBwDBVtVMwCSDo0ePeLUZm9ImCOiIhxBT+PSqJwf O/AElDBnywHFgCyy/P6n5IiGN3Xwzf5gBUaYZNSfB8k7BrKLwjYXFKjlJKZYgBB+S0Wg Fjpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B19i5NJrV/iCx0UbJT95G6GtJefFfOPsdlm9tSi/Wr4=; b=r3oV4aXWpeyrawhogR3u46usy+y2H2/iy/3n5FEEwXXxW33ehrNBhKbzT88kaG+jGi c53J74TaRsImfEkV5xOhNsXluUlb1MBgtLWwBrhx4FTThzo/NCmey+wxEsllDvfBkEND gKGA6BRGacDz6wFwfCkLrCR0wr0AYNQAiBLhs9ub2w19Apx9eFE1IlYWxBNtJ+2ghbwY vSgBc0DHDx0s7B9mR5/5BWb8GvnWeaZ45mFa70hrXX/pvDkbvoBRE9jN9nurnHd9HRq/ QW1S3oNYA1LJT2L54c89bqvxpmtWydwTM9mYTnsp27zHSCme5B+TbZKcsD9kLDrVeSTO tovQ== X-Gm-Message-State: AFeK/H3yJGfydk82KAh8WLSj+sENoZIIDJmMa+VTMaJ/wEQLld9CVKZz5BQQOVM3XSO42LKSHRPVYEj7f2715A== X-Received: by 10.36.16.21 with SMTP id 21mr21842563ity.66.1491571282424; Fri, 07 Apr 2017 06:21:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 06:21:01 -0700 (PDT) In-Reply-To: References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 15:21:01 +0200 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Erik Kline Cc: Mark Smith , 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:21:30 -0000 On Fri, Apr 7, 2017 at 3:11 PM, Erik Kline wrote: >> I probably need to make the text a bit more clear but the use case >> I've observed has nothing to do with SLAAC, so neither >> RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs >> manually >> and it's understandable that they do not want to generate an unique >> LLA for each interface (LLAs are supposed to be unique within a link, >> right? so it's perfectly fine to have fe80::1 configured on each >> interface). >> It's operational reality, it does make sense (or we shall stop >> pretending that LLAs have link scope...;( ) so I believe it would be >> nice to tweak the source address selection a bit to deal better with >> the real life..;) > It is a sad, but seemingly true, state of affairs that all of this blows up > the core DNAv6 working assumption: > > https://tools.ietf.org/html/rfc6059#section-1.5 > > o The combination of the link-layer address and the link-local IPv6 > address of a router is unique across links. Well, I'd expect that the combination of the L2 address AND LLA v6 address would still be unique (unless people are explicitly configuring L2 addresses or MAC addresses are not unique - both cases do happen but from my limited experience, not so often as explicitly configured VRRP LLA Ipv6 addresses). -- SY, Jen Linkova aka Furry From nobody Fri Apr 7 06:25:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED6129461 for ; Fri, 7 Apr 2017 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=google.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 UZCF2oAekpOi for ; Fri, 7 Apr 2017 06:25:42 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 D1F68129473 for ; Fri, 7 Apr 2017 06:25:35 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id f204so16967923ybc.2 for ; Fri, 07 Apr 2017 06:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MSkLPUu91LGTpZyHtkxxo9hE5tPWsvO4E1DFeEMqPYU=; b=AJv1vZDfSYZqDaBc50QNe55cMK7rq0+V1tmL4FBdk/1Jqe+9k8HcOtbjx/dIqX25F2 AIGsWoTgIDl3ZylpLvM1jKAW20y3gbuIBGq3U6TyMXYsx7RMT5iZSWGse3wuccIJ1DSt Ch9Ajl/AHpe9gyiaKe3pmXRwkyCyWTMiY0wUYSfHtkbH7iBTK2Qf3C8kE99oZL0IxFlN 9NRbjJvKsHK1189wvtcUzponBXJzXfJg1/Z8Zxg9hfrTZXHEledtavhUBKELy0wiGH5B FWBwwYZZjlOzlEwi1QYxZFEceM1obCgh2r7rG2gCWUlDnaRkCXzEWo+FuFdm3xDg52L9 VqrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MSkLPUu91LGTpZyHtkxxo9hE5tPWsvO4E1DFeEMqPYU=; b=jGMaER4lFaBsQVKmsg2GFHYcPyi31D45EWL+9jTI2atVu4X3CGdrepqbkgEXtX70tk JzNJBaOOuAF66pV05vZNX3rdrOUdVJaoF1ViWfZD9BhH6x6oYRtHwToFUtv4HePwHawd X6yd7FO+qX5zlMPOjZZD9d//yLhE73NPWupTFrSK/jkMbhklQZczNlA5GPgLmDPhzZH0 2iN+KjDA1KqE4D37lydg/BeJkECKLQTYwQwk2xJ24leOnLMfwOpMdzF+wsw8URr15/s1 3T5bxBOGd3EBZbVGXuCCjX13tEdQInevKBmjQMNrJS05XkH1PoCogYjnG1HrxNK6Rh/k NSYg== X-Gm-Message-State: AN3rC/4q9hbwoPNvspode3w/2Ea9LUIvgwp2akVySbOaXvvlRGpIaILtOUKjKK8YUdpD2sqKTzVVRIUgmNuLUleD X-Received: by 10.37.104.14 with SMTP id d14mr8922790ybc.27.1491571534631; Fri, 07 Apr 2017 06:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.220.12 with HTTP; Fri, 7 Apr 2017 06:25:13 -0700 (PDT) In-Reply-To: References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Erik Kline Date: Fri, 7 Apr 2017 22:25:13 +0900 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Jen Linkova Cc: Mark Smith , 6man Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045c01fe8474ab054c938fe7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:25:47 -0000 --f403045c01fe8474ab054c938fe7 Content-Type: multipart/alternative; boundary=f403045c01fe7b359f054c938f2b --f403045c01fe7b359f054c938f2b Content-Type: text/plain; charset=UTF-8 On 7 April 2017 at 22:21, Jen Linkova wrote: > On Fri, Apr 7, 2017 at 3:11 PM, Erik Kline wrote: > >> I probably need to make the text a bit more clear but the use case > >> I've observed has nothing to do with SLAAC, so neither > >> RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs > >> manually > >> and it's understandable that they do not want to generate an unique > >> LLA for each interface (LLAs are supposed to be unique within a link, > >> right? so it's perfectly fine to have fe80::1 configured on each > >> interface). > >> It's operational reality, it does make sense (or we shall stop > >> pretending that LLAs have link scope...;( ) so I believe it would be > >> nice to tweak the source address selection a bit to deal better with > >> the real life..;) > > > It is a sad, but seemingly true, state of affairs that all of this blows > up > > the core DNAv6 working assumption: > > > > https://tools.ietf.org/html/rfc6059#section-1.5 > > > > o The combination of the link-layer address and the link-local IPv6 > > address of a router is unique across links. > > Well, I'd expect that the combination of the L2 address AND LLA v6 > address would still be unique (unless > people are explicitly configuring L2 addresses or MAC addresses are > not unique - both cases do happen but from my limited experience, > not so often as explicitly configured VRRP LLA Ipv6 addresses). If people are using the VRRP MAC space, then I don't see a lot of room for uniqueness: https://tools.ietf.org/html/rfc5798#section-7.3 --f403045c01fe7b359f054c938f2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 April 2017 at 22:21, Jen Linkova <furry13@gmail.com> wrote:
On Fri, Apr 7, 2017 at 3:11 PM, Erik Kline <ek@google.com> wrote:
>> I probably need to make the text a bit more clear but the use case=
>> I've observed has nothing to do with SLAAC, so neither
>> RFC 7217 nor RFC8064 are applicable here. People do configure VRRP= LLAs
>> manually
>> and it's understandable that the= y do not want to generate an unique
>> LLA for each interface (LLAs are supposed to be unique within a li= nk,
>> right? so it's perfectly fine to have fe80::1 configured on ea= ch
>> interface).
>> It's operational reality, it does make sense (or we shall stop=
>> pretending that=C2=A0 LLAs have link scope...;( ) so I believe it = would be
>> nice to tweak the source address selection a bit to deal better wi= th
>> the real life..;)

> It is a sad, but seemingly true, state o= f affairs that all of this blows up
> the core DNAv6 working assumption:
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/<= wbr>rfc6059#section-1.5
>
>=C2=A0 =C2=A0 o=C2=A0 The combination of the link-layer address and the= link-local IPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0address of a router is unique across links.<= br>
Well, I'd expect that the combination of the L2 address AND LLA = v6
address would still be unique (unless
people are explicitly configuring L2 addresses or MAC addresses are
not unique - both cases do happen but from my limited experience,
not so often as explicitly configured VRRP LLA Ipv6 addresses).

If people are using the VRRP MAC space, then I don'= ;t see a lot of room for uniqueness:

--f403045c01fe7b359f054c938f2b-- --f403045c01fe8474ab054c938fe7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgFt5VByGYaTjKKc6PtZvSV9yCkPMlJowF iWMEqBh+PP8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDA3 MTMyNTM1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACN/wSH+blMH1s8vLKXeiFsV/64bhYHAzSG2XIBfpg653nfK7eI0 69mW0T/UY5XkpGpQzgagCKcKIWs1LM46nnuZZvBFcUcGgtxAeIGW9uAQ4Dyn3YqRfn8tb4uLvknn qHQZcP72dk2NZAh1fFQgdPk0h7MQGAnG/JaR7Cn1whP1UmpIRYgQYVsrpeFuAXHdiE+VLmDU6HC7 DEHZEKWlz4azBHMVEFi5X0LIBEbCq0Rc+pJNwkpR3D+dAcfqZyfP9wuvBTNZnTxnpyhSBlqqFBF+ EDjfvFHlxpaOU0zJelyCaeEimQHoSIOI5nDHT17Hpw27WqyaeCfe2Bi4m3+ajAY= --f403045c01fe8474ab054c938fe7-- From nobody Fri Apr 7 06:33:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09C912948E for ; Fri, 7 Apr 2017 06:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 o4zpFTrC8ABG for ; Fri, 7 Apr 2017 06:32:50 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 3318C1294B3 for ; Fri, 7 Apr 2017 06:32:50 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id r69so74947475vke.2 for ; Fri, 07 Apr 2017 06:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YQdlHlq7IwsFwNDdwrI1ZCD98SKmMzC8v/oXiFKNwvM=; b=LOcklXlR2F6z9q454Bt/L/Y5zQZjIVZLUo+NjjkCM9NEhEpfYuEkjVp8IS+5Ic4fbG WMlwq3XzgHPowjYhZL+QUl7ZSu45s/3RpQ+wpoX9zAHLRvnbafSDZgIQTUjBKJw7cFt6 Xr05Zn3tWGlpVU5pPdHKkmCYvV/Hea/DFW8BOJtYkWdLqzX7ur2pIE63jJuxh/bhQYcB Td/wGhPnfxUTik0RFbjNRJF1nxSlpFzSyT00bE7bYxhOuVuoFmKKZHFfM7pLyHSxhQvj U5ZPuAhUwMT12NqvrQLThwaFxSPr8hZw4e0G1jxOJWlEpF/e34Rip3+Cy4rb5n9ueFWW H/iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YQdlHlq7IwsFwNDdwrI1ZCD98SKmMzC8v/oXiFKNwvM=; b=D4PoFlQQv6mt9nx9sgq2hw4ANBNveOBojKIvByhrA0GqtZw6iHFUhJxJXHceocXoxv tiDQJSBo6+NIJZgf8onRwjGXeVkdAQ86sQwSW4FOpgOdCId0N82srBrySrNJooKv6xuS nm4VSGQqiyXrjIXwnC7nWu36vfTA8WjJptIlceSkSNo4Lh0BFQe/bOXEmv8nf/hNqpou xX2jNBd4zsMvyaCE0Es80wzu6EbnBcokyydeJDZp0MzuGbVjXmiCoaVjKdEDXv+Su9VF o0i0lDXrLoc2n7jcqgAk+AWobwzFOitt7lePNQIaID4a83ubh2weFzeNqhSMJwYmaUWP tG/w== X-Gm-Message-State: AFeK/H17nD1k0dITcPFoxSR8CcW+QbV9EkO50uM2bcdagwA2MmYmY3MVu7+3o87wFPntieULlKZDr3A7WsnMFYlL X-Received: by 10.31.11.73 with SMTP id 70mr18556785vkl.83.1491571969098; Fri, 07 Apr 2017 06:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 06:32:48 -0700 (PDT) Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 06:32:48 -0700 (PDT) In-Reply-To: <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 22:32:48 +0900 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: "Brian E. Carpenter" Cc: IETF IPv6 Mailing List Content-Type: multipart/alternative; boundary=001a11437e88606d9b054c93a91b Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 13:33:01 -0000 --001a11437e88606d9b054c93a91b Content-Type: text/plain; charset=UTF-8 On 5 Apr 2017 07:18, "Brian E Carpenter" wrote: Wow. Shouldn't there also be an operational recommendation to configure non-clashing or at least highly-unlikely-to-clash addresses for such routers? There's no way to do "highly unlikely" with only 256 VRRP groups. --001a11437e88606d9b054c93a91b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 5 Apr 2017 07:18, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wr= ote:
Wow. Shouldn't th= ere also be an operational recommendation to configure
non-clashing or at least highly-unlikely-to-clash addresses for
such routers?

There's no way to do "highly unlikely" with only 25= 6 VRRP groups.
--001a11437e88606d9b054c93a91b-- From nobody Fri Apr 7 07:02:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9B1294B3 for ; Fri, 7 Apr 2017 07:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 U4a1lizDiuJ6 for ; Fri, 7 Apr 2017 07:02:50 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 73E961294B8 for ; Fri, 7 Apr 2017 07:02:50 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id a140so43171583ita.0 for ; Fri, 07 Apr 2017 07:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IvnSWd/QhUrnOwhZMpjYRmBSeG3vJlmkh5Dcvfag3V0=; b=Hu9MVmcBbmQ2EWMATJwv6m/zp5mgZ+sOwq26nnA8rd0y97qHrKmC0fyoSKzIY3GLXU +yMw8kddW2Ax2ajIhQ2My49BAmawoErdyNs+FAAl+dGqYmAvHRKVskmJcXFT67ue3Zur J3YMeteeypDCVUO7qkXiBiwtkLbiWhgBODmlnPQnMULtW4xN63S8CthMlM41CglTx56V tbMWVNmPNvbRU8uXTOZJUB7QHEyrLFfzUVpRzdjKO67zDFH1dQhv9UhovVD82F2kpi/s opdnd/QpxxDQE8d5miqfmWqbBdNuWNcAOiVuwPOvgi+j+Du60znc+zajnpETRDnu6Htl +VxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IvnSWd/QhUrnOwhZMpjYRmBSeG3vJlmkh5Dcvfag3V0=; b=K4I7nSNIyHeCllWzMosuBiwkkU88ksjAp7yk5geVpt1p4hRIlfXoUEBrJhAHi5lV10 /8Y0iktvuJFEKLoKO/y9OytWRcxm0gmCgQJMm2d30mxW77Sv7sgEP7YtpQWc7q7xvzP8 p8cVjHL0PIOcKzCaav6GCFFf6jB+yIb+gV8UvtRL7SBwNeDPu+xgrM7gpP3A7xWXPYQo dP2JrzJ9euJpB/micTlcSoh7f2ZRJGbA94G6CR5D8495d7j+BWRrojydVkmlIazFW9f+ EIdbxw1Q1prSK55HHWy4FgwqTJl2l8lid8MOOhwXxrDFhxDrWyiftjbcOM3ZIyPL+Nfk w/4g== X-Gm-Message-State: AN3rC/7QxvlVX9QMbU2JyfqdJVtpE6tkeC7uahQkWiPMt+ONBWSBY2Tv cEdylVNpquGytglcHNfXoanm/KRyIQ== X-Received: by 10.36.190.206 with SMTP id i197mr1216613itf.18.1491573769776; Fri, 07 Apr 2017 07:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 07:02:29 -0700 (PDT) In-Reply-To: References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 16:02:29 +0200 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Erik Kline Cc: Mark Smith , 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:02:54 -0000 On Fri, Apr 7, 2017 at 3:25 PM, Erik Kline wrote: >> > It is a sad, but seemingly true, state of affairs that all of this blows >> > up >> > the core DNAv6 working assumption: >> > >> > https://tools.ietf.org/html/rfc6059#section-1.5 >> > >> > o The combination of the link-layer address and the link-local IPv6 >> > address of a router is unique across links. >> >> Well, I'd expect that the combination of the L2 address AND LLA v6 >> address would still be unique (unless >> people are explicitly configuring L2 addresses or MAC addresses are >> not unique - both cases do happen but from my limited experience, >> not so often as explicitly configured VRRP LLA Ipv6 addresses). > > > If people are using the VRRP MAC space, then I don't see a lot of room for > uniqueness: > > https://tools.ietf.org/html/rfc5798#section-7.3 oops, I stand corrected. You are right indeed, the MAC will be the same (assuming VRID is not changing between the interfaces, which is most likely to be the case). -- SY, Jen Linkova aka Furry From nobody Fri Apr 7 07:05:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E066C12441E for ; Fri, 7 Apr 2017 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 7ztrvpaxTdEe for ; Fri, 7 Apr 2017 07:05:37 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 C5452126C3D for ; Fri, 7 Apr 2017 07:05:37 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 19so23793840itj.1 for ; Fri, 07 Apr 2017 07:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eYoeHtv8OCrrYbeuUn15EbbDJuH3VEMBVdAIbw/BnKA=; b=DZDYDb+KH7tgYBdr3FbRbr7nfg/cogaGu2zfl+V4lbqTlyasV5/2EB/b1hNmGtA7gj 4tYaSTvZTawan++NxyQvaP19NQ8jKKZMhEmkiP97Qe5P/fqOxkSUpMKdspvAvA8UT5xp DDRWiJb4XUlkdRKcfNkQ8FLyrOUYXXsCeUxNx5JDCgr/w6C68tjzzr69a87fBkp6wQ3I P8+lVE2+WnwS5cI+0qFakO7AGffloSLp3Zkz/atrjGgry4QKa+TWgKgoqJnugOiiMW5Q ye8UUJCkMrh9sEfWzV44agcIsJ7VE4RtSNTtBzUFMHC7H2bxajNR3UNKCalxAqbBg4Zs zsmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=eYoeHtv8OCrrYbeuUn15EbbDJuH3VEMBVdAIbw/BnKA=; b=dqb/BwPYZMWLftVrqm2kzZD8XRen7qRsRT5kBx1kxXs4q+y0RH6Ldt65alt+30WkgP BJmpIkHS25PJIdhjiHfFwGtMdyBZVtXuJM0zmUeSUr51j3+dVBszWxHEY5ngDODr90sB YLOf6vflEebLQK6WSEoMwLKe4qafAvhZzrQxXKRQhHMYasexhGFIJFrOfnFP3ULqgRUE gmEM7bmbXvBEfSMWY8Be1UyXK6JeSTNLfMiHzHQ9uBZ5UZEVkb+QCN8y3y8dapf5Pfvv RE3Wt3ANy6+12hq+Rc2uj7Cylqhw5n+Yf6PIR6hvVoX4biexe7bgC0+LC4BOkIWPNeND YFFw== X-Gm-Message-State: AFeK/H3+jUzZ/t6j003LL66+zj8a5+rAYH8rQGrnEC5IINnDxpEFDJBP xT+bmtCzWYVZrw== X-Received: by 10.36.23.86 with SMTP id 83mr31540415ith.30.1491573937135; Fri, 07 Apr 2017 07:05:37 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id g64sm2449463iof.25.2017.04.07.07.05.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:05:36 -0700 (PDT) Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Erik Kline , Jen Linkova References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> Cc: 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> Date: Sat, 8 Apr 2017 02:05:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:05:40 -0000 On 08/04/2017 01:25, Erik Kline wrote: > On 7 April 2017 at 22:21, Jen Linkova wrote: > >> On Fri, Apr 7, 2017 at 3:11 PM, Erik Kline wrote: >>>> I probably need to make the text a bit more clear but the use case >>>> I've observed has nothing to do with SLAAC, so neither >>>> RFC 7217 nor RFC8064 are applicable here. People do configure VRRP LLAs >>>> manually >>>> and it's understandable that they do not want to generate an unique >>>> LLA for each interface (LLAs are supposed to be unique within a link, >>>> right? so it's perfectly fine to have fe80::1 configured on each >>>> interface). >>>> It's operational reality, it does make sense (or we shall stop >>>> pretending that LLAs have link scope...;( ) so I believe it would be >>>> nice to tweak the source address selection a bit to deal better with >>>> the real life..;) >> >>> It is a sad, but seemingly true, state of affairs that all of this blows >> up >>> the core DNAv6 working assumption: >>> >>> https://tools.ietf.org/html/rfc6059#section-1.5 >>> >>> o The combination of the link-layer address and the link-local IPv6 >>> address of a router is unique across links. >> >> Well, I'd expect that the combination of the L2 address AND LLA v6 >> address would still be unique (unless >> people are explicitly configuring L2 addresses or MAC addresses are >> not unique - both cases do happen but from my limited experience, >> not so often as explicitly configured VRRP LLA Ipv6 addresses). > > > If people are using the VRRP MAC space, then I don't see a lot of room for > uniqueness: > > https://tools.ietf.org/html/rfc5798#section-7.3 > The problem is section 7.4. It should be updated to RECOMMEND RFC7217/8064. That also answers Lorenzo's point: > There's no way to do "highly unlikely" with only 256 VRRP groups. But Jen is correct, we also have to consider reality with clashing addresses. Doesn't that mean that "when the host moves from one network segment to another" we should suggest that the stack *deletes* all state learned from that network interface? (And yes, that breaks RFC6059.) Brian Brian From nobody Fri Apr 7 07:39:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0C7127F0E for ; Fri, 7 Apr 2017 07:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 5ryCmKaEvtsK for ; Fri, 7 Apr 2017 07:39:44 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 D26BA1286B2 for ; Fri, 7 Apr 2017 07:39:43 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r69so77246528vke.2 for ; Fri, 07 Apr 2017 07:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UxlcNFJB0X0ZNUPOWSGaoEsohYS1+IB51I0Pk5wuVwY=; b=VzkLfhVmnTrGgnMOviTJesJegtNwK8amfj/5+By3yogYmRercWB7GJWVVVawNxnpRW c89rRV2g6vfWQW7EKGNHW4/HxzGkPSa9hwfD+WQHSfhc1zJYVaqbz6NWEyMdK1qthTfD 1yrKB+nYeT8yKGmd4ZR0oj4Ea1S44uNoOWQdOLaOqC6/uIM/N9CfcW7VWIAzaBMX8xPQ h4RuK3B1n3QlGNOQKabXm3t36Z07HdKkXYfOw7GomqFhOVNEf3/nRmNVPtmcXmam18sH g+jqjdJtgkPf4QP/wsf+P0LJS5/bnMEaj4LKpuaV5PFSrUgZPxbunmKXJg7s06KFFZHd OtTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UxlcNFJB0X0ZNUPOWSGaoEsohYS1+IB51I0Pk5wuVwY=; b=b0qeP/ryyEiRQoTDWsC8nFZBsFPPwVmQbW0XFZwNAv9xkvVPGtM+bavFmnbNGphe44 w5P0VvfZh6N0c8IV49DFdNObogmqKrhwi/ASxxM8KLMm64c4VexZD0M25xpgUkf4m+Wc AB8Eh10CCyFG1YaCcHJdKngp0B5JhNNeEowenTgkxrYHIb8n9I5E+JUjH+9hIkHWhybW pOB/nNCfhEkZpi1WuvMB6gyFTDtmp+QY33DIxHJ6HCtuLDcS1vYpZQZlCPtaaetc/jDJ pVgn4xisTlsKEyzrRr5F9jte3DpC2TGRssqVnfgk3EShK/vreWFi2TKZZ4O6RCqLoeak ccyg== X-Gm-Message-State: AFeK/H0vCP4VGsu8Nx5w7X/2U+lJOC2I8wh/5yen4/cHsyqrXy2Iqh3hQKq3gEvsE6EitpdtycxpnynEL+zjL34X X-Received: by 10.159.52.198 with SMTP id b6mr17933711uac.155.1491575982742; Fri, 07 Apr 2017 07:39:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 07:39:22 -0700 (PDT) In-Reply-To: <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> From: Lorenzo Colitti Date: Fri, 7 Apr 2017 23:39:22 +0900 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Brian E Carpenter Cc: Erik Kline , Jen Linkova , 6man Content-Type: multipart/alternative; boundary=f403045e2a5a9bb570054c9498a5 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:39:45 -0000 --f403045e2a5a9bb570054c9498a5 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 11:05 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The problem is section 7.4. It should be updated to RECOMMEND RFC7217/8064. > How do you configure RFC7217 such that the two VRRP routers in a given pair have the same link-local address, but other routers don't? --f403045e2a5a9bb570054c9498a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 11:05 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
The pr= oblem is section 7.4. It should be updated to RECOMMEND RFC7217/8064.

How do you configur= e RFC7217 such that the two VRRP routers in a given pair have the same link= -local address, but other routers don't?
--f403045e2a5a9bb570054c9498a5-- From nobody Fri Apr 7 07:46:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF52127F0E for ; Fri, 7 Apr 2017 07:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OMDNJ--H61tR for ; Fri, 7 Apr 2017 07:46:03 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 475CB12773A for ; Fri, 7 Apr 2017 07:46:03 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id l7so50636354ioe.3 for ; Fri, 07 Apr 2017 07:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Y7TVAnXpkGlWEbgPMqBjYq6A5mN76/Txbkg5ekQEwg=; b=hTvS/8PTvyT38XplyZXXin7BFBBibSYobfuuD4TYzm7SZQSGoW3G8YSIxGFiFir9At 1NdVwteQvIw3z4u46gJu9Koc0d9IqMdASTN+Ot2P8Hiiwe4nlEZRdhzxnRI4sQOPPtDt wo7XCoMpNiL2zXlkxBIFzN7AXfFdbEdjGzTbtlTWjwrs5X7qT4B13+89nSVTnRGwT/3c kVSC3OwK/LBKZJ2oNUzyTIqx5anxG8FC6MmqCoBK3uhd/rnyQo4oLNtW0RywnjZoa+Yn hfI0F8kZ16ZxSGUCXnlOjLVsUuirif+Si2mUx4VFayPzo1Hyddxv+fIBenM3xa1ABekn HQWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Y7TVAnXpkGlWEbgPMqBjYq6A5mN76/Txbkg5ekQEwg=; b=WTnt9GcUf56KPPK2TyaUTQpT+DZ5cpz/jbQghpN5cHdhQkuuodwFyHrBXsFywNP/tr 1TnJxqNklES0grEVyKSFXRF6aH8LNJNKPDkSIOK5e8hr0J32PAGGofyq5lIsgEDNkLww JE4yFNVRIE5+aBrTXu5ygZd6xxst7/WyQaJE7JshfOPWfAvjRyIJ/57gOOAPe4VVrnVa uwGZeTcD01M3RDZAbQuR5QOn18v5fYFZUVBn7Pb5Nvwy8JX5slAn6KYF6OWtTN6rk8wz MNIGLPBSf5fK7/CgYXcrG2rJaCwEKrJld2YvYeyZo+6g/ZqEN9Pp9XFelc1WMmOEPP4b oVUA== X-Gm-Message-State: AN3rC/7OFUrbLCYyHrxklNkAO36IZMAiWFaRfSay0buQbVsMfV5yrGr+Zu0j/eU4fQ9A2JpyxscxfjllxQ2ppw== X-Received: by 10.107.18.5 with SMTP id a5mr5084573ioj.189.1491576362685; Fri, 07 Apr 2017 07:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.184.197 with HTTP; Fri, 7 Apr 2017 07:45:42 -0700 (PDT) In-Reply-To: <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> From: Jen Linkova Date: Fri, 7 Apr 2017 16:45:42 +0200 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Brian E Carpenter Cc: Erik Kline , 6man Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:46:05 -0000 On Fri, Apr 7, 2017 at 4:05 PM, Brian E Carpenter wrote: > But Jen is correct, we also have to consider reality with clashing > addresses. > > Doesn't that mean that "when the host moves from one network segment > to another" we should suggest that the stack *deletes* all state > learned from that network interface? (And yes, that breaks RFC6059.) Well...I do not know the right answer...In some scenarios it does make sense (for example I'd prefer my laptop and my desktop to do that), while for mobile devices it might not be the best way to operate (why DNA was created in the first place?). Maybe DNA assumptions need to be changed to 'the combination of the link-layer address, the link-local IPv6 address and the list of PIOs is unique across links'? -- SY, Jen Linkova aka Furry From nobody Fri Apr 7 07:59:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47912773A for ; Fri, 7 Apr 2017 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 sWCjDVQjtgis for ; Fri, 7 Apr 2017 07:59:36 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 58CEF127333 for ; Fri, 7 Apr 2017 07:59:36 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l7so50898964ioe.3 for ; Fri, 07 Apr 2017 07:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=z7UgRD++JpE+8R/TkmrBXOYOGscZUA976WJSH0hD3f4=; b=J6PgrlPsejrYoZET0Ee4KcIAKJzH5ytDWao/IQSGt6MbLCt3IvkBSMox+Fw6jRZ8oF 3SRrB5h9k4I+7ffZ3gXIyWmUoqNtK6hN9q80b3nkqU8ur+s9LY/OUPFRRtWH62hYn94b 50t9p6vL6Im4iL5t6gF5FzCI+ZW3miiRDPTC+EoI34sB97CN/nQXpPcYmBrpbMFLoU3M rAJ7I4EgO3/xoOpEnovWDFkhXicins4pmJl7WoPK4oHLOhrU01MyNPA2n1QoehVQjns4 /4oA/jNFr6TDp1P9NfkFZ6/KX+jRZN3l3rZ9weh3frHWyKJjlXLWXkIgJ6ERrga2bha6 CqlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=z7UgRD++JpE+8R/TkmrBXOYOGscZUA976WJSH0hD3f4=; b=KKGYgAine4Bbk+dQXhRI7nFVqACnkst+HdA1AeWZxtZ6aWLyMMYwNb1X1vQvnTzFdj T9mrijVgnPNL0Ja8JM4sS3HmiwkqJz9qyYwZHqcMA5ycSXmUL/orRjJS0EJtx7IL6PMU ce1PmALby6uLJcH+y7JhE6vnb60HqcXiaj5hlh2wOgqVSjKwaDlWn2kMf6hl8yMcjYat 4z1WKUkgHU4BIkCw8XovSkDYh1A8UBV09x7Ns7v25RXb9p3CHnHhI1RRuFJZA+vF84V6 VtKvCIgHcoXiwT0ee40XB6GaJucZJfIUXbA2jLx3RtiUEs0CSwnx1dXK+yIgxFZiCkHu V7gw== X-Gm-Message-State: AFeK/H15V8wEwvsYNGcQOfAS36pwoOTyFISwHOSJg3cUc6S0vbuR8i1nE1Kkx3NTUIrBLA== X-Received: by 10.107.144.197 with SMTP id s188mr38066834iod.146.1491577175637; Fri, 07 Apr 2017 07:59:35 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id e134sm11808268itc.23.2017.04.07.07.59.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 07:59:35 -0700 (PDT) Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Lorenzo Colitti References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> Cc: Erik Kline , Jen Linkova , 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: <7d82c914-bbea-2b6c-3f63-52da383c47a9@gmail.com> Date: Sat, 8 Apr 2017 02:59:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:59:38 -0000 On 08/04/2017 02:39, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 11:05 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> The problem is section 7.4. It should be updated to RECOMMEND RFC7217/8064. >> > > How do you configure RFC7217 such that the two VRRP routers in a given pair > have the same link-local address, but other routers don't? I'm totally ignorant about how VRRP setups are created, so I can't answer that. Brian From nobody Fri Apr 7 08:01:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06EC1294D4 for ; Fri, 7 Apr 2017 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 Ywg41zMrC-zl for ; Fri, 7 Apr 2017 08:01:33 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 D9C571294C7 for ; Fri, 7 Apr 2017 08:01:29 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id t68so17505375iof.0 for ; Fri, 07 Apr 2017 08:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=exjd3UttEkLeJg1JrpcAz9rsj93AJiIqciUqRAbeJ24=; b=VFZxkNep/+tR78VUC2giN7q3fxk2xwERNpq40QMVdXN4Own586KUIa+/4NADLM8XVL J/BAwImZHgvMfPhO61w6gqjEFEUwFKK2k9Bhea5u+fj7SxN01qA5dE27rpOrq7Dmew2K zIBDRqeX4QYaMsCgkomBgqXJ4rAFdg3jih4WGLrbABD+fk89SFwJa31jzKsg/gsjzYlp v8pKBelj/LKREEq1NX9DbJDtxBdNRqZOU84WynRVOpqMa6NzaQIr5Mdp7OXllrpRdoEj ANWbg3b6IM9cQB9kjRCe63LQoAbr7RssyfqtOtWssX/R+1Fif6W7VMRkoJv+2CwU2d4R +lXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=exjd3UttEkLeJg1JrpcAz9rsj93AJiIqciUqRAbeJ24=; b=UvKMmZG0IVVeJ983n4HBNxtpNRXs3eWir4wEVIeOAJxfNAk6xZuMh5jAaOt392RLGR MBz+cZQogp0CBIYFuYHNtxBbFV47Y1OIih/iK7y67t3A1U3dCsaDtYc4GatNG/u7w02k UDauvg40p/04Ngop/ZJRqywHe2cbio+Wu7Rlo+C7XKveSGd9x+TidUxD3GiisQKuZ+AR jPwEarJuGpM8JC3WeqPvZMxoaGVqOSEFP/QjiLc747kbQNb23gHLTIMrE8IY6GXxa0Pu ZrFccjIkARA4hYRbqvjW8BZsSEnTm2sKMaAGn+qaMDHOlfVwn2FMIr0D5EyQ1FPJqU2F ug/w== X-Gm-Message-State: AFeK/H0TP4dg0d7YYrDO/kwrPyfUs47nqBI/AFK7BvVkXftOz4iqncnhhVHfHxgmQHm3/A== X-Received: by 10.107.134.234 with SMTP id q103mr38386492ioi.82.1491577289069; Fri, 07 Apr 2017 08:01:29 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id f19sm2505042itf.19.2017.04.07.08.01.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 08:01:28 -0700 (PDT) Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Jen Linkova References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> Cc: Erik Kline , 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 8 Apr 2017 03:01:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:01:35 -0000 On 08/04/2017 02:45, Jen Linkova wrote: > On Fri, Apr 7, 2017 at 4:05 PM, Brian E Carpenter > wrote: >> But Jen is correct, we also have to consider reality with clashing >> addresses. >> >> Doesn't that mean that "when the host moves from one network segment >> to another" we should suggest that the stack *deletes* all state >> learned from that network interface? (And yes, that breaks RFC6059.) > > Well...I do not know the right answer...In some scenarios it does make > sense (for example I'd prefer my laptop and my desktop > to do that), while for mobile devices it might not be the best way to > operate (why DNA was created in the first place?). > Maybe DNA assumptions need to be changed to 'the combination of the > link-layer address, the link-local IPv6 address and the list of PIOs > is unique across links'? Or maybe DNA implementations need to embody a heuristic approach, not a fixed rule. Brian From nobody Fri Apr 7 08:12:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECA9127F0E for ; Fri, 7 Apr 2017 08:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 AfvtscYB-60s for ; Fri, 7 Apr 2017 08:12:28 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 DED50127444 for ; Fri, 7 Apr 2017 08:12:27 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id s68so78329068vke.3 for ; Fri, 07 Apr 2017 08:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SR/fhQ8s3KjVSTxtXVvKtYiIAHAL2rH5McH0gYg2Q/k=; b=fRvo7SWTZ6N1KxYIdhVDKfGCCJrLm2PmwGHag1WViRR0zsiB1IYfU2BI7fWEnMbV2H 4yXtqmnXiwVz1b8C0/Fc7X+/9TeyoBtlaGMAJBB8Jjm1HA83JP7/yrYMACz5J6smBqzA AppXWKOf+XdHvNe3abItRs81iVh6+Ito00mHkb4dZ9g9exAPG9J9h6zYOysE8hnx0Epo iAFH5NQPR2QmrsK4m8FLbxZAUvT19JGd2MLMcATU2UZhn9Vi8MaITOADYiSOcAZUMoDd J84TeeV9B83Va2CWIzJ90bytu+cW03BR8e7kmyix4uFyUqPJ2P8mHNW1okYJciM31iVP M8DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SR/fhQ8s3KjVSTxtXVvKtYiIAHAL2rH5McH0gYg2Q/k=; b=abVkwxyjv8aDGn+eRz9DRRegD7jekM2D+gSgxqsT3/i52F/GRPU2G2CYA+NXU3xTaS WUvgFehY/6TQGrV0gK9xw7JR2vk5s9A+yB/l6ZciEVlsB3ZwlS4zG+lr9I58J13nuRHE kc4MwgMGVMiBRZeWoShuAqZDMuDO7+kDTOETPVK3N/SGOmHEUxw+hQc8Py3g26qgjyoT hXzuDpyaLXDulgm1pCxmgi6z1s47miMf0k1B3tQ4uPFQOivdn+FA2IjGvAgqSE+Bvsh+ NmG6jJvheVJ1wkJPORJpMc4w1wO7t89uUpSvQKqtSlFIoxoDwfHMnL1zprtHEc4LeOQh uqvA== X-Gm-Message-State: AFeK/H28LEFICzJIDiV3uUXUey0qGyk9oDZ73Z9iQRUSSjIbHnF7NhFRHr1GXszcmG1552v2fjC6V8nMNRpwfhaL X-Received: by 10.31.185.73 with SMTP id j70mr16527869vkf.102.1491577946761; Fri, 07 Apr 2017 08:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Fri, 7 Apr 2017 08:12:06 -0700 (PDT) In-Reply-To: <7d82c914-bbea-2b6c-3f63-52da383c47a9@gmail.com> References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> <7d82c914-bbea-2b6c-3f63-52da383c47a9@gmail.com> From: Lorenzo Colitti Date: Sat, 8 Apr 2017 00:12:06 +0900 Message-ID: Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Brian E Carpenter Cc: Erik Kline , Jen Linkova , 6man Content-Type: multipart/alternative; boundary=001a11439f3cac5393054c950de2 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 15:12:31 -0000 --001a11439f3cac5393054c950de2 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 11:59 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > How do you configure RFC7217 such that the two VRRP routers in a given > pair > > have the same link-local address, but other routers don't? > > I'm totally ignorant about how VRRP setups are created, so I can't answer > that. > This problem isn't really specific to VRRP, it's specific to 7217. The determinism in 7217 is obtained by running a hash function over a set of configuration variable. To use it for this purpose you have to ensure that all the configuration variables are the same for a given pair. If you want different VRRP groups to have different 7217 addresses then you need additional entropy. The VRRP group is still only 8 bits long, and the list of parameters in 7217 doesn't leave much room to maneuver... --001a11439f3cac5393054c950de2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 7, 2017 at 11:59 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> How do you configure RFC7217 such tha= t the two VRRP routers in a given pair
> have the same link-local address, but other routers don't?

I'm totally ignorant about how VRRP setups are created, so = I can't answer
that.

This problem isn't really spe= cific to VRRP, it's specific to 7217. The determinism in 7217 is obtain= ed by running a hash function over a set of configuration variable. To use = it for this purpose you have to ensure that all the configuration variables= are the same for a given pair.

If you want differ= ent VRRP groups to have different 7217 addresses then you need additional e= ntropy. The VRRP group is still only 8 bits long, and the list of parameter= s in 7217 doesn't leave much room to maneuver...
<= /div> --001a11439f3cac5393054c950de2-- From nobody Fri Apr 7 10:49:40 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9B1241FC; Fri, 7 Apr 2017 10:49:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc1981bis-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149158737894.11115.16409496906777752063@ietfa.amsl.com> Date: Fri, 07 Apr 2017 10:49:39 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:49:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Path MTU Discovery for IP version 6 Authors : Jack McCann <> Stephen E. Deering <> Jeffrey Mogul <> Robert M. Hinden Filename : draft-ietf-6man-rfc1981bis-06.txt Pages : 20 Date : 2017-04-07 Abstract: This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 7 10:55:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657DE1294E4 for ; Fri, 7 Apr 2017 10:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 OSKDw1_J5uAS for ; Fri, 7 Apr 2017 10:55:02 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 5BFCE129447 for ; Fri, 7 Apr 2017 10:55:02 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id a140so46739176ita.0 for ; Fri, 07 Apr 2017 10:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=B/33xFcBSC4k+uYa563rMvAKJr7aLTUnjmqMOIUgh3E=; b=hdjwXU8ELZ/OyZtEgxZb2BjGEGhvL1wtKAuzQqX/Ak1YwqYRvunxcVnY3RrEO8jobQ Fa614ecnE7mT8y/EAG3s1Xzy54uZ/kg0jbSIhLWFtGOXV8YqUqTLBacbC3MPfW9mBY4y 1ZFl6VxBT0HZQoo0up1Kt/pcWxafFZNg1Gbr2cFuBOcUCqVtkHZakp7F4gR05AwmJCjx W6yZ4DnXctV+0ua9Bsmx/BjoVPHN3wvwQd5afE3N7RUPp2ZF1XsM2zXyJQkmFECdovYQ DSFMH8EZQy8ZvK/DsB5jJk8iMTX+asDCIE0rmacyehxQrUfNJu+Wlm/38zTFQuW6nABD 3v8w== 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:date:cc:to; bh=B/33xFcBSC4k+uYa563rMvAKJr7aLTUnjmqMOIUgh3E=; b=pPsyhYtKxNjRZtuijKiqCY6RPTTBTNj89zS6GOpHKoJYGJ29xm5v0Iebap7O90LE2I uE0PX+xy8Bme4fHHbRi0qCuqnwDi/9kz6wLEAHJ97foFWNdHjvJ4TRo++HRYnYXwYXr9 Ie2uYFgpickrVGVneP6kw/QnjGUXYTnDmFWQrAccpwluT6nTi8rg1QIstph0mczwNxfe AYZoc3MBz8DTBpajPN1PqaBHDveuHz3Wf6/7G+EczHSaR2DQdH6JqJ5S6Oei3W+WeYdj SnTJ1IEpvj5S4qVUDuDk7TiN1xlozSf+/SA7h9duVvTauE1ZhJJdUNMzw+4pplRyjus0 dtGA== X-Gm-Message-State: AN3rC/7yX8EpE7ZD/nIhh4acbskVmMw1tIz3yAK7InVEp5BVtJceP3v8rS6YBPRWzBwc1A== X-Received: by 10.36.44.13 with SMTP id i13mr682067iti.34.1491587701746; Fri, 07 Apr 2017 10:55:01 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id e20sm1688178itc.3.2017.04.07.10.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 10:55:00 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_62675EB0-8B80-4AD3-B686-4557E8518022"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Message-Id: Date: Fri, 7 Apr 2017 10:54:58 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:55:04 -0000 --Apple-Mail=_62675EB0-8B80-4AD3-B686-4557E8518022 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new version of rfc1981bis (-06). Links to the document = below. The changes in this version are: Revised Appendix B "Changes since RFC1981" to have a summary of changes since RFC1981 and a separate subsection with a change history of each Internet Draft. This subsection will be removed when the RFC is published. Editorial changes based on comments received after publishing the -05 draft. A diff from the previous version can be found at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-06.txt Please review. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc1981bis-06.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc1981bis > Revision: 06 > Title: Path MTU Discovery for IP version 6 > Document date: 2017-04-07 > Group: 6man > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc1981bis-06 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-06 >=20 > Abstract: > This document describes Path MTU Discovery for IP version 6. It is > largely derived from RFC 1191, which describes Path MTU Discovery = for > IP version 4. It obsoletes RFC1981. >=20 --Apple-Mail=_62675EB0-8B80-4AD3-B686-4557E8518022 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY59JzAAoJEK7rdBF357uoxBAH/31YhvCTNKGLebCxk8oIVoq3 /l24o3fSQsCwPWap0uyHCe6M47Vv6EP+rdT/ppe/iaSHS5L07ErFkvO2bIRjephU CUewcRPAFQm9dLWFll8Js3h2Kl7iEHy6gx6AySN32c0HRx1665CMeGm+Y9mHxk/5 kR9IvXWJ44pXm+ZI95N31LbD4uF2r3VdJwU9q7IsjbMkFN1FMjPZQrSEN7Uhgu6M szEgrMWchGE+wtNYdTBlvmXcBKP6Fz8eETN9s2f6jZMWBhlYVQlChriliiW0Nm9X QG22/PO1gffD+m2SyKhEY4+gM057pFFuLnnk/bwoaMUHG9dAOJWLcthvtEFhLcM= =jAAZ -----END PGP SIGNATURE----- --Apple-Mail=_62675EB0-8B80-4AD3-B686-4557E8518022-- From nobody Fri Apr 7 11:40:04 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F0B1289B5; Fri, 7 Apr 2017 11:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, ipv6@ietf.org Subject: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 11:39:56 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 18:39:56 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First off, this DISCUSS is NOT about questioning the rough consensus calls that the responsible Chair and AD have made, or wanting to change them, but about clarifying to avoid misinterpretations. Given the ongoing discussion about Extension Headers and controlled domains (for example [1] and [2]), the text should be very specific on what is expected and where. Because it is not, I think that this document is teetering along the line of having a "high degree of technical maturity", and not being ready for Internet Standard [rfc6410]. Without further clarifications and guidance, this document also brings on unanticipated second order effects [rfc3439] that can impact the direction, or even the viability, of future work in the IETF. Specifically, a straight forward interpretation of the text in Section 4 is the absolute prohibition to process, insert or delete EHs -- but discussion on the 6man mailing list seems to point at an understanding that the conditions inside a controlled domain may be different, for example (from Brian Carpenter [3]): ===== I've tried to say this before but I'm not sure people are getting it: RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others. There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that. ===== [N.B.: I'm not implying that Brian's opinion represents consensus, that is not my call to make.] I'm pointing at an opinion (which I agree with) that recognizes the need to differentiate between contexts -- but the current text in rfc2460bis doesn't do that. I believe that this issue is significant (as reflected by the ongoing discussions) that that it should be resolved (by clarifying the text) before proceeding with the publication of this document as an Internet Standard. To summarize, the text in this document has the second order effect of not leaving a clear path forward for extensions to IPv6 so that they adhere to the protocol's architecture, specially when applied to a controlled domain. At a minimum, I would like to see a clear path forward, whether that is in the form of an update for use of extensions in controlled domains, or a statement that this document just applies to IPv6 traffic intended to cross the Internet (as suggested at the 6man meeting in Chicago [4])... My opinion is that this document should not be published as an Internet Standard until the remaining open discussions are explicitly resolved and this document reflects that resolution. [1] https://mailarchive.ietf.org/arch/msg/ipv6/UI0PfqrWco4Hpbvm8keGR8FabRg/?qid=9a6ba8e9777114e24a1e964336ed78f1 [2] https://mailarchive.ietf.org/arch/msg/ipv6/OrLYxKumiKWLHGkeNamhq9pxutQ/?qid=63c159fe41c18653d9dc0be609f9e97f [3] https://mailarchive.ietf.org/arch/msg/ipv6/REez0-lbebpo-Xem-xX_sWV0pf4/?qid=5cdab6c6085795129802ab622bb4159f [4] https://www.ietf.org/proceedings/98/minutes/minutes-98-6man-00 ========== Related to the above, I also want to point out the lack of clarity in the text in Section 4. (IPv6 Extension Headers), which leaves itself open to interpretation and should be cleaned up. (A) The main piece of text that has been discussed now reads: With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of [RFC7045]. ... The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. While the first sentence seems clear on what this document wants forwarding nodes to do (or not), there are two notes that define exceptions: any forwarding node can examine the headers "for any reason", and, the Hop-by-Hop Options header doesn't really have to be examined and processed by everyone. This text needs some more work to at least not contradict itself: there is more than one exception, and they are not absolute, anyone can examine the headers "for any reason"... (B) As it stands, the note about the changed expectations for the Hop-by-Hop options header opens a significant door to work around the "limitations" of other options. For example, it would be relatively straight forward to define a new Hop-by-Hop option to carry any type of information that could then be "examined, processed, inserted, or deleted by any node along a packet's delivery path". In the world of controllers and programmatic access to forwarding nodes, changing the explicit configuration on the fly to customize which nodes do what, is trivial. Is that the intent of this document, to provide a generic mechanism for cases that may need extension headers to be "examined, processed, inserted, or deleted by any node along a packet's delivery path"? Will the WG/IETF be in a position to charter, adopt and/or publish these types of documents? I ask this question not only in the context of my concerns expressed above, but also because the definition of the Hop-by-Hop Option would seem to be able to handle anything ("used to carry optional information that may be examined and processed by every node along a packet's delivery path" - I didn't see any constraints), even if (for example) the Routing Header "is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination" -- so it makes me wonder whether using the Hop-by-Hop Options header to carry (for example) routing information so that it can be "examined, processed, inserted, or deleted by any node along a packet's delivery path" would pass the bar set in Section 4.8. (Defining New Extension Headers and Options): New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behaviour. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. In the context of a controlled domain, it should be relatively easy for the operator to account for those issues. So my interpretation of whether a Hop-by-Hop option is ok to carry (for example) routing information is a strong "Yes!". Whether my interpretation is what was intended or not, I believe the overall text could benefit from more clarity. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Appendix B. (Changes Since RFC2460) mentions that the text was revised based on updates from several other RFCs which Updated rfc2460. I didn't check all the details, but if the updates were incorporated in this document, why are those RFCs not marked as being Obsolete? Is there any value left in them? From nobody Fri Apr 7 12:20:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CA9129459 for ; Fri, 7 Apr 2017 12:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Ja3OHuDubmmq for ; Fri, 7 Apr 2017 12:20:44 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 1CF43127775 for ; Fri, 7 Apr 2017 12:20:43 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l7so55312646ioe.3 for ; Fri, 07 Apr 2017 12:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5zmHG73TKGt1u4PkbLtX1d2X6tIp9ORcU/Ilb+vH0nk=; b=Wcn/h6m/AmgV9h/kdKPbhh3FWNnZiOUeH49e084iaoRAdHpZN5dpeOq8dW0DyKtuTd B4w3R+oQc5GP0Iv4gFCufIGlQ7KzQh5Wjyfj22X9j6PkupcLH26LWPyXC8I3htA6tVBl iaPU3Ubky4xUWVHZjcG6xpRaH8NiEWVvNmcxSaYN4O6kIOyYllYAtKDD/nNa6jLiTqrd S/vgQfIWG5F/O6pImdnSTps5lpo+usy/Gz3lNT/Z9yQuguU0AlDQkqIGJYJ0o97jGFhJ xkiG5BG+F/zFJDVn97B797ntk50r3KFf2dRsh04r0DtPhY53vNlj/AX/z6udI98fyEV2 RrbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5zmHG73TKGt1u4PkbLtX1d2X6tIp9ORcU/Ilb+vH0nk=; b=O36+fUhmHIeVhL8bPk7kBmG9ekeFmL/Lp2YdKBMI8fOMJika/5EnxV73vCFIbEyvTX BfOOTHipWlGRrt8YQV8tFReIHPkGih0ggyF23g1DdT5kWP4S/avdFmNajdjMv83z75S3 2hN8CD198Uzr3zW2B34L2j4n49WDYn/I1JyXrWTmJHffKbmFBQdGNdTOKMKg8c/shDlF 8JNp8a0T979HXByluLqjfK1ZyhKQEaDNcHRGYkdyLkbFsSq+uaIJ8K+F158sbR3PmVMU v+/bjfWINhznU9n9+jXj4oYoBp7W7VHrbknmFh1n/PqvfAma4KnTwR8IbcMhfmxtlL8t fFuw== X-Gm-Message-State: AFeK/H1DZan5uQhhAwcWTdgPb84b7OnSe5sMqVJlSZlZQpaRUSkgGQh/+aI4a8aC5M1oxw== X-Received: by 10.107.146.198 with SMTP id u189mr43916283iod.173.1491592842466; Fri, 07 Apr 2017 12:20:42 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id p6sm2807195iof.12.2017.04.07.12.20.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 12:20:41 -0700 (PDT) Subject: Re: To: Bob Hinden , IPv6 List References: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <905ec8d5-bef4-ff21-4912-457fd39d2e40@gmail.com> Date: Sat, 8 Apr 2017 07:20:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 19:20:47 -0000 As a reminder, I suggested this change precisely to avoid the issue raised by Alvaro Retana: On 31/03/2017 03:13, Brian E Carpenter wrote: > Proposed text change near the end of the Introduction: > > OLD: > This document specifies the basic IPv6 header and the initially- > defined IPv6 extension headers and options. > > NEW: > This document specifies the basic IPv6 header and the initially- > defined IPv6 extension headers and options required for interoperable > communication between any two nodes on the Internet. > > Regards > Brian > > On 31/03/2017 02:35, Bob Hinden wrote: >> Hi, >> >> I published the -09 version of 6man working group draft of rfc2460bis. Links below. >> >> The changes in this draft are: >> >> Based on results of IETF last call, changed text in Section 4 >> to add clarification that extension headers are not examined, >> processed, inserted, or deleted by any node along a packet's >> delivery path. >> >> Changed reference from draft-ietf-6man-rfc4291bis to RFC4291 >> because the bis draft won't be advanced as the same time. >> >> Revised "Changes since RFC2460" Section to have a summary of >> changes since RFC2460 and a separate subsection with a change >> history of each Internet Draft. This subsection will be >> removed when the RFC is published. >> >> Editorial changes. >> >> A diff from the -08 version can be found at: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >> >> Please review the changes. >> >> This is part of the project to move the core IPv6 specifications to Internet Standard. >> >> Thanks, >> Bob >> >>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt >>> has been successfully submitted by Robert M. Hinden and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-6man-rfc2460bis >>> Revision: 09 >>> Title: Internet Protocol, Version 6 (IPv6) Specification >>> Document date: 2017-03-30 >>> Group: 6man >>> Pages: 41 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >>> >>> Abstract: >>> This document specifies version 6 of the Internet Protocol (IPv6). >>> It obsoletes RFC2460 >>> >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> From nobody Fri Apr 7 13:38:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767BE12741D for ; Fri, 7 Apr 2017 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 dLlGyq9aXtNv for ; Fri, 7 Apr 2017 13:38:05 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 1DADF124BFA for ; Fri, 7 Apr 2017 13:38:05 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 70so2114029ita.0 for ; Fri, 07 Apr 2017 13:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=PphvNIY8nbbfNgbH+4RIuGJsN56K987FBLfTetK2E4k=; b=pkiyel12eZNrb7+wSPAqAX0IvEQywn8daTcMzyEwdRXP//4lFtPk+fX5klC2YUQ89r jlOKUSkzejoQYhsAivn6RRCg9yQ/nMhV7wm/Gw8TmiTwf15VMMyKqom+YrwAASDvVyhj yUkV6z59IJTQgckzh1p4NC++Zdw2J5UOKuHh4hj0Z/len1cjO8wRTAAr/YalTAi2mUS0 mjJZdwGslGdqY0HZ0NtoWxsizn2ud9jNaoSAZOOlAJSrD2wKt7nslx842sYrCZ4vo6+1 nx/dvBoRCC2wU6m10ZVco5GvtHJHt0gJDvgVxcJlXz1owRXIR21oHfZzGPD3R53/wMdL ohLw== 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:date:cc:to; bh=PphvNIY8nbbfNgbH+4RIuGJsN56K987FBLfTetK2E4k=; b=X628ND1/ccv6M1SGxFutgh81uQoM3cgHyktUdLzhrslfhThb4QP9F8GG2HBcdTDjsv P1cMVEa7eHf7Uz+JhCLLqYQkLWK/jKkha2b9xXV2j2jkVlJLhhkmAzoR4IXVEoqrqPrH MDDw4cy384xmGpfFGUtFs9fLPi080dQtNytiGg/QSQpFetGCpORvq9rdQYhUuIfdZFQ9 VrxzbZfK6VhY6/arAQax5eyVnEh6/F7mgZhgB2dANhCQ67zH4EEWqt3JUKMAJlj8yGdo sx9wTFGGDJrwAeIiFg58l/KkAfewMq9WwHnMjDkS+2zdKuvTIP45IbQTti3mys+T4Vfl jt8Q== X-Gm-Message-State: AN3rC/4l0XoWuYhWZaEYII5vDFWOZJh+WWfH1Q6LHHrU2r8m5FI2EGPo 590SaYxg29A9LXviSfw= X-Received: by 10.36.20.199 with SMTP id 190mr1496603itg.72.1491597484437; Fri, 07 Apr 2017 13:38:04 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r30sm2890320ioi.56.2017.04.07.13.38.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 13:38:03 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_9CBE8B40-846F-4480-AE56-872B18B58914"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01 Message-Id: Date: Fri, 7 Apr 2017 13:38:01 -0700 Cc: 6man Chairs <6man-chairs@tools.ietf.org> To: IPv6 List X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:38:10 -0000 --Apple-Mail=_9CBE8B40-846F-4480-AE56-872B18B58914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At the Chicago IETF 6MAN session there was clear consensus for adopting = draft-clw-rfc6434-bis as a 6MAN working group document. This message = starts a one week call on confirming the consensus from the WG meeting. Title : IPv6 Node Requirements Authors : Tim Chown John Loughney Tim Winters Filename : draft-clw-rfc6434-bis-01.txt Pages : 34 Date : 2017-03-13 https://tools.ietf.org/html/draft-clw-rfc6434-bis-01 Please respond only if you think this document should _not_ be adopted. This adoption call will end on April 14, 2017. Regards, Bob & Ole --Apple-Mail=_9CBE8B40-846F-4480-AE56-872B18B58914 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY5/iqAAoJEK7rdBF357uojbkH/ic7FYziqiOxnlWd1NCkPCL3 p1kbmIkcKfFUDiw1EnF3hB0l79xfjMOdwY7YR+KgKpTctYTGGyPCXX28x2vMtbGM BQFCbrF+9A/7KuYUNaKRmcxu7L7oeAsklOkxJSFa8mUzliE6QAGBuSNi8IAyZsYK dnfT5VBCFby72lsPADUJIhNMNBCfFRKQpe/dbXaWr/hKz9++riAvGzpjkMPnBSL6 xx3STuCFzi2h5Sg6Co9yeEA95hY8+StRtVwLKVNEbsW6loJ0NJvytGeMf288L7IS d72M06uRS1wnZREFD9ggVjueguAVTy0GjB8a4/5MFHTLJ6MzkZwk/J555Sdcbt0= =UE5w -----END PGP SIGNATURE----- --Apple-Mail=_9CBE8B40-846F-4480-AE56-872B18B58914-- From nobody Fri Apr 7 15:38:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E07127097 for ; Fri, 7 Apr 2017 15:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nDMejCKUjrfB for ; Fri, 7 Apr 2017 15:38:10 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E32128B92 for ; Fri, 7 Apr 2017 15:38:02 -0700 (PDT) Received: from [IPv6:2a02:c7d:316d:1c00:dd5d:49b2:1203:60c4] (unknown [IPv6:2a02:c7d:316d:1c00:dd5d:49b2:1203:60c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AFA3381AE2; Sat, 8 Apr 2017 00:37:57 +0200 (CEST) Subject: Re: To: Brian E Carpenter , Bob Hinden , IPv6 List References: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com> <905ec8d5-bef4-ff21-4912-457fd39d2e40@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3d4d3596-3b19-122c-6c50-226d4385b803@gont.com.ar> Date: Fri, 7 Apr 2017 23:37:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <905ec8d5-bef4-ff21-4912-457fd39d2e40@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 22:38:24 -0000 Brian, FWIW, I'm against the proposed "clarification". I don't think we want "IPv6 for the Internet", "IPv6 for...", "IPv6 for..". If we move in that direction, it's not hard to envision this kind of conversation: A: I have finally deployed IPv6 B: Which variant? IPv6 is IPv6. And it is an end-to-end protocol. Inserting EHs is quite the opposite to e2e, and in a very radical way. It's kind of unfortunate that, after the sequence of events we have had for this I-D, folks seem to find yet another loophole to accommodate the future plans of a single vendor. Thus, I don't think the current version of the I-D requires any changes. Actually quite the opposite: such modification would be incorrect. Thanks! Cheers, Fernando On 04/07/2017 08:20 PM, Brian E Carpenter wrote: > As a reminder, I suggested this change precisely to avoid the issue raised > by Alvaro Retana: > > On 31/03/2017 03:13, Brian E Carpenter wrote: >> Proposed text change near the end of the Introduction: >> >> OLD: >> This document specifies the basic IPv6 header and the initially- >> defined IPv6 extension headers and options. >> >> NEW: >> This document specifies the basic IPv6 header and the initially- >> defined IPv6 extension headers and options required for interoperable >> communication between any two nodes on the Internet. >> >> Regards >> Brian >> >> On 31/03/2017 02:35, Bob Hinden wrote: >>> Hi, >>> >>> I published the -09 version of 6man working group draft of rfc2460bis. Links below. >>> >>> The changes in this draft are: >>> >>> Based on results of IETF last call, changed text in Section 4 >>> to add clarification that extension headers are not examined, >>> processed, inserted, or deleted by any node along a packet's >>> delivery path. >>> >>> Changed reference from draft-ietf-6man-rfc4291bis to RFC4291 >>> because the bis draft won't be advanced as the same time. >>> >>> Revised "Changes since RFC2460" Section to have a summary of >>> changes since RFC2460 and a separate subsection with a change >>> history of each Internet Draft. This subsection will be >>> removed when the RFC is published. >>> >>> Editorial changes. >>> >>> A diff from the -08 version can be found at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >>> >>> Please review the changes. >>> >>> This is part of the project to move the core IPv6 specifications to Internet Standard. >>> >>> Thanks, >>> Bob >>> >>>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt >>>> has been successfully submitted by Robert M. Hinden and posted to the >>>> IETF repository. >>>> >>>> Name: draft-ietf-6man-rfc2460bis >>>> Revision: 09 >>>> Title: Internet Protocol, Version 6 (IPv6) Specification >>>> Document date: 2017-03-30 >>>> Group: 6man >>>> Pages: 41 >>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt >>>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09 >>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09 >>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >>>> >>>> Abstract: >>>> This document specifies version 6 of the Internet Protocol (IPv6). >>>> It obsoletes RFC2460 >>>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Apr 7 16:22:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1DC128DE7; Fri, 7 Apr 2017 16:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 SCQnkyKlFpIQ; Fri, 7 Apr 2017 16:21:50 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EA3127097; Fri, 7 Apr 2017 16:21:45 -0700 (PDT) Received: from [IPv6:2a02:c7d:316d:1c00:dd5d:49b2:1203:60c4] (unknown [IPv6:2a02:c7d:316d:1c00:dd5d:49b2:1203:60c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 84BF381D7D; Sat, 8 Apr 2017 01:21:43 +0200 (CEST) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Alvaro Retana , The IESG References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org, Enno Rey , Ivan Arce From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> Date: Sat, 8 Apr 2017 00:21:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:22:04 -0000 Alvaro, On 04/07/2017 07:39 PM, Alvaro Retana wrote: > First off, this DISCUSS is NOT about questioning the rough consensus > calls that the responsible Chair and AD have made, or wanting to change > them, but about clarifying to avoid misinterpretations. > > Given the ongoing discussion about Extension Headers and controlled > domains (for example [1] and [2]), the text should be very specific on > what is expected and where. Because it is not, I think that this > document is teetering along the line of having a "high degree of > technical maturity", and not being ready for Internet Standard > [rfc6410]. Why should any talk on EH insertion affect this document being ready for IS? Actually, it's quite the opposite: the experience we have with IPv6 is with "IPv6 'as is'" (i.e.,an end to end protocol that obviously does not allow for EH insertion). Opening the door to EH insertion would make this document, by definition, not ready for IS -- and actually, not even suitable for 6man (which is expected to be about maintaining IPv6, rather than about applying radical changes). So this document is clarifying what IPv6 has always been: EHs cannot not inserted by intermediate nodes. I personally don't get why the future plans of a vendor should essentially rule 6man to fundamentally change an end-to-end protocol (IPv6) into a...whatchamacallit, or be a show stopper during IESG review. > Without further clarifications and guidance, this document also brings on > unanticipated second order effects [rfc3439] that can impact the > direction, or even the viability, of future work in the IETF. An Architecture will clearly limit and delineate what you can and what you can't do. If you can do anything that you please, then that's an indication that you don't really have an architecture. > Specifically, a straight forward interpretation of the text in Section 4 > is the absolute prohibition to process, insert or delete EHs -- but > discussion on the 6man mailing list seems to point at an understanding > that the conditions inside a controlled domain may be different, for > example (from Brian Carpenter [3]): If you agree with the IETF LC (as oted), I'm not sure why *opinions* verted into the mailing list (*not* wg consensus of any sort) that happened *after* the IETF LC should affect this document moving forward. [...] > [N.B.: I'm not implying that Brian's opinion represents consensus, that > is not my call to make.] > > I'm pointing at an opinion (which I agree with) that recognizes the need > to differentiate between contexts -- but the current text in rfc2460bis > doesn't do that. I believe that this issue is significant (as reflected > by the ongoing discussions) that that it should be resolved (by > clarifying the text) before proceeding with the publication of this > document as an Internet Standard. As a wg participant, I strongly oppose to that. rfc2460bis specifies IPv6 -- an end to end protocol. EH insertion has nothing to do with that. In fact, it implies a radical change to the architecture. So I'm not sure why we're discussing what seems to be "yet another possible loophole so that a given vendor can do what it has in its plans". Please note: 6man decided to accept draft-ietf-6man-segment-routing-header on the condition that any suggestions/specification of EH insertion were removed. That, together with the IETF LC should be an indication regarding what seems to have been the consensus on the topic. I'm puzzled why any sort of ongoing discussion, taig place past IETF LC, and on a very radical change to the protocol and architecture should have an effect on rfc2460bis being moved forward. > To summarize, the text in this document has the second order effect of > not leaving a clear path forward for extensions to IPv6 so that they > adhere to the protocol's architecture, specially when applied to a > controlled domain. At a minimum, I would like to see a clear path > forward, whether that is in the form of an update for use of extensions > in controlled domains, or a statement that this document just applies to > IPv6 traffic intended to cross the Internet (as suggested at the 6man > meeting in Chicago [4])... My opinion is that this document should not > be published as an Internet Standard until the remaining open discussions > are explicitly resolved and this document reflects that resolution. The onus is on folks wanting to change the current state of affairs. Changing IPv6 (an end-to-end protocol) to allow for EH insertion is essentially a very radical change... not only to the protocol, but even to the architecture. [...] > (B) > > As it stands, the note about the changed expectations for the Hop-by-Hop > options header opens a significant door to work around the "limitations" > of other options. For example, it would be relatively straight forward > to define a new Hop-by-Hop option to carry any type of information that > could then be "examined, processed, inserted, or deleted by any node > along a packet's delivery path". Yes, the text is misleading, and should be improved. I pointed this one to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The text needs to be improved, so that this is not seen as a yet another loophole for suggesting that H insertion is allowed in IPv6 -- which was certainly not the intent. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Appendix B. (Changes Since RFC2460) mentions that the text was revised > based on updates from several other RFCs which Updated rfc2460. I didn't > check all the details, but if the updates were incorporated in this > document, why are those RFCs not marked as being Obsolete? Is there any > value left in them? AFAICT, in most cases rfc2460bis incorporated the changes, but didn't reproduce the rationale. Hence, at least the "rationale for the changes" is the value left in them, I'd say. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Apr 8 06:11:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4AC1293E4; Sat, 8 Apr 2017 06:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Gt1UxEIEYyIi; Sat, 8 Apr 2017 06:11:43 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 75D5E12025C; Sat, 8 Apr 2017 06:11:43 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id l7so62989904ioe.3; Sat, 08 Apr 2017 06:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ftCvG+BvIhXVpvTFLLkHIDk6RPCflGzvD/C10JeT5vA=; b=NOMSFyStMyn//sQiTaVzIydJAsCoTbHalJH1WFi9Tn2crhfZSQFGMnK8DfdiQw+WJC 67zepdMEGcaZxs5TfCUTJSYH0z45dVexgrcFxoWZhvTYr5ZnbeOTCIkW+ryamwCnS/Uu aLNMAvu88Kg3NSlb5YlWwsOqtyWPBw5+B2ABl1brsoJ+w3zdqGFxc5lbz0dIArAGna+Y SXe1oEjkvp7DSJ3xmiSEE2sdnyZu6gUuSWshrAwt3ke8zMoBue+JNsaFTqUvx9twDg6e aYlt0yYbZZBTJwCiXGH5ITMV6Rduhax31jlBNltgDqqREnYNe4kq3kQ4K6+qQduRE/vd ysEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ftCvG+BvIhXVpvTFLLkHIDk6RPCflGzvD/C10JeT5vA=; b=rPAltIN6eXZcRIGi/V0ADcvRByUMPv1L8Q9OxELtsgEUPgqF7tkvwfrs5yTuR4VbkX wfZeR6or92uA3suAgk9DhxuXNAtDAr6el+12As4S27t51wQUzb6YkYQzKifiQTCJG8rW K78YQz43DnCV8MfSCm+I3JNNg2zHkmsu6Q031CmPwBej6IhnSYFjj0TFO8g9ah1Sg9Qn f1udEBe3peFnkX19jl36TmWyomAK37ltKQqqQncAo5++588p8WAqCM83v1ghme9rxWJC FvhkFlAfCU1oj6pOabsXmoDYu9z7TQY3n1/9JDQY/a01fiitzEsssRUnPzyiuVki25Qw pBcg== X-Gm-Message-State: AFeK/H1zl6G2Z9xw0orwTpX/oEU+RZuC9pLJuJ1qZS/iu2aCUnmlHBVsRwT+rnt1/iROcg== X-Received: by 10.107.37.12 with SMTP id l12mr41700784iol.159.1491657102583; Sat, 08 Apr 2017 06:11:42 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id g23sm3790046ioi.20.2017.04.08.06.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 06:11:41 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Fernando Gont , Alvaro Retana , The IESG References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, Ivan Arce , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 9 Apr 2017 01:11:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:11:45 -0000 On 08/04/2017 11:21, Fernando Gont wrote: > Alvaro, > > On 04/07/2017 07:39 PM, Alvaro Retana wrote: >> First off, this DISCUSS is NOT about questioning the rough consensus >> calls that the responsible Chair and AD have made, or wanting to change >> them, but about clarifying to avoid misinterpretations. >> >> Given the ongoing discussion about Extension Headers and controlled >> domains (for example [1] and [2]), the text should be very specific on >> what is expected and where. Because it is not, I think that this >> document is teetering along the line of having a "high degree of >> technical maturity", and not being ready for Internet Standard >> [rfc6410]. > > Why should any talk on EH insertion affect this document being ready for IS? > > Actually, it's quite the opposite: the experience we have with IPv6 is > with "IPv6 'as is'" (i.e.,an end to end protocol that obviously does not > allow for EH insertion). Opening the door to EH insertion would make > this document, by definition, not ready for IS -- and actually, not even > suitable for 6man (which is expected to be about maintaining IPv6, > rather than about applying radical changes). > > So this document is clarifying what IPv6 has always been: EHs cannot not > inserted by intermediate nodes. > > > I personally don't get why the future plans of a vendor should > essentially rule 6man to fundamentally change an end-to-end protocol > (IPv6) into a...whatchamacallit, or be a show stopper during IESG review. > > > >> Without further clarifications and guidance, this document also brings on >> unanticipated second order effects [rfc3439] that can impact the >> direction, or even the viability, of future work in the IETF. > > An Architecture will clearly limit and delineate what you can and what > you can't do. If you can do anything that you please, then that's an > indication that you don't really have an architecture. Actually is is the proposal to allow header insertion that risks unanticipated effects; the draft simply consolidates the current simple interpretation of RFC 2460. Header insertion would be added complexity, exactly what RFC 3439 is about. >> Specifically, a straight forward interpretation of the text in Section 4 >> is the absolute prohibition to process, insert or delete EHs -- but >> discussion on the 6man mailing list seems to point at an understanding >> that the conditions inside a controlled domain may be different, for >> example (from Brian Carpenter [3]): > > If you agree with the IETF LC (as oted), I'm not sure why *opinions* > verted into the mailing list (*not* wg consensus of any sort) that > happened *after* the IETF LC should affect this document moving forward. Firstly, my opinion is indeed not part of the consensus; I fully support the WG consensus to publish this draft as IS. It *is* my opinion that after doing so, we should carefully examine proposals to define *exceptions* to the ban on header insertion. I have proposed a small clarification in the Introduction to make it clear that the scope of this draft is interoperation across the Internet as whole. I believe that completely answers Alvaro's point. > [...] >> [N.B.: I'm not implying that Brian's opinion represents consensus, that >> is not my call to make.] >> >> I'm pointing at an opinion (which I agree with) that recognizes the need >> to differentiate between contexts -- but the current text in rfc2460bis >> doesn't do that. I believe that this issue is significant (as reflected >> by the ongoing discussions) that that it should be resolved (by >> clarifying the text) before proceeding with the publication of this >> document as an Internet Standard. > > As a wg participant, I strongly oppose to that. rfc2460bis specifies > IPv6 -- an end to end protocol. EH insertion has nothing to do with > that. In fact, it implies a radical change to the architecture. So I'm > not sure why we're discussing what seems to be "yet another possible > loophole so that a given vendor can do what it has in its plans". > > Please note: 6man decided to accept > draft-ietf-6man-segment-routing-header on the condition that any > suggestions/specification of EH insertion were removed. That, together > with the IETF LC should be an indication regarding what seems to have > been the consensus on the topic. > > I'm puzzled why any sort of ongoing discussion, taig place past IETF LC, > and on a very radical change to the protocol and architecture should > have an effect on rfc2460bis being moved forward. > > > >> To summarize, the text in this document has the second order effect of >> not leaving a clear path forward for extensions to IPv6 so that they >> adhere to the protocol's architecture, specially when applied to a >> controlled domain. At a minimum, I would like to see a clear path >> forward, whether that is in the form of an update for use of extensions >> in controlled domains, or a statement that this document just applies to >> IPv6 traffic intended to cross the Internet (as suggested at the 6man >> meeting in Chicago [4])... My opinion is that this document should not >> be published as an Internet Standard until the remaining open discussions >> are explicitly resolved and this document reflects that resolution. As I understand the rules on promotion to IS, we cannot add new, untested features to the protocol. That means that adding header insertion is out of the question. All that is actually proposed is clarifying the intention, which was badly drafted in RFC 1883 and not corrected in RFC 2460. > > The onus is on folks wanting to change the current state of affairs. > Changing IPv6 (an end-to-end protocol) to allow for EH insertion is > essentially a very radical change... not only to the protocol, but even > to the architecture. > > > [...] >> (B) >> >> As it stands, the note about the changed expectations for the Hop-by-Hop >> options header opens a significant door to work around the "limitations" >> of other options. For example, it would be relatively straight forward >> to define a new Hop-by-Hop option to carry any type of information that >> could then be "examined, processed, inserted, or deleted by any node >> along a packet's delivery path". > > Yes, the text is misleading, and should be improved. I pointed this one > to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The > text needs to be improved, so that this is not seen as a yet another > loophole for suggesting that H insertion is allowed in IPv6 -- which was > certainly not the intent. I don't see that. The text says that HbH options may be examined and processed; it does not say that they may be inserted or deleted. But it would do no harm to add a 'must not' I guess. The other tiny change would be to qualify the "Note:..." by writing "Note: If an intermediate forwarding node _nevertheless_ examines an extension header for any reason,...". That would eliminate the minor inconsistency that the text refers to "one" exception. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Appendix B. (Changes Since RFC2460) mentions that the text was revised >> based on updates from several other RFCs which Updated rfc2460. I didn't >> check all the details, but if the updates were incorporated in this >> document, why are those RFCs not marked as being Obsolete? Is there any >> value left in them? > > AFAICT, in most cases rfc2460bis incorporated the changes, but didn't > reproduce the rationale. Hence, at least the "rationale for the changes" > is the value left in them, I'd say. Exactly. Regards Brian From nobody Sat Apr 8 06:21:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109B41279E5 for ; Sat, 8 Apr 2017 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 izMYNIdiv3Q5 for ; Sat, 8 Apr 2017 06:21:26 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 5B821128D44 for ; Sat, 8 Apr 2017 06:21:26 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so7087997itc.0 for ; Sat, 08 Apr 2017 06:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=gCsp6HJQmkBqBESorsNIBpcJk0lhDIQIFqf6JFXzTG0=; b=EVjIC5R6297vtBVxqr9E+GlrUxpRBoBFf4vxMPI0fK0xAJnTt+T1Noz1OWx6AYRM7g ScAnNfCY8BWZFtgZg65Y3NeOTqr6Tq4Jj/y1VM4CqI9Y2bOBSvaqnd/HdfXDveuo4yeA tFfYgknlRTYBFl4fMiajDIDE6VG9hvxrK869lpZLcGw/7REvXCp1ZpNtN/Hmx7Sq1q/1 1t0hgt+FpFAticGuSa54xjTO8bnXMGzXopKyMcmNDmZ1+hj3ENygm0bP94VcFQd8GaYa sHSCH+xffycvHAQ7GdWiWrAk3Og0WywdiReMzhTuuHRNkmo2vht5T6T9Xswad4N1q05G B6eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gCsp6HJQmkBqBESorsNIBpcJk0lhDIQIFqf6JFXzTG0=; b=oEWyXYNYjrZxOBkozZQBcvR3WQQaRm8h4vvxrNBZYoJotVmGrhYT41JXV1Zzb/29ww 3G+FbaQPxOhkgeOTGmUgKtiGFg152ZYb60pMloadmW1OJv+mra2x9nybk8cD1Y5AxFyh EgLlhlG9oNqURTdCpy6I+cOIJLjcLiKfxfy6U18db4g2F+vyPQs3dbIkg/jHUjWrD0LH t5JOdvVs2D7olpH90pZcpgMf6BLjR8AgiuBC9OkBFn81NjLVNFSGIxkW2O74HYaeGKPS g4cQ4wh3RO5r3uzO4USnR8MHhL1XL6zhdKbT/xI+J2fS2PrZZth68dQ66tBaiqlb2Tuf R5rQ== X-Gm-Message-State: AN3rC/7kvag+7jB4joYweFjHKV3zAZVSHVBdfVWvodPAQ+UWsAjtsKGk 8LfNsAKHbaxTdw== X-Received: by 10.36.53.194 with SMTP id k185mr4129797ita.27.1491657685644; Sat, 08 Apr 2017 06:21:25 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id d66sm1823263ioj.60.2017.04.08.06.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 06:21:25 -0700 (PDT) Subject: Re: To: Fernando Gont , Bob Hinden , IPv6 List References: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com> <905ec8d5-bef4-ff21-4912-457fd39d2e40@gmail.com> <3d4d3596-3b19-122c-6c50-226d4385b803@gont.com.ar> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7a8315fc-eabf-6632-03ed-54a5c2e3f5d5@gmail.com> Date: Sun, 9 Apr 2017 01:21:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3d4d3596-3b19-122c-6c50-226d4385b803@gont.com.ar> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:21:28 -0000 On 08/04/2017 10:37, Fernando Gont wrote: > Brian, > > FWIW, I'm against the proposed "clarification". I don't think we want > "IPv6 for the Internet", "IPv6 for...", "IPv6 for..". If we move in that > direction, it's not hard to envision this kind of conversation: > > A: I have finally deployed IPv6 > B: Which variant? > > IPv6 is IPv6. And it is an end-to-end protocol. Inserting EHs is quite > the opposite to e2e, and in a very radical way. IPv4 is IPv4. And it is an end-to-end protocol. Inserting NATs is quite the opposite to e2e, and in a very radical way. Yet we had zero success in preventing NATs. > It's kind of unfortunate that, after the sequence of events we have had > for this I-D, folks seem to find yet another loophole to accommodate the > future plans of a single vendor. I don't think this creates a loophole at all. The loophole is already there: there are no protocol police. I think we need a clear applicability statement: the IPv6 standard is for Internet-wide interoperability. If you don't follow this standard, you won't achieve interoperability. > Thus, I don't think the current version of the I-D requires any changes. > Actually quite the opposite: such modification would be incorrect. We want exactly the same final result... Regards Brian > > Thanks! > > Cheers, > Fernando > > > > > On 04/07/2017 08:20 PM, Brian E Carpenter wrote: >> As a reminder, I suggested this change precisely to avoid the issue raised >> by Alvaro Retana: >> >> On 31/03/2017 03:13, Brian E Carpenter wrote: >>> Proposed text change near the end of the Introduction: >>> >>> OLD: >>> This document specifies the basic IPv6 header and the initially- >>> defined IPv6 extension headers and options. >>> >>> NEW: >>> This document specifies the basic IPv6 header and the initially- >>> defined IPv6 extension headers and options required for interoperable >>> communication between any two nodes on the Internet. >>> >>> Regards >>> Brian >>> >>> On 31/03/2017 02:35, Bob Hinden wrote: >>>> Hi, >>>> >>>> I published the -09 version of 6man working group draft of rfc2460bis. Links below. >>>> >>>> The changes in this draft are: >>>> >>>> Based on results of IETF last call, changed text in Section 4 >>>> to add clarification that extension headers are not examined, >>>> processed, inserted, or deleted by any node along a packet's >>>> delivery path. >>>> >>>> Changed reference from draft-ietf-6man-rfc4291bis to RFC4291 >>>> because the bis draft won't be advanced as the same time. >>>> >>>> Revised "Changes since RFC2460" Section to have a summary of >>>> changes since RFC2460 and a separate subsection with a change >>>> history of each Internet Draft. This subsection will be >>>> removed when the RFC is published. >>>> >>>> Editorial changes. >>>> >>>> A diff from the -08 version can be found at: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >>>> >>>> Please review the changes. >>>> >>>> This is part of the project to move the core IPv6 specifications to Internet Standard. >>>> >>>> Thanks, >>>> Bob >>>> >>>>> A new version of I-D, draft-ietf-6man-rfc2460bis-09.txt >>>>> has been successfully submitted by Robert M. Hinden and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-ietf-6man-rfc2460bis >>>>> Revision: 09 >>>>> Title: Internet Protocol, Version 6 (IPv6) Specification >>>>> Document date: 2017-03-30 >>>>> Group: 6man >>>>> Pages: 41 >>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-09.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-09 >>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-09 >>>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-09 >>>>> >>>>> Abstract: >>>>> This document specifies version 6 of the Internet Protocol (IPv6). >>>>> It obsoletes RFC2460 >>>>> >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From nobody Sat Apr 8 06:34:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F7127010 for ; Sat, 8 Apr 2017 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 d8_OCPIySx2V for ; Sat, 8 Apr 2017 06:34:33 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 2E5EB1274D2 for ; Sat, 8 Apr 2017 06:34:33 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id y18so6605591itc.1 for ; Sat, 08 Apr 2017 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=t1T47TuwRRRbHNQ3OrLQ3evFtUhoLERFJlDLw+ftGsE=; b=elKcOhsEJ/6irryPEzqd+zTGqlOCDXx1JUNMeV5WihscLnwgbkwsz6a++bQFHs4aDS cQNP0y68ygKi1motH8o/aDRNOANz188wTGf2WcO8Tr8Ny9C/xbh7h5tzhUlbmuUQa3Na i2+9kTqQw3dqPfLeTyGV6x++fprLMK9SjzTIqapOcAGpYFdTXaJ8ZqmWjD/EVNjoDcXD eJcr7wV/aJufS51GcDauZ8ijbwVkkzT6jMGErwWn6n5NXkBWtwQVXtucs/pmbPBK5xWx LXS6WFQGbA67XiytiUVeZ6tlMC/8c0tIVUzMTdsOLSoIugsLyH/h0raBv+j5zk1MeiqY UnzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=t1T47TuwRRRbHNQ3OrLQ3evFtUhoLERFJlDLw+ftGsE=; b=F1Ea4wrVNIiyDeKNtwvYHNnffVqelz4z0ovv+jL4g2+36gzW3I1l/r6IajjUe+ZV4k K4y0GEq251yBJaUM73PM2bAXFhNDuZJKpBLsC1YLK8ecMoNdFJE5Kdsdk1Yx+q5Ygf1I raWp68glqbFvbmCIHhLOhag0JiCqyPlLHNC6RErt4oIliqrIIb2/RuWvNXEe5nGBKNvh 8sFcXQC6lpRc79QPUnlnD3PE0txfvLONerPaTmWEXL7QoDmFMI1cR4HeBpkb5a/I7CCv 6o8n4CH3lyOn5/7jaqX9bLM7L+DmVOYMeoApRhfWxo38fpMCpqWNLTdBgQxrawk/9VVN tIMQ== X-Gm-Message-State: AN3rC/7XC33HUVIuvJ9csr/q3lqmJSFJPRIv8xPrvssz8tpFnFRWrsEV izB6Ju/YlJN6NQ== X-Received: by 10.36.50.142 with SMTP id j136mr4319961ita.111.1491658472551; Sat, 08 Apr 2017 06:34:32 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id o97sm3797083ioi.53.2017.04.08.06.34.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 06:34:31 -0700 (PDT) Subject: Re: I-D Action: draft-linkova-6man-default-addr-selection-update-00.txt To: Lorenzo Colitti References: <149093611351.8864.5121956820429281359@ietfa.amsl.com> <1f8d497b-3286-2074-7c2e-f224ceda55a8@gmail.com> <696ab419-ed78-7a52-94be-96ea1e2d3e58@gmail.com> <7d82c914-bbea-2b6c-3f63-52da383c47a9@gmail.com> Cc: Erik Kline , Jen Linkova , 6man From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 9 Apr 2017 01:34:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:34:36 -0000 On 08/04/2017 03:12, Lorenzo Colitti wrote: > On Fri, Apr 7, 2017 at 11:59 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> How do you configure RFC7217 such that the two VRRP routers in a given >> pair >>> have the same link-local address, but other routers don't? >> >> I'm totally ignorant about how VRRP setups are created, so I can't answer >> that. >> > > This problem isn't really specific to VRRP, it's specific to 7217. The > determinism in 7217 is obtained by running a hash function over a set of > configuration variable. To use it for this purpose you have to ensure that > all the configuration variables are the same for a given pair. > > If you want different VRRP groups to have different 7217 addresses then you > need additional entropy. The VRRP group is still only 8 bits long, and the > list of parameters in 7217 doesn't leave much room to maneuver... I see. So maybe a different approach is needed. The objective is not privacy for VRRP routers, after all; it's non-clashing LL addresses. Brian > From nobody Sat Apr 8 06:37:05 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C691274D2; Sat, 8 Apr 2017 06:36:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Date: Sat, 08 Apr 2017 06:36:56 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 13:36:56 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This security considerations section seems fairly unsatisfactory. First, you can't just point back to IPv4, which doesn't even have a security considerations section. Second, IPv6 actually has different security and privacy properties than IPv4 in a number of respects, so you actually need to document them. document needs to as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I get that this document is from a period before the style became as uniformly to upper-casify RFC2119 keywords, but but it seems like it might be a good idea to do that here. It's a little hard to determine what is normative here, but S 4. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload Given that 6434-bis seems to have backed away from IPsec, this S 4.4. Assuming I am reading this document correctly (and I've never implemented v6 so I could be crazy), in order to implement the routing header you need to decrement Segments Left, but the document does not seem to say that. S 4.5. As I read this document the order of headers is only strongly recommended, but the rules about fragmentation seem to absolutely require a specific order: The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Is there a reason why the rules are not MUST? S 4.5. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. If fragments follow different paths (not crazy) then the hop limit will be different, right? So perhaps "not expected" is a bit strong. S 8.4. Response packets that carry Routing headers that were derived by reversing the Routing header of the received packet IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header from the received packet have been verified by the responder. It's not clear to me how this works. If, as I suggest above, the routing header gets changed in transit, how do you measure the integrity and authenticity? Even if that is not the case, and you use something like IPsec to provide integrity, why do you trust whatever claims the sender makes about routing. From nobody Sun Apr 9 06:52:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE091205D3; Sun, 9 Apr 2017 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zvj3ubB2u6ZE; Sun, 9 Apr 2017 06:52:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBF9129493; Sun, 9 Apr 2017 06:52:17 -0700 (PDT) Received: from [192.168.0.63] (unknown [2.219.17.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AD31A8306E; Sun, 9 Apr 2017 15:52:15 +0200 (CEST) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Brian E Carpenter , Alvaro Retana , The IESG References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, Ivan Arce , 6man-chairs@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7ff7970f-98bb-a939-5253-33aed259e772@si6networks.com> Date: Sun, 9 Apr 2017 12:11:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 13:52:23 -0000 Hi, Brian, Some additional comments about specific parts (I've omitted everything else, since we're in agreement :-) )... On 04/08/2017 02:11 PM, Brian E Carpenter wrote: > On 08/04/2017 11:21, Fernando Gont wrote: >> Alvaro, >> >> On 04/07/2017 07:39 PM, Alvaro Retana wrote: [....] >> If you agree with the IETF LC (as oted), I'm not sure why *opinions* >> verted into the mailing list (*not* wg consensus of any sort) that >> happened *after* the IETF LC should affect this document moving forward. > > Firstly, my opinion is indeed not part of the consensus; I fully support > the WG consensus to publish this draft as IS. It *is* my opinion that > after doing so, we should carefully examine proposals to define *exceptions* > to the ban on header insertion. > > I have proposed a small clarification in the Introduction to make it > clear that the scope of this draft is interoperation across the Internet > as whole. I believe that completely answers Alvaro's point. Since you have no way of ensuring that packets from such domain will not leak out that domain, you cannot really pretend that "I can break the protocol in anyway I please, since it's my own personal domain" -- actually, you can... but you don't need a standard for that. So any of such proposals should be evaluation considering that packet may leak out (plan for the worst, expect for the best). That's not an argument against EH insertion but rather: * Accept that EH insertion is a modification to IPv6 (as opposed to pretending that there are loopholes that allow for it) * Evaluate what's the damage in case packets leak out of such domain * Evaluate if there are alternative ways of ng the same thing, without the aforementioned risks (e.g., tunelling) * IMO, IETF can be assumed to standardize *I* protocols which, unless otherwise specified, are expected to operate over the Internet. There's no need to say/clarify that. And in fact, that might trigger folks assuming that there's a shortcut to modify or break protocols by simply defining an appropriate "domain". Folks coming with a proposal about EH insertion need not be any more special as any other folks bringing any other proposed modification to IPv6. i.e., evaluation of such proposals would seem to me like normal operation of the wg, rather than something that we've to agree on that we're going to do. >>> To summarize, the text in this document has the second order effect of >>> not leaving a clear path forward for extensions to IPv6 so that they >>> adhere to the protocol's architecture, specially when applied to a >>> controlled domain. At a minimum, I would like to see a clear path >>> forward, whether that is in the form of an update for use of extensions >>> in controlled domains, or a statement that this document just applies to >>> IPv6 traffic intended to cross the Internet (as suggested at the 6man >>> meeting in Chicago [4])... My opinion is that this document should not >>> be published as an Internet Standard until the remaining open discussions >>> are explicitly resolved and this document reflects that resolution. > > As I understand the rules on promotion to IS, we cannot add new, untested > features to the protocol. That means that adding header insertion is > out of the question. All that is actually proposed is clarifying the > intention, which was badly drafted in RFC 1883 and not corrected in > RFC 2460. Exactly. >> [...] >>> (B) >>> >>> As it stands, the note about the changed expectations for the Hop-by-Hop >>> options header opens a significant door to work around the "limitations" >>> of other options. For example, it would be relatively straight forward >>> to define a new Hop-by-Hop option to carry any type of information that >>> could then be "examined, processed, inserted, or deleted by any node >>> along a packet's delivery path". >> >> Yes, the text is misleading, and should be improved. I pointed this one >> to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The >> text needs to be improved, so that this is not seen as a yet another >> loophole for suggesting that H insertion is allowed in IPv6 -- which was >> certainly not the intent. > > I don't see that. The text says that HbH options may be examined and > processed; it does not say that they may be inserted or deleted. But > it would do no harm to add a 'must not' I guess. > > The other tiny change would be to qualify the "Note:..." by writing > "Note: If an intermediate forwarding node _nevertheless_ examines > an extension header for any reason,...". That would eliminate the > minor inconsistency that the text refers to "one" exception. The text currently says: With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. That is certainly misleading, since the exception is only about "examined and processed", but not about "inserted or deleted". The text should be unfolded such that it is clear that the exception only has to do with HBH being examined and processed, anout not about HBH being inserted or deleted. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Apr 9 06:52:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6671205D3; Sun, 9 Apr 2017 06:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jMCA6XJ6Dr4t; Sun, 9 Apr 2017 06:52:20 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB24129434; Sun, 9 Apr 2017 06:52:17 -0700 (PDT) Received: from [192.168.0.63] (unknown [2.219.17.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2EF8680F17; Sun, 9 Apr 2017 15:52:14 +0200 (CEST) Subject: Re: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Eric Rescorla , The IESG References: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <64008df9-352c-b93f-c92c-55f8fd21cfca@si6networks.com> Date: Sun, 9 Apr 2017 11:54:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 13:52:24 -0000 On 04/08/2017 02:36 PM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-6man-rfc2460bis-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This security considerations section seems fairly unsatisfactory. > First, you can't just point back to IPv4, which doesn't even have a > security considerations section. Second, IPv6 actually has > different security and privacy properties than IPv4 in > a number of respects, so you actually need to document them. FWIW, I commented on this and provided some suggestions here: * * > S 4.5. > As I read this document the order of headers is only strongly > recommended, but the rules about fragmentation seem to absolutely > require a specific order: > > The Per-Fragment Headers consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to the > destination, that is, all headers up to and including the Routing > header if present, else the Hop-by-Hop Options header if present, > else no extension headers. > > Is there a reason why the rules are not MUST? I don't think fragmentation encorces stricker EH ordering than the rest of the document. Thinking out loud, however, I'd say it'd be a good thing to enforce such order --- and I'd probably also limit the number of instances of each EH type. (the latter, I'd agree, would probably be out-of-scope for this bis document?) > S 4.5. > The following conditions are not expected to occur, but are not > considered errors if they do: > > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > > If fragments follow different paths (not crazy) then the hop limit > will be different, right? So perhaps "not expected" is a bit strong. This text talks about occurence of EHs, rather than e.g. differences in the value of the Hop Limit. That said, I'm of the idea that if there's no way something should happen in legitimate cases, then "still allowing for that" is essentially a present for potential attackers that might find a creative way of exploiting the "feature" (in this case, mismatching EHs in different packets). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Apr 9 06:53:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46F129486 for ; Sun, 9 Apr 2017 06:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 w_9cw1x1svXy for ; Sun, 9 Apr 2017 06:52:25 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC36D1205D3 for ; Sun, 9 Apr 2017 06:52:24 -0700 (PDT) Received: from [192.168.0.63] (unknown [2.219.17.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9C34580F17; Sun, 9 Apr 2017 15:52:21 +0200 (CEST) Subject: Re: To: Brian E Carpenter , Fernando Gont , Bob Hinden , IPv6 List References: <03bf42e7-504c-2dd9-3824-2aec6e83e329@gmail.com> <905ec8d5-bef4-ff21-4912-457fd39d2e40@gmail.com> <3d4d3596-3b19-122c-6c50-226d4385b803@gont.com.ar> <7a8315fc-eabf-6632-03ed-54a5c2e3f5d5@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <88419b9f-395b-b564-4510-9ad8d6522f34@si6networks.com> Date: Sun, 9 Apr 2017 14:21:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7a8315fc-eabf-6632-03ed-54a5c2e3f5d5@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 13:52:26 -0000 On 04/08/2017 02:21 PM, Brian E Carpenter wrote: > On 08/04/2017 10:37, Fernando Gont wrote: >> Brian, >> >> FWIW, I'm against the proposed "clarification". I don't think we want >> "IPv6 for the Internet", "IPv6 for...", "IPv6 for..". If we move in that >> direction, it's not hard to envision this kind of conversation: >> >> A: I have finally deployed IPv6 >> B: Which variant? >> >> IPv6 is IPv6. And it is an end-to-end protocol. Inserting EHs is quite >> the opposite to e2e, and in a very radical way. > > IPv4 is IPv4. And it is an end-to-end protocol. Inserting NATs is quite > the opposite to e2e, and in a very radical way. > > Yet we had zero success in preventing NATs. But nobody argued that NATs were compliant with the IP model, which is what's going on here. As noted in my previous email, if there's a clear need for something, and it's also clear that the only/best possible way to do that is to insert EHs, fine. But pretending that there are loopholes in RFC2460 that allow for EH insertion, or meaning to block this document from going to IS because it just make it crystal clear what has always been the case, is not. That is, let's call a lemon like that: "lemon". >> It's kind of unfortunate that, after the sequence of events we have had >> for this I-D, folks seem to find yet another loophole to accommodate the >> future plans of a single vendor. > > I don't think this creates a loophole at all. The loophole is already > there: there are no protocol police. I think we need a clear applicability > statement: the IPv6 standard is for Internet-wide interoperability. If > you don't follow this standard, you won't achieve interoperability. It's not just Internet-wide. If you mean to operate, say, in multiple domains (without that including "the Internet"), and packets leak from one domain to another, you still fail to interoperate. I think there's no need for rfc2460bis to have an applicability statement. Actually it's the other way arund: if the wg eventually agrees to do EH, then such document should have a big boilerplate that says "look, we're breaking the e2e model, and the IPv6 operation context, and these are the implications, and possible problems that may arise. You're supposed to use this only in a blahblah domain. If you're packets leak out of that domain, you're probably busted" >> Thus, I don't think the current version of the I-D requires any changes. >> Actually quite the opposite: such modification would be incorrect. > > We want exactly the same final result... Agreed. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Apr 9 07:42:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110D7126D05 for ; Sun, 9 Apr 2017 07:42: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51726ITQIv27 for ; Sun, 9 Apr 2017 07:42:20 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 F37591274D0 for ; Sun, 9 Apr 2017 07:42:17 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id m133so25243909ybb.1 for ; Sun, 09 Apr 2017 07:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zN+N1CZK4vX4o9A70dX9zVbEi9YzRvc70vKRN/k+AGo=; b=aJ/nGjpGRv7CucPkS/NJvHLtV+hgjoaNPjG2occHaAzLWWDtB3OrIUr7dWvJ9skNcW RpgGkVCmqoYRaoOpcuatwjQmpcMYeOdTo176I+8g/yVHTO558OpuqZvSUnRd/xFl3O5u iSSC/96InF/ijRYyWXeRHFeK4sR0He4OPvzd2cI/7QCWE22K4zlzSiU28pfDBGkbPHAI 8nHN4AAe0DrhihHz59zygFjl3SHmgn/5IC36IPb5GkUzzq9XQnoMliZXfedYXct65APi J2nP5C8+6BxGqpSdryV2AQzF1xQqViFFXe0xjCFiduroN6jsWznFjSl1Cchj9x8kc1K6 A+bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zN+N1CZK4vX4o9A70dX9zVbEi9YzRvc70vKRN/k+AGo=; b=CwEQxK/I7lDlDzAXFcdB3Ac7GTMlpR6xAPA77eXgUZ4+FstYVv0jj+AyoT8aq60Vlb XQpblLNJx51YStkk8bxLK5DKzJ85dpMoaZ+InBMZajPn0/WRSckmITpJTb0vxBa+Em/+ bbs4WcoJftrBwg8DYB+csZ2rkV01ACqLpYnb0LgRDIZcsmG6EJks+FmIreQl2e0FKjAs +0jI526bBTykmj4yKZJDTnentee/Z8L3Ff7BmlclCPKfHxLorq/lVPt4l28pVxynuZoV ysNqjhaaJIeZgyOsLQm4f2N6EX4AXvR7z+MxaP9623yA3L9oLB99dra70dG7z3Jwrzf2 Jqcg== X-Gm-Message-State: AN3rC/5e18XWWHrfVBrrJg4xX6IXx4R/19PoxrhoAY1AUQDEMh7Z2ClqQVPVmlhIDwPOgbUoTu/R4kodZ2wq1A== X-Received: by 10.37.89.139 with SMTP id n133mr10334795ybb.65.1491748937117; Sun, 09 Apr 2017 07:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sun, 9 Apr 2017 07:41:36 -0700 (PDT) In-Reply-To: <64008df9-352c-b93f-c92c-55f8fd21cfca@si6networks.com> References: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> <64008df9-352c-b93f-c92c-55f8fd21cfca@si6networks.com> From: Eric Rescorla Date: Sun, 9 Apr 2017 07:41:36 -0700 Message-ID: Subject: Re: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Fernando Gont Cc: The IESG , draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a1147caa27ddf7a054cbcdd63 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 14:42:22 -0000 --001a1147caa27ddf7a054cbcdd63 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 9, 2017 at 3:54 AM, Fernando Gont wrote: > On 04/08/2017 02:36 PM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-6man-rfc2460bis-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This security considerations section seems fairly unsatisfactory. > > First, you can't just point back to IPv4, which doesn't even have a > > security considerations section. Second, IPv6 actually has > > different security and privacy properties than IPv4 in > > a number of respects, so you actually need to document them. > > FWIW, I commented on this and provided some suggestions here: > > * > qid=7ea59f7651fdf59475568e052b5c1609> > > * > vxQ6AsjveevcXAA_jdTtjSY/?qid=7ea59f7651fdf59475568e052b5c1609> > > I'm not saying that this is a bad topic for security considerations, but I also don't think it would be sufficient itself. > > > > > > S 4.5. > > As I read this document the order of headers is only strongly > > recommended, but the rules about fragmentation seem to absolutely > > require a specific order: > > > > The Per-Fragment Headers consists of the IPv6 header plus any > > extension headers that must be processed by nodes en route to the > > destination, that is, all headers up to and including the Routing > > header if present, else the Hop-by-Hop Options header if present, > > else no extension headers. > > > > Is there a reason why the rules are not MUST? > > I don't think fragmentation encorces stricker EH ordering than the rest > of the document. > Well, the rest of the document doesn't require any order. My point is that if you use a different order, then these rules will not behave properly. > > Thinking out loud, however, I'd say it'd be a good thing to enforce such > order --- and I'd probably also limit the number of instances of each EH > type. (the latter, I'd agree, would probably be out-of-scope for this > bis document?) > > > > S 4.5. > > The following conditions are not expected to occur, but are not > > considered errors if they do: > > > > The number and content of the headers preceding the Fragment > > header of different fragments of the same original packet may > > differ. Whatever headers are present, preceding the Fragment > > header in each fragment packet, are processed when the packets > > arrive, prior to queueing the fragments for reassembly. Only > > those headers in the Offset zero fragment packet are retained in > > the reassembled packet. > > > > If fragments follow different paths (not crazy) then the hop limit > > will be different, right? So perhaps "not expected" is a bit strong. > > This text talks about occurence of EHs, rather than e.g. differences in > the value of the Hop Limit. > The text says "number and *content*". Am I misreadng it? -Ekr That said, I'm of the idea that if there's no way something should > happen in legitimate cases, then "still allowing for that" is > essentially a present for potential attackers that might find a creative > way of exploiting the "feature" (in this case, mismatching EHs in > different packets). > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a1147caa27ddf7a054cbcdd63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 9, 2017 at 3:54 AM, Fernando Gont <fgont@si6networks.c= om> wrote:
On 04/08/2017 02:36 PM, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-6man-rfc2460bis-09: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/d= oc/draft-ietf-6man-rfc2460bis/
>
>
>
> ------------------------------------------------------------= ----------
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> This security considerations section seems fairly unsatisfactory.
> First, you can't just point back to IPv4, which doesn't even h= ave a
> security considerations section. Second, IPv6 actually has
> different security and privacy properties than IPv4 in
> a number of respects, so you actually need to document them.

FWIW, I commented on this and provided some suggestions here:

*
<https://mailarchive.ietf.org/arch/msg/ietf/zW2Bh413= vVJWgMGSZDOHwM9BZ2I/?qid=3D7ea59f7651fdf59475568e052b5c1609<= /a>>

*
<https://mailarchive.ietf.org/arch/msg/ietf/ZCb-vxQ6= AsjveevcXAA_jdTtjSY/?qid=3D7ea59f7651fdf59475568e052b5c1609&g= t;


I'm not sa= ying that this is a bad topic for security considerations, but I also don&#= 39;t think it would be sufficient itself.




> S 4.5.
> As I read this document the order of headers is only strongly
> recommended, but the rules about fragmentation seem to absolutely
> require a specific order:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The Per-Fragment Headers consists of the IPv= 6 header plus any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension headers that must be processed by = nodes en route to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0destination, that is, all headers up to and = including the Routing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0header if present, else the Hop-by-Hop Optio= ns header if present,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0else no extension headers.
>
> Is there a reason why the rules are not MUST?

I don't think fragmentation encorces stricker EH ordering than t= he rest
of the document.

Well, the rest of the = document doesn't require any order. My point is that if you use a diffe= rent order, then these rules will not behave properly.
=C2=A0

Thinking out loud, however, I'd say it'd be a good thing to enforce= such
order --- and I'd probably also limit the number of instances of each E= H
type. (the latter, I'd agree, would probably be out-of-scope for this bis document?)


> S 4.5.
>=C2=A0 =C2=A0 The following conditions are not expected to occur, but a= re not
>=C2=A0 =C2=A0 considered errors if they do:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The number and content of the headers preced= ing the Fragment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0header of different fragments of the same or= iginal packet may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0differ.=C2=A0 Whatever headers are present, = preceding the Fragment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0header in each fragment packet, are processe= d when the packets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0arrive, prior to queueing the fragments for = reassembly.=C2=A0 Only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0those headers in the Offset zero fragment pa= cket are retained in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the reassembled packet.
>
> If fragments follow different paths (not crazy) then the hop limit
> will be different, right? So perhaps "not expected" is a bit= strong.

This text talks about occurence of EHs, rather than e.g. differences= in
the value of the Hop Limit.

The text sa= ys "number and *content*".=C2=A0 Am I misreadng it?
-Ekr

That said, I'm of the idea that if there's no way something should<= br> happen in legitimate cases, then "still allowing for that" is
essentially a present for potential attackers that might find a creative way of exploiting the "feature" (in this case, mismatching EHs in=
different packets).

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a1147caa27ddf7a054cbcdd63-- From nobody Sun Apr 9 08:23:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B71241FC; Sun, 9 Apr 2017 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 AKeCZ_4yU5XY; Sun, 9 Apr 2017 08:23:31 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 087FF126C83; Sun, 9 Apr 2017 08:23:31 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id 68so11554503ioh.3; Sun, 09 Apr 2017 08:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=t+fBfmk3nUTUfc8BJmRSbilVZ1By8Bf3DAc85gp7+yM=; b=qj/cbPR5IYvZH3VfiwleDxYSz87nIM97dk/VfBHKpCz3bRINHHabySm1wG6LExt9F6 RndPTLVepDbouI30TYPK4BQBIAAKQzXe68WSwNBo1/2Azf7IfPuTypwGBc3cucgnaG1r d7gUd2Fcvv4hZmC71R7cxEXfEHgmTvmJSiUO6aGwuRjkQ3mns9eYvN2jx8EED0LajDgB WwMgdfcv+/+b8ZXcB+23mo4Z5A/8dNTWg2fCLO2VePZ2BwuWULoMpgoSR7uieOE1jBCI 1dcTjdQuezJE0SDsMJmI3uWvgjvnaIqx8l45Go5O150zzjCxpq8RPs6jI6JfzXdiheVL tZEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=t+fBfmk3nUTUfc8BJmRSbilVZ1By8Bf3DAc85gp7+yM=; b=WnwPvtKgTLsUUHvJd4RHxfYvS6G/nf7R0gC/yCBdw0euWYevqv38kVGWr5xdWU7rbm Hn4M8XhOelVMLPKaEE0q8400Y07wqCDsvyb45N5+TZvQPLyDHL5cFkP8KtTsSWPe/cF8 Kryi5vN69WzWNkbSE9/O77vK2CmYhP4U0jQUjVPYhjaI8qKfY2Q/Ni88pBsXtgXVPsW1 GTNgYbg2nwkMtgoYn+TeKIJqeHWqRlBX1xx63Xqk1brX4uOyOmqBFiaXGf6RIIE4pUiZ KD47qPbUN0JBGk/fzkurhR97PdFnvZL5Eyqgr7YwsYpsQ7T8i3DKpuus9xwMOCGH4PSc Sj5w== X-Gm-Message-State: AN3rC/5RuR3REcik6UHxMD84heUUp+qEOkwhJ0w+nFykcGft5WaAnpYFsuew0N4ZOySxTQ== X-Received: by 10.107.18.5 with SMTP id a5mr13170306ioj.189.1491751410222; Sun, 09 Apr 2017 08:23:30 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id v23sm2364161ite.6.2017.04.09.08.23.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 08:23:29 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Fernando Gont , Alvaro Retana , The IESG References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> <7ff7970f-98bb-a939-5253-33aed259e772@si6networks.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, Ivan Arce , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <49f097ef-5401-d380-3823-d88f518b5c4b@gmail.com> Date: Mon, 10 Apr 2017 03:23:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7ff7970f-98bb-a939-5253-33aed259e772@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 15:23:33 -0000 On 09/04/2017 23:11, Fernando Gont wrote: > Hi, Brian, > > Some additional comments about specific parts (I've omitted everything > else, since we're in agreement :-) )... > > On 04/08/2017 02:11 PM, Brian E Carpenter wrote: >> On 08/04/2017 11:21, Fernando Gont wrote: >>> Alvaro, >>> >>> On 04/07/2017 07:39 PM, Alvaro Retana wrote: > [....] >>> If you agree with the IETF LC (as oted), I'm not sure why *opinions* >>> verted into the mailing list (*not* wg consensus of any sort) that >>> happened *after* the IETF LC should affect this document moving forward. >> >> Firstly, my opinion is indeed not part of the consensus; I fully support >> the WG consensus to publish this draft as IS. It *is* my opinion that >> after doing so, we should carefully examine proposals to define *exceptions* >> to the ban on header insertion. >> >> I have proposed a small clarification in the Introduction to make it >> clear that the scope of this draft is interoperation across the Internet >> as whole. I believe that completely answers Alvaro's point. > > Since you have no way of ensuring that packets from such domain will not > leak out that domain, Well, that's exactly why we would need a detailed specification for how the boundary of the "controlled domain" would work. That's clearly new work. > you cannot really pretend that "I can break the > protocol in anyway I please, since it's my own personal domain" -- > actually, you can... but you don't need a standard for that. > > So any of such proposals should be evaluation considering that packet > may leak out (plan for the worst, expect for the best). An interesting aspect is "who gets hurt?" I think the answer is that only users inside domains that insert headers will get hurt, if such packets escape and are dropped. But that also needs detailed analysis. > > That's not an argument against EH insertion but rather: > > * Accept that EH insertion is a modification to IPv6 (as opposed to > pretending that there are loopholes that allow for it) > > * Evaluate what's the damage in case packets leak out of such domain > > * Evaluate if there are alternative ways of ng the same thing, without > the aforementioned risks (e.g., tunelling) > > * IMO, IETF can be assumed to standardize *I* protocols which, unless > otherwise specified, are expected to operate over the Internet. There's > no need to say/clarify that. Well, I looked for that in the rules for Internet Standard (RFC 6410) and didn't find it. That's why I suggested adding it to 2460bis - exactly because the Internet Protocol is *above all* the standard that is expected to operate over the Internet. But if you are correct, Alvaro's DISCUSS is simply wrong: the scope is by definition the Internet, so by definition locally inserted or deleted extension headers are out of scope for this document. My extra words are only intended to confirm that logic. If we don't need them, so much the better. > And in fact, that might trigger folks > assuming that there's a shortcut to modify or break protocols by simply > defining an appropriate "domain". Don't worry, plenty of people assume that anyway :-(. > Folks coming with a proposal about EH insertion need not be any more > special as any other folks bringing any other proposed modification to IPv6. > > i.e., evaluation of such proposals would seem to me like normal > operation of the wg, rather than something that we've to agree on that > we're going to do. I agree. Once we get rfc2460bis in the RFC Editor queue, of course. >>>> To summarize, the text in this document has the second order effect of >>>> not leaving a clear path forward for extensions to IPv6 so that they >>>> adhere to the protocol's architecture, specially when applied to a >>>> controlled domain. Alvaro: Correct, and that is intentional. The *intention* is to forbid insertion of extension headers in the Internet. >>>> At a minimum, I would like to see a clear path >>>> forward, whether that is in the form of an update for use of extensions >>>> in controlled domains, I think that is clearly in breach of the rule in RFC6410: "(3) There are no unused features in the specification that greatly increase implementation complexity." because it would be a new feature of the protocol that has definitely not seen "widespread deployment and successful operational experience" as required by rule (1) in RFC6410. >>>> or a statement that this document just applies to >>>> IPv6 traffic intended to cross the Internet (as suggested at the 6man >>>> meeting in Chicago [4])... See above - Fernando and I have exactly opposite opinions on this. Brian >>>> My opinion is that this document should not >>>> be published as an Internet Standard until the remaining open discussions >>>> are explicitly resolved and this document reflects that resolution. >> >> As I understand the rules on promotion to IS, we cannot add new, untested >> features to the protocol. That means that adding header insertion is >> out of the question. All that is actually proposed is clarifying the >> intention, which was badly drafted in RFC 1883 and not corrected in >> RFC 2460. > > Exactly. > > > > >>> [...] >>>> (B) >>>> >>>> As it stands, the note about the changed expectations for the Hop-by-Hop >>>> options header opens a significant door to work around the "limitations" >>>> of other options. For example, it would be relatively straight forward >>>> to define a new Hop-by-Hop option to carry any type of information that >>>> could then be "examined, processed, inserted, or deleted by any node >>>> along a packet's delivery path". >>> >>> Yes, the text is misleading, and should be improved. I pointed this one >>> to Brian and Suresh off-list, based on comments by Ivan Arce (CCed). The >>> text needs to be improved, so that this is not seen as a yet another >>> loophole for suggesting that H insertion is allowed in IPv6 -- which was >>> certainly not the intent. >> >> I don't see that. The text says that HbH options may be examined and >> processed; it does not say that they may be inserted or deleted. But >> it would do no harm to add a 'must not' I guess. >> >> The other tiny change would be to qualify the "Note:..." by writing >> "Note: If an intermediate forwarding node _nevertheless_ examines >> an extension header for any reason,...". That would eliminate the >> minor inconsistency that the text refers to "one" exception. > > The text currently says: > > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. > > That is certainly misleading, since the exception is only about > "examined and processed", but not about "inserted or deleted". > > The text should be unfolded such that it is clear that the exception > only has to do with HBH being examined and processed, anout not about > HBH being inserted or deleted. > > Thanks! > > Cheers, > From nobody Sun Apr 9 08:30:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AB127241; Sun, 9 Apr 2017 08:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 Pu2SUyaGbIJr; Sun, 9 Apr 2017 08:30:03 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 6102F12704A; Sun, 9 Apr 2017 08:30:03 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id 68so11563514ioh.3; Sun, 09 Apr 2017 08:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Ha0KgK0vTZOjP2+5pUMTDErgOpF+pdc1XO59ldWHkJ4=; b=TnT5E8tblKLinbyG76bExOTYhZ9N0hunUknLpoRcA8/7nzXlJ/KN2O5rkb9GvzBuh9 FSXGcw1S3rBHrczIMabpd9iwBHNktqjZ259Ye1nZe1QjBKdb4S14WCp5XRdUV7xBIzBg wrVef+mii2J84UuYLx3AQ9joUHwFmmftVH0Q1ROfpXJdcUMVtXS5qfjlq5K83lBAVyEy X4B58/Xq8Gi0mFenoR8HDK1HHJBCm+uJn9tOuKjxLnyExKiIlIPlxahsggK+vkr5q3FH uGIM44zSUEkSBVy88cbtt7etMgIbCkl7CZ1xrp1m6FQxPpAwcIVQj69E4upiPwUMV8ZY UUFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Ha0KgK0vTZOjP2+5pUMTDErgOpF+pdc1XO59ldWHkJ4=; b=o4N2NmosQ+kCaFfZzmbkvNwDBtvpnu74EQ7d4yGwhrhPoTrIUL/Eq3g033KAIb+UvU xZpnd4C5aEPpykKBKtRT7eEosgXR4e/N4xmjxdKp6MDCU5hbX6K4mv4EdClr5/wZ9uni P/UzphkEnsXI/AJERPH3X9WiGZkVt0R8nnLb/5QXHBWjyxfufNqcJ2WjAqUOADrAy5Kh +Uck2PuS0fsNmHt1QijePN/x98shTVDwelZB5g5eE5ZrINiS5qpJ5/tedR1VWRg7SUAl 4qz7uxUCCu9reys4js4LlHAYa3DCxHTO14qoTdzZwCcoP0KqVMRNBjmFzKl//CWXllRs 2fnA== X-Gm-Message-State: AFeK/H3XMm+2NMrN8D651QskPgPtT6P7kh52iBpX7pYMBB+rcesB0hs48TVigtZLNL00Sg== X-Received: by 10.107.165.9 with SMTP id o9mr47407528ioe.73.1491751802668; Sun, 09 Apr 2017 08:30:02 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id u124sm2334914ita.27.2017.04.09.08.30.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 08:30:02 -0700 (PDT) Subject: Re: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Eric Rescorla , The IESG References: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 10 Apr 2017 03:30:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 15:30:05 -0000 On 09/04/2017 01:36, Eric Rescorla wrote: ... > DISCUSS: > ---------------------------------------------------------------------- > > This security considerations section seems fairly unsatisfactory. > First, you can't just point back to IPv4, which doesn't even have a > security considerations section. Second, IPv6 actually has > different security and privacy properties than IPv4 in > a number of respects, so you actually need to document them. I've been mulling that over. And I am a bit puzzled. The question is which security issues apply to *this* document? There are of course substantive security and privacy issues affecting many other IPv6 documents (neighbour discovery, SLAAC, IID creation, ICMPv6, etc. etc.) But what is specific to this one? Or to ask it another way, what security considerations would you include in rfc791bis? Brian From nobody Sun Apr 9 09:00:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B134E126D05 for ; Sun, 9 Apr 2017 09:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-pHaMw6lQEb for ; Sun, 9 Apr 2017 09:00:41 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 A63B81273B1 for ; Sun, 9 Apr 2017 09:00:39 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id p77so50642829ywg.1 for ; Sun, 09 Apr 2017 09:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1FQwqu4D2OQRtZRKXp2gqzgGGb5mFldPVygYCLCwoJU=; b=2HoOmr8Owx4MgrZknGBdd6CXqkHwQCMPqydNcwCyEeDE63kJ9tp2FgnmegIKISfmd3 S5dfqQAr9I8P8wQOs17yA8LqFMEwj8jdR9z7t6KrROSM654StZegyX8D1Io3Ia7IsZ+C wBPhHWGNFYDl0TWsV6ALBWGpkrqfCyBNTN/noxVIkQyo6Xfgdsk97BfrOU4Zq/BzpZSa WDwUekk5I3UvUSnRaAK65pD8GlpME8McbK7/p/MRsn4zdTFvi10QIk6XhEV6UEnTVlQE 02jtA/bE5ZTKHxHvRTjzUBSJobDJuMW5Ttygc0MCm0l+mIk3DvMSP03RrbIxNJYl5FsQ 6WbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1FQwqu4D2OQRtZRKXp2gqzgGGb5mFldPVygYCLCwoJU=; b=mncbz8fklcvK+3pfK+jWPTflpvEDL2PcZ+avtRpLx7SaWZ0xxnv3l9+xVQ7/ymmhIm L4n+QxU/LyznSKImhE701kHNUznNpj4Xu8tttJtgvrX6aeUwS9yvsMCEqz420elILEl/ IARF0hQPenqaf9akzuPDdlLsJBJotaOQ2tdIJ8kSt2/BEGHfkD0bcw1UC3RjOlCLXtCw sQAqzZseqCKM/ziRJ1+I6VcsTaCRjQRviILF5d9djjIwGSdCdeeXdncx29ZkmttKb7EP hipse5DdR+oCbUaMXZ8QM0ZvvW4w5wZraKRI2dYhnLSvE1jVgBfhreCDM0nELJieP3ba A0Cg== X-Gm-Message-State: AFeK/H3+LflwqVCiCk4iPIsHLEIVcdeScXlg5cRJoNtzRpbW0uD+mwtiP57tYAnYy0GMN24f6xHTAxKATmpYkw== X-Received: by 10.129.125.5 with SMTP id y5mr32629595ywc.120.1491753638600; Sun, 09 Apr 2017 09:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sun, 9 Apr 2017 08:59:58 -0700 (PDT) In-Reply-To: References: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sun, 9 Apr 2017 08:59:58 -0700 Message-ID: Subject: Re: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Brian E Carpenter Cc: The IESG , draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a11493644b8d515054cbdf51c Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 16:00:42 -0000 --001a11493644b8d515054cbdf51c Content-Type: text/plain; charset=UTF-8 On Sun, Apr 9, 2017 at 8:30 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 09/04/2017 01:36, Eric Rescorla wrote: > ... > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This security considerations section seems fairly unsatisfactory. > > First, you can't just point back to IPv4, which doesn't even have a > > security considerations section. Second, IPv6 actually has > > different security and privacy properties than IPv4 in > > a number of respects, so you actually need to document them. > > I've been mulling that over. And I am a bit puzzled. The question is > which security issues apply to *this* document? That's the analysis I'm saying needs to be done. > There are of course > substantive security and privacy issues affecting many other IPv6 documents > (neighbour discovery, SLAAC, IID creation, ICMPv6, etc. etc.) But what > is specific to this one? > > Or to ask it another way, what security considerations would you > include in rfc791bis? > Just off the top of my head: - Origin IP addresses can't be trusted (I assume this is part of the reason for the restrictions on reversing the routing header) - IP addresses are a potential tracking identifier - Absent IPsec, IP doesn't provide confidentiality (or, as noted, integrity and authentication) - IP fragmentation DoS attacks. No doubt a real security considerations would have more. However, as I said, IPv6 has different properties. -Ekr --001a11493644b8d515054cbdf51c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 9, 2017 at 8:30 AM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
On 09/04/2017 01:36, Eric Rescorla wrote:
...
> DISCUSS:
> ------------------------------------------------------------= ----------
>
> This security considerations section seems fairly unsatisfactory.
> First, you can't just point back to IPv4, which doesn't even h= ave a
> security considerations section. Second, IPv6 actually has
> different security and privacy properties than IPv4 in
> a number of respects, so you actually need to document them.

I've been mulling that over. And I am a bit puzzled. The questio= n is
which security issues apply to *this* document?

That's the analysis I'm saying needs to be done.
=C2=A0
= There are of course
substantive security and privacy issues affecting many other IPv6 documents=
(neighbour discovery, SLAAC, IID creation, ICMPv6, etc. etc.) But what
is specific to this one?

Or to ask it another way, what security considerations would you
include in rfc791bis?

Just off the top = of my head:

- Origin IP addresses can't be tru= sted (I assume this is part of the reason
=C2=A0 for the restrict= ions on reversing the routing header)
- IP addresses are a potent= ial tracking identifier
- Absent IPsec, IP doesn't provid= e confidentiality (or, as noted, integrity and authentication)
- = IP fragmentation DoS attacks.

No doubt a real secu= rity considerations would have more.

However, as I= said, IPv6 has different properties.

-Ekr
=C2=A0
--001a11493644b8d515054cbdf51c-- From nobody Sun Apr 9 10:40:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB76C1241FC; Sun, 9 Apr 2017 10:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 KmfRJ1nu--_p; Sun, 9 Apr 2017 10:40:14 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F8112778D; Sun, 9 Apr 2017 10:40:11 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id BC634739BD; Sun, 9 Apr 2017 13:40:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=FQ5FzJq7EpbnCpcTr5bclsP3YNY=; b=OK8WvS ea7AU2w9UBqyJVD57D/FrDeGMX+UGb44XpBk/Q5faB7r5h4emgl+Im5J17rdgK2c g481kdgWVZvQlxj3uip49FgQ8mqkIBnLulNXru+77Q1CVM6D3pq4ibc6TvRUCX2x cXlOx9cf13WAJYhUcflIAJ8HXCle/K1iwwWZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=Zuyk9apF5+/ETha05JgbtKmaAMasxzSJ OCwqojyKuLbrmAU5kZuIn4hRlQuLrz2DuO+tkXX1TDA1WXtDIK/Q38/jaDQlIXY9 xDn+IHizVvRRL2g8RLbw9RBet+MbahIA9hBOiFQGcr570S1wPOFoBNFCMZWAO7OG EwIVG+fAiIM= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AA700739BC; Sun, 9 Apr 2017 13:40:09 -0400 (EDT) Received: from mail-qt0-f170.google.com (unknown [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 2D57E739B8; Sun, 9 Apr 2017 13:40:09 -0400 (EDT) Received: by mail-qt0-f170.google.com with SMTP id v3so40681470qtd.3; Sun, 09 Apr 2017 10:40:09 -0700 (PDT) X-Gm-Message-State: AN3rC/5pklNradMEiXKzLAEU7jUOBTKqZBYR92vz/xzzc894BAUS0m9kZNcUIYRL2BzCny0/dzARq8yjR0nrQw== X-Received: by 10.200.45.155 with SMTP id p27mr12093725qta.267.1491759608743; Sun, 09 Apr 2017 10:40:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Sun, 9 Apr 2017 10:39:48 -0700 (PDT) In-Reply-To: References: From: "C. M. Heard" Date: Sun, 9 Apr 2017 10:39:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: To: Brian E Carpenter , Fernando Gont , Alvaro Retana , The IESG Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man Chairs <6man-chairs@ietf.org>, 6man WG , Ivan Arce Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 93784788-1D4B-11E7-9C02-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 17:40:16 -0000 On Mon, 10 Apr 2017 03:23:27 +1200, Brian E Carpenter wrote: >>>>> or a statement that this document just applies to >>>>> IPv6 traffic intended to cross the Internet (as suggested at the 6man >>>>> meeting in Chicago [4])... > > See above - Fernando and I have exactly opposite opinions on this. With due respect to Fernando, I strongly support Brian's proposed revision to the introduction as an appropriate way to address this concern. >>> The other tiny change would be to qualify the "Note:..." by writing >>> "Note: If an intermediate forwarding node _nevertheless_ examines >>> an extension header for any reason,...". That would eliminate the >>> minor inconsistency that the text refers to "one" exception. I support this change also. On Sun, 9 Apr 2017 12:11:38 +0100, Fernando Gont wrote: > The text currently says: > > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. > > That is certainly misleading, since the exception is only about > "examined and processed", but not about "inserted or deleted". > > The text should be unfolded such that it is clear that the exception > only has to do with HBH being examined and processed, [and] not about > HBH being inserted or deleted. Not necessary; the paragraph below describing the exception says: The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. That, to me at least, makes it perfectly clear that the exception allows HbH options to be examined and processed only; since it makes no provision for insertion or deletion, the prohibition in the text above still applies. Mike Heard From nobody Sun Apr 9 12:54:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBB1128656; Sun, 9 Apr 2017 12:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 JBm6maG7q7vn; Sun, 9 Apr 2017 12:54:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5F11276AF; Sun, 9 Apr 2017 12:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11766; q=dns/txt; s=iport; t=1491767668; x=1492977268; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IIPn89P1tcm7lXCc/u1oG0R5EALl7Sm61m+t/0+ujn4=; b=jrFsL1tUC2nJrjOL/HTt8LtVNk+5uJWkyAjiaA5QwkiB2nnB2Q62ZZE4 0IdF27OzSOzJCQGwwyDM0sAonJ78NiEPg18E8NvilZLe0aAYwDOg3Ugyi rFISMP21lJ+DMHqqnohQRiX4Q/aUGUB2XO4tFw2l2re6xygtwm6JtTFxx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQA9kepY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXKRQIgajT2CDyELhXgCGoNEPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToLBQsCAQgSBgICJgICAh8GCxUCDgIEDgWJdwMNCA6oFIImh?= =?us-ascii?q?yINgy0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUWCBYJrglGBYiMXgm8ugjE?= =?us-ascii?q?FiSWTGzsBiiqDcYQ9gX+FLooUiGOCHYh/AR84gQVbFUERAYR+gUp1AYZLgS+BD?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,179,1488844800"; d="scan'208";a="230827906" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2017 19:54:27 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v39JsRiT005947 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 9 Apr 2017 19:54:27 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 9 Apr 2017 15:54:26 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Sun, 9 Apr 2017 15:54:26 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: Fernando Gont , "Alvaro Retana (aretana)" , The IESG , "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , Ivan Arce , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSsWsXQN6LT9J+0UqqVkFBV0xh3g== Date: Sun, 9 Apr 2017 19:54:26 +0000 Message-ID: <377CC903-CD32-434E-8AC5-B4846F356A67@cisco.com> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.162.249] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 19:54:31 -0000 DQo+IE9uIEFwciA4LCAyMDE3LCBhdCAzOjExIFBNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDA4LzA0LzIwMTcgMTE6MjEs IEZlcm5hbmRvIEdvbnQgd3JvdGU6DQo+PiBBbHZhcm8sDQo+PiANCj4+IE9uIDA0LzA3LzIwMTcg MDc6MzkgUE0sIEFsdmFybyBSZXRhbmEgd3JvdGU6DQo+Pj4gRmlyc3Qgb2ZmLCB0aGlzIERJU0NV U1MgaXMgTk9UIGFib3V0IHF1ZXN0aW9uaW5nIHRoZSByb3VnaCBjb25zZW5zdXMNCj4+PiBjYWxs cyB0aGF0IHRoZSByZXNwb25zaWJsZSBDaGFpciBhbmQgQUQgaGF2ZSBtYWRlLCBvciB3YW50aW5n IHRvIGNoYW5nZQ0KPj4+IHRoZW0sIGJ1dCBhYm91dCBjbGFyaWZ5aW5nIHRvIGF2b2lkIG1pc2lu dGVycHJldGF0aW9ucy4NCj4+PiANCj4+PiBHaXZlbiB0aGUgb25nb2luZyBkaXNjdXNzaW9uIGFi b3V0IEV4dGVuc2lvbiBIZWFkZXJzIGFuZCBjb250cm9sbGVkDQo+Pj4gZG9tYWlucyAoZm9yIGV4 YW1wbGUgWzFdIGFuZCBbMl0pLCB0aGUgdGV4dCBzaG91bGQgYmUgdmVyeSBzcGVjaWZpYyBvbg0K Pj4+IHdoYXQgaXMgZXhwZWN0ZWQgYW5kIHdoZXJlLiAgQmVjYXVzZSBpdCBpcyBub3QsIEkgdGhp bmsgdGhhdCB0aGlzDQo+Pj4gZG9jdW1lbnQgaXMgdGVldGVyaW5nIGFsb25nIHRoZSBsaW5lIG9m IGhhdmluZyBhICJoaWdoIGRlZ3JlZSBvZg0KPj4+IHRlY2huaWNhbCBtYXR1cml0eSIsIGFuZCBu b3QgYmVpbmcgcmVhZHkgZm9yIEludGVybmV0IFN0YW5kYXJkDQo+Pj4gW3JmYzY0MTBdLg0KPj4g DQo+PiBXaHkgc2hvdWxkIGFueSB0YWxrIG9uIEVIIGluc2VydGlvbiBhZmZlY3QgdGhpcyBkb2N1 bWVudCBiZWluZyByZWFkeSBmb3IgSVM/DQo+PiANCj4+IEFjdHVhbGx5LCBpdCdzIHF1aXRlIHRo ZSBvcHBvc2l0ZTogdGhlIGV4cGVyaWVuY2Ugd2UgaGF2ZSB3aXRoIElQdjYgaXMNCj4+IHdpdGgg IklQdjYgJ2FzIGlzJyIgKGkuZS4sYW4gZW5kIHRvIGVuZCBwcm90b2NvbCB0aGF0IG9idmlvdXNs eSBkb2VzIG5vdA0KPj4gYWxsb3cgZm9yIEVIIGluc2VydGlvbikuIE9wZW5pbmcgdGhlIGRvb3Ig dG8gRUggaW5zZXJ0aW9uIHdvdWxkIG1ha2UNCj4+IHRoaXMgZG9jdW1lbnQsIGJ5IGRlZmluaXRp b24sIG5vdCByZWFkeSBmb3IgSVMgLS0gYW5kIGFjdHVhbGx5LCBub3QgZXZlbg0KPj4gc3VpdGFi bGUgZm9yIDZtYW4gKHdoaWNoIGlzIGV4cGVjdGVkIHRvIGJlIGFib3V0IG1haW50YWluaW5nIElQ djYsDQo+PiByYXRoZXIgdGhhbiBhYm91dCBhcHBseWluZyByYWRpY2FsIGNoYW5nZXMpLg0KPj4g DQo+PiBTbyB0aGlzIGRvY3VtZW50IGlzIGNsYXJpZnlpbmcgd2hhdCBJUHY2IGhhcyBhbHdheXMg YmVlbjogRUhzIGNhbm5vdCBub3QNCj4+IGluc2VydGVkIGJ5IGludGVybWVkaWF0ZSBub2Rlcy4N Cj4+IA0KPj4gDQo+PiBJIHBlcnNvbmFsbHkgZG9uJ3QgZ2V0IHdoeSB0aGUgZnV0dXJlIHBsYW5z IG9mIGEgdmVuZG9yIHNob3VsZA0KPj4gZXNzZW50aWFsbHkgcnVsZSA2bWFuIHRvIGZ1bmRhbWVu dGFsbHkgY2hhbmdlIGFuIGVuZC10by1lbmQgcHJvdG9jb2wNCj4+IChJUHY2KSBpbnRvIGEuLi53 aGF0Y2hhbWFjYWxsaXQsIG9yIGJlIGEgc2hvdyBzdG9wcGVyIGR1cmluZyBJRVNHIHJldmlldy4N Cj4+IA0KPj4gDQo+PiANCj4+PiBXaXRob3V0IGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMgYW5kIGd1 aWRhbmNlLCB0aGlzIGRvY3VtZW50IGFsc28gYnJpbmdzIG9uDQo+Pj4gdW5hbnRpY2lwYXRlZCBz ZWNvbmQgb3JkZXIgZWZmZWN0cyBbcmZjMzQzOV0gdGhhdCBjYW4gaW1wYWN0IHRoZQ0KPj4+IGRp cmVjdGlvbiwgb3IgZXZlbiB0aGUgdmlhYmlsaXR5LCBvZiBmdXR1cmUgd29yayBpbiB0aGUgSUVU Ri4gDQo+PiANCj4+IEFuIEFyY2hpdGVjdHVyZSB3aWxsIGNsZWFybHkgbGltaXQgYW5kIGRlbGlu ZWF0ZSB3aGF0IHlvdSBjYW4gYW5kIHdoYXQNCj4+IHlvdSBjYW4ndCBkby4gSWYgeW91IGNhbiBk byBhbnl0aGluZyB0aGF0IHlvdSBwbGVhc2UsIHRoZW4gdGhhdCdzIGFuDQo+PiBpbmRpY2F0aW9u IHRoYXQgeW91IGRvbid0IHJlYWxseSBoYXZlIGFuIGFyY2hpdGVjdHVyZS4NCj4gDQo+IEFjdHVh bGx5IGlzIGlzIHRoZSBwcm9wb3NhbCB0byBhbGxvdyBoZWFkZXIgaW5zZXJ0aW9uIHRoYXQgcmlz a3MNCj4gdW5hbnRpY2lwYXRlZCBlZmZlY3RzOyB0aGUgZHJhZnQgc2ltcGx5IGNvbnNvbGlkYXRl cyB0aGUgY3VycmVudA0KPiBzaW1wbGUgaW50ZXJwcmV0YXRpb24gb2YgUkZDIDI0NjAuIEhlYWRl ciBpbnNlcnRpb24gd291bGQgYmUgYWRkZWQNCj4gY29tcGxleGl0eSwgZXhhY3RseSB3aGF0IFJG QyAzNDM5IGlzIGFib3V0Lg0KPiANCj4+PiBTcGVjaWZpY2FsbHksIGEgc3RyYWlnaHQgZm9yd2Fy ZCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgdGV4dCBpbiBTZWN0aW9uIDQNCj4+PiBpcyB0aGUgYWJz b2x1dGUgcHJvaGliaXRpb24gdG8gcHJvY2VzcywgaW5zZXJ0IG9yIGRlbGV0ZSBFSHMgLS0gYnV0 DQo+Pj4gZGlzY3Vzc2lvbiBvbiB0aGUgNm1hbiBtYWlsaW5nIGxpc3Qgc2VlbXMgdG8gcG9pbnQg YXQgYW4gdW5kZXJzdGFuZGluZw0KPj4+IHRoYXQgdGhlIGNvbmRpdGlvbnMgaW5zaWRlIGEgY29u dHJvbGxlZCBkb21haW4gbWF5IGJlIGRpZmZlcmVudCwgZm9yDQo+Pj4gZXhhbXBsZSAoZnJvbSBC cmlhbiBDYXJwZW50ZXIgWzNdKToNCj4+IA0KPj4gSWYgeW91IGFncmVlIHdpdGggdGhlIElFVEYg TEMgKGFzIG90ZWQpLCBJJ20gbm90IHN1cmUgd2h5ICpvcGluaW9ucyoNCj4+IHZlcnRlZCBpbnRv IHRoZSBtYWlsaW5nIGxpc3QgKCpub3QqIHdnIGNvbnNlbnN1cyBvZiBhbnkgc29ydCkgdGhhdA0K Pj4gaGFwcGVuZWQgKmFmdGVyKiB0aGUgSUVURiBMQyBzaG91bGQgYWZmZWN0IHRoaXMgZG9jdW1l bnQgbW92aW5nIGZvcndhcmQuDQo+IA0KPiBGaXJzdGx5LCBteSBvcGluaW9uIGlzIGluZGVlZCBu b3QgcGFydCBvZiB0aGUgY29uc2Vuc3VzOyBJIGZ1bGx5IHN1cHBvcnQNCj4gdGhlIFdHIGNvbnNl bnN1cyB0byBwdWJsaXNoIHRoaXMgZHJhZnQgYXMgSVMuDQoNCg0KSeKAmW0gbm90IHN1cmUgd2Ug aGF2ZSBzdWNoIGNvbnNlbnN1cy4gV2UgX2hhZF8gY29uc2Vuc3VzIG9uIGFub3RoZXIgdGV4dCB0 aGF0IGhhcyBiZWVuIGxhdGVyIHJlbW92ZWQuDQoNCnMuDQoNCg0KPiBJdCAqaXMqIG15IG9waW5p b24gdGhhdA0KPiBhZnRlciBkb2luZyBzbywgd2Ugc2hvdWxkIGNhcmVmdWxseSBleGFtaW5lIHBy b3Bvc2FscyB0byBkZWZpbmUgKmV4Y2VwdGlvbnMqDQo+IHRvIHRoZSBiYW4gb24gaGVhZGVyIGlu c2VydGlvbi4NCj4gDQo+IEkgaGF2ZSBwcm9wb3NlZCBhIHNtYWxsIGNsYXJpZmljYXRpb24gaW4g dGhlIEludHJvZHVjdGlvbiB0byBtYWtlIGl0DQo+IGNsZWFyIHRoYXQgdGhlIHNjb3BlIG9mIHRo aXMgZHJhZnQgaXMgaW50ZXJvcGVyYXRpb24gYWNyb3NzIHRoZSBJbnRlcm5ldA0KPiBhcyAgd2hv bGUuIEkgYmVsaWV2ZSB0aGF0IGNvbXBsZXRlbHkgYW5zd2VycyBBbHZhcm8ncyBwb2ludC4NCj4g DQo+PiBbLi4uXQ0KPj4+IFtOLkIuOiBJJ20gbm90IGltcGx5aW5nIHRoYXQgQnJpYW4ncyBvcGlu aW9uIHJlcHJlc2VudHMgY29uc2Vuc3VzLCB0aGF0DQo+Pj4gaXMgbm90IG15IGNhbGwgdG8gbWFr ZS5dDQo+Pj4gDQo+Pj4gSSdtIHBvaW50aW5nIGF0IGFuIG9waW5pb24gKHdoaWNoIEkgYWdyZWUg d2l0aCkgdGhhdCByZWNvZ25pemVzIHRoZSBuZWVkDQo+Pj4gdG8gZGlmZmVyZW50aWF0ZSBiZXR3 ZWVuIGNvbnRleHRzIC0tIGJ1dCB0aGUgY3VycmVudCB0ZXh0IGluIHJmYzI0NjBiaXMNCj4+PiBk b2Vzbid0IGRvIHRoYXQuICBJIGJlbGlldmUgdGhhdCB0aGlzIGlzc3VlIGlzIHNpZ25pZmljYW50 IChhcyByZWZsZWN0ZWQNCj4+PiBieSB0aGUgb25nb2luZyBkaXNjdXNzaW9ucykgdGhhdCB0aGF0 IGl0IHNob3VsZCBiZSByZXNvbHZlZCAoYnkNCj4+PiBjbGFyaWZ5aW5nIHRoZSB0ZXh0KSBiZWZv cmUgcHJvY2VlZGluZyB3aXRoIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGlzDQo+Pj4gZG9jdW1lbnQg YXMgYW4gSW50ZXJuZXQgU3RhbmRhcmQuIA0KPj4gDQo+PiBBcyBhIHdnIHBhcnRpY2lwYW50LCBJ IHN0cm9uZ2x5IG9wcG9zZSB0byB0aGF0LiByZmMyNDYwYmlzIHNwZWNpZmllcw0KPj4gSVB2NiAt LSBhbiBlbmQgdG8gZW5kIHByb3RvY29sLiBFSCBpbnNlcnRpb24gaGFzIG5vdGhpbmcgdG8gZG8g d2l0aA0KPj4gdGhhdC4gSW4gZmFjdCwgaXQgaW1wbGllcyBhIHJhZGljYWwgY2hhbmdlIHRvIHRo ZSBhcmNoaXRlY3R1cmUuIFNvIEknbQ0KPj4gbm90IHN1cmUgd2h5IHdlJ3JlIGRpc2N1c3Npbmcg d2hhdCBzZWVtcyB0byBiZSAieWV0IGFub3RoZXIgcG9zc2libGUNCj4+IGxvb3Bob2xlIHNvIHRo YXQgYSBnaXZlbiB2ZW5kb3IgY2FuIGRvIHdoYXQgaXQgaGFzIGluIGl0cyBwbGFucyIuDQo+PiAN Cj4+IFBsZWFzZSBub3RlOiA2bWFuIGRlY2lkZWQgdG8gYWNjZXB0DQo+PiBkcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciAgb24gdGhlIGNvbmRpdGlvbiB0aGF0IGFueQ0KPj4g c3VnZ2VzdGlvbnMvc3BlY2lmaWNhdGlvbiBvZiBFSCBpbnNlcnRpb24gd2VyZSByZW1vdmVkLiBU aGF0LCB0b2dldGhlcg0KPj4gd2l0aCB0aGUgSUVURiBMQyBzaG91bGQgYmUgYW4gaW5kaWNhdGlv biByZWdhcmRpbmcgd2hhdCBzZWVtcyB0byBoYXZlDQo+PiBiZWVuIHRoZSBjb25zZW5zdXMgb24g dGhlIHRvcGljLg0KPj4gDQo+PiBJJ20gcHV6emxlZCB3aHkgYW55IHNvcnQgb2Ygb25nb2luZyBk aXNjdXNzaW9uLCB0YWlnIHBsYWNlIHBhc3QgSUVURiBMQywNCj4+IGFuZCBvbiBhIHZlcnkgcmFk aWNhbCBjaGFuZ2UgdG8gdGhlIHByb3RvY29sIGFuZCBhcmNoaXRlY3R1cmUgc2hvdWxkDQo+PiBo YXZlIGFuIGVmZmVjdCBvbiByZmMyNDYwYmlzIGJlaW5nIG1vdmVkIGZvcndhcmQuDQo+PiANCj4+ IA0KPj4gDQo+Pj4gVG8gc3VtbWFyaXplLCB0aGUgdGV4dCBpbiB0aGlzIGRvY3VtZW50IGhhcyB0 aGUgc2Vjb25kIG9yZGVyIGVmZmVjdCBvZg0KPj4+IG5vdCBsZWF2aW5nIGEgY2xlYXIgcGF0aCBm b3J3YXJkIGZvciBleHRlbnNpb25zIHRvIElQdjYgc28gdGhhdCB0aGV5DQo+Pj4gYWRoZXJlIHRv IHRoZSBwcm90b2NvbCdzIGFyY2hpdGVjdHVyZSwgc3BlY2lhbGx5IHdoZW4gYXBwbGllZCB0byBh DQo+Pj4gY29udHJvbGxlZCBkb21haW4uICBBdCBhIG1pbmltdW0sIEkgd291bGQgbGlrZSB0byBz ZWUgYSBjbGVhciBwYXRoDQo+Pj4gZm9yd2FyZCwgd2hldGhlciB0aGF0IGlzIGluIHRoZSBmb3Jt IG9mIGFuIHVwZGF0ZSBmb3IgdXNlIG9mIGV4dGVuc2lvbnMNCj4+PiBpbiBjb250cm9sbGVkIGRv bWFpbnMsIG9yIGEgc3RhdGVtZW50IHRoYXQgdGhpcyBkb2N1bWVudCBqdXN0IGFwcGxpZXMgdG8N Cj4+PiBJUHY2IHRyYWZmaWMgaW50ZW5kZWQgdG8gY3Jvc3MgdGhlIEludGVybmV0IChhcyBzdWdn ZXN0ZWQgYXQgdGhlIDZtYW4NCj4+PiBtZWV0aW5nIGluIENoaWNhZ28gWzRdKS4uLiAgTXkgb3Bp bmlvbiBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgc2hvdWxkIG5vdA0KPj4+IGJlIHB1Ymxpc2hlZCBh cyBhbiBJbnRlcm5ldCBTdGFuZGFyZCB1bnRpbCB0aGUgcmVtYWluaW5nIG9wZW4gZGlzY3Vzc2lv bnMNCj4+PiBhcmUgZXhwbGljaXRseSByZXNvbHZlZCBhbmQgdGhpcyBkb2N1bWVudCByZWZsZWN0 cyB0aGF0IHJlc29sdXRpb24uDQo+IA0KPiBBcyBJIHVuZGVyc3RhbmQgdGhlIHJ1bGVzIG9uIHBy b21vdGlvbiB0byBJUywgd2UgY2Fubm90IGFkZCBuZXcsIHVudGVzdGVkDQo+IGZlYXR1cmVzIHRv IHRoZSBwcm90b2NvbC4gVGhhdCBtZWFucyB0aGF0IGFkZGluZyBoZWFkZXIgaW5zZXJ0aW9uIGlz DQo+IG91dCBvZiB0aGUgcXVlc3Rpb24uIEFsbCB0aGF0IGlzIGFjdHVhbGx5IHByb3Bvc2VkIGlz IGNsYXJpZnlpbmcgdGhlDQo+IGludGVudGlvbiwgd2hpY2ggd2FzIGJhZGx5IGRyYWZ0ZWQgaW4g UkZDIDE4ODMgYW5kIG5vdCBjb3JyZWN0ZWQgaW4NCj4gUkZDIDI0NjAuDQo+IA0KPj4gDQo+PiBU aGUgb251cyBpcyBvbiBmb2xrcyB3YW50aW5nIHRvIGNoYW5nZSB0aGUgY3VycmVudCBzdGF0ZSBv ZiBhZmZhaXJzLg0KPj4gQ2hhbmdpbmcgSVB2NiAoYW4gZW5kLXRvLWVuZCBwcm90b2NvbCkgdG8g YWxsb3cgZm9yIEVIIGluc2VydGlvbiBpcw0KPj4gZXNzZW50aWFsbHkgYSB2ZXJ5IHJhZGljYWwg Y2hhbmdlLi4uIG5vdCBvbmx5IHRvIHRoZSBwcm90b2NvbCwgYnV0IGV2ZW4NCj4+IHRvIHRoZSBh cmNoaXRlY3R1cmUuDQo+PiANCj4+IA0KPj4gWy4uLl0NCj4+PiAoQikNCj4+PiANCj4+PiBBcyBp dCBzdGFuZHMsIHRoZSBub3RlIGFib3V0IHRoZSBjaGFuZ2VkIGV4cGVjdGF0aW9ucyBmb3IgdGhl IEhvcC1ieS1Ib3ANCj4+PiBvcHRpb25zIGhlYWRlciBvcGVucyBhIHNpZ25pZmljYW50IGRvb3Ig dG8gd29yayBhcm91bmQgdGhlICJsaW1pdGF0aW9ucyINCj4+PiBvZiBvdGhlciBvcHRpb25zLiAg Rm9yIGV4YW1wbGUsIGl0IHdvdWxkIGJlIHJlbGF0aXZlbHkgc3RyYWlnaHQgZm9yd2FyZA0KPj4+ IHRvIGRlZmluZSBhIG5ldyBIb3AtYnktSG9wIG9wdGlvbiB0byBjYXJyeSBhbnkgdHlwZSBvZiBp bmZvcm1hdGlvbiB0aGF0DQo+Pj4gY291bGQgdGhlbiBiZSAiZXhhbWluZWQsIHByb2Nlc3NlZCwg aW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUNCj4+PiBhbG9uZyBhIHBhY2tldCdzIGRl bGl2ZXJ5IHBhdGgiLiANCj4+IA0KPj4gWWVzLCB0aGUgdGV4dCBpcyBtaXNsZWFkaW5nLCBhbmQg c2hvdWxkIGJlIGltcHJvdmVkLiBJIHBvaW50ZWQgdGhpcyBvbmUNCj4+IHRvIEJyaWFuIGFuZCBT dXJlc2ggb2ZmLWxpc3QsIGJhc2VkIG9uIGNvbW1lbnRzIGJ5IEl2YW4gQXJjZSAoQ0NlZCkuIFRo ZQ0KPj4gdGV4dCBuZWVkcyB0byBiZSBpbXByb3ZlZCwgc28gdGhhdCB0aGlzIGlzIG5vdCBzZWVu IGFzIGEgeWV0IGFub3RoZXINCj4+IGxvb3Bob2xlIGZvciBzdWdnZXN0aW5nIHRoYXQgSCBpbnNl cnRpb24gaXMgYWxsb3dlZCBpbiBJUHY2IC0tIHdoaWNoIHdhcw0KPj4gY2VydGFpbmx5IG5vdCB0 aGUgaW50ZW50Lg0KPiANCj4gSSBkb24ndCBzZWUgdGhhdC4gVGhlIHRleHQgc2F5cyB0aGF0IEhi SCBvcHRpb25zIG1heSBiZSBleGFtaW5lZCBhbmQNCj4gcHJvY2Vzc2VkOyBpdCBkb2VzIG5vdCBz YXkgdGhhdCB0aGV5IG1heSBiZSBpbnNlcnRlZCBvciBkZWxldGVkLiBCdXQNCj4gaXQgd291bGQg ZG8gbm8gaGFybSB0byBhZGQgYSAnbXVzdCBub3QnIEkgZ3Vlc3MuDQo+IA0KPiBUaGUgb3RoZXIg dGlueSBjaGFuZ2Ugd291bGQgYmUgdG8gcXVhbGlmeSB0aGUgIk5vdGU6Li4uIiBieSB3cml0aW5n DQo+ICJOb3RlOiBJZiBhbiBpbnRlcm1lZGlhdGUgZm9yd2FyZGluZyBub2RlIF9uZXZlcnRoZWxl c3NfIGV4YW1pbmVzDQo+IGFuIGV4dGVuc2lvbiBoZWFkZXIgZm9yIGFueSByZWFzb24sLi4uIi4g VGhhdCB3b3VsZCBlbGltaW5hdGUgdGhlDQo+IG1pbm9yIGluY29uc2lzdGVuY3kgdGhhdCB0aGUg dGV4dCByZWZlcnMgdG8gIm9uZSIgZXhjZXB0aW9uLg0KPiANCj4+IA0KPj4gDQo+PiANCj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4gQ09NTUVOVDoNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gDQo+Pj4g QXBwZW5kaXggQi4gKENoYW5nZXMgU2luY2UgUkZDMjQ2MCkgbWVudGlvbnMgdGhhdCB0aGUgdGV4 dCB3YXMgcmV2aXNlZA0KPj4+IGJhc2VkIG9uIHVwZGF0ZXMgZnJvbSBzZXZlcmFsIG90aGVyIFJG Q3Mgd2hpY2ggVXBkYXRlZCByZmMyNDYwLiAgSSBkaWRuJ3QNCj4+PiBjaGVjayBhbGwgdGhlIGRl dGFpbHMsIGJ1dCBpZiB0aGUgdXBkYXRlcyB3ZXJlIGluY29ycG9yYXRlZCBpbiB0aGlzDQo+Pj4g ZG9jdW1lbnQsIHdoeSBhcmUgdGhvc2UgUkZDcyBub3QgbWFya2VkIGFzIGJlaW5nIE9ic29sZXRl PyAgSXMgdGhlcmUgYW55DQo+Pj4gdmFsdWUgbGVmdCBpbiB0aGVtPw0KPj4gDQo+PiBBRkFJQ1Qs IGluIG1vc3QgY2FzZXMgcmZjMjQ2MGJpcyBpbmNvcnBvcmF0ZWQgdGhlIGNoYW5nZXMsIGJ1dCBk aWRuJ3QNCj4+IHJlcHJvZHVjZSB0aGUgcmF0aW9uYWxlLiBIZW5jZSwgYXQgbGVhc3QgdGhlICJy YXRpb25hbGUgZm9yIHRoZSBjaGFuZ2VzIg0KPj4gaXMgdGhlIHZhbHVlIGxlZnQgaW4gdGhlbSwg SSdkIHNheS4NCj4gDQo+IEV4YWN0bHkuDQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4g aXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Sun Apr 9 20:03:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C43D127866; Sun, 9 Apr 2017 20:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 OhhhCRWNh3yB; Sun, 9 Apr 2017 20:03:38 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25974129406; Sun, 9 Apr 2017 20:03:37 -0700 (PDT) X-AuditID: c618062d-767ff700000029b8-1e-58eb08149544 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id D7.50.10680.4180BE85; Mon, 10 Apr 2017 06:20:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0339.000; Sun, 9 Apr 2017 23:03:33 -0400 From: Suresh Krishnan To: Alvaro Retana CC: The IESG , "draft-ietf-6man-rfc2460bis@ietf.org" , Ole Troan , "6man WG" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85dIz03aMxFhU+3LFAz8qOczKG+MXcA Date: Mon, 10 Apr 2017 03:03:32 +0000 Message-ID: <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> In-Reply-To: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_205FE8BF-A0C5-49D8-9052-BCFFEDD31A7A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUyuXRPoK4Ex+sIg2nhFrunTGOz+PtzK6NF /+ZYixl/JjJbvDz7nslictsKNgc2jym/N7J6HDz2kdFjyZKfTAHMUVw2Kak5mWWpRfp2CVwZ R9vnshQ8b2WqmNR5n7WBcecjxi5GTg4JAROJVx/a2LsYuTiEBDYwSix8tYEJwlnGKDFp0SU2 kCo2oKoNOz8zgdgiAqoS/8//YgMpYha4ySixumctWJGwQLLEjfV72SCKUiTmLP7CAmEbSRzc /IsdxGYBal747DuYzStgL3Fu5XaweiEBP4mrT6+zgticAv4S1//9AoszCohJfD+1Bmwxs4C4 xK0n85kgzhaReHjxNBuELSrx8vE/VghbSeLj7/nsEMdNYZSY938SM8QyQYmTM5+wTGAUmYVk 1ixkdbOQ1M1i5ABKJEn8myAMUa8tsWzha2YIW1Nif/dyFkxxDYnObxNZIWxTiddHPzJC2NYS M34dZIOwFSWmdD9kX8DIvYqRo7S4ICc33chgEyMwqo9JsOnuYLw/3fMQowAHoxIP74N1ryKE WBPLiitzDzGqALU+2rD6AqMUS15+XqqSCO/aS0Bp3pTEyqrUovz4otKc1OJDjNIcLErivBPO X4gQEkhPLEnNTk0tSC2CyTJxcEo1MKbPfjif+YrY8eynliVM5Xv7Xad+eqaUdoG/xjrxNN8c 16eJZ085zMt3qXwdk71c6Sv3c7aF0cWbJHgCFscKp00ze/EzzyW7qsX1mOOG9cua684xhGjZ xSTeVPlr83RGnN66/5sNdMsyJ7r2HBdza1xte7hD6uZWRSmr47uVL/6bvDbo8Ve2ciWW4oxE Qy3mouJEADY50QHyAgAA Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 03:03:42 -0000 --Apple-Mail=_205FE8BF-A0C5-49D8-9052-BCFFEDD31A7A Content-Type: multipart/alternative; boundary="Apple-Mail=_7BF929D8-C474-46F1-9377-B0D23C6B1D63" --Apple-Mail=_7BF929D8-C474-46F1-9377-B0D23C6B1D63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alvaro, Thanks for your comments. Please find responses inline. > On Apr 7, 2017, at 2:39 PM, Alvaro Retana wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-6man-rfc2460bis-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > First off, this DISCUSS is NOT about questioning the rough consensus > calls that the responsible Chair and AD have made, or wanting to = change > them, but about clarifying to avoid misinterpretations. >=20 > Given the ongoing discussion about Extension Headers and controlled > domains (for example [1] and [2]), the text should be very specific on > what is expected and where. Because it is not, I think that this > document is teetering along the line of having a "high degree of > technical maturity", and not being ready for Internet Standard > [rfc6410]. >=20 > Without further clarifications and guidance, this document also brings = on > unanticipated second order effects [rfc3439] that can impact the > direction, or even the viability, of future work in the IETF.=20 > Specifically, a straight forward interpretation of the text in Section = 4 > is the absolute prohibition to process, insert or delete EHs -- but > discussion on the 6man mailing list seems to point at an understanding > that the conditions inside a controlled domain may be different, for > example (from Brian Carpenter [3]): >=20 > =3D=3D=3D=3D=3D > I've tried to say this before but I'm not sure people are getting it:=20= >=20 > RFC2460bis, if approved as is, draws a line in the sand *for > interoperability across the whole Internet*. There are reasons for = this - > PMTUD in any form, any future replacement for the unsuccessful = IPsec/AH, > and all the problems of deploying extension headers that are = understood > by some nodes and not by others.=20 >=20 > There is no reason why a subsequent standards-track document cannot = allow > header insertion (and removal) within finite domains where the above > issues do not apply. In fact, an improved version of > draft-voyer-6man-extension-header-insertion-00 could become exactly > that. >=20 > =3D=3D=3D=3D=3D >=20 > [N.B.: I'm not implying that Brian's opinion represents consensus, = that > is not my call to make.] I read Brian=E2=80=99s comments and I am in agreement with them, but I = think the message is subtly different from your understanding. This is = how I see it.=20 =3D> If someone comes up with a mechanism to safely do header insertion = and documents how to do it, that document can safely progress. This can = be done in a controlled domain as long as the proponents are willing to = address the concerns that have been brought up and any breakage does not = affect any unmodified nodes outside the controlled domain.=20 Is this the same way you see it or is there a difference? >=20 > I'm pointing at an opinion (which I agree with) that recognizes the = need > to differentiate between contexts -- but the current text in = rfc2460bis > doesn't do that. I believe that this issue is significant (as = reflected > by the ongoing discussions) that that it should be resolved (by > clarifying the text) before proceeding with the publication of this > document as an Internet Standard.=20 >=20 > To summarize, the text in this document has the second order effect of > not leaving a clear path forward for extensions to IPv6 so that they > adhere to the protocol's architecture, specially when applied to a > controlled domain. At a minimum, I would like to see a clear path > forward, whether that is in the form of an update for use of = extensions > in controlled domains, or a statement that this document just applies = to > IPv6 traffic intended to cross the Internet (as suggested at the 6man > meeting in Chicago [4])... My opinion is that this document should = not > be published as an Internet Standard until the remaining open = discussions > are explicitly resolved and this document reflects that resolution. >=20 >=20 > [1] > = https://mailarchive.ietf.org/arch/msg/ipv6/UI0PfqrWco4Hpbvm8keGR8FabRg/?qi= d=3D9a6ba8e9777114e24a1e964336ed78f1 > [2] > = https://mailarchive.ietf.org/arch/msg/ipv6/OrLYxKumiKWLHGkeNamhq9pxutQ/?qi= d=3D63c159fe41c18653d9dc0be609f9e97f > [3] > = https://mailarchive.ietf.org/arch/msg/ipv6/REez0-lbebpo-Xem-xX_sWV0pf4/?qi= d=3D5cdab6c6085795129802ab622bb4159f > [4] https://www.ietf.org/proceedings/98/minutes/minutes-98-6man-00 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Related to the above, I also want to point out the lack of clarity in = the > text in Section 4. (IPv6 Extension Headers), which leaves itself open = to > interpretation and should be cleaned up. >=20 > (A) The main piece of text that has been discussed now reads: >=20 > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field > of > the IPv6 header. Note: If an intermediate forwarding node examines > an extension header for any reason, it must do so in accordance with > the provisions of [RFC7045]. > ... > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by every node along a packet's delivery path, > including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. >=20 >=20 > While the first sentence seems clear on what this document wants > forwarding nodes to do (or not), there are two notes that define > exceptions: any forwarding node can examine the headers "for any = reason", > and, the Hop-by-Hop Options header doesn't really have to be examined = and > processed by everyone. >=20 > This text needs some more work to at least not contradict itself: = there > is more than one exception, and they are not absolute, anyone can = examine > the headers "for any reason=E2=80=9D=E2=80=A6 Right. I think the examine piece could use some rewording to merge with = the RFC7045 exception. >=20 > (B) >=20 > As it stands, the note about the changed expectations for the = Hop-by-Hop > options header opens a significant door to work around the = "limitations" > of other options. For example, it would be relatively straight = forward > to define a new Hop-by-Hop option to carry any type of information = that > could then be "examined, processed, inserted, or deleted by any node > along a packet's delivery path". In the world of controllers and > programmatic access to forwarding nodes, changing the explicit > configuration on the fly to customize which nodes do what, is trivial. >=20 > Is that the intent of this document, to provide a generic mechanism = for > cases that may need extension headers to be "examined, processed, > inserted, or deleted by any node along a packet's delivery path"? = Will > the WG/IETF be in a position to charter, adopt and/or publish these = types > of documents? I ask this question not only in the context of my = concerns > expressed above, but also because the definition of the Hop-by-Hop = Option > would seem to be able to handle anything ("used to carry optional > information that may be examined and processed by every node along a > packet's delivery path" - I didn't see any constraints), even if (for > example) the Routing Header "is used by an IPv6 source to list one or > more intermediate nodes to be "visited" on the way to a packet's > destination" -- so it makes me wonder whether using the Hop-by-Hop > Options header to carry (for example) routing information so that it = can > be "examined, processed, inserted, or deleted by any node along a > packet's delivery path" would pass the bar set in Section 4.8. = (Defining > New Extension Headers and Options): >=20 > New hop-by-hop options are not recommended because nodes may be > configured to ignore the Hop-by-Hop Option header, drop packets > containing a hop-by-hop header, or assign packets containing a hop- > by-hop header to a slow processing path. Designers considering > defining new hop-by-hop options need to be aware of this likely > behaviour. There has to be a very clear justification why any new > hop-by-hop option is needed before it is standardized. >=20 > In the context of a controlled domain, it should be relatively easy = for > the operator to account for those issues. So my interpretation of > whether a Hop-by-Hop option is ok to carry (for example) routing > information is a strong "Yes!". Whether my interpretation is what was > intended or not, I believe the overall text could benefit from more > clarity. My personal opinion is also Yes, as long as the Hop-by-hop option header = is inserted into a packet originated in the controlled domain (such as = the mechanism specified in draft-ietf-6man-segment-routing-header-06 = ). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Appendix B. (Changes Since RFC2460) mentions that the text was revised > based on updates from several other RFCs which Updated rfc2460. I = didn't > check all the details, but if the updates were incorporated in this > document, why are those RFCs not marked as being Obsolete? Is there = any > value left in them? There is a lot of rationale and background that the WG decided not to = fold into this document. Lot of these updates documents have led to a = few sentences with a pointer back to the other documents for more info = and applicability. e.g. RFC6935 allowed UDP checksums to be zero and = RFC6936 explains applicability, issues and design principles to consider = when zero UDP checksums can be used. They resulted in a few sentences = and a pointer for further info. That is why they cannot be obsoleted. Thanks Suresh --Apple-Mail=_7BF929D8-C474-46F1-9377-B0D23C6B1D63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alvaro,
  Thanks for your comments. = Please find responses inline.

On = Apr 7, 2017, at 2:39 PM, Alvaro Retana <aretana@cisco.com> = wrote:

Alvaro Retana has entered the following ballot position = for
draft-ietf-6man-rfc2460bis-09: Discuss
When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

First off, this DISCUSS is NOT = about questioning the rough consensus
calls that the = responsible Chair and AD have made, or wanting to change
them, but about clarifying to avoid misinterpretations.

Given the ongoing discussion about Extension = Headers and controlled
domains (for example [1] and [2]), = the text should be very specific on
what is expected and = where.  Because it is not, I think that this
document = is teetering along the line of having a "high degree of
technical maturity", and not being ready for Internet = Standard
[rfc6410].

Without = further clarifications and guidance, this document also brings on
unanticipated second order effects [rfc3439] that can impact = the
direction, or even the viability, of future work in = the IETF.
Specifically, a straight forward interpretation = of the text in Section 4
is the absolute prohibition to = process, insert or delete EHs -- but
discussion on the = 6man mailing list seems to point at an understanding
that = the conditions inside a controlled domain may be different, for
example (from Brian Carpenter [3]):

=3D=3D=3D=3D=3D
I've tried to say this before = but I'm not sure people are getting it:

RFC2460bis, if approved as is, draws a line in the sand = *for
interoperability across the whole Internet*. There = are reasons for this -
PMTUD in any form, any future = replacement for the unsuccessful IPsec/AH,
and all the = problems of deploying extension headers that are understood
by some nodes and not by others.

There is no reason why a subsequent standards-track document = cannot allow
header insertion (and removal) within finite = domains where the above
issues do not apply. In fact, an = improved version of
draft-voyer-6man-extension-header-insertion-00 could become = exactly
that.

=3D=3D=3D=3D=3D
[N.B.: I'm not implying that Brian's opinion = represents consensus, that
is not my call to make.]

I read = Brian=E2=80=99s comments and I am in agreement with them, but I think = the message is subtly different from your understanding. This is how I = see it. 




I'm pointing = at an opinion (which I agree with) that recognizes the need
to differentiate between contexts -- but the current text in = rfc2460bis
doesn't do that.  I believe that this = issue is significant (as reflected
by the ongoing = discussions) that that it should be resolved (by
clarifying = the text) before proceeding with the publication of this
document as an Internet = Standard. 

To summarize, = the text in this document has the second order effect of
not= leaving a clear path forward for extensions to IPv6 so that they
adhere to the protocol's architecture, specially when applied = to a
controlled domain.  At a minimum, I would like = to see a clear path
forward, whether that is in the form = of an update for use of extensions
in controlled domains, = or a statement that this document just applies to
IPv6 = traffic intended to cross the Internet (as suggested at the 6man
meeting in Chicago [4])...  My opinion is that this = document should not
be published as an Internet Standard = until the remaining open discussions
are explicitly = resolved and this document reflects that = resolution.


[1]
https://mailarchive.ietf.org/arch/msg/ipv6/UI0PfqrWco4Hpbvm8keG= R8FabRg/?qid=3D9a6ba8e9777114e24a1e964336ed78f1
[2]
https://mailarchive.ietf.org/arch/msg/ipv6/OrLYxKumiKWLHGkeNamh= q9pxutQ/?qid=3D63c159fe41c18653d9dc0be609f9e97f
[3]
https://mailarchive.ietf.org/arch/msg/ipv6/REez0-lbebpo-Xem-xX_= sWV0pf4/?qid=3D5cdab6c6085795129802ab622bb4159f
[4] = https://www.ietf.org/proceedings/98/minutes/minutes-98-6man-00



=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Related to the above, I also = want to point out the lack of clarity in the
text in = Section 4. (IPv6 Extension Headers), which leaves itself open to
interpretation and should be cleaned up.

(A)  The main piece of text that has been discussed now = reads:

  With one exception, = extension headers are not examined, processed,
=   inserted, or deleted by any node along a packet's delivery = path,
  until the packet reaches the node (or = each of the set of nodes, in
  the case of = multicast) identified in the Destination Address field
of   the IPv6 header.  Note: If an intermediate = forwarding node examines
  an extension header = for any reason, it must do so in accordance with
=   the provisions of [RFC7045].
=   ...
  The exception referred to in = the preceding paragraph is the Hop-by-
  Hop = Options header, which carries information that may be examined
  and processed by every node along a packet's = delivery path,
including
  the = source and destination nodes.  The Hop-by-Hop Options header,
  when present, must immediately follow the IPv6 = header.  Its presence
  is indicated by = the value zero in the Next Header field of the IPv6
=   header.

  NOTE: = While [RFC2460] required that all nodes must examine and
=   process the Hop-by-Hop Options header, it is now expected = that nodes
  along a packet's delivery path = only examine and process the Hop-by-
  Hop = Options header if explicitly configured to do so.


While the first sentence seems clear on what = this document wants
forwarding nodes to do (or not), there = are two notes that define
exceptions: any forwarding node = can examine the headers "for any reason",
and, the = Hop-by-Hop Options header doesn't really have to be examined and
processed by = everyone.

This text = needs some more work to at least not contradict itself: there
is more than one exception, and they are not absolute, anyone = can examine
the headers "for any = reason=E2=80=9D=E2=80=A6

Right. I think the examine piece could use = some rewording to merge with the RFC7045 exception.


(B)

As it stands, the note about the changed = expectations for the Hop-by-Hop
options header opens a = significant door to work around the "limitations"
of other = options.  For example, it would be relatively straight forward
to define a new Hop-by-Hop option to carry any type of = information that
could then be "examined, processed, = inserted, or deleted by any node
along a packet's delivery = path".  In the world of controllers and
programmatic = access to forwarding nodes, changing the explicit
configuration on the fly to customize which nodes do what, is = trivial.

Is that the intent of this = document, to provide a generic mechanism for
cases that = may need extension headers to be "examined, processed,
inserted, or deleted by any node along a packet's delivery = path"?  Will
the WG/IETF be in a position to charter, = adopt and/or publish these types
of documents?  I ask = this question not only in the context of my concerns
expressed above, but also because the definition of the = Hop-by-Hop Option
would seem to be able to handle anything = ("used to carry optional
information that may be examined = and processed by every node along a
packet's delivery = path" - I didn't see any constraints), even if (for
example)= the Routing Header "is used by an IPv6 source to list one or
more intermediate nodes to be "visited" on the way to a = packet's
destination" -- so it makes me wonder whether = using the Hop-by-Hop
Options header to carry (for example) = routing information so that it can
be "examined, = processed, inserted, or deleted by any node along a
packet's= delivery path" would pass the bar set in Section 4.8. (Defining
New Extension Headers and Options):

  New hop-by-hop options are not recommended = because nodes may be
  configured to ignore the = Hop-by-Hop Option header, drop packets
=   containing a hop-by-hop header, or assign packets containing = a hop-
  by-hop header to a slow processing = path.  Designers considering
  defining = new hop-by-hop options need to be aware of this likely
=   behaviour.  There has to be a very clear justification = why any new
  hop-by-hop option is needed = before it is standardized.

In the context = of a controlled domain, it should be relatively easy for
the= operator to account for those issues.  So my interpretation of
whether a Hop-by-Hop option is ok to carry (for example) = routing
information is a strong "Yes!".  Whether my = interpretation is what was
intended or not, I believe the = overall text could benefit from more
clarity.

My = personal opinion is also Yes, as long as the Hop-by-hop option header is = inserted into a packet originated in the controlled domain (such as the = mechanism specified in draft-ietf-6man-segment-routing-header-06).



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Appendix B. (Changes Since RFC2460) = mentions that the text was revised
based on updates from = several other RFCs which Updated rfc2460.  I didn't
check all the details, but if the updates were incorporated = in this
document, why are those RFCs not marked as being = Obsolete?  Is there any
value left in them?

There = is a lot of rationale and background that the WG decided not to fold = into this document. Lot of these updates documents have led to a few = sentences with a pointer back to the other documents for more info and = applicability. e.g. RFC6935 allowed UDP checksums to be zero and RFC6936 = explains applicability, issues and design principles to consider when = zero UDP checksums can be used. They resulted in a few sentences and a = pointer for further info. That is why they cannot be = obsoleted.

Thanks
Suresh

= --Apple-Mail=_7BF929D8-C474-46F1-9377-B0D23C6B1D63-- --Apple-Mail=_205FE8BF-A0C5-49D8-9052-BCFFEDD31A7A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDEwMDMwMzIzWjAjBgkqhkiG9w0B CQQxFgQU8T4KVUFo5ZSO2I/6LZuR4Z+hY6swXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQA7CMUyt4+SkswpAYlR/HQsycIwuD0P/WMpo51WChcNAQV6sQP5NatiHi9xHtE1 X4G3Rk8RmZ+Z+KsJ7tpfq5zeDFT22hj2K7PN5P7oU3ASQhciHt085bRPX7lQt3cDqppxiIAIAyO+ y84By3ihvWd9Qv8lk9gGRBo7ZiZ1dW0ex5frackwRXCCqhg/uSQgTPoaPcuvjtLx+ypBMZ2++3wV xtj0fF61hlkRf5V4uj0+DEN/g2AvOZ5h1Ywiwlj4E+uyy8I4Pv69tvh+CIuBiaZJBYYVquW7kdve jZWIuhdkho0zo0Kk05ajv6hyaEHoRDcN6kpPxA7bbdi2kHWlGclLAAAAAAAA --Apple-Mail=_205FE8BF-A0C5-49D8-9052-BCFFEDD31A7A-- From nobody Mon Apr 10 01:54:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E513D129435 for ; Mon, 10 Apr 2017 01:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 aTbUmN8wLjOa for ; Mon, 10 Apr 2017 01:54:04 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBC4129417 for ; Mon, 10 Apr 2017 01:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491814442; bh=zdKJ0wx/ZLpxMduZBLJyP+WyNzD38rsd8YmIlcH8z9E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KY9CKHqklB1+yjejp6T8PX4vT4qJ/IFVusuCUc3QUSG0V5DuaF3HtQTKULg35KFfQ9G14sk37rfnWmOR3gExjkC5KRe1fqHop//rvL0w7C1ZIvu4bsAnGj6/jP7sJ8m6GdVSyTHjNrF1jJjckW7iv6AF/8s72xUWfIHSpfIwEYQ= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0246.outbound.protection.outlook.com [213.199.154.246]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-25-QSesPlgnOEyTgKwo01gWrA-1; Mon, 10 Apr 2017 09:52:14 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Mon, 10 Apr 2017 08:52:13 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1034.009; Mon, 10 Apr 2017 08:52:12 +0000 From: Tim Chown To: Suresh Krishnan CC: Alvaro Retana , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85pLrAb8QsmG0aX1HJll0Sq6aG97nUAgABhaoA= Date: Mon, 10 Apr 2017 08:52:12 +0000 Message-ID: <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> In-Reply-To: <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:cc95:815d:f10f:1ea6] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:A5t9Xum0RQoY7D6Y20An0F45gbE+UPr5xIWzpya4z7SxG8aSY3I1klmhGokoGVmIMaTLpwAiY1cUw0TIfMj3K1Cc3OtBZXXPKQvoQ2AEuG21OylS07Nfsz+j1bdbeAZ1tLnDx3KVjDECcFLiyXp/XcH1WE2HsmAc1tCJqfmuMi0JAp03wyKLGCERjQXhvRlCFwpoXmdi8pykkrDAzMQFDRVUohhXy3RcEmxyir/iZTQdBsHzRcktbSrovXLG7rB6nuQEgwdRlQwBZ1zHeZWJsdsGYo6XphlvdBZ+t5QB3PWXIjDsI990U2RMKlebAF8Y2qlOmZDdeBX1s9dRVcXtXg==; 20:iK9Z5Yecf3ddeJ+g2nj9RVr8VZZ6Ge38pV3JLBpfzTVbQDt/yu3tNJuuzEtcS0dAP0/7V9438UQvXN0hiZ6F9Gx46tZ15xvXTOCaZhlY9wybl9JUBtf/N3OniucHcS0PQXQYd38Bh6geFlDNEiCplvIvlH5xaQBtq+2bqap1Nl4= x-ms-office365-filtering-correlation-id: 5479b2d2-237d-4805-e97f-08d47feee14e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(377454003)(24454002)(76176999)(6246003)(74482002)(50986999)(86362001)(110136004)(6116002)(38730400002)(102836003)(2906002)(6506006)(6436002)(2950100002)(53936002)(5250100002)(42882006)(6916009)(8936002)(8676002)(81166006)(50226002)(6512007)(54906002)(4326008)(99286003)(25786009)(53546009)(33656002)(2900100001)(83716003)(82746002)(57306001)(189998001)(230783001)(36756003)(229853002)(3660700001)(6486002)(3280700002)(305945005)(7736002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <68DBBC5C61728E449A799293FBC26989@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2017 08:52:12.4446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: QSesPlgnOEyTgKwo01gWrA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:54:06 -0000 SGksDQoNCj4gT24gMTAgQXByIDIwMTcsIGF0IDA0OjAzLCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVz aC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkgQWx2YXJvLA0KPiAgIFRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgcmVzcG9uc2VzIGlubGluZS4NCj4g DQo+PiBPbiBBcHIgNywgMjAxNywgYXQgMjozOSBQTSwgQWx2YXJvIFJldGFuYSA8YXJldGFuYUBj aXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiA9PT09PT09PT09DQo+PiANCj4+IFJlbGF0ZWQgdG8g dGhlIGFib3ZlLCBJIGFsc28gd2FudCB0byBwb2ludCBvdXQgdGhlIGxhY2sgb2YgY2xhcml0eSBp biB0aGUNCj4+IHRleHQgaW4gU2VjdGlvbiA0LiAoSVB2NiBFeHRlbnNpb24gSGVhZGVycyksIHdo aWNoIGxlYXZlcyBpdHNlbGYgb3BlbiB0bw0KPj4gaW50ZXJwcmV0YXRpb24gYW5kIHNob3VsZCBi ZSBjbGVhbmVkIHVwLg0KPj4gDQo+PiAoQSkgIFRoZSBtYWluIHBpZWNlIG9mIHRleHQgdGhhdCBo YXMgYmVlbiBkaXNjdXNzZWQgbm93IHJlYWRzOg0KPj4gDQo+PiAgIFdpdGggb25lIGV4Y2VwdGlv biwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KPj4gICBp bnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5 IHBhdGgsDQo+PiAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBv ZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KPj4gICB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpIGlkZW50 aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQNCj4+IG9mDQo+PiAgIHRoZSBJ UHY2IGhlYWRlci4gIE5vdGU6IElmIGFuIGludGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhh bWluZXMNCj4+ICAgYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBk byBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCj4+ICAgdGhlIHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVd Lg0KPj4gICAuLi4NCj4+ICAgVGhlIGV4Y2VwdGlvbiByZWZlcnJlZCB0byBpbiB0aGUgcHJlY2Vk aW5nIHBhcmFncmFwaCBpcyB0aGUgSG9wLWJ5LQ0KPj4gICBIb3AgT3B0aW9ucyBoZWFkZXIsIHdo aWNoIGNhcnJpZXMgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgZXhhbWluZWQNCj4+ICAgYW5kIHBy b2Nlc3NlZCBieSBldmVyeSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4+ IGluY2x1ZGluZw0KPj4gICB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBub2Rlcy4gIFRoZSBI b3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLA0KPj4gICB3aGVuIHByZXNlbnQsIG11c3QgaW1tZWRp YXRlbHkgZm9sbG93IHRoZSBJUHY2IGhlYWRlci4gIEl0cyBwcmVzZW5jZQ0KPj4gICBpcyBpbmRp Y2F0ZWQgYnkgdGhlIHZhbHVlIHplcm8gaW4gdGhlIE5leHQgSGVhZGVyIGZpZWxkIG9mIHRoZSBJ UHY2DQo+PiAgIGhlYWRlci4NCj4+IA0KPj4gICBOT1RFOiBXaGlsZSBbUkZDMjQ2MF0gcmVxdWly ZWQgdGhhdCBhbGwgbm9kZXMgbXVzdCBleGFtaW5lIGFuZA0KPj4gICBwcm9jZXNzIHRoZSBIb3At YnktSG9wIE9wdGlvbnMgaGVhZGVyLCBpdCBpcyBub3cgZXhwZWN0ZWQgdGhhdCBub2Rlcw0KPj4g ICBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGggb25seSBleGFtaW5lIGFuZCBwcm9jZXNz IHRoZSBIb3AtYnktDQo+PiAgIEhvcCBPcHRpb25zIGhlYWRlciBpZiBleHBsaWNpdGx5IGNvbmZp Z3VyZWQgdG8gZG8gc28uDQo+PiANCj4+IFdoaWxlIHRoZSBmaXJzdCBzZW50ZW5jZSBzZWVtcyBj bGVhciBvbiB3aGF0IHRoaXMgZG9jdW1lbnQgd2FudHMNCj4+IGZvcndhcmRpbmcgbm9kZXMgdG8g ZG8gKG9yIG5vdCksIHRoZXJlIGFyZSB0d28gbm90ZXMgdGhhdCBkZWZpbmUNCj4+IGV4Y2VwdGlv bnM6IGFueSBmb3J3YXJkaW5nIG5vZGUgY2FuIGV4YW1pbmUgdGhlIGhlYWRlcnMgImZvciBhbnkg cmVhc29uIiwNCj4+IGFuZCwgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIgZG9lc24ndCBy ZWFsbHkgaGF2ZSB0byBiZSBleGFtaW5lZCBhbmQNCj4+IHByb2Nlc3NlZCBieSBldmVyeW9uZS4N Cj4+IA0KPj4gVGhpcyB0ZXh0IG5lZWRzIHNvbWUgbW9yZSB3b3JrIHRvIGF0IGxlYXN0IG5vdCBj b250cmFkaWN0IGl0c2VsZjogdGhlcmUNCj4+IGlzIG1vcmUgdGhhbiBvbmUgZXhjZXB0aW9uLCBh bmQgdGhleSBhcmUgbm90IGFic29sdXRlLCBhbnlvbmUgY2FuIGV4YW1pbmUNCj4+IHRoZSBoZWFk ZXJzICJmb3IgYW55IHJlYXNvbuKAneKApg0KPiANCj4gUmlnaHQuIEkgdGhpbmsgdGhlIGV4YW1p bmUgcGllY2UgY291bGQgdXNlIHNvbWUgcmV3b3JkaW5nIHRvIG1lcmdlIHdpdGggdGhlIFJGQzcw NDUgZXhjZXB0aW9uLg0KDQpPbmUgd2F5IHRvIGltcHJvdmUgdGhlIFJGQzcwNDUg4oCcY29udHJh ZGljdGlvbuKAnSBpbiB0aGUgMjQ2MC1iaXMgdGV4dCB3b3VsZCBiZSB0byByZWFycmFuZ2UgdGhl IHRleHQgdG8gbGlmdCBvdXQgdGhlIFJGQzcwNDUgcmVmZXJlbmNlIHN1Y2ggdGhhdCBpdCBmb2xs b3dzIHRoZSB0ZXh0IGFib3V0IHRoZSBIYkggb3B0aW9uIGhlYWRlciwgYWRkaW5nIGFuIGV4YW1w bGUgb2YgaW5zcGVjdGluZyB0aGUgcGF5bG9hZCwgd2hpY2ggaXMgdGhlIG1haW4gcmF0aW9uYWxl IGZvciBzdWNoIGluc3BlY3Rpb24gc3RhdGVkIGluIFJGQzcwNDUuIA0KDQpPbGQ6DQoNCiAgIFdp dGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJv Y2Vzc2VkLA0KICAgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNr ZXQncyBkZWxpdmVyeSBwYXRoLA0KICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2Rl IChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQogICB0aGUgY2FzZSBvZiBtdWx0aWNh c3QpIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YNCiAgIHRo ZSBJUHY2IGhlYWRlci4gIE5vdGU6IElmIGFuIGludGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUg ZXhhbWluZXMNCiAgIGFuIGV4dGVuc2lvbiBoZWFkZXIgZm9yIGFueSByZWFzb24sIGl0IG11c3Qg ZG8gc28gaW4gYWNjb3JkYW5jZSB3aXRoDQogICB0aGUgcHJvdmlzaW9ucyBvZiBbUkZDNzA0NV0u ICBBdCB0aGUgRGVzdGluYXRpb24gbm9kZSwgbm9ybWFsDQogICBkZW11bHRpcGxleGluZyBvbiB0 aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMNCiAgIHRoZSBt b2R1bGUgdG8gcHJvY2VzcyB0aGUgZmlyc3QgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVwcGVy LWxheWVyDQogICBoZWFkZXIgaWYgbm8gZXh0ZW5zaW9uIGhlYWRlciBpcyBwcmVzZW50LiAgVGhl IGNvbnRlbnRzIGFuZCBzZW1hbnRpY3MNCiAgIG9mIGVhY2ggZXh0ZW5zaW9uIGhlYWRlciBkZXRl cm1pbmUgd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUNCiAgIG5leHQgaGVhZGVyLiAg VGhlcmVmb3JlLCBleHRlbnNpb24gaGVhZGVycyBtdXN0IGJlIHByb2Nlc3NlZCBzdHJpY3RseQ0K ICAgaW4gdGhlIG9yZGVyIHRoZXkgYXBwZWFyIGluIHRoZSBwYWNrZXQ7IGEgcmVjZWl2ZXIgbXVz dCBub3QsIGZvcg0KICAgZXhhbXBsZSwgc2NhbiB0aHJvdWdoIGEgcGFja2V0IGxvb2tpbmcgZm9y IGEgcGFydGljdWxhciBraW5kIG9mDQogICBleHRlbnNpb24gaGVhZGVyIGFuZCBwcm9jZXNzIHRo YXQgaGVhZGVyIHByaW9yIHRvIHByb2Nlc3NpbmcgYWxsDQogICBwcmVjZWRpbmcgb25lcy4NCg0K ICAgVGhlIGV4Y2VwdGlvbiByZWZlcnJlZCB0byBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFwaCBp cyB0aGUgSG9wLWJ5LQ0KICAgSG9wIE9wdGlvbnMgaGVhZGVyLCB3aGljaCBjYXJyaWVzIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1pbmVkDQogICBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5v ZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCBpbmNsdWRpbmcNCiAgIHRoZSBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uIG5vZGVzLiAgVGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIs DQogICB3aGVuIHByZXNlbnQsIG11c3QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBJUHY2IGhlYWRl ci4gIEl0cyBwcmVzZW5jZQ0KICAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSB6ZXJvIGluIHRo ZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KICAgaGVhZGVyLg0KDQogICBOT1RFOiBX aGlsZSBbUkZDMjQ2MF0gcmVxdWlyZWQgdGhhdCBhbGwgbm9kZXMgbXVzdCBleGFtaW5lIGFuZA0K ICAgcHJvY2VzcyB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwgaXQgaXMgbm93IGV4cGVj dGVkIHRoYXQgbm9kZXMNCiAgIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4 YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCiAgIEhvcCBPcHRpb25zIGhlYWRlciBpZiBl eHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8gc28uDQoNCk5ldzoNCg0KICAgV2l0aCBvbmUgZXhj ZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQog ICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2 ZXJ5IHBhdGgsDQogICB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2gg b2YgdGhlIHNldCBvZiBub2RlcywgaW4NCiAgIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRp ZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KICAgdGhlIElQdjYgaGVh ZGVyLiAgQXQgdGhlIERlc3RpbmF0aW9uIG5vZGUsIG5vcm1hbA0KICAgZGVtdWx0aXBsZXhpbmcg b24gdGhlIE5leHQgSGVhZGVyIGZpZWxkIG9mIHRoZSBJUHY2IGhlYWRlciBpbnZva2VzDQogICB0 aGUgbW9kdWxlIHRvIHByb2Nlc3MgdGhlIGZpcnN0IGV4dGVuc2lvbiBoZWFkZXIsIG9yIHRoZSB1 cHBlci1sYXllcg0KICAgaGVhZGVyIGlmIG5vIGV4dGVuc2lvbiBoZWFkZXIgaXMgcHJlc2VudC4g IFRoZSBjb250ZW50cyBhbmQgc2VtYW50aWNzDQogICBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXIg ZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgdG8gdGhlDQogICBuZXh0IGhlYWRl ci4gIFRoZXJlZm9yZSwgZXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQgc3RyaWN0 bHkNCiAgIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUgcGFja2V0OyBhIHJlY2VpdmVy IG11c3Qgbm90LCBmb3INCiAgIGV4YW1wbGUsIHNjYW4gdGhyb3VnaCBhIHBhY2tldCBsb29raW5n IGZvciBhIHBhcnRpY3VsYXIga2luZCBvZg0KICAgZXh0ZW5zaW9uIGhlYWRlciBhbmQgcHJvY2Vz cyB0aGF0IGhlYWRlciBwcmlvciB0byBwcm9jZXNzaW5nIGFsbA0KICAgcHJlY2VkaW5nIG9uZXMu DQoNCiAgIFRoZSBleGNlcHRpb24gcmVmZXJyZWQgdG8gaW4gdGhlIHByZWNlZGluZyBwYXJhZ3Jh cGggaXMgdGhlIEhvcC1ieS0NCiAgIEhvcCBPcHRpb25zIGhlYWRlciwgd2hpY2ggY2FycmllcyBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBleGFtaW5lZA0KICAgYW5kIHByb2Nlc3NlZCBieSBldmVy eSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgaW5jbHVkaW5nDQogICB0aGUg c291cmNlIGFuZCBkZXN0aW5hdGlvbiBub2Rlcy4gIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVh ZGVyLA0KICAgd2hlbiBwcmVzZW50LCBtdXN0IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBo ZWFkZXIuICBJdHMgcHJlc2VuY2UNCiAgIGlzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgemVybyBp biB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYNCiAgIGhlYWRlci4NCg0KICAgTk9U RTogV2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgZXhhbWluZSBh bmQNCiAgIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBl eHBlY3RlZCB0aGF0IG5vZGVzDQogICBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGggb25s eSBleGFtaW5lIGFuZCBwcm9jZXNzIHRoZSBIb3AtYnktDQogICBIb3AgT3B0aW9ucyBoZWFkZXIg aWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KICAgDQogICBOT1RFOiBJZiBhbnkg b3RoZXIgaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgZGV2aWNlIG5lZWRzIHRvIGV4YW1pbmUNCiAg IGFuIGV4dGVuc2lvbiBoZWFkZXIgZm9yIGFueSByZWFzb24sIGUuZy4sIHRvIHRyYXZlcnNlIHRo ZSBleHRlbnNpb24NCiAgIGhlYWRlciBjaGFpbiB0byBpbnNwZWN0IHRoZSB0cmFuc3BvcnQgaGVh ZGVyIG9mIGEgcGFja2V0LCBpdCBtdXN0IGRvIHNvIGluIA0KICAgYWNjb3JkYW5jZSB3aXRoIHRo ZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4gDQoNClRoZSBxdWVzdGlvbiB0aGVuIHdvdWxkIGJl IHRoZSBzcGVjaWZpYyB3b3JkaW5nIG9mIHRoYXQgbGFzdCBwYXJhZ3JhcGguDQoNClRpbQ== From nobody Mon Apr 10 06:39:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ADC1294E4; Mon, 10 Apr 2017 06:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AP4236pg8oPp; Mon, 10 Apr 2017 06:39:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDF912948E; Mon, 10 Apr 2017 06:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5966; q=dns/txt; s=iport; t=1491831541; x=1493041141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Nx1T3ZZUR78IHlDWv6GPJLq1eNIZNi/+Mu62NC6cWE0=; b=J4pN/6eRi4ENQtzmFltD6HYUMbjuSdZuNafWUEo+wtTPnv2cb2EybLtG 3Gn9uFPJFIWiuUZk5pgfWt5c9xC2lAOHFhQXlZuBO4uP+LP3XizSUfwRX +8mz6TpFlx0CCQNLvYR5o8E9CIZUt3vumse6FEzBacTX0DLtTpkeiJJ4u 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQBRiutY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeDX4oTkUaIGo09gg+GJAIag0I/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjEUUFCwIBBgIYAgImAgICHxEVEAIEAQ0FFAKJYQMNCIsnnV2CJoFHh?= =?us-ascii?q?WINgy0BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFRYIFgmuCUYFVMBeCby6CMQE?= =?us-ascii?q?EliCGIDsBiiqDcYQ9CoF1hS6KFIsAiH8BHziBBVsVUgGEfoFKdQGHIYEwgQ0BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="220721885" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 13:39:00 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3ADd0aw019743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 13:39:00 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 08:38:59 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 08:38:59 -0500 From: "Alvaro Retana (aretana)" To: Brian E Carpenter , Fernando Gont , The IESG , Suresh Krishnan CC: "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85dTThx1SRXYEO6jo/FFmbU1aG636uAgADn2wCAAXDMAIAARluAgAEyFgA= Date: Mon, 10 Apr 2017 13:38:59 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> <7ff7970f-98bb-a939-5253-33aed259e772@si6networks.com> <49f097ef-5401-d380-3823-d88f518b5c4b@gmail.com> In-Reply-To: <49f097ef-5401-d380-3823-d88f518b5c4b@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:39:03 -0000 T24gNC85LzE3LCAxMToyMyBBTSwgIkJyaWFuIEUgQ2FycGVudGVyIiA8YnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPiB3cm90ZToNCg0KQnJpYW4vRmVybmFuZG86DQoNCkhpIQ0KDQpBcyBJIHRy aWVkIHNheWluZyBiZWZvcmUsIG15IERJU0NVU1MgaXMgbm90IGFib3V0IGhhdmluZyB0aGlzIGRv Y3VtZW50IGFsbG93IEVIIGluc2VydGlvbi4NCg0KSSBqdXN0IHdhbnQgdGhlIHRleHQgdG8gYmUg Y2xlYXIuICBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1cyBvbiB0aGUgY3VycmVudCB0 ZXh0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaXQgaXMgY2xlYXIuICBUaGUgb25lIHRoaW5nIHRoYXQg aXMgY2xlYXIgdG8gbWUgaXMgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBvZiBpbnRlcnBy ZXRpbmcgdGhlIGN1cnJlbnQgdGV4dCDigJMgYW5kIGV2ZW4gd2hhdCBwZW9wbGUgc2F5IGFib3V0 IGl0Lg0KDQo+IE9uIDA5LzA0LzIwMTcgMjM6MTEsIEZlcm5hbmRvIEdvbnQgd3JvdGU6DQo+ID4N Cj4gPiogSU1PLCBJRVRGIGNhbiBiZSBhc3N1bWVkIHRvIHN0YW5kYXJkaXplICpJKiBwcm90b2Nv bHMgd2hpY2gsIHVubGVzcw0KPiA+b3RoZXJ3aXNlIHNwZWNpZmllZCwgYXJlIGV4cGVjdGVkIHRv IG9wZXJhdGUgb3ZlciB0aGUgSW50ZXJuZXQuIFRoZXJlJ3MNCj4gPm5vIG5lZWQgdG8gc2F5L2Ns YXJpZnkgdGhhdC4NCj4NCj4gV2VsbCwgSSBsb29rZWQgZm9yIHRoYXQgaW4gdGhlIHJ1bGVzIGZv ciBJbnRlcm5ldCBTdGFuZGFyZCAoUkZDIDY0MTApDQo+IGFuZCBkaWRuJ3QgZmluZCBpdC4gVGhh dCdzIHdoeSBJIHN1Z2dlc3RlZCBhZGRpbmcgaXQgdG8gMjQ2MGJpcyAtDQo+IGV4YWN0bHkgYmVj YXVzZSB0aGUgSW50ZXJuZXQgUHJvdG9jb2wgaXMgKmFib3ZlIGFsbCogdGhlIHN0YW5kYXJkIHRo YXQNCj4gaXMgZXhwZWN0ZWQgdG8gb3BlcmF0ZSBvdmVyIHRoZSBJbnRlcm5ldC4NCj4NCj4gQnV0 IGlmIHlvdSBhcmUgY29ycmVjdCwgQWx2YXJvJ3MgRElTQ1VTUyBpcyBzaW1wbHkgd3Jvbmc6IHRo ZSBzY29wZSBpcw0KPiBieSBkZWZpbml0aW9uIHRoZSBJbnRlcm5ldCwgc28gYnkgZGVmaW5pdGlv biBsb2NhbGx5IGluc2VydGVkIG9yIGRlbGV0ZWQNCj4gZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG91 dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4gTXkgZXh0cmEgd29yZHMgYXJlDQo+IG9ubHkg aW50ZW5kZWQgdG8gY29uZmlybSB0aGF0IGxvZ2ljLiBJZiB3ZSBkb24ndCBuZWVkIHRoZW0sIHNv IG11Y2gNCj4gdGhlIGJldHRlci4NCg0KV2UgYWxsIGtub3cgdGhhdCB0aGUgbWlzc2lvbiBvZiB0 aGUgSUVURiBpcyB0byDigJxtYWtlIHRoZSBJbnRlcm5ldCB3b3JrIGJldHRlcuKAnSBbcmZjMzkz NV0g4oCTIGhlcmUgaXMgd2hhdCBJIHRoaW5rIGlzIHRoZSByZWxldmFudCBkZWZpbml0aW9uIGlu IHRoaXMgY2FzZSAoZnJvbSBTZWN0aW9uIDIuIChEZWZpbml0aW9uIG9mIFRlcm1zKSk6DQogICBU aGUgSW50ZXJuZXQ6IEEgbGFyZ2UsIGhldGVyb2dlbmVvdXMgY29sbGVjdGlvbiBvZiBpbnRlcmNv bm5lY3RlZA0KICAgICAgc3lzdGVtcyB0aGF0IGNhbiBiZSB1c2VkIGZvciBjb21tdW5pY2F0aW9u IG9mIG1hbnkgZGlmZmVyZW50IHR5cGVzDQogICAgICBiZXR3ZWVuIGFueSBpbnRlcmVzdGVkIHBh cnRpZXMgY29ubmVjdGVkIHRvIGl0LiAgVGhlIHRlcm0gaW5jbHVkZXMNCiAgICAgIGJvdGggdGhl ICJjb3JlIEludGVybmV0IiAoSVNQIG5ldHdvcmtzKSBhbmQgImVkZ2UgSW50ZXJuZXQiDQogICAg ICAoY29ycG9yYXRlIGFuZCBwcml2YXRlIG5ldHdvcmtzLCBvZnRlbiBjb25uZWN0ZWQgdmlhIGZp cmV3YWxscywNCiAgICAgIE5BVCBib3hlcywgYXBwbGljYXRpb24gbGF5ZXIgZ2F0ZXdheXMgYW5k IHNpbWlsYXIgZGV2aWNlcykuICBUaGUNCiAgICAgIEludGVybmV0IGlzIGEgdHJ1bHkgZ2xvYmFs IG5ldHdvcmssIHJlYWNoaW5nIGludG8ganVzdCBhYm91dCBldmVyeQ0KICAgICAgY291bnRyeSBp biB0aGUgd29ybGQuDQogICAgICBUaGUgSUVURiBjb21tdW5pdHkgd2FudHMgdGhlIEludGVybmV0 IHRvIHN1Y2NlZWQgYmVjYXVzZSB3ZQ0KICAgICAgYmVsaWV2ZSB0aGF0IHRoZSBleGlzdGVuY2Ug b2YgdGhlIEludGVybmV0LCBhbmQgaXRzIGluZmx1ZW5jZSBvbg0KICAgICAgZWNvbm9taWNzLCBj b21tdW5pY2F0aW9uLCBhbmQgZWR1Y2F0aW9uLCB3aWxsIGhlbHAgdXMgdG8gYnVpbGQgYQ0KICAg ICAgYmV0dGVyIGh1bWFuIHNvY2lldHkuDQoNCg0KU3RhcnRpbmcgZnJvbSB0aGF0IGRlZmluaXRp b24sIGFuZCBwbGVhc2UgY29ycmVjdCBtZSBpZiBteSBpbnRlcnByZXRhdGlvbiBpcyB3cm9uZywg 4oCcZXhwZWN0ZWQgdG8gb3BlcmF0ZSBvdmVyIHRoZSBJbnRlcm5ldOKAnSAoZnJvbSBGZXJuYW5k byBhYm92ZSkgcmVhbGx5IHBvaW50cyB0byB0aGUg4oCcY29yZSBJbnRlcm5ldOKAnSwgcmlnaHQ/ Pw0KDQpZZXMsIGl0IGlzIHVuZGVyc3Rvb2QgdGhhdCB0aGUgSUVURiB3b3JrcyBvbiBwcm90b2Nv bHMgZm9yIOKAnHRoZSBJbnRlcm5ldOKAnSwgYnV0IOKAnHRoZSBJbnRlcm5ldOKAnSByZWFsbHkg aGFzIHR3byBwYXJ0cywgb25lIG9mIHRoZW0gaW5jbHVkZXMgKGFtb25nIG90aGVyIHRoaW5ncykg d2hhdCBJ4oCZdmUgYmVlbiBjYWxsaW5nIGEgY29udHJvbGxlZCBkb21haW4gKGFrYSBwcml2YXRl IG5ldHdvcmspLg0KDQpJ4oCZbSB0aGVuIGxvb2tpbmcgZm9yIGEgY2xhcmlmaWNhdGlvbiBvbiB0 aGUgYXBwbGljYWJpbGl0eSBvZiByZmMyNDYwYmlzIOKAkyBzb21ldGhpbmcgbGlrZSAodG8gcGFy YXBocmFzZSBCcmlhbik6IHRoaXMgZG9jdW1lbnQgYXBwbGllcyB0byBwYWNrZXRzIGludGVuZGVk IHRvIHRyYXZlcnNlIHRoZSDigJxjb3JlIEludGVybmV04oCdLg0KDQpJIGFtIG5vdCBsb29raW5n IGZvciBhIGJsYW5rZXQgc3RhdGVtZW50IGFib3V0IGluc2VydGlvbi9kZWxldGlvbiBvZiBFSHMu ICBRdW90aW5nIFN1cmVzaCBmcm9tIHRoaXMgdGhyZWFkOg0KDQpPbiA0LzkvMTcsIDExOjAzIFBN LCAiU3VyZXNoIEtyaXNobmFuIiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQoNCj4gPT4gSWYgc29tZW9uZSBjb21lcyB1cCB3aXRoIGEgbWVjaGFuaXNtIHRvIHNhZmVseSBk byBoZWFkZXIgaW5zZXJ0aW9uIGFuZCANCj4gZG9jdW1lbnRzIGhvdyB0byBkbyBpdCwgdGhhdCBk b2N1bWVudCBjYW4gc2FmZWx5IHByb2dyZXNzLiBUaGlzIGNhbiBiZSBkb25lIGluIGEgDQo+IGNv bnRyb2xsZWQgZG9tYWluIGFzIGxvbmcgYXMgdGhlIHByb3BvbmVudHMgYXJlIHdpbGxpbmcgdG8g YWRkcmVzcyB0aGUgY29uY2VybnMgDQo+IHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgYW5kIGFu eSBicmVha2FnZSBkb2VzIG5vdCBhZmZlY3QgYW55IHVubW9kaWZpZWQgbm9kZXMgDQo+IG91dHNp ZGUgdGhlIGNvbnRyb2xsZWQgZG9tYWluLiANCg0KRm9yIGNsYXJpdHksIEkgd291bGQgYWRkIHRo YXQg4oCcc2FmZWx5IHByb2dyZXNz4oCdIHJlYWxseSBtZWFucyB0aGF0IDZtYW4gY2FuIGNvbnNp ZGVyIGl0LCBhbmQgaWYgYWRvcHRlZCBhbmQgY29uc2Vuc3VzIGlzIHJlYWNoZWQsIHRoZW4gaXQg Y291bGQgYmUgcHVibGlzaGVkLiAgSSBhZ3JlZSB3aXRoIHRoYXQuDQoNCg0KQmFjayB0byB0aGUg b3JpZ2luYWwgdGV4dCBvZiBteSBESVNDVVNTLiAgQnkgc2F5aW5nIHRoYXQg4oCcV2l0aG91dCBm dXJ0aGVyIGNsYXJpZmljYXRpb25zIGFuZCBndWlkYW5jZSwgdGhpcyBkb2N1bWVudCBhbHNvIGJy aW5ncyBvbiB1bmFudGljaXBhdGVkIHNlY29uZCBvcmRlciBlZmZlY3RzIFtyZmMzNDM5XSB0aGF0 IGNhbiBpbXBhY3QgdGhlIGRpcmVjdGlvbiwgb3IgZXZlbiB0aGUgdmlhYmlsaXR5LCBvZiBmdXR1 cmUgd29yayBpbiB0aGUgSUVURi7igJ0g4oCmIEkgbWVhbnQgdGhhdCAod2l0aG91dCBjbGFyaWZ5 aW5nKSwgaXQgaXMgdmVyeSBlYXN5IHRvIGFzc3VtZSB0aGF0IHRoZXJlIGFyZSBubyBleGNlcHRp b25zIHRvIHdoYXQgaXMgc3BlY2lmaWVkIGluIHJmYzI1NjBiaXMuICAgV2hpbGUgaXQgbWF5IGJl IHRoYXQgZXZlcnlvbmUgaXMgaW4gd2lsZCBhZ3JlZW1lbnQgYWJvdXQgdGhlIGFwcGxpY2FiaWxp dHkgKHRvIHRoZSDigJxjb3JlIEludGVybmV04oCdKSBhbmQgd2hldGhlciBvdGhlcnMgaW4gdGhl IGZ1dHVyZSBjYW4g4oCcc2FmZWx5IHByb2dyZXNz4oCdIGEgZGlmZmVyZW50IHByb3Bvc2FsLCBJ IHdhbnQgaXQgZG9jdW1lbnRlZCBzbyB3ZSBkb27igJl0IGhhdmUgdG8gY2hhc2UgZG93biBvbGQg dGhyZWFkcyBhbmQgYXJndWUgYWJvdXQgdGhlIGludGVudGlvbiBvZiBhIGRvY3VtZW504oCmICAN Cg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg== From nobody Mon Apr 10 06:46:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06841294F6; Mon, 10 Apr 2017 06:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KlsU4d179Jor; Mon, 10 Apr 2017 06:45:49 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24DA1294EC; Mon, 10 Apr 2017 06:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16056; q=dns/txt; s=iport; t=1491831948; x=1493041548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oF8JpctwVHE9y8mP+mgYljMf0KlqGoY95H/ligqWuEk=; b=LZzu+BxU6N/G5JsH0AeH0MGCMWtNq2nqNrH2lCgsU+yvvqOSR65jnbWi yErzMjzBYY77Bt4Tce7xRmrT2utXcxAz6RStjLKG9sozdhkJ1TjvzVL0S CjJca+6dUr1Ue0TiQzlsvf731+Z0ElbaVQjfKnHG5eMTQlO0yNw4SGdki U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgAljOtY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB4NfihORJx+VV4IPIQ+FdAIag0I/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBASERMwcLBQsCAQYCEgYCAhEVAgICJQsVAg4CBA4FigcIDosjn?= =?us-ascii?q?V2CJopjAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VFggUJgmKDF4EQAREBMyi?= =?us-ascii?q?CRy6CMQWJJZNWAYZ/gyuILoF/hS6DWoY6iGOLHAEfOH0IWxVBEQGESRwZgUp1A?= =?us-ascii?q?QSHLIEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="408338330" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 13:45:47 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3ADjkJB019016 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 13:45:47 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 09:45:46 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 09:45:46 -0400 From: "Stefano Previdi (sprevidi)" To: Suresh Krishnan CC: "Alvaro Retana (aretana)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSsgDBZSSTo0QNXE6hNhLZaMYdxA== Date: Mon, 10 Apr 2017 13:45:46 +0000 Message-ID: <48ACB89A-430E-4142-A2C1-F2C4043E5B1A@cisco.com> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> In-Reply-To: <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.162.103] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:45:51 -0000 SGkgU3VyZXNoLA0KDQoNCj4gT24gQXByIDEwLCAyMDE3LCBhdCA1OjAzIEFNLCBTdXJlc2ggS3Jp c2huYW4gPHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkgQWx2 YXJvLA0KPiAgIFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgcmVzcG9uc2Vz IGlubGluZS4NCj4gDQo+PiBPbiBBcHIgNywgMjAxNywgYXQgMjozOSBQTSwgQWx2YXJvIFJldGFu YSA8YXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBBbHZhcm8gUmV0YW5hIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4gZHJhZnQtaWV0Zi02 bWFuLXJmYzI0NjBiaXMtMDk6IERpc2N1c3MNCj4+IA0KPj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+PiBlbWFp bCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0 byBjdXQgdGhpcw0KPj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+PiANCj4+ IA0KPj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4+IA0KPj4gDQo+PiBUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4tcmZj MjQ2MGJpcy8NCj4+IA0KPj4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IERJU0NVU1M6DQo+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IEZpcnN0IG9mZiwgdGhpcyBESVNDVVNTIGlzIE5PVCBh Ym91dCBxdWVzdGlvbmluZyB0aGUgcm91Z2ggY29uc2Vuc3VzDQo+PiBjYWxscyB0aGF0IHRoZSBy ZXNwb25zaWJsZSBDaGFpciBhbmQgQUQgaGF2ZSBtYWRlLCBvciB3YW50aW5nIHRvIGNoYW5nZQ0K Pj4gdGhlbSwgYnV0IGFib3V0IGNsYXJpZnlpbmcgdG8gYXZvaWQgbWlzaW50ZXJwcmV0YXRpb25z Lg0KPj4gDQo+PiBHaXZlbiB0aGUgb25nb2luZyBkaXNjdXNzaW9uIGFib3V0IEV4dGVuc2lvbiBI ZWFkZXJzIGFuZCBjb250cm9sbGVkDQo+PiBkb21haW5zIChmb3IgZXhhbXBsZSBbMV0gYW5kIFsy XSksIHRoZSB0ZXh0IHNob3VsZCBiZSB2ZXJ5IHNwZWNpZmljIG9uDQo+PiB3aGF0IGlzIGV4cGVj dGVkIGFuZCB3aGVyZS4gIEJlY2F1c2UgaXQgaXMgbm90LCBJIHRoaW5rIHRoYXQgdGhpcw0KPj4g ZG9jdW1lbnQgaXMgdGVldGVyaW5nIGFsb25nIHRoZSBsaW5lIG9mIGhhdmluZyBhICJoaWdoIGRl Z3JlZSBvZg0KPj4gdGVjaG5pY2FsIG1hdHVyaXR5IiwgYW5kIG5vdCBiZWluZyByZWFkeSBmb3Ig SW50ZXJuZXQgU3RhbmRhcmQNCj4+IFtyZmM2NDEwXS4NCj4+IA0KPj4gV2l0aG91dCBmdXJ0aGVy IGNsYXJpZmljYXRpb25zIGFuZCBndWlkYW5jZSwgdGhpcyBkb2N1bWVudCBhbHNvIGJyaW5ncyBv bg0KPj4gdW5hbnRpY2lwYXRlZCBzZWNvbmQgb3JkZXIgZWZmZWN0cyBbcmZjMzQzOV0gdGhhdCBj YW4gaW1wYWN0IHRoZQ0KPj4gZGlyZWN0aW9uLCBvciBldmVuIHRoZSB2aWFiaWxpdHksIG9mIGZ1 dHVyZSB3b3JrIGluIHRoZSBJRVRGLiANCj4+IFNwZWNpZmljYWxseSwgYSBzdHJhaWdodCBmb3J3 YXJkIGludGVycHJldGF0aW9uIG9mIHRoZSB0ZXh0IGluIFNlY3Rpb24gNA0KPj4gaXMgdGhlIGFi c29sdXRlIHByb2hpYml0aW9uIHRvIHByb2Nlc3MsIGluc2VydCBvciBkZWxldGUgRUhzIC0tIGJ1 dA0KPj4gZGlzY3Vzc2lvbiBvbiB0aGUgNm1hbiBtYWlsaW5nIGxpc3Qgc2VlbXMgdG8gcG9pbnQg YXQgYW4gdW5kZXJzdGFuZGluZw0KPj4gdGhhdCB0aGUgY29uZGl0aW9ucyBpbnNpZGUgYSBjb250 cm9sbGVkIGRvbWFpbiBtYXkgYmUgZGlmZmVyZW50LCBmb3INCj4+IGV4YW1wbGUgKGZyb20gQnJp YW4gQ2FycGVudGVyIFszXSk6DQo+PiANCj4+ID09PT09DQo+PiBJJ3ZlIHRyaWVkIHRvIHNheSB0 aGlzIGJlZm9yZSBidXQgSSdtIG5vdCBzdXJlIHBlb3BsZSBhcmUgZ2V0dGluZyBpdDogDQo+PiAN Cj4+IFJGQzI0NjBiaXMsIGlmIGFwcHJvdmVkIGFzIGlzLCBkcmF3cyBhIGxpbmUgaW4gdGhlIHNh bmQgKmZvcg0KPj4gaW50ZXJvcGVyYWJpbGl0eSBhY3Jvc3MgdGhlIHdob2xlIEludGVybmV0Ki4g VGhlcmUgYXJlIHJlYXNvbnMgZm9yIHRoaXMgLQ0KPj4gUE1UVUQgaW4gYW55IGZvcm0sIGFueSBm dXR1cmUgcmVwbGFjZW1lbnQgZm9yIHRoZSB1bnN1Y2Nlc3NmdWwgSVBzZWMvQUgsDQo+PiBhbmQg YWxsIHRoZSBwcm9ibGVtcyBvZiBkZXBsb3lpbmcgZXh0ZW5zaW9uIGhlYWRlcnMgdGhhdCBhcmUg dW5kZXJzdG9vZA0KPj4gYnkgc29tZSBub2RlcyBhbmQgbm90IGJ5IG90aGVycy4gDQo+PiANCj4+ IFRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgYSBzdWJzZXF1ZW50IHN0YW5kYXJkcy10cmFjayBkb2N1 bWVudCBjYW5ub3QgYWxsb3cNCj4+IGhlYWRlciBpbnNlcnRpb24gKGFuZCByZW1vdmFsKSB3aXRo aW4gZmluaXRlIGRvbWFpbnMgd2hlcmUgdGhlIGFib3ZlDQo+PiBpc3N1ZXMgZG8gbm90IGFwcGx5 LiBJbiBmYWN0LCBhbiBpbXByb3ZlZCB2ZXJzaW9uIG9mDQo+PiBkcmFmdC12b3llci02bWFuLWV4 dGVuc2lvbi1oZWFkZXItaW5zZXJ0aW9uLTAwIGNvdWxkIGJlY29tZSBleGFjdGx5DQo+PiB0aGF0 Lg0KPj4gDQo+PiA9PT09PQ0KPj4gDQo+PiBbTi5CLjogSSdtIG5vdCBpbXBseWluZyB0aGF0IEJy aWFuJ3Mgb3BpbmlvbiByZXByZXNlbnRzIGNvbnNlbnN1cywgdGhhdA0KPj4gaXMgbm90IG15IGNh bGwgdG8gbWFrZS5dDQo+IA0KPiBJIHJlYWQgQnJpYW7igJlzIGNvbW1lbnRzIGFuZCBJIGFtIGlu IGFncmVlbWVudCB3aXRoIHRoZW0sIGJ1dCBJIHRoaW5rIHRoZSBtZXNzYWdlIGlzIHN1YnRseSBk aWZmZXJlbnQgZnJvbSB5b3VyIHVuZGVyc3RhbmRpbmcuIFRoaXMgaXMgaG93IEkgc2VlIGl0LiAN Cj4gDQo+ID0+IElmIHNvbWVvbmUgY29tZXMgdXAgd2l0aCBhIG1lY2hhbmlzbSB0byBzYWZlbHkg ZG8gaGVhZGVyIGluc2VydGlvbiBhbmQgZG9jdW1lbnRzIGhvdyB0byBkbyBpdCwgdGhhdCBkb2N1 bWVudCBjYW4gc2FmZWx5IHByb2dyZXNzLiBUaGlzIGNhbiBiZSBkb25lIGluIGEgY29udHJvbGxl ZCBkb21haW4gYXMgbG9uZyBhcyB0aGUgcHJvcG9uZW50cyBhcmUgd2lsbGluZyB0byBhZGRyZXNz IHRoZSBjb25jZXJucyB0aGF0IGhhdmUgYmVlbiBicm91Z2h0IHVwIGFuZCBhbnkgYnJlYWthZ2Ug ZG9lcyBub3QgYWZmZWN0IGFueSB1bm1vZGlmaWVkIG5vZGVzIG91dHNpZGUgdGhlIGNvbnRyb2xs ZWQgZG9tYWluLiANCg0KDQppZiB5b3UgY2FuIHJlZmxlY3QgdGhlIGFib3ZlIGluIHRoZSBjdXJy ZW50IHRleHQgb2YgcmZjMjQ2MGJpcywgdGhlbiBJIHRoaW5rIGl0IHdvdWxkIHJlYWxseSBoZWxw IGZpbmRpbmcgdGhlIGNvbnNlbnN1cyB3ZSBkb27igJl0IGhhdmUgdG9kYXkuDQoNCnMuDQoNCg0K PiANCj4gSXMgdGhpcyB0aGUgc2FtZSB3YXkgeW91IHNlZSBpdCBvciBpcyB0aGVyZSBhIGRpZmZl cmVuY2U/DQo+IA0KPj4gDQo+PiBJJ20gcG9pbnRpbmcgYXQgYW4gb3BpbmlvbiAod2hpY2ggSSBh Z3JlZSB3aXRoKSB0aGF0IHJlY29nbml6ZXMgdGhlIG5lZWQNCj4+IHRvIGRpZmZlcmVudGlhdGUg YmV0d2VlbiBjb250ZXh0cyAtLSBidXQgdGhlIGN1cnJlbnQgdGV4dCBpbiByZmMyNDYwYmlzDQo+ PiBkb2Vzbid0IGRvIHRoYXQuICBJIGJlbGlldmUgdGhhdCB0aGlzIGlzc3VlIGlzIHNpZ25pZmlj YW50IChhcyByZWZsZWN0ZWQNCj4+IGJ5IHRoZSBvbmdvaW5nIGRpc2N1c3Npb25zKSB0aGF0IHRo YXQgaXQgc2hvdWxkIGJlIHJlc29sdmVkIChieQ0KPj4gY2xhcmlmeWluZyB0aGUgdGV4dCkgYmVm b3JlIHByb2NlZWRpbmcgd2l0aCB0aGUgcHVibGljYXRpb24gb2YgdGhpcw0KPj4gZG9jdW1lbnQg YXMgYW4gSW50ZXJuZXQgU3RhbmRhcmQuIA0KPj4gDQo+PiBUbyBzdW1tYXJpemUsIHRoZSB0ZXh0 IGluIHRoaXMgZG9jdW1lbnQgaGFzIHRoZSBzZWNvbmQgb3JkZXIgZWZmZWN0IG9mDQo+PiBub3Qg bGVhdmluZyBhIGNsZWFyIHBhdGggZm9yd2FyZCBmb3IgZXh0ZW5zaW9ucyB0byBJUHY2IHNvIHRo YXQgdGhleQ0KPj4gYWRoZXJlIHRvIHRoZSBwcm90b2NvbCdzIGFyY2hpdGVjdHVyZSwgc3BlY2lh bGx5IHdoZW4gYXBwbGllZCB0byBhDQo+PiBjb250cm9sbGVkIGRvbWFpbi4gIEF0IGEgbWluaW11 bSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIHBhdGgNCj4+IGZvcndhcmQsIHdoZXRoZXIg dGhhdCBpcyBpbiB0aGUgZm9ybSBvZiBhbiB1cGRhdGUgZm9yIHVzZSBvZiBleHRlbnNpb25zDQo+ PiBpbiBjb250cm9sbGVkIGRvbWFpbnMsIG9yIGEgc3RhdGVtZW50IHRoYXQgdGhpcyBkb2N1bWVu dCBqdXN0IGFwcGxpZXMgdG8NCj4+IElQdjYgdHJhZmZpYyBpbnRlbmRlZCB0byBjcm9zcyB0aGUg SW50ZXJuZXQgKGFzIHN1Z2dlc3RlZCBhdCB0aGUgNm1hbg0KPj4gbWVldGluZyBpbiBDaGljYWdv IFs0XSkuLi4gIE15IG9waW5pb24gaXMgdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBub3QNCj4+ IGJlIHB1Ymxpc2hlZCBhcyBhbiBJbnRlcm5ldCBTdGFuZGFyZCB1bnRpbCB0aGUgcmVtYWluaW5n IG9wZW4gZGlzY3Vzc2lvbnMNCj4+IGFyZSBleHBsaWNpdGx5IHJlc29sdmVkIGFuZCB0aGlzIGRv Y3VtZW50IHJlZmxlY3RzIHRoYXQgcmVzb2x1dGlvbi4NCj4+IA0KPj4gDQo+PiBbMV0NCj4+IGh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvaXB2Ni9VSTBQZnFyV2NvNEhwYnZt OGtlR1I4RmFiUmcvP3FpZD05YTZiYThlOTc3NzExNGUyNGExZTk2NDMzNmVkNzhmMQ0KPj4gWzJd DQo+PiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lwdjYvT3JMWXhLdW1p S1dMSEdrZU5hbWhxOXB4dXRRLz9xaWQ9NjNjMTU5ZmU0MWMxODY1M2Q5ZGMwYmU2MDlmOWU5N2YN Cj4+IFszXQ0KPj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pcHY2L1JF ZXowLWxiZWJwby1YZW0teFhfc1dWMHBmNC8/cWlkPTVjZGFiNmM2MDg1Nzk1MTI5ODAyYWI2MjJi YjQxNTlmDQo+PiBbNF0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTgvbWludXRl cy9taW51dGVzLTk4LTZtYW4tMDANCj4+IA0KPj4gDQo+PiANCj4+ID09PT09PT09PT0NCj4+IA0K Pj4gUmVsYXRlZCB0byB0aGUgYWJvdmUsIEkgYWxzbyB3YW50IHRvIHBvaW50IG91dCB0aGUgbGFj ayBvZiBjbGFyaXR5IGluIHRoZQ0KPj4gdGV4dCBpbiBTZWN0aW9uIDQuIChJUHY2IEV4dGVuc2lv biBIZWFkZXJzKSwgd2hpY2ggbGVhdmVzIGl0c2VsZiBvcGVuIHRvDQo+PiBpbnRlcnByZXRhdGlv biBhbmQgc2hvdWxkIGJlIGNsZWFuZWQgdXAuDQo+PiANCj4+IChBKSAgVGhlIG1haW4gcGllY2Ug b2YgdGV4dCB0aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBub3cgcmVhZHM6DQo+PiANCj4+ICAgV2l0 aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9j ZXNzZWQsDQo+PiAgIGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFj a2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4+ICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBu b2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+PiAgIHRoZSBjYXNlIG9mIG11 bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZA0KPj4g b2YNCj4+ICAgdGhlIElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndh cmRpbmcgbm9kZSBleGFtaW5lcw0KPj4gICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVh c29uLCBpdCBtdXN0IGRvIHNvIGluIGFjY29yZGFuY2Ugd2l0aA0KPj4gICB0aGUgcHJvdmlzaW9u cyBvZiBbUkZDNzA0NV0uDQo+PiAgIC4uLg0KPj4gICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRv IGluIHRoZSBwcmVjZWRpbmcgcGFyYWdyYXBoIGlzIHRoZSBIb3AtYnktDQo+PiAgIEhvcCBPcHRp b25zIGhlYWRlciwgd2hpY2ggY2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBleGFtaW5l ZA0KPj4gICBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxp dmVyeSBwYXRoLA0KPj4gaW5jbHVkaW5nDQo+PiAgIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9u IG5vZGVzLiAgVGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsDQo+PiAgIHdoZW4gcHJlc2Vu dCwgbXVzdCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVyLiAgSXRzIHByZXNlbmNl DQo+PiAgIGlzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgemVybyBpbiB0aGUgTmV4dCBIZWFkZXIg ZmllbGQgb2YgdGhlIElQdjYNCj4+ICAgaGVhZGVyLg0KPj4gDQo+PiAgIE5PVEU6IFdoaWxlIFtS RkMyNDYwXSByZXF1aXJlZCB0aGF0IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUgYW5kDQo+PiAgIHBy b2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBleHBlY3RlZCB0 aGF0IG5vZGVzDQo+PiAgIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1p bmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCj4+ICAgSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4 cGxpY2l0bHkgY29uZmlndXJlZCB0byBkbyBzby4NCj4+IA0KPj4gDQo+PiBXaGlsZSB0aGUgZmly c3Qgc2VudGVuY2Ugc2VlbXMgY2xlYXIgb24gd2hhdCB0aGlzIGRvY3VtZW50IHdhbnRzDQo+PiBm b3J3YXJkaW5nIG5vZGVzIHRvIGRvIChvciBub3QpLCB0aGVyZSBhcmUgdHdvIG5vdGVzIHRoYXQg ZGVmaW5lDQo+PiBleGNlcHRpb25zOiBhbnkgZm9yd2FyZGluZyBub2RlIGNhbiBleGFtaW5lIHRo ZSBoZWFkZXJzICJmb3IgYW55IHJlYXNvbiIsDQo+PiBhbmQsIHRoZSBIb3AtYnktSG9wIE9wdGlv bnMgaGVhZGVyIGRvZXNuJ3QgcmVhbGx5IGhhdmUgdG8gYmUgZXhhbWluZWQgYW5kDQo+PiBwcm9j ZXNzZWQgYnkgZXZlcnlvbmUuDQo+PiANCj4+IFRoaXMgdGV4dCBuZWVkcyBzb21lIG1vcmUgd29y ayB0byBhdCBsZWFzdCBub3QgY29udHJhZGljdCBpdHNlbGY6IHRoZXJlDQo+PiBpcyBtb3JlIHRo YW4gb25lIGV4Y2VwdGlvbiwgYW5kIHRoZXkgYXJlIG5vdCBhYnNvbHV0ZSwgYW55b25lIGNhbiBl eGFtaW5lDQo+PiB0aGUgaGVhZGVycyAiZm9yIGFueSByZWFzb27igJ3igKYNCj4gDQo+IFJpZ2h0 LiBJIHRoaW5rIHRoZSBleGFtaW5lIHBpZWNlIGNvdWxkIHVzZSBzb21lIHJld29yZGluZyB0byBt ZXJnZSB3aXRoIHRoZSBSRkM3MDQ1IGV4Y2VwdGlvbi4NCj4gDQo+PiANCj4+IChCKQ0KPj4gDQo+ PiBBcyBpdCBzdGFuZHMsIHRoZSBub3RlIGFib3V0IHRoZSBjaGFuZ2VkIGV4cGVjdGF0aW9ucyBm b3IgdGhlIEhvcC1ieS1Ib3ANCj4+IG9wdGlvbnMgaGVhZGVyIG9wZW5zIGEgc2lnbmlmaWNhbnQg ZG9vciB0byB3b3JrIGFyb3VuZCB0aGUgImxpbWl0YXRpb25zIg0KPj4gb2Ygb3RoZXIgb3B0aW9u cy4gIEZvciBleGFtcGxlLCBpdCB3b3VsZCBiZSByZWxhdGl2ZWx5IHN0cmFpZ2h0IGZvcndhcmQN Cj4+IHRvIGRlZmluZSBhIG5ldyBIb3AtYnktSG9wIG9wdGlvbiB0byBjYXJyeSBhbnkgdHlwZSBv ZiBpbmZvcm1hdGlvbiB0aGF0DQo+PiBjb3VsZCB0aGVuIGJlICJleGFtaW5lZCwgcHJvY2Vzc2Vk LCBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZQ0KPj4gYWxvbmcgYSBwYWNrZXQncyBk ZWxpdmVyeSBwYXRoIi4gIEluIHRoZSB3b3JsZCBvZiBjb250cm9sbGVycyBhbmQNCj4+IHByb2dy YW1tYXRpYyBhY2Nlc3MgdG8gZm9yd2FyZGluZyBub2RlcywgY2hhbmdpbmcgdGhlIGV4cGxpY2l0 DQo+PiBjb25maWd1cmF0aW9uIG9uIHRoZSBmbHkgdG8gY3VzdG9taXplIHdoaWNoIG5vZGVzIGRv IHdoYXQsIGlzIHRyaXZpYWwuDQo+PiANCj4+IElzIHRoYXQgdGhlIGludGVudCBvZiB0aGlzIGRv Y3VtZW50LCB0byBwcm92aWRlIGEgZ2VuZXJpYyBtZWNoYW5pc20gZm9yDQo+PiBjYXNlcyB0aGF0 IG1heSBuZWVkIGV4dGVuc2lvbiBoZWFkZXJzIHRvIGJlICJleGFtaW5lZCwgcHJvY2Vzc2VkLA0K Pj4gaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxp dmVyeSBwYXRoIj8gIFdpbGwNCj4+IHRoZSBXRy9JRVRGIGJlIGluIGEgcG9zaXRpb24gdG8gY2hh cnRlciwgYWRvcHQgYW5kL29yIHB1Ymxpc2ggdGhlc2UgdHlwZXMNCj4+IG9mIGRvY3VtZW50cz8g IEkgYXNrIHRoaXMgcXVlc3Rpb24gbm90IG9ubHkgaW4gdGhlIGNvbnRleHQgb2YgbXkgY29uY2Vy bnMNCj4+IGV4cHJlc3NlZCBhYm92ZSwgYnV0IGFsc28gYmVjYXVzZSB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUgSG9wLWJ5LUhvcCBPcHRpb24NCj4+IHdvdWxkIHNlZW0gdG8gYmUgYWJsZSB0byBoYW5k bGUgYW55dGhpbmcgKCJ1c2VkIHRvIGNhcnJ5IG9wdGlvbmFsDQo+PiBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBleGFtaW5lZCBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYQ0KPj4g cGFja2V0J3MgZGVsaXZlcnkgcGF0aCIgLSBJIGRpZG4ndCBzZWUgYW55IGNvbnN0cmFpbnRzKSwg ZXZlbiBpZiAoZm9yDQo+PiBleGFtcGxlKSB0aGUgUm91dGluZyBIZWFkZXIgImlzIHVzZWQgYnkg YW4gSVB2NiBzb3VyY2UgdG8gbGlzdCBvbmUgb3INCj4+IG1vcmUgaW50ZXJtZWRpYXRlIG5vZGVz IHRvIGJlICJ2aXNpdGVkIiBvbiB0aGUgd2F5IHRvIGEgcGFja2V0J3MNCj4+IGRlc3RpbmF0aW9u IiAtLSBzbyBpdCBtYWtlcyBtZSB3b25kZXIgd2hldGhlciB1c2luZyB0aGUgSG9wLWJ5LUhvcA0K Pj4gT3B0aW9ucyBoZWFkZXIgdG8gY2FycnkgKGZvciBleGFtcGxlKSByb3V0aW5nIGluZm9ybWF0 aW9uIHNvIHRoYXQgaXQgY2FuDQo+PiBiZSAiZXhhbWluZWQsIHByb2Nlc3NlZCwgaW5zZXJ0ZWQs IG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYQ0KPj4gcGFja2V0J3MgZGVsaXZlcnkgcGF0 aCIgd291bGQgcGFzcyB0aGUgYmFyIHNldCBpbiBTZWN0aW9uIDQuOC4gKERlZmluaW5nDQo+PiBO ZXcgRXh0ZW5zaW9uIEhlYWRlcnMgYW5kIE9wdGlvbnMpOg0KPj4gDQo+PiAgIE5ldyBob3AtYnkt aG9wIG9wdGlvbnMgYXJlIG5vdCByZWNvbW1lbmRlZCBiZWNhdXNlIG5vZGVzIG1heSBiZQ0KPj4g ICBjb25maWd1cmVkIHRvIGlnbm9yZSB0aGUgSG9wLWJ5LUhvcCBPcHRpb24gaGVhZGVyLCBkcm9w IHBhY2tldHMNCj4+ICAgY29udGFpbmluZyBhIGhvcC1ieS1ob3AgaGVhZGVyLCBvciBhc3NpZ24g cGFja2V0cyBjb250YWluaW5nIGEgaG9wLQ0KPj4gICBieS1ob3AgaGVhZGVyIHRvIGEgc2xvdyBw cm9jZXNzaW5nIHBhdGguICBEZXNpZ25lcnMgY29uc2lkZXJpbmcNCj4+ICAgZGVmaW5pbmcgbmV3 IGhvcC1ieS1ob3Agb3B0aW9ucyBuZWVkIHRvIGJlIGF3YXJlIG9mIHRoaXMgbGlrZWx5DQo+PiAg IGJlaGF2aW91ci4gIFRoZXJlIGhhcyB0byBiZSBhIHZlcnkgY2xlYXIganVzdGlmaWNhdGlvbiB3 aHkgYW55IG5ldw0KPj4gICBob3AtYnktaG9wIG9wdGlvbiBpcyBuZWVkZWQgYmVmb3JlIGl0IGlz IHN0YW5kYXJkaXplZC4NCj4+IA0KPj4gSW4gdGhlIGNvbnRleHQgb2YgYSBjb250cm9sbGVkIGRv bWFpbiwgaXQgc2hvdWxkIGJlIHJlbGF0aXZlbHkgZWFzeSBmb3INCj4+IHRoZSBvcGVyYXRvciB0 byBhY2NvdW50IGZvciB0aG9zZSBpc3N1ZXMuICBTbyBteSBpbnRlcnByZXRhdGlvbiBvZg0KPj4g d2hldGhlciBhIEhvcC1ieS1Ib3Agb3B0aW9uIGlzIG9rIHRvIGNhcnJ5IChmb3IgZXhhbXBsZSkg cm91dGluZw0KPj4gaW5mb3JtYXRpb24gaXMgYSBzdHJvbmcgIlllcyEiLiAgV2hldGhlciBteSBp bnRlcnByZXRhdGlvbiBpcyB3aGF0IHdhcw0KPj4gaW50ZW5kZWQgb3Igbm90LCBJIGJlbGlldmUg dGhlIG92ZXJhbGwgdGV4dCBjb3VsZCBiZW5lZml0IGZyb20gbW9yZQ0KPj4gY2xhcml0eS4NCj4g DQo+IE15IHBlcnNvbmFsIG9waW5pb24gaXMgYWxzbyBZZXMsIGFzIGxvbmcgYXMgdGhlIEhvcC1i eS1ob3Agb3B0aW9uIGhlYWRlciBpcyBpbnNlcnRlZCBpbnRvIGEgcGFja2V0IG9yaWdpbmF0ZWQg aW4gdGhlIGNvbnRyb2xsZWQgZG9tYWluIChzdWNoIGFzIHRoZSBtZWNoYW5pc20gc3BlY2lmaWVk IGluIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLTA2KS4NCj4gDQo+PiAN Cj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gQ09NTUVOVDoNCj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ IA0KPj4gQXBwZW5kaXggQi4gKENoYW5nZXMgU2luY2UgUkZDMjQ2MCkgbWVudGlvbnMgdGhhdCB0 aGUgdGV4dCB3YXMgcmV2aXNlZA0KPj4gYmFzZWQgb24gdXBkYXRlcyBmcm9tIHNldmVyYWwgb3Ro ZXIgUkZDcyB3aGljaCBVcGRhdGVkIHJmYzI0NjAuICBJIGRpZG4ndA0KPj4gY2hlY2sgYWxsIHRo ZSBkZXRhaWxzLCBidXQgaWYgdGhlIHVwZGF0ZXMgd2VyZSBpbmNvcnBvcmF0ZWQgaW4gdGhpcw0K Pj4gZG9jdW1lbnQsIHdoeSBhcmUgdGhvc2UgUkZDcyBub3QgbWFya2VkIGFzIGJlaW5nIE9ic29s ZXRlPyAgSXMgdGhlcmUgYW55DQo+PiB2YWx1ZSBsZWZ0IGluIHRoZW0/DQo+IA0KPiBUaGVyZSBp cyBhIGxvdCBvZiByYXRpb25hbGUgYW5kIGJhY2tncm91bmQgdGhhdCB0aGUgV0cgZGVjaWRlZCBu b3QgdG8gZm9sZCBpbnRvIHRoaXMgZG9jdW1lbnQuIExvdCBvZiB0aGVzZSB1cGRhdGVzIGRvY3Vt ZW50cyBoYXZlIGxlZCB0byBhIGZldyBzZW50ZW5jZXMgd2l0aCBhIHBvaW50ZXIgYmFjayB0byB0 aGUgb3RoZXIgZG9jdW1lbnRzIGZvciBtb3JlIGluZm8gYW5kIGFwcGxpY2FiaWxpdHkuIGUuZy4g UkZDNjkzNSBhbGxvd2VkIFVEUCBjaGVja3N1bXMgdG8gYmUgemVybyBhbmQgUkZDNjkzNiBleHBs YWlucyBhcHBsaWNhYmlsaXR5LCBpc3N1ZXMgYW5kIGRlc2lnbiBwcmluY2lwbGVzIHRvIGNvbnNp ZGVyIHdoZW4gemVybyBVRFAgY2hlY2tzdW1zIGNhbiBiZSB1c2VkLiBUaGV5IHJlc3VsdGVkIGlu IGEgZmV3IHNlbnRlbmNlcyBhbmQgYSBwb2ludGVyIGZvciBmdXJ0aGVyIGluZm8uIFRoYXQgaXMg d2h5IHRoZXkgY2Fubm90IGJlIG9ic29sZXRlZC4NCj4gDQo+IFRoYW5rcw0KPiBTdXJlc2gNCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K PiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Mon Apr 10 06:53:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC21294E0; Mon, 10 Apr 2017 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 OGTTIoj8beW4; Mon, 10 Apr 2017 06:53:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4951293E0; Mon, 10 Apr 2017 06:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10530; q=dns/txt; s=iport; t=1491832432; x=1493042032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nA5ueIPcj2HLkyCetdGHeJuiX1FI0TABfYHHt/HhDRw=; b=IKgywsAzTe4abph9mR5AEX5jO+jOVAYIOhIN3cR40ttShGzdwPXoCDiZ 9Tqy8yB2BG3hxuQ0oFLrODzeYWxS9MsL7XwtyMwjAQFVuPgqx7oKePzUH l21/T72LfJFjqNVYkGp7Gud9gS6bVqTTB+kLRMR/3frKSjtmQ2I5cGBx8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQC+jetY/5RdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNTgWwHg1+KE5FGlVeCD4YkAhqDQj8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECASMRMxIFCwIBBgIYAgImAgICMBUQAgQBDQWKBwiLLp1dgiaKYwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BC4VFggWCa4RWOAKCTC6CMQEEliCGWwGKKoguCoF?= =?us-ascii?q?1hS6KFJN/AR84PkdbFVIBhH6BDT11iFKBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="234134957" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 13:53:51 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3ADrpxA012181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 13:53:51 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 08:53:50 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 08:53:50 -0500 From: "Alvaro Retana (aretana)" To: Tim Chown , Suresh Krishnan CC: "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85dTThx1SRXYEO6jo/FFmbU1aG+QkcAgABhawCAABE3gA== Date: Mon, 10 Apr 2017 13:53:50 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> In-Reply-To: <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <410382FACB55E946981226BB6DE1D705@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:53:55 -0000 VGltOg0KDQpIaSENCg0KVGhlIGluaXRpYWwgc2VudGVuY2UgbWVudGlvbnMgNCBhY3Rpb25zOiBl eGFtaW5lLCBwcm9jZXNzLCBpbnNlcnQsIG9yIGRlbGV0ZS4gIA0KDQpUaGUgdGV4dCBhbHJlYWR5 IHNheXMgdGhhdCBhbnkgbm9kZSBjYW4gZXhhbWluZSB0aGUgaGVhZGVycyDigJxmb3IgYW55IHJl YXNvbuKAnSwgYWNjb3JkaW5nIHRvIFtyZmM3MDQ1XS4gIFNvIG1heWJlIHRha2UgdGhhdCBvdXQg YXMgcGFydCBvZiB0aGUgb3JpZ2luYWwgNC4NCg0KSSBkbyBoYXZlIGFuIGFkZGl0aW9uYWwgY2xh cml0eSBxdWVzdGlvbi4gIFdoYXQgZG9lcyDigJxwcm9jZXNz4oCdIG1lYW4/ICBEb2VzIGl0IGlu Y2x1ZGUgYSDigJxjaGFuZ2UgZW4tcm91dGXigJ0/ICAgIEnigJltIGFza2luZyBiZWNhdXNlIFNl Y3Rpb24gNC4yLiAoT3B0aW9ucykgc2F5cyB0aGF0IOKAnHRoZSBIb3AtYnktSG9wIE9wdGlvbnMg aGVhZGVyIGFuZCB0aGUgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXLigJ0gaGFzIGFuIG9wdGlv biBiaXQgdGhhdCBpbmRpY2F0ZXMg4oCcd2hldGhlciBvciBub3QgdGhlIE9wdGlvbiBEYXRhIG9m IHRoYXQgb3B0aW9uIGNhbiBjaGFuZ2UgZW4tcm91dGUgdG8gdGhlIHBhY2tldCdzIGZpbmFsIGRl c3RpbmF0aW9u4oCdLiAgSeKAmW0gYXNzdW1pbmcgdGhhdCB0byBjaGFuZ2UgdGhlIGRhdGEgdGhl IHRyYW5zaXQgbm9kZSBoYXMgdG8gbm90IGp1c3Qg4oCcZXhhbWluZeKAnSAod2hpY2ggSSB0aGlu ayBtZWFucyDigJxsb29rIGF04oCdKSwgYnV0IGFsc28gKGF0IGxlYXN0KSDigJxwcm9jZXNz4oCd IHRoZSBFSCBhcyB3ZWxsLiAgIElmIHRvIOKAnHByb2Nlc3PigJ0gaW5jbHVkZXMgdGhlIGFiaWxp dHkgdG8g4oCcY2hhbmdlIGVuLXJvdXRl4oCdLCB0aGVuIGl0IGxvb2tzIGxpa2UgdGhlIERlc3Rp bmF0aW9uIE9wdGlvbiBtYXkgYWxzbyBiZSBhbiBleGNlcHRpb27igKYNCg0KDQpJIGRvbuKAmXQg dGhpbmsgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbXVjaCB0byBjbGFyaWZ54oCmYXQgbGVhc3Qg bm90IGZvciBtZS4g4pi5DQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCg0KDQpPbiA0LzEwLzE3 LCA0OjUyIEFNLCAiVGltIENob3duIiA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KDQpI aSwNCg0KPiBPbiAxMCBBcHIgMjAxNywgYXQgMDQ6MDMsIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNo LmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBBbHZhcm8sDQo+ICAgVGhh bmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgZmluZCByZXNwb25zZXMgaW5saW5lLg0KPiAN Cj4+IE9uIEFwciA3LCAyMDE3LCBhdCAyOjM5IFBNLCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hQGNp c2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+ID09PT09PT09PT0NCj4+IA0KPj4gUmVsYXRlZCB0byB0 aGUgYWJvdmUsIEkgYWxzbyB3YW50IHRvIHBvaW50IG91dCB0aGUgbGFjayBvZiBjbGFyaXR5IGlu IHRoZQ0KPj4gdGV4dCBpbiBTZWN0aW9uIDQuIChJUHY2IEV4dGVuc2lvbiBIZWFkZXJzKSwgd2hp Y2ggbGVhdmVzIGl0c2VsZiBvcGVuIHRvDQo+PiBpbnRlcnByZXRhdGlvbiBhbmQgc2hvdWxkIGJl IGNsZWFuZWQgdXAuDQo+PiANCj4+IChBKSAgVGhlIG1haW4gcGllY2Ugb2YgdGV4dCB0aGF0IGhh cyBiZWVuIGRpc2N1c3NlZCBub3cgcmVhZHM6DQo+PiANCj4+ICAgV2l0aCBvbmUgZXhjZXB0aW9u LCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQo+PiAgIGlu c2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkg cGF0aCwNCj4+ICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9m IHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+PiAgIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRp ZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZA0KPj4gb2YNCj4+ICAgdGhlIElQ djYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgbm9kZSBleGFt aW5lcw0KPj4gICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBpdCBtdXN0IGRv IHNvIGluIGFjY29yZGFuY2Ugd2l0aA0KPj4gICB0aGUgcHJvdmlzaW9ucyBvZiBbUkZDNzA0NV0u DQo+PiAgIC4uLg0KPj4gICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRvIGluIHRoZSBwcmVjZWRp bmcgcGFyYWdyYXBoIGlzIHRoZSBIb3AtYnktDQo+PiAgIEhvcCBPcHRpb25zIGhlYWRlciwgd2hp Y2ggY2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBleGFtaW5lZA0KPj4gICBhbmQgcHJv Y2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLA0KPj4g aW5jbHVkaW5nDQo+PiAgIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG5vZGVzLiAgVGhlIEhv cC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsDQo+PiAgIHdoZW4gcHJlc2VudCwgbXVzdCBpbW1lZGlh dGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVyLiAgSXRzIHByZXNlbmNlDQo+PiAgIGlzIGluZGlj YXRlZCBieSB0aGUgdmFsdWUgemVybyBpbiB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQ djYNCj4+ICAgaGVhZGVyLg0KPj4gDQo+PiAgIE5PVEU6IFdoaWxlIFtSRkMyNDYwXSByZXF1aXJl ZCB0aGF0IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUgYW5kDQo+PiAgIHByb2Nlc3MgdGhlIEhvcC1i eS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBleHBlY3RlZCB0aGF0IG5vZGVzDQo+PiAg IGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3Mg dGhlIEhvcC1ieS0NCj4+ICAgSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4cGxpY2l0bHkgY29uZmln dXJlZCB0byBkbyBzby4NCj4+IA0KPj4gV2hpbGUgdGhlIGZpcnN0IHNlbnRlbmNlIHNlZW1zIGNs ZWFyIG9uIHdoYXQgdGhpcyBkb2N1bWVudCB3YW50cw0KPj4gZm9yd2FyZGluZyBub2RlcyB0byBk byAob3Igbm90KSwgdGhlcmUgYXJlIHR3byBub3RlcyB0aGF0IGRlZmluZQ0KPj4gZXhjZXB0aW9u czogYW55IGZvcndhcmRpbmcgbm9kZSBjYW4gZXhhbWluZSB0aGUgaGVhZGVycyAiZm9yIGFueSBy ZWFzb24iLA0KPj4gYW5kLCB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciBkb2Vzbid0IHJl YWxseSBoYXZlIHRvIGJlIGV4YW1pbmVkIGFuZA0KPj4gcHJvY2Vzc2VkIGJ5IGV2ZXJ5b25lLg0K Pj4gDQo+PiBUaGlzIHRleHQgbmVlZHMgc29tZSBtb3JlIHdvcmsgdG8gYXQgbGVhc3Qgbm90IGNv bnRyYWRpY3QgaXRzZWxmOiB0aGVyZQ0KPj4gaXMgbW9yZSB0aGFuIG9uZSBleGNlcHRpb24sIGFu ZCB0aGV5IGFyZSBub3QgYWJzb2x1dGUsIGFueW9uZSBjYW4gZXhhbWluZQ0KPj4gdGhlIGhlYWRl cnMgImZvciBhbnkgcmVhc29u4oCd4oCmDQo+IA0KPiBSaWdodC4gSSB0aGluayB0aGUgZXhhbWlu ZSBwaWVjZSBjb3VsZCB1c2Ugc29tZSByZXdvcmRpbmcgdG8gbWVyZ2Ugd2l0aCB0aGUgUkZDNzA0 NSBleGNlcHRpb24uDQoNCk9uZSB3YXkgdG8gaW1wcm92ZSB0aGUgUkZDNzA0NSDigJxjb250cmFk aWN0aW9u4oCdIGluIHRoZSAyNDYwLWJpcyB0ZXh0IHdvdWxkIGJlIHRvIHJlYXJyYW5nZSB0aGUg dGV4dCB0byBsaWZ0IG91dCB0aGUgUkZDNzA0NSByZWZlcmVuY2Ugc3VjaCB0aGF0IGl0IGZvbGxv d3MgdGhlIHRleHQgYWJvdXQgdGhlIEhiSCBvcHRpb24gaGVhZGVyLCBhZGRpbmcgYW4gZXhhbXBs ZSBvZiBpbnNwZWN0aW5nIHRoZSBwYXlsb2FkLCB3aGljaCBpcyB0aGUgbWFpbiByYXRpb25hbGUg Zm9yIHN1Y2ggaW5zcGVjdGlvbiBzdGF0ZWQgaW4gUkZDNzA0NS4gDQoNCk9sZDoNCg0KICAgV2l0 aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9j ZXNzZWQsDQogICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tl dCdzIGRlbGl2ZXJ5IHBhdGgsDQogICB1bnRpbCB0aGUgcGFja2V0IHJlYWNoZXMgdGhlIG5vZGUg KG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4NCiAgIHRoZSBjYXNlIG9mIG11bHRpY2Fz dCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KICAgdGhl IElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgbm9kZSBl eGFtaW5lcw0KICAgYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBk byBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCiAgIHRoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4g IEF0IHRoZSBEZXN0aW5hdGlvbiBub2RlLCBub3JtYWwNCiAgIGRlbXVsdGlwbGV4aW5nIG9uIHRo ZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgaW52b2tlcw0KICAgdGhlIG1v ZHVsZSB0byBwcm9jZXNzIHRoZSBmaXJzdCBleHRlbnNpb24gaGVhZGVyLCBvciB0aGUgdXBwZXIt bGF5ZXINCiAgIGhlYWRlciBpZiBubyBleHRlbnNpb24gaGVhZGVyIGlzIHByZXNlbnQuICBUaGUg Y29udGVudHMgYW5kIHNlbWFudGljcw0KICAgb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyIGRldGVy bWluZSB3aGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHRvIHRoZQ0KICAgbmV4dCBoZWFkZXIuICBU aGVyZWZvcmUsIGV4dGVuc2lvbiBoZWFkZXJzIG11c3QgYmUgcHJvY2Vzc2VkIHN0cmljdGx5DQog ICBpbiB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4gdGhlIHBhY2tldDsgYSByZWNlaXZlciBtdXN0 IG5vdCwgZm9yDQogICBleGFtcGxlLCBzY2FuIHRocm91Z2ggYSBwYWNrZXQgbG9va2luZyBmb3Ig YSBwYXJ0aWN1bGFyIGtpbmQgb2YNCiAgIGV4dGVuc2lvbiBoZWFkZXIgYW5kIHByb2Nlc3MgdGhh dCBoZWFkZXIgcHJpb3IgdG8gcHJvY2Vzc2luZyBhbGwNCiAgIHByZWNlZGluZyBvbmVzLg0KDQog ICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRvIGluIHRoZSBwcmVjZWRpbmcgcGFyYWdyYXBoIGlz IHRoZSBIb3AtYnktDQogICBIb3AgT3B0aW9ucyBoZWFkZXIsIHdoaWNoIGNhcnJpZXMgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgZXhhbWluZWQNCiAgIGFuZCBwcm9jZXNzZWQgYnkgZXZlcnkgbm9k ZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgsIGluY2x1ZGluZw0KICAgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gbm9kZXMuICBUaGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwN CiAgIHdoZW4gcHJlc2VudCwgbXVzdCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVy LiAgSXRzIHByZXNlbmNlDQogICBpcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIHplcm8gaW4gdGhl IE5leHQgSGVhZGVyIGZpZWxkIG9mIHRoZSBJUHY2DQogICBoZWFkZXIuDQoNCiAgIE5PVEU6IFdo aWxlIFtSRkMyNDYwXSByZXF1aXJlZCB0aGF0IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUgYW5kDQog ICBwcm9jZXNzIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLCBpdCBpcyBub3cgZXhwZWN0 ZWQgdGhhdCBub2Rlcw0KICAgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoIG9ubHkgZXhh bWluZSBhbmQgcHJvY2VzcyB0aGUgSG9wLWJ5LQ0KICAgSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4 cGxpY2l0bHkgY29uZmlndXJlZCB0byBkbyBzby4NCg0KTmV3Og0KDQogICBXaXRoIG9uZSBleGNl cHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCwNCiAg IGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZl cnkgcGF0aCwNCiAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBv ZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlm aWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mDQogICB0aGUgSVB2NiBoZWFk ZXIuICBBdCB0aGUgRGVzdGluYXRpb24gbm9kZSwgbm9ybWFsDQogICBkZW11bHRpcGxleGluZyBv biB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMNCiAgIHRo ZSBtb2R1bGUgdG8gcHJvY2VzcyB0aGUgZmlyc3QgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVw cGVyLWxheWVyDQogICBoZWFkZXIgaWYgbm8gZXh0ZW5zaW9uIGhlYWRlciBpcyBwcmVzZW50LiAg VGhlIGNvbnRlbnRzIGFuZCBzZW1hbnRpY3MNCiAgIG9mIGVhY2ggZXh0ZW5zaW9uIGhlYWRlciBk ZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUNCiAgIG5leHQgaGVhZGVy LiAgVGhlcmVmb3JlLCBleHRlbnNpb24gaGVhZGVycyBtdXN0IGJlIHByb2Nlc3NlZCBzdHJpY3Rs eQ0KICAgaW4gdGhlIG9yZGVyIHRoZXkgYXBwZWFyIGluIHRoZSBwYWNrZXQ7IGEgcmVjZWl2ZXIg bXVzdCBub3QsIGZvcg0KICAgZXhhbXBsZSwgc2NhbiB0aHJvdWdoIGEgcGFja2V0IGxvb2tpbmcg Zm9yIGEgcGFydGljdWxhciBraW5kIG9mDQogICBleHRlbnNpb24gaGVhZGVyIGFuZCBwcm9jZXNz IHRoYXQgaGVhZGVyIHByaW9yIHRvIHByb2Nlc3NpbmcgYWxsDQogICBwcmVjZWRpbmcgb25lcy4N Cg0KICAgVGhlIGV4Y2VwdGlvbiByZWZlcnJlZCB0byBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFw aCBpcyB0aGUgSG9wLWJ5LQ0KICAgSG9wIE9wdGlvbnMgaGVhZGVyLCB3aGljaCBjYXJyaWVzIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1pbmVkDQogICBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5 IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCBpbmNsdWRpbmcNCiAgIHRoZSBz b3VyY2UgYW5kIGRlc3RpbmF0aW9uIG5vZGVzLiAgVGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFk ZXIsDQogICB3aGVuIHByZXNlbnQsIG11c3QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBJUHY2IGhl YWRlci4gIEl0cyBwcmVzZW5jZQ0KICAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSB6ZXJvIGlu IHRoZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KICAgaGVhZGVyLg0KDQogICBOT1RF OiBXaGlsZSBbUkZDMjQ2MF0gcmVxdWlyZWQgdGhhdCBhbGwgbm9kZXMgbXVzdCBleGFtaW5lIGFu ZA0KICAgcHJvY2VzcyB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwgaXQgaXMgbm93IGV4 cGVjdGVkIHRoYXQgbm9kZXMNCiAgIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5 IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCiAgIEhvcCBPcHRpb25zIGhlYWRlciBp ZiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8gc28uDQogICANCiAgIE5PVEU6IElmIGFueSBv dGhlciBpbnRlcm1lZGlhdGUgZm9yd2FyZGluZyBkZXZpY2UgbmVlZHMgdG8gZXhhbWluZQ0KICAg YW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgZS5nLiwgdG8gdHJhdmVyc2UgdGhl IGV4dGVuc2lvbg0KICAgaGVhZGVyIGNoYWluIHRvIGluc3BlY3QgdGhlIHRyYW5zcG9ydCBoZWFk ZXIgb2YgYSBwYWNrZXQsIGl0IG11c3QgZG8gc28gaW4gDQogICBhY2NvcmRhbmNlIHdpdGggdGhl IHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVdLiANCg0KVGhlIHF1ZXN0aW9uIHRoZW4gd291bGQgYmUg dGhlIHNwZWNpZmljIHdvcmRpbmcgb2YgdGhhdCBsYXN0IHBhcmFncmFwaC4NCg0KVGltDQoNCg== From nobody Mon Apr 10 09:09:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7CB128C81 for ; Mon, 10 Apr 2017 09:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 ewHaE9SbnoOG for ; Mon, 10 Apr 2017 09:09:11 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9D412955F for ; Mon, 10 Apr 2017 09:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491840547; bh=/63s80E05Jy/e1NHB9XdPtKhTpgvtGBitSWdghTA2yE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aS0HrLFO8SijM17YhBdcy/0KMkG2HsYKsXeh79/3WOnkcA6rskL+ZSk1tSk/TJKBkAat8mGfvsLSxrEVucJkqZuIo80mcXEQED8ilAs0l6qyNqD07DXclun+LNTbLqoeeSqANNYj1aSAkC3iTwiCEUkPti5s5rgxqMU0RmVMRKo= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0146.outbound.protection.outlook.com [213.199.154.146]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-20-8wbJqGAaOKSOI2oMGouwzw-1; Mon, 10 Apr 2017 17:09:03 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Mon, 10 Apr 2017 16:09:02 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1034.009; Mon, 10 Apr 2017 16:09:02 +0000 From: Tim Chown To: "Alvaro Retana (aretana)" CC: Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85pLrAb8QsmG0aX1HJll0Sq6aG97nUAgABhaoCAAFRHAIAAJcWA Date: Mon, 10 Apr 2017 16:09:02 +0000 Message-ID: <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:74eb:c2b5:afca:b935] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:hjIdMCvMpzj5yzPMV5+pLRilb9OntinRp2URyDiZNHZgY4YUtavZ+Qd8IfVEkZ1tcDF3+h2MSDgvYngOzQHczIxAMR8S/OTv0l0KOPabl24qF1cA0JIwd8k57vmxTPIBAFtrGEx9EKjLSD7SXb9JLUDVzKOLr8Ahgu14qFKXZG3DtU2oklX2lfdP4zzJnqPbx1P3On4YVg7Ty3Tp5bCsUcFhs/qaFbzOw/MoRWJvfRzCA/wm5mgDHmrc6Bc5M8FeVbpWUjdnXi7ouq8LElaPdy/awoLx21E1JWKWUCTxlNGreqKuZCWzEKU1MY34j12Udza7wpKkCaFPKaJHl6jn9Q==; 20:aejhgzZG5lAnuGI3fxbRBeOGOIU60tuLDd5gMFdXTS85pQ+g17QZcZA+taEFmsCpzbSll5Z/8pZn3xByCCsGdav0wQSS79DNAy+VASFV+GT/1gSKmBoKg08v675u1KJ+CpoCgfzCHUCQuIWSmBeQeVZURNAYLnoA1s5bL25S2PQ= x-ms-office365-filtering-correlation-id: f4030435-0fb6-4958-7795-08d4802be784 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(37575265505322)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 027367F73D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39400400002)(39450400003)(39840400002)(39410400002)(24454002)(377454003)(81166006)(53546009)(25786009)(36756003)(50986999)(2900100001)(8936002)(8676002)(7736002)(50226002)(102836003)(6116002)(74482002)(33656002)(110136004)(38730400002)(189998001)(57306001)(4326008)(76176999)(229853002)(6436002)(6486002)(6506006)(42882006)(6916009)(2950100002)(2906002)(5660300001)(3660700001)(3280700002)(5250100002)(53936002)(6512007)(54906002)(99286003)(93886004)(6246003)(230783001)(305945005)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2017 16:09:02.1624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: 8wbJqGAaOKSOI2oMGouwzw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:09:14 -0000 SGkgQWx2YXJvLA0KDQo+IE9uIDEwIEFwciAyMDE3LCBhdCAxNDo1MywgQWx2YXJvIFJldGFuYSAo YXJldGFuYSkgPGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IFRpbToNCj4gDQo+IEhp IQ0KPiANCj4gVGhlIGluaXRpYWwgc2VudGVuY2UgbWVudGlvbnMgNCBhY3Rpb25zOiBleGFtaW5l LCBwcm9jZXNzLCBpbnNlcnQsIG9yIGRlbGV0ZS4gIA0KPiANCj4gVGhlIHRleHQgYWxyZWFkeSBz YXlzIHRoYXQgYW55IG5vZGUgY2FuIGV4YW1pbmUgdGhlIGhlYWRlcnMg4oCcZm9yIGFueSByZWFz b27igJ0sIGFjY29yZGluZyB0byBbcmZjNzA0NV0uICBTbyBtYXliZSB0YWtlIHRoYXQgb3V0IGFz IHBhcnQgb2YgdGhlIG9yaWdpbmFsIDQuDQo+IA0KPiBJIGRvIGhhdmUgYW4gYWRkaXRpb25hbCBj bGFyaXR5IHF1ZXN0aW9uLiAgV2hhdCBkb2VzIOKAnHByb2Nlc3PigJ0gbWVhbj8gIERvZXMgaXQg aW5jbHVkZSBhIOKAnGNoYW5nZSBlbi1yb3V0ZeKAnT8gICAgSeKAmW0gYXNraW5nIGJlY2F1c2Ug U2VjdGlvbiA0LjIuIChPcHRpb25zKSBzYXlzIHRoYXQg4oCcdGhlIEhvcC1ieS1Ib3AgT3B0aW9u cyBoZWFkZXIgYW5kIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRlcuKAnSBoYXMgYW4gb3B0 aW9uIGJpdCB0aGF0IGluZGljYXRlcyDigJx3aGV0aGVyIG9yIG5vdCB0aGUgT3B0aW9uIERhdGEg b2YgdGhhdCBvcHRpb24gY2FuIGNoYW5nZSBlbi1yb3V0ZSB0byB0aGUgcGFja2V0J3MgZmluYWwg ZGVzdGluYXRpb27igJ0uICBJ4oCZbSBhc3N1bWluZyB0aGF0IHRvIGNoYW5nZSB0aGUgZGF0YSB0 aGUgdHJhbnNpdCBub2RlIGhhcyB0byBub3QganVzdCDigJxleGFtaW5l4oCdICh3aGljaCBJIHRo aW5rIG1lYW5zIOKAnGxvb2sgYXTigJ0pLCBidXQgYWxzbyAoYXQgbGVhc3QpIOKAnHByb2Nlc3Pi gJ0gdGhlIEVIIGFzIHdlbGwuICAgSWYgdG8g4oCccHJvY2Vzc+KAnSBpbmNsdWRlcyB0aGUgYWJp bGl0eSB0byDigJxjaGFuZ2UgZW4tcm91dGXigJ0sIHRoZW4gaXQgbG9va3MgbGlrZSB0aGUgRGVz dGluYXRpb24gT3B0aW9uIG1heSBhbHNvIGJlIGFuIGV4Y2VwdGlvbuKApg0KDQpJIHRoaW5rIG1v c3QgcGVvcGxlIGFsd2F5cyBhc3N1bWVkIHByb2Nlc3MgaW5jbHVkZWQgaW5zZXJ0aW5nIGFuZCBy ZW1vdmluZyBoZWFkZXJzLCBidXQgZXF1YWxseSBzb21lIHBlb3BsZSBhcmd1ZSB0aGF0IHN0cmlj dGx5IGV4YW1pbmluZyBpbnZvbHZlcyBzb21lIGZvcm0gb2YgcHJvY2Vzc2luZy4NCg0KPiBJIGRv buKAmXQgdGhpbmsgeW91ciBwcm9wb3NlZCB0ZXh0IGRvZXMgbXVjaCB0byBjbGFyaWZ54oCmYXQg bGVhc3Qgbm90IGZvciBtZS4g4pi5DQoNCkl04oCZcyB0cmlja3ksIHdpdGhvdXQgcmV3cml0aW5n IG1vcmUgdGV4dCB0aGFuIHdhcyBvcmlnaW5hbGx5IGRlc2lyZWQuICBJdCB3b3VsZCBnb29kIGZv ciB0aGUgdGV4dCB0byBiZSBleHBsaWNpdCwgYW5kIG5vbi1jb250cmFkaWN0b3J5Lg0KDQpUaW0N Cg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gQWx2YXJvLg0KPiANCj4gDQo+IA0KPiANCj4gT24gNC8x MC8xNywgNDo1MiBBTSwgIlRpbSBDaG93biIgPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToN Cj4gDQo+IEhpLA0KPiANCj4+IE9uIDEwIEFwciAyMDE3LCBhdCAwNDowMywgU3VyZXNoIEtyaXNo bmFuIDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgQWx2 YXJvLA0KPj4gIFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgcmVzcG9uc2Vz IGlubGluZS4NCj4+IA0KPj4+IE9uIEFwciA3LCAyMDE3LCBhdCAyOjM5IFBNLCBBbHZhcm8gUmV0 YW5hIDxhcmV0YW5hQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gPT09PT09PT09PQ0KPj4+ IA0KPj4+IFJlbGF0ZWQgdG8gdGhlIGFib3ZlLCBJIGFsc28gd2FudCB0byBwb2ludCBvdXQgdGhl IGxhY2sgb2YgY2xhcml0eSBpbiB0aGUNCj4+PiB0ZXh0IGluIFNlY3Rpb24gNC4gKElQdjYgRXh0 ZW5zaW9uIEhlYWRlcnMpLCB3aGljaCBsZWF2ZXMgaXRzZWxmIG9wZW4gdG8NCj4+PiBpbnRlcnBy ZXRhdGlvbiBhbmQgc2hvdWxkIGJlIGNsZWFuZWQgdXAuDQo+Pj4gDQo+Pj4gKEEpICBUaGUgbWFp biBwaWVjZSBvZiB0ZXh0IHRoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIG5vdyByZWFkczoNCj4+PiAN Cj4+PiAgV2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1p bmVkLCBwcm9jZXNzZWQsDQo+Pj4gIGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFs b25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4+PiAgdW50aWwgdGhlIHBhY2tldCByZWFj aGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+Pj4gIHRoZSBj YXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBm aWVsZA0KPj4+IG9mDQo+Pj4gIHRoZSBJUHY2IGhlYWRlci4gIE5vdGU6IElmIGFuIGludGVybWVk aWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhhbWluZXMNCj4+PiAgYW4gZXh0ZW5zaW9uIGhlYWRlciBm b3IgYW55IHJlYXNvbiwgaXQgbXVzdCBkbyBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCj4+PiAgdGhl IHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVdLg0KPj4+ICAuLi4NCj4+PiAgVGhlIGV4Y2VwdGlvbiBy ZWZlcnJlZCB0byBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFwaCBpcyB0aGUgSG9wLWJ5LQ0KPj4+ ICBIb3AgT3B0aW9ucyBoZWFkZXIsIHdoaWNoIGNhcnJpZXMgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgZXhhbWluZWQNCj4+PiAgYW5kIHByb2Nlc3NlZCBieSBldmVyeSBub2RlIGFsb25nIGEgcGFj a2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4+PiBpbmNsdWRpbmcNCj4+PiAgdGhlIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24gbm9kZXMuICBUaGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwNCj4+PiAg d2hlbiBwcmVzZW50LCBtdXN0IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJ dHMgcHJlc2VuY2UNCj4+PiAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSB6ZXJvIGluIHRoZSBO ZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KPj4+ICBoZWFkZXIuDQo+Pj4gDQo+Pj4gIE5P VEU6IFdoaWxlIFtSRkMyNDYwXSByZXF1aXJlZCB0aGF0IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUg YW5kDQo+Pj4gIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5v dyBleHBlY3RlZCB0aGF0IG5vZGVzDQo+Pj4gIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0 aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCj4+PiAgSG9wIE9wdGlvbnMg aGVhZGVyIGlmIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBkbyBzby4NCj4+PiANCj4+PiBXaGls ZSB0aGUgZmlyc3Qgc2VudGVuY2Ugc2VlbXMgY2xlYXIgb24gd2hhdCB0aGlzIGRvY3VtZW50IHdh bnRzDQo+Pj4gZm9yd2FyZGluZyBub2RlcyB0byBkbyAob3Igbm90KSwgdGhlcmUgYXJlIHR3byBu b3RlcyB0aGF0IGRlZmluZQ0KPj4+IGV4Y2VwdGlvbnM6IGFueSBmb3J3YXJkaW5nIG5vZGUgY2Fu IGV4YW1pbmUgdGhlIGhlYWRlcnMgImZvciBhbnkgcmVhc29uIiwNCj4+PiBhbmQsIHRoZSBIb3At YnktSG9wIE9wdGlvbnMgaGVhZGVyIGRvZXNuJ3QgcmVhbGx5IGhhdmUgdG8gYmUgZXhhbWluZWQg YW5kDQo+Pj4gcHJvY2Vzc2VkIGJ5IGV2ZXJ5b25lLg0KPj4+IA0KPj4+IFRoaXMgdGV4dCBuZWVk cyBzb21lIG1vcmUgd29yayB0byBhdCBsZWFzdCBub3QgY29udHJhZGljdCBpdHNlbGY6IHRoZXJl DQo+Pj4gaXMgbW9yZSB0aGFuIG9uZSBleGNlcHRpb24sIGFuZCB0aGV5IGFyZSBub3QgYWJzb2x1 dGUsIGFueW9uZSBjYW4gZXhhbWluZQ0KPj4+IHRoZSBoZWFkZXJzICJmb3IgYW55IHJlYXNvbuKA neKApg0KPj4gDQo+PiBSaWdodC4gSSB0aGluayB0aGUgZXhhbWluZSBwaWVjZSBjb3VsZCB1c2Ug c29tZSByZXdvcmRpbmcgdG8gbWVyZ2Ugd2l0aCB0aGUgUkZDNzA0NSBleGNlcHRpb24uDQo+IA0K PiBPbmUgd2F5IHRvIGltcHJvdmUgdGhlIFJGQzcwNDUg4oCcY29udHJhZGljdGlvbuKAnSBpbiB0 aGUgMjQ2MC1iaXMgdGV4dCB3b3VsZCBiZSB0byByZWFycmFuZ2UgdGhlIHRleHQgdG8gbGlmdCBv dXQgdGhlIFJGQzcwNDUgcmVmZXJlbmNlIHN1Y2ggdGhhdCBpdCBmb2xsb3dzIHRoZSB0ZXh0IGFi b3V0IHRoZSBIYkggb3B0aW9uIGhlYWRlciwgYWRkaW5nIGFuIGV4YW1wbGUgb2YgaW5zcGVjdGlu ZyB0aGUgcGF5bG9hZCwgd2hpY2ggaXMgdGhlIG1haW4gcmF0aW9uYWxlIGZvciBzdWNoIGluc3Bl Y3Rpb24gc3RhdGVkIGluIFJGQzcwNDUuIA0KPiANCj4gT2xkOg0KPiANCj4gICBXaXRoIG9uZSBl eGNlcHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCwN Cj4gICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRl bGl2ZXJ5IHBhdGgsDQo+ICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBl YWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+ICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBp ZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mDQo+ICAgdGhlIElQ djYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgbm9kZSBleGFt aW5lcw0KPiAgIGFuIGV4dGVuc2lvbiBoZWFkZXIgZm9yIGFueSByZWFzb24sIGl0IG11c3QgZG8g c28gaW4gYWNjb3JkYW5jZSB3aXRoDQo+ICAgdGhlIHByb3Zpc2lvbnMgb2YgW1JGQzcwNDVdLiAg QXQgdGhlIERlc3RpbmF0aW9uIG5vZGUsIG5vcm1hbA0KPiAgIGRlbXVsdGlwbGV4aW5nIG9uIHRo ZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgaW52b2tlcw0KPiAgIHRoZSBt b2R1bGUgdG8gcHJvY2VzcyB0aGUgZmlyc3QgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVwcGVy LWxheWVyDQo+ICAgaGVhZGVyIGlmIG5vIGV4dGVuc2lvbiBoZWFkZXIgaXMgcHJlc2VudC4gIFRo ZSBjb250ZW50cyBhbmQgc2VtYW50aWNzDQo+ICAgb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyIGRl dGVybWluZSB3aGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHRvIHRoZQ0KPiAgIG5leHQgaGVhZGVy LiAgVGhlcmVmb3JlLCBleHRlbnNpb24gaGVhZGVycyBtdXN0IGJlIHByb2Nlc3NlZCBzdHJpY3Rs eQ0KPiAgIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUgcGFja2V0OyBhIHJlY2VpdmVy IG11c3Qgbm90LCBmb3INCj4gICBleGFtcGxlLCBzY2FuIHRocm91Z2ggYSBwYWNrZXQgbG9va2lu ZyBmb3IgYSBwYXJ0aWN1bGFyIGtpbmQgb2YNCj4gICBleHRlbnNpb24gaGVhZGVyIGFuZCBwcm9j ZXNzIHRoYXQgaGVhZGVyIHByaW9yIHRvIHByb2Nlc3NpbmcgYWxsDQo+ICAgcHJlY2VkaW5nIG9u ZXMuDQo+IA0KPiAgIFRoZSBleGNlcHRpb24gcmVmZXJyZWQgdG8gaW4gdGhlIHByZWNlZGluZyBw YXJhZ3JhcGggaXMgdGhlIEhvcC1ieS0NCj4gICBIb3AgT3B0aW9ucyBoZWFkZXIsIHdoaWNoIGNh cnJpZXMgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgZXhhbWluZWQNCj4gICBhbmQgcHJvY2Vzc2Vk IGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCBpbmNsdWRpbmcN Cj4gICB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBub2Rlcy4gIFRoZSBIb3AtYnktSG9wIE9w dGlvbnMgaGVhZGVyLA0KPiAgIHdoZW4gcHJlc2VudCwgbXVzdCBpbW1lZGlhdGVseSBmb2xsb3cg dGhlIElQdjYgaGVhZGVyLiAgSXRzIHByZXNlbmNlDQo+ICAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2 YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KPiAgIGhlYWRl ci4NCj4gDQo+ICAgTk9URTogV2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVz IG11c3QgZXhhbWluZSBhbmQNCj4gICBwcm9jZXNzIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVh ZGVyLCBpdCBpcyBub3cgZXhwZWN0ZWQgdGhhdCBub2Rlcw0KPiAgIGFsb25nIGEgcGFja2V0J3Mg ZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCj4gICBI b3AgT3B0aW9ucyBoZWFkZXIgaWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KPiAN Cj4gTmV3Og0KPiANCj4gICBXaXRoIG9uZSBleGNlcHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFy ZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCwNCj4gICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBh bnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGgsDQo+ICAgdW50aWwgdGhlIHBh Y2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+ ICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBB ZGRyZXNzIGZpZWxkIG9mDQo+ICAgdGhlIElQdjYgaGVhZGVyLiAgQXQgdGhlIERlc3RpbmF0aW9u IG5vZGUsIG5vcm1hbA0KPiAgIGRlbXVsdGlwbGV4aW5nIG9uIHRoZSBOZXh0IEhlYWRlciBmaWVs ZCBvZiB0aGUgSVB2NiBoZWFkZXIgaW52b2tlcw0KPiAgIHRoZSBtb2R1bGUgdG8gcHJvY2VzcyB0 aGUgZmlyc3QgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVwcGVyLWxheWVyDQo+ICAgaGVhZGVy IGlmIG5vIGV4dGVuc2lvbiBoZWFkZXIgaXMgcHJlc2VudC4gIFRoZSBjb250ZW50cyBhbmQgc2Vt YW50aWNzDQo+ICAgb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyIGRldGVybWluZSB3aGV0aGVyIG9y IG5vdCB0byBwcm9jZWVkIHRvIHRoZQ0KPiAgIG5leHQgaGVhZGVyLiAgVGhlcmVmb3JlLCBleHRl bnNpb24gaGVhZGVycyBtdXN0IGJlIHByb2Nlc3NlZCBzdHJpY3RseQ0KPiAgIGluIHRoZSBvcmRl ciB0aGV5IGFwcGVhciBpbiB0aGUgcGFja2V0OyBhIHJlY2VpdmVyIG11c3Qgbm90LCBmb3INCj4g ICBleGFtcGxlLCBzY2FuIHRocm91Z2ggYSBwYWNrZXQgbG9va2luZyBmb3IgYSBwYXJ0aWN1bGFy IGtpbmQgb2YNCj4gICBleHRlbnNpb24gaGVhZGVyIGFuZCBwcm9jZXNzIHRoYXQgaGVhZGVyIHBy aW9yIHRvIHByb2Nlc3NpbmcgYWxsDQo+ICAgcHJlY2VkaW5nIG9uZXMuDQo+IA0KPiAgIFRoZSBl eGNlcHRpb24gcmVmZXJyZWQgdG8gaW4gdGhlIHByZWNlZGluZyBwYXJhZ3JhcGggaXMgdGhlIEhv cC1ieS0NCj4gICBIb3AgT3B0aW9ucyBoZWFkZXIsIHdoaWNoIGNhcnJpZXMgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgZXhhbWluZWQNCj4gICBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxv bmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCBpbmNsdWRpbmcNCj4gICB0aGUgc291cmNlIGFu ZCBkZXN0aW5hdGlvbiBub2Rlcy4gIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLA0KPiAg IHdoZW4gcHJlc2VudCwgbXVzdCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVyLiAg SXRzIHByZXNlbmNlDQo+ICAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSB6ZXJvIGluIHRoZSBO ZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KPiAgIGhlYWRlci4NCj4gDQo+ICAgTk9URTog V2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgZXhhbWluZSBhbmQN Cj4gICBwcm9jZXNzIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLCBpdCBpcyBub3cgZXhw ZWN0ZWQgdGhhdCBub2Rlcw0KPiAgIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5 IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhvcC1ieS0NCj4gICBIb3AgT3B0aW9ucyBoZWFkZXIg aWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KPiANCj4gICBOT1RFOiBJZiBhbnkg b3RoZXIgaW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgZGV2aWNlIG5lZWRzIHRvIGV4YW1pbmUNCj4g ICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBlLmcuLCB0byB0cmF2ZXJzZSB0 aGUgZXh0ZW5zaW9uDQo+ICAgaGVhZGVyIGNoYWluIHRvIGluc3BlY3QgdGhlIHRyYW5zcG9ydCBo ZWFkZXIgb2YgYSBwYWNrZXQsIGl0IG11c3QgZG8gc28gaW4gDQo+ICAgYWNjb3JkYW5jZSB3aXRo IHRoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4gDQo+IA0KPiBUaGUgcXVlc3Rpb24gdGhlbiB3 b3VsZCBiZSB0aGUgc3BlY2lmaWMgd29yZGluZyBvZiB0aGF0IGxhc3QgcGFyYWdyYXBoLg0KPiAN Cj4gVGltDQo+IA0KDQo= From nobody Mon Apr 10 13:24:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308F1129AD0; Mon, 10 Apr 2017 13:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 j082QB7S0RvG; Mon, 10 Apr 2017 13:24:41 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 5F9DD127B57; Mon, 10 Apr 2017 13:24:38 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id r16so55011772ioi.2; Mon, 10 Apr 2017 13:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=e18t/vscegHiMMi+HIDf2U/9dOvczVezDdLwtQR/4k0=; b=pgBAZXCxxiUxcBojsOOC1bKpPWnsld6WHshOiwZlLGnv8tS4t16f/V6LeHGgEQ6NVZ 2VMLpwm1L7aGqd1XdJhAjlAaOwVIuzmCnes57pJJm4BL9ZjOK9X+CKY+Jt8OXCWwvIzd kukZ3T7Aaeo2dbWyXd+iREOAi3TNu61xt7++nkp2lquySrs7hVEizZrLbjwZ10dqGnr4 gm3ta/fuasPjMlSBqwE+55HL/L/7fe4kwpMY2Gn56mZKGwU3iBhZPDV5adA0Ypj2aOq1 O6Mwlzy1jVuhtMXBfkP+YQdxYDmpUI+kK0neixA1DJYKC5KyRkKR9cgKH7cRXLLUxn/W xQPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=e18t/vscegHiMMi+HIDf2U/9dOvczVezDdLwtQR/4k0=; b=So4b7DU3i9OrX4EECeStyQEbXMyIMRVZtqEOpel6sVf9/4g2Ph23qg5gg9HWj6HANY KMX/al/vieWSk/4W5yeQ5aNQfxTqozzQGWliw4Cxd8WQEu+CLEyGqsiunLNLCRHMwQ1o DV3ogyZcLlF2kq/BQeQfg+GcrBBEnFLAVktI95g0n4Q8y0sMIKzsL8AcDyjAB0LUlQgX NLDJR9IBNhBOcER6z4YPLdmD1f+eoEi0Ypm4/qMPU/oZLvRIYuP+aZcSK/QBexYKopf5 80ukxcm2yzeFpcRAspus+gG/biZL19V8EbPPXb+qTafMJpF7kcpxbnar3G8tgJTp0UQM xVSg== X-Gm-Message-State: AN3rC/7eqt5QQrtScBsLHlU1MAEFIDhBVVkXGTFNzrVdXwymUUSVWHI0 D3dU7Fl26O9qsA== X-Received: by 10.36.22.85 with SMTP id a82mr14018334ita.83.1491855877526; Mon, 10 Apr 2017 13:24:37 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id y125sm4043225itb.4.2017.04.10.13.24.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 13:24:36 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Tim Chown , "Alvaro Retana (aretana)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , Suresh Krishnan , The IESG From: Brian E Carpenter Organization: University of Auckland Message-ID: <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> Date: Tue, 11 Apr 2017 08:24:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:24:45 -0000 Excuse front posting, but the interleaving is getting a bit distracting i= n itself. My considered opinion is that pretending to forbid "examine" is just laug= hable, since we know that middleboxes make it their job to examine packet header= s.=20 So it's pointless to state it; take it out (but leave in the reference to= 7045). The word "process" is too vague - and has been too vague since RFC 1883. So take that out too. (Clearly, a middlebox that can examine a header can process it - but so what? That doesn't affect the contents of the packet.) What we can meaningfully prohibit in the context of Internet-wide interop= is "insert, modify or delete". Regards Brian On 11/04/2017 04:09, Tim Chown wrote: > Hi Alvaro, >=20 >> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) = wrote: >> >> Tim: >> >> Hi! >> >> The initial sentence mentions 4 actions: examine, process, insert, or = delete. =20 >> >> The text already says that any node can examine the headers =E2=80=9Cf= or any reason=E2=80=9D, according to [rfc7045]. So maybe take that out a= s part of the original 4. >> >> I do have an additional clarity question. What does =E2=80=9Cprocess=E2= =80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? I=E2= =80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe Hop-= by-Hop Options header and the Destination Options header=E2=80=9D has an = option bit that indicates =E2=80=9Cwhether or not the Option Data of that= option can change en-route to the packet's final destination=E2=80=9D. = I=E2=80=99m assuming that to change the data the transit node has to not = just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook at=E2=80= =9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as well. If = to =E2=80=9Cprocess=E2=80=9D includes the ability to =E2=80=9Cchange en-r= oute=E2=80=9D, then it looks like the Destination Option may also be an e= xception=E2=80=A6 >=20 > I think most people always assumed process included inserting and remov= ing headers, but equally some people argue that strictly examining involv= es some form of processing. >=20 >> I don=E2=80=99t think your proposed text does much to clarify=E2=80=A6= at least not for me. =E2=98=B9 >=20 > It=E2=80=99s tricky, without rewriting more text than was originally de= sired. It would good for the text to be explicit, and non-contradictory.= >=20 > Tim >=20 >> >> Thanks! >> >> Alvaro. >> >> >> >> >> On 4/10/17, 4:52 AM, "Tim Chown" wrote: >> >> Hi, >> >>> On 10 Apr 2017, at 04:03, Suresh Krishnan wrote: >>> >>> Hi Alvaro, >>> Thanks for your comments. Please find responses inline. >>> >>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana wrote:= >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> Related to the above, I also want to point out the lack of clarity i= n the >>>> text in Section 4. (IPv6 Extension Headers), which leaves itself ope= n to >>>> interpretation and should be cleaned up. >>>> >>>> (A) The main piece of text that has been discussed now reads: >>>> >>>> With one exception, extension headers are not examined, processed, >>>> inserted, or deleted by any node along a packet's delivery path, >>>> until the packet reaches the node (or each of the set of nodes, in >>>> the case of multicast) identified in the Destination Address field >>>> of >>>> the IPv6 header. Note: If an intermediate forwarding node examines= >>>> an extension header for any reason, it must do so in accordance wit= h >>>> the provisions of [RFC7045]. >>>> ... >>>> The exception referred to in the preceding paragraph is the Hop-by-= >>>> Hop Options header, which carries information that may be examined >>>> and processed by every node along a packet's delivery path, >>>> including >>>> the source and destination nodes. The Hop-by-Hop Options header, >>>> when present, must immediately follow the IPv6 header. Its presenc= e >>>> is indicated by the value zero in the Next Header field of the IPv6= >>>> header. >>>> >>>> NOTE: While [RFC2460] required that all nodes must examine and >>>> process the Hop-by-Hop Options header, it is now expected that node= s >>>> along a packet's delivery path only examine and process the Hop-by-= >>>> Hop Options header if explicitly configured to do so. >>>> >>>> While the first sentence seems clear on what this document wants >>>> forwarding nodes to do (or not), there are two notes that define >>>> exceptions: any forwarding node can examine the headers "for any rea= son", >>>> and, the Hop-by-Hop Options header doesn't really have to be examine= d and >>>> processed by everyone. >>>> >>>> This text needs some more work to at least not contradict itself: th= ere >>>> is more than one exception, and they are not absolute, anyone can ex= amine >>>> the headers "for any reason=E2=80=9D=E2=80=A6 >>> >>> Right. I think the examine piece could use some rewording to merge wi= th the RFC7045 exception. >> >> One way to improve the RFC7045 =E2=80=9Ccontradiction=E2=80=9D in the = 2460-bis text would be to rearrange the text to lift out the RFC7045 refe= rence such that it follows the text about the HbH option header, adding a= n example of inspecting the payload, which is the main rationale for such= inspection stated in RFC7045.=20 >> >> Old: >> >> With one exception, extension headers are not examined, processed, >> inserted, or deleted by any node along a packet's delivery path, >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field o= f >> the IPv6 header. Note: If an intermediate forwarding node examines >> an extension header for any reason, it must do so in accordance with= >> the provisions of [RFC7045]. At the Destination node, normal >> demultiplexing on the Next Header field of the IPv6 header invokes >> the module to process the first extension header, or the upper-layer= >> header if no extension header is present. The contents and semantic= s >> of each extension header determine whether or not to proceed to the >> next header. Therefore, extension headers must be processed strictl= y >> in the order they appear in the packet; a receiver must not, for >> example, scan through a packet looking for a particular kind of >> extension header and process that header prior to processing all >> preceding ones. >> >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by every node along a packet's delivery path, includin= g >> the source and destination nodes. The Hop-by-Hop Options header, >> when present, must immediately follow the IPv6 header. Its presence= >> is indicated by the value zero in the Next Header field of the IPv6 >> header. >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes= >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >> >> New: >> >> With one exception, extension headers are not examined, processed, >> inserted, or deleted by any node along a packet's delivery path, >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field o= f >> the IPv6 header. At the Destination node, normal >> demultiplexing on the Next Header field of the IPv6 header invokes >> the module to process the first extension header, or the upper-layer= >> header if no extension header is present. The contents and semantic= s >> of each extension header determine whether or not to proceed to the >> next header. Therefore, extension headers must be processed strictl= y >> in the order they appear in the packet; a receiver must not, for >> example, scan through a packet looking for a particular kind of >> extension header and process that header prior to processing all >> preceding ones. >> >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by every node along a packet's delivery path, includin= g >> the source and destination nodes. The Hop-by-Hop Options header, >> when present, must immediately follow the IPv6 header. Its presence= >> is indicated by the value zero in the Next Header field of the IPv6 >> header. >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes= >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >> >> NOTE: If any other intermediate forwarding device needs to examine >> an extension header for any reason, e.g., to traverse the extension >> header chain to inspect the transport header of a packet, it must do= so in=20 >> accordance with the provisions of [RFC7045].=20 >> >> The question then would be the specific wording of that last paragraph= =2E >> >> Tim >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Apr 10 15:06:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1A2126CF6; Mon, 10 Apr 2017 15:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 iZqQ60CwpRzc; Mon, 10 Apr 2017 15:06:14 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8E8127333; Mon, 10 Apr 2017 15:06:14 -0700 (PDT) Received: from [IPv6:2001:1291:200:42e::2] (cl-1071.udi-01.br.sixxs.net [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E8995832CC; Tue, 11 Apr 2017 00:06:01 +0200 (CEST) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: "Alvaro Retana (aretana)" , Brian E Carpenter , The IESG , Suresh Krishnan References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <00cf4128-7c6e-7ad2-8eb9-a739c88ae13c@si6networks.com> <7ff7970f-98bb-a939-5253-33aed259e772@si6networks.com> <49f097ef-5401-d380-3823-d88f518b5c4b@gmail.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5ade9cdd-01f7-f9b0-5c1b-de26836f15fa@si6networks.com> Date: Mon, 10 Apr 2017 22:56:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 22:06:17 -0000 Alvaro, I'll top post because it seems we're arguing about unnecessary details and missing the high-order bit: 6man is meaning to progress RFC2460 to IS. RFC2460 specifies IPv6. IPv6 applies everywhere. There has never been an applicability statement for IPv6 because, by definition, it's an Internet protocol (even the name claims that!). For that reason, I think there is no need for any applicability statement, and, in fact, that would be wrong. Having a discussion in which 6man seems to have to sign a contract that EH-insertion will be "doable" seems unnecessary, off-topic, and plain wrong (since EH insertion has never been a 6man wg item, and it probably doesn't even fall within 6man's charter). I don't even know why it's being brought up in this discussion. To make the point crystal clear: a document under IESG evaluation meant to be progressed to IS is being stopped because an *individual* proposal to do EH insertion (that has never had wg consensus) would be ruled out/banned. I think that's very bad. Anything related to EH insertion is not a discussion that should take place in the context of this document, because IPv6 has never accommodated EH insertion, and what 6man is currently doing is progressing the existing IPv6 spec to IS. It seems to me that were wasting a lot of wg energy for the sake of pleasing a specific vendor. And that's bad. P.S.: (Off-topic) Funny exercise for folks playing with the idea of an applicability statement: Which std should I implement or try to comply with for, e.g., link-local traffic. -- no, not rfc2460bis, since your applicability statement would make it *not* apply for link-local traffic. (Your options are to cherry-pick what applies and what not, or publish different "versions" of IPv6, with complementary applicability statements). Thanks, Fernando On 04/10/2017 02:38 PM, Alvaro Retana (aretana) wrote: > On 4/9/17, 11:23 AM, "Brian E Carpenter" > wrote: > > Brian/Fernando: > > Hi! > > As I tried saying before, my DISCUSS is not about having this > document allow EH insertion. > > I just want the text to be clear. The fact that there is consensus > on the current text doesn’t mean that it is clear. The one thing > that is clear to me is that there are multiple ways of interpreting > the current text – and even what people say about it. > >> On 09/04/2017 23:11, Fernando Gont wrote: >>> >>> * IMO, IETF can be assumed to standardize *I* protocols which, >>> unless otherwise specified, are expected to operate over the >>> Internet. There's no need to say/clarify that. >> >> Well, I looked for that in the rules for Internet Standard (RFC >> 6410) and didn't find it. That's why I suggested adding it to >> 2460bis - exactly because the Internet Protocol is *above all* the >> standard that is expected to operate over the Internet. >> >> But if you are correct, Alvaro's DISCUSS is simply wrong: the scope >> is by definition the Internet, so by definition locally inserted or >> deleted extension headers are out of scope for this document. My >> extra words are only intended to confirm that logic. If we don't >> need them, so much the better. > > We all know that the mission of the IETF is to “make the Internet > work better” [rfc3935] – here is what I think is the relevant > definition in this case (from Section 2. (Definition of Terms)): The > Internet: A large, heterogeneous collection of interconnected systems > that can be used for communication of many different types between > any interested parties connected to it. The term includes both the > "core Internet" (ISP networks) and "edge Internet" (corporate and > private networks, often connected via firewalls, NAT boxes, > application layer gateways and similar devices). The Internet is a > truly global network, reaching into just about every country in the > world. The IETF community wants the Internet to succeed because we > believe that the existence of the Internet, and its influence on > economics, communication, and education, will help us to build a > better human society. > > > Starting from that definition, and please correct me if my > interpretation is wrong, “expected to operate over the Internet” > (from Fernando above) really points to the “core Internet”, right?? > > Yes, it is understood that the IETF works on protocols for “the > Internet”, but “the Internet” really has two parts, one of them > includes (among other things) what I’ve been calling a controlled > domain (aka private network). > > I’m then looking for a clarification on the applicability of > rfc2460bis – something like (to paraphrase Brian): this document > applies to packets intended to traverse the “core Internet”. > > I am not looking for a blanket statement about insertion/deletion of > EHs. Quoting Suresh from this thread: > > On 4/9/17, 11:03 PM, "Suresh Krishnan" > wrote: > >> => If someone comes up with a mechanism to safely do header >> insertion and documents how to do it, that document can safely >> progress. This can be done in a controlled domain as long as the >> proponents are willing to address the concerns that have been >> brought up and any breakage does not affect any unmodified nodes >> outside the controlled domain. > > For clarity, I would add that “safely progress” really means that > 6man can consider it, and if adopted and consensus is reached, then > it could be published. I agree with that. > > > Back to the original text of my DISCUSS. By saying that “Without > further clarifications and guidance, this document also brings on > unanticipated second order effects [rfc3439] that can impact the > direction, or even the viability, of future work in the IETF.” … I > meant that (without clarifying), it is very easy to assume that there > are no exceptions to what is specified in rfc2560bis. While it may > be that everyone is in wild agreement about the applicability (to the > “core Internet”) and whether others in the future can “safely > progress” a different proposal, I want it documented so we don’t have > to chase down old threads and argue about the intention of a > document… > > Thanks! > > Alvaro. > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Apr 10 21:01:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41260128D40; Mon, 10 Apr 2017 21:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 4f7F5B4FjEse; Mon, 10 Apr 2017 21:01:30 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC02A1289B5; Mon, 10 Apr 2017 21:01:29 -0700 (PDT) X-AuditID: c6180641-80136980000058cf-35-58ec0ebf0a29 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id DA.20.22735.FBE0CE85; Tue, 11 Apr 2017 01:01:19 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 00:01:28 -0400 From: Suresh Krishnan To: "ipv6@ietf.org" , The IESG CC: "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Topic: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Index: AQHSsnhL+TGQiQhuW0ybIahc30o+Yg== Date: Tue, 11 Apr 2017 04:01:27 +0000 Message-ID: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <5CB6DA6D37C4484DB18D25F3771BA722@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt+5+vjcRBm2/FS12T5nGZtG/OdZi xp+JzBYvz75ncmDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxqRfM9gK3klUHD86jb2BcY5EFyMn h4SAicSstZ9Yuxi5OIQENjBK7Nv9nR3CWc4osehdJyNIFRtQ1Yadn5m6GDk4RARsJf5scgCp YRZoYpR4NPkjE0iNsEC9xKmj55lAEiICLYwSb5ZsZgFJiAjoSVzYdYkVpJlFQFXi2rdwEJNX wF7i9SkpkApGATGJ76fWgI1hFhCXuPVkPhPEcQISS/acZ4awRSVePv7HCmKLAk2cufMvI0Rc SWLO62vMICOZBTQl1u/ShzCtJXrPa0NMVJSY0v2QHcTmFRCUODnzCcsERtFZSJbNQmiehdA8 C0nzLCTNCxhZVzFylBYX5OSmGxluYgRGyTEJNscdjHt7PQ8xCnAwKvHwLgh/HSHEmlhWXJl7 iFGCg1lJhJcn4E2EEG9KYmVValF+fFFpTmrxIUZpDhYlcd535RcihATSE0tSs1NTC1KLYLJM HJxSDYxK7lcYv/6RP3rC4dOFR2INW06cnFAclZrDt+zjiX9cC00MagVKe3Zfu/Tq8rwvStP5 1j8smBd0cRL/lFuqnS2PWM63HWE53c3S4aeXXiHJLjT1u+j11tDLBqk2q+SvLxa5KT6v9aSV /hND6VzpAG2uxjrfuU7WaU6u/oZKL76GJKtbNMhahiuxFGckGmoxFxUnAgARSq5/jgIAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 04:01:31 -0000 SGkgYWxsLA0KICBTaW5jZSB0aGlzIGRpc2N1c3Npb24gaGFzIHN0YXJ0ZWQgZGV0ZXJpb3JhdGlu ZyBpbnRvIHJlaGFzaGluZyBvZiBwcmV2aW91cyBhcmd1bWVudHMsIEkgd291bGQgbGlrZSB0byB0 cnkgdG8gdGFrZSBhIHN0ZXAgYmFjayBhbmQgbG9vayBhdCB0aGlzIGRpc2N1c3Npb24gdG8gc2Vl IGlmIHdlIGNhbiBmaW5kIHNvbWUgY29tbW9uIGdyb3VuZC4gRm9yIHRoaXMgSSB3b3VsZCBsaWtl IHRvIHN0YXJ0IGJ5IHByb3ZpZGluZyBhbiBleGFtcGxlIG9mIHNvbWV0aGluZyB0aGF0IHdhcyBj bGVhcmx5IG5vdCBhbGxvd2VkIGluIElQdjYgKGFzIG9mIFJGQzI0NjApLg0KDQpXaGVuIFJGQzI0 NjAgd2FzIHdyaXR0ZW4gemVybyBVRFAgY2hlY2tzdW1zIHdlcmUgY2xlYXJseSBkaXNhbGxvd2Vk LiBTZWUgdGhlIGZvbGxvd2luZyB0ZXh0IGluIFNlY3Rpb24gOC4xIG9mIFJGQzI0NjANCg0KVGhh dCBpcywgd2hlbmV2ZXIgb3JpZ2luYXRpbmcgYSBVRFAgcGFja2V0LCBhbiBJUHY2IG5vZGUgbXVz dCBjb21wdXRlIGEgVURQDQpjaGVja3N1bSBvdmVyIHRoZSBwYWNrZXQgYW5kIHRoZSBwc2V1ZG8t aGVhZGVyLCBhbmQsIGlmIHRoYXQNCmNvbXB1dGF0aW9uIHlpZWxkcyBhIHJlc3VsdCBvZiB6ZXJv LCBpdCBtdXN0IGJlIGNoYW5nZWQgdG8gaGV4DQpGRkZGIGZvciBwbGFjZW1lbnQgaW4gdGhlIFVE UCBoZWFkZXIuICBJUHY2IHJlY2VpdmVycyBtdXN0DQpkaXNjYXJkIFVEUCBwYWNrZXRzIGNvbnRh aW5pbmcgYSB6ZXJvIGNoZWNrc3VtLCBhbmQgc2hvdWxkIGxvZw0KdGhlIGVycm9yLg0KDQpBIGJ1 bmNoIG9mIHBlb3BsZSBmZWx0IHRoYXQgdGhpcyByZXN0cmljdGlvbiB3YXMgbm90IGFsd2F5cyBu ZWVkZWQgaW4gY2VydGFpbiBsaW1pdGVkIGVudmlyb25tZW50cyBhbmQgemVybyBVRFAgY2hlY2tz dW1zIGNvdWxkIGJlIG1hZGUgdG8gd29yayB3ZWxsIChhbmQgZXZlbiBiZSBiZW5lZmljaWFsKSBp biBzdWNoIGVudmlyb25tZW50cy4gVGhleSB3ZW50IGFoZWFkIGFuZCB3cm90ZSB1cCB0aGVpciBw cm9wb3NhbHMgZm9yIHRoZSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCBhbmQgdGhlIG1lY2hhbmlz bSBhbmQgdGhlc2Ugd2VudCB0aHJvdWdoIHRoZSA2bWFuIHByb2Nlc3MgdG8gdXBkYXRlIFJGQzI0 NjANCg0KZHJhZnQtZmFpcmh1cnN0LXRzdndnLTZtYW4tdWRwemVyby9kcmFmdC1pZXRmLTZtYW4t dWRwemVybyB0aGF0IGJlY2FtZSBSRkM2OTM2IA0KZHJhZnQtaWV0Zi02bWFuLXVkcGNoZWNrc3Vt cyBiZWNhbWUgUkZDNjkzNSBhbmQgdXBkYXRlZCBSRkMyNDYwIHRvIGFsbG93IHplcm8gVURQIGNo ZWNrc3VtIGluIHRoZSBjb250ZXh0IG9mIGFwcGxpY2FiaWxpdHkNCg0KSSBhbSBzdHJ1Z2dsaW5n IHRvIHVuZGVyc3RhbmQgd2h5IHRoaW5ncyBhcmUgYW55IGRpZmZlcmVudCBub3cgd2l0aCBoZWFk ZXIgaW5zZXJ0aW9uLiBJIGFtIGV4cGVjdGluZyB0aGUgcHJvcG9uZW50cyBvZiBoZWFkZXIgaW5z ZXJ0aW9uIHRvIGRvIGV4YWN0bHkgd2hhdCB0aGUgcHJvcG9uZW50cyBvZiB6ZXJvIFVEUCBjaGVj a3N1bXMgZGlkIGFuZCBkbyB0aGUgZ3JvdW5kd29yayBmb3IgdXBkYXRpbmcgUkZDMjQ2MGJpcy4g VGhlcmUgaXMgbm8g4oCcc3BlYWsgbm93IG9yIGZvcmV2ZXIgaG9sZCB5b3VyIHBlYWNl4oCdIG1v bWVudCBoZXJlLiBXZSBhcmUgbm90IGNsb3Npbmcgb2ZmIGFueSBhdmVudWVzIG9mIGZ1dHVyZSBl eHRlbnNpYmlsaXR5LiBUaGUgZnV0dXJlIGV4dGVuc2liaWxpdHkgcHJvcG9zYWxzIHdpbGwgYmUg anVkZ2VkIG9uIHRoZWlyIG93biBtZXJpdHMuIEdpdmVuIHRoYXQgdGhlcmUgaXMgZXhpc3RlbmNl IHByb29mLCBJIHdvdWxkIGxpa2UgdG8gYmV0dGVyIHVuZGVyc3RhbmQgd2h5IHRoaXMgc2FtZSBz dHJhdGVneSB3aWxsIG5vdCB3b3JrIGluIHRoZSBoZWFkZXIgaW5zZXJ0aW9uIGNhc2UuIEkgYmVs aWV2ZSB0aGF0IHdvdWxkIGJlIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgYSBjb25zdHJ1Y3Rp dmUgZGlzY3Vzc2lvbiBnb2luZyBmb3J3YXJkLg0KDQpUaGFua3MNClN1cmVzaA0KDQpQLlMuOiBB cyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yLCBJIGFncmVlIHdpdGggQWx2YXJvIHRoYXQgdGhl IHRleHQgYnJlYWsgcmVnYXJkaW5nIHRoZSBleGNlcHRpb24gcmVkdWNlcyB0aGUgcmVhZGFiaWxp dHkgb2YgdGhlIHRleHQuIEkgdGhpbmsgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBjYW4gYmUgZml4 ZWQgYnkgcmV3b3JkaW5nIGFzIGxvbmcgYXMgd2UgZG8gbm90IHJlb3BlbiBhbGwgZGlzY3Vzc2lv bnMgb24gYWxsIHRvcGljcyBkdWUgdG8gdGhpcyByZXdvcmRpbmcuDQoNCg0K From nobody Mon Apr 10 21:07:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5D31293FB for ; Mon, 10 Apr 2017 21:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HrhG6E1T3oRp for ; Mon, 10 Apr 2017 21:07:07 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 73B62129456 for ; Mon, 10 Apr 2017 21:07:07 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id r69so106156720vke.2 for ; Mon, 10 Apr 2017 21:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HSNgtiujFCi5ojQ1+5C/DWoa8l2TROSLHWxh8LTgIbU=; b=PH5SI1K6Jb+U9NGscUNnQbGPuu9LRKZeiFQIwOFfukZaQdSEp5EfLAxtzsdHY9bX8F tBj15ItKX685AH9hw6OzXiRMk8HiuzRJJd3sX2OYbLC6/l0B7oB5AJofKNqXRFtq57Oe iVoIyvFvTkg8LPItDtbyB9ZjyUJt+4nyvMQ1cgPTcVR365AhuhTIvCuLXmMhwEW2JMGJ VBcOXL6XbYbspOs9VLjCd+K30F7UE2SOft05kHv9n6WB94BXB98S10Cvd3qURcUWWobC mu7C3Cd4Eb/1Ztx7Cnc7foEZ5NGPJ4r7KExuqkfCqELeiO/8FVpPcGyZ5zMkLQZm15oW gp0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HSNgtiujFCi5ojQ1+5C/DWoa8l2TROSLHWxh8LTgIbU=; b=RbMrtwod1hbUOyE8DTRhEHG1uFvNwPK20wfh2nocRPgy2dxs23K3e7qzNOHr/aXuOe q2uU4xDNqRBgKLj1fcIUXlpoYJ0cCcy5FrK/kQuNMgvQeqwqk9gyiHvN1z4jT5fmbHeg Gsx3+GkVLAbONtgP/Zf1YVfrQWxG4ndM+HBM/oKuebhmpR2rfvjZsVb+v9vKvSuwKztO 0Hnh28IuROH4Cg7kuB2E7o9+MNnU6mKwAi/lMjVFCRnA5G7SaRp3Yhp65SZGwHPvK2bh LBfHRO9I3IWf3/qaWonCwotgfkpI1j3E8lQ9KEt08QAglZ2wQxF/fzMzshDkvZts5341 fhIQ== X-Gm-Message-State: AN3rC/4S+EI6sXkEbCUCy1ntTXDG7NTJHCEWT4xVgU6dZX/jLQTLpaOHZe39XgGIWIWAwAcPJBaPQHXOPwJqMLWA X-Received: by 10.31.16.200 with SMTP id 69mr5339908vkq.45.1491883626375; Mon, 10 Apr 2017 21:07:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.137.142 with HTTP; Mon, 10 Apr 2017 21:06:45 -0700 (PDT) In-Reply-To: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> From: Lorenzo Colitti Date: Tue, 11 Apr 2017 13:06:45 +0900 Message-ID: Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Suresh Krishnan Cc: "ipv6@ietf.org" , The IESG , "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary=001a11431e98991852054cdc39e1 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 04:07:10 -0000 --001a11431e98991852054cdc39e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > I am struggling to understand why things are any different now with heade= r > insertion. I am expecting the proponents of header insertion to do exactl= y > what the proponents of zero UDP checksums did and do the groundwork for > updating RFC2460bis. There is no =E2=80=9Cspeak now or forever hold your = peace=E2=80=9D > moment here. We are not closing off any avenues of future extensibility. > The future extensibility proposals will be judged on their own merits. > Given that there is existence proof, I would like to better understand wh= y > this same strategy will not work in the header insertion case. I believe > that would be a good starting point for a constructive discussion going > forward. > Hear, hear. Frankly I'm surprised we're even still talking about this. Anything we'd like to do on this topic is achievable via an update to whatever document RFC2460bis becomes. The sooner we start work on such an update, the sooner it will be published. --001a11431e98991852054cdc39e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan <suresh.krishnan@= ericsson.com> wrote:
I am s= truggling to understand why things are any different now with header insert= ion. I am expecting the proponents of header insertion to do exactly what t= he proponents of zero UDP checksums did and do the groundwork for updating = RFC2460bis. There is no =E2=80=9Cspeak now or forever hold your peace=E2=80= =9D moment here. We are not closing off any avenues of future extensibility= . The future extensibility proposals will be judged on their own merits. Gi= ven that there is existence proof, I would like to better understand why th= is same strategy will not work in the header insertion case. I believe that= would be a good starting point for a constructive discussion going forward= .

Hear, hear. Frankly I'm surprised= we're even still talking about this. Anything we'd like to do on t= his topic is achievable via an update to whatever document RFC2460bis becom= es. The sooner we start work on such an update, the sooner it will be publi= shed.
--001a11431e98991852054cdc39e1-- From nobody Tue Apr 11 00:11:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0721129407; Tue, 11 Apr 2017 00:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Koy89HLXW7md; Tue, 11 Apr 2017 00:11:42 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9961292D3; Tue, 11 Apr 2017 00:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13984; q=dns/txt; s=iport; t=1491894701; x=1493104301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Q8buotyZ51VL8+GZtDcVRi9Z0riekzKKp8dY4VXArA=; b=Ui8QteyDdds5nCHxiyxsVAchQVIBfLyIuuV2XUAMrqk2pcLIm1fRuewG RxVscVjoD6GgCrrQE1v6UODa+ZnuhQcGOeZdjmiRcpW49v3vnNmIj05ed FqGMQIXcB91jRvVPqgn/s5HU6VKBLCQraxwMv6VU7Yu284J+iT/00V4LZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAgC+gOxY/4MNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5EqH4gajT6CDyELhXgCGoNPPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhETMHCwULAgEGAhgCAiYCAgIfBgsVEAIEDgWJeAMNCA6LH?= =?us-ascii?q?J1dgiaHLw2DRAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFRYIFCYJiglGCBRc?= =?us-ascii?q?hAoJMLoIxAQSJJZMdOwGKKoNxhD+Bf4UuihWLAIh/AR84gQVbFUERAYR+gUp1A?= =?us-ascii?q?YhHgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,184,1488844800"; d="scan'208";a="410356942" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2017 07:11:40 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3B7BeT4019216 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 07:11:40 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 03:11:39 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 03:11:39 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: Tim Chown , "Alvaro Retana (aretana)" , "draft-ietf-6man-rfc2460bis@ietf.org" , The IESG , 6man WG , Suresh Krishnan , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSspLddTBRWP+GFUef/sTsplW2vg== Date: Tue, 11 Apr 2017 07:11:39 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> In-Reply-To: <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.83.87] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:11:45 -0000 DQo+IE9uIEFwciAxMCwgMjAxNywgYXQgMTA6MjQgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gRXhjdXNlIGZyb250IHBvc3Rp bmcsIGJ1dCB0aGUgaW50ZXJsZWF2aW5nIGlzIGdldHRpbmcgYSBiaXQgZGlzdHJhY3RpbmcgaW4g aXRzZWxmLg0KPiANCj4gTXkgY29uc2lkZXJlZCBvcGluaW9uIGlzIHRoYXQgcHJldGVuZGluZyB0 byBmb3JiaWQgImV4YW1pbmUiIGlzIGp1c3QgbGF1Z2hhYmxlLA0KPiBzaW5jZSB3ZSBrbm93IHRo YXQgbWlkZGxlYm94ZXMgbWFrZSBpdCB0aGVpciBqb2IgdG8gZXhhbWluZSBwYWNrZXQgaGVhZGVy cy4gDQo+IFNvIGl0J3MgcG9pbnRsZXNzIHRvIHN0YXRlIGl0OyB0YWtlIGl0IG91dCAoYnV0IGxl YXZlIGluIHRoZSByZWZlcmVuY2UgdG8gNzA0NSkuDQo+IA0KPiBUaGUgd29yZCAicHJvY2VzcyIg aXMgdG9vIHZhZ3VlIC0gYW5kIGhhcyBiZWVuIHRvbyB2YWd1ZSBzaW5jZSBSRkMgMTg4My4NCj4g U28gdGFrZSB0aGF0IG91dCB0b28uIChDbGVhcmx5LCBhIG1pZGRsZWJveCB0aGF0IGNhbiBleGFt aW5lIGEgaGVhZGVyDQo+IGNhbiBwcm9jZXNzIGl0IC0gYnV0IHNvIHdoYXQ/IFRoYXQgZG9lc24n dCBhZmZlY3QgdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPiBwYWNrZXQuKQ0KPiANCj4gV2hhdCB3ZSBj YW4gbWVhbmluZ2Z1bGx5IHByb2hpYml0IGluIHRoZSBjb250ZXh0IG9mIEludGVybmV0LXdpZGUg aW50ZXJvcA0KPiBpcyAiaW5zZXJ0LCBtb2RpZnkgb3IgZGVsZXRl4oCdLg0KDQoNCndlIGRvbuKA mXQgaGF2ZSBhIGRlZmluaXRpb24gb2Yg4oCcaW50ZXJuZXQtd2lkZeKAnSBhbmQgd2UgbWF5IHdl bGwgZW5kIHVwIGluIGFub3RoZXIgbG9vcCB0eWluZyB0byBhZ3JlZSB3aGF0IGl0IG1lYW5zLg0K DQpUaGUgc2ltcGxlc3QgYXBwcm9hY2ggaXMgdG8gYWRkIGFuIGV4Y2VwdGlvbiB3aGljaCBjb25z aXN0cyBvZiBhIGNvbnRyb2xsZWQvY2xvc2VkIGRvbWFpbiAoZm9yIHdoaWNoIHdlIGRvIGhhdmUg YSBkZWZpbml0aW9uKS4NCg0Kcy4NCg0KDQo+IA0KPiBSZWdhcmRzDQo+ICAgQnJpYW4NCj4gDQo+ IA0KPiBPbiAxMS8wNC8yMDE3IDA0OjA5LCBUaW0gQ2hvd24gd3JvdGU6DQo+PiBIaSBBbHZhcm8s DQo+PiANCj4+PiBPbiAxMCBBcHIgMjAxNywgYXQgMTQ6NTMsIEFsdmFybyBSZXRhbmEgKGFyZXRh bmEpIDxhcmV0YW5hQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gVGltOg0KPj4+IA0KPj4+ IEhpIQ0KPj4+IA0KPj4+IFRoZSBpbml0aWFsIHNlbnRlbmNlIG1lbnRpb25zIDQgYWN0aW9uczog ZXhhbWluZSwgcHJvY2VzcywgaW5zZXJ0LCBvciBkZWxldGUuICANCj4+PiANCj4+PiBUaGUgdGV4 dCBhbHJlYWR5IHNheXMgdGhhdCBhbnkgbm9kZSBjYW4gZXhhbWluZSB0aGUgaGVhZGVycyDigJxm b3IgYW55IHJlYXNvbuKAnSwgYWNjb3JkaW5nIHRvIFtyZmM3MDQ1XS4gIFNvIG1heWJlIHRha2Ug dGhhdCBvdXQgYXMgcGFydCBvZiB0aGUgb3JpZ2luYWwgNC4NCj4+PiANCj4+PiBJIGRvIGhhdmUg YW4gYWRkaXRpb25hbCBjbGFyaXR5IHF1ZXN0aW9uLiAgV2hhdCBkb2VzIOKAnHByb2Nlc3PigJ0g bWVhbj8gIERvZXMgaXQgaW5jbHVkZSBhIOKAnGNoYW5nZSBlbi1yb3V0ZeKAnT8gICAgSeKAmW0g YXNraW5nIGJlY2F1c2UgU2VjdGlvbiA0LjIuIChPcHRpb25zKSBzYXlzIHRoYXQg4oCcdGhlIEhv cC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIgYW5kIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRl cuKAnSBoYXMgYW4gb3B0aW9uIGJpdCB0aGF0IGluZGljYXRlcyDigJx3aGV0aGVyIG9yIG5vdCB0 aGUgT3B0aW9uIERhdGEgb2YgdGhhdCBvcHRpb24gY2FuIGNoYW5nZSBlbi1yb3V0ZSB0byB0aGUg cGFja2V0J3MgZmluYWwgZGVzdGluYXRpb27igJ0uICBJ4oCZbSBhc3N1bWluZyB0aGF0IHRvIGNo YW5nZSB0aGUgZGF0YSB0aGUgdHJhbnNpdCBub2RlIGhhcyB0byBub3QganVzdCDigJxleGFtaW5l 4oCdICh3aGljaCBJIHRoaW5rIG1lYW5zIOKAnGxvb2sgYXTigJ0pLCBidXQgYWxzbyAoYXQgbGVh c3QpIOKAnHByb2Nlc3PigJ0gdGhlIEVIIGFzIHdlbGwuICAgSWYgdG8g4oCccHJvY2Vzc+KAnSBp bmNsdWRlcyB0aGUgYWJpbGl0eSB0byDigJxjaGFuZ2UgZW4tcm91dGXigJ0sIHRoZW4gaXQgbG9v a3MgbGlrZSB0aGUgRGVzdGluYXRpb24gT3B0aW9uIG1heSBhbHNvIGJlIGFuIGV4Y2VwdGlvbuKA pg0KPj4gDQo+PiBJIHRoaW5rIG1vc3QgcGVvcGxlIGFsd2F5cyBhc3N1bWVkIHByb2Nlc3MgaW5j bHVkZWQgaW5zZXJ0aW5nIGFuZCByZW1vdmluZyBoZWFkZXJzLCBidXQgZXF1YWxseSBzb21lIHBl b3BsZSBhcmd1ZSB0aGF0IHN0cmljdGx5IGV4YW1pbmluZyBpbnZvbHZlcyBzb21lIGZvcm0gb2Yg cHJvY2Vzc2luZy4NCj4+IA0KPj4+IEkgZG9u4oCZdCB0aGluayB5b3VyIHByb3Bvc2VkIHRleHQg ZG9lcyBtdWNoIHRvIGNsYXJpZnnigKZhdCBsZWFzdCBub3QgZm9yIG1lLiDimLkNCj4+IA0KPj4g SXTigJlzIHRyaWNreSwgd2l0aG91dCByZXdyaXRpbmcgbW9yZSB0ZXh0IHRoYW4gd2FzIG9yaWdp bmFsbHkgZGVzaXJlZC4gIEl0IHdvdWxkIGdvb2QgZm9yIHRoZSB0ZXh0IHRvIGJlIGV4cGxpY2l0 LCBhbmQgbm9uLWNvbnRyYWRpY3RvcnkuDQo+PiANCj4+IFRpbQ0KPj4gDQo+Pj4gDQo+Pj4gVGhh bmtzIQ0KPj4+IA0KPj4+IEFsdmFyby4NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+PiBPbiA0 LzEwLzE3LCA0OjUyIEFNLCAiVGltIENob3duIiA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3Rl Og0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+PiBPbiAxMCBBcHIgMjAxNywgYXQgMDQ6MDMsIFN1 cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4+ IA0KPj4+PiBIaSBBbHZhcm8sDQo+Pj4+IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNl IGZpbmQgcmVzcG9uc2VzIGlubGluZS4NCj4+Pj4gDQo+Pj4+PiBPbiBBcHIgNywgMjAxNywgYXQg MjozOSBQTSwgQWx2YXJvIFJldGFuYSA8YXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4g DQo+Pj4+PiA9PT09PT09PT09DQo+Pj4+PiANCj4+Pj4+IFJlbGF0ZWQgdG8gdGhlIGFib3ZlLCBJ IGFsc28gd2FudCB0byBwb2ludCBvdXQgdGhlIGxhY2sgb2YgY2xhcml0eSBpbiB0aGUNCj4+Pj4+ IHRleHQgaW4gU2VjdGlvbiA0LiAoSVB2NiBFeHRlbnNpb24gSGVhZGVycyksIHdoaWNoIGxlYXZl cyBpdHNlbGYgb3BlbiB0bw0KPj4+Pj4gaW50ZXJwcmV0YXRpb24gYW5kIHNob3VsZCBiZSBjbGVh bmVkIHVwLg0KPj4+Pj4gDQo+Pj4+PiAoQSkgIFRoZSBtYWluIHBpZWNlIG9mIHRleHQgdGhhdCBo YXMgYmVlbiBkaXNjdXNzZWQgbm93IHJlYWRzOg0KPj4+Pj4gDQo+Pj4+PiBXaXRoIG9uZSBleGNl cHRpb24sIGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBub3QgZXhhbWluZWQsIHByb2Nlc3NlZCwNCj4+ Pj4+IGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVs aXZlcnkgcGF0aCwNCj4+Pj4+IHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3Ig ZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KPj4+Pj4gdGhlIGNhc2Ugb2YgbXVsdGljYXN0 KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkDQo+Pj4+PiBvZg0K Pj4+Pj4gdGhlIElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRp bmcgbm9kZSBleGFtaW5lcw0KPj4+Pj4gYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNv biwgaXQgbXVzdCBkbyBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCj4+Pj4+IHRoZSBwcm92aXNpb25z IG9mIFtSRkM3MDQ1XS4NCj4+Pj4+IC4uLg0KPj4+Pj4gVGhlIGV4Y2VwdGlvbiByZWZlcnJlZCB0 byBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFwaCBpcyB0aGUgSG9wLWJ5LQ0KPj4+Pj4gSG9wIE9w dGlvbnMgaGVhZGVyLCB3aGljaCBjYXJyaWVzIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1p bmVkDQo+Pj4+PiBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBk ZWxpdmVyeSBwYXRoLA0KPj4+Pj4gaW5jbHVkaW5nDQo+Pj4+PiB0aGUgc291cmNlIGFuZCBkZXN0 aW5hdGlvbiBub2Rlcy4gIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLA0KPj4+Pj4gd2hl biBwcmVzZW50LCBtdXN0IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJdHMg cHJlc2VuY2UNCj4+Pj4+IGlzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgemVybyBpbiB0aGUgTmV4 dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYNCj4+Pj4+IGhlYWRlci4NCj4+Pj4+IA0KPj4+Pj4g Tk9URTogV2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgZXhhbWlu ZSBhbmQNCj4+Pj4+IHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlz IG5vdyBleHBlY3RlZCB0aGF0IG5vZGVzDQo+Pj4+PiBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5 IHBhdGggb25seSBleGFtaW5lIGFuZCBwcm9jZXNzIHRoZSBIb3AtYnktDQo+Pj4+PiBIb3AgT3B0 aW9ucyBoZWFkZXIgaWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KPj4+Pj4gDQo+ Pj4+PiBXaGlsZSB0aGUgZmlyc3Qgc2VudGVuY2Ugc2VlbXMgY2xlYXIgb24gd2hhdCB0aGlzIGRv Y3VtZW50IHdhbnRzDQo+Pj4+PiBmb3J3YXJkaW5nIG5vZGVzIHRvIGRvIChvciBub3QpLCB0aGVy ZSBhcmUgdHdvIG5vdGVzIHRoYXQgZGVmaW5lDQo+Pj4+PiBleGNlcHRpb25zOiBhbnkgZm9yd2Fy ZGluZyBub2RlIGNhbiBleGFtaW5lIHRoZSBoZWFkZXJzICJmb3IgYW55IHJlYXNvbiIsDQo+Pj4+ PiBhbmQsIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIGRvZXNuJ3QgcmVhbGx5IGhhdmUg dG8gYmUgZXhhbWluZWQgYW5kDQo+Pj4+PiBwcm9jZXNzZWQgYnkgZXZlcnlvbmUuDQo+Pj4+PiAN Cj4+Pj4+IFRoaXMgdGV4dCBuZWVkcyBzb21lIG1vcmUgd29yayB0byBhdCBsZWFzdCBub3QgY29u dHJhZGljdCBpdHNlbGY6IHRoZXJlDQo+Pj4+PiBpcyBtb3JlIHRoYW4gb25lIGV4Y2VwdGlvbiwg YW5kIHRoZXkgYXJlIG5vdCBhYnNvbHV0ZSwgYW55b25lIGNhbiBleGFtaW5lDQo+Pj4+PiB0aGUg aGVhZGVycyAiZm9yIGFueSByZWFzb27igJ3igKYNCj4+Pj4gDQo+Pj4+IFJpZ2h0LiBJIHRoaW5r IHRoZSBleGFtaW5lIHBpZWNlIGNvdWxkIHVzZSBzb21lIHJld29yZGluZyB0byBtZXJnZSB3aXRo IHRoZSBSRkM3MDQ1IGV4Y2VwdGlvbi4NCj4+PiANCj4+PiBPbmUgd2F5IHRvIGltcHJvdmUgdGhl IFJGQzcwNDUg4oCcY29udHJhZGljdGlvbuKAnSBpbiB0aGUgMjQ2MC1iaXMgdGV4dCB3b3VsZCBi ZSB0byByZWFycmFuZ2UgdGhlIHRleHQgdG8gbGlmdCBvdXQgdGhlIFJGQzcwNDUgcmVmZXJlbmNl IHN1Y2ggdGhhdCBpdCBmb2xsb3dzIHRoZSB0ZXh0IGFib3V0IHRoZSBIYkggb3B0aW9uIGhlYWRl ciwgYWRkaW5nIGFuIGV4YW1wbGUgb2YgaW5zcGVjdGluZyB0aGUgcGF5bG9hZCwgd2hpY2ggaXMg dGhlIG1haW4gcmF0aW9uYWxlIGZvciBzdWNoIGluc3BlY3Rpb24gc3RhdGVkIGluIFJGQzcwNDUu IA0KPj4+IA0KPj4+IE9sZDoNCj4+PiANCj4+PiAgV2l0aCBvbmUgZXhjZXB0aW9uLCBleHRlbnNp b24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQo+Pj4gIGluc2VydGVkLCBv ciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4+ PiAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQg b2Ygbm9kZXMsIGluDQo+Pj4gIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0 aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KPj4+ICB0aGUgSVB2NiBoZWFkZXIuICBO b3RlOiBJZiBhbiBpbnRlcm1lZGlhdGUgZm9yd2FyZGluZyBub2RlIGV4YW1pbmVzDQo+Pj4gIGFu IGV4dGVuc2lvbiBoZWFkZXIgZm9yIGFueSByZWFzb24sIGl0IG11c3QgZG8gc28gaW4gYWNjb3Jk YW5jZSB3aXRoDQo+Pj4gIHRoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4gIEF0IHRoZSBEZXN0 aW5hdGlvbiBub2RlLCBub3JtYWwNCj4+PiAgZGVtdWx0aXBsZXhpbmcgb24gdGhlIE5leHQgSGVh ZGVyIGZpZWxkIG9mIHRoZSBJUHY2IGhlYWRlciBpbnZva2VzDQo+Pj4gIHRoZSBtb2R1bGUgdG8g cHJvY2VzcyB0aGUgZmlyc3QgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVwcGVyLWxheWVyDQo+ Pj4gIGhlYWRlciBpZiBubyBleHRlbnNpb24gaGVhZGVyIGlzIHByZXNlbnQuICBUaGUgY29udGVu dHMgYW5kIHNlbWFudGljcw0KPj4+ICBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXIgZGV0ZXJtaW5l IHdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgdG8gdGhlDQo+Pj4gIG5leHQgaGVhZGVyLiAgVGhl cmVmb3JlLCBleHRlbnNpb24gaGVhZGVycyBtdXN0IGJlIHByb2Nlc3NlZCBzdHJpY3RseQ0KPj4+ ICBpbiB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4gdGhlIHBhY2tldDsgYSByZWNlaXZlciBtdXN0 IG5vdCwgZm9yDQo+Pj4gIGV4YW1wbGUsIHNjYW4gdGhyb3VnaCBhIHBhY2tldCBsb29raW5nIGZv ciBhIHBhcnRpY3VsYXIga2luZCBvZg0KPj4+ICBleHRlbnNpb24gaGVhZGVyIGFuZCBwcm9jZXNz IHRoYXQgaGVhZGVyIHByaW9yIHRvIHByb2Nlc3NpbmcgYWxsDQo+Pj4gIHByZWNlZGluZyBvbmVz Lg0KPj4+IA0KPj4+ICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRvIGluIHRoZSBwcmVjZWRpbmcg cGFyYWdyYXBoIGlzIHRoZSBIb3AtYnktDQo+Pj4gIEhvcCBPcHRpb25zIGhlYWRlciwgd2hpY2gg Y2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBleGFtaW5lZA0KPj4+ICBhbmQgcHJvY2Vz c2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoLCBpbmNsdWRp bmcNCj4+PiAgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbm9kZXMuICBUaGUgSG9wLWJ5LUhv cCBPcHRpb25zIGhlYWRlciwNCj4+PiAgd2hlbiBwcmVzZW50LCBtdXN0IGltbWVkaWF0ZWx5IGZv bGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJdHMgcHJlc2VuY2UNCj4+PiAgaXMgaW5kaWNhdGVkIGJ5 IHRoZSB2YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2Ng0KPj4+ ICBoZWFkZXIuDQo+Pj4gDQo+Pj4gIE5PVEU6IFdoaWxlIFtSRkMyNDYwXSByZXF1aXJlZCB0aGF0 IGFsbCBub2RlcyBtdXN0IGV4YW1pbmUgYW5kDQo+Pj4gIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3Ag T3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBleHBlY3RlZCB0aGF0IG5vZGVzDQo+Pj4gIGFsb25n IGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1pbmUgYW5kIHByb2Nlc3MgdGhlIEhv cC1ieS0NCj4+PiAgSG9wIE9wdGlvbnMgaGVhZGVyIGlmIGV4cGxpY2l0bHkgY29uZmlndXJlZCB0 byBkbyBzby4NCj4+PiANCj4+PiBOZXc6DQo+Pj4gDQo+Pj4gIFdpdGggb25lIGV4Y2VwdGlvbiwg ZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KPj4+ICBpbnNl cnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBh dGgsDQo+Pj4gIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0 aGUgc2V0IG9mIG5vZGVzLCBpbg0KPj4+ICB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpIGlkZW50aWZp ZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YNCj4+PiAgdGhlIElQdjYgaGVh ZGVyLiAgQXQgdGhlIERlc3RpbmF0aW9uIG5vZGUsIG5vcm1hbA0KPj4+ICBkZW11bHRpcGxleGlu ZyBvbiB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMNCj4+ PiAgdGhlIG1vZHVsZSB0byBwcm9jZXNzIHRoZSBmaXJzdCBleHRlbnNpb24gaGVhZGVyLCBvciB0 aGUgdXBwZXItbGF5ZXINCj4+PiAgaGVhZGVyIGlmIG5vIGV4dGVuc2lvbiBoZWFkZXIgaXMgcHJl c2VudC4gIFRoZSBjb250ZW50cyBhbmQgc2VtYW50aWNzDQo+Pj4gIG9mIGVhY2ggZXh0ZW5zaW9u IGhlYWRlciBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUNCj4+PiAg bmV4dCBoZWFkZXIuICBUaGVyZWZvcmUsIGV4dGVuc2lvbiBoZWFkZXJzIG11c3QgYmUgcHJvY2Vz c2VkIHN0cmljdGx5DQo+Pj4gIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUgcGFja2V0 OyBhIHJlY2VpdmVyIG11c3Qgbm90LCBmb3INCj4+PiAgZXhhbXBsZSwgc2NhbiB0aHJvdWdoIGEg cGFja2V0IGxvb2tpbmcgZm9yIGEgcGFydGljdWxhciBraW5kIG9mDQo+Pj4gIGV4dGVuc2lvbiBo ZWFkZXIgYW5kIHByb2Nlc3MgdGhhdCBoZWFkZXIgcHJpb3IgdG8gcHJvY2Vzc2luZyBhbGwNCj4+ PiAgcHJlY2VkaW5nIG9uZXMuDQo+Pj4gDQo+Pj4gIFRoZSBleGNlcHRpb24gcmVmZXJyZWQgdG8g aW4gdGhlIHByZWNlZGluZyBwYXJhZ3JhcGggaXMgdGhlIEhvcC1ieS0NCj4+PiAgSG9wIE9wdGlv bnMgaGVhZGVyLCB3aGljaCBjYXJyaWVzIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1pbmVk DQo+Pj4gIGFuZCBwcm9jZXNzZWQgYnkgZXZlcnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRlbGl2 ZXJ5IHBhdGgsIGluY2x1ZGluZw0KPj4+ICB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBub2Rl cy4gIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLA0KPj4+ICB3aGVuIHByZXNlbnQsIG11 c3QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBJUHY2IGhlYWRlci4gIEl0cyBwcmVzZW5jZQ0KPj4+ ICBpcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIHplcm8gaW4gdGhlIE5leHQgSGVhZGVyIGZpZWxk IG9mIHRoZSBJUHY2DQo+Pj4gIGhlYWRlci4NCj4+PiANCj4+PiAgTk9URTogV2hpbGUgW1JGQzI0 NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgZXhhbWluZSBhbmQNCj4+PiAgcHJvY2Vz cyB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwgaXQgaXMgbm93IGV4cGVjdGVkIHRoYXQg bm9kZXMNCj4+PiAgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBwYXRoIG9ubHkgZXhhbWluZSBh bmQgcHJvY2VzcyB0aGUgSG9wLWJ5LQ0KPj4+ICBIb3AgT3B0aW9ucyBoZWFkZXIgaWYgZXhwbGlj aXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KPj4+IA0KPj4+ICBOT1RFOiBJZiBhbnkgb3RoZXIg aW50ZXJtZWRpYXRlIGZvcndhcmRpbmcgZGV2aWNlIG5lZWRzIHRvIGV4YW1pbmUNCj4+PiAgYW4g ZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgZS5nLiwgdG8gdHJhdmVyc2UgdGhlIGV4 dGVuc2lvbg0KPj4+ICBoZWFkZXIgY2hhaW4gdG8gaW5zcGVjdCB0aGUgdHJhbnNwb3J0IGhlYWRl ciBvZiBhIHBhY2tldCwgaXQgbXVzdCBkbyBzbyBpbiANCj4+PiAgYWNjb3JkYW5jZSB3aXRoIHRo ZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4gDQo+Pj4gDQo+Pj4gVGhlIHF1ZXN0aW9uIHRoZW4g d291bGQgYmUgdGhlIHNwZWNpZmljIHdvcmRpbmcgb2YgdGhhdCBsYXN0IHBhcmFncmFwaC4NCj4+ PiANCj4+PiBUaW0NCj4+PiANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQo= From nobody Tue Apr 11 05:03:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3A12948F; Tue, 11 Apr 2017 05:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CbE6TQv1oqG0; Tue, 11 Apr 2017 05:02:59 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 0E3E6129488; Tue, 11 Apr 2017 05:02:59 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id q26so54210315uaa.0; Tue, 11 Apr 2017 05:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l7HMgjHTqTQNXHZzdnwhPfKdOcqFhd7YJgQl8cAovj4=; b=lnQd3BDPHqiz2Vtv6kpMJBgqZ1NA5WvLf7CM1ZaXa4TjcFEM31TSdWWGhT2zBQiIxx ewPotcO1Q5egacg5WmK/n3NGdnTtpMYmwsquA3NlcaV9kWooj89IG+d9BCJvqSCPMjz5 axWDXJs/tUK6/jguCazE1E66XzicljD5S9FrCRXye2qDA7lL/55KpsBSXvkQg87z5Xx9 dTzb/9qyS5giXhmTNsPrMIWcrVC+gNlCP91qW5l5+gh3eCHsyLHOJ8sYFYkAlPgvhPaS 53BiceO4LtABRocQ+t5bOvCBeA1gu90R3J9dzv+7ZuXa68dRWIB1hemq4RSXUZikoFq9 ueyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l7HMgjHTqTQNXHZzdnwhPfKdOcqFhd7YJgQl8cAovj4=; b=a7SnkNTVtWGWAAE7CfdzHERzpJdYPhDVg4J9ZbjDEDvjL7I/sZDfr9qpB6dks5fhd3 IKfOpmuuE/bcSiivuHfu2r3EYxVfMYu3DaYFycffIbbNVMbTIzf0/Q2TWH4vwF6c3XjI atg9sqX677CDcjlRbMLHp4i4NI3fiGqbr/+jM31RdEAh1jbQLsIYoVZ1TxyZouKnlknR LQVUSnkaXsHZB/r0kceesS7l20aBoGkwlhFwspI69nb80mr6oskFRju737Fwpf+4pgWu YgXLx4DMyRxn7w0Al8JpWliwcNIgtlsfo/iET59YFdUDnhMdLpLQJ6ZPJum/QfYnfPc6 LcRQ== X-Gm-Message-State: AFeK/H0Rwdg7LtNfbGdcnPgAGPnEqeDEyoLvJs5T6TP/Va42m70eaYIER2bPgtKC6Uag+xpdsLycEnkbVrunmw== X-Received: by 10.176.3.212 with SMTP id 78mr30872847uau.97.1491912177981; Tue, 11 Apr 2017 05:02:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 11 Apr 2017 05:02:27 -0700 (PDT) In-Reply-To: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> From: Mark Smith Date: Tue, 11 Apr 2017 22:02:27 +1000 Message-ID: Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: "Stefano Previdi (sprevidi)" Cc: The IESG , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary=94eb2c05e17c67a0fa054ce2df02 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 12:03:03 -0000 --94eb2c05e17c67a0fa054ce2df02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 Apr. 2017 5:11 pm, "Stefano Previdi (sprevidi)" wrote: > On Apr 10, 2017, at 10:24 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Excuse front posting, but the interleaving is getting a bit distracting in itself. > > My considered opinion is that pretending to forbid "examine" is just laughable, > since we know that middleboxes make it their job to examine packet headers. > So it's pointless to state it; take it out (but leave in the reference to 7045). > > The word "process" is too vague - and has been too vague since RFC 1883. > So take that out too. (Clearly, a middlebox that can examine a header > can process it - but so what? That doesn't affect the contents of the > packet.) > > What we can meaningfully prohibit in the context of Internet-wide interop > is "insert, modify or delete=E2=80=9D. we don=E2=80=99t have a definition of =E2=80=9Cinternet-wide=E2=80=9D and w= e may well end up in another loop tying to agree what it means. I think we do. In IPv6 devices that are given 2000::/3 addresses are part of the IPv6 Internet. Are you going to limit EH insertion to packets that only have ULA and Link-Local addresses? How will that be policed to prevent people trying to use EH insertion on packets with 2000::/3 addresses? The simplest approach is to add an exception which consists of a controlled/closed domain (for which we do have a definition). Yet one that we know from RFC1918s and private network route leaks only exist in theory. The misuse of 1/8 as a private network demonstrates how "private" traffic leaks outside closed domains that are attached to the Internet. http://www.potaroo.net/studies/1slash8/1slash8.html You spec could state that packets that have had EHs inserted MUST have them removed, however in practice, they may not be removed because of implementation bugs, device misconfiguration or partial device failure. This failure to remove them will not be visible to the domain that added them, because there are no local SR domain consequences of that failure. Other receivers may suffer the consequences, yet there is nothing to indicate in the packet which device or domain inserted the EH. Consider this scenario, using an AS boundaries as a EH insertion domain boundaries, with the packet travelling left to right, and this being a path across the Internet. Imagine being at one of the ASes upstream of one or both of the EH insertion ASes, trying to work out which one inserted the EH and didn't remove it successfully. [pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS ASY]--[AS3]--[AS4]--[pkt dst AS] To make this example more visceral, imagine [pkt src AS] is a residential ISP who has with 10 of 000s of customers failing to access a streaming VoD provider at [pkt dst AS]. Those angry customers will be ringing [pkt src AS]'s helpdesk, increasing their support costs, market reputation and possibly cost them customers, and [pkt dst AS] will be losing reputation, revenue and possibly customers while this troubleshooting is going on. Regards, Mark. s. > > Regards > Brian > > > On 11/04/2017 04:09, Tim Chown wrote: >> Hi Alvaro, >> >>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) wrote: >>> >>> Tim: >>> >>> Hi! >>> >>> The initial sentence mentions 4 actions: examine, process, insert, or delete. >>> >>> The text already says that any node can examine the headers =E2=80=9Cfo= r any reason=E2=80=9D, according to [rfc7045]. So maybe take that out as part of= the original 4. >>> >>> I do have an additional clarity question. What does =E2=80=9Cprocess= =E2=80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? I=E2=80=99m asking = because Section 4.2. (Options) says that =E2=80=9Cthe Hop-by-Hop Options header and the Destinat= ion Options header=E2=80=9D has an option bit that indicates =E2=80=9Cwhether o= r not the Option Data of that option can change en-route to the packet's final destination=E2=80=9D. I=E2=80=99m assuming that to change the data the tra= nsit node has to not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook at=E2= =80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as well. If to =E2=80=9Cprocess=E2=80=9D= includes the ability to =E2=80=9Cchange en-route=E2=80=9D, then it looks like the Destination Option may also be an exception=E2=80=A6 >> >> I think most people always assumed process included inserting and removing headers, but equally some people argue that strictly examining involves some form of processing. >> >>> I don=E2=80=99t think your proposed text does much to clarify=E2=80=A6a= t least not for me. =E2=98=B9 >> >> It=E2=80=99s tricky, without rewriting more text than was originally des= ired. It would good for the text to be explicit, and non-contradictory. >> >> Tim >> >>> >>> Thanks! >>> >>> Alvaro. >>> >>> >>> >>> >>> On 4/10/17, 4:52 AM, "Tim Chown" wrote: >>> >>> Hi, >>> >>>> On 10 Apr 2017, at 04:03, Suresh Krishnan wrote: >>>> >>>> Hi Alvaro, >>>> Thanks for your comments. Please find responses inline. >>>> >>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana wrote: >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> Related to the above, I also want to point out the lack of clarity in the >>>>> text in Section 4. (IPv6 Extension Headers), which leaves itself open to >>>>> interpretation and should be cleaned up. >>>>> >>>>> (A) The main piece of text that has been discussed now reads: >>>>> >>>>> With one exception, extension headers are not examined, processed, >>>>> inserted, or deleted by any node along a packet's delivery path, >>>>> until the packet reaches the node (or each of the set of nodes, in >>>>> the case of multicast) identified in the Destination Address field >>>>> of >>>>> the IPv6 header. Note: If an intermediate forwarding node examines >>>>> an extension header for any reason, it must do so in accordance with >>>>> the provisions of [RFC7045]. >>>>> ... >>>>> The exception referred to in the preceding paragraph is the Hop-by- >>>>> Hop Options header, which carries information that may be examined >>>>> and processed by every node along a packet's delivery path, >>>>> including >>>>> the source and destination nodes. The Hop-by-Hop Options header, >>>>> when present, must immediately follow the IPv6 header. Its presence >>>>> is indicated by the value zero in the Next Header field of the IPv6 >>>>> header. >>>>> >>>>> NOTE: While [RFC2460] required that all nodes must examine and >>>>> process the Hop-by-Hop Options header, it is now expected that nodes >>>>> along a packet's delivery path only examine and process the Hop-by- >>>>> Hop Options header if explicitly configured to do so. >>>>> >>>>> While the first sentence seems clear on what this document wants >>>>> forwarding nodes to do (or not), there are two notes that define >>>>> exceptions: any forwarding node can examine the headers "for any reason", >>>>> and, the Hop-by-Hop Options header doesn't really have to be examined and >>>>> processed by everyone. >>>>> >>>>> This text needs some more work to at least not contradict itself: there >>>>> is more than one exception, and they are not absolute, anyone can examine >>>>> the headers "for any reason=E2=80=9D=E2=80=A6 >>>> >>>> Right. I think the examine piece could use some rewording to merge with the RFC7045 exception. >>> >>> One way to improve the RFC7045 =E2=80=9Ccontradiction=E2=80=9D in the 2= 460-bis text would be to rearrange the text to lift out the RFC7045 reference such that it follows the text about the HbH option header, adding an example of inspecting the payload, which is the main rationale for such inspection stated in RFC7045. >>> >>> Old: >>> >>> With one exception, extension headers are not examined, processed, >>> inserted, or deleted by any node along a packet's delivery path, >>> until the packet reaches the node (or each of the set of nodes, in >>> the case of multicast) identified in the Destination Address field of >>> the IPv6 header. Note: If an intermediate forwarding node examines >>> an extension header for any reason, it must do so in accordance with >>> the provisions of [RFC7045]. At the Destination node, normal >>> demultiplexing on the Next Header field of the IPv6 header invokes >>> the module to process the first extension header, or the upper-layer >>> header if no extension header is present. The contents and semantics >>> of each extension header determine whether or not to proceed to the >>> next header. Therefore, extension headers must be processed strictly >>> in the order they appear in the packet; a receiver must not, for >>> example, scan through a packet looking for a particular kind of >>> extension header and process that header prior to processing all >>> preceding ones. >>> >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that may be examined >>> and processed by every node along a packet's delivery path, including >>> the source and destination nodes. The Hop-by-Hop Options header, >>> when present, must immediately follow the IPv6 header. Its presence >>> is indicated by the value zero in the Next Header field of the IPv6 >>> header. >>> >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>> >>> New: >>> >>> With one exception, extension headers are not examined, processed, >>> inserted, or deleted by any node along a packet's delivery path, >>> until the packet reaches the node (or each of the set of nodes, in >>> the case of multicast) identified in the Destination Address field of >>> the IPv6 header. At the Destination node, normal >>> demultiplexing on the Next Header field of the IPv6 header invokes >>> the module to process the first extension header, or the upper-layer >>> header if no extension header is present. The contents and semantics >>> of each extension header determine whether or not to proceed to the >>> next header. Therefore, extension headers must be processed strictly >>> in the order they appear in the packet; a receiver must not, for >>> example, scan through a packet looking for a particular kind of >>> extension header and process that header prior to processing all >>> preceding ones. >>> >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that may be examined >>> and processed by every node along a packet's delivery path, including >>> the source and destination nodes. The Hop-by-Hop Options header, >>> when present, must immediately follow the IPv6 header. Its presence >>> is indicated by the value zero in the Next Header field of the IPv6 >>> header. >>> >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>> >>> NOTE: If any other intermediate forwarding device needs to examine >>> an extension header for any reason, e.g., to traverse the extension >>> header chain to inspect the transport header of a packet, it must do so in >>> accordance with the provisions of [RFC7045]. >>> >>> The question then would be the specific wording of that last paragraph. >>> >>> Tim >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --94eb2c05e17c67a0fa054ce2df02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=
On 11 Apr. 2017 5:11 pm, "Stefano Previdi (= sprevidi)" <sprevidi@cisco.com> wrote:

> On Apr 10, 2017, at 10:24 PM, Brian E Carpenter <brian.e.carpenter@gmail.com<= /a>> wrote:
>
> Excuse front posting, but the interleaving is getting a bit distractin= g in itself.
>
> My considered opinion is that pretending to forbid "examine"= is just laughable,
> since we know that middleboxes make it their job to examine packet hea= ders.
> So it's pointless to state it; take it out (but leave in the refer= ence to 7045).
>
> The word "process" is too vague - and has been too vague sin= ce RFC 1883.
> So take that out too. (Clearly, a middlebox that can examine a header<= br> > can process it - but so what? That doesn't affect the contents of = the
> packet.)
>
> What we can meaningfully prohibit in the context of Internet-wide inte= rop
> is "insert, modify or delete=E2=80=9D.


we don=E2=80=99t have a definition of =E2=80=9Cinternet-wide=E2=80=9D= and we may well end up in another loop tying to agree what it means.



=

The simplest approach is to add an exception which consists of a controlled= /closed domain (for which we do have a definition).
<= /div>

Yet one that we kn= ow from RFC1918s and private network route leaks only exist in theory.

The misuse of 1/8 as a priva= te network demonstrates how "private" traffic leaks outside close= d domains that are attached to the Internet.



You spec could state that packets that have had EHs i= nserted MUST have them removed, however in practice, they may not be remove= d because of implementation bugs, device misconfiguration or partial device= failure.

This failure t= o remove them will not be visible to the domain that added them, because th= ere are no local SR domain consequences of that failure. Other receivers ma= y suffer the consequences, yet there is nothing to indicate in the packet w= hich device or domain inserted the EH.

Consider this scenario, using an AS boundaries as a EH inser= tion domain boundaries, with the packet travelling left to right, and this = being a path across the Internet. Imagine being at one of the ASes upstream= of one or both of the EH insertion ASes, trying to work out which one inse= rted the EH and didn't remove it successfully.

[pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[E= H INS ASY]--[AS3]--[AS4]--[pkt dst AS]

To make this example more visceral, imagine [pkt src AS] is a residen= tial ISP who has with 10 of 000s of customers failing to access a streaming= VoD provider at=C2=A0[pkt dst AS]. Those angry customers will be ringing [= pkt src AS]'s helpdesk, increasing their support costs, market reputati= on and possibly cost them customers, and [pkt dst AS] will be losing reputa= tion, revenue and possibly customers while this troubleshooting is going on= .


Regards,
Mark.


=

s.


>
> Regards
>=C2=A0 =C2=A0Brian
>
>
> On 11/04/2017 04:09, Tim Chown wrote:
>> Hi Alvaro,
>>
>>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) <aretana@cisco.com> w= rote:
>>>
>>> Tim:
>>>
>>> Hi!
>>>
>>> The initial sentence mentions 4 actions: examine, process, ins= ert, or delete.
>>>
>>> The text already says that any node can examine the headers = =E2=80=9Cfor any reason=E2=80=9D, according to [rfc7045].=C2=A0 So maybe ta= ke that out as part of the original 4.
>>>
>>> I do have an additional clarity question.=C2=A0 What does =E2= =80=9Cprocess=E2=80=9D mean?=C2=A0 Does it include a =E2=80=9Cchange en-rou= te=E2=80=9D?=C2=A0 =C2=A0 I=E2=80=99m asking because Section 4.2. (Options)= says that =E2=80=9Cthe Hop-by-Hop Options header and the Destination Optio= ns header=E2=80=9D has an option bit that indicates =E2=80=9Cwhether or not= the Option Data of that option can change en-route to the packet's fin= al destination=E2=80=9D.=C2=A0 I=E2=80=99m assuming that to change the data= the transit node has to not just =E2=80=9Cexamine=E2=80=9D (which I think = means =E2=80=9Clook at=E2=80=9D), but also (at least) =E2=80=9Cprocess=E2= =80=9D the EH as well.=C2=A0 =C2=A0If to =E2=80=9Cprocess=E2=80=9D includes= the ability to =E2=80=9Cchange en-route=E2=80=9D, then it looks like the D= estination Option may also be an exception=E2=80=A6
>>
>> I think most people always assumed process included inserting and = removing headers, but equally some people argue that strictly examining inv= olves some form of processing.
>>
>>> I don=E2=80=99t think your proposed text does much to clarify= =E2=80=A6at least not for me. =E2=98=B9
>>
>> It=E2=80=99s tricky, without rewriting more text than was original= ly desired.=C2=A0 It would good for the text to be explicit, and non-contra= dictory.
>>
>> Tim
>>
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>>>
>>>
>>>
>>> On 4/10/17, 4:52 AM, "Tim Chown" <Tim.Chown@jisc.ac.uk> wro= te:
>>>
>>> Hi,
>>>
>>>> On 10 Apr 2017, at 04:03, Suresh Krishnan <suresh.krishnan@erics= son.com> wrote:
>>>>
>>>> Hi Alvaro,
>>>> Thanks for your comments. Please find responses inline. >>>>
>>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana <aretana@cisco.com> w= rote:
>>>>>
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>
>>>>> Related to the above, I also want to point out the lac= k of clarity in the
>>>>> text in Section 4. (IPv6 Extension Headers), which lea= ves itself open to
>>>>> interpretation and should be cleaned up.
>>>>>
>>>>> (A)=C2=A0 The main piece of text that has been discuss= ed now reads:
>>>>>
>>>>> With one exception, extension headers are not examined= , processed,
>>>>> inserted, or deleted by any node along a packet's = delivery path,
>>>>> until the packet reaches the node (or each of the set = of nodes, in
>>>>> the case of multicast) identified in the Destination A= ddress field
>>>>> of
>>>>> the IPv6 header.=C2=A0 Note: If an intermediate forwar= ding node examines
>>>>> an extension header for any reason, it must do so in a= ccordance with
>>>>> the provisions of [RFC7045].
>>>>> ...
>>>>> The exception referred to in the preceding paragraph i= s the Hop-by-
>>>>> Hop Options header, which carries information that may= be examined
>>>>> and processed by every node along a packet's deliv= ery path,
>>>>> including
>>>>> the source and destination nodes.=C2=A0 The Hop-by-Hop= Options header,
>>>>> when present, must immediately follow the IPv6 header.= =C2=A0 Its presence
>>>>> is indicated by the value zero in the Next Header fiel= d of the IPv6
>>>>> header.
>>>>>
>>>>> NOTE: While [RFC2460] required that all nodes must exa= mine and
>>>>> process the Hop-by-Hop Options header, it is now expec= ted that nodes
>>>>> along a packet's delivery path only examine and pr= ocess the Hop-by-
>>>>> Hop Options header if explicitly configured to do so.<= br> >>>>>
>>>>> While the first sentence seems clear on what this docu= ment wants
>>>>> forwarding nodes to do (or not), there are two notes t= hat define
>>>>> exceptions: any forwarding node can examine the header= s "for any reason",
>>>>> and, the Hop-by-Hop Options header doesn't really = have to be examined and
>>>>> processed by everyone.
>>>>>
>>>>> This text needs some more work to at least not contrad= ict itself: there
>>>>> is more than one exception, and they are not absolute,= anyone can examine
>>>>> the headers "for any reason=E2=80=9D=E2=80=A6
>>>>
>>>> Right. I think the examine piece could use some rewording = to merge with the RFC7045 exception.
>>>
>>> One way to improve the RFC7045 =E2=80=9Ccontradiction=E2=80=9D= in the 2460-bis text would be to rearrange the text to lift out the RFC704= 5 reference such that it follows the text about the HbH option header, addi= ng an example of inspecting the payload, which is the main rationale for su= ch inspection stated in RFC7045.
>>>
>>> Old:
>>>
>>>=C2=A0 With one exception, extension headers are not examined, = processed,
>>>=C2=A0 inserted, or deleted by any node along a packet's de= livery path,
>>>=C2=A0 until the packet reaches the node (or each of the set of= nodes, in
>>>=C2=A0 the case of multicast) identified in the Destination Add= ress field of
>>>=C2=A0 the IPv6 header.=C2=A0 Note: If an intermediate forwardi= ng node examines
>>>=C2=A0 an extension header for any reason, it must do so in acc= ordance with
>>>=C2=A0 the provisions of [RFC7045].=C2=A0 At the Destination no= de, normal
>>>=C2=A0 demultiplexing on the Next Header field of the IPv6 head= er invokes
>>>=C2=A0 the module to process the first extension header, or the= upper-layer
>>>=C2=A0 header if no extension header is present.=C2=A0 The cont= ents and semantics
>>>=C2=A0 of each extension header determine whether or not to pro= ceed to the
>>>=C2=A0 next header.=C2=A0 Therefore, extension headers must be = processed strictly
>>>=C2=A0 in the order they appear in the packet; a receiver must = not, for
>>>=C2=A0 example, scan through a packet looking for a particular = kind of
>>>=C2=A0 extension header and process that header prior to proces= sing all
>>>=C2=A0 preceding ones.
>>>
>>>=C2=A0 The exception referred to in the preceding paragraph is = the Hop-by-
>>>=C2=A0 Hop Options header, which carries information that may b= e examined
>>>=C2=A0 and processed by every node along a packet's deliver= y path, including
>>>=C2=A0 the source and destination nodes.=C2=A0 The Hop-by-Hop O= ptions header,
>>>=C2=A0 when present, must immediately follow the IPv6 header.= =C2=A0 Its presence
>>>=C2=A0 is indicated by the value zero in the Next Header field = of the IPv6
>>>=C2=A0 header.
>>>
>>>=C2=A0 NOTE: While [RFC2460] required that all nodes must exami= ne and
>>>=C2=A0 process the Hop-by-Hop Options header, it is now expecte= d that nodes
>>>=C2=A0 along a packet's delivery path only examine and proc= ess the Hop-by-
>>>=C2=A0 Hop Options header if explicitly configured to do so. >>>
>>> New:
>>>
>>>=C2=A0 With one exception, extension headers are not examined, = processed,
>>>=C2=A0 inserted, or deleted by any node along a packet's de= livery path,
>>>=C2=A0 until the packet reaches the node (or each of the set of= nodes, in
>>>=C2=A0 the case of multicast) identified in the Destination Add= ress field of
>>>=C2=A0 the IPv6 header.=C2=A0 At the Destination node, normal >>>=C2=A0 demultiplexing on the Next Header field of the IPv6 head= er invokes
>>>=C2=A0 the module to process the first extension header, or the= upper-layer
>>>=C2=A0 header if no extension header is present.=C2=A0 The cont= ents and semantics
>>>=C2=A0 of each extension header determine whether or not to pro= ceed to the
>>>=C2=A0 next header.=C2=A0 Therefore, extension headers must be = processed strictly
>>>=C2=A0 in the order they appear in the packet; a receiver must = not, for
>>>=C2=A0 example, scan through a packet looking for a particular = kind of
>>>=C2=A0 extension header and process that header prior to proces= sing all
>>>=C2=A0 preceding ones.
>>>
>>>=C2=A0 The exception referred to in the preceding paragraph is = the Hop-by-
>>>=C2=A0 Hop Options header, which carries information that may b= e examined
>>>=C2=A0 and processed by every node along a packet's deliver= y path, including
>>>=C2=A0 the source and destination nodes.=C2=A0 The Hop-by-Hop O= ptions header,
>>>=C2=A0 when present, must immediately follow the IPv6 header.= =C2=A0 Its presence
>>>=C2=A0 is indicated by the value zero in the Next Header field = of the IPv6
>>>=C2=A0 header.
>>>
>>>=C2=A0 NOTE: While [RFC2460] required that all nodes must exami= ne and
>>>=C2=A0 process the Hop-by-Hop Options header, it is now expecte= d that nodes
>>>=C2=A0 along a packet's delivery path only examine and proc= ess the Hop-by-
>>>=C2=A0 Hop Options header if explicitly configured to do so. >>>
>>>=C2=A0 NOTE: If any other intermediate forwarding device needs = to examine
>>>=C2=A0 an extension header for any reason, e.g., to traverse th= e extension
>>>=C2=A0 header chain to inspect the transport header of a packet= , it must do so in
>>>=C2=A0 accordance with the provisions of [RFC7045].
>>>
>>> The question then would be the specific wording of that last p= aragraph.
>>>
>>> Tim
>>>
>>
>> ------------------------------------------------------------<= wbr>--------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------<= wbr>--------
>>
>
> ------------------------------------------------------------= --------
> IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------

-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

--94eb2c05e17c67a0fa054ce2df02-- From nobody Tue Apr 11 05:48:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B513E129B71; Tue, 11 Apr 2017 05:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 kcd0t9biG6eo; Tue, 11 Apr 2017 05:47:55 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EF91201F2; Tue, 11 Apr 2017 05:47:48 -0700 (PDT) Received: from [192.168.1.187] (host-79-79-21-8.static.as13285.net [79.79.21.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C8EA68094B; Tue, 11 Apr 2017 14:47:45 +0200 (CEST) Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Suresh Krishnan , "ipv6@ietf.org" , The IESG References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Fernando Gont Message-ID: <8e750e8f-d1e7-c19f-0a3c-d6a0a6614ce5@si6networks.com> Date: Tue, 11 Apr 2017 13:47:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 12:47:58 -0000 Suresh, I appreciate your email below, and even agree with it. My question is: why are we having this dicsussion durig IESG review? Thanks, Fernando On 04/11/2017 05:01 AM, Suresh Krishnan wrote: > Hi all, > Since this discussion has started deteriorating into rehashing of previous arguments, I would like to try to take a step back and look at this discussion to see if we can find some common ground. For this I would like to start by providing an example of something that was clearly not allowed in IPv6 (as of RFC2460). > > When RFC2460 was written zero UDP checksums were clearly disallowed. See the following text in Section 8.1 of RFC2460 > > That is, whenever originating a UDP packet, an IPv6 node must compute a UDP > checksum over the packet and the pseudo-header, and, if that > computation yields a result of zero, it must be changed to hex > FFFF for placement in the UDP header. IPv6 receivers must > discard UDP packets containing a zero checksum, and should log > the error. > > A bunch of people felt that this restriction was not always needed in certain limited environments and zero UDP checksums could be made to work well (and even be beneficial) in such environments. They went ahead and wrote up their proposals for the Applicability Statement and the mechanism and these went through the 6man process to update RFC2460 > > draft-fairhurst-tsvwg-6man-udpzero/draft-ietf-6man-udpzero that became RFC6936 > draft-ietf-6man-udpchecksums became RFC6935 and updated RFC2460 to allow zero UDP checksum in the context of applicability > > I am struggling to understand why things are any different now with header insertion. I am expecting the proponents of header insertion to do exactly what the proponents of zero UDP checksums did and do the groundwork for updating RFC2460bis. There is no “speak now or forever hold your peace” moment here. We are not closing off any avenues of future extensibility. The future extensibility proposals will be judged on their own merits. Given that there is existence proof, I would like to better understand why this same strategy will not work in the header insertion case. I believe that would be a good starting point for a constructive discussion going forward. > > Thanks > Suresh > > P.S.: As an individual contributor, I agree with Alvaro that the text break regarding the exception reduces the readability of the text. I think this is something that can be fixed by rewording as long as we do not reopen all discussions on all topics due to this rewording. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 11 06:39:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5672129B9E; Tue, 11 Apr 2017 06:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 BHJpFbL-RfGW; Tue, 11 Apr 2017 06:39:08 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 BD57A129BBD; Tue, 11 Apr 2017 06:39:07 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id h41so310608ioi.1; Tue, 11 Apr 2017 06:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Fm4yDhHhCOMvjbALRgyHmhYCInqTqcp88N2FnYYwm5Y=; b=UPYj66f2N7C4YawoREnZrYh2SK2gUdIyxVq/hodYmt1vKv/xIxwN7Ys9L2+7Npp+/5 mNitEb2oHHL1v/KUMtRH05yePBAFP3q7z1+W6o2fg147bmb/S5EXLe2emN9etk/aBnkz uC3tyZZ9sLjqETtkg9TUrcSnvTGFRcbkWqkELZBxMhzNPaFeBjdvPpe4LJHqEyN+HnD0 OgXdwdqGySZmWa8eCXxdqz0/riBBAsTputPcaZ1rGgJYfWOxo9AIIWug/NAkrsa7ydh1 svZ63ba2Y6R/8IlWw/7/zDA6Gs6ZhE2ceyzNv2s1DcLWLpT4bESmtjh8VBxklRpZLIvr 3zUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Fm4yDhHhCOMvjbALRgyHmhYCInqTqcp88N2FnYYwm5Y=; b=W9Rm4DdDaI2hTf3nGwVTs9RZYGwvv1AvRRTBed1S0zilwM2rU9RO5GvNOaQZHgdIN+ wtf+kJ8X8mMXB8BFDXaCTHvGe36Tjb+Dy8SmEzcoMdT52vTi24l3bY4zQXoaiXgcUwyp Dpytq20L8KpA6C2rRPxSaCfAZzvBAXxtC2Lj5YXY7rhrEuQe3F6HBOVvi099gOvLeO0g esNVPdVZiurQepKHqJUKV++Sz8RN93stXxLffPxtwe3rQpqDRTvmCGZH9xOj8qxN+ovz 2CjkvbEYvNFtJBAa4ucM+aTKQI70BtS6sBpszVQpelhkypm/DnhFyV+KnTCvemT4nqu7 IIrQ== X-Gm-Message-State: AN3rC/7nZt+J64HdGmIgupzTUjWbIWBgsbt9CWrM50xqjtnGoDzF/A3/ NccP0GqTJXxvow== X-Received: by 10.36.36.131 with SMTP id f125mr17766277ita.45.1491917946895; Tue, 11 Apr 2017 06:39:06 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m41sm906465iti.0.2017.04.11.06.39.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 06:39:06 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: "Stefano Previdi (sprevidi)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> Cc: Tim Chown , "Alvaro Retana (aretana)" , "draft-ietf-6man-rfc2460bis@ietf.org" , The IESG , 6man WG , Suresh Krishnan , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <935698ca-d56d-adf8-c3d9-c8ea9fa07989@gmail.com> Date: Wed, 12 Apr 2017 01:39:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:39:11 -0000 On 11/04/2017 19:11, Stefano Previdi (sprevidi) wrote: >=20 >> On Apr 10, 2017, at 10:24 PM, Brian E Carpenter wrote: >> >> Excuse front posting, but the interleaving is getting a bit distractin= g in itself. >> >> My considered opinion is that pretending to forbid "examine" is just l= aughable, >> since we know that middleboxes make it their job to examine packet hea= ders.=20 >> So it's pointless to state it; take it out (but leave in the reference= to 7045). >> >> The word "process" is too vague - and has been too vague since RFC 188= 3. >> So take that out too. (Clearly, a middlebox that can examine a header >> can process it - but so what? That doesn't affect the contents of the >> packet.) >> >> What we can meaningfully prohibit in the context of Internet-wide inte= rop >> is "insert, modify or delete=E2=80=9D. >=20 >=20 > we don=E2=80=99t have a definition of =E2=80=9Cinternet-wide=E2=80=9D a= nd we may well end up in another loop tying to agree what it means. >=20 > The simplest approach is to add an exception which consists of a contro= lled/closed domain (for which we do have a definition). Unfortunately, we don't, as I discovered when I proposed such an approach to allow local use of the IPv6 Flow Label. "Internet-wide" on the other hand seems completely clear to me. Any node to any node. Brian >=20 > s. >=20 >=20 >> >> Regards >> Brian >> >> >> On 11/04/2017 04:09, Tim Chown wrote: >>> Hi Alvaro, >>> >>>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) wrote: >>>> >>>> Tim: >>>> >>>> Hi! >>>> >>>> The initial sentence mentions 4 actions: examine, process, insert, o= r delete. =20 >>>> >>>> The text already says that any node can examine the headers =E2=80=9C= for any reason=E2=80=9D, according to [rfc7045]. So maybe take that out = as part of the original 4. >>>> >>>> I do have an additional clarity question. What does =E2=80=9Cproces= s=E2=80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe= Hop-by-Hop Options header and the Destination Options header=E2=80=9D ha= s an option bit that indicates =E2=80=9Cwhether or not the Option Data of= that option can change en-route to the packet's final destination=E2=80=9D= =2E I=E2=80=99m assuming that to change the data the transit node has to= not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook at= =E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as well.= If to =E2=80=9Cprocess=E2=80=9D includes the ability to =E2=80=9Cchang= e en-route=E2=80=9D, then it looks like the Destination Option may also b= e an exception=E2=80=A6 >>> >>> I think most people always assumed process included inserting and rem= oving headers, but equally some people argue that strictly examining invo= lves some form of processing. >>> >>>> I don=E2=80=99t think your proposed text does much to clarify=E2=80=A6= at least not for me. =E2=98=B9 >>> >>> It=E2=80=99s tricky, without rewriting more text than was originally = desired. It would good for the text to be explicit, and non-contradictor= y. >>> >>> Tim >>> >>>> >>>> Thanks! >>>> >>>> Alvaro. >>>> >>>> >>>> >>>> >>>> On 4/10/17, 4:52 AM, "Tim Chown" wrote: >>>> >>>> Hi, >>>> >>>>> On 10 Apr 2017, at 04:03, Suresh Krishnan wrote: >>>>> >>>>> Hi Alvaro, >>>>> Thanks for your comments. Please find responses inline. >>>>> >>>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana wrot= e: >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> >>>>>> Related to the above, I also want to point out the lack of clarity= in the >>>>>> text in Section 4. (IPv6 Extension Headers), which leaves itself o= pen to >>>>>> interpretation and should be cleaned up. >>>>>> >>>>>> (A) The main piece of text that has been discussed now reads: >>>>>> >>>>>> With one exception, extension headers are not examined, processed,= >>>>>> inserted, or deleted by any node along a packet's delivery path, >>>>>> until the packet reaches the node (or each of the set of nodes, in= >>>>>> the case of multicast) identified in the Destination Address field= >>>>>> of >>>>>> the IPv6 header. Note: If an intermediate forwarding node examine= s >>>>>> an extension header for any reason, it must do so in accordance wi= th >>>>>> the provisions of [RFC7045]. >>>>>> ... >>>>>> The exception referred to in the preceding paragraph is the Hop-by= - >>>>>> Hop Options header, which carries information that may be examined= >>>>>> and processed by every node along a packet's delivery path, >>>>>> including >>>>>> the source and destination nodes. The Hop-by-Hop Options header, >>>>>> when present, must immediately follow the IPv6 header. Its presen= ce >>>>>> is indicated by the value zero in the Next Header field of the IPv= 6 >>>>>> header. >>>>>> >>>>>> NOTE: While [RFC2460] required that all nodes must examine and >>>>>> process the Hop-by-Hop Options header, it is now expected that nod= es >>>>>> along a packet's delivery path only examine and process the Hop-by= - >>>>>> Hop Options header if explicitly configured to do so. >>>>>> >>>>>> While the first sentence seems clear on what this document wants >>>>>> forwarding nodes to do (or not), there are two notes that define >>>>>> exceptions: any forwarding node can examine the headers "for any r= eason", >>>>>> and, the Hop-by-Hop Options header doesn't really have to be exami= ned and >>>>>> processed by everyone. >>>>>> >>>>>> This text needs some more work to at least not contradict itself: = there >>>>>> is more than one exception, and they are not absolute, anyone can = examine >>>>>> the headers "for any reason=E2=80=9D=E2=80=A6 >>>>> >>>>> Right. I think the examine piece could use some rewording to merge = with the RFC7045 exception. >>>> >>>> One way to improve the RFC7045 =E2=80=9Ccontradiction=E2=80=9D in th= e 2460-bis text would be to rearrange the text to lift out the RFC7045 re= ference such that it follows the text about the HbH option header, adding= an example of inspecting the payload, which is the main rationale for su= ch inspection stated in RFC7045.=20 >>>> >>>> Old: >>>> >>>> With one exception, extension headers are not examined, processed, >>>> inserted, or deleted by any node along a packet's delivery path, >>>> until the packet reaches the node (or each of the set of nodes, in >>>> the case of multicast) identified in the Destination Address field = of >>>> the IPv6 header. Note: If an intermediate forwarding node examines= >>>> an extension header for any reason, it must do so in accordance wit= h >>>> the provisions of [RFC7045]. At the Destination node, normal >>>> demultiplexing on the Next Header field of the IPv6 header invokes >>>> the module to process the first extension header, or the upper-laye= r >>>> header if no extension header is present. The contents and semanti= cs >>>> of each extension header determine whether or not to proceed to the= >>>> next header. Therefore, extension headers must be processed strict= ly >>>> in the order they appear in the packet; a receiver must not, for >>>> example, scan through a packet looking for a particular kind of >>>> extension header and process that header prior to processing all >>>> preceding ones. >>>> >>>> The exception referred to in the preceding paragraph is the Hop-by-= >>>> Hop Options header, which carries information that may be examined >>>> and processed by every node along a packet's delivery path, includi= ng >>>> the source and destination nodes. The Hop-by-Hop Options header, >>>> when present, must immediately follow the IPv6 header. Its presenc= e >>>> is indicated by the value zero in the Next Header field of the IPv6= >>>> header. >>>> >>>> NOTE: While [RFC2460] required that all nodes must examine and >>>> process the Hop-by-Hop Options header, it is now expected that node= s >>>> along a packet's delivery path only examine and process the Hop-by-= >>>> Hop Options header if explicitly configured to do so. >>>> >>>> New: >>>> >>>> With one exception, extension headers are not examined, processed, >>>> inserted, or deleted by any node along a packet's delivery path, >>>> until the packet reaches the node (or each of the set of nodes, in >>>> the case of multicast) identified in the Destination Address field = of >>>> the IPv6 header. At the Destination node, normal >>>> demultiplexing on the Next Header field of the IPv6 header invokes >>>> the module to process the first extension header, or the upper-laye= r >>>> header if no extension header is present. The contents and semanti= cs >>>> of each extension header determine whether or not to proceed to the= >>>> next header. Therefore, extension headers must be processed strict= ly >>>> in the order they appear in the packet; a receiver must not, for >>>> example, scan through a packet looking for a particular kind of >>>> extension header and process that header prior to processing all >>>> preceding ones. >>>> >>>> The exception referred to in the preceding paragraph is the Hop-by-= >>>> Hop Options header, which carries information that may be examined >>>> and processed by every node along a packet's delivery path, includi= ng >>>> the source and destination nodes. The Hop-by-Hop Options header, >>>> when present, must immediately follow the IPv6 header. Its presenc= e >>>> is indicated by the value zero in the Next Header field of the IPv6= >>>> header. >>>> >>>> NOTE: While [RFC2460] required that all nodes must examine and >>>> process the Hop-by-Hop Options header, it is now expected that node= s >>>> along a packet's delivery path only examine and process the Hop-by-= >>>> Hop Options header if explicitly configured to do so. >>>> >>>> NOTE: If any other intermediate forwarding device needs to examine >>>> an extension header for any reason, e.g., to traverse the extension= >>>> header chain to inspect the transport header of a packet, it must d= o so in=20 >>>> accordance with the provisions of [RFC7045].=20 >>>> >>>> The question then would be the specific wording of that last paragra= ph. >>>> >>>> Tim >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Apr 11 06:40:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3462A129BCE; Tue, 11 Apr 2017 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 FCJtff096Crx; Tue, 11 Apr 2017 06:40:37 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 510D0129BBE; Tue, 11 Apr 2017 06:40:37 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id t68so310018iof.2; Tue, 11 Apr 2017 06:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1wGL3SHAoN3o2zNycGrHO7iDoA6Ue4Nu25InLZb9Oe0=; b=dOPXYAsbbF8dLBlRRHYm5hR1lEbMGrFDk0J/Ox3fH90N6h13st21rY05Yo6Np/UILN M2iRe3tNm8Ww7K3QzvmYe0KLNBa7gfBALo0nRYC/w42y7uPBALq+HLN6KZK6xBuqvx7o MIY7ONdqnszUDiaT5sLknR1R8DrY1Idm5mK6W3z/e3URbiEPCSZip65qplwadsSo0kTY T2y7L51tYJJImb/sVatEezG94enuSbEWbMpZUa9Ayj04dxlB/WQ58r7KLHnSH2/wBjbg dM/tVAxTK7U8jOeLWEzCvRm+ufLu9gtJWjp1jNEP1ULtEAYKwtqyhSo2Ah5Wi2aZLUPz Vdow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1wGL3SHAoN3o2zNycGrHO7iDoA6Ue4Nu25InLZb9Oe0=; b=DKAQfXW6w10/LfmERkZHGMk/lwwji0PRHmWGZi0SE52Cn4Z2purHjLB1z6WZGQMPE6 0MuvTnSaeIZZ+McP19Z9ER4vHOSvOrSm06hl/1unjsZ4sFEyVa0qtlSlxCQRDHFWyZuw B+txZEuEFoxU5URfdLWGynz1iDbb/6iC9jfSaTdqYxWjHXzOvR9ORIjkIbTPCJnApPCL R+51zZKDve1aAUnNjWSsD/3yQfokgnLJlbgzBg81J1EEeV4jSBRdzG7uD/vUaOlCYK+R DUP044/SmZIKP27tADwQzZNGMARE4zkSPgT9bRZbyTZ89Hy9kKzA+nwG9wFLVR/v0+R3 8nDA== X-Gm-Message-State: AN3rC/7gkAVdlWf+tBIbxFHqszBgNhzeSfsJnrUlPTk6m16lly65gr+B wGOk495oUd8qHbDI X-Received: by 10.36.40.81 with SMTP id h78mr17621536ith.44.1491918036620; Tue, 11 Apr 2017 06:40:36 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id h68sm4344170iod.27.2017.04.11.06.40.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 06:40:36 -0700 (PDT) Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Lorenzo Colitti , Suresh Krishnan References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 12 Apr 2017 01:40:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:40:40 -0000 On 11/04/2017 16:06, Lorenzo Colitti wrote: > On Tue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan < > suresh.krishnan@ericsson.com> wrote: >=20 >> I am struggling to understand why things are any different now with he= ader >> insertion. I am expecting the proponents of header insertion to do exa= ctly >> what the proponents of zero UDP checksums did and do the groundwork fo= r >> updating RFC2460bis. There is no =E2=80=9Cspeak now or forever hold yo= ur peace=E2=80=9D >> moment here. We are not closing off any avenues of future extensibilit= y. >> The future extensibility proposals will be judged on their own merits.= >> Given that there is existence proof, I would like to better understand= why >> this same strategy will not work in the header insertion case. I belie= ve >> that would be a good starting point for a constructive discussion goin= g >> forward. >> >=20 > Hear, hear. Frankly I'm surprised we're even still talking about this. > Anything we'd like to do on this topic is achievable via an update to > whatever document RFC2460bis becomes. The sooner we start work on such = an > update, the sooner it will be published. Violent agreement. Brian From nobody Tue Apr 11 08:35:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17D12EAB0; Tue, 11 Apr 2017 08:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 FCAGCvNSN_be; Tue, 11 Apr 2017 08:35:15 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC52612EAAA; Tue, 11 Apr 2017 08:35:14 -0700 (PDT) Received: from [192.168.1.187] (host-79-79-21-8.static.as13285.net [79.79.21.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BE18C80A75; Tue, 11 Apr 2017 17:35:12 +0200 (CEST) Subject: COntrolled-domains (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Brian E Carpenter , "Stefano Previdi (sprevidi)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> <935698ca-d56d-adf8-c3d9-c8ea9fa07989@gmail.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , Suresh Krishnan , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 11 Apr 2017 16:33:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <935698ca-d56d-adf8-c3d9-c8ea9fa07989@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:35:17 -0000 On 04/11/2017 02:39 PM, Brian E Carpenter wrote: > On 11/04/2017 19:11, Stefano Previdi (sprevidi) wrote: >> >>> On Apr 10, 2017, at 10:24 PM, Brian E Carpenter wrote: >>> >>> Excuse front posting, but the interleaving is getting a bit distracting in itself. >>> >>> My considered opinion is that pretending to forbid "examine" is just laughable, >>> since we know that middleboxes make it their job to examine packet headers. >>> So it's pointless to state it; take it out (but leave in the reference to 7045). >>> >>> The word "process" is too vague - and has been too vague since RFC 1883. >>> So take that out too. (Clearly, a middlebox that can examine a header >>> can process it - but so what? That doesn't affect the contents of the >>> packet.) >>> >>> What we can meaningfully prohibit in the context of Internet-wide interop >>> is "insert, modify or delete”. >> >> >> we don’t have a definition of “internet-wide” and we may well end up in another loop tying to agree what it means. >> >> The simplest approach is to add an exception which consists of a controlled/closed domain (for which we do have a definition). > > Unfortunately, we don't, as I discovered when I proposed such an > approach to allow local use of the IPv6 Flow Label. "Internet-wide" > on the other hand seems completely clear to me. Any node to any node. My understanding is that the "controlled domains" that R people talk about is a different thing: they talk about controlled domains regarding who inserts/removes EHs, rather than src/dst addresses of th packets. If packets still have internet-wide srd/dst addresses, then packets require internet-wide interoperability. P.S.: This is a side comment -- as noted before, I'm against "applicability statements" on rfc2460 for a bunch of reasons. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 11 08:35:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6412EACB; Tue, 11 Apr 2017 08:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 9th16tqUHzdd; Tue, 11 Apr 2017 08:35:18 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEC812EAAA; Tue, 11 Apr 2017 08:35:18 -0700 (PDT) Received: from [192.168.1.187] (host-79-79-21-8.static.as13285.net [79.79.21.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B1A8C80ABA; Tue, 11 Apr 2017 17:35:15 +0200 (CEST) Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Brian E Carpenter , Lorenzo Colitti , Suresh Krishnan References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Fernando Gont Message-ID: <851f242c-921f-933f-3bd3-7e2c82ac052c@si6networks.com> Date: Tue, 11 Apr 2017 16:35:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 15:35:25 -0000 On 04/11/2017 02:40 PM, Brian E Carpenter wrote: > On 11/04/2017 16:06, Lorenzo Colitti wrote: >> On Tue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan < >> suresh.krishnan@ericsson.com> wrote: >> >>> I am struggling to understand why things are any different now with header >>> insertion. I am expecting the proponents of header insertion to do exactly >>> what the proponents of zero UDP checksums did and do the groundwork for >>> updating RFC2460bis. There is no “speak now or forever hold your peace” >>> moment here. We are not closing off any avenues of future extensibility. >>> The future extensibility proposals will be judged on their own merits. >>> Given that there is existence proof, I would like to better understand why >>> this same strategy will not work in the header insertion case. I believe >>> that would be a good starting point for a constructive discussion going >>> forward. >>> >> >> Hear, hear. Frankly I'm surprised we're even still talking about this. >> Anything we'd like to do on this topic is achievable via an update to >> whatever document RFC2460bis becomes. The sooner we start work on such an >> update, the sooner it will be published. > > Violent agreement. Agredd. That's why I argue that there's no need for changes to rfc2460bis as a result of this discussion (except for the clarification of HBH insertion/delation not being allowed). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 11 09:30:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0764D12EAFC; Tue, 11 Apr 2017 09:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 ogaXnVhjt3cs; Tue, 11 Apr 2017 09:29:57 -0700 (PDT) Received: from smtp.uniroma2.it (mysmtp.uniroma2.it [160.80.6.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929DB12EB08; Tue, 11 Apr 2017 09:29:55 -0700 (PDT) Received: from smtpauth.uniroma2.it (smtpauth.uniroma2.it [160.80.6.47]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id v3BGTeeN020078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Apr 2017 18:29:45 +0200 Received: from [160.80.82.21] ([160.80.82.21]) (authenticated bits=0) by smtpauth.uniroma2.it (8.14.3/8.14.3/Debian-9.4) with ESMTP id v3BGTY1Q030465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 11 Apr 2017 18:29:35 +0200 Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Mark Smith , "Stefano Previdi (sprevidi)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , Suresh Krishnan , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Stefano Salsano Message-ID: <06f690d1-710c-7093-8eea-f37e89434992@uniroma2.it> Date: Tue, 11 Apr 2017 18:29:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2015 X-Virus-Status: Clean Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 16:30:01 -0000 Il 2017-04-11 14:02, Mark Smith ha scritto: > You spec could state that packets that have had EHs inserted MUST have > them removed, however in practice, they may not be removed because of > implementation bugs, device misconfiguration or partial device failure. > > This failure to remove them will not be visible to the domain that added > them, because there are no local SR domain consequences of that failure. > Other receivers may suffer the consequences, yet there is nothing to > indicate in the packet which device or domain inserted the EH. > > Consider this scenario, using an AS boundaries as a EH insertion domain > boundaries, with the packet travelling left to right, and this being a > path across the Internet. Imagine being at one of the ASes upstream of > one or both of the EH insertion ASes, trying to work out which one > inserted the EH and didn't remove it successfully. > > [pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS > ASY]--[AS3]--[AS4]--[pkt dst AS] > > To make this example more visceral, imagine [pkt src AS] is a > residential ISP who has with 10 of 000s of customers failing to access a > streaming VoD provider at [pkt dst AS]. Those angry customers will be > ringing [pkt src AS]'s helpdesk, increasing their support costs, market > reputation and possibly cost them customers, and [pkt dst AS] will be > losing reputation, revenue and possibly customers while this > troubleshooting is going on. Dear Mark, I want to clarify that the example you provided does not apply to the "controlled domain" insertion discussed in draft-voyer-6man-extension-header-insertion according to draft-voyer-6man-extension-header-insertion, ASX and ASY of your example are NOT allowed to insert EH in the packet originated by src AS the EH is inserted in a outer packet which encapsulates the original one and with with a destination IPv6 address within the "controlled domain" if you want to map your example into something that is aligned with draft-voyer-6man-extension-header-insertion, it should become something like the following (covering only EH insertion on ASX): [pkt src AS]--[AS1]--[ASX:encapsulation of the packet in a new outer packet] [ASX:EH INS on the outer packet ]--[ASX:decapsulation of the packet]-- [AS2]-- [....] -- [pkt dst AS] regards, Stefano > > > Regards, > Mark. > > > > s. > > > > > > Regards > > Brian > > > > > > On 11/04/2017 04:09, Tim Chown wrote: > >> Hi Alvaro, > >> > >>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) > > wrote: > >>> > >>> Tim: > >>> > >>> Hi! > >>> > >>> The initial sentence mentions 4 actions: examine, process, > insert, or delete. > >>> > >>> The text already says that any node can examine the headers “for > any reason”, according to [rfc7045]. So maybe take that out as part > of the original 4. > >>> > >>> I do have an additional clarity question. What does “process” > mean? Does it include a “change en-route”? I’m asking because > Section 4.2. (Options) says that “the Hop-by-Hop Options header and > the Destination Options header” has an option bit that indicates > “whether or not the Option Data of that option can change en-route > to the packet's final destination”. I’m assuming that to change the > data the transit node has to not just “examine” (which I think means > “look at”), but also (at least) “process” the EH as well. If to > “process” includes the ability to “change en-route”, then it looks > like the Destination Option may also be an exception… > >> > >> I think most people always assumed process included inserting and > removing headers, but equally some people argue that strictly > examining involves some form of processing. > >> > >>> I don’t think your proposed text does much to clarify…at least > not for me. ⹠> >> > >> It’s tricky, without rewriting more text than was originally > desired. It would good for the text to be explicit, and > non-contradictory. > >> > >> Tim > >> > >>> > >>> Thanks! > >>> > >>> Alvaro. > >>> > >>> > >>> > >>> > >>> On 4/10/17, 4:52 AM, "Tim Chown" > wrote: > >>> > >>> Hi, > >>> > >>>> On 10 Apr 2017, at 04:03, Suresh Krishnan > > > wrote: > >>>> > >>>> Hi Alvaro, > >>>> Thanks for your comments. Please find responses inline. > >>>> > >>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana > wrote: > >>>>> > >>>>> ========== > >>>>> > >>>>> Related to the above, I also want to point out the lack of > clarity in the > >>>>> text in Section 4. (IPv6 Extension Headers), which leaves > itself open to > >>>>> interpretation and should be cleaned up. > >>>>> > >>>>> (A) The main piece of text that has been discussed now reads: > >>>>> > >>>>> With one exception, extension headers are not examined, processed, > >>>>> inserted, or deleted by any node along a packet's delivery path, > >>>>> until the packet reaches the node (or each of the set of nodes, in > >>>>> the case of multicast) identified in the Destination Address field > >>>>> of > >>>>> the IPv6 header. Note: If an intermediate forwarding node > examines > >>>>> an extension header for any reason, it must do so in > accordance with > >>>>> the provisions of [RFC7045]. > >>>>> ... > >>>>> The exception referred to in the preceding paragraph is the > Hop-by- > >>>>> Hop Options header, which carries information that may be examined > >>>>> and processed by every node along a packet's delivery path, > >>>>> including > >>>>> the source and destination nodes. The Hop-by-Hop Options header, > >>>>> when present, must immediately follow the IPv6 header. Its > presence > >>>>> is indicated by the value zero in the Next Header field of the > IPv6 > >>>>> header. > >>>>> > >>>>> NOTE: While [RFC2460] required that all nodes must examine and > >>>>> process the Hop-by-Hop Options header, it is now expected that > nodes > >>>>> along a packet's delivery path only examine and process the > Hop-by- > >>>>> Hop Options header if explicitly configured to do so. > >>>>> > >>>>> While the first sentence seems clear on what this document wants > >>>>> forwarding nodes to do (or not), there are two notes that define > >>>>> exceptions: any forwarding node can examine the headers "for > any reason", > >>>>> and, the Hop-by-Hop Options header doesn't really have to be > examined and > >>>>> processed by everyone. > >>>>> > >>>>> This text needs some more work to at least not contradict > itself: there > >>>>> is more than one exception, and they are not absolute, anyone > can examine > >>>>> the headers "for any reason”… > >>>> > >>>> Right. I think the examine piece could use some rewording to > merge with the RFC7045 exception. > >>> > >>> One way to improve the RFC7045 “contradiction” in the 2460-bis > text would be to rearrange the text to lift out the RFC7045 > reference such that it follows the text about the HbH option header, > adding an example of inspecting the payload, which is the main > rationale for such inspection stated in RFC7045. > >>> > >>> Old: > >>> > >>> With one exception, extension headers are not examined, processed, > >>> inserted, or deleted by any node along a packet's delivery path, > >>> until the packet reaches the node (or each of the set of nodes, in > >>> the case of multicast) identified in the Destination Address > field of > >>> the IPv6 header. Note: If an intermediate forwarding node examines > >>> an extension header for any reason, it must do so in accordance > with > >>> the provisions of [RFC7045]. At the Destination node, normal > >>> demultiplexing on the Next Header field of the IPv6 header invokes > >>> the module to process the first extension header, or the > upper-layer > >>> header if no extension header is present. The contents and > semantics > >>> of each extension header determine whether or not to proceed to the > >>> next header. Therefore, extension headers must be processed > strictly > >>> in the order they appear in the packet; a receiver must not, for > >>> example, scan through a packet looking for a particular kind of > >>> extension header and process that header prior to processing all > >>> preceding ones. > >>> > >>> The exception referred to in the preceding paragraph is the Hop-by- > >>> Hop Options header, which carries information that may be examined > >>> and processed by every node along a packet's delivery path, > including > >>> the source and destination nodes. The Hop-by-Hop Options header, > >>> when present, must immediately follow the IPv6 header. Its > presence > >>> is indicated by the value zero in the Next Header field of the IPv6 > >>> header. > >>> > >>> NOTE: While [RFC2460] required that all nodes must examine and > >>> process the Hop-by-Hop Options header, it is now expected that > nodes > >>> along a packet's delivery path only examine and process the Hop-by- > >>> Hop Options header if explicitly configured to do so. > >>> > >>> New: > >>> > >>> With one exception, extension headers are not examined, processed, > >>> inserted, or deleted by any node along a packet's delivery path, > >>> until the packet reaches the node (or each of the set of nodes, in > >>> the case of multicast) identified in the Destination Address > field of > >>> the IPv6 header. At the Destination node, normal > >>> demultiplexing on the Next Header field of the IPv6 header invokes > >>> the module to process the first extension header, or the > upper-layer > >>> header if no extension header is present. The contents and > semantics > >>> of each extension header determine whether or not to proceed to the > >>> next header. Therefore, extension headers must be processed > strictly > >>> in the order they appear in the packet; a receiver must not, for > >>> example, scan through a packet looking for a particular kind of > >>> extension header and process that header prior to processing all > >>> preceding ones. > >>> > >>> The exception referred to in the preceding paragraph is the Hop-by- > >>> Hop Options header, which carries information that may be examined > >>> and processed by every node along a packet's delivery path, > including > >>> the source and destination nodes. The Hop-by-Hop Options header, > >>> when present, must immediately follow the IPv6 header. Its > presence > >>> is indicated by the value zero in the Next Header field of the IPv6 > >>> header. > >>> > >>> NOTE: While [RFC2460] required that all nodes must examine and > >>> process the Hop-by-Hop Options header, it is now expected that > nodes > >>> along a packet's delivery path only examine and process the Hop-by- > >>> Hop Options header if explicitly configured to do so. > >>> > >>> NOTE: If any other intermediate forwarding device needs to examine > >>> an extension header for any reason, e.g., to traverse the extension > >>> header chain to inspect the transport header of a packet, it > must do so in > >>> accordance with the provisions of [RFC7045]. > >>> > >>> The question then would be the specific wording of that last > paragraph. > >>> > >>> Tim > >>> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Tue Apr 11 11:31:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCB812EB8F; Tue, 11 Apr 2017 11:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6irMImn1CIdh; Tue, 11 Apr 2017 11:31:01 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 43B5E12EB99; Tue, 11 Apr 2017 11:30:56 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id f133so4996814qke.2; Tue, 11 Apr 2017 11:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=qqj2bi9llybdT8A7JUaoFp41vjUkhjDklrhSx5QNS2o=; b=utIbl9H9ZlLRpPEG4zbllNYdfjkkmkQzbKh6Af62IgtLkGTongLeiwCINRrJI40ebW 5k9umb8eEOQ1gtRIEY70o7C3eTAJwbzMZNfTf6uLxNtlnezcsvr9TXi0rTn1nXGBrKw2 urlZpZw4rdIFIvJJjjkIep+VcGsrsjoiN37LxCR4trgevFlZdIFABqGPm6WZe0xb9hWg s21GKUTKVKkwG0KdcmoPK/JglTRxP+jEwEEbaqFphlCZKlTGctKWJVEWGIIJVti3wref WBPeO51djPUnTAjt471w8yWleq0GFS5KVEPWY2QzKQ3IObsLNI931x9nf5hjSyZRxE9R 85jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=qqj2bi9llybdT8A7JUaoFp41vjUkhjDklrhSx5QNS2o=; b=W9ruRe2Q+WacSbRvNI/BAaLWRfdfX5YiFbnFjFIcdoYUyy5ipUuiBQQDMJzg3DLnUt 3n3UzPPUyHrk0mkYNU5y5rnr32yFk8CKOBmoSqOKw3A2KdEqqjDrburw/JSlqlHFswz2 yvbVZRG4Ka0wuD2onArJuvoegbMBB6K9E3kxYe7ByQ6BYFnSdfvCbGWdqOvm0sHGdrgp qWIebAhf4H7kEer0SXN+g/1jvNOqI7zcZllKhc+/3cdeLm6W1ZuH0sJ6JYdo3zSKN81N r5JVYUKMiMur7TYfqOEIjIf+zrvDLP719cG4eYNkte7j464+lYX+f8Dt/B7IMsThdO3Z cJtA== X-Gm-Message-State: AFeK/H3HsveLgge2+0q0MqP2utwfcoIo1+vHqeZYW/q2k9cCJ5EZzQNae9HS2iflNK4h+vSQy2JtcoyNKR2Whw== X-Received: by 10.55.146.135 with SMTP id u129mr56127065qkd.219.1491935455203; Tue, 11 Apr 2017 11:30:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Tue, 11 Apr 2017 11:30:54 -0700 (PDT) In-Reply-To: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 11 Apr 2017 11:30:54 -0700 X-Google-Sender-Auth: wUVhzUhFMgZLT3FjdwVZNOkUnhE Message-ID: Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) To: Suresh Krishnan Cc: "ipv6@ietf.org" , The IESG , "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:31:03 -0000 At Tue, 11 Apr 2017 04:01:27 +0000, Suresh Krishnan wrote: > I am struggling to understand why things are any different now with > header insertion. I am expecting the proponents of header insertion > to do exactly what the proponents of zero UDP checksums did and do > the groundwork for updating RFC2460bis. There is no =E2=80=9Cspeak now or > forever hold your peace=E2=80=9D moment here. We are not closing off any > avenues of future extensibility. The future extensibility proposals > will be judged on their own merits. Given that there is existence > proof, I would like to better understand why this same strategy will > not work in the header insertion case. I believe that would be a > good starting point for a constructive discussion going forward. I personally agree with you, but if I were a "proponent of header insertion", I might say "the difference from the UDP checksum is that we're adding new text that explicitly mentions the header insertion case". So, assuming we're at least done with "eliminating ambiguity" itself, I think the main questions are: - whether we should add any supplemental text to explain that the added text in 2460bis is not intended to deny future extensibility - if so, how we phrase it Frankly, I don't see the need for the additional explanation (in which sense I'm with Fernando), but if the "proponents" are so worried about the new text with a stamp of Internet Standard being interpreted as an "outright ban", I'm also okay with adding a note as a kind of compromise for moving forward. And, in that case, I'm okay with Brian's proposal, and if it's even considered too vague I'm also okay with stating it more explicitly. -- JINMEI, Tatuya From nobody Tue Apr 11 12:14:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8212951B; Tue, 11 Apr 2017 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 qWctKzCg6tWX; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 3905E127010; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l28so4171779wre.0; Tue, 11 Apr 2017 12:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=zxlUSKEaMm1Eq+h1p4NutfP7p+TiI+7JXyhJxV/1z+M=; b=GLAGTPH3aHn7YILqAmHozC6KYDZ5MClWv6XZ+YDCizM6kUoIQzxvo/U+hozFDOM60O OcA5Z4/njNL6zm5VFOSBzyPkaqMsgijOp83wl2WaM/phfi7nlyNVHc0Q7iMH8tzFy+vC /FitYubE4LIQigFIylZmK/ajV5mih4x8OnuXy54PrUnqSF50IzfJbsBee3+r0WKytev0 2BKV7XPIXQz7jWv7aT/Iwu7mkOkba7/KI/zU/nACpC5HGxhZX07R6/zxlciWN/SxLeSy wlCDLYUJxnP0Kyf22zfb8M21YsMhkLS57c7mSOxiPVGCfih6V/GiHnjR/Y3EKIzL3qsI sHCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=zxlUSKEaMm1Eq+h1p4NutfP7p+TiI+7JXyhJxV/1z+M=; b=R2cVmObCUHUqXA9IkdrIFdwQSfnG2xJH2MpwITgfmX8Hk1Xe4CyvZwZjNTAvXUsYoF poGce2bk0srsyi1oQEp5BwSFJx8MwmXFnKnfRSoQBKpub0xkUgXIus4LAm7sDLOAJ8F3 +jz8ic/wohhCOyJaEKwtcsYBiaWL0d3/i9E8VF9oOlq5fVdjTWzsZj+7Thsm3rL0SO0V zalEpD+ccJuQKjJBhY/oDhhMy7kGzJ2/+cpWC8PD1DKRVGxwVKLCvgUce2cqeOs9gLJU 1D8GZ+HPInvnoxnGhqNbr7BVO2D9cmrRsrmUU6MRMZIeO2j6zxiSW+zPGzsqNFMacsfn A1OA== X-Gm-Message-State: AFeK/H1oBoPa+7BsnkCFXQNWRyJmc8aYHb7CAx/VLLgILOTBnpfEx68XaWzKJIrhv+zIrQ== X-Received: by 10.223.144.8 with SMTP id h8mr49392107wrh.45.1491938048169; Tue, 11 Apr 2017 12:14:08 -0700 (PDT) Received: from ?IPv6:2003:6:1575:649:78ae:9e4f:62ab:8918? (p200300061575064978AE9E4F62AB8918.dip0.t-ipconnect.de. [2003:6:1575:649:78ae:9e4f:62ab:8918]) by smtp.googlemail.com with ESMTPSA id d7sm22638188wrc.6.2017.04.11.12.14.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 12:14:07 -0700 (PDT) From: Martin Stiemerling Subject: TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: ipv6@ietf.org Cc: tsv-art@ietf.org Message-ID: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> Date: Tue, 11 Apr 2017 21:14:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:14:12 -0000 Hi, I've reviewed this document as part of the transport area review team (TSV-ART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Sorry for being so late with the review... Summary: This draft has serious issues out of a transport area perspective, described in the review, and needs to be rethought. Major issues: - Section 4.8. "Defining New Extension Headers and Options": It says new hop-by-hop headers must never ever defined. This is problematic, as this closing the door forever, even if future instances of the IETF do would like to wish to define new hop-by-hop headers. A better way would have to say "that new hop-by-hop headers must have IETF consensus". - Section 4.8. "Defining New Extension Headers and Options": Also the „not recommended“ to define new extension headers looks strange, especially with the phrase "There has to be a very clear justification". The term "clear justification" is not an exact engineering specification. Why not using "technical protocol specification and real word use case required, plus IETF consensus"? Minor issues: none. Thank you, Martin Stiemerling From nobody Tue Apr 11 12:30:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C5312F28E; Tue, 11 Apr 2017 12:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4y78SB1rba5X; Tue, 11 Apr 2017 12:30:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A842712F4EA; Tue, 11 Apr 2017 12:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3564; q=dns/txt; s=iport; t=1491939041; x=1493148641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=l3Pc8l+l2Xf6NeA+YVOTr9MW2s067WvJEFcat7FYm/I=; b=YUAs9NPKpuAwM+1Frh5OlChK9CLWB8zToiMRuKu3Cg3kRZEwWZscSdBB hvTHdM7Y+E8LTB5r5W3RVOZuG3JuzkCVCC0neVdAfwIN4Q8MY5NqYpHc1 YnKFmNWX/itEvbQ72nZz48bZGR7WVKno8lYLNjOVBXCLMmc1AaVpdIPOa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgD8Le1Y/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeDX4oTkU+IGo0+gg+GJAIag0k/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjEUUFCwIBCA4KAgIfBwICAh8RFRACBA4FiXgDDQipJ4ImhzANgz0BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFRYIFgmuCUYIFF4JvLoIxBZxEOwGOG4R?= =?us-ascii?q?CCoF1hS6KF4sBiH8BHziBBVsVUgGEfoFKdQGIR4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="scan'208";a="231720556" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 19:30:40 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3BJUetm032637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 19:30:40 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 15:30:39 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 15:30:39 -0400 From: "Stefano Previdi (sprevidi)" To: Fernando Gont CC: Brian E Carpenter , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , Suresh Krishnan , "The IESG" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: COntrolled-domains (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Topic: COntrolled-domains (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Index: AQHSstk8UKTsYk5j+0KPn9Wc4Vlca6HA0ZIA Date: Tue, 11 Apr 2017 19:30:39 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> <935698ca-d56d-adf8-c3d9-c8ea9fa07989@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.161.35] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:30:46 -0000 DQo+IE9uIEFwciAxMSwgMjAxNywgYXQgNTozMyBQTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2 bmV0d29ya3MuY29tPiB3cm90ZToNCj4gDQo+IE9uIDA0LzExLzIwMTcgMDI6MzkgUE0sIEJyaWFu IEUgQ2FycGVudGVyIHdyb3RlOg0KPj4gT24gMTEvMDQvMjAxNyAxOToxMSwgU3RlZmFubyBQcmV2 aWRpIChzcHJldmlkaSkgd3JvdGU6DQo+Pj4gDQo+Pj4+IE9uIEFwciAxMCwgMjAxNywgYXQgMTA6 MjQgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdy b3RlOg0KPj4+PiANCj4+Pj4gRXhjdXNlIGZyb250IHBvc3RpbmcsIGJ1dCB0aGUgaW50ZXJsZWF2 aW5nIGlzIGdldHRpbmcgYSBiaXQgZGlzdHJhY3RpbmcgaW4gaXRzZWxmLg0KPj4+PiANCj4+Pj4g TXkgY29uc2lkZXJlZCBvcGluaW9uIGlzIHRoYXQgcHJldGVuZGluZyB0byBmb3JiaWQgImV4YW1p bmUiIGlzIGp1c3QgbGF1Z2hhYmxlLA0KPj4+PiBzaW5jZSB3ZSBrbm93IHRoYXQgbWlkZGxlYm94 ZXMgbWFrZSBpdCB0aGVpciBqb2IgdG8gZXhhbWluZSBwYWNrZXQgaGVhZGVycy4gDQo+Pj4+IFNv IGl0J3MgcG9pbnRsZXNzIHRvIHN0YXRlIGl0OyB0YWtlIGl0IG91dCAoYnV0IGxlYXZlIGluIHRo ZSByZWZlcmVuY2UgdG8gNzA0NSkuDQo+Pj4+IA0KPj4+PiBUaGUgd29yZCAicHJvY2VzcyIgaXMg dG9vIHZhZ3VlIC0gYW5kIGhhcyBiZWVuIHRvbyB2YWd1ZSBzaW5jZSBSRkMgMTg4My4NCj4+Pj4g U28gdGFrZSB0aGF0IG91dCB0b28uIChDbGVhcmx5LCBhIG1pZGRsZWJveCB0aGF0IGNhbiBleGFt aW5lIGEgaGVhZGVyDQo+Pj4+IGNhbiBwcm9jZXNzIGl0IC0gYnV0IHNvIHdoYXQ/IFRoYXQgZG9l c24ndCBhZmZlY3QgdGhlIGNvbnRlbnRzIG9mIHRoZQ0KPj4+PiBwYWNrZXQuKQ0KPj4+PiANCj4+ Pj4gV2hhdCB3ZSBjYW4gbWVhbmluZ2Z1bGx5IHByb2hpYml0IGluIHRoZSBjb250ZXh0IG9mIElu dGVybmV0LXdpZGUgaW50ZXJvcA0KPj4+PiBpcyAiaW5zZXJ0LCBtb2RpZnkgb3IgZGVsZXRl4oCd Lg0KPj4+IA0KPj4+IA0KPj4+IHdlIGRvbuKAmXQgaGF2ZSBhIGRlZmluaXRpb24gb2Yg4oCcaW50 ZXJuZXQtd2lkZeKAnSBhbmQgd2UgbWF5IHdlbGwgZW5kIHVwIGluIGFub3RoZXIgbG9vcCB0eWlu ZyB0byBhZ3JlZSB3aGF0IGl0IG1lYW5zLg0KPj4+IA0KPj4+IFRoZSBzaW1wbGVzdCBhcHByb2Fj aCBpcyB0byBhZGQgYW4gZXhjZXB0aW9uIHdoaWNoIGNvbnNpc3RzIG9mIGEgY29udHJvbGxlZC9j bG9zZWQgZG9tYWluIChmb3Igd2hpY2ggd2UgZG8gaGF2ZSBhIGRlZmluaXRpb24pLg0KPj4gDQo+ PiBVbmZvcnR1bmF0ZWx5LCB3ZSBkb24ndCwgYXMgSSBkaXNjb3ZlcmVkIHdoZW4gSSBwcm9wb3Nl ZCBzdWNoIGFuDQo+PiBhcHByb2FjaCB0byBhbGxvdyBsb2NhbCB1c2Ugb2YgdGhlIElQdjYgRmxv dyBMYWJlbC4gIkludGVybmV0LXdpZGUiDQo+PiBvbiB0aGUgb3RoZXIgaGFuZCBzZWVtcyBjb21w bGV0ZWx5IGNsZWFyIHRvIG1lLiBBbnkgbm9kZSB0byBhbnkgbm9kZS4NCj4gDQo+IE15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCB0aGUgImNvbnRyb2xsZWQgZG9tYWlucyIgdGhhdCBSIHBlb3BsZSB0 YWxrDQo+IGFib3V0IGlzIGEgZGlmZmVyZW50IHRoaW5nOiB0aGV5IHRhbGsgYWJvdXQgY29udHJv bGxlZCBkb21haW5zIHJlZ2FyZGluZw0KPiB3aG8gaW5zZXJ0cy9yZW1vdmVzIEVIcywgcmF0aGVy IHRoYW4gc3JjL2RzdCBhZGRyZXNzZXMgb2YgdGggcGFja2V0cy4NCj4gDQo+IElmIHBhY2tldHMg c3RpbGwgaGF2ZSBpbnRlcm5ldC13aWRlIHNyZC9kc3QgYWRkcmVzc2VzLCB0aGVuIHBhY2tldHMN Cj4gcmVxdWlyZSBpbnRlcm5ldC13aWRlIGludGVyb3BlcmFiaWxpdHkuDQoNCg0KYXMgZGVzY3Jp YmVkIGluIGRyYWZ0LXZveWVyLTZtYW4tZXh0ZW5zaW9uLWhlYWRlci1pbnNlcnRpb24sIHRoZSBj b250cm9sbGVkIGRvbWFpbiBpcyB0aGUgZG9tYWluIHdoZXJlIHRoZSBwYWNrZXQgaXMgc291cmNl ZCBfYW5kXyAocGxlYXNlLCBub3RlIHRoZSDigJxhbmTigJ0pIGRlc3RpbmVkLg0KDQpJT1csIGJv dGggU0EgYW5kIERBIGJlbG9uZyB0byB0aGUgZG9tYWluIHVuZGVyIHRoZSBzYW1lIGNvbnRyb2wg YW5kIHdpdGhpbiB0aGF0IGRvbWFpbiBhbGwgYm94ZXMgdGhhdCB0aGUgcGFja2V0IHdpbGwgdHJh dmVyc2UgYXJlIGFsc28gdW5kZXIgdGhlIHNhbWUgY29udHJvbC4NCg0KZHJhZnQtdm95ZXItNm1h bi1leHRlbnNpb24taGVhZGVyLWluc2VydGlvbiBhbHNvIGdpdmVzIGEgY291cGxlIG9mIGV4YW1w bGVzLg0KDQpzLg0KDQo+IA0KPiBQLlMuOiBUaGlzIGlzIGEgc2lkZSBjb21tZW50IC0tIGFzIG5v dGVkIGJlZm9yZSwgSSdtIGFnYWluc3QNCj4gImFwcGxpY2FiaWxpdHkgc3RhdGVtZW50cyIgb24g cmZjMjQ2MCBmb3IgYSBidW5jaCBvZiByZWFzb25zLg0KPiANCj4gVGhhbmtzLA0KPiAtLSANCj4g RmVybmFuZG8gR29udA0KPiBTSTYgTmV0d29ya3MNCj4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jr cy5jb20NCj4gUEdQIEZpbmdlcnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBB RTI1IDBENTUgMUQ0RSA3NDkyDQo+IA0KPiANCj4gDQo+IA0KDQo= From nobody Tue Apr 11 14:12:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5A1201F8; Tue, 11 Apr 2017 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 7CzHnl9U9tby; Tue, 11 Apr 2017 14:11:56 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1ED1243F6; Tue, 11 Apr 2017 14:11:56 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 11 Apr 2017 21:11:56 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BCF23D788D; Tue, 11 Apr 2017 14:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=c4NiGDUEWSHLi2jyIl5o4a4VD0Q=; b= rPJrIPy8lQ0LFtZLfxs0wsZNcGf+4Cv6/BPRqDHtsw5laCcn97BSvfbXjaExXM+Y Vm3TF6gLrlVX32qiAQcLNmcMaT3/PhM/F/yD8esTiHe3INtbgj1JsFK7TVSZZfhV Bg9UBGfMTeO+CVCPGSu3aSAiHqk+8yaYx82ZrHa0MWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=rxdWHowr5GIG6liwW6Jle7T eDr9tBBxoa76nzfS3d4YkQyR/KgoOgi7LhwSeVevhJJv4SzktVse0rkkANro+yAF DrBZFecq6CctEbb2vMrLwp60+UwHiJfSsOhInHJOZHSl3xUD/Vzv4s8/IMwShdfO g95SzMbBMxwS56mJyDc0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5F60DD788A; Tue, 11 Apr 2017 14:11:55 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3FC45A86A923; Tue, 11 Apr 2017 23:11:52 +0200 (CEST) From: otroan@employees.org Message-Id: <4313570D-3C60-4872-B8C4-3CA76C1B240A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_583D08CE-419F-4267-95F9-07F5470BE7F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Date: Tue, 11 Apr 2017 23:11:51 +0200 In-Reply-To: <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> Cc: Tim Chown , "Alvaro Retana (aretana)" , "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , Suresh Krishnan , The IESG To: Brian E Carpenter References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:11:59 -0000 --Apple-Mail=_583D08CE-419F-4267-95F9-07F5470BE7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Excuse front posting, but the interleaving is getting a bit = distracting in itself. >=20 > My considered opinion is that pretending to forbid "examine" is just = laughable, > since we know that middleboxes make it their job to examine packet = headers. > So it's pointless to state it; take it out (but leave in the reference = to 7045). >=20 > The word "process" is too vague - and has been too vague since RFC = 1883. > So take that out too. (Clearly, a middlebox that can examine a header > can process it - but so what? That doesn't affect the contents of the > packet.) >=20 > What we can meaningfully prohibit in the context of Internet-wide = interop > is "insert, modify or delete". 2460 doesn't (largely nor does the IETF) specify middlebox behaviour. I am opposed to accommodating middleboxes in 2460. The point of this text as I read it, is to specify what 2460 routers = need to do. And the requirement for IPv6 forwarding is to only process = the IPv6 base header (with one exception (HBH)). Cheers, Ole >=20 > Regards > Brian >=20 >=20 > On 11/04/2017 04:09, Tim Chown wrote: >> Hi Alvaro, >>=20 >>> On 10 Apr 2017, at 14:53, Alvaro Retana (aretana) = wrote: >>>=20 >>> Tim: >>>=20 >>> Hi! >>>=20 >>> The initial sentence mentions 4 actions: examine, process, insert, = or delete. >>>=20 >>> The text already says that any node can examine the headers =E2=80=9Cf= or any reason=E2=80=9D, according to [rfc7045]. So maybe take that out = as part of the original 4. >>>=20 >>> I do have an additional clarity question. What does =E2=80=9Cprocess=E2= =80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe = Hop-by-Hop Options header and the Destination Options header=E2=80=9D = has an option bit that indicates =E2=80=9Cwhether or not the Option Data = of that option can change en-route to the packet's final destination=E2=80= =9D. I=E2=80=99m assuming that to change the data the transit node has = to not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook = at=E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as = well. If to =E2=80=9Cprocess=E2=80=9D includes the ability to = =E2=80=9Cchange en-route=E2=80=9D, then it looks like the Destination = Option may also be an exception=E2=80=A6 >>=20 >> I think most people always assumed process included inserting and = removing headers, but equally some people argue that strictly examining = involves some form of processing. >>=20 >>> I don=E2=80=99t think your proposed text does much to clarify=E2=80=A6= at least not for me. =E2=98=B9 >>=20 >> It=E2=80=99s tricky, without rewriting more text than was originally = desired. It would good for the text to be explicit, and = non-contradictory. >>=20 >> Tim >>=20 >>>=20 >>> Thanks! >>>=20 >>> Alvaro. >>>=20 >>>=20 >>>=20 >>>=20 >>> On 4/10/17, 4:52 AM, "Tim Chown" wrote: >>>=20 >>> Hi, >>>=20 >>>> On 10 Apr 2017, at 04:03, Suresh Krishnan = wrote: >>>>=20 >>>> Hi Alvaro, >>>> Thanks for your comments. Please find responses inline. >>>>=20 >>>>> On Apr 7, 2017, at 2:39 PM, Alvaro Retana = wrote: >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> Related to the above, I also want to point out the lack of clarity = in the >>>>> text in Section 4. (IPv6 Extension Headers), which leaves itself = open to >>>>> interpretation and should be cleaned up. >>>>>=20 >>>>> (A) The main piece of text that has been discussed now reads: >>>>>=20 >>>>> With one exception, extension headers are not examined, processed, >>>>> inserted, or deleted by any node along a packet's delivery path, >>>>> until the packet reaches the node (or each of the set of nodes, in >>>>> the case of multicast) identified in the Destination Address field >>>>> of >>>>> the IPv6 header. Note: If an intermediate forwarding node = examines >>>>> an extension header for any reason, it must do so in accordance = with >>>>> the provisions of [RFC7045]. >>>>> ... >>>>> The exception referred to in the preceding paragraph is the = Hop-by- >>>>> Hop Options header, which carries information that may be examined >>>>> and processed by every node along a packet's delivery path, >>>>> including >>>>> the source and destination nodes. The Hop-by-Hop Options header, >>>>> when present, must immediately follow the IPv6 header. Its = presence >>>>> is indicated by the value zero in the Next Header field of the = IPv6 >>>>> header. >>>>>=20 >>>>> NOTE: While [RFC2460] required that all nodes must examine and >>>>> process the Hop-by-Hop Options header, it is now expected that = nodes >>>>> along a packet's delivery path only examine and process the = Hop-by- >>>>> Hop Options header if explicitly configured to do so. >>>>>=20 >>>>> While the first sentence seems clear on what this document wants >>>>> forwarding nodes to do (or not), there are two notes that define >>>>> exceptions: any forwarding node can examine the headers "for any = reason", >>>>> and, the Hop-by-Hop Options header doesn't really have to be = examined and >>>>> processed by everyone. >>>>>=20 >>>>> This text needs some more work to at least not contradict itself: = there >>>>> is more than one exception, and they are not absolute, anyone can = examine >>>>> the headers "for any reason=E2=80=9D=E2=80=A6 >>>>=20 >>>> Right. I think the examine piece could use some rewording to merge = with the RFC7045 exception. >>>=20 >>> One way to improve the RFC7045 =E2=80=9Ccontradiction=E2=80=9D in = the 2460-bis text would be to rearrange the text to lift out the RFC7045 = reference such that it follows the text about the HbH option header, = adding an example of inspecting the payload, which is the main rationale = for such inspection stated in RFC7045. >>>=20 >>> Old: >>>=20 >>> With one exception, extension headers are not examined, processed, >>> inserted, or deleted by any node along a packet's delivery path, >>> until the packet reaches the node (or each of the set of nodes, in >>> the case of multicast) identified in the Destination Address field = of >>> the IPv6 header. Note: If an intermediate forwarding node examines >>> an extension header for any reason, it must do so in accordance = with >>> the provisions of [RFC7045]. At the Destination node, normal >>> demultiplexing on the Next Header field of the IPv6 header invokes >>> the module to process the first extension header, or the = upper-layer >>> header if no extension header is present. The contents and = semantics >>> of each extension header determine whether or not to proceed to the >>> next header. Therefore, extension headers must be processed = strictly >>> in the order they appear in the packet; a receiver must not, for >>> example, scan through a packet looking for a particular kind of >>> extension header and process that header prior to processing all >>> preceding ones. >>>=20 >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that may be examined >>> and processed by every node along a packet's delivery path, = including >>> the source and destination nodes. The Hop-by-Hop Options header, >>> when present, must immediately follow the IPv6 header. Its = presence >>> is indicated by the value zero in the Next Header field of the IPv6 >>> header. >>>=20 >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that = nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>>=20 >>> New: >>>=20 >>> With one exception, extension headers are not examined, processed, >>> inserted, or deleted by any node along a packet's delivery path, >>> until the packet reaches the node (or each of the set of nodes, in >>> the case of multicast) identified in the Destination Address field = of >>> the IPv6 header. At the Destination node, normal >>> demultiplexing on the Next Header field of the IPv6 header invokes >>> the module to process the first extension header, or the = upper-layer >>> header if no extension header is present. The contents and = semantics >>> of each extension header determine whether or not to proceed to the >>> next header. Therefore, extension headers must be processed = strictly >>> in the order they appear in the packet; a receiver must not, for >>> example, scan through a packet looking for a particular kind of >>> extension header and process that header prior to processing all >>> preceding ones. >>>=20 >>> The exception referred to in the preceding paragraph is the Hop-by- >>> Hop Options header, which carries information that may be examined >>> and processed by every node along a packet's delivery path, = including >>> the source and destination nodes. The Hop-by-Hop Options header, >>> when present, must immediately follow the IPv6 header. Its = presence >>> is indicated by the value zero in the Next Header field of the IPv6 >>> header. >>>=20 >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that = nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>>=20 >>> NOTE: If any other intermediate forwarding device needs to examine >>> an extension header for any reason, e.g., to traverse the extension >>> header chain to inspect the transport header of a packet, it must = do so in >>> accordance with the provisions of [RFC7045]. >>>=20 >>> The question then would be the specific wording of that last = paragraph. >>>=20 >>> Tim >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 --Apple-Mail=_583D08CE-419F-4267-95F9-07F5470BE7F5 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7UaXAAoJEL7aWKiYQt92SK0P/1vbw7H0+vEplLU8MPiKPu/z +0PhLJ9nwHyITdc8D+69A57EyIAjDbrpVmtRhLoljwY7ZS2EHfZZ5io7mITp2ufJ K1rNUgBrb/PetvbCcNpIkC+9grky0kRbyWX37GJPHunQHighOZBkUPlpc6+F9kB4 4sgY7fbm3YjJHQIGcORN2EmkyIl4IH/6h+B0oSs40TjVsJqe4/cwlmy/AH1+Pqms cQLlaMuiH4Nw5ix7vGaPTFSxdBjeDZ0LW0+xMUd6iYq/RnCEuaYrgzlWEZXddhOF yWhUVMYVeu5stXF9BgBPUIyafrlHRqxek1VtWki18wSv3LSbiUMmndZGDDkRqfBH 7Fc+ES5vrNIb+caKIbZUa2M5byPWDCnMV0WLeYS+mBBbnkyuDfb5PqtbeIq2B7aM r9m200h/aYk4A6DrQentBODfRXn01MOswUTkCMB8iI7mqo3gXa0dP68L+IiaOP1Q WwBJ4MS/5Be6BP/G6tjaU3jxS0QdAZ6WNvExgQjV4legU8HNJORHKsV9KBvtQ5Ot KeIJbnElE1NG74MagFkxi3UM0d1L71fX7JWBoa2wXgJeiErMHHErrfd0YRNNvsGR IPmtFEhthDx3jExkALG9ET+uj5DDS4zvNx+6g5o689xnfItf/IdyyXCoZS6zuZ3s /ja2YvLxWiUzFv1qm+BP =u15z -----END PGP SIGNATURE----- --Apple-Mail=_583D08CE-419F-4267-95F9-07F5470BE7F5-- From nobody Tue Apr 11 14:17:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846D1127876; Tue, 11 Apr 2017 14:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 dn5km5_46Bv5; Tue, 11 Apr 2017 14:17:47 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id EE7851201F8; Tue, 11 Apr 2017 14:17:46 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 11 Apr 2017 21:17:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AE72FD788A; Tue, 11 Apr 2017 14:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=IIOsjHFtX7vyCqR3Mz4DmuiJUwU=; b= DV9XfoK49oevZRpu3n++AdFVL7b5y/CQ7pde+u5sNZyExD3Vndh+78Kv2z98CbAy GonfRy6+lgPyCCCg1p7quoG3k4sh5kBLKfARC6oWCeLee+TJE4+UISqe3juCzy0p j5u3st7A8PS9UxdNptt9S4E5SEmYFuCG17hwqKrdd4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=iIgkAs4N+JCsWSs+sswiXm/ xGtTTXn5dH64OaQE40fGDdmZ7HHOMNMgt83ugpVFAqKG1v6zcfu6ksEAoqjrhLdx 6aSiG+U/VtMPzUXjaPk8HHAI8A/zofvZLUPvi2ZlUNNIo3q7HDeapj7dTuwLRmLB +2Dp0MxIGVbXFHYfSMI0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 3976BD788D; Tue, 11 Apr 2017 14:17:46 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 20A53A86C6BC; Tue, 11 Apr 2017 23:17:44 +0200 (CEST) From: otroan@employees.org Message-Id: <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_431E656E-2AB3-4DB5-9B53-EF809D814082"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Date: Tue, 11 Apr 2017 23:17:43 +0200 In-Reply-To: Cc: Tim Chown , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> To: "Alvaro Retana (aretana)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:17:48 -0000 --Apple-Mail=_431E656E-2AB3-4DB5-9B53-EF809D814082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro, > The initial sentence mentions 4 actions: examine, process, insert, or = delete. >=20 > The text already says that any node can examine the headers =E2=80=9Cfor= any reason=E2=80=9D, according to [rfc7045]. So maybe take that out as = part of the original 4. >=20 > I do have an additional clarity question. What does =E2=80=9Cprocess=E2= =80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe = Hop-by-Hop Options header and the Destination Options header=E2=80=9D = has an option bit that indicates =E2=80=9Cwhether or not the Option Data = of that option can change en-route to the packet's final destination=E2=80= =9D. I=E2=80=99m assuming that to change the data the transit node has = to not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook = at=E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as = well. If to =E2=80=9Cprocess=E2=80=9D includes the ability to = =E2=80=9Cchange en-route=E2=80=9D, then it looks like the Destination = Option may also be an exception=E2=80=A6 Both options inside of an HBH option header and a Destination Options = header can have the change en-route flag set. The Destinations Options header are only processed at the destination = host, so an option can then only change en-route when it is part of a = source route path (and the Destination options header is before the = routing header). The "feature" here is that one can specify options that can be processed = only by the routers listed in a routing header or one can specify = options that can change en-route for every hop along the path. Cheers, Ole --Apple-Mail=_431E656E-2AB3-4DB5-9B53-EF809D814082 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7Uf3AAoJEL7aWKiYQt92848QAKGVouikFe5PfwDmgt3Jzl7t RN1xbo9FoXw+O6W583GSJ33JzOFagIY80YXlneMt14pfesYEFkcPP2z6V5toRdXi po38s/rEGICcl6fvZqYkkPZD1P303eQw4LDM+6+e5Utqsplx9pGttiGSQ3WrG77h 0r5WWMuS/viWuvdiJ4t183MAyhv8ZNZPnei5c7uFp9Tvy8KokWrceikqGET28u2g MLbhUXTGjoJzuFybevi5V4Jkob8MSygmvMIURy0TLK8ROsaGa9N7w4CECvaJZijg AnYN8fLZsVBCQiHP9Ll8ReIfCoLHUa50OEcIF8qAfGtvck0IhSDwbjYtVVdosZn2 cDi40QTBKMfp2miLnzpTI61vh80G0+KqzLhUxuqrmwn9p3CY1CZMo2wjPOe4vjsW +SQvyC2YurGyDk8VIHaB53wHi+IBUvIjZxTnMv6Pytjqf6SizljiewCd+kC4xAgE gshb0nLFktu+sxzgW9YdDZXhfBtY+TUD+ZBMyFZi9U4dfGpIQ8UATnXof2l/MOIU Rpz8U9AdRCbYDBg8amzKI9xi6ks9bI9ai7cR2ssAn9pM0FN44W8tMRUOpNSWy9ef JmUte078DzD3rqPiROfNCivaGEmVPp1Jv/dcNV6+PZmQSxleTK/x4nH46/VieYYG lEoj3z8hnPcGaGPDBSvL =HzuZ -----END PGP SIGNATURE----- --Apple-Mail=_431E656E-2AB3-4DB5-9B53-EF809D814082-- From nobody Tue Apr 11 14:31:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BC1200C5; Tue, 11 Apr 2017 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tCUNgtzDZ1Ua; Tue, 11 Apr 2017 14:31:19 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 9F517126DC2; Tue, 11 Apr 2017 14:31:19 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 49so6128462uau.2; Tue, 11 Apr 2017 14:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vlQCTCaLyNeRwz26YAhOKLid0eOpGd39KjqGkJSwrAs=; b=PilYDMujIxqC+can1YkAAyVS8xGkmgZSbrYlFQeEO5e1YBHbIimTf5Lg8Uc8rFo60p fKk9ioqIxILTJTH9Cgz+2aZuR5kDdIvtUkVbUN/Mk9jZMyI2FR9akTXoJL52eB/FOWwU vPiJS08lmoFN2aGHILgvAIVah3Qh2bT9tCGJvsQ/v3z2ogBJX5IpwdxGPyHZgz7agxcu ToMoLjgE0pHiuYwUgc/bWfpGFaZTcuImopBHhLqUcXKD4LRiQwE2z5kI8Y0ffAVqniJ6 +1Z98Esl3kUCK2tRr1h/xL8BYFcNioh4nnFayI6fsP04K40O0MThT/0OLwHdVmE6wLbq 0AwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vlQCTCaLyNeRwz26YAhOKLid0eOpGd39KjqGkJSwrAs=; b=ZibXBM9WdmBvOVz3YkYn8Z5aQXUf19govsWDFVbL5+GIkdGepsOz9P3tSTQlrkqtRg z1c9VN1yKyCnfyv4rHneF8QkGPz3leegYNHrNz3XMWPle/6/OGgnbfSFB4ikzALaZBcc gBw0K1cdVRgUZMhYFRm+ThhyypbVuJ30DcvyjptDCoS7JbbnWZqwfX68+AEVqv1QIMH8 Ar2AxQYEvMgad1B70X9Z33vcT8No3bkh1bP2tikFGS1WhC97U7u3KHmIV7fbcJ0mpTY4 01Jh3ka4chOJa4LvMvXwnomTW9sM+un/+gp0XuQM6S5vB7nOmea12Mr9pUOM75JNvNB2 lYRw== X-Gm-Message-State: AN3rC/7z/Kx1kzAyW8/eTrMmZpiUcE7VEUuxvpR7NptbUeqEoQTqDUraJEC9jsS9RzSqKIS2g3su8sh1dnB3PA== X-Received: by 10.159.40.33 with SMTP id c30mr16698845uac.98.1491946278671; Tue, 11 Apr 2017 14:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 11 Apr 2017 14:30:48 -0700 (PDT) In-Reply-To: <06f690d1-710c-7093-8eea-f37e89434992@uniroma2.it> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> <06f690d1-710c-7093-8eea-f37e89434992@uniroma2.it> From: Mark Smith Date: Wed, 12 Apr 2017 07:30:48 +1000 Message-ID: Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Stefano Salsano Cc: "Stefano Previdi (sprevidi)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , Suresh Krishnan , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:31:21 -0000 On 12 April 2017 at 02:29, Stefano Salsano wrote: > Il 2017-04-11 14:02, Mark Smith ha scritto: >> >> You spec could state that packets that have had EHs inserted MUST have >> them removed, however in practice, they may not be removed because of >> implementation bugs, device misconfiguration or partial device failure. >> >> This failure to remove them will not be visible to the domain that added >> them, because there are no local SR domain consequences of that failure. >> Other receivers may suffer the consequences, yet there is nothing to >> indicate in the packet which device or domain inserted the EH. >> >> Consider this scenario, using an AS boundaries as a EH insertion domain >> boundaries, with the packet travelling left to right, and this being a >> path across the Internet. Imagine being at one of the ASes upstream of >> one or both of the EH insertion ASes, trying to work out which one >> inserted the EH and didn't remove it successfully. >> >> [pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS >> ASY]--[AS3]--[AS4]--[pkt dst AS] >> >> To make this example more visceral, imagine [pkt src AS] is a >> residential ISP who has with 10 of 000s of customers failing to access a >> streaming VoD provider at [pkt dst AS]. Those angry customers will be >> ringing [pkt src AS]'s helpdesk, increasing their support costs, market >> reputation and possibly cost them customers, and [pkt dst AS] will be >> losing reputation, revenue and possibly customers while this >> troubleshooting is going on. > > > Dear Mark, > > I want to clarify that the example you provided does not apply to the > "controlled domain" insertion discussed in > draft-voyer-6man-extension-header-insertion > I'm not talking specifically about draft-voyer-6man-extension-header-insertion. This is a general example of what could happen if packets that have inserted EHs leak outside the notional controlled domain (it also serves as a more general example of the problems of any operation that makes flight structural modifications to packets that aren't attributable to the device that makes them). > according to draft-voyer-6man-extension-header-insertion, > ASX and ASY of your example are NOT allowed to insert EH in the packet > originated by src AS > > the EH is inserted in a outer packet which encapsulates the original one and > with with a destination IPv6 address within the "controlled domain" > They can still leak, c.f. RFC1918s. In draft-voyer-6man-extension-header-insertion why have two methods that achieve exactly the same outcome, with the only selection criteria for the method being whether the traffic is originated externally or internally? Pick one that can serve both purposes that is most similar to existing mechanisms, leverages existing deployed devices if possible, is the one that will cause the least damage if it fails and is the easier and quickest of the two to troubleshoot. > if you want to map your example into something that is aligned with > draft-voyer-6man-extension-header-insertion, it should become something like > the following (covering only EH insertion on ASX): > > [pkt src AS]--[AS1]--[ASX:encapsulation of the packet in a new outer packet] > [ASX:EH INS on the outer packet ]--[ASX:decapsulation of the packet]-- > [AS2]-- [....] -- [pkt dst AS] > That's the model that I think should be used for all cases i.e. both internal and externally originated traffic. Regards, Mark. From nobody Tue Apr 11 14:31:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2225312869B; Tue, 11 Apr 2017 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 XFF5uxprU_uX; Tue, 11 Apr 2017 14:31:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA6A126DC2; Tue, 11 Apr 2017 14:31:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 456176B06C; Tue, 11 Apr 2017 17:31:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=uqV/OHg0cZi6zVEFODWkjOqxp 0Y=; b=EjCHwOleIkWP8mlIA+zUQk7Jx+4+noYS5s4zszzOXQoN9Qvb0iQ5MXBk8 PUfNqFN8a2GEAoOWeMMKsE5gsMMP5sTe81OflokG0unGdI1yjAx1lrdpxT8clGyY bgcG+8ShbipwdU+TJObH++juhc8R+kWIyjm7rM1M+8YT7/hjUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=AAX1ctCeKh7kf7ddBYy F+o8sFDimRLakQeoEQiUou2VCrth3Owcx82lyukXJX0Icivd1jeOpCNHXq7i37yQ hs7o3JIvkpV6R/ig+C5Eej5Zsty0dZE/V2fmDay2hxKxJm2Kzvih0kWka/34bXSD bVUu9U7w/kRkCBHw83qnPMWM= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3A6E76B069; Tue, 11 Apr 2017 17:31:52 -0400 (EDT) Received: from mail-qk0-f176.google.com (unknown [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id B42906B066; Tue, 11 Apr 2017 17:31:51 -0400 (EDT) Received: by mail-qk0-f176.google.com with SMTP id f133so8958062qke.2; Tue, 11 Apr 2017 14:31:51 -0700 (PDT) X-Gm-Message-State: AFeK/H0+jFKIfhWQXy05knO2lmFqTdWlufhTe3kRaoBIZ4INuU7MDWplW2kTCN/uSdUs6SIqzFdCyf/bhPNy9Q== X-Received: by 10.55.3.1 with SMTP id 1mr46925001qkd.245.1491946311309; Tue, 11 Apr 2017 14:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.18.75 with HTTP; Tue, 11 Apr 2017 14:31:30 -0700 (PDT) From: "C. M. Heard" Date: Tue, 11 Apr 2017 14:31:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: Martin Stiemerling , 6man WG Cc: TSV-ART Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 46DD0AA8-1EFE-11E7-BDDF-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:31:57 -0000 On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: > Major issues: > > - Section 4.8. "Defining New Extension Headers and Options": > > It says new hop-by-hop headers must never ever defined. This is problemat= ic, > as this closing the door forever, even if future instances of the IETF do > would like to wish to define new hop-by-hop headers. A better way would h= ave > to say "that new hop-by-hop headers must have IETF consensus". If a new extension header with hop-by-hop behavior were defined, it would require a router or other forwarding device to look beyond the header immediately following the base IPv6 header, possibly even arbitrarily deep into an IPv6 header chain. That's not backward compatible with the existing specification, which was written the way it was to limit the amount of header processing required in the forwarding path. Can you provide an example of anything that can be done with a new hop-by-hop extension header that cannot also be done with a new hop-by-hop option? > - Section 4.8. "Defining New Extension Headers and Options": > > Also the =E2=80=9Enot recommended=E2=80=9C to define new extension header= s looks strange, > especially with the phrase "There has to be a very clear justification". = The > term "clear justification" is not an exact engineering specification. Why > not using "technical protocol specification and real word use case requir= ed, > plus IETF consensus"? We could perhaps make this clearer by stating that a new extension header must not be defined unless it can be proven that the desired functionality cannot reasonably be provided either by a new destination option or by a new upper layer protocol, but I'm not convinced that it's that much of an improvement - there's that pesky word "reasonably," which still implies an exercise of engineering judgment, which you seem to want to avoid. For a necessarily imprecise analysis of which of the existing extension headers meet the "cannot reasonably be provided" criterion, please see https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html Mike Heard From nobody Tue Apr 11 14:33:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8DC129AD0; Tue, 11 Apr 2017 14:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gjq1xguTv9FV; Tue, 11 Apr 2017 14:33:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7EF1200C5; Tue, 11 Apr 2017 14:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1491946412; x=1493156012; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YWRuly6ILSRCXx05zBA1Z4xsDvST5g8PLZqDI1hromQ=; b=TVA1Sj21q64lSTLsUorEpUkSVVF+vJAKNZHSTxxiFvn5QOwA9zOwrHY7 unqrrMkqIPSMuImaFPpqsJEHjokMmZFGxmciHqCBtryeUZnuyDgmi//N/ kfuNWUu12VIhKZbQ+oMTjaLTyeYKP8jkpwhlRePJS0swken3TLrYK20eD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAwChSu1Y/5ldJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgygrgWwHg1+KE5ExlXeCD4YkAhqDST8YAQIBAQEBAQEBax0LhRYGIxF?= =?us-ascii?q?FEAIBCBoCJgICAjAVEAIEDgWKEKkngiaKeQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2BC4VFggUJgmKEVoMGLoIxAQSWI4ZcAZJdCoF1iQuGOpQAAR84gQVbFVIBhEk?= =?us-ascii?q?cGYFKdYgggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,187,1488844800"; d="scan'208";a="410175494" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 21:33:31 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3BLXVbC016680 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 21:33:31 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 16:33:30 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 16:33:30 -0500 From: "Alvaro Retana (aretana)" To: "otroan@employees.org" CC: Tim Chown , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85dTThx1SRXYEO6jo/FFmbU1aG+QkcAgABhawCAABE3gIACUWmA///BWYA= Date: Tue, 11 Apr 2017 21:33:30 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> In-Reply-To: <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:33:33 -0000 T2xlOg0KDQpIaSENCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiEgIEl0IHdvdWxkIGJl IG5pY2UgaWYgdGhlIGRvY3VtZW50IGFsc28gc2FpZCB0aGlzIOKAkyBmcm9tIHdoYXQgSSBjb3Vs ZCByZWFkLCB0aGUgdGV4dCBkb2VzbuKAmXQgbWF0Y2ggd2hhdCB5b3Ugc2FpZCDigJMgb3IgZGlk IEkgbWlzcyBpdD8NCg0KQWx2YXJvLg0KDQpPbiA0LzExLzE3LCA1OjE3IFBNLCAib3Ryb2FuQGVt cGxveWVlcy5vcmciIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4gd3JvdGU6DQoNCj4NCj5UaGUgaW5p dGlhbCBzZW50ZW5jZSBtZW50aW9ucyA0IGFjdGlvbnM6IGV4YW1pbmUsIHByb2Nlc3MsIGluc2Vy dCwgb3IgZGVsZXRlLg0KPlRoZSB0ZXh0IGFscmVhZHkgc2F5cyB0aGF0IGFueSBub2RlIGNhbiBl eGFtaW5lIHRoZSBoZWFkZXJzIOKAnGZvciBhbnkgcmVhc29u4oCdLCBhY2NvcmRpbmcgdG8gW3Jm YzcwNDVdLiAgU28gbWF5YmUgdGFrZSB0aGF0IG91dCBhcyBwYXJ0IG9mIHRoZSBvcmlnaW5hbCA0 Lg0KPkkgZG8gaGF2ZSBhbiBhZGRpdGlvbmFsIGNsYXJpdHkgcXVlc3Rpb24uICBXaGF0IGRvZXMg 4oCccHJvY2Vzc+KAnSBtZWFuPyAgRG9lcyBpdCBpbmNsdWRlIGEg4oCcY2hhbmdlIGVuLXJvdXRl 4oCdPyAgICBJ4oCZbSBhc2tpbmcgYmVjYXVzZSBTZWN0aW9uIDQuMi4gKE9wdGlvbnMpIHNheXMg dGhhdCDigJx0aGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciBhbmQgdGhlIERlc3RpbmF0aW9u IE9wdGlvbnMgaGVhZGVy4oCdIGhhcyBhbiBvcHRpb24gYml0IHRoYXQgaW5kaWNhdGVzIOKAnHdo ZXRoZXIgb3Igbm90IHRoZSBPcHRpb24gRGF0YSBvZiB0aGF0IG9wdGlvbiBjYW4gY2hhbmdlIGVu LXJvdXRlIHRvIHRoZSBwYWNrZXQncyBmaW5hbCBkZXN0aW5hdGlvbuKAnS4gIEnigJltIGFzc3Vt aW5nIHRoYXQgdG8gY2hhbmdlIHRoZSBkYXRhIHRoZSB0cmFuc2l0IG5vZGUgaGFzIHRvIG5vdCBq dXN0IOKAnGV4YW1pbmXigJ0gKHdoaWNoIEkgdGhpbmsgbWVhbnMg4oCcbG9vayBhdOKAnSksIGJ1 dCBhbHNvIChhdCBsZWFzdCkg4oCccHJvY2Vzc+KAnSB0aGUgRUggYXMgd2VsbC4gICBJZiB0byDi gJxwcm9jZXNz4oCdIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRvIOKAnGNoYW5nZSBlbi1yb3V0ZeKA nSwgdGhlbiBpdCBsb29rcyBsaWtlIHRoZSBEZXN0aW5hdGlvbiBPcHRpb24gbWF5IGFsc28gYmUg YW4gZXhjZXB0aW9u4oCmDQoNCkJvdGggb3B0aW9ucyBpbnNpZGUgb2YgYW4gSEJIIG9wdGlvbiBo ZWFkZXIgYW5kIGEgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgY2FuIGhhdmUgdGhlIGNoYW5n ZSBlbi1yb3V0ZSBmbGFnIHNldC4NClRoZSBEZXN0aW5hdGlvbnMgT3B0aW9ucyBoZWFkZXIgYXJl IG9ubHkgcHJvY2Vzc2VkIGF0IHRoZSBkZXN0aW5hdGlvbiBob3N0LCBzbyBhbiBvcHRpb24gY2Fu IHRoZW4gb25seSBjaGFuZ2UgZW4tcm91dGUgd2hlbiBpdCBpcyBwYXJ0IG9mIGEgc291cmNlIHJv dXRlIHBhdGggKGFuZCB0aGUgRGVzdGluYXRpb24gb3B0aW9ucyBoZWFkZXIgaXMgYmVmb3JlIHRo ZSByb3V0aW5nIGhlYWRlcikuDQoNClRoZSAiZmVhdHVyZSIgaGVyZSBpcyB0aGF0IG9uZSBjYW4g c3BlY2lmeSBvcHRpb25zIHRoYXQgY2FuIGJlIHByb2Nlc3NlZCBvbmx5IGJ5IHRoZSByb3V0ZXJz IGxpc3RlZCBpbiBhIHJvdXRpbmcgaGVhZGVyIG9yIG9uZSBjYW4gc3BlY2lmeSBvcHRpb25zIHRo YXQgY2FuIGNoYW5nZSBlbi1yb3V0ZSBmb3IgZXZlcnkgaG9wIGFsb25nIHRoZSBwYXRoLg0KDQo= From nobody Tue Apr 11 19:33:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CAC128B88; Tue, 11 Apr 2017 19:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 ZHS5ED_TdHsn; Tue, 11 Apr 2017 19:33:38 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 622AE1242F5; Tue, 11 Apr 2017 19:33:38 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id g2so2540332pge.2; Tue, 11 Apr 2017 19:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5xMjsKMa5O6ChM6ME8T2wqbBHf8w/pmWSA1eVP9m/io=; b=JTe7Rrn2s0hhcnAmCiaemgL1jJGUTWniLbKq9wUQVB7x6KmDIvSJC+cHyOYSwCWjvD 0tWwDm5wd9EimBG96SRVAZklscnJqnKMYMSM1KthZ91m0xxYYlhKth2yiSLVimTU8pyv yNX9gj89HCtTutvhgbKpfKjZemBpA39ECBDwLswAQWpGkA1chCdxYoV5rkH25JarXqyN FyI5W5+4d2AqNRfmgUlhj+HhJZGo/CSN5MQAqBtDsRy89x5U3O2eGJjtG2FPi4u2YYkD OlXStpi8xQ1y2q0MuRzdUK6Rb7G1e7wjF6W0vmmdemNMDz8u4gE/RT2y3iDNbEjLBPFj RS7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5xMjsKMa5O6ChM6ME8T2wqbBHf8w/pmWSA1eVP9m/io=; b=iH5QMwC49YMsHhIsuGNBERVRwJrt3qlpWvuTtCoMjwl3UK56mBnaEb7IytzTtsW2YT BFf7p8DrL60c1a2NOj0S0Bi9nTQP3fjMvUAb2XHI3zhY2ksRlNFfC7ApBkQ16UvtesNf 57RH7+VOLmA8ppJUEvw1hnu+MJQQ1PTQzjkGdVmpLPC0pRrddl1xXtUfZIXQ9qHvDPqZ vawXL55nRfSAFYQZZ+OZi3IixG3oWF4QjhQ2XfOXn/Z9hr6dWPH5Y+A4HOYBlLQTSoyl N2Vk8rYa9njD0i/5fkoT0/NsS1ilaO0eCRXbmAj/w/jUzY5LeQl6F6m7vqujauOORD1b AyWA== X-Gm-Message-State: AFeK/H3f4v9PmERb3G3wURuQgwEinIKBVP3MxHyNTtbbkFp5JlY/3bzQzFg3HojG36mfmg== X-Received: by 10.98.67.157 with SMTP id l29mr65955704pfi.251.1491964418028; Tue, 11 Apr 2017 19:33:38 -0700 (PDT) Received: from [172.26.34.236] ([104.129.192.114]) by smtp.gmail.com with ESMTPSA id 65sm32905749pgc.1.2017.04.11.19.33.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 19:33:37 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: otroan@employees.org References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> <4313570D-3C60-4872-B8C4-3CA76C1B240A@employees.org> Cc: Tim Chown , "Alvaro Retana (aretana)" , "draft-ietf-6man-rfc2460bis@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG , Suresh Krishnan , The IESG From: Brian E Carpenter Organization: University of Auckland Message-ID: <069ba2b9-1cee-f440-113b-0b4b7f7160ff@gmail.com> Date: Wed, 12 Apr 2017 14:33:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4313570D-3C60-4872-B8C4-3CA76C1B240A@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:33:40 -0000 Ole, On 12/04/2017 09:11, otroan@employees.org wrote: >> Excuse front posting, but the interleaving is getting a bit distracting in itself. >> >> My considered opinion is that pretending to forbid "examine" is just laughable, >> since we know that middleboxes make it their job to examine packet headers. >> So it's pointless to state it; take it out (but leave in the reference to 7045). >> >> The word "process" is too vague - and has been too vague since RFC 1883. >> So take that out too. (Clearly, a middlebox that can examine a header >> can process it - but so what? That doesn't affect the contents of the >> packet.) >> >> What we can meaningfully prohibit in the context of Internet-wide interop >> is "insert, modify or delete". > > 2460 doesn't (largely nor does the IETF) specify middlebox behaviour. > I am opposed to accommodating middleboxes in 2460. > > The point of this text as I read it, is to specify what 2460 routers need to do. And the requirement for IPv6 forwarding is to only process the IPv6 base header (with one exception (HBH)). I completely agree with that last sentence, but where does 2460bis state that this is the scope of the document? Brian From nobody Tue Apr 11 19:47:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D23126C7A for ; Tue, 11 Apr 2017 19:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 r1yiQz_YQNA6 for ; Tue, 11 Apr 2017 19:47:46 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 B91891242F5 for ; Tue, 11 Apr 2017 19:47:46 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id x125so7536845pgb.0 for ; Tue, 11 Apr 2017 19:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=vzEtAv0Pbsao/sZZ9warQekY45znDUno2XMHnazNlYw=; b=Y+YGnhmFb580R7O3bz9pTHe1O5Dw/TTKj2RVlyZRVtSy3T5igsxY7NcXz367VYPvDv 7LTDfcArko/S7kM8oCmduPgBQ9M844vA1U+PHh4yDXN/dPKhs9LJiYvgIp7gKMftPaGX XKiMXHrhyOg0UkBrYFB+aGsLKiBfC1nhJk3G8XucJw8OCmBZDUM3/4ZVFIPzujzbZKzH +ObiTzpwcdCtjd0m3qumXgSvGRHSv4IjLf4v0MdNj7DzRvU5QXgisu201KUK/dhbM+mF KjCs0c/qg6qkNLkScNlSY5oFwZkbcdHFO0q3v+4/EdN3ncm1A7k0uODZAOAe9gYx6pML dBbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=vzEtAv0Pbsao/sZZ9warQekY45znDUno2XMHnazNlYw=; b=BX89tOfJJT4qHb5C8LgpVAj6rFxQzAnq7ZSfnl26E7ARCxxGpkH4LE19mPOwHUuQe7 pWmuIcLQxOdy5jA2VCF8wo9IopfteYcf4f7Gi+rdVDu09A2S0trc17XkCMFhJD+gx55S JZ7RcEKV6DZq3PbKX8Bvs1KvUp9HM4OlosZXHHImelbQSWgz+VKTcLAGHLS8lppgYFE9 CjVXlyz7edz9GZWLH0TLJJiEknwp3ECZyVIzzjJ93BDDN3FjIdl+0sbLv6Qjc3bME/cy TIZxOTGayOTJCxDBuwLsz5hZ+tk6uonjPQYEgtVI2YHh3pvmAYrVkYTYDVifijzerhqN zSFw== X-Gm-Message-State: AN3rC/6DHBjL8XoM9lhcXafkUJITvJwwXDHy29PCKlYaEr4Eq37/rzcrHpzxov7qVK4pEw== X-Received: by 10.99.148.26 with SMTP id m26mr8079105pge.92.1491965266164; Tue, 11 Apr 2017 19:47:46 -0700 (PDT) Received: from [172.26.34.236] ([104.129.192.114]) by smtp.gmail.com with ESMTPSA id s3sm32976066pgn.29.2017.04.11.19.47.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 19:47:45 -0700 (PDT) Subject: Re: TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <7148a2b4-fd72-b13a-a3bd-cd3a3ac09f58@gmail.com> Date: Wed, 12 Apr 2017 14:47:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:47:49 -0000 On 12/04/2017 09:31, C. M. Heard wrote: > On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: >> Major issues: >> >> - Section 4.8. "Defining New Extension Headers and Options": >> >> It says new hop-by-hop headers must never ever defined. This is proble= matic, >> as this closing the door forever, even if future instances of the IETF= do >> would like to wish to define new hop-by-hop headers. A better way woul= d have >> to say "that new hop-by-hop headers must have IETF consensus". >=20 > If a new extension header with hop-by-hop behavior were defined, > it would require a router or other forwarding device to look > beyond the header immediately following the base IPv6 header, > possibly even arbitrarily deep into an IPv6 header chain. That's > not backward compatible with the existing specification, which was > written the way it was to limit the amount of header processing > required in the forwarding path. >=20 > Can you provide an example of anything that can be done with a > new hop-by-hop extension header that cannot also be done with > a new hop-by-hop option? Also consider that all our experience is that router designers are mainly allergic to even the existing HbH header. So adding a new one would really be a lost cause anyway. >=20 >> - Section 4.8. "Defining New Extension Headers and Options": >> >> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension hea= ders looks strange, >> especially with the phrase "There has to be a very clear justification= ". The >> term "clear justification" is not an exact engineering specification. = Why >> not using "technical protocol specification and real word use case req= uired, >> plus IETF consensus"? >=20 > We could perhaps make this clearer by stating that a new extension > header must not be defined unless it can be proven that the desired > functionality cannot reasonably be provided either by a new > destination option or by a new upper layer protocol, but I'm not > convinced that it's that much of an improvement - there's that > pesky word "reasonably," which still implies an exercise of > engineering judgment, which you seem to want to avoid. >=20 > For a necessarily imprecise analysis of which of the existing > extension headers meet the "cannot reasonably be provided" > criterion, please see >=20 > https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html And also consider that deploying new extension headers is hard to impossible anyway, for reasons discussed in RFC 7045. We do need to set the bar very high. I'd have no objection to adding IETF consensus, if it isn't already implied. Brian From nobody Tue Apr 11 22:35:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA48B1287A7; Tue, 11 Apr 2017 22:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GAVTyF0nKzoi; Tue, 11 Apr 2017 22:35:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98D8127B31; Tue, 11 Apr 2017 22:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3990; q=dns/txt; s=iport; t=1491975311; x=1493184911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FoZJmQUwfvc68+FxqIhPbvNUOGBUSc4TawPV5lRG5BM=; b=EnDJsGDebsswHgZfHFi/5goPSnDOx8Lap9vMIRcCF2J3xWQtr8JEqtIj eD+nMpQSGgAzv2vYwRn/c7+kgzIgoib+L3PPSesNLgpW63qxv+HYvRFqM eD4ASmXuNIoW9S+zKosInBO7Iw21i3wMkgtwqF1aN5mYapWMvxxheBApW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQCru+1Y/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeNcpExH4gajT6CD4YkAoNkPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBOg0yBQsCAQgYHhAhESUCBA4FiX0DDQirNYM+g20Ngz0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhlCCBQmCYoJRggWDNIIxBZxEOwGOG4RCkUSLAYh/AR84gQV?= =?us-ascii?q?bFVIBhH6BSnWIIIENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,188,1488844800"; d="scan'208";a="409183975" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 05:35:10 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3C5ZAWZ017717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 05:35:10 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 01:35:09 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 01:35:09 -0400 From: "Stefano Previdi (sprevidi)" To: Mark Smith CC: Stefano Salsano , "draft-ietf-6man-rfc2460bis@ietf.org" , 6man WG , Suresh Krishnan , "The IESG" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSsrvjcUCcsmuI5ESTcvAsxgbkLaHAnyoAgABUMQCAAIdbgA== Date: Wed, 12 Apr 2017 05:35:09 +0000 Message-ID: <07CFB3E3-655F-4011-BBB9-B00365C63351@cisco.com> References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <51BC7360-A314-4A06-B160-0C3F21FB0B17@jisc.ac.uk> <808fb664-7f48-ae20-2405-9f875c03d605@gmail.com> <06f690d1-710c-7093-8eea-f37e89434992@uniroma2.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.161.35] Content-Type: text/plain; charset="us-ascii" Content-ID: <40922125B94BD74EA08C288D44ED1F84@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 05:35:18 -0000 > On Apr 11, 2017, at 11:30 PM, Mark Smith wrote: >=20 > On 12 April 2017 at 02:29, Stefano Salsano = wrote: >> Il 2017-04-11 14:02, Mark Smith ha scritto: >>>=20 >>> You spec could state that packets that have had EHs inserted MUST have >>> them removed, however in practice, they may not be removed because of >>> implementation bugs, device misconfiguration or partial device failure. >>>=20 >>> This failure to remove them will not be visible to the domain that adde= d >>> them, because there are no local SR domain consequences of that failure= . >>> Other receivers may suffer the consequences, yet there is nothing to >>> indicate in the packet which device or domain inserted the EH. >>>=20 >>> Consider this scenario, using an AS boundaries as a EH insertion domain >>> boundaries, with the packet travelling left to right, and this being a >>> path across the Internet. Imagine being at one of the ASes upstream of >>> one or both of the EH insertion ASes, trying to work out which one >>> inserted the EH and didn't remove it successfully. >>>=20 >>> [pkt src AS]--[AS1]--[EH INS ASX]--[AS2]--[EH INS >>> ASY]--[AS3]--[AS4]--[pkt dst AS] >>>=20 >>> To make this example more visceral, imagine [pkt src AS] is a >>> residential ISP who has with 10 of 000s of customers failing to access = a >>> streaming VoD provider at [pkt dst AS]. Those angry customers will be >>> ringing [pkt src AS]'s helpdesk, increasing their support costs, market >>> reputation and possibly cost them customers, and [pkt dst AS] will be >>> losing reputation, revenue and possibly customers while this >>> troubleshooting is going on. >>=20 >>=20 >> Dear Mark, >>=20 >> I want to clarify that the example you provided does not apply to the >> "controlled domain" insertion discussed in >> draft-voyer-6man-extension-header-insertion >>=20 >=20 > I'm not talking specifically about > draft-voyer-6man-extension-header-insertion. This is a general example > of what could happen if packets that have inserted EHs leak outside > the notional controlled domain this does NOT happens for the simple reason that both SA and DA are within = the domain. IOW, a packet reaches its destination within the domain, not ou= tside. s. > (it also serves as a more general > example of the problems of any operation that makes flight structural > modifications to packets that aren't attributable to the device that > makes them). >=20 >> according to draft-voyer-6man-extension-header-insertion, >> ASX and ASY of your example are NOT allowed to insert EH in the packet >> originated by src AS >>=20 >> the EH is inserted in a outer packet which encapsulates the original one= and >> with with a destination IPv6 address within the "controlled domain" >>=20 >=20 > They can still leak, c.f. RFC1918s. >=20 > In draft-voyer-6man-extension-header-insertion why have two methods > that achieve exactly the same outcome, with the only selection > criteria for the method being whether the traffic is originated > externally or internally? >=20 > Pick one that can serve both purposes that is most similar to existing > mechanisms, leverages existing deployed devices if possible, is the > one that will cause the least damage if it fails and is the easier and > quickest of the two to troubleshoot. >=20 >> if you want to map your example into something that is aligned with >> draft-voyer-6man-extension-header-insertion, it should become something = like >> the following (covering only EH insertion on ASX): >>=20 >> [pkt src AS]--[AS1]--[ASX:encapsulation of the packet in a new outer pac= ket] >> [ASX:EH INS on the outer packet ]--[ASX:decapsulation of the packet]-- >> [AS2]-- [....] -- [pkt dst AS] >>=20 >=20 > That's the model that I think should be used for all cases i.e. both > internal and externally originated traffic. >=20 > Regards, > Mark. From nobody Wed Apr 12 01:37:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816CA129C67 for ; Wed, 12 Apr 2017 01:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 Cq_D0vDfM9NN for ; Wed, 12 Apr 2017 01:37:39 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E908812EA97 for ; Wed, 12 Apr 2017 01:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1491986256; bh=1msFiijCs6dLh3mbV9W+dNAFRwSA3PDWmI052dlcdoQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DHETpHwdTAf0fVeDd2KJ2Lu7mYGypyjnNdJjgzry0P/f23A88YLGeKsPQP9br5OA3wosqwLtZjSW+UqJQwVR24LTYVmdCPeHUG1+PWqgDgBaEhb9rINTHUc3yB4ZkVSXeJJak3x1NBgtJWSCNk0GciWCO1yPRbLRBuq3yjTOsKU= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-64-fo4McN2aOvOFN2RG20FU8w-1; Wed, 12 Apr 2017 09:37:32 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 08:37:30 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::29d9:4eb6:edcf:55dc%14]) with mapi id 15.01.1034.009; Wed, 12 Apr 2017 08:37:30 +0000 From: Tim Chown To: Lorenzo Colitti CC: Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , "ipv6@ietf.org" , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Topic: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)) Thread-Index: AQHSsnhL+TGQiQhuW0ybIahc30o+YqG/jSCAgAHd+YA= Date: Wed, 12 Apr 2017 08:37:30 +0000 Message-ID: <6A96A6DB-7ED1-40E7-B5EF-CC328CB20FAD@jisc.ac.uk> References: <84C37E3E-2908-449E-83E1-5FDC11E28690@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [152.71.207.141] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:L1oWiTVWVw/99Wz6vM/5uAE39Yoly8WDr7Kk+owDk+D3YOIoYnovVfZhKweNeUI29NFLs23N5x9O2l+Vl1b0qFrK9NjYrP/KiufACdKWUnvCmRx+rutV0eaa+Dg0XJkE2MopPOfT7SMhL1SaSA9J+PrhUtjH/Yk2JNHwJRHCke5KwCQl2bKf0iQkHhfnifwATzTvrTqzgN0bQoBng9UbAUdcyvlXlGiDwJINxB12Y7q98u3D+9li1Phk1XyAgbEAMIUkvRxs7lMJRp6yI2/dRsH82vSdkwX4WuYdj2hM3BIvOtncnvp3UntvL45Sxe6oJMzOFAFIylQwjhK1/8abvg==; 20:Z+r0rzz+5OO/qNoTMUJCz9MfNeAfnD8bYhKDX049Acyi/5LukRi4wHrioc49pBp/Eb9g9RK6vlBRr52TK7B7qc5sVgxR+yPmqDI4vBN5wnE592/hnmtgXkxjHm2b15kl4ABhjvAY2nWLTwWLwYsUUF10NxNEOyu9atixs9LMvkM= x-ms-office365-filtering-correlation-id: 13bef839-8d05-4f84-9e23-08d4817f289a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1138; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39450400003)(39400400002)(24454002)(377454003)(5250100002)(7736002)(189998001)(6246003)(2906002)(5660300001)(3280700002)(3660700001)(102836003)(36756003)(3846002)(6506006)(6116002)(25786009)(53936002)(2900100001)(76176999)(50226002)(42882006)(50986999)(8936002)(2950100002)(74482002)(110136004)(6512007)(83716003)(82746002)(4326008)(54906002)(6916009)(81166006)(305945005)(8676002)(53546009)(66066001)(99286003)(229853002)(230783001)(6436002)(86362001)(33656002)(6486002)(38730400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <11E1A5F0E98DB8499D56912E580DF3F0@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 08:37:30.7483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: fo4McN2aOvOFN2RG20FU8w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:37:41 -0000 PiBPbiAxMSBBcHIgMjAxNywgYXQgMDU6MDYsIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29n bGUuY29tPiB3cm90ZToNCj4gDQo+IE9uIFR1ZSwgQXByIDExLCAyMDE3IGF0IDE6MDEgUE0sIFN1 cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IEkg YW0gc3RydWdnbGluZyB0byB1bmRlcnN0YW5kIHdoeSB0aGluZ3MgYXJlIGFueSBkaWZmZXJlbnQg bm93IHdpdGggaGVhZGVyIGluc2VydGlvbi4gSSBhbSBleHBlY3RpbmcgdGhlIHByb3BvbmVudHMg b2YgaGVhZGVyIGluc2VydGlvbiB0byBkbyBleGFjdGx5IHdoYXQgdGhlIHByb3BvbmVudHMgb2Yg emVybyBVRFAgY2hlY2tzdW1zIGRpZCBhbmQgZG8gdGhlIGdyb3VuZHdvcmsgZm9yIHVwZGF0aW5n IFJGQzI0NjBiaXMuIFRoZXJlIGlzIG5vIOKAnHNwZWFrIG5vdyBvciBmb3JldmVyIGhvbGQgeW91 ciBwZWFjZeKAnSBtb21lbnQgaGVyZS4gV2UgYXJlIG5vdCBjbG9zaW5nIG9mZiBhbnkgYXZlbnVl cyBvZiBmdXR1cmUgZXh0ZW5zaWJpbGl0eS4gVGhlIGZ1dHVyZSBleHRlbnNpYmlsaXR5IHByb3Bv c2FscyB3aWxsIGJlIGp1ZGdlZCBvbiB0aGVpciBvd24gbWVyaXRzLiBHaXZlbiB0aGF0IHRoZXJl IGlzIGV4aXN0ZW5jZSBwcm9vZiwgSSB3b3VsZCBsaWtlIHRvIGJldHRlciB1bmRlcnN0YW5kIHdo eSB0aGlzIHNhbWUgc3RyYXRlZ3kgd2lsbCBub3Qgd29yayBpbiB0aGUgaGVhZGVyIGluc2VydGlv biBjYXNlLiBJIGJlbGlldmUgdGhhdCB3b3VsZCBiZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9y IGEgY29uc3RydWN0aXZlIGRpc2N1c3Npb24gZ29pbmcgZm9yd2FyZC4NCj4gDQo+IEhlYXIsIGhl YXIuIEZyYW5rbHkgSSdtIHN1cnByaXNlZCB3ZSdyZSBldmVuIHN0aWxsIHRhbGtpbmcgYWJvdXQg dGhpcy4gQW55dGhpbmcgd2UnZCBsaWtlIHRvIGRvIG9uIHRoaXMgdG9waWMgaXMgYWNoaWV2YWJs ZSB2aWEgYW4gdXBkYXRlIHRvIHdoYXRldmVyIGRvY3VtZW50IFJGQzI0NjBiaXMgYmVjb21lcy4g VGhlIHNvb25lciB3ZSBzdGFydCB3b3JrIG9uIHN1Y2ggYW4gdXBkYXRlLCB0aGUgc29vbmVyIGl0 IHdpbGwgYmUgcHVibGlzaGVkLg0KDQpBZ3JlZWQuIFJGQzI0NjAgYXMgaXQgc3RhbmRzIGhhcyBi ZWVuIHVwZGF0ZWQgYnkgOSBSRkNzIGluIDE5IHllYXJzIHNpbmNlIHB1YmxpY2F0aW9uLiBBbmQg aXTigJlzIGhpZ2hseSBwcm9iYWJsZSB0aGVyZSB3aWxsIGJlIGZ1dHVyZSB1cGRhdGVzIHRvIHRo ZSBwdWJsaXNoZWQgMjQ2MGJpcyBhcyBuZXcgSVB2NiBpbm5vdmF0aW9ucyBhcmUgZGVmaW5lZCBp biB0aGUgSUVURiBvdmVyIHRoZSBjb21pbmcgNSwgMTAgb3IgMjAgeWVhcnMuIFdlIGRvbuKAmXQg bm93IHdoYXQgdGhvc2UgaW5ub3ZhdGlvbnMgYXJlIHlldCwgYmV5b25kIHRoZSBwcm9wb3NlZCB3 b3JrIG9uIEVIIGluc2VydGlvbiwgYnV0IHRoZXkgd2lsbCBjb21lOyAyNDYwYmlzIGlzIG5vdCBz ZXQgaW4gc3RvbmUganVzdCBiZWNhdXNlIGl0IGhhcyBhbiBJUyBzdGFtcCBvbiBpdC4NCg0KVGlt DQoNCg== From nobody Wed Apr 12 08:34:38 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5A131747; Wed, 12 Apr 2017 08:34:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6man-rfc2?= =?utf-8?q?460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 08:34:30 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 15:34:30 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My discuss is mainly on text in section 4.8 (also based on the tsv-art review -> Thanks Martin!): I find the recommendation to basically just not use hop-by-hop headers in section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it be maybe time to just deprecate the current hop-by-hop number an assign a new one? I know that also has deployment problem but maybe it's worth a try. I guess the assignment could happen in a new document though, but the deprecation could be done here. This related to this comment from Martin's review, also proposing a potential way forward: "- Section 4.8. "Defining New Extension Headers and Options": It says new hop-by-hop headers must never ever defined. This is problematic, as this closing the door forever, even if future instances of the IETF do would like to wish to define new hop-by-hop headers. A better way would have to say "that new hop-by-hop headers must have IETF consensus". - Section 4.8. "Defining New Extension Headers and Options": Also the „not recommended“ to define new extension headers looks strange, especially with the phrase "There has to be a very clear justification". The term "clear justification" is not an exact engineering specification. Why not using "technical protocol specification and real word use case required, plus IETF consensus"?" As a side note, there is at least one experimental RFC that defines a destination option to be inspected by a network device, given the know problems of hop-by-hop option which renders them unusable. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question because I'm not sure if I interpret this correct to make it part of my discuss: Section 4.5: "The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet." Does this mean the ECN codepoint (part of the Traffic Class field) is copied from the first fragment? This doesn't seem to be correct, however, also not sure what the correct answer is. I know this was not changed in this revision but maybe we can still get this right. From nobody Wed Apr 12 09:42:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F26129543 for ; Wed, 12 Apr 2017 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 3FVA45mPhTtG for ; Wed, 12 Apr 2017 09:42:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC89A129540 for ; Wed, 12 Apr 2017 09:42:00 -0700 (PDT) Received: (qmail 32698 invoked from network); 12 Apr 2017 18:41:58 +0200 Received: from p5dec24e1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.225) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Apr 2017 18:41:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 12 Apr 2017 18:41:58 +0200 Cc: Martin Stiemerling , 6man WG , TSV-ART Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:42:04 -0000 Hi Mike, > Am 11.04.2017 um 23:31 schrieb C. M. Heard : >=20 > On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: >> Major issues: >>=20 >> - Section 4.8. "Defining New Extension Headers and Options": >>=20 >> It says new hop-by-hop headers must never ever defined. This is = problematic, >> as this closing the door forever, even if future instances of the = IETF do >> would like to wish to define new hop-by-hop headers. A better way = would have >> to say "that new hop-by-hop headers must have IETF consensus". >=20 > If a new extension header with hop-by-hop behavior were defined, > it would require a router or other forwarding device to look > beyond the header immediately following the base IPv6 header, > possibly even arbitrarily deep into an IPv6 header chain. That's > not backward compatible with the existing specification, which was > written the way it was to limit the amount of header processing > required in the forwarding path. >=20 > Can you provide an example of anything that can be done with a > new hop-by-hop extension header that cannot also be done with > a new hop-by-hop option? Given the current hop-by-hop header is partially not usable, = everything=E2=80=A6 I thinking would be to basically replace/deprecate the old one and = define a new one. >=20 >> - Section 4.8. "Defining New Extension Headers and Options": >>=20 >> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >> especially with the phrase "There has to be a very clear = justification". The >> term "clear justification" is not an exact engineering specification. = Why >> not using "technical protocol specification and real word use case = required, >> plus IETF consensus"? >=20 > We could perhaps make this clearer by stating that a new extension > header must not be defined unless it can be proven that the desired > functionality cannot reasonably be provided either by a new > destination option or by a new upper layer protocol, but I'm not > convinced that it's that much of an improvement - there's that > pesky word "reasonably," which still implies an exercise of > engineering judgment, which you seem to want to avoid. >=20 > For a necessarily imprecise analysis of which of the existing > extension headers meet the "cannot reasonably be provided" > criterion, please see >=20 > https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html I have to say I find this phrasing also to be useful. I guess the real = point is to recommend to rather use a destination option if possible = than defining a new extension header. Mirja >=20 > Mike Heard >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art From nobody Wed Apr 12 12:31:44 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B512957F; Wed, 12 Apr 2017 12:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Alissa Cooper's No Objection on draft-ietf-6man-rfc2460bis-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202550312.15690.13102264583704924554.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 12:31:43 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:31:43 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please have a look at the changes suggested in Peter's Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-6man-rfc2460bis-08-genart-lc-yee-2017-02-28/ From nobody Wed Apr 12 12:32:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02912952C; Wed, 12 Apr 2017 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=l2itjAqw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ehgg10RP 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 1lmg5fQtfbaD; Wed, 12 Apr 2017 12:32:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA97012EB3F; Wed, 12 Apr 2017 12:32:16 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6080020EB1; Wed, 12 Apr 2017 15:32:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 12 Apr 2017 15:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=aSuH1/uTq2A829KkXT 8jfzadRmcL4KmPPNH5iNl07dY=; b=l2itjAqw5LAuQg0oDoXVaQr36PigAETxQk PErdZueIrKiCIAsO/81wRbJnYQ9yQjQeadIpvlWOn0u0oymIYCNs8enwTSZBiwSd zJgrFRnnOEUz3BhiAX0XwWWNZeMPnBkWHvZEUpgHA8vWRvykRY9JLk865JohfOiI frID2TEIGrWjKbMmp2nuxnAqtR6Rp2uiiVX6qiXGQn+pXjWjOyTB0Lm64rOPY9ZF o8HyqhUqT8whraNXZZtg33fatz3PiFVTDpGaV2lBYjBu0JhuiH1IAYTud0dDub5D v3u1YXzW8gqoUjTnmnHWkzmXnaG8hlMbxt3g6kOjNiPj+Thb1R8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=aSuH1/uTq2A829KkXT8jfzadRmcL4KmPPNH5iNl07dY=; b=Ehgg10RP XWj0rlqMFxtgkFKeLbuhYmsH1KOy5C/VsBHcaLm147Se3Tv8yNwg5iXq1Av4TJkv zO8o8C6PphwaTc/nlkG+5R49YhbHkObTcnuevwbAfCMhEyldjvrQl3vTSWNhwe0n JN5dibKREEisRwg6OCEv5/wj5cWUMZemCZNKcCNTWE4sRehyd3xozj/D3XhYda/4 pEGk/05Y/+E1HOeg7q8QkkZMvKtnq5EHtY9vK4mVNAov3kZ79XeAn9/gSNeaeivF I7jPEqX0rq8OGT4BOUKwlrvKXq5K0FKO+S0d9+xL6zwmEwuUfhoBxQK8JzeQMlD2 tT528K2X1BrWaA== X-ME-Sender: X-Sasl-enc: o0u3PNllqODVO8VF5ta9doJwwoWPNJOFeRoFCqqKaJH/ 1492025535 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F45824722; Wed, 12 Apr 2017 15:32:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Review of draft-ietf-6man-rfc2460bis-08 From: Alissa Cooper In-Reply-To: <148834537055.29494.17692224713818414298.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 15:32:12 -0400 Cc: gen-art@ietf.org, draft-ietf-6man-rfc2460bis.all@ietf.org, IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <5A651777-8781-47E8-ACAB-FFC72E0BE0D5@cooperw.in> References: <148834537055.29494.17692224713818414298.idtracker@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:32:21 -0000 Peter, thank you for your review! I have asked the authors/WG to = consider your suggestions in my ballot. Alissa > On Mar 1, 2017, at 12:16 AM, Peter Yee wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-6man-rfc2460bis-08 > Reviewer: Peter Yee > Review Date: 2017-02-28 > IETF LC End Date: 2017-03-01 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready with nits. This Internet-Draft is an update to RFC > 2460, the specification for IPv6. See the following note. >=20 > Note that I read this document in the context that it is an update of > RFC 2460, primarily for the purpose of cleaning up minor items (things > that to moved to other documents, for example) and addressing errata.=20= > I did not do a top-to-bottom review of the document as though it were > a wholly new work. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments:=20 >=20 > General: >=20 > For RFCs named outside of references (i.e., those that aren't found in > square brackets), separate "RFC" from the following numbers with a > space. This is especially prevalent in Appendix B. >=20 >> =46rom the mailing list discussion back in 2015, I can't determine if = an > actual decision was taken as to whether RFC 2119 recommended/expected > language ought to be used in this document. The discussion mentioned > leaving the topic for IETF LC, but I can't even tell if there was > consensus to do that. This document does not use RFC 2119 language > primarily because it is minor update to RFC 2460, which itself did not > use RFC 2119 language. There was a healthy debate on the mailing list > and I feel it came down mostly on the side of using RFC 2119, but > again no consensus was obvious, just a preponderance of opinions. The > thread starts here: > https://www.ietf.org/mail-archive/web/ipv6/current/msg23284.html >=20 > Change all uses of "en-route" to "en route". Usage is mixed in the > document, but en-route is never used before a noun and as a borrowed > word from French would arguably not even be hyphenated had it appeared > before a noun. We won't even get into italicizing it. ;-) >=20 > Change all uses of "behaviour" to "behavior". Although both British > and American English are permissible, it seems preferable that only > form be used in any particular document. Given so many other > Americanized spellings in the document, I'm recommending going with > American English in this case. >=20 > Specific: >=20 > Page 20, 5th bullet item, 2nd paragraph, 2nd sentence: delete "an" > before "overlapping". >=20 > Page 22, Section 4.8, 1st paragraph, append a comma after "because". >=20 > Page 23, 1st partial paragraph, 1st full sentence: insert "be" before > "a". >=20 > Page 23, 1st full paragraph, 2nd sentence: insert "be" before "a". >=20 > Page 23, 2nd full paragraph: consider changing "need to" to "must".=20 > (Ignoring any decision taken on RFC 2119 usage.) I don't believe the > "need to" at the top of this page needs to(!) change as it describing > what designers need to do, not placing a restriction on a protocol > element. >=20 > Page 23, Header Specific Data definition: change the comma to a > period. >=20 > Page 26, 2nd bullet item, 1st sentence: delete the comma after > "node". >=20 > Page 26, 3rd bullet item, 2nd sentence: change "use" to "Use" in the > title of RFC 6936. >=20 > Page 29, Section 12.1, [I-D.ietf-6man-rfc4291bis] reference: update > -06 to -07 to reflect the current version of that draft. >=20 > Page 34, Appendix B title: change to "Changes since RFC 2460". >=20 > Page 35, 1st 07) item: change "IPSEC" to "IPsec". >=20 > Page 39, 01) item: delete an extraneous space before "and". >=20 From nobody Wed Apr 12 12:54:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683DC12778E; Wed, 12 Apr 2017 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 6qHyUan0uq14; Wed, 12 Apr 2017 12:54:19 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 6AAE9124B0A; Wed, 12 Apr 2017 12:54:18 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id a103so56243727ioj.1; Wed, 12 Apr 2017 12:54:18 -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=yqt7rAVDFgHc7zMPC9M1M3o1lmeTBw8VXLPK9rUT4wQ=; b=ZcUVWm94xWz6ke+Xq/OYqgmzed8MpTfCHt64+jtbOiDNzR2PR3rRaXttRF3qYWlMOR KeAY8bNCTrN+ZH4Huv54vXD1omRSuh+yhxN+AMOYOU0UucdBkEdL+5tbMkLnlCdxvDz+ da/6Yyyk+GHQ/YJ2FehCbMtGNDhEFMLbBuSLJk7+lTkZdnOIA8e1j08tyky1C6/po/VD DG9dKmor8eMkziO00rr2AvMGUc8BfFeDtMACW7GrwGUAkCEqMLvwx1E3ZpDkchNfWCGh bhwCvE1xdEu9jA/fvl6b/hQlUE3d7qOtgSwkL5gJCpT4mzMl3uedxvZJVVS5wZSzkEYO B3tg== 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=yqt7rAVDFgHc7zMPC9M1M3o1lmeTBw8VXLPK9rUT4wQ=; b=lkVqaCHAueJKT1v2dT/hXReefMfDmdY8BdStAQTk5bnNoZoRQwOLWdL8F3y0/uYFbn YBD/inNe0oZiWTuhYMOcmO1KZ+RpjqrzGspukPgraFh/ao6OiuWaSH7je5DXMriucJwb Fs+2HI8/cXZqQLdnbyZGKsyjgUm0ahnvkARx9vUV1zEW4DOhlUUUEQ6P1+gI+b1EI3+Z oZgzWOayJ60nW9LM2c9P37IjbeOLmPJVjphRFL1/iQWFaIo57i7u30UbHm1NkcHe77KF 6TXiiOQaQdLUeLhY8a6gonx/fKmLT2hdEVWomr1vXoq9dAHRkNPyB0zGNjk/nn9uNU/N zpGg== X-Gm-Message-State: AN3rC/6A269gLotWbGR2lmUfOkzZo5GzvDMPTQ7iB6pqsa/rRZ7iHTDJ9b3VUDD9qd2Cmw== X-Received: by 10.107.20.81 with SMTP id 78mr9534100iou.219.1492026857776; Wed, 12 Apr 2017 12:54:17 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c41sm2880773itd.5.2017.04.12.12.54.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:54:17 -0700 (PDT) From: Bob Hinden Message-Id: <3016FFF1-0676-4063-A884-9AE460314A09@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TSV-ART review of draft-ietf-6man-rfc2460bis-09 Date: Wed, 12 Apr 2017 12:54:15 -0700 In-Reply-To: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> Cc: Bob Hinden , IPv6 List , tsv-art@ietf.org To: Martin Stiemerling References: <1ff5b4e0-c2bb-0f00-97af-c1b888e29833@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:54:21 -0000 --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Martin, Thanks for your review. Comments below. Thanks, Bob > On Apr 11, 2017, at 12:14 PM, Martin Stiemerling = wrote: >=20 > Hi, >=20 > I've reviewed this document as part of the transport area review team = (TSV-ART) ongoing effort to review key IETF documents. These comments = were written primarily for the transport area directors, but are copied = to the document's authors for their information and to allow them to = address any issues raised. When done at the time of IETF Last Call, the = authors should consider this review together with any other last-call = comments they receive. Please always CC tsv-art@=E2=80=A6 if you reply = to or forward this review. >=20 > Sorry for being so late with the review... >=20 > Summary: > This draft has serious issues out of a transport area perspective, = described in the review, and needs to be rethought. >=20 > Major issues: >=20 > - Section 4.8. "Defining New Extension Headers and Options": >=20 > It says new hop-by-hop headers must never ever defined. This is = problematic, as this closing the door forever, even if future instances = of the IETF do would like to wish to define new hop-by-hop headers. A = better way would have to say "that new hop-by-hop headers must have IETF = consensus=E2=80=9D. I think there is a misunderstanding here. There can only be one = hop-by-hop header. It has to be the first extension header in the = packet. =46rom Section 4: The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. I think the text in Section 4.8 is correct: New extension headers that require hop-by-hop behavior must not be defined because, as specified in Section 4 of this document, the only Extension Header that has hop-by-hop behavior is the Hop-by-Hop Options header. New Hop-by-Hop header options (that go inside of a hop-by-hop header) = can be defined, but are not recommended. >=20 > - Section 4.8. "Defining New Extension Headers and Options": >=20 > Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, especially with the phrase "There has to be a = very clear justification". The term "clear justification" is not an = exact engineering specification. Why not using "technical protocol = specification and real word use case required, plus IETF consensus=E2=80=9D= ? Personally, I think the writing is clear. It does mention = standardization: There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. =E2=80=9Cstandardization=E2=80=9D implies IETF consensus, etc., etc. We could change it is "standardized in the IETF=E2=80=9D or similar. >=20 >=20 > Minor issues: >=20 > none. >=20 > Thank you, >=20 > Martin Stiemerling >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7oXnAAoJEK7rdBF357uoJMAIAKJEI07F98DMh9FQ16Xejk53 zZUYR9jAmhI8y3mbXryVoBz7g0mRVnncd2KB9JiHG4tzec/Ilfjf8RJRwf/itLiq F9b08F4bFlEpYqWfTvfLAuoaRzZRZSnKppNzaCrVNFThkizDUyfwtak3qGNCjmwZ /TOevQXSPyPB2k810HZI0aSUhjp++/w9VgNEyPK+xcParr+1Xsjqji1q/hS5o6xs XJ1KUfV3ldKHSpi9ouqnD/TnDq7eO6qCqqYfWJ01Lr5IgVyU9RmHBXMz5/Hwt/LY dHnzdzouIgNGfPIbDu2HIF+oePP/2phZJMBMnmv7vcwTBft/sarThWIeKeLwGUg= =KBNH -----END PGP SIGNATURE----- --Apple-Mail=_DD824BA7-141B-496F-9C86-72D5F128E203-- From nobody Wed Apr 12 13:35:12 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D674F12EB55; Wed, 12 Apr 2017 13:35:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Ben Campbell's No Objection on draft-ietf-6man-rfc2460bis-09: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202930186.15730.11137897885015072161.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 13:35:01 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:35:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ekr's DISCUSS. Otherwise, thank you for structuring this bis draft in a way where the diff tools are actually helpful. From nobody Wed Apr 12 13:36:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C601243F3; Wed, 12 Apr 2017 13:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 YFGmZqpJ4o-B; Wed, 12 Apr 2017 13:36:05 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id EB46F129AC4; Wed, 12 Apr 2017 13:35:59 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 12 Apr 2017 20:35:59 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 35760D788B; Wed, 12 Apr 2017 13:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=aKCQ1EjYmt5fZXu3E9JITmnwmg0=; b= dpSz/w+MpiohRyoiHk8loWicRjnR1H8L+Jej8kKW/IWSXfr29CDsBWw1tYVmYrD8 0nhq4yJJ5d+lnBMgUExGaPYR2DtglUTrYevJeILkO1f6l/AgYXLn1+LEJdchmW+I j4eIATTBOhv8RxbDDJTzJFBPyQu7X5cRC8BFtKBJws8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=Zw+IjQjvduvrE6FhyH+LPMJ oD9DskZwyU1TOMkl6iRzUzjWS8wDNA9pwVBA+6bPy8daFDYtgWW4kV4NTmvU+UKR DqDhien7ttjV1QxBl3m9UPQ++EVw7dIqWk3ahsve2cGGFv/ECP+c4nFka4APmdlr pZs0mrRFdLHiHxXE1Htg= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id D54FCD788E; Wed, 12 Apr 2017 13:35:58 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5088BA99FFAC; Wed, 12 Apr 2017 22:35:54 +0200 (CEST) From: otroan@employees.org Message-Id: <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_1E0B371C-4728-423D-95D6-E50494431612"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Wed, 12 Apr 2017 22:35:52 +0200 In-Reply-To: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-6man-rfc2460bis@ietf.org, 6man-chairs@ietf.org, 6man WG To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:36:09 -0000 --Apple-Mail=_1E0B371C-4728-423D-95D6-E50494431612 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > My discuss is mainly on text in section 4.8 (also based on the tsv-art > review -> Thanks Martin!): See also Bob's response to Maritn. >=20 > I find the recommendation to basically just not use hop-by-hop headers = in > section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't = it > be maybe time to just deprecate the current hop-by-hop number an = assign a > new one? I know that also has deployment problem but maybe it's worth = a > try. I guess the assignment could happen in a new document though, but > the deprecation could be done here. The Hop-by-Hop header (HBH) is a container option. It has the protocol = value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. RFC2460 has: The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The problem with this was that implementations ended up punting packets = with the HBH to software, essentially opening up for a DOS attack, which = again led operators to filtering out packets with the HBH =3D=3D 0. (While at the same time there were no HBH options with cross Internet = significance). How the HBH option could be saved has been discussed for quite some time = in the 6MAN working group. Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 Which conclusion got included into 2460bis. The working group thought it premature to deprecate the HBH option = header. As a way to "rescue" the HBH option we have made one significant change: NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. What we lose by this approach is that one cannot use mandatory options = anymore. I.e. options that MUST be processed by every router along the = packet's path. RFC2675 for example is a mechanism depending on that. In = our view this is not a problem, since routers with links with MTU larger = than 64K would have to be configured and would be within a controlled = domain anyhow. >=20 > This related to this comment from Martin's review, also proposing a > potential way forward: > "- Section 4.8. "Defining New Extension Headers and Options": > It says new hop-by-hop headers must never ever defined. This is > problematic, as this closing the door forever, even if future = instances > of the IETF do would like to wish to define new hop-by-hop headers. A > better way would have to say "that new hop-by-hop headers must have = IETF > consensus". Yes, the door for a new HBH option header container is closed. Given that this is the signal that every router has to check. Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. > - Section 4.8. "Defining New Extension Headers and Options": > Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, > especially with the phrase "There has to be a very clear = justification". > The term "clear justification" is not an exact engineering = specification. > Why not using "technical protocol specification and real word use case > required, plus IETF consensus"?" Defining new IPv6 extension headers is not recommended. There has to be a very clear justification why any new extension header is needed before it is standardized. The text does state "standardized" though. Just to remind you that the Destination options header, the HBH options = header and the Routing header are all container options, which allows = for arbitrary number of TLVs inside. Since extension headers share the = numbering space with upper layer protocols, defining new ones would = require all implementations parsing header chains (e.g. to do packet = filtering on transport headers) would have to be updated. This is the = reason for the strict restriction on adding new ones. >=20 > As a side note, there is at least one experimental RFC that defines a > destination option to be inspected by a network device, given the know > problems of hop-by-hop option which renders them unusable. Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One question because I'm not sure if I interpret this correct to make = it > part of my discuss: > Section 4.5: "The number and content of the headers preceding the > Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet." > Does this mean the ECN codepoint (part of the Traffic Class field) is > copied from the first fragment? This doesn't seem to be correct, = however, > also not sure what the correct answer is. I know this was not changed = in > this revision but maybe we can still get this right. When fragments are created most of the fields are copied from the IPv6 = headers (e.g., Source Address, Destination address, flow label, traffic = class, hop limit). Some like payload length, next header, and hop limit = are modified. If I understand your question, the answer is yes, the ECN code point is = copied from the first fragment, but should be the same from all of the = fragments. Best regards, Ole --Apple-Mail=_1E0B371C-4728-423D-95D6-E50494431612 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY7o+pAAoJEL7aWKiYQt92TGMQALDKmd6wDLsEi11CDuFl/INk 9Rcip/ds1KjCKnhXjCR1fnCDtTzUF9b7puS2v+ynGjwO4EHaGLJwJeZu2277xxiq LmtC5s2v69vpZnFXqPTm1NA3NHPPteVCfX8XBCy8QzjP6U+H0o/3A9s8Hm0IqExZ kClo2aPr1DnxQZ/w32rHdtFF+5jZ/DyNaXVtRhTBg0VSZan4zhu8XRyqV6vhe1eA Lynus+50LTU6WMXIIjWt70SwbkYfbzragF5ogNuxklDwJ1+myaDOLrtElBIJRcBp K3gXg4tFbuc4vtGjYkO4B9SQUM/yj9SuiU2NhTzh92n1pnTfs7sf+eZoaOwfeymD 0dBqKmImdKNtFQbbdlU+wjubYKzUVRPyUNO8+1pn2o7kt1Mx4Hd9L2fxOJMZTPdI K/WJFGR1mMDeLKpqHBWubbwv0jYxG6ZPgGs9w3pw/T7aTc+WldYOIwVEJyFnEQUQ CHi5cyc/+QKCLg+v391EK07veV/ewxImtyre3K/heyY/CSxsxnKzqtfpFGT4rgy4 NEthlkNtZ8XxTm6ZG1shJ/2lfpuppMqSXH340FWprs0AWKQCWUGjh0Qs8A4t4HSj yn7GY35+T+6ZZ3ZlA+G6Busm8/oBRU3uu+vtN+IKuy3bqYAzkjqi6a2xnwIT4ZNZ n3+s6J19faA+2Jcx3nCt =x7nB -----END PGP SIGNATURE----- --Apple-Mail=_1E0B371C-4728-423D-95D6-E50494431612-- From nobody Wed Apr 12 13:57:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51DC127369; Wed, 12 Apr 2017 13:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 KqEI-VCsTJFy; Wed, 12 Apr 2017 13:57:26 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 D4BB8120227; Wed, 12 Apr 2017 13:57:25 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id a103so58261427ioj.1; Wed, 12 Apr 2017 13:57:25 -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=v8QpOuAUzR+jUvCDUzLdB1wqUdYnVYV4gqIsSj1WfQo=; b=mYcczKrN2uZ/oy4Gm1RKxzPbEAzqAcYOjzwHNkWK6I87SF7L+Sd1beo4I2Iz8Zr2sm F/LD4Pdw79inytwN6FFX5G3v/ddZ9h5bT5scHKXi6KVMiD56mSgoqgFMATxCbx6jJCtf vyXBHQIck/srCHpZTlZwmV1KC1+SUgZsSUxyJBKBFRkkA3oFlfK5cHwyfyWtoU5IpYG6 b+p4lVFsJKDCnpTAF51gq4HRPYKw8uJVD9hXBYSUkYMScg1cLqiYGgvNDpxuqvX+fEEY YtkbZZnXQ8EekVpD2JEcHa08qeZ9JFTWMnDQjYaJ0DSAk5jD2lyyxdKQtZqPPUge9uCU KZyQ== 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=v8QpOuAUzR+jUvCDUzLdB1wqUdYnVYV4gqIsSj1WfQo=; b=HajyKBwz3qar6jm2RZgqPZGBXZ2TSGPfnUw8ZGw0Iae/6SjxI77lBMKe+vtd4v3/ay 0iWK9esykAAkJ8ia2FJ3lY0IIcHy+yONaUMBV0g9+60HeIW8eUjvtIU21oSSCTfnuykY 3JQBT4n5uDFlt7HvbKHRQb8QlVncW99rqvj0HhsbyH0ZI022GaAGgCUA24gAavRjepwT SxSRmEcQ2zmbyyheosjRRtqha7QF4gq1l0NwCtx2iwnYl5EUAtmwZeu8ZFYoku3msNpt 8KauxkmOUtpr7Z0dHJrvIglX+zGzQlyoTiPWd4XpmSMghl4Ec7Y8pTcC8Lpe4cfHR/gD BeYg== X-Gm-Message-State: AN3rC/78Gfp+9v9Dn6spDXeK5ZrIxqXT+ojDYK2FV0WjLYmGf1p1S/kA j6rBs8et2qMXRw== X-Received: by 10.107.137.148 with SMTP id t20mr191189ioi.79.1492030645176; Wed, 12 Apr 2017 13:57:25 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id n10sm2945126itg.8.2017.04.12.13.57.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 13:57:24 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9C55D7AD-A935-4AC9-A475-69B541442ADE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alissa Cooper's No Objection on draft-ietf-6man-rfc2460bis-09: (with COMMENT) Date: Wed, 12 Apr 2017 13:57:21 -0700 In-Reply-To: <149202550312.15690.13102264583704924554.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-rfc2460bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List To: Alissa Cooper References: <149202550312.15690.13102264583704924554.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:57:28 -0000 --Apple-Mail=_9C55D7AD-A935-4AC9-A475-69B541442ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alissa, Thanks. > On Apr 12, 2017, at 12:31 PM, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-6man-rfc2460bis-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please have a look at the changes suggested in Peter's Gen-ART review: > = https://datatracker.ietf.org/doc/review-ietf-6man-rfc2460bis-08-genart-lc-= yee-2017-02-28/ >=20 The majority of the specific editorial changes were made in the -09 = version. I will leave the spelling of =E2=80=9Cen-route=E2=80=9D and = =E2=80=9Cbehaviour=E2=80=9D to the RFC Editor. Thanks, Bob --Apple-Mail=_9C55D7AD-A935-4AC9-A475-69B541442ADE 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7pSyAAoJEK7rdBF357uoYroH/A1n3D98dOWv8746XcIuxvTW bJiEtE6gz9YeqPtk450HFRQkhJjEXSwIG1y15BMe8ewBB8CIF/7ZLjrJUAd3JYy3 g42FL4NZdic9U/VmmmI4cJNGDrHoY4jH+ja6DtMFL25x676zD7a4NbQ+jfSdnB1+ r2iW0TyuRjLxiydq7l049KCotxAFihZI2vFy3l+U0nB2vqbmWvyjztRmQVXrn9E3 3vapktSShCx0QMjUV4T04ckfasvfkrPD+xfVr+xSTRHC53OaAC56wZ6vtVRgEn6l WxzzluYnIQXDI7Hz0YW18MiyZjQUgn7KW0YQg25sR3A1p9w1I3GcYUSrDWNAt/E= =Y59j -----END PGP SIGNATURE----- --Apple-Mail=_9C55D7AD-A935-4AC9-A475-69B541442ADE-- From nobody Wed Apr 12 13:59:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476EC129ACC; Wed, 12 Apr 2017 13:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=CLjLaNDi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iTBHmIgv 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 9Dcy7Rfo2jhO; Wed, 12 Apr 2017 13:59:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F2B127369; Wed, 12 Apr 2017 13:59:12 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DA528213C7; Wed, 12 Apr 2017 16:59:11 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 12 Apr 2017 16:59:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=vK9ZpOYddQZiGF7koW Q8iwpTTgXU67JKGQgJm8XCJiA=; b=CLjLaNDiv2JxEfn9hz7wyncanpLw4zQswx rdULK5vXljSvbHZF3AN6GJg/34k0khndO1kXLDAiAGRxUw/FdDmhfFCEWHjRxQJj 3cEmmRBigJR47dlIwV6w3B3GcgMvRy6gmXVTKWvkvAGkahBqNAZgGxsjKrwBRyBi zZEt1ararEUugWwqMQXCrTa7cYlogEljMNfP0k7ls1OwP/VZrPttgD3eW5Rx9Ozg Dzyxlt5JSmVavGqiwgtdIsZDE0NZ1+QL87N6fC1+njBTaPSfK/QoVM1/aChPLshU F4BHkHiqWnbWfO86DpCfi1bMKBLaI2QfvwYAsQWtiFPMbymT9M5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=vK9ZpOYddQZiGF7koWQ8iwpTTgXU67JKGQgJm8XCJiA=; b=iTBHmIgv Sy4kF729V4WWV4KQYtF7zKrIkdVp4dghlbRrUvPI5OpjU1ahhgk78Q85FMzBXMw6 4bXbqsGPe032pKn1kC9XvUA0zUGYUvzQUBirXJgo7kmOEEPaZo4XIa5QRQihY3g0 TBfLkgeo+EEly8ClFi7BWy7+MtIZpQ5DAVXd+m0QyWIT+eIf6sb2pCS456dES0DN Bpo60S1CyYLw8qBUrdNMhEobIQq2vtg7s2f77Si20/sRaTO3v5K+bLYQL0mZrAxP vRC1Lrp+VLmBBWEgvwQLbnIR4Wo5n5X7f11oNQO4DazaWWKIA08VmjhmagIDwpEN kvGwZsZk6Y/Opw== X-ME-Sender: X-Sasl-enc: jHq3fmJ/h4INsC7G/ZjZ6t5KN7N36g4jL2u+sPN716pU 1492030751 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 96AEB2470C; Wed, 12 Apr 2017 16:59:10 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Alissa Cooper's No Objection on draft-ietf-6man-rfc2460bis-09: (with COMMENT) From: Alissa Cooper In-Reply-To: Date: Wed, 12 Apr 2017 16:59:08 -0400 Cc: IESG , draft-ietf-6man-rfc2460bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <0D670D97-69C0-44DF-BE13-FC8E5D29022F@cooperw.in> References: <149202550312.15690.13102264583704924554.idtracker@ietfa.amsl.com> To: Bob Hinden X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:59:14 -0000 > On Apr 12, 2017, at 4:57 PM, Bob Hinden wrote: >=20 > Alissa, >=20 > Thanks. >=20 >> On Apr 12, 2017, at 12:31 PM, Alissa Cooper = wrote: >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-6man-rfc2460bis-09: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Please have a look at the changes suggested in Peter's Gen-ART = review: >> = https://datatracker.ietf.org/doc/review-ietf-6man-rfc2460bis-08-genart-lc-= yee-2017-02-28/ >>=20 >=20 > The majority of the specific editorial changes were made in the -09 = version. I will leave the spelling of =E2=80=9Cen-route=E2=80=9D and = =E2=80=9Cbehaviour=E2=80=9D to the RFC Editor. Thanks, wasn=E2=80=99t sure if those were missed or applied selectively. Alissa >=20 > Thanks, > Bob >=20 From nobody Wed Apr 12 14:34:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E212EB61 for ; Wed, 12 Apr 2017 14:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 9LocTG6RsolZ for ; Wed, 12 Apr 2017 14:34:47 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E643712EB57 for ; Wed, 12 Apr 2017 14:34:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3CLYjJ6063919; Wed, 12 Apr 2017 14:34:46 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3CLYfNF063896 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 12 Apr 2017 14:34:41 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 12 Apr 2017 14:34:40 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Wed, 12 Apr 2017 14:34:40 -0700 From: "Templin, Fred L" To: "ipv6@ietf.org" CC: james woodyatt , Lorenzo Colitti , Dave Thaler , Jen Linkova , "David Schinazi" Subject: Route Information Options in IPv6 Neighbor Discovery Thread-Topic: Route Information Options in IPv6 Neighbor Discovery Thread-Index: AdKz02OPoeaHB7mXSI2gKFT6CIowLQ== Date: Wed, 12 Apr 2017 21:34:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:34:49 -0000 Please see below for an updated version of "Route Information Options in IPv6 Neighbor Discovery". Note that the title is changed since the last version because we are now allowing RIOs to appear in other IPv6 ND messages besides just Redirects. In particular, we are now allowing RIOs to also appear in Neighbor Solicitation (NS) and Advertisement (NA) messages. The rationale for leveraging NS/NA instead of RS/RA is given in Section 4.2= .6. The rest of document was updated to address the helpful input received from colleagues at IETF98. Please review and post comments to the list and/or the authors. Fred and James -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Thursday, April 06, 2017 4:25 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-6man-rio-redirect-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Route Information Options in IPv6 Neighbor Discov= ery Authors : Fred L. Templin James Woodyatt Filename : draft-templin-6man-rio-redirect-02.txt Pages : 12 Date : 2017-04-06 Abstract: The IPv6 Neighbor Discovery protocol provides a Redirect function allowing routers to inform recipients of a better next hop neighbor on the link toward the destination, and a Neighbor Solicitation (NS) function allowing nodes to solicit a Neighbor Advertisement (NA) response from the neighbor. This document specifies backward- compatible extensions to Redirect, NS and NA messages to support the discovery of more-specific routes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-6man-rio-redirect-02 https://datatracker.ietf.org/doc/html/draft-templin-6man-rio-redirect-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-6man-rio-redirect-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Apr 12 14:45:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3659312EB55; Wed, 12 Apr 2017 14:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 nlHW3kNPvE7c; Wed, 12 Apr 2017 14:45:21 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 294D812EB4F; Wed, 12 Apr 2017 14:45:21 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v3so33109104qtd.3; Wed, 12 Apr 2017 14:45:21 -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=B1uRp0do+e2HvnBfG429XdFnkycB3p3n6TgS8VUvqeE=; b=IyZrFf38MHa6Yt44j8Ta8C05lexSMuJKAGKc2Y1gb8fBAtZu7/Ogy4x3uizEmYJjJG DvcZItkrLG4nXOEYw1Rj4LjAOlj0lMbvxLVB4MUtv2fL4D9csnqL0xHYYUBh9nrYNTIV PF6TSm30BZH2jm7kCBLcKGRkt7USxw0n7P6GNDQpuPeMsz6iMKg5rJTIdS1Dg5dZKaPn vHd+/ihzze3dmpLpNGdLnoS/dwOqf4jpgFfj8dbVKjgAGrCZY5V3stkOHpmguHgNpDrT XwgoenmzI8g4M6A7hfepiFswcjkNDMcVXhQd7Oab+cND1YE0IJAq7Vk2CHK9repp9grJ H3/g== 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=B1uRp0do+e2HvnBfG429XdFnkycB3p3n6TgS8VUvqeE=; b=CHk5fMfeWissrmavysBPx1XVHEQGPqfT2EuJbQ+yM1AGXxWGG5rnaFGo2kd9JBIUd9 zz9o92mlUEGwZRRb8DWx1NNI1rxJ2EftkKruUC/O4B8aaqlFZpxAVFypyjLOWCHfYLHP QZBWws+0VjgoThGPSf7qV8nM60WGoD9inxNtTouQcmVtyNGtQrIthOWkVkLGz/SnFM6J LROF3nHwN/t658CE90oOoDxFmfeCbIN+t13L9XZzood96M7Vgw/FLK+/R3yH3jYKFpn4 QftBC8zayyUFxpdPDXVR/O6f7GOBFr2bz+B/1NxPZWZtZIe0f9c8O1a6iJ9usZs5zBmP z9jQ== X-Gm-Message-State: AFeK/H0M/pGz/t5psgXayvgdcH6qhBZG9CKPcf//9tVnc4AJdoARGVxzARgIhgdUHmNeSQ== X-Received: by 10.237.59.115 with SMTP id q48mr62629998qte.85.1492033520304; Wed, 12 Apr 2017 14:45:20 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c189sm1545723qkg.6.2017.04.12.14.45.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 14:45:19 -0700 (PDT) From: Bob Hinden Message-Id: <96A7997A-D6EA-413B-AB6F-5B2CBE4110DA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2D8851D0-C387-47AB-BDBD-668F51D953D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Date: Wed, 12 Apr 2017 14:45:16 -0700 In-Reply-To: Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , Tim Chown , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> To: "Alvaro Retana (aretana)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:45:23 -0000 --Apple-Mail=_2D8851D0-C387-47AB-BDBD-668F51D953D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro, > On Apr 11, 2017, at 2:33 PM, Alvaro Retana (aretana) = wrote: >=20 > Ole: >=20 > Hi! >=20 > Thanks for the clarification! It would be nice if the document also = said this =E2=80=93 from what I could read, the text doesn=E2=80=99t = match what you said =E2=80=93 or did I miss it? On page 10: The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. When an Authentication header is present in the packet, for any option whose data may change en-route, its entire Option Data field must be treated as zero-valued octets when computing or verifying the packet's authenticating value. 0 - Option Data does not change en-route 1 - Option Data may change en-route Was that your question? Bob > Alvaro. >=20 > On 4/11/17, 5:17 PM, "otroan@employees.org" = wrote: >=20 >>=20 >> The initial sentence mentions 4 actions: examine, process, insert, or = delete. >> The text already says that any node can examine the headers =E2=80=9Cfo= r any reason=E2=80=9D, according to [rfc7045]. So maybe take that out = as part of the original 4. >> I do have an additional clarity question. What does =E2=80=9Cprocess=E2= =80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe = Hop-by-Hop Options header and the Destination Options header=E2=80=9D = has an option bit that indicates =E2=80=9Cwhether or not the Option Data = of that option can change en-route to the packet's final destination=E2=80= =9D. I=E2=80=99m assuming that to change the data the transit node has = to not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook = at=E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as = well. If to =E2=80=9Cprocess=E2=80=9D includes the ability to = =E2=80=9Cchange en-route=E2=80=9D, then it looks like the Destination = Option may also be an exception=E2=80=A6 >=20 > Both options inside of an HBH option header and a Destination Options = header can have the change en-route flag set. > The Destinations Options header are only processed at the destination = host, so an option can then only change en-route when it is part of a = source route path (and the Destination options header is before the = routing header). >=20 > The "feature" here is that one can specify options that can be = processed only by the routers listed in a routing header or one can = specify options that can change en-route for every hop along the path. >=20 --Apple-Mail=_2D8851D0-C387-47AB-BDBD-668F51D953D0 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7p/tAAoJEK7rdBF357uoLnUH/iKrxNjhNuIb2eWewsveLgLn PEjKL1RHU7hnNnkNpUEoTVx6ZRrB+BQM17Lb3QnA2jNqetOG4WPG9ya/W8JN/LKB sx2mLublmpxbEvzEx8w3XtfrQhABRCXaOyE60vMpKy+s8Lic+toPCiPZSY8ii1DG 66SU4R2gnY9BcWcu69ZLG5wcTIc98LmS1jOb/lmcBsbm7GdDeSnxSRDBM5141WdJ 1ow3cfuvhlCFL0E3n4e+mK0E5SmcrKNq/Kv0BMc4qwovGf55mVvyvMfKyRUQS8je 0vApT87zcA4HWiT6UICwxrJWUrJ5mfXUSNffFwpNoK2Ix0E4lwaZ9gTGdjUIVxY= =z8TZ -----END PGP SIGNATURE----- --Apple-Mail=_2D8851D0-C387-47AB-BDBD-668F51D953D0-- From nobody Wed Apr 12 14:48:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E779D12EB62 for ; Wed, 12 Apr 2017 14:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 3xtWuWaD-29y for ; Wed, 12 Apr 2017 14:48:21 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFAE12EB5A for ; Wed, 12 Apr 2017 14:48:20 -0700 (PDT) Received: (qmail 24436 invoked from network); 12 Apr 2017 23:48:18 +0200 Received: from p5dec24e1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.225) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Apr 2017 23:48:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> Date: Wed, 12 Apr 2017 23:48:17 +0200 Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:48:24 -0000 Hi Ole, see below. > Am 12.04.2017 um 22:35 schrieb otroan@employees.org: >=20 > Mirja, >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> My discuss is mainly on text in section 4.8 (also based on the = tsv-art >> review -> Thanks Martin!): >=20 > See also Bob's response to Maritn. >=20 >>=20 >> I find the recommendation to basically just not use hop-by-hop = headers in >> section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't = it >> be maybe time to just deprecate the current hop-by-hop number an = assign a >> new one? I know that also has deployment problem but maybe it's worth = a >> try. I guess the assignment could happen in a new document though, = but >> the deprecation could be done here. >=20 > The Hop-by-Hop header (HBH) is a container option. It has the protocol = value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. Sorry, I meant hop-by-hop option in this case. >=20 > RFC2460 has: > The Hop-by-Hop Options header is used to carry optional information > that must be examined by every node along a packet's delivery path. >=20 > The problem with this was that implementations ended up punting = packets with the HBH to software, essentially opening up for a DOS = attack, which again led operators to filtering out packets with the HBH = =3D=3D 0. > (While at the same time there were no HBH options with cross Internet = significance). >=20 > How the HBH option could be saved has been discussed for quite some = time in the 6MAN working group. > Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 > Which conclusion got included into 2460bis. >=20 > The working group thought it premature to deprecate the HBH option = header. > As a way to "rescue" the HBH option we have made one significant = change: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. >=20 > Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >=20 > What we lose by this approach is that one cannot use mandatory options = anymore. I.e. options that MUST be processed by every router along the = packet's path. RFC2675 for example is a mechanism depending on that. In = our view this is not a problem, since routers with links with MTU larger = than 64K would have to be configured and would be within a controlled = domain anyhow. Yes, I also don=E2=80=99t see that as a problem. It=E2=80=99s anyway = always hard to ensure that something is process by every hop. Not sure = that would have been achievable in reality every. >=20 >>=20 >> This related to this comment from Martin's review, also proposing a >> potential way forward: >> "- Section 4.8. "Defining New Extension Headers and Options": >> It says new hop-by-hop headers must never ever defined. This is >> problematic, as this closing the door forever, even if future = instances >> of the IETF do would like to wish to define new hop-by-hop headers. A >> better way would have to say "that new hop-by-hop headers must have = IETF >> consensus". >=20 > Yes, the door for a new HBH option header container is closed. > Given that this is the signal that every router has to check. > Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. >=20 >> - Section 4.8. "Defining New Extension Headers and Options": >> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >> especially with the phrase "There has to be a very clear = justification". >> The term "clear justification" is not an exact engineering = specification. >> Why not using "technical protocol specification and real word use = case >> required, plus IETF consensus"?" >=20 > Defining new IPv6 extension headers is not recommended. There has = to > be a very clear justification why any new extension header is needed > before it is standardized. >=20 > The text does state "standardized" though. >=20 > Just to remind you that the Destination options header, the HBH = options header and the Routing header are all container options, which = allows for arbitrary number of TLVs inside. Since extension headers = share the numbering space with upper layer protocols, defining new ones = would require all implementations parsing header chains (e.g. to do = packet filtering on transport headers) would have to be updated. This is = the reason for the strict restriction on adding new ones. See my response to Mike=E2=80=99s reply to Martin=E2=80=99s review: I = think what you better should say is that it is recommended to use a = destination option, if suitable, rather than a new header. I don=E2=80=99t= think you need to anything else than this about new headers. >=20 >>=20 >> As a side note, there is at least one experimental RFC that defines a >> destination option to be inspected by a network device, given the = know >> problems of hop-by-hop option which renders them unusable. >=20 > Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. It=E2=80=99s very costly but unfortunately currently the only way to = achieve that at all. Given that this experimental option is intended to = be inspected by only a few nodes on the path (not all) and usually these = nodes are close the edge, it=E2=80=99s probably still doable. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> One question because I'm not sure if I interpret this correct to make = it >> part of my discuss: >> Section 4.5: "The number and content of the headers preceding the >> Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet." >> Does this mean the ECN codepoint (part of the Traffic Class field) is >> copied from the first fragment? This doesn't seem to be correct, = however, >> also not sure what the correct answer is. I know this was not changed = in >> this revision but maybe we can still get this right. >=20 > When fragments are created most of the fields are copied from the IPv6 = headers (e.g., Source Address, Destination address, flow label, traffic = class, hop limit). Some like payload length, next header, and hop limit = are modified. >=20 > If I understand your question, the answer is yes, the ECN code point = is copied from the first fragment, but should be the same from all of = the fragments. My concern is that the ECN code point could be changed on one of the = fragmented packets to signal congestion of a intermediate node and then = when you reassemble this information gets lost. That seems wrong. Mirja >=20 > Best regards, > Ole From nobody Wed Apr 12 14:49:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568C9129ADF; Wed, 12 Apr 2017 14:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zfSPuHcv7U2G; Wed, 12 Apr 2017 14:49:04 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55971274D2; Wed, 12 Apr 2017 14:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4004; q=dns/txt; s=iport; t=1492033744; x=1493243344; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t9nwnyqUizKFAFigSADr0ZrL0jv5VbrjNyN8OxwCJcA=; b=EQ8hNaXWnhe0PD9/hbMb9ZnFPunUd01phW/QEjA35rHUXFLqYWWcvoG2 lz7gY/iM9CDxZDF1aWkIsHuLRMFeHo0gN4i26Zzd2XJzMDv8olP1xuq02 orRMdw7yKtDJseqnruYFqp/N4Lt8Va3G2c5stFUwZMVgiOUIBGj86KfTW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQAJoO5Y/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrgWwHg1+KE5FUiBqNP4IPhiQCGoNnPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBIxFFBQsCAQgYAgImAgICHxEVEAIEDgWJfgMNCKlygiaHMA2DUwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BC4VGggiCbIJRggWDBi6CMQWWJ4YoOwGKLIN?= =?us-ascii?q?xhEOBf4kLhjqLAoh/AR84gQVbFVIBhEkcGYFKdYgVgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="410764475" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 21:49:03 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3CLn2Sq025405 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 21:49:02 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 16:49:02 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 16:49:02 -0500 From: "Alvaro Retana (aretana)" To: Bob Hinden CC: =?utf-8?B?T2xlIFRyw7hhbg==?= , Tim Chown , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Topic: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Thread-Index: AQHSr85dTThx1SRXYEO6jo/FFmbU1aG+QkcAgABhawCAABE3gIACUWmA///BWYCAAdiuAP//vf6A Date: Wed, 12 Apr 2017 21:49:02 +0000 Message-ID: References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> <96A7997A-D6EA-413B-AB6F-5B2CBE4110DA@gmail.com> In-Reply-To: <96A7997A-D6EA-413B-AB6F-5B2CBE4110DA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: text/plain; charset="utf-8" Content-ID: <9DBF34DF0932C24F9F5718694C43A4A3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:49:05 -0000 Qm9iOg0KDQpIaSENCg0KTm8sIHRoYXQgd2FzIG5vdCBteSBxdWVzdGlvbi4NCg0KT2xlIG1lbnRp b25lZCB0aGF0IOKAnFRoZSBEZXN0aW5hdGlvbnMgT3B0aW9ucyBoZWFkZXIgYXJlIG9ubHkgcHJv Y2Vzc2VkIGF0IHRoZSBkZXN0aW5hdGlvbiBob3N0LCBzbyBhbiBvcHRpb24gY2FuIHRoZW4gb25s eSBjaGFuZ2UgZW4tcm91dGUgd2hlbiBpdCBpcyBwYXJ0IG9mIGEgc291cmNlIHJvdXRlIHBhdGgg KGFuZCB0aGUgRGVzdGluYXRpb24gb3B0aW9ucyBoZWFkZXIgaXMgYmVmb3JlIHRoZSByb3V0aW5n IGhlYWRlciku4oCdICBUaGF0IOKAnGZlYXR1cmXigJ0gKGFzIE9sZSBjYWxsZWQgaXQpIGlzIG5v dCBwYXJ0IG9mIHRoZSB0ZXh0Lg0KDQpBbHZhcm8uDQoNCg0KDQoNCg0KT24gNC8xMi8xNywgNTo0 NSBQTSwgIkJvYiBIaW5kZW4iIDxib2IuaGluZGVuQGdtYWlsLmNvbT4gd3JvdGU6DQoNCkFsdmFy bywNCg0KPiBPbiBBcHIgMTEsIDIwMTcsIGF0IDI6MzMgUE0sIEFsdmFybyBSZXRhbmEgKGFyZXRh bmEpIDxhcmV0YW5hQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBPbGU6DQo+IA0KPiBIaSENCj4g DQo+IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24hICBJdCB3b3VsZCBiZSBuaWNlIGlmIHRo ZSBkb2N1bWVudCBhbHNvIHNhaWQgdGhpcyDigJMgZnJvbSB3aGF0IEkgY291bGQgcmVhZCwgdGhl IHRleHQgZG9lc27igJl0IG1hdGNoIHdoYXQgeW91IHNhaWQg4oCTIG9yIGRpZCBJIG1pc3MgaXQ/ DQoNCk9uIHBhZ2UgMTA6DQoNCiAgIFRoZSB0aGlyZC1oaWdoZXN0LW9yZGVyIGJpdCBvZiB0aGUg T3B0aW9uIFR5cGUgc3BlY2lmaWVzIHdoZXRoZXIgb3INCiAgIG5vdCB0aGUgT3B0aW9uIERhdGEg b2YgdGhhdCBvcHRpb24gY2FuIGNoYW5nZSBlbi1yb3V0ZSB0byB0aGUNCiAgIHBhY2tldCdzIGZp bmFsIGRlc3RpbmF0aW9uLiAgV2hlbiBhbiBBdXRoZW50aWNhdGlvbiBoZWFkZXIgaXMgcHJlc2Vu dA0KICAgaW4gdGhlIHBhY2tldCwgZm9yIGFueSBvcHRpb24gd2hvc2UgZGF0YSBtYXkgY2hhbmdl IGVuLXJvdXRlLCBpdHMNCiAgIGVudGlyZSBPcHRpb24gRGF0YSBmaWVsZCBtdXN0IGJlIHRyZWF0 ZWQgYXMgemVyby12YWx1ZWQgb2N0ZXRzIHdoZW4NCiAgIGNvbXB1dGluZyBvciB2ZXJpZnlpbmcg dGhlIHBhY2tldCdzIGF1dGhlbnRpY2F0aW5nIHZhbHVlLg0KDQogICAgICAwIC0gT3B0aW9uIERh dGEgZG9lcyBub3QgY2hhbmdlIGVuLXJvdXRlDQoNCiAgICAgIDEgLSBPcHRpb24gRGF0YSBtYXkg Y2hhbmdlIGVuLXJvdXRlDQoNCldhcyB0aGF0IHlvdXIgcXVlc3Rpb24/DQoNCkJvYg0KDQoNCj4g QWx2YXJvLg0KPiANCj4gT24gNC8xMS8xNywgNToxNyBQTSwgIm90cm9hbkBlbXBsb3llZXMub3Jn IiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPiANCj4+IA0KPj4gVGhlIGluaXRpYWwg c2VudGVuY2UgbWVudGlvbnMgNCBhY3Rpb25zOiBleGFtaW5lLCBwcm9jZXNzLCBpbnNlcnQsIG9y IGRlbGV0ZS4NCj4+IFRoZSB0ZXh0IGFscmVhZHkgc2F5cyB0aGF0IGFueSBub2RlIGNhbiBleGFt aW5lIHRoZSBoZWFkZXJzIOKAnGZvciBhbnkgcmVhc29u4oCdLCBhY2NvcmRpbmcgdG8gW3JmYzcw NDVdLiAgU28gbWF5YmUgdGFrZSB0aGF0IG91dCBhcyBwYXJ0IG9mIHRoZSBvcmlnaW5hbCA0Lg0K Pj4gSSBkbyBoYXZlIGFuIGFkZGl0aW9uYWwgY2xhcml0eSBxdWVzdGlvbi4gIFdoYXQgZG9lcyDi gJxwcm9jZXNz4oCdIG1lYW4/ICBEb2VzIGl0IGluY2x1ZGUgYSDigJxjaGFuZ2UgZW4tcm91dGXi gJ0/ICAgIEnigJltIGFza2luZyBiZWNhdXNlIFNlY3Rpb24gNC4yLiAoT3B0aW9ucykgc2F5cyB0 aGF0IOKAnHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIGFuZCB0aGUgRGVzdGluYXRpb24g T3B0aW9ucyBoZWFkZXLigJ0gaGFzIGFuIG9wdGlvbiBiaXQgdGhhdCBpbmRpY2F0ZXMg4oCcd2hl dGhlciBvciBub3QgdGhlIE9wdGlvbiBEYXRhIG9mIHRoYXQgb3B0aW9uIGNhbiBjaGFuZ2UgZW4t cm91dGUgdG8gdGhlIHBhY2tldCdzIGZpbmFsIGRlc3RpbmF0aW9u4oCdLiAgSeKAmW0gYXNzdW1p bmcgdGhhdCB0byBjaGFuZ2UgdGhlIGRhdGEgdGhlIHRyYW5zaXQgbm9kZSBoYXMgdG8gbm90IGp1 c3Qg4oCcZXhhbWluZeKAnSAod2hpY2ggSSB0aGluayBtZWFucyDigJxsb29rIGF04oCdKSwgYnV0 IGFsc28gKGF0IGxlYXN0KSDigJxwcm9jZXNz4oCdIHRoZSBFSCBhcyB3ZWxsLiAgIElmIHRvIOKA nHByb2Nlc3PigJ0gaW5jbHVkZXMgdGhlIGFiaWxpdHkgdG8g4oCcY2hhbmdlIGVuLXJvdXRl4oCd LCB0aGVuIGl0IGxvb2tzIGxpa2UgdGhlIERlc3RpbmF0aW9uIE9wdGlvbiBtYXkgYWxzbyBiZSBh biBleGNlcHRpb27igKYNCj4gDQo+IEJvdGggb3B0aW9ucyBpbnNpZGUgb2YgYW4gSEJIIG9wdGlv biBoZWFkZXIgYW5kIGEgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgY2FuIGhhdmUgdGhlIGNo YW5nZSBlbi1yb3V0ZSBmbGFnIHNldC4NCj4gVGhlIERlc3RpbmF0aW9ucyBPcHRpb25zIGhlYWRl ciBhcmUgb25seSBwcm9jZXNzZWQgYXQgdGhlIGRlc3RpbmF0aW9uIGhvc3QsIHNvIGFuIG9wdGlv biBjYW4gdGhlbiBvbmx5IGNoYW5nZSBlbi1yb3V0ZSB3aGVuIGl0IGlzIHBhcnQgb2YgYSBzb3Vy Y2Ugcm91dGUgcGF0aCAoYW5kIHRoZSBEZXN0aW5hdGlvbiBvcHRpb25zIGhlYWRlciBpcyBiZWZv cmUgdGhlIHJvdXRpbmcgaGVhZGVyKS4NCj4gDQo+IFRoZSAiZmVhdHVyZSIgaGVyZSBpcyB0aGF0 IG9uZSBjYW4gc3BlY2lmeSBvcHRpb25zIHRoYXQgY2FuIGJlIHByb2Nlc3NlZCBvbmx5IGJ5IHRo ZSByb3V0ZXJzIGxpc3RlZCBpbiBhIHJvdXRpbmcgaGVhZGVyIG9yIG9uZSBjYW4gc3BlY2lmeSBv cHRpb25zIHRoYXQgY2FuIGNoYW5nZSBlbi1yb3V0ZSBmb3IgZXZlcnkgaG9wIGFsb25nIHRoZSBw YXRoLg0KPiANCg0KDQoNCg== From nobody Wed Apr 12 15:03:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6823D127876; Wed, 12 Apr 2017 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 IfJpmaAFJXU7; Wed, 12 Apr 2017 15:03:30 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 745CA1243F6; Wed, 12 Apr 2017 15:03:30 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id a103so60033362ioj.1; Wed, 12 Apr 2017 15:03:30 -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=TOBUT0lqIHhJKdcxZ0mz+O18Am18EKKiexmbNqw7q3s=; b=iwVXMQG9ZQGo1Zd6DoD7fqHpAcLINLJTUbH4kd6QZ64P7WYXBaeeNMC0Gk3sNR1vjx kLosP74ANxqZTXp+ZuhQ4L8tQkhmM/P5TJkLhgXog+q7rHAF/sjTygEdSOEPq6UK/DqZ 2f6qnkxu+4bb2TFcfI5o+owb3evjuUEmTr7WaMJzi75SJhCN9Y3E8ZN+i5UfmWC3yjXs FDT4joZZFJ6U3GFSFNG3/WSeHrgZ5FbgTRm/aTfCrOV+gc17lRJisgSsZSTljmczQTFU yJtANFBLXS46XiiWCckqs7t4ZoFuFrCODrNYRv1LbX8N6oM4OjEBZurPvHzBIl78msco Bl1w== 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=TOBUT0lqIHhJKdcxZ0mz+O18Am18EKKiexmbNqw7q3s=; b=c5DDRS4y7qXi9hUwSs11yp0AZI6b7fQ2374hvM3nO379uDN5iILBYYLo1jJqEgtNqy W26rpA7NM2TjVoEt740NyXe0cTTggkt2sPnp74frU7QylUpw42B7ZGM8GOruxQnemUhl jVctJMlKOWTlly7/JkGRJ7huhuIVdkczh7CAc6C9veIDf68S2MRztecPLeyhbMcEw9SO hYg/wUwTq8MDcNBEqhvarBOunYMKphbZxYxIidn4pHefHLzZyTvMe2/KpucRRLiDQgY9 mD1rxkV2D3BoUWsycN+69YOa4dD71qbrSwKyZkC4EHzIamaYOFu2MmD28XpmPiIztH+n Do4A== X-Gm-Message-State: AN3rC/5u6laGZx0CwagmY1uPmvC5uqbzuI85vwMp7hbXvihxuHthBCki 93B9zINamJMhRg== X-Received: by 10.36.246.72 with SMTP id u69mr426083ith.79.1492034609642; Wed, 12 Apr 2017 15:03:29 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id b132sm10087396iob.6.2017.04.12.15.03.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 15:03:28 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FDF5775B-B349-4756-B227-7D75469ED2D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Date: Wed, 12 Apr 2017 15:03:25 -0700 In-Reply-To: Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , Tim Chown , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> To: "Alvaro Retana (aretana)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> <96A7997A-D6EA-413B-AB6F-5B2CBE4110DA@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:03:36 -0000 --Apple-Mail=_FDF5775B-B349-4756-B227-7D75469ED2D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro, > On Apr 12, 2017, at 2:49 PM, Alvaro Retana (aretana) = wrote: >=20 > Bob: >=20 > Hi! >=20 > No, that was not my question. OK :-) >=20 > Ole mentioned that =E2=80=9CThe Destinations Options header are only = processed at the destination host, so an option can then only change = en-route when it is part of a source route path (and the Destination = options header is before the routing header).=E2=80=9D That = =E2=80=9Cfeature=E2=80=9D (as Ole called it) is not part of the text. That can be inferred by how destination extension headers are defined. = That is. they are processed at the destination indicated by the IPv6 = destination address in the packet header. =46rom Page 9: note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. Where Note 1, is for the Destination Options header on the previous = page: Destination Options header (note 1) Options in the hop-by-hop header are, of course, processed at every hop. Bob >=20 > Alvaro. >=20 >=20 >=20 >=20 >=20 > On 4/12/17, 5:45 PM, "Bob Hinden" wrote: >=20 > Alvaro, >=20 >> On Apr 11, 2017, at 2:33 PM, Alvaro Retana (aretana) = wrote: >>=20 >> Ole: >>=20 >> Hi! >>=20 >> Thanks for the clarification! It would be nice if the document also = said this =E2=80=93 from what I could read, the text doesn=E2=80=99t = match what you said =E2=80=93 or did I miss it? >=20 > On page 10: >=20 > The third-highest-order bit of the Option Type specifies whether or > not the Option Data of that option can change en-route to the > packet's final destination. When an Authentication header is = present > in the packet, for any option whose data may change en-route, its > entire Option Data field must be treated as zero-valued octets when > computing or verifying the packet's authenticating value. >=20 > 0 - Option Data does not change en-route >=20 > 1 - Option Data may change en-route >=20 > Was that your question? >=20 > Bob >=20 >=20 >> Alvaro. >>=20 >> On 4/11/17, 5:17 PM, "otroan@employees.org" = wrote: >>=20 >>>=20 >>> The initial sentence mentions 4 actions: examine, process, insert, = or delete. >>> The text already says that any node can examine the headers =E2=80=9Cf= or any reason=E2=80=9D, according to [rfc7045]. So maybe take that out = as part of the original 4. >>> I do have an additional clarity question. What does =E2=80=9Cprocess=E2= =80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe = Hop-by-Hop Options header and the Destination Options header=E2=80=9D = has an option bit that indicates =E2=80=9Cwhether or not the Option Data = of that option can change en-route to the packet's final destination=E2=80= =9D. I=E2=80=99m assuming that to change the data the transit node has = to not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook = at=E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as = well. If to =E2=80=9Cprocess=E2=80=9D includes the ability to = =E2=80=9Cchange en-route=E2=80=9D, then it looks like the Destination = Option may also be an exception=E2=80=A6 >>=20 >> Both options inside of an HBH option header and a Destination Options = header can have the change en-route flag set. >> The Destinations Options header are only processed at the destination = host, so an option can then only change en-route when it is part of a = source route path (and the Destination options header is before the = routing header). >>=20 >> The "feature" here is that one can specify options that can be = processed only by the routers listed in a routing header or one can = specify options that can change en-route for every hop along the path. >>=20 >=20 >=20 >=20 --Apple-Mail=_FDF5775B-B349-4756-B227-7D75469ED2D3 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7qQuAAoJEK7rdBF357uoMVcIAKxDV2RipcwG+0s5qRfdCGzW QrnCZLym8yqG8V+Nlmb5FFEX0pKDWm3KqnxgAgHIYVWxszX1X/3gyBXExzdSyzzg tdAlr1mbcY0W2uxBpKLHj8yAlM4utWDyY+fuw81dx2xLsEJtjVblqH47mTZdAdjw 0arAe4v0kmMswTnHTZL0sdvRX2P+WMfSX6r4tgEcDNTrLut8DM+hw4S1pSI1pi8l 7C7WNuxotuyZKcjrlIUQFapUBxUjzu2sDBV4cRF/rlOX9bZ4UYqB82P6UiXVt4HZ 6onm+ceIWe2DNmFD9uBSYG7yjCy7o3BncAw5bg3lxK5vG8UTfZz6KMmYTZSqg5g= =TaB9 -----END PGP SIGNATURE----- --Apple-Mail=_FDF5775B-B349-4756-B227-7D75469ED2D3-- From nobody Wed Apr 12 15:09:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6A7129ADF; Wed, 12 Apr 2017 15:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 hZl98-wXXQcm; Wed, 12 Apr 2017 15:09:38 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 0993112951B; Wed, 12 Apr 2017 15:09:38 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k87so41125475ioi.0; Wed, 12 Apr 2017 15:09:37 -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=Zp4ep3Iqkm2Yjrut9BSNbk6X7aA5MfN7Bo+VYjNnoGI=; b=A2ogp++pd4257+i22hAiqOQKY36Oxn+c94jVk/N37pk8EFdYM1/ybSSYpS0K0TAF9s kfoj/U2WzRtI0XYoGwHhU1jp4ZFKnXkUSMbo7WQ/f5S5XylrJOw2xDSUWhT+z25cbYHZ GBfWEi+IwIXF+KZIZoWqmL35AHvh/NfGv07Osh/mPrYDca4LgMXTvS3nIqESXqwawQRu V5WO8UwN8v8ZN4Nz6gG96m0v3xtcI6xOyw9/W+mjtPOwZZ4Usui20+bsdHcv908Nh4p0 zFxdg2+b9kNy4YDyWAajeQwftEs+p2ofXJdD5nA79+qh/9FF8xnLE8iOzE9SaPzQSAu3 k7vg== 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=Zp4ep3Iqkm2Yjrut9BSNbk6X7aA5MfN7Bo+VYjNnoGI=; b=pYyCtjcxLLV6SrTaH5O9yMGAnKywlXluXQuj0Va9jhqoSrDvolP39Wq6W4TEv/yuUT AK1/L8XtgPBzKSifKbt+FEFsN3STkd2CVpEeLHJpSQmbHk49ugjFIy/LLEheGRznTj3A VEUILDUJnVs95iY7cdWGErcc9dzaB8peE4V04GdarnEnKDAm6bkzLn+uUuwXNcXwEwN4 74yTbz1tdI1ISXgh/OY0z/4MPg+0fBygUSzE2rKf8Q4zgIVGM4SWNu6rlyJ2iYxysWW+ v0clRvJ2Kc5UelQogWiZJBf0IWkC/xJYMzTAzqnqJ/S4AXNzVFMnH9JqA9LI084Rqtag vekA== X-Gm-Message-State: AN3rC/5yAApqi5hIUNMNm/LY52yAOAU0zJk9JEkeUlWZnonolsRtStNk IFxH5fey5PEmVg== X-Received: by 10.107.12.167 with SMTP id 39mr545222iom.28.1492034977174; Wed, 12 Apr 2017 15:09:37 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id h42sm2551047ioi.16.2017.04.12.15.09.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 15:09:36 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_176360CF-3E24-48DC-BC1C-B913EFD069F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Wed, 12 Apr 2017 15:09:34 -0700 In-Reply-To: <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:09:44 -0000 --Apple-Mail=_176360CF-3E24-48DC-BC1C-B913EFD069F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, > On Apr 12, 2017, at 2:48 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Ole, >=20 > see below. >=20 >> Am 12.04.2017 um 22:35 schrieb otroan@employees.org: >>=20 >> Mirja, >>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> My discuss is mainly on text in section 4.8 (also based on the = tsv-art >>> review -> Thanks Martin!): >>=20 >> See also Bob's response to Maritn. >>=20 >>>=20 >>> I find the recommendation to basically just not use hop-by-hop = headers in >>> section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't = it >>> be maybe time to just deprecate the current hop-by-hop number an = assign a >>> new one? I know that also has deployment problem but maybe it's = worth a >>> try. I guess the assignment could happen in a new document though, = but >>> the deprecation could be done here. >>=20 >> The Hop-by-Hop header (HBH) is a container option. It has the = protocol value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. >=20 > Sorry, I meant hop-by-hop option in this case. >>=20 >> RFC2460 has: >> The Hop-by-Hop Options header is used to carry optional information >> that must be examined by every node along a packet's delivery path. >>=20 >> The problem with this was that implementations ended up punting = packets with the HBH to software, essentially opening up for a DOS = attack, which again led operators to filtering out packets with the HBH = =3D=3D 0. >> (While at the same time there were no HBH options with cross Internet = significance). >>=20 >> How the HBH option could be saved has been discussed for quite some = time in the 6MAN working group. >> Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 >> Which conclusion got included into 2460bis. >>=20 >> The working group thought it premature to deprecate the HBH option = header. >> As a way to "rescue" the HBH option we have made one significant = change: >>=20 >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >>=20 >> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >=20 > I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >=20 >>=20 >> What we lose by this approach is that one cannot use mandatory = options anymore. I.e. options that MUST be processed by every router = along the packet's path. RFC2675 for example is a mechanism depending on = that. In our view this is not a problem, since routers with links with = MTU larger than 64K would have to be configured and would be within a = controlled domain anyhow. >=20 > Yes, I also don=E2=80=99t see that as a problem. It=E2=80=99s anyway = always hard to ensure that something is process by every hop. Not sure = that would have been achievable in reality every. >=20 >>=20 >>>=20 >>> This related to this comment from Martin's review, also proposing a >>> potential way forward: >>> "- Section 4.8. "Defining New Extension Headers and Options": >>> It says new hop-by-hop headers must never ever defined. This is >>> problematic, as this closing the door forever, even if future = instances >>> of the IETF do would like to wish to define new hop-by-hop headers. = A >>> better way would have to say "that new hop-by-hop headers must have = IETF >>> consensus". >>=20 >> Yes, the door for a new HBH option header container is closed. >> Given that this is the signal that every router has to check. >> Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. >>=20 >>> - Section 4.8. "Defining New Extension Headers and Options": >>> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >>> especially with the phrase "There has to be a very clear = justification". >>> The term "clear justification" is not an exact engineering = specification. >>> Why not using "technical protocol specification and real word use = case >>> required, plus IETF consensus"?" >>=20 >> Defining new IPv6 extension headers is not recommended. There has = to >> be a very clear justification why any new extension header is needed >> before it is standardized. >>=20 >> The text does state "standardized" though. >>=20 >> Just to remind you that the Destination options header, the HBH = options header and the Routing header are all container options, which = allows for arbitrary number of TLVs inside. Since extension headers = share the numbering space with upper layer protocols, defining new ones = would require all implementations parsing header chains (e.g. to do = packet filtering on transport headers) would have to be updated. This is = the reason for the strict restriction on adding new ones. >=20 > See my response to Mike=E2=80=99s reply to Martin=E2=80=99s review: I = think what you better should say is that it is recommended to use a = destination option, if suitable, rather than a new header. I don=E2=80=99t= think you need to anything else than this about new headers. As it says in Section 4.8: Defining new IPv6 extension headers is not recommended. There has to be a very clear justification why any new extension header is needed before it is standardized. Instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility. >=20 >>=20 >>>=20 >>> As a side note, there is at least one experimental RFC that defines = a >>> destination option to be inspected by a network device, given the = know >>> problems of hop-by-hop option which renders them unusable. >>=20 >> Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. >=20 > It=E2=80=99s very costly but unfortunately currently the only way to = achieve that at all. Given that this experimental option is intended to = be inspected by only a few nodes on the path (not all) and usually these = nodes are close the edge, it=E2=80=99s probably still doable. >=20 >>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> One question because I'm not sure if I interpret this correct to = make it >>> part of my discuss: >>> Section 4.5: "The number and content of the headers preceding the >>> Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in >>> the reassembled packet." >>> Does this mean the ECN codepoint (part of the Traffic Class field) = is >>> copied from the first fragment? This doesn't seem to be correct, = however, >>> also not sure what the correct answer is. I know this was not = changed in >>> this revision but maybe we can still get this right. >>=20 >> When fragments are created most of the fields are copied from the = IPv6 headers (e.g., Source Address, Destination address, flow label, = traffic class, hop limit). Some like payload length, next header, and = hop limit are modified. >>=20 >> If I understand your question, the answer is yes, the ECN code point = is copied from the first fragment, but should be the same from all of = the fragments. >=20 > My concern is that the ECN code point could be changed on one of the = fragmented packets to signal congestion of a intermediate node and then = when you reassemble this information gets lost. That seems wrong. That is an interesting idea, but I think out of scope for advancing this = document to Internet Standard. Then there is the question of how to = encode n of m fragments experienced congestion. Interesting future = work. Thanks, Bob --Apple-Mail=_176360CF-3E24-48DC-BC1C-B913EFD069F7 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7qWeAAoJEK7rdBF357uo7k0IAIg8sCkekOmKoak56Dr+4ysn TBcWYSiReYLl0OAyhlOQUaEk2qGTVf5OdsvOdZ45jbItCisrUzUMDq2aq+tcRybE OBymCHinLrhnwTA9TrFAzRo/M5F3y1rEu00d86J0cS8rEx7Qc7+lSbMteB1kTm9A ArLyN4ASTP8e0v2BqeqxdDmmr20+CfnyCyZ+gaAoHVwKQltX7kvGU7qhNSFo2uhQ tuIomh97sJV+01HyGvualHJARt1f9zAfGhE8gvV9+uQithFIyc+hlSRWkecZcVwb COM2+WbloyqGL2yV7FfXIGimiQAL1OOCC/Oo7sTUQsUxlQ5ih2nGV8eSCuOfSFo= =so82 -----END PGP SIGNATURE----- --Apple-Mail=_176360CF-3E24-48DC-BC1C-B913EFD069F7-- From nobody Wed Apr 12 15:37:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D9512EB5D for ; Wed, 12 Apr 2017 15:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 5hBHD1KjFd11 for ; Wed, 12 Apr 2017 15:37:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8E129AD0 for ; Wed, 12 Apr 2017 15:37:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A38D0203BE for ; Wed, 12 Apr 2017 19:02:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3ECA0636E0 for ; Wed, 12 Apr 2017 18:37:22 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: Re: Mirja =?utf-8?Q?K=C3=BChlewind's?= Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) In-Reply-To: <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 22:37:32 -0000 {cutting out a bunch of lists} otroan@employees.org wrote: > NOTE: While [RFC2460] required that all nodes must examine and process > the Hop-by-Hop Options header, it is now expected that nodes along a > packet's delivery path only examine and process the Hop-by- Hop Options > header if explicitly configured to do so. > Which means by default routers unless they have been configured to > process a particular option contained in an HBH option, shall forward > the packet as normal. Thereby rectifying the attack vector. > What we lose by this approach is that one cannot use mandatory options > anymore. I.e. options that MUST be processed by every router along the > packet's path. RFC2675 for example is a mechanism depending on that. In > our view this is not a problem, since routers with links with MTU > larger than 64K would have to be configured and would be within a > controlled domain anyhow. What I don't understand is why, given that processing all options is now opt-in, why the upper-bits have any meaning at all? I thought we were going to deprecate the meaning, and then we weren't. I also note that rfc2460bis doesn't update the host requirements, so a host might still do the old thing, and the packet gets dropped anyway. I wonder if we shouldn't hold rfc2460bis until we update host-requirements. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Apr 12 17:05:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97812941C for ; Wed, 12 Apr 2017 17:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 l_481uPuE42i for ; Wed, 12 Apr 2017 17:05:13 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 2C15212786A for ; Wed, 12 Apr 2017 17:05:03 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id x125so22026793pgb.0 for ; Wed, 12 Apr 2017 17:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=GgusRxQ54TTxqm0efdRcgDgs/Rg3ME0dJQYh9iKbW24=; b=QVPPXDwOve0Q1Pn+JtBi/YUDMPKAua0p8yCI96VYCGbJ3npFZG9d8x6x96FNrspQmd rsE7TcbI3jsXcye7gwBIDwSJRsnGkqQDdGczQ00zeimz90VdEO7VKBZmZwlbrX6NTIIH qRZJBsqNOgim8zP8BIkWzG8PaIeDhQ9gwwd88m0v/LXYo3bOGmIjeILggdcD/SX8aN55 bu9Nji8ZguqTYkDFTvNSEyhz5JgB/ie6u+Ay4bbi8oJCdKSAu3fDlP5Dcj4XJta7Dp1p lAVeu5TJmlPx7DAvltwr1Xe2q3tXtLRpqia/oT5J1OrUv6ZhisUbF0XmRu7xyuC7uxlt gj9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GgusRxQ54TTxqm0efdRcgDgs/Rg3ME0dJQYh9iKbW24=; b=T5xQONAS/qhV/8/jI6vdzNy8RbnecSeNtWJir6hKiPn659s7a4FYsM0ziU8oEgQNxC 7cOqOA6YisvzzIT/QStMJNPCEpyKvZ1ZV3j6eb6EhC0lFVomcqylTBDtfuJBzGsbTD4g heeWNszJzs7YjIkaaTbRNL6QrNDXrLqT1HDo7EtbvYyVc85mkrel/7L9eWAOWGc/BSdm ZPIqGPD+du0J+/bAECqomrkIxXA9H/irdhxgALog5tOB3/SLGm/nekURLenjrTL/Nn+N lLU/8SCLl1a1JnhtCbBvcKUH2Iu+bElVhSTAcpjHzqO1Ytq4ekRICLttS2y/zed5A1m6 dScA== X-Gm-Message-State: AN3rC/4B4ZfS2CteWO3yRw1TXE9elhcmmEl+21H4Y9Dq7K6bGSfaA41A 5wUh75S20uk/rLwo X-Received: by 10.84.236.74 with SMTP id h10mr408782pln.91.1492041902584; Wed, 12 Apr 2017 17:05:02 -0700 (PDT) Received: from [192.168.178.26] ([118.149.111.148]) by smtp.gmail.com with ESMTPSA id 4sm38534980pff.17.2017.04.12.17.05.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 17:05:02 -0700 (PDT) Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 13 Apr 2017 12:05:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 00:05:15 -0000 On 13/04/2017 04:41, Mirja Kuehlewind (IETF) wrote: > Hi Mike, >=20 >=20 >> Am 11.04.2017 um 23:31 schrieb C. M. Heard : >> >> On Tue, 11 Apr 2017 21:14:06 +0200, Martin Stiemerling wrote: >>> Major issues: >>> >>> - Section 4.8. "Defining New Extension Headers and Options": >>> >>> It says new hop-by-hop headers must never ever defined. This is probl= ematic, >>> as this closing the door forever, even if future instances of the IET= F do >>> would like to wish to define new hop-by-hop headers. A better way wou= ld have >>> to say "that new hop-by-hop headers must have IETF consensus". >> >> If a new extension header with hop-by-hop behavior were defined, >> it would require a router or other forwarding device to look >> beyond the header immediately following the base IPv6 header, >> possibly even arbitrarily deep into an IPv6 header chain. That's >> not backward compatible with the existing specification, which was >> written the way it was to limit the amount of header processing >> required in the forwarding path. >> >> Can you provide an example of anything that can be done with a >> new hop-by-hop extension header that cannot also be done with >> a new hop-by-hop option? >=20 > Given the current hop-by-hop header is partially not usable, everything= =E2=80=A6 But the reason it's not fully supported is intrinsic to the words "hop by= hop". Router designers don't want to spend cycles this way, that's all. =20 > I thinking would be to basically replace/deprecate the old one and defi= ne a new one. That is way out of scope for the promotion to IS (no new features). And a= s Bob points out, HbH must come first, so you can't have two... Brian =20 >=20 >> >>> - Section 4.8. "Defining New Extension Headers and Options": >>> >>> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension he= aders looks strange, >>> especially with the phrase "There has to be a very clear justificatio= n". The >>> term "clear justification" is not an exact engineering specification.= Why >>> not using "technical protocol specification and real word use case re= quired, >>> plus IETF consensus"? >> >> We could perhaps make this clearer by stating that a new extension >> header must not be defined unless it can be proven that the desired >> functionality cannot reasonably be provided either by a new >> destination option or by a new upper layer protocol, but I'm not >> convinced that it's that much of an improvement - there's that >> pesky word "reasonably," which still implies an exercise of >> engineering judgment, which you seem to want to avoid. >> >> For a necessarily imprecise analysis of which of the existing >> extension headers meet the "cannot reasonably be provided" >> criterion, please see >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html >=20 > I have to say I find this phrasing also to be useful. I guess the real = point is to recommend to rather use a destination option if possible than= defining a new extension header. >=20 > Mirja >=20 >=20 >=20 >> >> Mike Heard >> >> _______________________________________________ >> Tsv-art mailing list >> Tsv-art@ietf.org >> https://www.ietf.org/mailman/listinfo/tsv-art >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Apr 12 18:31:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607B6127909; Wed, 12 Apr 2017 18:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 bXkak6ad2oQ0; Wed, 12 Apr 2017 18:31:41 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 988E1126C7B; Wed, 12 Apr 2017 18:31:41 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id i5so21376147pfc.2; Wed, 12 Apr 2017 18:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0n9v6w3dpJ4fDPRvO73ALqlZwKY2ZGxhwdlv6/gp+GY=; b=nuuAnLye0H3mLbdHAA1VUDOxMhEOZpjnQa81dnrQy0k2O932ySnLMuznFOXiJz6Pb4 E0YAPq5PCrD0K6Oer8F/h1Y+Eoq8Ncd1CkTvaRUtFSiq2QjhNjMxVjtHwAoZuvFEyj9h QVVuAlm8Ki7sFh2B96bQS1AdDsvwckp9Pbrd4PLxFG/93Aes5AflA4xo9h5oLtqc0zwV 7p0/FrTGq1VX2A0Nk+i9i35XDHPaQa+mWWop4/anmNoH9MWt7SYDv1yiVh1f9IJ84Plc vmVRDhGpoka9xZpdqJgKD4td4LaHxr5pxTb6nF41z0o/2OzMnDbjX4qgZme1yoG7nDZ6 5hIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0n9v6w3dpJ4fDPRvO73ALqlZwKY2ZGxhwdlv6/gp+GY=; b=WjbcY6dRXiPWt8J9CqzP3MnhQs+AaBMqPGyIz5IFOK1Rlsfc77aRpCgzt8v5/nf5r4 Fs100Y/Rz58W798n8KgowYrePfwIHo6IbyyTe9kacrwGtCM8L4Ra1lCpCO1tTJOQEDZL m/aUqQiLAX4kjbtwfRb09nb0rpoDzBObeRFmP8L1S4Wiyu3d+eM80gzDjvCo/qAc1286 0nO/t8s+PMAk41Coqn9RjLQ9rau9ii1k/w6gRCc2NWMcWRTxGP/Muz1JZOs6PaapG11Z 4fOf6CIRPA2yALhlvsq5HIAgQ1YgAfvEKWedRslkBhQpJxlXWY4glhD3oufODA2Flqdj WIiA== X-Gm-Message-State: AN3rC/7c57xkJsKCv20FXIdgF09uigv2s6CQbT4TZWejfGXpFnjbgBC8 p/ezKaPaX18MrA== X-Received: by 10.99.37.1 with SMTP id l1mr667803pgl.86.1492047100979; Wed, 12 Apr 2017 18:31:40 -0700 (PDT) Received: from [192.168.178.26] ([118.149.111.148]) by smtp.gmail.com with ESMTPSA id r13sm38741776pfg.55.2017.04.12.18.31.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 18:31:40 -0700 (PDT) Subject: Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) To: Bob Hinden , "Alvaro Retana (aretana)" References: <149159039616.11195.17680235063548847108.idtracker@ietfa.amsl.com> <95820C53-D993-490D-9CE6-0BF5CC169CE9@ericsson.com> <3BD2F772-D731-4A63-8090-B8B820FE10AE@jisc.ac.uk> <86CAC0F7-1A86-49FC-8AE9-DBFE361D9C4C@employees.org> <96A7997A-D6EA-413B-AB6F-5B2CBE4110DA@gmail.com> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 13 Apr 2017 13:31:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:31:43 -0000 I'm still not sure it's explaine completely by Bob's reply: On 13/04/2017 10:03, Bob Hinden wrote: > Alvaro, >=20 >> On Apr 12, 2017, at 2:49 PM, Alvaro Retana (aretana) wrote: >> >> Bob: >> >> Hi! >> >> No, that was not my question. >=20 > OK :-) >=20 >> >> Ole mentioned that =E2=80=9CThe Destinations Options header are only p= rocessed at the destination host, so an option can then only change en-ro= ute when it is part of a source route path (and the Destination options h= eader is before the routing header).=E2=80=9D That =E2=80=9Cfeature=E2=80= =9D (as Ole called it) is not part of the text. >=20 > That can be inferred by how destination extension headers are defined. = That is. they are processed at the destination indicated by the IPv6 des= tination address in the packet header. From Page 9: >=20 > note 1: for options to be processed by the first destination that= > appears in the IPv6 Destination Address field plus > subsequent destinations listed in the Routing header. In other words, if the packet is sent initially from S to D1, D1 may process the destination options. If a routing header, also processed by D1, flips the destination to D2, the destination options may be processed by D2, and so on to the final destination Dn. However, other routers on the path S--D1--D2----Dn do not process the destination option= s, only HbH options. That is indeed implied (but not explained in detail) by RFC2460 and RFC24= 60bis. Brian >=20 > Where Note 1, is for the Destination Options header on the previous pag= e: >=20 > Destination Options header (note 1) >=20 > Options in the hop-by-hop header are, of course, processed at every hop= =2E >=20 > Bob >=20 >=20 >> >> Alvaro. >> >> >> >> >> >> On 4/12/17, 5:45 PM, "Bob Hinden" wrote: >> >> Alvaro, >> >>> On Apr 11, 2017, at 2:33 PM, Alvaro Retana (aretana) wrote: >>> >>> Ole: >>> >>> Hi! >>> >>> Thanks for the clarification! It would be nice if the document also = said this =E2=80=93 from what I could read, the text doesn=E2=80=99t matc= h what you said =E2=80=93 or did I miss it? >> >> On page 10: >> >> The third-highest-order bit of the Option Type specifies whether or >> not the Option Data of that option can change en-route to the >> packet's final destination. When an Authentication header is presen= t >> in the packet, for any option whose data may change en-route, its >> entire Option Data field must be treated as zero-valued octets when >> computing or verifying the packet's authenticating value. >> >> 0 - Option Data does not change en-route >> >> 1 - Option Data may change en-route >> >> Was that your question? >> >> Bob >> >> >>> Alvaro. >>> >>> On 4/11/17, 5:17 PM, "otroan@employees.org" wr= ote: >>> >>>> >>>> The initial sentence mentions 4 actions: examine, process, insert, o= r delete. >>>> The text already says that any node can examine the headers =E2=80=9C= for any reason=E2=80=9D, according to [rfc7045]. So maybe take that out = as part of the original 4. >>>> I do have an additional clarity question. What does =E2=80=9Cproces= s=E2=80=9D mean? Does it include a =E2=80=9Cchange en-route=E2=80=9D? = I=E2=80=99m asking because Section 4.2. (Options) says that =E2=80=9Cthe= Hop-by-Hop Options header and the Destination Options header=E2=80=9D ha= s an option bit that indicates =E2=80=9Cwhether or not the Option Data of= that option can change en-route to the packet's final destination=E2=80=9D= =2E I=E2=80=99m assuming that to change the data the transit node has to= not just =E2=80=9Cexamine=E2=80=9D (which I think means =E2=80=9Clook at= =E2=80=9D), but also (at least) =E2=80=9Cprocess=E2=80=9D the EH as well.= If to =E2=80=9Cprocess=E2=80=9D includes the ability to =E2=80=9Cchang= e en-route=E2=80=9D, then it looks like the Destination Option may also b= e an exception=E2=80=A6 >>> >>> Both options inside of an HBH option header and a Destination Options= header can have the change en-route flag set. >>> The Destinations Options header are only processed at the destination= host, so an option can then only change en-route when it is part of a so= urce route path (and the Destination options header is before the routing= header). >>> >>> The "feature" here is that one can specify options that can be proces= sed only by the routers listed in a routing header or one can specify opt= ions that can change en-route for every hop along the path. >>> >> >> >> >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Apr 12 18:45:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F43128BB6; Wed, 12 Apr 2017 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 hIhvmsNFgjFV; Wed, 12 Apr 2017 18:45:34 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 D76551286B1; Wed, 12 Apr 2017 18:45:33 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id g2so8316843pge.2; Wed, 12 Apr 2017 18:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=97L6kZ1oz54delRtSgmPBA4i+woB1JjCkP9pwTEFKtg=; b=kPwMt710aoEWzkW2f444XQUnqNz2Tjt9ujY+97RA6DmBP28bqlS+n6V+Su6aJPfLHv ebEK07I5zfiCj3G2uRMaj3Iys4qNG0C42/VR1PZSyrv+ZBI6+Rl5jYWUZlZASJSypWzu oPgnKvGmr7l8/GWZRJgQ+EybxwRcy6PFcZIkrcJQ9k+heSAoltfXVBRsNfPk8iPC+xsL +G3tIEG3GJq0iLCdujQkozk+mBl2/i38kx79pbXPt2nOfQveBSb2UEWvsyujtqiooWHd cLKBwSdlDsftzNIfg4PStpxwGo5hb17d243vSc3CfdmtGa7a0sq6r4kuPXnSAOwYJNDD kN1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=97L6kZ1oz54delRtSgmPBA4i+woB1JjCkP9pwTEFKtg=; b=Ziqu4eQYxx0iAfPWJspkHSWsZP9cO0UvyzuJyp7nZepq/h5+zwe2/P3XXGUWNx62BU LeOfPFpzJpwkBrlm/sG2MrJCBnQkIvzFrjI2+WSFqEWADmYwgv4O9MXJ9j2GaH/08TuE Kn5Q/2fGH8uNeJ62mYCQT2nhNQ5yaNXbGxOO+sWHurP4078MBi7aBOHt2+fCIvSYJ8vK Hv58At5H+ASB0MXVMAALMMXmGmxyKG0bPcecXic0qu7ZMukFI6XrqNWl9Zc7KUyc88l5 4hIYtCtetUxHWdr1hO3cA97aNYSQCp1RLJckM/yRLU63gh5mxMMXkwxrbM+QBasW9fMt Fhfg== X-Gm-Message-State: AN3rC/7lwhrCmtBM+fyDLYCfv0z6GxPaLwPha0EE34njIB/Wx+e7G0cR vXjbTV1Nm4/Yig== X-Received: by 10.99.106.66 with SMTP id f63mr701281pgc.46.1492047933505; Wed, 12 Apr 2017 18:45:33 -0700 (PDT) Received: from [192.168.178.26] ([118.149.111.148]) by smtp.gmail.com with ESMTPSA id n67sm38718550pfk.44.2017.04.12.18.45.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 18:45:32 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" , otroan@employees.org References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> Date: Thu, 13 Apr 2017 13:45:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:45:36 -0000 On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote: =2E.. >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >> >> Which means by default routers unless they have been configured to pro= cess a particular option contained in an HBH option, shall forward the pa= cket as normal. Thereby rectifying the attack vector. >=20 > I=E2=80=99ve see this change and it=E2=80=99s a step in the right direc= tion but it doesn=E2=80=99t solve the problem given there are already dep= loyment that still put packets with an hop-by-hop header on the slow path= which still renders the hop-by-hop header as currently defined unusable.= I think I'm repeating myself due to jet lag, but this problem IMHO has *n= othing* to do with the current definition of HbH. It's to do with the very nature of HbH - s= omething we are asking *every* router in the Internet to do. The core routers in transit = providers will never do that. Redefining the HbH header cannot change that; it's intrins= ic. The above quoted Note was a WG consensus choice to resolve this issue, ii= rc, adapted from section 2.2 of RFC7045. Brian From nobody Wed Apr 12 21:33:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4749D127241; Wed, 12 Apr 2017 21:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 ncQkKPjywMfi; Wed, 12 Apr 2017 21:33:14 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 0C89E1242F5; Wed, 12 Apr 2017 21:33:14 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z109so28296346wrb.1; Wed, 12 Apr 2017 21:33:13 -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=gVZTfpNukBkk0FFQU9Ikg9q/A7txrQEzzOoMiEpALFg=; b=NEV0R+oWmxHnMKt+wCm6cSqQFS/QpaQ9/tGQDZjiDjF3a7D/lp9uw40eyeIBZmMzlo 8+imttJJz4HUhPplr0Z+vE5DvOyFGlT/dT87rB5PEPHICzI/j1ejdi0V4wNRVsjdrz23 kROkWCyty+5Tj99Pmf+7aHsCnGzHmeRlWqvag/osqREhG9NQkqRidN68O4aqT/o2Hd8F R8wauAyhlgMxv4KukW7hbrgvR7rLF/vTsjj3dqzYNyLSmcR628tdz3D0DTnwqz9jjAPf bKnBsePTQ1K9Nhj0mJTtUYLY/H76+8UEnIxDr/FELVJBKalM6xvmzY+mA2xt4WdS/HkN 8t/A== 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=gVZTfpNukBkk0FFQU9Ikg9q/A7txrQEzzOoMiEpALFg=; b=kIPtE/gKESDxjr5Mdyb1uTALmu8xZGhaxsuIG9+43Y7qTX4pYvNzi86hx3BXe93qV3 dMGpDahoqJmsZ7p255thOXJ2GzJIWTbnyzcM6tZygMei+OIqHznpVLy9Njiu5xb0Zq23 AUceSKdHFOduf1eoqlL7TQadDeChbfsIiTeLwlW1DNVfdnf4mw7MF6WLuYQ4pjba4tpd HVko/pA4rOp9yLU4MpfzWgMB/1DMJBvObBn7G/LsUzQtBBK1J135wKOO84Fd7KNgjjln tYyjERQL/vpxl9oiSy5FzfUT8jgpl1bbq7U+8LVwzoqzCjjpS8avSvnagjD53XDNt2hX SXow== X-Gm-Message-State: AN3rC/59unrqMdRjNUnZZI5e8QRDiS9yduSs2z50q1lbiKIaI7KVUVw9 7G8mXlXUpNk8WQ== X-Received: by 10.223.161.130 with SMTP id u2mr781893wru.203.1492057992457; Wed, 12 Apr 2017 21:33:12 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:8cee:ca98:6ec9:ce? ([2601:647:4d01:db10:8cee:ca98:6ec9:ce]) by smtp.gmail.com with ESMTPSA id b82sm8962657wmh.4.2017.04.12.21.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 21:33:11 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AAF31C9C-6360-4A2A-B602-A72F357E4CC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Eric Rescorla's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) Date: Wed, 12 Apr 2017 21:33:06 -0700 In-Reply-To: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-rfc2460bis@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man-chairs@ietf.org, IPv6 List To: Eric Rescorla References: <149165861661.3204.6123030248038692210.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 04:33:16 -0000 --Apple-Mail=_AAF31C9C-6360-4A2A-B602-A72F357E4CC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric, Thanks for the feedback. Comments below. Bob > On Apr 8, 2017, at 6:36 AM, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-6man-rfc2460bis-09: Discuss >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Discuss (2017-04-08) > This security considerations section seems fairly unsatisfactory. > First, you can't just point back to IPv4, which doesn't even have a > security considerations section. Second, IPv6 actually has > different security and privacy properties than IPv4 in > a number of respects, so you actually need to document them. I agree it=E2=80=99s pretty minimal. I will work on some new text. > ---------------------------------------------------------------------- > DISCUSS: > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > I get that this document is from a period before the style > became as uniformly to upper-casify RFC2119 keywords, but > but it seems like it might be a good idea to do that here. >=20 > It's a little hard to determine what is normative here, but S 4. says >=20 > A full implementation of IPv6 includes implementation of the > following extension headers: > Hop-by-Hop Options > Fragment > Destination Options > Routing > Authentication > Encapsulating Security Payload >=20 > Given that 6434-bis seems to have backed away from IPsec, this > document needs to as well. While I don=E2=80=99t object, the revision of rfc6434 is a work in = progress and removing ESP from this list has not yet been discussed in = the w.g. >=20 > S 4.4. > Assuming I am reading this document correctly (and I've never > implemented v6 so I could be crazy), in order to implement > the routing header you need to decrement Segments Left, > but the document does not seem to say that. The details regarding the operation of a specific type of routing header = are specified in the documents that specify that routing header. The = earlier version of this specification (RFC2460) specified Routing Header = type 0 and it did specify the operation (Pages 14-17). Since this = routing header type 0 has been deprecated the base IPv6 spec does not = describe any specific routing header operation. It says in the end of = this section: The currently defined IPv6 Routing Headers and their status can be found at [IANA-RH]. Allocation guidelines for IPv6 Routing Headers can be found in [RFC5871]. For example, RFC6554 defines the how Segments Left is decremented for = RH3. >=20 >=20 > S 4.5. > As I read this document the order of headers is only strongly > recommended, but the rules about fragmentation seem to absolutely > require a specific order: >=20 > The Per-Fragment Headers consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to = the > destination, that is, all headers up to and including the = Routing > header if present, else the Hop-by-Hop Options header if = present, > else no extension headers. >=20 > Is there a reason why the rules are not MUST? I think the rules for fragmentation could be strengthened, like =E2=80=9CT= he Per-Fragment Headers must consist of the IPv6 header=E2=80=A6. >=20 >=20 > S 4.5. > The following conditions are not expected to occur, but are not > considered errors if they do: >=20 > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. >=20 > If fragments follow different paths (not crazy) then the hop limit > will be different, right? So perhaps "not expected" is a bit strong. This is clarifying that if fragments reach the destination with varying = number and content of headers proceeding the fragment is not an error. = That is, don=E2=80=99t discard it. I can=E2=80=99t speak to how frequent fragments arrive with different = hop limits, but as long as they arrive at the destination they will be = reassembled. We could change it to =E2=80=9Cnot expected to occur frequently=E2=80=9D. >=20 >=20 > S 8.4. > Response packets that carry Routing headers that were derived > by reversing the Routing header of the received packet IF AND > ONLY IF the integrity and authenticity of the Source Address > and Routing header from the received packet have been = verified > by the responder. >=20 > It's not clear to me how this works. If, as I suggest above, the > routing header gets changed in transit, how do you measure > the integrity and authenticity? Even if that is not the case, > and you use something like IPsec to provide integrity, why do you > trust whatever claims the sender makes about routing. >=20 It would have to be defined in a specific Routing Header specification. = I read this as saying don=E2=80=99t reverse the route unless you are = very confident in it=E2=80=99s contents. In most cases, you can=E2=80=99t= , so don=E2=80=99t reverse it. >=20 --Apple-Mail=_AAF31C9C-6360-4A2A-B602-A72F357E4CC1 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY7v+DAAoJEK7rdBF357uoyd4H/23cTM5hAS27fDGWqvTPuq2T K95G8LMi8uQQRXMYPLxfhDWRF/RJL4fN+eqykpS2ENHRSTRmDppavHcRZAWjk5Cu NTS0Zy1s32TfKBMVTts4hhxnW9EihCLq2K/V62EcRKQ5HJWXO4Lr5jRJ4IH+c+h8 egZKwGBgUTeKsCstFlLfiYJgdw9bQT8ElKHVuye6dNx8tq0ey/swpfBirvdHzuLK dXxuvfCUL432jiRotRXxv3fMVTJHatQVxRWoFjbs4eWh0VSu9sSt6I80zYMgL09R +I2XqU8X8I2sz+ONcOR4XBSSHQWzzFNqGVyse/5eQJW7Nw68gZWXaZAWIlMRVgM= =LBtK -----END PGP SIGNATURE----- --Apple-Mail=_AAF31C9C-6360-4A2A-B602-A72F357E4CC1-- From nobody Thu Apr 13 02:40:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4412FC17; Thu, 13 Apr 2017 02:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 wb7LfIM1rKPI; Thu, 13 Apr 2017 02:40:56 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 696851300BC; Thu, 13 Apr 2017 02:40:56 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 09:40:56 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F04D8D788E; Thu, 13 Apr 2017 02:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=D4bgej+Gd2rm66lRxo6Nzm/QZiY=; b= KmESvukQtOcCs8JcAGFPEHRKLVdG1zPNH+sJWXhMFEzPlAbhzUWWWbiYCjzRImoe HAXiq9rkr22xT46WyWi/AVk9tqNTYNi5H9pWI8SvG3cT/meBtTlqr3C5HHfQsdvf OhHyQaNqnw+dO3eatrSJfhwYEjuvhnQiInE9efSWKnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=S/51G2XoilgVoQHtvClfKMr aTz2lBAgeMMXTXKbuU0a/AZgvhBetGmfB/NmkfbEokfmCCtzYRNiO1DVHS+UvWNe ECA9em72KTZ30klujU750m7ULTKFlHDEVLHX764l71veDFfN1RWr1AD/++W28/zp oQTSoDEJSHDDszPDZzZQ= Received: from h.hanazo.no (77.16.76.254.tmi.telenormobil.no [77.16.76.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7C2EDD788D; Thu, 13 Apr 2017 02:40:55 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 93319A9A6968; Thu, 13 Apr 2017 11:40:51 +0200 (CEST) From: otroan@employees.org Message-Id: <05482791-E24E-4C4F-AE39-D111C005AB0B@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D5086B14-A8C8-47EE-B87B-300E3ADCC8C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 13 Apr 2017 11:40:50 +0200 In-Reply-To: <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 09:40:58 -0000 --Apple-Mail=_D5086B14-A8C8-47EE-B87B-300E3ADCC8C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja, >> The Hop-by-Hop header (HBH) is a container option. It has the = protocol value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. >=20 > Sorry, I meant hop-by-hop option in this case. Ack, and you can define new hop by hop options, as long as you are aware = that with the new behaviour only nodes configured to process them will. = And it is in general though to make expectations of these options being = processed across administrative boundaries. >> RFC2460 has: >> The Hop-by-Hop Options header is used to carry optional information >> that must be examined by every node along a packet's delivery path. >>=20 >> The problem with this was that implementations ended up punting = packets with the HBH to software, essentially opening up for a DOS = attack, which again led operators to filtering out packets with the HBH = =3D=3D 0. >> (While at the same time there were no HBH options with cross Internet = significance). >>=20 >> How the HBH option could be saved has been discussed for quite some = time in the 6MAN working group. >> Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 >> Which conclusion got included into 2460bis. >>=20 >> The working group thought it premature to deprecate the HBH option = header. >> As a way to "rescue" the HBH option we have made one significant = change: >>=20 >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >>=20 >> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >=20 > I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. It has a somewhat higher drop probability but it is not unusable. When = implementations are updated with the new behaviour then the hope is that = it will become more usable. >> What we lose by this approach is that one cannot use mandatory = options anymore. I.e. options that MUST be processed by every router = along the packet's path. RFC2675 for example is a mechanism depending on = that. In our view this is not a problem, since routers with links with = MTU larger than 64K would have to be configured and would be within a = controlled domain anyhow. >=20 > Yes, I also don=E2=80=99t see that as a problem. It=E2=80=99s anyway = always hard to ensure that something is process by every hop. Not sure = that would have been achievable in reality every. >=20 Exactly. >>> This related to this comment from Martin's review, also proposing a >>> potential way forward: >>> "- Section 4.8. "Defining New Extension Headers and Options": >>> It says new hop-by-hop headers must never ever defined. This is >>> problematic, as this closing the door forever, even if future = instances >>> of the IETF do would like to wish to define new hop-by-hop headers. = A >>> better way would have to say "that new hop-by-hop headers must have = IETF >>> consensus". >>=20 >> Yes, the door for a new HBH option header container is closed. >> Given that this is the signal that every router has to check. >> Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. >>=20 >>> - Section 4.8. "Defining New Extension Headers and Options": >>> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >>> especially with the phrase "There has to be a very clear = justification". >>> The term "clear justification" is not an exact engineering = specification. >>> Why not using "technical protocol specification and real word use = case >>> required, plus IETF consensus"?" >>=20 >> Defining new IPv6 extension headers is not recommended. There has = to >> be a very clear justification why any new extension header is needed >> before it is standardized. >>=20 >> The text does state "standardized" though. >>=20 >> Just to remind you that the Destination options header, the HBH = options header and the Routing header are all container options, which = allows for arbitrary number of TLVs inside. Since extension headers = share the numbering space with upper layer protocols, defining new ones = would require all implementations parsing header chains (e.g. to do = packet filtering on transport headers) would have to be updated. This is = the reason for the strict restriction on adding new ones. >=20 > See my response to Mike=E2=80=99s reply to Martin=E2=80=99s review: I = think what you better should say is that it is recommended to use a = destination option, if suitable, rather than a new header. I don=E2=80=99t= think you need to anything else than this about new headers. A destination option would be the wrong thing to use. That violates the = premise for how this option is used. If you only want a certain set of nodes along a path to process the = header, that is the behaviour you will now get with HBH. An alternative is to use source routing with the routing header combined = with a destination options header. Just using the destination header for this is inefficient and is really = a "give up" choice, where you end up requiring all routers to go and = hunt for "interesting" options. >>>=20 >>> As a side note, there is at least one experimental RFC that defines = a >>> destination option to be inspected by a network device, given the = know >>> problems of hop-by-hop option which renders them unusable. >>=20 >> Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. >=20 > It=E2=80=99s very costly but unfortunately currently the only way to = achieve that at all. Given that this experimental option is intended to = be inspected by only a few nodes on the path (not all) and usually these = nodes are close the edge, it=E2=80=99s probably still doable. HBH or RH also lets you do that. Note that destination options also has = a higher drop probability than packets with extension headers. >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> One question because I'm not sure if I interpret this correct to = make it >>> part of my discuss: >>> Section 4.5: "The number and content of the headers preceding the >>> Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in >>> the reassembled packet." >>> Does this mean the ECN codepoint (part of the Traffic Class field) = is >>> copied from the first fragment? This doesn't seem to be correct, = however, >>> also not sure what the correct answer is. I know this was not = changed in >>> this revision but maybe we can still get this right. >>=20 >> When fragments are created most of the fields are copied from the = IPv6 headers (e.g., Source Address, Destination address, flow label, = traffic class, hop limit). Some like payload length, next header, and = hop limit are modified. >>=20 >> If I understand your question, the answer is yes, the ECN code point = is copied from the first fragment, but should be the same from all of = the fragments. >=20 > My concern is that the ECN code point could be changed on one of the = fragmented packets to signal congestion of a intermediate node and then = when you reassemble this information gets lost. That seems wrong. I do see your point. Is this behaviour described somewhere else? Best regards, Ole --Apple-Mail=_D5086B14-A8C8-47EE-B87B-300E3ADCC8C7 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY70eiAAoJEL7aWKiYQt929EEQAJfblr4lj//e11ge5q3VNEM4 +1iVvbruOftGMUPy5Epsxst17oNMiEDkJbC56SL3sRpAMDO6052MqeIDiL9nTKA5 m6f/RX4bUPYre9d1is7ONjXtF0KWfHy1avjNsWT+oercwRiTvPP8UwzPpWRtJOJG SjiicVex6RcaDHOI8dLieW+MMds3RuHJpLmR4aMela5r7EB34V191VpJ9t9MWOUK MJR2ZZsEhIS59toGmQ0JJwHlUqqw2/5BDuk44VlFodbwRI6BcawBKxVZ2SFHCkCe M1jxMN4vPfv1K0LEQMQIwo6ePcQWWt80OTfyCBMuR1VW1GN8bCdXnqPD6OUYm0Zo 4oYMdHIk3cWBu83gcbF1Fm8OhuNic5Ab/DZMoaGWvXCCQqIqksXgxMipC7YKKNt4 zfANqsIe+rdOf+8h2dnkWptluwVXhJtiIS00WGd0ozuXlSN35pGK/QjtDSVRKo3T +gA0pVJvysZdJIwBwu1sbAWKLOdCWTboOerp4EdaLhT027YXOAusFBZceEwxlyze 7F0yOdR+RKcR7J92r2Waxl19h8WBDA7t8y2lQsBk+zJDZTBayGH/oTliq6YZiXhP wljGmBAcZfRE7Q3wDz1MxJzHxbjIVDXXqoeyauiLDklD44sHLja0NCi0KCqitxba Vjs1qCGVJOzAnNkD4bDH =Vo76 -----END PGP SIGNATURE----- --Apple-Mail=_D5086B14-A8C8-47EE-B87B-300E3ADCC8C7-- From nobody Thu Apr 13 04:26:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9F13150C for ; Thu, 13 Apr 2017 04:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 n3rajxiaXcee for ; Thu, 13 Apr 2017 04:26:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82694127B31 for ; Thu, 13 Apr 2017 04:26:31 -0700 (PDT) Received: (qmail 17531 invoked from network); 13 Apr 2017 13:19:48 +0200 Received: from p5dec220c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.12) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Apr 2017 13:19:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> Date: Thu, 13 Apr 2017 13:19:47 +0200 Cc: otroan@employees.org, draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:26:33 -0000 Hi again, > Am 13.04.2017 um 03:45 schrieb Brian E Carpenter = : >=20 > On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote: > ... >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>>=20 >>> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >>=20 >> I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >=20 > I think I'm repeating myself due to jet lag, but this problem IMHO has = *nothing* to do with > the current definition of HbH. It's to do with the very nature of HbH = - something we are > asking *every* router in the Internet to do. The core routers in = transit providers will > never do that. Redefining the HbH header cannot change that; it's = intrinsic. >=20 > The above quoted Note was a WG consensus choice to resolve this issue, = iirc, adapted > from section 2.2 of RFC7045. I might repeat myself as well but anyway. The above quoted text is fine = but it does not solve the problem we have in reality. If the behavior = would have been defined the way it is defined now from the beginning = that would have been fine. However, there are router out there that put = all packets that have the HBH header in the slow path which makes the = HBH header unusable in practice. Redefining the behavior in the spec = opens the door to fix that problem but the deploy router will not go = away quickly, leaving a risk that your packets go on the slow path. Just = because there is this risk, I would not recommend to use any HBH option = (as the document does). However, if HBH are not usable, how can I then = achieve the desired behavior (where some of the router on the path are = allow to inspect and process some information in the IP extension = header)? Mirja >=20 > Brian >=20 >=20 From nobody Thu Apr 13 04:43:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8A13157E for ; Thu, 13 Apr 2017 04:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4wPfd8meGLUv for ; Thu, 13 Apr 2017 04:43:43 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2477A13157B for ; Thu, 13 Apr 2017 04:43:40 -0700 (PDT) Received: (qmail 18018 invoked from network); 13 Apr 2017 13:36:58 +0200 Received: from p5dec220c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.12) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Apr 2017 13:36:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 13 Apr 2017 13:36:57 +0200 Cc: draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , =?utf-8?Q?Ole_Tr=C3=B8an?= , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> To: Bob Hinden X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:43:47 -0000 Hi again, see below. > Am 13.04.2017 um 00:09 schrieb Bob Hinden : >=20 > Mirja, >=20 >> On Apr 12, 2017, at 2:48 PM, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Ole, >>=20 >> see below. >>=20 >>> Am 12.04.2017 um 22:35 schrieb otroan@employees.org: >>>=20 >>> Mirja, >>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> My discuss is mainly on text in section 4.8 (also based on the = tsv-art >>>> review -> Thanks Martin!): >>>=20 >>> See also Bob's response to Maritn. >>>=20 >>>>=20 >>>> I find the recommendation to basically just not use hop-by-hop = headers in >>>> section 4.8 extremely unsatisfying. Can we maybe do better? = Wouldn't it >>>> be maybe time to just deprecate the current hop-by-hop number an = assign a >>>> new one? I know that also has deployment problem but maybe it's = worth a >>>> try. I guess the assignment could happen in a new document though, = but >>>> the deprecation could be done here. >>>=20 >>> The Hop-by-Hop header (HBH) is a container option. It has the = protocol value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. >>=20 >> Sorry, I meant hop-by-hop option in this case. >>>=20 >>> RFC2460 has: >>> The Hop-by-Hop Options header is used to carry optional information >>> that must be examined by every node along a packet's delivery path. >>>=20 >>> The problem with this was that implementations ended up punting = packets with the HBH to software, essentially opening up for a DOS = attack, which again led operators to filtering out packets with the HBH = =3D=3D 0. >>> (While at the same time there were no HBH options with cross = Internet significance). >>>=20 >>> How the HBH option could be saved has been discussed for quite some = time in the 6MAN working group. >>> Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 >>> Which conclusion got included into 2460bis. >>>=20 >>> The working group thought it premature to deprecate the HBH option = header. >>> As a way to "rescue" the HBH option we have made one significant = change: >>>=20 >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>>=20 >>> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >>=20 >> I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >>=20 >>>=20 >>> What we lose by this approach is that one cannot use mandatory = options anymore. I.e. options that MUST be processed by every router = along the packet's path. RFC2675 for example is a mechanism depending on = that. In our view this is not a problem, since routers with links with = MTU larger than 64K would have to be configured and would be within a = controlled domain anyhow. >>=20 >> Yes, I also don=E2=80=99t see that as a problem. It=E2=80=99s anyway = always hard to ensure that something is process by every hop. Not sure = that would have been achievable in reality every. >>=20 >>>=20 >>>>=20 >>>> This related to this comment from Martin's review, also proposing a >>>> potential way forward: >>>> "- Section 4.8. "Defining New Extension Headers and Options": >>>> It says new hop-by-hop headers must never ever defined. This is >>>> problematic, as this closing the door forever, even if future = instances >>>> of the IETF do would like to wish to define new hop-by-hop headers. = A >>>> better way would have to say "that new hop-by-hop headers must have = IETF >>>> consensus". >>>=20 >>> Yes, the door for a new HBH option header container is closed. >>> Given that this is the signal that every router has to check. >>> Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. >>>=20 >>>> - Section 4.8. "Defining New Extension Headers and Options": >>>> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >>>> especially with the phrase "There has to be a very clear = justification". >>>> The term "clear justification" is not an exact engineering = specification. >>>> Why not using "technical protocol specification and real word use = case >>>> required, plus IETF consensus"?" >>>=20 >>> Defining new IPv6 extension headers is not recommended. There has = to >>> be a very clear justification why any new extension header is needed >>> before it is standardized. >>>=20 >>> The text does state "standardized" though. >>>=20 >>> Just to remind you that the Destination options header, the HBH = options header and the Routing header are all container options, which = allows for arbitrary number of TLVs inside. Since extension headers = share the numbering space with upper layer protocols, defining new ones = would require all implementations parsing header chains (e.g. to do = packet filtering on transport headers) would have to be updated. This is = the reason for the strict restriction on adding new ones. >>=20 >> See my response to Mike=E2=80=99s reply to Martin=E2=80=99s review: I = think what you better should say is that it is recommended to use a = destination option, if suitable, rather than a new header. I don=E2=80=99t= think you need to anything else than this about new headers. >=20 > As it says in Section 4.8: >=20 > Defining new IPv6 extension headers is not recommended. There has = to > be a very clear justification why any new extension header is needed > before it is standardized. Instead of defining new Extension > Headers, it is recommended that the Destination Options header is > used to carry optional information that must be examined only by a > packet's destination node(s), because they provide better handling > and backward compatibility. >=20 Yes, this text is the text I have problem with. I think I would suggest = to drop the first part and only have this part: "It is recommended to rather use the Destination Options header=20 to carry optional information that must be examined only by a packet's destination node(s), instead of defining new Extension Headers, because they provide better handling and backward compatibility." >=20 >>=20 >>>=20 >>>>=20 >>>> As a side note, there is at least one experimental RFC that defines = a >>>> destination option to be inspected by a network device, given the = know >>>> problems of hop-by-hop option which renders them unusable. >>>=20 >>> Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. >>=20 >> It=E2=80=99s very costly but unfortunately currently the only way to = achieve that at all. Given that this experimental option is intended to = be inspected by only a few nodes on the path (not all) and usually these = nodes are close the edge, it=E2=80=99s probably still doable. >=20 >>=20 >>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> One question because I'm not sure if I interpret this correct to = make it >>>> part of my discuss: >>>> Section 4.5: "The number and content of the headers preceding the >>>> Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained in >>>> the reassembled packet." >>>> Does this mean the ECN codepoint (part of the Traffic Class field) = is >>>> copied from the first fragment? This doesn't seem to be correct, = however, >>>> also not sure what the correct answer is. I know this was not = changed in >>>> this revision but maybe we can still get this right. >>>=20 >>> When fragments are created most of the fields are copied from the = IPv6 headers (e.g., Source Address, Destination address, flow label, = traffic class, hop limit). Some like payload length, next header, and = hop limit are modified. >>>=20 >>> If I understand your question, the answer is yes, the ECN code point = is copied from the first fragment, but should be the same from all of = the fragments. >>=20 >> My concern is that the ECN code point could be changed on one of the = fragmented packets to signal congestion of a intermediate node and then = when you reassemble this information gets lost. That seems wrong. >=20 > That is an interesting idea, but I think out of scope for advancing = this document to Internet Standard. Then there is the question of how = to encode n of m fragments experienced congestion. Interesting future = work. Yes there might be some more further work needed but that still makes = the guidance in this text wrong. Maybe we can add some text that the = Traffic Class may be handled differently because it could be changed on = the path. Mirja >=20 > Thanks, > Bob >=20 >=20 From nobody Thu Apr 13 04:53:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28905131533 for ; Thu, 13 Apr 2017 04:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 sVgSoRzJkPIX for ; Thu, 13 Apr 2017 04:53:40 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950B4131520 for ; Thu, 13 Apr 2017 04:53:40 -0700 (PDT) X-AuditID: 60721c4b-c6bff70000000e40-5a-58ef66c3b07d Received: from VAADCEX47.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 36.04.03648.3C66FE85; Thu, 13 Apr 2017 07:53:39 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX47.cable.comcast.com (147.191.103.224) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 13 Apr 2017 07:52:20 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Thu, 13 Apr 2017 07:52:20 -0400 From: "Leddy, John" To: Brian E Carpenter , "ipv6@ietf.org" Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Thread-Topic: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Thread-Index: AQHSs6u9Y8ciS/x/aUKn/8KdY1N6M6HCruUAgACC74A= Date: Thu, 13 Apr 2017 11:52:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: text/plain; charset="utf-8" Content-ID: <136EA8AC4063504487115F50881A3B13@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsWSUOxpoXs47X2EwdtmTYu2i/uYLF6efc/k wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU8XTeXsaCDp2LLn0UsDYwPuLsYOTkkBEwk znU2s3UxcnEICWxnknj28zQ7hHOIUWJvXy8LhHOSUWL7qw/sIC1sAjoSM6ZdYwWxRQTCJJYd fgUU5+AQFnCTaHmtChF2lzgzbTsLhG0lcaJ/DhuIzSKgKtF8vgeslVfARWLi9K2MEPN3M0p8 fTANbD6ngK3Eha2fmEFsRgExie+n1jCB2MwC4hK3nsxngjhbQGLJnvPMELaoxMvH/8CGigro Sczc+ZcRIq4jcfb6EyjbQGLr0n0sIHdKCMhLfJzLBGIyC2hKrN+lDzHdQWL9rR9sELaixJTu h+wQZwpKnJz5hAViirjE4SM7WCcwSs1CctAshEmzkEyahWTSLCSTFjCyrmKUK0tMTEnOzcgv LTEw1EtOTMpJ1UvOz01OLC4B0ZsYQXFcJOO9g3HdT/dDjAIcjEo8vBfi30cIsSaWFVfmAiOH g1lJhHd9KlCINyWxsiq1KD++qDQntfgQozQHi5I4r+fNWxFCAumJJanZqakFqUUwWSYOTqkG xnl3jpcuTk7PeddalvloQfDffxfiDoQUMRsX2ikdS5+yqadk2h9z+T27Xq04J9awhK1JRj8m t7Dr39feRCPRN/m6KUmfeK1Y359XCby9zD5X1+rA/6OPA146/FjIo9EYmv7KP+DHLUbZKsEd rX+efMkR0lML3V99c/Zp4/2+9ZvE8p8vqis+qcRSnJFoqMVcVJwIAHOKegXfAgAA Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:53:42 -0000 QXMgbW9yZSBvZiB0aGUgc2VydmljZSBkZWxpdmVyeSBwYXRoIGluY2x1ZGVzIGNvbXBsZXggdmly dHVhbGl6ZWQgZW52aXJvbm1lbnRzIHdpdGggcHJvZ3JhbW1hYmxlIGRhdGEgcGxhbmVzIGFuZCBn ZW5lcmFsIHNvZnR3YXJlIGJhc2VkIElQVjYgZm9yd2FyZGluZywgdGhlIGNvc3QvYmVuZWZpdCB0 cmFkZW9mZnMgZm9yIGltcGxlbWVudGluZyBFSCBwcm9jZXNzaW5nIGNoYW5nZXMg4oCTIGV2ZW4g SGJILg0KDQpJZiB0aGUgc3RhbmRhcmQgaXMgaGVhdmlseSBza2V3ZWQgdG93YXJkIG1vcmUgdHJh ZGl0aW9uYWwgVmVuZG9yIGJhc2VkIEFTSUMvTlBVIGZvcndhcmRpbmcgcHJlZmVyZW5jZXMgZm9y IHRoZWlyIGltcGxlbWVudGF0aW9ucywgaXQgZG9lcyBmdXR1cmUgSVBWNiBkZXZlbG9wbWVudCBh IGRpc3NlcnZpY2UuDQoNCkVuYWJsaW5nIHNvbWUgb2YgdGhlc2UgRUggZmVhdHVyZXMgdG8gYmUg Y29uZmlndXJhYmxlIG1ha2VzIHNlbnNlIHNvIGN1cnJlbnQgY29uc3RyYWluZWQgcm91dGVycyB3 b27igJl0IGJlIG5vbi1jb21wbGlhbnQgd2l0aCAyNDYwYmlzIGFuZCB0aGVyZWZvcmUg4oCcbWlk ZGxlIGJveGVz4oCdIHRoZW1zZWx2ZXMsIHdpdGhvdXQgYmFubmluZy9kZXByZWNhdGluZy93aXRo aG9sZGluZyBhbmQgZ2VuZXJhbGx5IHNodXR0aW5nIGRvd24gZnV0dXJlIHdvcmsgaW4gdGhpcyBh cmVhLg0KDQoNCj4+IENhbiB5b3UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIGFueXRoaW5nIHRoYXQg Y2FuIGJlIGRvbmUgd2l0aCBhDQogICAgPj4gbmV3IGhvcC1ieS1ob3AgZXh0ZW5zaW9uIGhlYWRl ciB0aGF0IGNhbm5vdCBhbHNvIGJlIGRvbmUgd2l0aA0KICAgID4+IGEgbmV3IGhvcC1ieS1ob3Ag b3B0aW9uPw0KICAgID4gDQogICAgPiBHaXZlbiB0aGUgY3VycmVudCBob3AtYnktaG9wIGhlYWRl ciBpcyBwYXJ0aWFsbHkgbm90IHVzYWJsZSwgZXZlcnl0aGluZ+KApg0KICAgIA0KICAgIEJ1dCB0 aGUgcmVhc29uIGl0J3Mgbm90IGZ1bGx5IHN1cHBvcnRlZCBpcyBpbnRyaW5zaWMgdG8gdGhlIHdv cmRzICJob3AgYnkgaG9wIi4NCiAgICBSb3V0ZXIgZGVzaWduZXJzIGRvbid0IHdhbnQgdG8gc3Bl bmQgY3ljbGVzIHRoaXMgd2F5LCB0aGF0J3MgYWxsLg0KICAgICANCiANCg0K From nobody Thu Apr 13 04:58:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D551E120727 for ; Thu, 13 Apr 2017 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 G3yFx11Pt3nC for ; Thu, 13 Apr 2017 04:57:57 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AEF126B7F for ; Thu, 13 Apr 2017 04:57:56 -0700 (PDT) Received: (qmail 17862 invoked from network); 13 Apr 2017 13:31:13 +0200 Received: from p5dec220c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.12) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Apr 2017 13:31:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <05482791-E24E-4C4F-AE39-D111C005AB0B@employees.org> Date: Thu, 13 Apr 2017 13:31:12 +0200 Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0ECE510B-8E38-45DF-945D-F2938E002E9C@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <05482791-E24E-4C4F-AE39-D111C005AB0B@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:57:59 -0000 > Am 13.04.2017 um 11:40 schrieb otroan@employees.org: >=20 > Hi Mirja, >=20 >>> The Hop-by-Hop header (HBH) is a container option. It has the = protocol value 0, and has to be first in the header chain, so to make it = efficient for routers to check for it's presence. >>=20 >> Sorry, I meant hop-by-hop option in this case. >=20 > Ack, and you can define new hop by hop options, as long as you are = aware that with the new behaviour only nodes configured to process them = will. And it is in general though to make expectations of these options = being processed across administrative boundaries. The draft says: "New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behaviour.=E2=80=9C Now I as a designer am aware that there are problems with HBH option and = it might put my traffic on the slow path. I decide that I can=E2=80=99t = risk that because that would downgrade the QoS and make my service = unusable and I can=E2=80=99t even risk that because I would immediately = lose costumers. However, I would like to signal something to = midddleboxes that support this new fancy QoS mechanism that makes my = service better. What should I do? >=20 >>> RFC2460 has: >>> The Hop-by-Hop Options header is used to carry optional information >>> that must be examined by every node along a packet's delivery path. >>>=20 >>> The problem with this was that implementations ended up punting = packets with the HBH to software, essentially opening up for a DOS = attack, which again led operators to filtering out packets with the HBH = =3D=3D 0. >>> (While at the same time there were no HBH options with cross = Internet significance). >>>=20 >>> How the HBH option could be saved has been discussed for quite some = time in the 6MAN working group. >>> Including a draft: = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 >>> Which conclusion got included into 2460bis. >>>=20 >>> The working group thought it premature to deprecate the HBH option = header. >>> As a way to "rescue" the HBH option we have made one significant = change: >>>=20 >>> NOTE: While [RFC2460] required that all nodes must examine and >>> process the Hop-by-Hop Options header, it is now expected that nodes >>> along a packet's delivery path only examine and process the Hop-by- >>> Hop Options header if explicitly configured to do so. >>>=20 >>> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >>=20 >> I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >=20 > It has a somewhat higher drop probability but it is not unusable. Congestion control reacts to drop, thus you=E2=80=99ll get a very low = throughput. Yes you still have connectivity, but I would call this = unusable. > When implementations are updated with the new behaviour then the hope = is that it will become more usable. Yes, but that will take a very long time and I can never be sure that I = might not hit an old box somewhere on the path. >=20 >>> What we lose by this approach is that one cannot use mandatory = options anymore. I.e. options that MUST be processed by every router = along the packet's path. RFC2675 for example is a mechanism depending on = that. In our view this is not a problem, since routers with links with = MTU larger than 64K would have to be configured and would be within a = controlled domain anyhow. >>=20 >> Yes, I also don=E2=80=99t see that as a problem. It=E2=80=99s anyway = always hard to ensure that something is process by every hop. Not sure = that would have been achievable in reality every. >>=20 >=20 > Exactly. >=20 >>>> This related to this comment from Martin's review, also proposing a >>>> potential way forward: >>>> "- Section 4.8. "Defining New Extension Headers and Options": >>>> It says new hop-by-hop headers must never ever defined. This is >>>> problematic, as this closing the door forever, even if future = instances >>>> of the IETF do would like to wish to define new hop-by-hop headers. = A >>>> better way would have to say "that new hop-by-hop headers must have = IETF >>>> consensus". >>>=20 >>> Yes, the door for a new HBH option header container is closed. >>> Given that this is the signal that every router has to check. >>> Given that this is a container option one can put whatever one likes = into the existing HBH options header, so it would be hard to see the use = case for a new one. >>>=20 >>>> - Section 4.8. "Defining New Extension Headers and Options": >>>> Also the =E2=80=9Enot recommended=E2=80=9C to define new extension = headers looks strange, >>>> especially with the phrase "There has to be a very clear = justification". >>>> The term "clear justification" is not an exact engineering = specification. >>>> Why not using "technical protocol specification and real word use = case >>>> required, plus IETF consensus"?" >>>=20 >>> Defining new IPv6 extension headers is not recommended. There has = to >>> be a very clear justification why any new extension header is needed >>> before it is standardized. >>>=20 >>> The text does state "standardized" though. >>>=20 >>> Just to remind you that the Destination options header, the HBH = options header and the Routing header are all container options, which = allows for arbitrary number of TLVs inside. Since extension headers = share the numbering space with upper layer protocols, defining new ones = would require all implementations parsing header chains (e.g. to do = packet filtering on transport headers) would have to be updated. This is = the reason for the strict restriction on adding new ones. >>=20 >> See my response to Mike=E2=80=99s reply to Martin=E2=80=99s review: I = think what you better should say is that it is recommended to use a = destination option, if suitable, rather than a new header. I don=E2=80=99t= think you need to anything else than this about new headers. >=20 > A destination option would be the wrong thing to use. That violates = the premise for how this option is used. > If you only want a certain set of nodes along a path to process the = header, that is the behaviour you will now get with HBH. > An alternative is to use source routing with the routing header = combined with a destination options header. >=20 > Just using the destination header for this is inefficient and is = really a "give up" choice, where you end up requiring all routers to go = and hunt for "interesting" options. I know but it WAS done because it was the only usable approach, see = https://datatracker.ietf.org/doc/rfc7837/ Source routing is not an option here because the sender is not aware of = the box on the path. >=20 >>>>=20 >>>> As a side note, there is at least one experimental RFC that defines = a >>>> destination option to be inspected by a network device, given the = know >>>> problems of hop-by-hop option which renders them unusable. >>>=20 >>> Right, that's a much more costly way of doing it, given that routers = would now have to go and hunt for the particular sub option. This also = violates RFC2460. And this would obviously neither achieve hop by hop = behaviour. >>=20 >> It=E2=80=99s very costly but unfortunately currently the only way to = achieve that at all. Given that this experimental option is intended to = be inspected by only a few nodes on the path (not all) and usually these = nodes are close the edge, it=E2=80=99s probably still doable. >=20 > HBH or RH also lets you do that. Note that destination options also = has a higher drop probability than packets with extension headers. I aware of this but it=E2=80=99s still better than HBH. >=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> One question because I'm not sure if I interpret this correct to = make it >>>> part of my discuss: >>>> Section 4.5: "The number and content of the headers preceding the >>>> Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained in >>>> the reassembled packet." >>>> Does this mean the ECN codepoint (part of the Traffic Class field) = is >>>> copied from the first fragment? This doesn't seem to be correct, = however, >>>> also not sure what the correct answer is. I know this was not = changed in >>>> this revision but maybe we can still get this right. >>>=20 >>> When fragments are created most of the fields are copied from the = IPv6 headers (e.g., Source Address, Destination address, flow label, = traffic class, hop limit). Some like payload length, next header, and = hop limit are modified. >>>=20 >>> If I understand your question, the answer is yes, the ECN code point = is copied from the first fragment, but should be the same from all of = the fragments. >>=20 >> My concern is that the ECN code point could be changed on one of the = fragmented packets to signal congestion of a intermediate node and then = when you reassemble this information gets lost. That seems wrong. >=20 > I do see your point. Is this behaviour described somewhere else? There is an RFC on ECN for tunneling https://tools.ietf.org/html/rfc6040 I don=E2=80=99t think there is anything on fragmentation specifically. >=20 > Best regards, > Ole From nobody Thu Apr 13 06:28:43 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD093129496; Thu, 13 Apr 2017 06:28:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Kathleen Moriarty's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149209011176.15808.8461362192419736357.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 06:28:31 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 13:28:32 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would also like to see an updated security considerations section specific to IPv6 and have the opportunity to review that prior to publication of this draft. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the SecDir reviewer that the text should not be limited to privacy. s/exposure of private information/exposure of confidential information/ From nobody Thu Apr 13 08:06:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6648F129446 for ; Thu, 13 Apr 2017 08:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Tvpbrt3no_z3 for ; Thu, 13 Apr 2017 08:06:09 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id CE3001289B0 for ; Thu, 13 Apr 2017 08:06:09 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 13 Apr 2017 15:06:09 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5C716D788B; Thu, 13 Apr 2017 08:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=GQes+y5HrRKHp1YwzvUg1Oy4Eck=; b= qhMwIVkhyHnlpsf0sj0dot6UP49C4UFlG6n4rhVP5zv6bZ/IwUHLDM9GZr/ZtI6k WxFj94wNWldvpUMgV4J6cgbY+66jqU3oBcbm3E6KEHX9pZk7XLdDdkDatH37DAX+ N+3zymSQ7KGn8A+KRwLbZ/4ZRJ9ohGrOxB/j96lKdKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=sAOVRLzJNS7qW6VxzqR562I QADd1B1Jn1BBOskc/409fq3C8o6ZvHAfQddVX+Je89Z7i4oj71APsoVZcZfZ6Jgn OtSq2VbZUM3PLq6B50EuOaCWNUQJro8+aDDOjIv/GPaPh+nbsdMhGnmys9bc0igJ a91X5+//zYk6582VGKLE= Received: from h.hanazo.no (77.18.51.71.tmi.telenormobil.no [77.18.51.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 24CD9D7890; Thu, 13 Apr 2017 08:06:09 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7335FA9B1E3F; Thu, 13 Apr 2017 17:06:06 +0200 (CEST) From: otroan@employees.org Message-Id: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_50F693A5-C3D8-465D-98DB-92291504AEF3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Date: Thu, 13 Apr 2017 17:06:05 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man WG To: "Leddy, John" References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 15:06:12 -0000 --Apple-Mail=_50F693A5-C3D8-465D-98DB-92291504AEF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > As more of the service delivery path includes complex virtualized = environments with programmable data planes and general software based = IPV6 forwarding, the cost/benefit tradeoffs for implementing EH = processing changes =E2=80=93 even HbH. >=20 > If the standard is heavily skewed toward more traditional Vendor based = ASIC/NPU forwarding preferences for their implementations, it does = future IPV6 development a disservice. >=20 > Enabling some of these EH features to be configurable makes sense so = current constrained routers won=E2=80=99t be non-compliant with 2460bis = and therefore =E2=80=9Cmiddle boxes=E2=80=9D themselves, without = banning/deprecating/withholding and generally shutting down future work = in this area. Indeed, and if there was an actual real use for a particular hop by hop = option that would obviously be implemented and supported. today we don't see much use of it, which is also one reason why it is = filtered / not well supported. So I would certainly be supportive of new and useful uses of the hop by = hop header. And much more so than workarounds like requiring routers to = parse deep into packets. Workarounds which are likely to just trigger = the weapons race. Btw, even for high performance software routers there is a cost to parse = deeply into the packet. The memory subsystem is bottleneck, and while = processing packet #1 and #2 we prefetch cachelines for packet #3 and #4. = If it turns out that when processing packet #1 we need to fetch one or = more cache lines we have already lost. Cheers, Ole --Apple-Mail=_50F693A5-C3D8-465D-98DB-92291504AEF3 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY75PeAAoJEL7aWKiYQt92B9UQAJVazxblUYKvQu9yxu77I2Wq Y+S/NhHpmx4VOc0CBynoRtvKjgTwOllr2W+FUulpfsTLCZDh6j3XAM1LGdWXW6db bm6n7yzjVbvxUKupuFUyWTdR8kaVTznvSF0lf4W1Jvopr7+RXS1JdEAzUUfEdEGo MsKzJIhUG4Kw1kQdBvRgaX9hQDphhR+SMCxtRmCuHObJ05QRluSR32z0GbJrJuEo hrEHeIcAULh5kmBXR0B6zPJb9Lm1YGOsTPqQb5Mt4oIhy6SIoYu5KPphscqxgm3F RA6okPSk/L2aOa4wDXmzNlC/BARpC6oausEDCKrO1D02zvdJAvOf1QqhnU5iDyWz qvYSWa3o0X33hRgHbAkqszqvBplFDiHZl7jSHsycyL6bwx5tgO+VBiUZ130vLutf fvb9YSrGji70bi+6qkWmjeNxYsoKCb3+b0Q82c0+jfzLKzNjayGQBlxj5EFF8V4d ILcEfaAQpdDSYxnsfDTWz4tdZ6CF+Jze3XjYSTSUWmeeiYmnm+ylR8txuoh6kakd bJdXID6J1AFAES6nK1GXJu0HhLQZ/db9LcE2hZHzjYQfKO8zLO1qsFrhCQyna1kH +AJmJf9G1BJYnoetvgsiVPfsP3rYvJ8nNFRHroYyLMUUsDCsmA4yUYEzZz/226x2 c/e3ieTkXhhn1FwWJRd1 =ajNL -----END PGP SIGNATURE----- --Apple-Mail=_50F693A5-C3D8-465D-98DB-92291504AEF3-- From nobody Thu Apr 13 09:14:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1F1294DC for ; Thu, 13 Apr 2017 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ShgyNRRqe5eu for ; Thu, 13 Apr 2017 09:14:44 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 EBDB712922E for ; Thu, 13 Apr 2017 09:14:43 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id l7so84612923ioe.3 for ; Thu, 13 Apr 2017 09:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gsXTfswJBO1hMaJzKghJ3JgKCfjpZs4xL/IWqdd2Li4=; b=s8OPAqXVba9WVxrL3o6gCEL17TggDuUB/krPfdMHSuJC53JOyNSqSCVA7u6dbf4EHC SrWMD+48oPTZk+XqhHjf9hTjq/EATyS0tzK/Uv1a8X3lb2Ye16btIE4Oz6yOjerZvyYN 5ghvKIRzou1l7EVvMx8G1kkDAm2DpeA2YbVMu1rQ1oBerO12Dm9nIqYrgL08ExKIQvS7 F6/pg04ej3WfTpyTYftZAO4EDij6AdR2mdX5WYe7jvk1EVhVaVPockw1jXT0cdLIxE1k nCydSftw5rDgEhbEfhj3dPfabiUowIRLPg8A00Z1Ge25XA4pBimiS3ysOIdx9ptT0dwd tzoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gsXTfswJBO1hMaJzKghJ3JgKCfjpZs4xL/IWqdd2Li4=; b=BmXakNJ+QsZWW5waGYYI9nIY5NzrKUIcndX7YeDeiC7RRtwholDbnf9/JNAEOsRfgc sPssYYa9UjLvEMgwYWY6q7IDuYgLXnXqceTTcK4fneTFNEA9O9fclwgmrgMC6LN2WkAU c/pdmhT7cLU+B3EUK5V17guV9cF7MTNlHiA2Dfaao2fv+80dNtIYy2r7jdH6+N7saPJG KzH2Powd3rDA78OBJcr5yjOg6v5jMR0TPKu8ONDFdzDmm1JCV1FV9Me39AatdMDEW/eu VDJa3o4KNVZa5vdYVvqiRLOtb07eN4Vx/E7P+Ufj0WQH6VgLkUtQrftgBVDOvA2lK0xO DqQQ== X-Gm-Message-State: AN3rC/7tKwJ0q781h0PRQ5qQvOvgmaUbpYd9G6n+cqEo257dDgz+QRNs DX8GQPKvznu3eUR8OVJUDxS5lTiw1U0e X-Received: by 10.36.219.195 with SMTP id c186mr18577937itg.25.1492100083147; Thu, 13 Apr 2017 09:14:43 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.170.4 with HTTP; Thu, 13 Apr 2017 09:14:42 -0700 (PDT) Received: by 10.79.170.4 with HTTP; Thu, 13 Apr 2017 09:14:42 -0700 (PDT) In-Reply-To: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> References: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> From: Robert Raszuk Date: Thu, 13 Apr 2017 18:14:42 +0200 X-Google-Sender-Auth: jOxh60dKh0a4Y_wKptpENTqiToY Message-ID: Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: otroan@employees.org Cc: 6man WG , "Leddy, John" Content-Type: multipart/alternative; boundary=001a114f5cce6cf7a7054d0e9f23 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 16:14:46 -0000 --001a114f5cce6cf7a7054d0e9f23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, Let's observe that your claim is only partially correct. Talking to real hardware designers I came to know that it cost nothing to get into first 150-200 bytes of packet. Yes aftee that you face cliff effect. But are we really that concerned about headers beyond that ? Cheers, R. On Apr 13, 2017 5:06 PM, wrote: > > As more of the service delivery path includes complex virtualized > environments with programmable data planes and general software based IPV= 6 > forwarding, the cost/benefit tradeoffs for implementing EH processing > changes =E2=80=93 even HbH. > > > > If the standard is heavily skewed toward more traditional Vendor based > ASIC/NPU forwarding preferences for their implementations, it does future > IPV6 development a disservice. > > > > Enabling some of these EH features to be configurable makes sense so > current constrained routers won=E2=80=99t be non-compliant with 2460bis a= nd > therefore =E2=80=9Cmiddle boxes=E2=80=9D themselves, without banning/depr= ecating/withholding > and generally shutting down future work in this area. > > Indeed, and if there was an actual real use for a particular hop by hop > option that would obviously be implemented and supported. > today we don't see much use of it, which is also one reason why it is > filtered / not well supported. > > So I would certainly be supportive of new and useful uses of the hop by > hop header. And much more so than workarounds like requiring routers to > parse deep into packets. Workarounds which are likely to just trigger the > weapons race. > > Btw, even for high performance software routers there is a cost to parse > deeply into the packet. The memory subsystem is bottleneck, and while > processing packet #1 and #2 we prefetch cachelines for packet #3 and #4. = If > it turns out that when processing packet #1 we need to fetch one or more > cache lines we have already lost. > > Cheers, > Ole > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a114f5cce6cf7a7054d0e9f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ole,

Let&= #39;s observe that your claim is only partially correct.

Talking to real hardware designers I came = to know that it cost nothing to get into first 150-200 bytes of packet.

Yes aftee that you face cli= ff effect.=C2=A0

But are= we really that concerned about headers beyond that ?

Cheers,
R.
=

On Apr 13, 2017 5= :06 PM, <otroan@employees.org> wrote:
> A= s more of the service delivery path includes complex virtualized environmen= ts with programmable data planes and general software based IPV6 forwarding= , the cost/benefit tradeoffs for implementing EH processing changes =E2=80= =93 even HbH.
>
> If the standard is heavily skewed toward more traditional Vendor based= ASIC/NPU forwarding preferences for their implementations, it does future = IPV6 development a disservice.
>
> Enabling some of these EH features to be configurable makes sense so c= urrent constrained routers won=E2=80=99t be non-compliant with 2460bis and = therefore =E2=80=9Cmiddle boxes=E2=80=9D themselves, without banning/deprec= ating/withholding and generally shutting down future work in this area= .

Indeed, and if there was an actual real use for a particular hop by hop opt= ion that would obviously be implemented and supported.
today we don't see much use of it, which is also one reason why it is f= iltered / not well supported.

So I would certainly be supportive of new and useful uses of the hop by hop= header. And much more so than workarounds like requiring routers to parse = deep into packets. Workarounds which are likely to just trigger the weapons= race.

Btw, even for high performance software routers there is a cost to parse de= eply into the packet. The memory subsystem is bottleneck, and while process= ing packet #1 and #2 we prefetch cachelines for packet #3 and #4. If it tur= ns out that when processing packet #1 we need to fetch one or more cache li= nes we have already lost.

Cheers,
Ole


-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

--001a114f5cce6cf7a7054d0e9f23-- From nobody Thu Apr 13 18:50:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F4127097; Thu, 13 Apr 2017 18:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 ttcxJlZ1xOUx; Thu, 13 Apr 2017 18:50:07 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 4303F127076; Thu, 13 Apr 2017 18:50:07 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 63so1292340pgh.0; Thu, 13 Apr 2017 18:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=twUdWpoVPBafS+gk+tvmW6KdXdiHenvvNv7deKRMp4w=; b=Ji4xCHatYl97gzj7viPZU6RuAlEChAvkUAF9GnZqsZYA14/zIoviRfv+G4l+GXN9WA usIFzPgtfzQ4sSRaH9EGCKkMr2C5rdLQZRDINjkiwvCy99bGdyKSbiREErersguHO7Qz tj9LPDxzwJ+j6bmddp2/ZVuBkJgPTv09i9l27pHguiXCFpEetO/46KT8PB07QWDJ+lJy mVv6RXIsnfzT1TRyOO9Hx7qiDuciT5nNua73Msz0cozM7vxnb7LgWrkfWVaLZ2JoIh/c 4bNNfYHXZLqkkyMjmJy1lV1UN2Jw9rkuxT0h6JC9V3tWQvqYyTaY5arCgBRbniSgOhmi yq8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=twUdWpoVPBafS+gk+tvmW6KdXdiHenvvNv7deKRMp4w=; b=meCG0eEcGWAUoUwkJtLgzsnaLy6MYxFtRGmDEKzIQyI+h5HzqWxxX+PmSnRl2F0a2b H6sfsaTbDg2ScwBR9KJ9yoAZMb02PhMq16BbgWEPJxFXv6RLS4WwHVfYBDmxpRokhnn9 BjRKcT1bSFbjTj7IMYHJ0RavEl/9qt2ydDKtpq8dYIK15MmjLVMW7CinD21BVgmtq8+n Wdpbtpj9t8pJlQOaZ0sGe+iixphuHPBofBM3LHG5jGMrxhERH5B7O8xOqzxcgq82u650 XrCEQPGhIWY17s/2DawlLlyyiNZWByA/fU3EvxxAbCzscumjnQgn4au/5pt95v9k6rMY Yg4Q== X-Gm-Message-State: AN3rC/5ut+GE/2PMPfMrsDMhMxKPRmA9c5gDYRIJQPjwKGnA+zFqRxop R31+2gYn20Q8Eg== X-Received: by 10.98.97.7 with SMTP id v7mr4514879pfb.161.1492134606843; Thu, 13 Apr 2017 18:50:06 -0700 (PDT) Received: from [192.168.178.26] ([118.149.101.64]) by smtp.gmail.com with ESMTPSA id e67sm408522pfe.64.2017.04.13.18.50.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 18:50:06 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" , Bob Hinden References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Cc: draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <0e715656-4bf3-a406-2eb4-7ebda40f9430@gmail.com> Date: Fri, 14 Apr 2017 13:50:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:50:09 -0000 On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: ... >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> One question because I'm not sure if I interpret this correct to make it >>>>> part of my discuss: >>>>> Section 4.5: "The number and content of the headers preceding the >>>>> Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained in >>>>> the reassembled packet." >>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is >>>>> copied from the first fragment? This doesn't seem to be correct, however, >>>>> also not sure what the correct answer is. I know this was not changed in >>>>> this revision but maybe we can still get this right. >>>> >>>> When fragments are created most of the fields are copied from the IPv6 headers (e.g., Source Address, Destination address, flow label, traffic class, hop limit). Some like payload length, next header, and hop limit are modified. >>>> >>>> If I understand your question, the answer is yes, the ECN code point is copied from the first fragment, but should be the same from all of the fragments. >>> >>> My concern is that the ECN code point could be changed on one of the fragmented packets to signal congestion of a intermediate node and then when you reassemble this information gets lost. That seems wrong. >> >> That is an interesting idea, but I think out of scope for advancing this document to Internet Standard. Then there is the question of how to encode n of m fragments experienced congestion. Interesting future work. > > Yes there might be some more further work needed but that still makes the guidance in this text wrong. Maybe we can add some text that the Traffic Class may be handled differently because it could be changed on the path. Good point. It's not only ECN that can change; the DSCP can change too. Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical for 2460bis to note this issue. Brian From nobody Thu Apr 13 19:12:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4749126BF7; Thu, 13 Apr 2017 19:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 B8CDTjqcbD3I; Thu, 13 Apr 2017 19:12:13 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 3C1161200C5; Thu, 13 Apr 2017 19:12:11 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id o123so14437316pga.1; Thu, 13 Apr 2017 19:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nMzDCElPzaSrth5LqIbJJjZBDTdJmuC1mkr4yAPFbMA=; b=vYsfDWoe46xZHJ+PkImD1bDepZvGtLYuP4E5CVCcwkD7VtXWtMq8RDjp6R9A/bIKLn WMkOTKDb19KL88+JP4OjqB84duQV81mMfAajP7KPJ0grozRsNXaR97v2TYX5/fvTDOY3 xL60BwFYGGHt6m77PvdUKpcCouoYqU4/t/7PUF77RU723roH3X8J0T6WN8jyHlNSiTDL 1EEj0T46t2TdJSZE6W87V028q36E44yHA2aMPt+uGv72s3wlofOZtV88MSAOYNf8Wcpl qkO9uYxpEPaRctX7foqLx/fppyos49WTgDLTlLtAIJeu0CalMQ/VAOXQ6XGByV/SH2pb 9OFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nMzDCElPzaSrth5LqIbJJjZBDTdJmuC1mkr4yAPFbMA=; b=fJWHyp6rie1dz0PP89k+rg4aE2l1JWMlu59nYdkaZIFpfcQ3kPS9ijW7wqgXCwZALz NDII4gs5h7yj4GerND/cwS9jY6KSw+Z3/POuG5pNKTzoSEka3MYKzxu3t4ev1RA/+RAA LP9aw68asKKASaoN9EyWJOhIPHRCqyyqfuMpFkqze3fQ62Nyb9pQXSup/wf9W2km1UC9 xlsW6Zov5z78950fK/MlyDKxwioaqOstumWvpQI9+i3Ne8ufz42pN5OYfv6JXrBH6HeV IJrj+J7sZeBwBE7TFAHfCTkQhWPdjloyGWFONgKLC7/+W59Xj6dFSv//F6eDLnwSMm2g ZJgw== X-Gm-Message-State: AN3rC/52ZVTfxDw6Cd1aFHfcQQXxDKUS2Ol/JBy9VKILrImzXn3AdUgV nfeAL4MUtASnAg== X-Received: by 10.84.128.4 with SMTP id 4mr6089855pla.37.1492135930838; Thu, 13 Apr 2017 19:12:10 -0700 (PDT) Received: from [192.168.178.26] ([118.149.101.64]) by smtp.gmail.com with ESMTPSA id h14sm437083pgn.64.2017.04.13.19.12.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 19:12:09 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> Cc: otroan@employees.org, draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Apr 2017 14:12:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:12:16 -0000 Still jet lagged but let me try: On 13/04/2017 23:19, Mirja Kuehlewind (IETF) wrote: > Hi again, >=20 >=20 >> Am 13.04.2017 um 03:45 schrieb Brian E Carpenter : >> >> On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote: >> ... >>>> NOTE: While [RFC2460] required that all nodes must examine and >>>> process the Hop-by-Hop Options header, it is now expected that nodes= >>>> along a packet's delivery path only examine and process the Hop-by- >>>> Hop Options header if explicitly configured to do so. >>>> >>>> Which means by default routers unless they have been configured to p= rocess a particular option contained in an HBH option, shall forward the = packet as normal. Thereby rectifying the attack vector. >>> >>> I=E2=80=99ve see this change and it=E2=80=99s a step in the right dir= ection but it doesn=E2=80=99t solve the problem given there are already d= eployment that still put packets with an hop-by-hop header on the slow pa= th which still renders the hop-by-hop header as currently defined unusabl= e. >> >> I think I'm repeating myself due to jet lag, but this problem IMHO has= *nothing* to do with >> the current definition of HbH. It's to do with the very nature of HbH = - something we are >> asking *every* router in the Internet to do. The core routers in trans= it providers will >> never do that. Redefining the HbH header cannot change that; it's intr= insic. >> >> The above quoted Note was a WG consensus choice to resolve this issue,= iirc, adapted >> from section 2.2 of RFC7045. >=20 > I might repeat myself as well but anyway. The above quoted text is fine= but it does not solve the problem we have in reality. If the behavior wo= uld have been defined the way it is defined now from the beginning that w= ould have been fine. However, there are router out there that put all pac= kets that have the HBH header in the slow path which makes the HBH header= unusable in practice. Redefining the behavior in the spec opens the door= to fix that problem but the deploy router will not go away quickly, leav= ing a risk that your packets go on the slow path. Just because there is t= his risk, I would not recommend to use any HBH option (as the document do= es). However, if HBH are not usable, how can I then achieve the desired b= ehavior (where some of the router on the path are allow to inspect and pr= ocess some information in the IP extension header)? I have no good answer. We got this wrong originally, so what can we do in= the Internet Standard except document the problem? (I suspect that the real answer is that to install any kind of flow state= , we need to use an explicit flow state creation protocol, not hang it of= f a packet header designed mainly for stateless processing. If that sound= s like a short explanation of why Integrated Services/RSVP failed, it is.= And it's surely out of scope for 2460bis.) Brian From nobody Thu Apr 13 19:28:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092531288B8; Thu, 13 Apr 2017 19:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 mEVbRgmhU4z2; Thu, 13 Apr 2017 19:28:44 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 4360B126C7B; Thu, 13 Apr 2017 19:28:44 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id o123so14479358pga.1; Thu, 13 Apr 2017 19:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Xuryny723PfaUUKJaD4ONNJKtXfnJHlQgCquEatupqY=; b=buUGpbFqG4vWYLviAn68ycxp38n674fZ2GBNmsdtfDWlJj38+4iqCX8CZPakRtYWhP NeRPBhojBcSrKfkd+mGVHn+HjjvbuFGUdogpGI1CbBSYBKLx3ZP9sWhvbWpeh/dgfG3L wR+gEhwObWn8oPWq9AG4cxQtwfxvOMihvr1rOdIJasJrYZwcIq4nRjx2WYdbEtToMt+C +2Anh0VYsHcHQtSQJnywOiLjJnZRfgYe/L4v4abWJQMr5QllZevyBkZJzYQtR4hPIoiQ /8/inWQaRPOiKlCm1RQPaSBa/gdPRP1r6/6C7mx950PpF4Np0ZRP0pRNvrWB8iavh98y fQUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Xuryny723PfaUUKJaD4ONNJKtXfnJHlQgCquEatupqY=; b=lUAiA7qhoIbqhhBsYiW1Y/k6cDRVQueUuQwkYPoSAF1op1cQvSD/Z9lcBgacv4JHQ6 lDomUL9QdFSEbjNyatL0yNcANxUMDl1c4Po2pDgcO3PUHMfBt+417GWosvjzTNaBDlPM WA01RZMinpUqSzqKDfhc/illHxgJL5W/04F4vXyguwcV58AdgmN5TmYwMvoDsxxg8PuL 1y0Z/lgGSat6KKg8RBcPa+uI0iSLdB80b2S6Ac8DhQYEHfettf710ZSNswuzVqw+0L0y xy0EYYyosGOvIMjk1uULCh/qCVSB518xWEwnNEM+gFzXqT51v+kH2Fe5ziznOo4qiYYJ w6PQ== X-Gm-Message-State: AN3rC/6sVTqbUWY1tj7wPb3PJoOu+xIwhUc/3ugGspVeTIhkD+D6zh4M O2vy9BIN6Pkz1A== X-Received: by 10.98.49.70 with SMTP id x67mr4625346pfx.177.1492136923873; Thu, 13 Apr 2017 19:28:43 -0700 (PDT) Received: from [192.168.178.26] ([118.149.101.64]) by smtp.gmail.com with ESMTPSA id p68sm476041pfp.104.2017.04.13.19.28.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 19:28:43 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" , Bob Hinden References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Cc: draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> Date: Fri, 14 Apr 2017 14:28:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:28:46 -0000 And one more comment for today: On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: ... >> As it says in Section 4.8: >> >> Defining new IPv6 extension headers is not recommended. There has to >> be a very clear justification why any new extension header is needed >> before it is standardized. Instead of defining new Extension >> Headers, it is recommended that the Destination Options header is >> used to carry optional information that must be examined only by a >> packet's destination node(s), because they provide better handling >> and backward compatibility. >> > Yes, this text is the text I have problem with. I think I would suggest to drop the first part and only have this part: > > "It is recommended to rather use the Destination Options header > to carry optional information that must be examined only by a > packet's destination node(s), instead of defining new Extension > Headers, because they provide better handling > and backward compatibility." "Defining new IPv6 extension headers is not recommended" is a rather mild statement. There were certainly some in the WG who wanted a MUST NOT here. It's an operational and security concern: existing middleboxes, especially firewalls, are allergic to extension headers that they don't understand. This is unfortunate, since the design model was that the forwarding path should be transparent to all headers, which meant that new headers could be deployed between consenting adults without any infrastructure issues. But this simply doesn't work in the real world - that's the main reason we wrote RFC7045. I think it's worth quoting this: This combination of circumstances creates a "Catch-22" situation [Heller] for the deployment of any newly standardised extension header except for local use. It cannot be widely deployed because existing middleboxes will drop it on many paths through the Internet. However, most middleboxes will not be updated to allow the new header to pass until it has been proved safe and useful on the open Internet, which is impossible until the middleboxes have been updated. So, defining new IPv6 extension headers is not recommended, because they probably won't work across the Internet. But it isn't a MUST NOT, because if there was a compelling operational case, we could do it and the middleboxes would follow. RFC 7045 was intended to nudge middlebox developers in the right direction, and similarly draft-ietf-opsec-ipv6-eh-filtering. But it's an uphill battle. Brian From nobody Thu Apr 13 20:22:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCA8126CD8 for ; Thu, 13 Apr 2017 20:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 RYBNKGb3Wvkq for ; Thu, 13 Apr 2017 20:22:42 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 512DC12426E for ; Thu, 13 Apr 2017 20:22:41 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id i5so36285788pfc.2 for ; Thu, 13 Apr 2017 20:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IzO9tgaid3yBwfgMwTac/QkdJ7M3LpM9g8fkdt0ey/8=; b=Ren+javYXu56KnNg7m5eio1Pkq27ONxS+IYx8cJg5/t4dDavSNh0GE5mr0LdB6tAmx 1c8gctRu05cvNBzUiUXMJnO0BMWlhilO7aZzpXR+FcfjKaiodvmKyweIE6+Y5Jt7zrKn EdoENbc2adEwI04r3LvKj3NPNhw7smMGfElUE/LE5Y3bNMal/19dp9N5D6odf/5lZ4ot XD48eKsjIb77AMldVVv1s30dwAlhcy9uVj52C2BGBmFZ6PDp2GEIYkaFaBKRkZeYZF33 LqJiPYYL6io32Asu+DFZJ5UXY/GaM+OofGmeX0h7ICnmeXBdlWm4qhFE+PRHrPSlL6py fv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IzO9tgaid3yBwfgMwTac/QkdJ7M3LpM9g8fkdt0ey/8=; b=aGQd0juej7ZyWBkQJLlYiym5U0+4uxgrRgTwtPrxcNlpWxgnHECMwD86ncWqfWs2+m K7AvkwDGM90w9Z0bdFFA3Tx92ycy2gW8gnLOmwlOs0e7v6Hv3VM3FtBSm0cbDzMCgTkL Rl1m4qT5N1fDMIkEhFtjQap2pYX3vbQLkJ1dz9IbhD5uDeGaJHD9tUlfG5QVNYwV6Bfv 3rVOLg65GIvWQdZHMluFQhUx062ndE2daN/819bFrFDpKd85wc45Qqx5FkX/UBF1PS6L fvdZ4tvt02z1WDLjdUYjj1+wywckyebqPkHwIfJ65BYOkAQwlL8JpeElQZbGoIm89IB/ t/PA== X-Gm-Message-State: AN3rC/7vZYBHzTtSR1lfqM+JovlO7wDKavVsxrfg0PE2Ih9avTbZ3nOG i8xx7TzA8kwKFQ== X-Received: by 10.84.233.203 with SMTP id m11mr6192646pln.177.1492140160952; Thu, 13 Apr 2017 20:22:40 -0700 (PDT) Received: from [192.168.178.26] ([118.148.72.29]) by smtp.gmail.com with ESMTPSA id n85sm603275pfi.101.2017.04.13.20.22.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 20:22:40 -0700 (PDT) Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 To: Robert Raszuk , otroan@employees.org References: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> Cc: "Leddy, John" , 6man WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 14 Apr 2017 15:22:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 03:22:44 -0000 On 14/04/2017 04:14, Robert Raszuk wrote: > Hi Ole, > > Let's observe that your claim is only partially correct. > > Talking to real hardware designers I came to know that it cost nothing to > get into first 150-200 bytes of packet. Good. That should make new HbH options viable, as long as we agree that processing HbH is optional, so that less capable routers can ignore it. Given that, the current HbH header format is OK, isn't it? Nobody is proposing to remove the possibility of defining new HbH options within the HbH header. > Yes aftee that you face cliff effect. > > But are we really that concerned about headers beyond that ? Quoting Steinar Haug a couple of years ago, we need >> [IPv6 Fixed Hdr] + [IPv6 EHs] + [L4 Hdr] <= hardware inspection limit >> >> in order for the router hardware to be able to filter based on TCP/UDP >> headers at line rate. So, the fixed header is 40 bytes and a TCP header is 20 bytes. If the hardware limit is 150 bytes as you suggest, that allows for 90 bytes of extension headers. If the limit is 128 bytes, as people claimed a couple of years ago, that would be 68 bytes of extension headers. For most extension headers, that seems like a lot. But routing headers could be quite long, and shim6 (hardly a success, but it is standardised) could be even longer in some circumstances. I did calculate two years ago that a packet with the following could exceed the 68 byte limit: Hop-by-Hop Options/Router Alert + Fragment + ESP + Destination Options/Tunnel Encapsulation Limit + SHIM6 Replace SHIM6 with a big Routing Header if you prefer. Also consider what you might want to do with encapsulated packets in a router that is also a firewall. So, falling off the cliff seems like a real possibility. Brian From nobody Fri Apr 14 04:54:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B412EB92 for ; Fri, 14 Apr 2017 04:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=swm.pp.se 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 O5u1EnSV_DZt for ; Fri, 14 Apr 2017 04:54:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A893912EB87 for ; Fri, 14 Apr 2017 04:54:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 097E4A2; Fri, 14 Apr 2017 13:56:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492170982; bh=AkKrfwDSpKURffbr1cXg9cTQXmF3OPargjQVeRThm/I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Lo1WHTYfsKRDB1Y3So8nQuKDv7k1P2LDtYqD/DsfRmCTqlxpv1ok2f+JwVze0ty72 yK8onTCUZid2XoRvbGzW4VckwlQ9Cy5RHGfxLgq2LXJaFlywWPY1qblR1DiImBKq91 C0PVwKsNvpboz6jcXDIcAQpF8os7MKFurT/Wcp1c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 04BB8A1; Fri, 14 Apr 2017 13:56:22 +0200 (CEST) Date: Fri, 14 Apr 2017 13:56:21 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: "ipv6@ietf.org" , james woodyatt , Dave Thaler Subject: Re: Route Information Options in IPv6 Neighbor Discovery In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 11:54:12 -0000 On Wed, 12 Apr 2017, Templin, Fred L wrote: > Please see below for an updated version of "Route Information Options > in IPv6 Neighbor Discovery". Note that the title is changed since the last > version because we are now allowing RIOs to appear in other IPv6 ND > messages besides just Redirects. In particular, we are now allowing RIOs to > also appear in Neighbor Solicitation (NS) and Advertisement (NA) messages. > > The rationale for leveraging NS/NA instead of RS/RA is given in Section 4.2.6. > The rest of document was updated to address the helpful input received > from colleagues at IETF98. Please review and post comments to the list > and/or the authors. SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would be in scope for this documents security section. For instance, what would an SAVI enabled L2 switch that inspects ND entries do when it sees this RIO entry in ND? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Apr 14 08:23:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD981294A0 for ; Fri, 14 Apr 2017 08:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LvEFMjDlS42k for ; Fri, 14 Apr 2017 08:23:35 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9C4128768 for ; Fri, 14 Apr 2017 08:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EFNYk0011034; Fri, 14 Apr 2017 08:23:34 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EFNVTQ011015 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 08:23:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 08:23:30 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 08:23:30 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: "ipv6@ietf.org" , james woodyatt , "Dave Thaler" , Lorenzo Colitti , "Jen Linkova" , David Schinazi Subject: RE: Route Information Options in IPv6 Neighbor Discovery Thread-Topic: Route Information Options in IPv6 Neighbor Discovery Thread-Index: AdKz02OPoeaHB7mXSI2gKFT6CIowLQBfWq6AAAerc0A= Date: Fri, 14 Apr 2017 15:23:30 +0000 Message-ID: <2fa25981cbc141598852feb0b67a4f77@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:23:38 -0000 Hi Mikael, > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Friday, April 14, 2017 4:56 AM > To: Templin, Fred L > Cc: ipv6@ietf.org; james woodyatt ; Dave Thaler > Subject: Re: Route Information Options in IPv6 Neighbor Discovery >=20 > On Wed, 12 Apr 2017, Templin, Fred L wrote: >=20 > > Please see below for an updated version of "Route Information Options > > in IPv6 Neighbor Discovery". Note that the title is changed since the l= ast > > version because we are now allowing RIOs to appear in other IPv6 ND > > messages besides just Redirects. In particular, we are now allowing RIO= s to > > also appear in Neighbor Solicitation (NS) and Advertisement (NA) messag= es. > > > > The rationale for leveraging NS/NA instead of RS/RA is given in Section= 4.2.6. > > The rest of document was updated to address the helpful input received > > from colleagues at IETF98. Please review and post comments to the list > > and/or the authors. >=20 > SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would > be in scope for this documents security section. Can you send a pointer to the document? > For instance, what would > an SAVI enabled L2 switch that inspects ND entries do when it sees this > RIO entry in ND? I would have to look, but if the document says that the switch should throw away ND messages with options other than those specified in RFC4861 that sort of defeats the extensibility of IPv6 ND in general, doesn't it? Thanks - Fred fred.l.templin@boeing.com > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Apr 14 08:28:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9F130154 for ; Fri, 14 Apr 2017 08:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 Mnm2xr9yPkW2 for ; Fri, 14 Apr 2017 08:28:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7149A128768 for <6man@ietf.org>; Fri, 14 Apr 2017 08:28:45 -0700 (PDT) Received: from [192.168.0.228] (176-35-156-161.xdsl.murphx.net [176.35.156.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5EEE681D90; Fri, 14 Apr 2017 17:28:43 +0200 (CEST) To: "6man@ietf.org" <6man@ietf.org> Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" From: Fernando Gont Subject: Deprecation of IPv6 atomic fragments (some good news) X-Enigmail-Draft-Status: N1110 Message-ID: <626c7e05-c3b5-2463-6547-96d875196697@gont.com.ar> Date: Fri, 14 Apr 2017 16:28:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:28:48 -0000 Folks, Thought it might be good feedback for the group. Juniper published a vulnerability advisory with patches for the issue discussed in RFC8021: Besides providing the rationale for the change in rfc2460bis and RFC7915, this kind of thing was one of the motivations for working on such RFC. Thanks! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Apr 14 08:40:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B34112ECA8 for ; Fri, 14 Apr 2017 08:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kHNbxuedNc1j for ; Fri, 14 Apr 2017 08:40:10 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F27131448 for <6man@ietf.org>; Fri, 14 Apr 2017 08:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EFe9Gf013004; Fri, 14 Apr 2017 08:40:09 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EFe5ZH012948 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 08:40:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 08:40:04 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 08:40:04 -0700 From: "Templin, Fred L" To: Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Subject: RE: Deprecation of IPv6 atomic fragments (some good news) Thread-Topic: Deprecation of IPv6 atomic fragments (some good news) Thread-Index: AQHStTPa1hK2AEEwp0Wezupmp4l/LKHE/9+w Date: Fri, 14 Apr 2017 15:40:04 +0000 Message-ID: References: <626c7e05-c3b5-2463-6547-96d875196697@gont.com.ar> In-Reply-To: <626c7e05-c3b5-2463-6547-96d875196697@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:40:12 -0000 Hi Fernando, With the deprecation of atomic fragments, is there another way to include an Identification value in the header of an IPv6 packet? Do we need a new extension header or destination option for that? Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Friday, April 14, 2017 8:28 AM > To: 6man@ietf.org > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: Deprecation of IPv6 atomic fragments (some good news) >=20 > Folks, >=20 > Thought it might be good feedback for the group. Juniper published a > vulnerability advisory with patches for the issue discussed in RFC8021: > >=20 > Besides providing the rationale for the change in rfc2460bis and > RFC7915, this kind of thing was one of the motivations for working on > such RFC. >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 14 08:44:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115741296D2 for ; Fri, 14 Apr 2017 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 FWd4JbEtyhzs for ; Fri, 14 Apr 2017 08:44:47 -0700 (PDT) Received: from nm18-vm4.bullet.mail.gq1.yahoo.com (nm18-vm4.bullet.mail.gq1.yahoo.com [98.136.217.219]) (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 1280E1270AC for <6man@ietf.org>; Fri, 14 Apr 2017 08:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492184686; bh=XnuZ3m1ObM10AG3+qumtADalbWXx62QosbcpNvnxS8U=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=OhII8sGkKbokcmek1TSBKJPmGCkWlZY6Xm8q7KGlov6/7inPWj2y3QJptyEHGn6hcTD1C6zXMFJl+C2ioc4iPo2Fow/8uzr1imM9MJvnRGFRwfanOndNJrJWxO+pGotKaFKYx7fCxtQ5kvhZuTEdeaGCF39+pOOoOn6YpxcL39xIVsXxFq4qY5pP6K/dm9cn/Khc4PeLZUS9I69WliDmEnbvYlMWvtE6KHV6vHUFPGY+hcpSURf5/2Mp9FRi0++YJGQfvxCLFzEuVmdXoy2JlMdx29w52yoROIF4VYndHwmj3LhHt6zs/b/piZGHQpTGGUvVY0rFvx+hIdHaT1uUxg== Received: from [98.137.12.56] by nm18.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 15:44:46 -0000 Received: from [98.137.12.219] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 15:44:46 -0000 Received: from [127.0.0.1] by omp1027.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 15:44:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 691413.81348.bm@omp1027.mail.gq1.yahoo.com X-YMail-OSG: nJ_Ns1YVM1kvLm6EHW35L7ZNfWulbxZY4sdf0Tukx1gN0Y2nkpZmTrmOSB8Hmox IfUuHzt.ns3oOxOC__4BywLJcrU56L0IijhLKT2hSnx070lBvc739T1T28WU.YMpn1lWUzgkJoLZ MN1a_LH66A4fWyN_Y.Ml8eB26v9IRRwY6A.184.Rx9A1nC_JQSeO_.mPlpGbSG6fCuaWCI4HDC9S qbYuE_07KbDLm_465mZ96Wrd1F2OnQUO9OgS9UPQ93_ICZIfloUoziQEnesqVvzvQGifi.SKcOa1 wKdyG7kQCRwD5qirpWguYwlIxK5H10y4D32IIVCJFaPPNtvf9WDnzJDH2S8zMFFMRlxCHEcB0g1N AIVLhsuXbv.UpgoIfAizRcCTh6D97l6jpIJIF8CQtz71zYk.gy0REpritmu4dGAIRvUzvFdBay5q ckkpRDY6K_YYctxxnb7SBlleqA85RQnE6DFKPxDKnEuXPv4sqnbzQz_kqaP9AdOeQc7YB64PT9_q TqEJow7klWJXkdTifdL.WWY1EowYGpewhYgad Received: from jws300018.mail.gq1.yahoo.com by sendmailws106.mail.gq1.yahoo.com; Fri, 14 Apr 2017 15:44:46 +0000; 1492184686.048 Date: Fri, 14 Apr 2017 15:44:45 +0000 (UTC) From: Reply-To: To: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Fred LTemplin Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Message-ID: <758692672.512417.1492184685846@mail.yahoo.com> Subject: RE: Deprecation of IPv6 atomic fragments (some good news) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <758692672.512417.1492184685846.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:44:49 -0000 Fred, For sequence numbers in IPv6, You may wish to look at https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ which was on the telechat agenda for Thursday. We will be addressing all the comments & hope to be rolling quite soon. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/14/17, Templin, Fred L wrote: Subject: RE: Deprecation of IPv6 atomic fragments (some good news) To: "Fernando Gont" , "6man@ietf.org" <6man@ietf.org> Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Date: Friday, April 14, 2017, 8:40 AM Hi Fernando, With the deprecation of atomic fragments, is there another way to include an Identification value in the header of an IPv6 packet? Do we need a new extension header or destination option for that? Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Friday, April 14, 2017 8:28 AM > To: 6man@ietf.org > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: Deprecation of IPv6 atomic fragments (some good news) > > Folks, > > Thought it might be good feedback for the group. Juniper published a > vulnerability advisory with patches for the issue discussed in RFC8021: > > > Besides providing the rationale for the change in rfc2460bis and > RFC7915, this kind of thing was one of the motivations for working on > such RFC. > > Thanks! > > Cheers, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Apr 14 08:49:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96D1289B0 for ; Fri, 14 Apr 2017 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zM-RNnzs3ejb for ; Fri, 14 Apr 2017 08:49:46 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9D11273E2 for <6man@ietf.org>; Fri, 14 Apr 2017 08:49:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EFnjj9028579; Fri, 14 Apr 2017 08:49:45 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EFnYNK028356 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 08:49:34 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 08:49:33 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 08:49:33 -0700 From: "Templin, Fred L" To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Subject: RE: Deprecation of IPv6 atomic fragments (some good news) Thread-Topic: Deprecation of IPv6 atomic fragments (some good news) Thread-Index: AQHStTYK1hK2AEEwp0Wezupmp4l/LKHFAtXQ Date: Fri, 14 Apr 2017 15:49:33 +0000 Message-ID: <37ff3e415a274e81ac925a9e1b6f23f5@XCH15-06-08.nw.nos.boeing.com> References: <758692672.512417.1492184685846.ref@mail.yahoo.com> <758692672.512417.1492184685846@mail.yahoo.com> In-Reply-To: <758692672.512417.1492184685846@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:49:48 -0000 VmVyeSBnb29kLiBUaGFua3MuDQoNCkZyZWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbSBbbWFpbHRvOm5hbGlu aS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tXQ0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDE0LCAy MDE3IDg6NDUgQU0NCj4gVG86IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPjsg Nm1hbkBpZXRmLm9yZzsgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Pg0KPiBDYzogZHJhZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9uQHRv b2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBEZXByZWNhdGlvbiBvZiBJUHY2IGF0b21pYyBm cmFnbWVudHMgKHNvbWUgZ29vZCBuZXdzKQ0KPiANCj4gRnJlZCwNCj4gDQo+IEZvciBzZXF1ZW5j ZSBudW1iZXJzIGluIElQdjYsIFlvdSBtYXkgd2lzaCB0byBsb29rIGF0DQo+IA0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9u Lw0KPiANCj4gd2hpY2ggd2FzIG9uIHRoZSB0ZWxlY2hhdCBhZ2VuZGEgZm9yIFRodXJzZGF5LiAg IFdlIHdpbGwgYmUgYWRkcmVzc2luZyBhbGwgdGhlIGNvbW1lbnRzICYgaG9wZSB0byBiZSByb2xs aW5nIHF1aXRlIHNvb24uDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBOYWxpbmkgRWxraW5zDQo+IENF TyBhbmQgRm91bmRlcg0KPiBJbnNpZGUgUHJvZHVjdHMsIEluYy4NCj4gd3d3Lmluc2lkZXRoZXN0 YWNrLmNvbQ0KPiAoODMxKSA2NTktODM2MA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gT24gRnJpLCA0LzE0LzE3LCBUZW1wbGluLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiANCj4gIFN1YmplY3Q6IFJFOiBE ZXByZWNhdGlvbiBvZiBJUHY2IGF0b21pYyBmcmFnbWVudHMgKHNvbWUgZ29vZCBuZXdzKQ0KPiAg VG86ICJGZXJuYW5kbyBHb250IiA8ZmVybmFuZG9AZ29udC5jb20uYXI+LCAiNm1hbkBpZXRmLm9y ZyIgPDZtYW5AaWV0Zi5vcmc+DQo+ICBDYzogImRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRv bWZyYWctZ2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZyIgPGRyYWZ0LWlldGYtNm1hbi1kZXByZWNh dGUtYXRvbWZyYWctDQo+IGdlbmVyYXRpb25AdG9vbHMuaWV0Zi5vcmc+DQo+ICBEYXRlOiBGcmlk YXksIEFwcmlsIDE0LCAyMDE3LCA4OjQwIEFNDQo+IA0KPiAgSGkgRmVybmFuZG8sDQo+IA0KPiAg V2l0aCB0aGUgZGVwcmVjYXRpb24gb2YgYXRvbWljIGZyYWdtZW50cywgaXMNCj4gIHRoZXJlIGFu b3RoZXIgd2F5IHRvIGluY2x1ZGUNCj4gIGFuDQo+ICBJZGVudGlmaWNhdGlvbiB2YWx1ZSBpbiB0 aGUgaGVhZGVyIG9mIGFuIElQdjYgcGFja2V0PyBEbyB3ZQ0KPiAgbmVlZCBhIG5ldw0KPiAgZXh0 ZW5zaW9uIGhlYWRlciBvciBkZXN0aW5hdGlvbg0KPiAgb3B0aW9uIGZvciB0aGF0Pw0KPiANCj4g IFRoYW5rcyAtDQo+ICBGcmVkDQo+IA0KPiAgPiAtLS0tLU9yaWdpbmFsDQo+ICBNZXNzYWdlLS0t LS0NCj4gID4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10NCj4gIE9u IEJlaGFsZiBPZiBGZXJuYW5kbyBHb250DQo+ICA+IFNlbnQ6DQo+ICBGcmlkYXksIEFwcmlsIDE0 LCAyMDE3IDg6MjggQU0NCj4gID4gVG86IDZtYW5AaWV0Zi5vcmcNCj4gID4gQ2M6IGRyYWZ0LWll dGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZw0KPiAg PiBTdWJqZWN0OiBEZXByZWNhdGlvbiBvZiBJUHY2IGF0b21pYw0KPiAgZnJhZ21lbnRzIChzb21l IGdvb2QgbmV3cykNCj4gID4NCj4gID4gRm9sa3MsDQo+ICA+DQo+ICA+IFRob3VnaHQgaXQgbWln aHQgYmUgZ29vZCBmZWVkYmFjayBmb3IgdGhlDQo+ICBncm91cC4gSnVuaXBlciBwdWJsaXNoZWQg YQ0KPiAgPg0KPiAgdnVsbmVyYWJpbGl0eSBhZHZpc29yeSB3aXRoIHBhdGNoZXMgZm9yIHRoZSBp c3N1ZSBkaXNjdXNzZWQNCj4gIGluIFJGQzgwMjE6DQo+ICA+IDxodHRwczovL2tiLmp1bmlwZXIu bmV0L0luZm9DZW50ZXIvaW5kZXg/cGFnZT1jb250ZW50JmlkPUpTQTEwNzgwJmFjdHA9U1VCU0NS SVBUSU9OPg0KPiAgPg0KPiAgPiBCZXNpZGVzIHByb3ZpZGluZw0KPiAgdGhlIHJhdGlvbmFsZSBm b3IgdGhlIGNoYW5nZSBpbiByZmMyNDYwYmlzIGFuZA0KPiAgPiBSRkM3OTE1LCB0aGlzIGtpbmQg b2YgdGhpbmcgd2FzIG9uZSBvZiB0aGUNCj4gIG1vdGl2YXRpb25zIGZvciB3b3JraW5nIG9uDQo+ ICA+IHN1Y2ggUkZDLg0KPiAgPg0KPiAgPiBUaGFua3MhDQo+ICA+DQo+ICA+IENoZWVycywNCj4g ID4gLS0NCj4gID4gRmVybmFuZG8gR29udA0KPiAgPiBlLW1haWw6IGZlcm5hbmRvQGdvbnQuY29t LmFyDQo+ICB8fCBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj4gID4gUEdQIEZpbmdlcnByaW50OiA3 ODA5IDg0RjUgMzIyRSA0NUM3IEYxQzkNCj4gIDM5NDUgOTZFRSBBOUVGIEQwNzYgRkZGMQ0KPiAg Pg0KPiAgPg0KPiAgPg0KPiAgPg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gID4gSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ICA+IGlwdjZAaWV0Zi5vcmcNCj4gID4gQWRtaW5pc3Ry YXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiAgPg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gIElFVEYg SVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiAgaXB2NkBpZXRmLm9yZw0KPiAgQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2Ng0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Fri Apr 14 08:53:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97641289B0 for ; Fri, 14 Apr 2017 08:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uOsPDGUTzuEx for ; Fri, 14 Apr 2017 08:53:42 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23931273E2 for <6man@ietf.org>; Fri, 14 Apr 2017 08:53:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EFrgwg060319; Fri, 14 Apr 2017 08:53:42 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EFrWv7059905 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 08:53:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 08:53:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 08:53:31 -0700 From: "Templin, Fred L" To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Subject: RE: Deprecation of IPv6 atomic fragments (some good news) Thread-Topic: Deprecation of IPv6 atomic fragments (some good news) Thread-Index: AQHStTYK1hK2AEEwp0Wezupmp4l/LKHFAtXQgAAArzA= Date: Fri, 14 Apr 2017 15:53:31 +0000 Message-ID: <69f010704f6a4374ac63db9cfa2f1cdd@XCH15-06-08.nw.nos.boeing.com> References: <758692672.512417.1492184685846.ref@mail.yahoo.com> <758692672.512417.1492184685846@mail.yahoo.com> <37ff3e415a274e81ac925a9e1b6f23f5@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <37ff3e415a274e81ac925a9e1b6f23f5@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 15:53:45 -0000 Oh, I just looked and saw that the option presents 16-bit Packet Sequence N= umbers. I was thinking 32 for use cases such as Duplicate Packet Detection. Is ther= e any way to get a 32-bit Identification? Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, April 14, 2017 8:50 AM > To: nalini.elkins@insidethestack.com; Fernando Gont ; 6man@ietf.org > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=20 > Very good. Thanks. >=20 > Fred >=20 > > -----Original Message----- > > From: nalini.elkins@insidethestack.com [mailto:nalini.elkins@insidethes= tack.com] > > Sent: Friday, April 14, 2017 8:45 AM > > To: Fernando Gont ; 6man@ietf.org; Templin, Fred = L > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) > > > > Fred, > > > > For sequence numbers in IPv6, You may wish to look at > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > which was on the telechat agenda for Thursday. We will be addressing = all the comments & hope to be rolling quite soon. > > > > Thanks, > > > > Nalini Elkins > > CEO and Founder > > Inside Products, Inc. > > www.insidethestack.com > > (831) 659-8360 > > > > -------------------------------------------- > > On Fri, 4/14/17, Templin, Fred L wrote: > > > > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) > > To: "Fernando Gont" , "6man@ietf.org" <6man@ietf= .org> > > Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" > generation@tools.ietf.org> > > Date: Friday, April 14, 2017, 8:40 AM > > > > Hi Fernando, > > > > With the deprecation of atomic fragments, is > > there another way to include > > an > > Identification value in the header of an IPv6 packet? Do we > > need a new > > extension header or destination > > option for that? > > > > Thanks - > > Fred > > > > > -----Original > > Message----- > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] > > On Behalf Of Fernando Gont > > > Sent: > > Friday, April 14, 2017 8:28 AM > > > To: 6man@ietf.org > > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > > > Subject: Deprecation of IPv6 atomic > > fragments (some good news) > > > > > > Folks, > > > > > > Thought it might be good feedback for the > > group. Juniper published a > > > > > vulnerability advisory with patches for the issue discussed > > in RFC8021: > > > > > > > > > Besides providing > > the rationale for the change in rfc2460bis and > > > RFC7915, this kind of thing was one of the > > motivations for working on > > > such RFC. > > > > > > Thanks! > > > > > > Cheers, > > > -- > > > Fernando Gont > > > e-mail: fernando@gont.com.ar > > || fgont@si6networks.com > > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 > > 3945 96EE A9EF D076 FFF1 > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 14 09:04:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD10131450 for ; Fri, 14 Apr 2017 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 1afnNIIiKIKl for ; Fri, 14 Apr 2017 09:04:54 -0700 (PDT) Received: from nm40-vm3.bullet.mail.gq1.yahoo.com (nm40-vm3.bullet.mail.gq1.yahoo.com [98.136.217.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391DA13144D for <6man@ietf.org>; Fri, 14 Apr 2017 09:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492185893; bh=it/rWS6jHxt4rOAFwAFF1eRf+KqpozSaGa30UaGDrGs=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=jMj4i3P8dUejSku7PR2q80CV4QJYMqpocnQeoUa68g0nIF6ZT7lw/9u1qjS47bm8fdw4t49UE4TezpmgnWEosXkGDBOOTZ9iT0dDdB7WbBlb/TEAoxiCdZps2I265G8eT3VcicxjpgSM0jH4HbLMgrmgkpX2CiTjL/yZepaqk5rOygkQMDsRMgP8Bp/LanwAZzfqowG32/dS/AlGbdmQT902jKRvKWjCwrRiWG5YSeIU3+yuCzXK287tpQLBDhzelkZOCCgeqBX0ANPs6U9wAchF6M0ojpPTGttXkUNoFHM7d2gIadjjkBnaJvZ4WTiAaJJhA0LZzX99yH6OVeY6sg== Received: from [127.0.0.1] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:04:53 -0000 Received: from [98.137.12.175] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:02:11 -0000 Received: from [98.137.12.237] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:00:11 -0000 Received: from [127.0.0.1] by omp1045.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:00:11 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 78011.2862.bm@omp1045.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300035.mail.gq1.yahoo.com by sendmailws144.mail.gq1.yahoo.com; Fri, 14 Apr 2017 16:00:10 +0000; 1492185610.649 Date: Fri, 14 Apr 2017 16:00:10 +0000 (UTC) From: Reply-To: To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Fred LTemplin Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Message-ID: <1027338590.520049.1492185610385@mail.yahoo.com> Subject: RE: Deprecation of IPv6 atomic fragments (some good news) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1027338590.520049.1492185610385.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:04:56 -0000 You can use the sequence number (PSN) in combination with the other fields PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTATLR : Delta Time Last Received DELTATLS : Delta Time Last Sent to get quite a good idea of duplicate packets. You can also differentiate= duplicate packets from retransmissions. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/14/17, Templin, Fred L wrote: Subject: RE: Deprecation of IPv6 atomic fragments (some good news) To: "nalini.elkins@insidethestack.com" ,= "Fernando Gont" , "6man@ietf.org" <6man@ietf.org> Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Date: Friday, April 14, 2017, 8:53 AM =20 Oh, I just looked and saw that the option presents 16-bit Packet Sequence Numbers. I was thinking 32 for use cases such as Duplicate Packet Detection. Is there any way to get a 32-bit Identification? =20 Thanks - Fred =20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, April 14, 2017 8:50 AM > To: nalini.elkins@insidethestack.com; Fernando Gont ; 6man@ietf.org > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=20 > Very good. Thanks. > =20 > Fred >=20 > > -----Original Message----- > > From: nalini.elkins@insidethestack.com [mailto:nalini.elkins@insidethestack.com] > > Sent: Friday, April 14, 2017 8:45 AM > > To: Fernando Gont ; 6man@ietf.org; Templin, Fred L > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) > > > > Fred, > > > > For sequence numbers in IPv6, You may wish to look at > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ > > > > which was on the telechat agenda for Thursday.=C2=A0 We will be addressing all the comments & hope to be rolling quite soon. > > > > Thanks, > > > > Nalini Elkins > > CEO and Founder > > Inside Products, Inc. > > www.insidethestack.com > > (831) 659-8360 > > > > -------------------------------------------- > > On Fri, 4/14/17, Templin, Fred L wrote: > > > >=C2=A0 Subject: RE: Deprecation of IPv6 atomic fragments (some good news) > >=C2=A0 To: "Fernando Gont" , "6man@ietf.org" <6man@ietf.org> > >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.or= g" > generation@tools.ietf.org> > >=C2=A0 Date: Friday, April 14, 2017, 8:40 AM > > > >=C2=A0 Hi Fernando, > > > >=C2=A0 With the deprecation of atomic fragments, is > >=C2=A0 there another way to include > >=C2=A0 an > >=C2=A0 Identification value in the header of an IPv6 packet? Do we > >=C2=A0 need a new > >=C2=A0 extension header or destination > >=C2=A0 option for that? > > > >=C2=A0 Thanks - > >=C2=A0 Fred > > > >=C2=A0 > -----Original > >=C2=A0 Message----- > >=C2=A0 > From: ipv6 [mailto:ipv6-bounces@ietf.org] > >=C2=A0 On Behalf Of Fernando Gont > >=C2=A0 > Sent: > >=C2=A0 Friday, April 14, 2017 8:28 AM > >=C2=A0 > To: 6man@ietf.org > >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.o= rg > >=C2=A0 > Subject: Deprecation of IPv6 atomic > >=C2=A0 fragments (some good news) > >=C2=A0 > > >=C2=A0 > Folks, > >=C2=A0 > > >=C2=A0 > Thought it might be good feedback for the > >=C2=A0 group. Juniper published a > >=C2=A0 > > >=C2=A0 vulnerability advisory with patches for the issue discussed > >=C2=A0 in RFC8021: > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > Besides providing > >=C2=A0 the rationale for the change in rfc2460bis and > >=C2=A0 > RFC7915, this kind of thing was one of the > >=C2=A0 motivations for working on > >=C2=A0 > such RFC. > >=C2=A0 > > >=C2=A0 > Thanks! > >=C2=A0 > > >=C2=A0 > Cheers, > >=C2=A0 > -- > >=C2=A0 > Fernando Gont > >=C2=A0 > e-mail: fernando@gont.com.ar > >=C2=A0 || fgont@si6networks.com > >=C2=A0 > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 > >=C2=A0 3945 96EE A9EF D076 FFF1 > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 -------------------------------------------------------------------- > >=C2=A0 > IETF IPv6 working group mailing list > >=C2=A0 > ipv6@ietf.org > >=C2=A0 > Administrative Requests: https://www.ietf.org/mailman/listinfo= /ipv6 > >=C2=A0 > > >=C2=A0 -------------------------------------------------------------------- > > > > > >=C2=A0 -------------------------------------------------------------------- > >=C2=A0 IETF IPv6 working group mailing list > >=C2=A0 ipv6@ietf.org > >=C2=A0 Administrative Requests: https://www.ietf.org/mailman/listinfo/i= pv6 > >=C2=A0 -------------------------------------------------------------------- > > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =20 =20 From nobody Fri Apr 14 09:23:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7C1294C5 for ; Fri, 14 Apr 2017 09:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 abIs8UvRLXTW for ; Fri, 14 Apr 2017 09:23:00 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26956129493 for <6man@ietf.org>; Fri, 14 Apr 2017 09:23:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EGMwDA019798; Fri, 14 Apr 2017 09:22:59 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EGMvSL019779 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 09:22:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 09:22:56 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 09:22:56 -0700 From: "Templin, Fred L" To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Subject: RE: Deprecation of IPv6 atomic fragments (some good news) Thread-Topic: Deprecation of IPv6 atomic fragments (some good news) Thread-Index: AQHStTgx1hK2AEEwp0Wezupmp4l/LKHFCM/g Date: Fri, 14 Apr 2017 16:22:56 +0000 Message-ID: <51f620f289f64e90a334310c1a17d97d@XCH15-06-08.nw.nos.boeing.com> References: <1027338590.520049.1492185610385.ref@mail.yahoo.com> <1027338590.520049.1492185610385@mail.yahoo.com> In-Reply-To: <1027338590.520049.1492185610385@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:23:03 -0000 SGkgTmFsaW5pLA0KDQpPSy4gQnV0LCB0dW5uZWwgZW5jYXBzdWxhdGlvbnMgZnJlcXVlbnRseSBp bmNsdWRlIDMyLWJpdCBJZGVudGlmaWNhdGlvbiB2YWx1ZXMNCihHUkUsIEdVRSwgSVBzZWMsIG90 aGVycykgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIERQRCBzbyBJIHdhcyB3b25kZXJpbmcgaWYgYQ0K c2ltaWxhciBmYWNpbGl0eSB3YXMgYXZhaWxhYmxlIGZvciByYXcgSVB2NiBwYWNrZXRzLiBJdCBz b3VuZHMgbGlrZSB3aXRoIHRoZQ0KUFNOIGZlYXR1cmUgeW91ciBkb2N1bWVudCBpcyBwcm92aWRp bmcgdGhlcmUgaXMgb3Bwb3J0dW5pdHkgZm9yIERQRCBidXQNCmluIGEgZGlmZmVyZW50IHdheSB0 aGFuIHdpZGVseS1kZXBsb3llZCB0dW5uZWxpbmcgc3lzdGVtcyBjdXJyZW50bHkgZG8gaXQuDQoN CkkgdGhpbmsgd2UgaGFkIHRoaXMgc2FtZSBjb252ZXJzYXRpb24gYXQgb25lIG9mIHRoZSByZWNl bnQgbWVldGluZ3MsIGJ1dA0KSSBhbSBsZWZ0IHdvbmRlcmluZyB3aGV0aGVyIGhhdmluZyB0d28g ZGlmZmVyZW50IHdheXMgb2YgZG9pbmcgRFBEIHdpbGwNCmJlIGNvbmZ1c2luZyB0byBpbXBsZW1l bnRlcnMuIE1heWJlIHdoYXQgeW91IGhhdmUgaXMgYmV0dGVyLCBidXQgd2lsbA0Kd2lkZWx5LWRl cGxveWVkIG5ldHdvcmtpbmcgZ2VhciBiZSBvdmVyaGF1bGVkIHRvIHBpY2sgdXAgdGhlIG5ldw0K ZmVhdHVyZT8NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tIFttYWlsdG86bmFsaW5p LmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb21dDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTQsIDIw MTcgOTowMCBBTQ0KPiBUbzogbmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb207IEZlcm5h bmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPjsgNm1hbkBpZXRmLm9yZzsgVGVtcGxpbiwg RnJlZCBMDQo+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogZHJhZnQtaWV0Zi02 bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9uQHRvb2xzLmlldGYub3JnDQo+IFN1Ympl Y3Q6IFJFOiBEZXByZWNhdGlvbiBvZiBJUHY2IGF0b21pYyBmcmFnbWVudHMgKHNvbWUgZ29vZCBu ZXdzKQ0KPiANCj4gWW91IGNhbiB1c2UgdGhlIHNlcXVlbmNlIG51bWJlciAoUFNOKSBpbiBjb21i aW5hdGlvbiB3aXRoIHRoZSBvdGhlciBmaWVsZHMNCj4gDQo+IFBTTlRQICAgICAgOiBQYWNrZXQg U2VxdWVuY2UgTnVtYmVyIFRoaXMgUGFja2V0DQo+IFBTTkxSICAgICAgOiBQYWNrZXQgU2VxdWVu Y2UgTnVtYmVyIExhc3QgUmVjZWl2ZWQNCj4gREVMVEFUTFIgOiBEZWx0YSBUaW1lIExhc3QgUmVj ZWl2ZWQNCj4gREVMVEFUTFMgOiBEZWx0YSBUaW1lIExhc3QgU2VudA0KPiANCj4gdG8gZ2V0IHF1 aXRlIGEgZ29vZCBpZGVhIG9mIGR1cGxpY2F0ZSBwYWNrZXRzLiAgIFlvdSBjYW4gYWxzbyBkaWZm ZXJlbnRpYXRlIGR1cGxpY2F0ZSBwYWNrZXRzIGZyb20gcmV0cmFuc21pc3Npb25zLg0KPiANCj4g VGhhbmtzLA0KPiANCj4gTmFsaW5pIEVsa2lucw0KPiBDRU8gYW5kIEZvdW5kZXINCj4gSW5zaWRl IFByb2R1Y3RzLCBJbmMuDQo+IHd3dy5pbnNpZGV0aGVzdGFjay5jb20NCj4gKDgzMSkgNjU5LTgz NjANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IE9uIEZyaSwgNC8xNC8xNywgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPiB3cm90ZToNCj4gDQo+ICBTdWJqZWN0OiBSRTogRGVwcmVjYXRpb24gb2YgSVB2NiBhdG9t aWMgZnJhZ21lbnRzIChzb21lIGdvb2QgbmV3cykNCj4gIFRvOiAibmFsaW5pLmVsa2luc0BpbnNp ZGV0aGVzdGFjay5jb20iIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4sICJGZXJu YW5kbyBHb250IiA8ZmVybmFuZG9AZ29udC5jb20uYXI+LA0KPiAiNm1hbkBpZXRmLm9yZyIgPDZt YW5AaWV0Zi5vcmc+DQo+ICBDYzogImRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWct Z2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZyIgPGRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRv bWZyYWctDQo+IGdlbmVyYXRpb25AdG9vbHMuaWV0Zi5vcmc+DQo+ICBEYXRlOiBGcmlkYXksIEFw cmlsIDE0LCAyMDE3LCA4OjUzIEFNDQo+IA0KPiAgT2gsIEkganVzdCBsb29rZWQgYW5kIHNhdyB0 aGF0DQo+ICB0aGUgb3B0aW9uIHByZXNlbnRzIDE2LWJpdCBQYWNrZXQgU2VxdWVuY2UgTnVtYmVy cy4NCj4gIEkgd2FzIHRoaW5raW5nIDMyIGZvciB1c2UgY2FzZXMgc3VjaCBhcw0KPiAgRHVwbGlj YXRlIFBhY2tldCBEZXRlY3Rpb24uIElzIHRoZXJlIGFueSB3YXkgdG8NCj4gIGdldCBhIDMyLWJp dCBJZGVudGlmaWNhdGlvbj8NCj4gDQo+ICBUaGFua3MgLSBGcmVkDQo+IA0KPiAgPiAtLS0tLU9y aWdpbmFsDQo+ICBNZXNzYWdlLS0tLS0NCj4gID4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91 bmNlc0BpZXRmLm9yZ10NCj4gIE9uIEJlaGFsZiBPZiBUZW1wbGluLCBGcmVkIEwNCj4gID4gU2Vu dDoNCj4gIEZyaWRheSwgQXByaWwgMTQsIDIwMTcgODo1MCBBTQ0KPiAgPiBUbzogbmFsaW5pLmVs a2luc0BpbnNpZGV0aGVzdGFjay5jb207DQo+ICBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250 LmNvbS5hcj47DQo+ICA2bWFuQGlldGYub3JnDQo+ICA+IENjOiBkcmFmdC1pZXRmLTZtYW4tZGVw cmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb25AdG9vbHMuaWV0Zi5vcmcNCj4gID4gU3ViamVjdDog UkU6IERlcHJlY2F0aW9uIG9mIElQdjYgYXRvbWljDQo+ICBmcmFnbWVudHMgKHNvbWUgZ29vZCBu ZXdzKQ0KPiAgPg0KPiAgPiBWZXJ5IGdvb2QuIFRoYW5rcy4NCj4gID4NCj4gDQo+ICA+IEZyZWQN Cj4gID4NCj4gID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgPiA+IEZyb206IG5h bGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tDQo+ICBbbWFpbHRvOm5hbGluaS5lbGtpbnNA aW5zaWRldGhlc3RhY2suY29tXQ0KPiAgPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTQsIDIwMTcg ODo0NQ0KPiAgQU0NCj4gID4gPiBUbzogRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5jb20u YXI+Ow0KPiAgNm1hbkBpZXRmLm9yZzsNCj4gIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4NCj4gID4gPiBDYzogZHJhZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9t ZnJhZy1nZW5lcmF0aW9uQHRvb2xzLmlldGYub3JnDQo+ICA+ID4gU3ViamVjdDogUkU6IERlcHJl Y2F0aW9uIG9mIElQdjYNCj4gIGF0b21pYyBmcmFnbWVudHMgKHNvbWUgZ29vZCBuZXdzKQ0KPiAg Pg0KPiAgPg0KPiAgPiA+IEZyZWQsDQo+ICA+DQo+ICA+DQo+ICA+ID4gRm9yIHNlcXVlbmNlIG51 bWJlcnMgaW4gSVB2NiwNCj4gIFlvdSBtYXkgd2lzaCB0byBsb29rIGF0DQo+ICA+ID4NCj4gID4g PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0tNm1hbi1w ZG0tb3B0aW9uLw0KPiAgPiA+DQo+ICA+ID4gd2hpY2ggd2FzDQo+ICBvbiB0aGUgdGVsZWNoYXQg YWdlbmRhIGZvciBUaHVyc2RheS7CoCAgV2Ugd2lsbCBiZQ0KPiAgYWRkcmVzc2luZyBhbGwgdGhl IGNvbW1lbnRzICYgaG9wZSB0byBiZSByb2xsaW5nIHF1aXRlDQo+ICBzb29uLg0KPiAgPiA+DQo+ ICA+ID4NCj4gIFRoYW5rcywNCj4gID4gPg0KPiAgPiA+DQo+ICBOYWxpbmkgRWxraW5zDQo+ICA+ ID4gQ0VPIGFuZCBGb3VuZGVyDQo+ICA+ID4gSW5zaWRlIFByb2R1Y3RzLCBJbmMuDQo+ICA+ID4g d3d3Lmluc2lkZXRoZXN0YWNrLmNvbQ0KPiAgPiA+ICg4MzEpIDY1OS04MzYwDQo+ICA+DQo+ICA+ DQo+ICA+ID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ICA+ID4gT24gRnJpLCA0LzE0LzE3LCBUZW1wbGluLCBGcmVkIEwNCj4gIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiAgd3JvdGU6DQo+ICA+ID4NCj4gID4gPg0KPiAgU3ViamVjdDog UkU6IERlcHJlY2F0aW9uIG9mIElQdjYgYXRvbWljIGZyYWdtZW50cyAoc29tZSBnb29kDQo+ICBu ZXdzKQ0KPiAgPiA+wqAgVG86ICJGZXJuYW5kbw0KPiAgR29udCIgPGZlcm5hbmRvQGdvbnQuY29t LmFyPiwNCj4gICI2bWFuQGlldGYub3JnIg0KPiAgPDZtYW5AaWV0Zi5vcmc+DQo+ICA+ID7CoCBD YzogImRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlvbkB0b29scy5p ZXRmLm9yZyINCj4gIDxkcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLQ0KPiAgPg0K PiAgPiBnZW5lcmF0aW9uQHRvb2xzLmlldGYub3JnPg0KPiAgPiA+wqAgRGF0ZTogRnJpZGF5LCBB cHJpbCAxNCwgMjAxNywgODo0MA0KPiAgQU0NCj4gID4gPg0KPiAgPiA+wqAgSGkNCj4gIEZlcm5h bmRvLA0KPiAgPiA+DQo+ICA+DQo+ICA+wqAgV2l0aCB0aGUgZGVwcmVjYXRpb24gb2YgYXRvbWlj IGZyYWdtZW50cywgaXMNCj4gID4gPsKgIHRoZXJlIGFub3RoZXIgd2F5IHRvIGluY2x1ZGUNCj4g ID4gPsKgIGFuDQo+ICA+ID4NCj4gIElkZW50aWZpY2F0aW9uIHZhbHVlIGluIHRoZSBoZWFkZXIg b2YgYW4gSVB2NiBwYWNrZXQ/IERvDQo+ICB3ZQ0KPiAgPiA+wqAgbmVlZCBhIG5ldw0KPiAgPiA+ wqAgZXh0ZW5zaW9uIGhlYWRlciBvciBkZXN0aW5hdGlvbg0KPiAgPiA+wqAgb3B0aW9uIGZvciB0 aGF0Pw0KPiAgPiA+DQo+ICA+ID7CoCBUaGFua3MNCj4gIC0NCj4gID4gPsKgIEZyZWQNCj4gID4N Cj4gID4NCj4gID4gPsKgID4gLS0tLS1PcmlnaW5hbA0KPiAgPiA+wqAgTWVzc2FnZS0tLS0tDQo+ ICA+DQo+ICA+wqAgPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXQ0K PiAgPiA+wqAgT24gQmVoYWxmIE9mIEZlcm5hbmRvIEdvbnQNCj4gID4gPsKgID4gU2VudDoNCj4g ID4NCj4gID7CoCBGcmlkYXksIEFwcmlsIDE0LCAyMDE3IDg6MjggQU0NCj4gID4NCj4gID7CoCA+ IFRvOiA2bWFuQGlldGYub3JnDQo+ICA+ID7CoCA+IENjOiBkcmFmdC1pZXRmLTZtYW4tZGVwcmVj YXRlLWF0b21mcmFnLWdlbmVyYXRpb25AdG9vbHMuaWV0Zi5vcmcNCj4gID4gPsKgID4gU3ViamVj dDogRGVwcmVjYXRpb24gb2YgSVB2Ng0KPiAgYXRvbWljDQo+ICA+ID7CoCBmcmFnbWVudHMgKHNv bWUgZ29vZA0KPiAgbmV3cykNCj4gID4gPsKgID4NCj4gID4NCj4gID7CoCA+IEZvbGtzLA0KPiAg PiA+wqAgPg0KPiAgPiA+wqAgPiBUaG91Z2h0IGl0IG1pZ2h0IGJlIGdvb2QNCj4gIGZlZWRiYWNr IGZvciB0aGUNCj4gID4gPsKgIGdyb3VwLiBKdW5pcGVyDQo+ICBwdWJsaXNoZWQgYQ0KPiAgPiA+ wqAgPg0KPiAgPiA+wqAgdnVsbmVyYWJpbGl0eSBhZHZpc29yeSB3aXRoIHBhdGNoZXMNCj4gIGZv ciB0aGUgaXNzdWUgZGlzY3Vzc2VkDQo+ICA+ID7CoCBpbg0KPiAgUkZDODAyMToNCj4gID4gPsKg ID4gPGh0dHBzOi8va2IuanVuaXBlci5uZXQvSW5mb0NlbnRlci9pbmRleD9wYWdlPWNvbnRlbnQm aWQ9SlNBMTA3ODAmYWN0cD1TVUJTQ1JJUFRJT04+DQo+ICA+ID7CoCA+DQo+ICA+ID4NCj4gID4g QmVzaWRlcyBwcm92aWRpbmcNCj4gID4gPsKgIHRoZQ0KPiAgcmF0aW9uYWxlIGZvciB0aGUgY2hh bmdlIGluIHJmYzI0NjBiaXMgYW5kDQo+ICA+ID7CoCA+IFJGQzc5MTUsIHRoaXMga2luZCBvZiB0 aGluZw0KPiAgd2FzIG9uZSBvZiB0aGUNCj4gID4gPsKgIG1vdGl2YXRpb25zIGZvcg0KPiAgd29y a2luZyBvbg0KPiAgPiA+wqAgPiBzdWNoIFJGQy4NCj4gID4gPsKgID4NCj4gID4gPg0KPiAgPiBU aGFua3MhDQo+ICA+ID7CoCA+DQo+ICA+ID7CoCA+IENoZWVycywNCj4gID4NCj4gID7CoCA+IC0t DQo+ICA+ID7CoCA+IEZlcm5hbmRvDQo+ICBHb250DQo+ICA+ID7CoCA+IGUtbWFpbDogZmVybmFu ZG9AZ29udC5jb20uYXINCj4gID4gPsKgIHx8IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KPiAgPiA+ wqAgPiBQR1AgRmluZ2VycHJpbnQ6IDc4MDkgODRGNQ0KPiAgMzIyRSA0NUM3IEYxQzkNCj4gID4g PsKgIDM5NDUgOTZFRSBBOUVGDQo+ICBEMDc2IEZGRjENCj4gID4gPsKgID4NCj4gID4gPsKgID4N Cj4gID4gPg0KPiAgPg0KPiAgPiA+wqAgPg0KPiAgPg0KPiAgPg0KPiAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g ID4gPsKgID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXANCj4gIG1haWxpbmcgbGlzdA0KPiAgPiA+ wqAgPiBpcHY2QGlldGYub3JnDQo+ICA+ID7CoCA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gID4NCj4gID7CoCA+ DQo+ICA+ID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+ID4NCj4gID4gPg0KPiAgPiA+DQo+ICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgPiA+wqAgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZw0KPiAgbGlz dA0KPiAgPiA+wqAgaXB2NkBpZXRmLm9yZw0KPiAgPiA+wqAgQWRtaW5pc3RyYXRpdmUgUmVxdWVz dHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAgPiA+DQo+ ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAgPiA+DQo+ICA+DQo+ICA+DQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgPiBJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gID4gaXB2NkBpZXRmLm9yZw0K PiAgPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2DQo+ICA+DQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQoNCg== From nobody Fri Apr 14 09:36:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382A1294C9 for ; Fri, 14 Apr 2017 09:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 q-WPKYzHFsdu for ; Fri, 14 Apr 2017 09:36:49 -0700 (PDT) Received: from nm19-vm1.bullet.mail.gq1.yahoo.com (nm19-vm1.bullet.mail.gq1.yahoo.com [98.136.217.24]) (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 9F339129421 for <6man@ietf.org>; Fri, 14 Apr 2017 09:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492187809; bh=zUTaiAocFCtqi+OREK8QCuFvUn6ujGu79Cv3H8bH0dk=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=kKjBSia4cNKoyfCvSMdxAX4rcVT5ZVmDsk8wR5m1gr1CyHMbKS0Z+YLHxMbnYCIgg7SimjPsiR7r9A0ioE6+6w7Uhl0jwLzgZpaM2hEa4qsrO0CCyhQxL3fS43Sp1mOdip3fanaPYOy7tQXKdtQG7VMm/shA1FsMqrnPehuY3993vJY/o82SaA73JiKuGYVrJ4SC/EqZvuPVLtLK8GZrdx7gIpf1xfP6xPr9CXLaTnnsDZl3mnZZJc0QiMxQNw13oDNg54n2bH1CLHwN58IwSnTEBfkysvSyPDQa5FMkld3eHYooGNKTE/2EuusokpONI15rmVFnBcdCDz+UJFxGtQ== Received: from [98.137.12.189] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:36:49 -0000 Received: from [98.137.12.239] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:36:49 -0000 Received: from [127.0.0.1] by omp1047.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:36:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 249865.29234.bm@omp1047.mail.gq1.yahoo.com X-YMail-OSG: 1XG6Q5cVM1kEX7w9D1MN12MjdEWIhe80kH1sUjtMsGPs8ZZGl0SBi6iOv7mFJBu QEjcJrtT7y0hiYizN8xUd1tEhRh_JYfOAOsOeDMNnLxgZwuKs9rddSF_bFcCcO3kh_A747IOS0wh 8PIEs.5hPQdK_2U7fjIY706LrjXxZP7qaEy0ffctPgA3nIBhInyYaZeFFJZUKrYp_52Ju4HLBn6i R_B8.qTvG8L9LEKv2nnSCO.MWotR9SSk74.GbOuE57wl4l8Z77tKJpKmQ2a5LUt6MeS4Q66qOE4n TdyvdEh04ESiGg2IridYrjAs1RO25rZWP4KqjmYOkQsoWtsTBtfP.E2_kwQNuwEMXMTpjc0uWJ8k em_MGppIqn1Xzt2HOgERSMAI3biZrNWqTrF083ZCp63UKPplcZ5l9mwP2gUeGaZYmFJqMLll7k2X dpspyN3Ollui7t.jKoCB5iCibaYyGN1thwdKeDIvM8o5Qw70SP5oVOYHmtVnA_GJCnwfh07RW3Vb faKriGqjwbbghWEYJleZZfQDN09OB7n67rA-- Received: from jws300001.mail.gq1.yahoo.com by sendmailws131.mail.gq1.yahoo.com; Fri, 14 Apr 2017 16:36:48 +0000; 1492187808.860 Date: Fri, 14 Apr 2017 16:36:47 +0000 (UTC) From: Reply-To: To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Fred LTemplin Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Message-ID: <1197525357.563762.1492187807985@mail.yahoo.com> Subject: RE: Deprecation of IPv6 atomic fragments (some good news) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1197525357.563762.1492187807985.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:36:51 -0000 Fred, Very interesting comments. =20 One thing, the Destination Option is set by the end host(s). Of course, t= he devices in the middle, if those are doing the encapsulation rather than = the end host, could certainly examine the Destination Option. As far as implementation, we are starting on code in the FreeBSD kernel at = the end of next week & I have already had two other requests for code sampl= es. I believe that at least one person (other than us!) has already start= ed on implementation. Let's see how this rolls! Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/14/17, Templin, Fred L wrote: Subject: RE: Deprecation of IPv6 atomic fragments (some good news) To: "nalini.elkins@insidethestack.com" ,= "Fernando Gont" , "6man@ietf.org" <6man@ietf.org> Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Date: Friday, April 14, 2017, 9:22 AM =20 Hi Nalini, =20 OK. But, tunnel encapsulations frequently include 32-bit Identification values (GRE, GUE, IPsec, others) which can be used for DPD so I was wondering if a similar facility was available for raw IPv6 packets. It sounds like with the PSN feature your document is providing there is opportunity for DPD but in a different way than widely-deployed tunneling systems currently do it. =20 I think we had this same conversation at one of the recent meetings, but I am left wondering whether having two different ways of doing DPD will be confusing to implementers. Maybe what you have is better, but will widely-deployed networking gear be overhauled to pick up the new feature? =20 Thanks - Fred =20 > -----Original Message----- > From: nalini.elkins@insidethestack.com [mailto:nalini.elkins@insidethestack.com] > Sent: Friday, April 14, 2017 9:00 AM > To: nalini.elkins@insidethestack.com; Fernando Gont ; 6man@ietf.org; Templin, Fred L > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=20 > You can use the sequence number (PSN) in combination with the other fields >=20 > PSNTP=C2=A0 =C2=A0 =C2=A0 : Packet Sequence Number This Packet > PSNLR=C2=A0 =C2=A0 =C2=A0 : Packet Sequence Number Last Received > DELTATLR : Delta Time Last Received > DELTATLS : Delta Time Last Sent >=20 > to get quite a good idea of duplicate packets.=C2=A0 You can also differentiate duplicate packets from retransmissions. >=20 > Thanks, >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 > -------------------------------------------- > On Fri, 4/14/17, Templin, Fred L wrote: >=20 >=C2=A0 Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=C2=A0 To: "nalini.elkins@insidethestack.com" , "Fernando Gont" , > "6man@ietf.org" <6man@ietf.org> >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" generation@tools.ietf.org> >=C2=A0 Date: Friday, April 14, 2017, 8:53 AM >=20 >=C2=A0 Oh, I just looked and saw that >=C2=A0 the option presents 16-bit Packet Sequence Numbers. >=C2=A0 I was thinking 32 for use cases such as >=C2=A0 Duplicate Packet Detection. Is there any way to >=C2=A0 get a 32-bit Identification? >=20 >=C2=A0 Thanks - Fred >=20 >=C2=A0 > -----Original >=C2=A0 Message----- >=C2=A0 > From: ipv6 [mailto:ipv6-bounces@ietf.org] >=C2=A0 On Behalf Of Templin, Fred L >=C2=A0 > Sent: >=C2=A0 Friday, April 14, 2017 8:50 AM >=C2=A0 > To: nalini.elkins@insidethestack.com; >=C2=A0 Fernando Gont ; >=C2=A0 6man@ietf.org >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org >=C2=A0 > Subject: RE: Deprecation of IPv6 atomic >=C2=A0 fragments (some good news) >=C2=A0 > >=C2=A0 > Very good. Thanks. >=C2=A0 > >=20 >=C2=A0 > Fred >=C2=A0 > >=C2=A0 > > -----Original Message----- >=C2=A0 > > From: nalini.elkins@insidethestack.com >=C2=A0 [mailto:nalini.elkins@insidethestack.com] >=C2=A0 > > Sent: Friday, April 14, 2017 8:45 >=C2=A0 AM >=C2=A0 > > To: Fernando Gont ; >=C2=A0 6man@ietf.org; >=C2=A0 Templin, Fred L >=C2=A0 > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.o= rg >=C2=A0 > > Subject: RE: Deprecation of IPv6 >=C2=A0 atomic fragments (some good news) >=C2=A0 > >=C2=A0 > >=C2=A0 > > Fred, >=C2=A0 > >=C2=A0 > >=C2=A0 > > For sequence numbers in IPv6, >=C2=A0 You may wish to look at >=C2=A0 > > >=C2=A0 > > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ >=C2=A0 > > >=C2=A0 > > which was >=C2=A0 on the telechat agenda for Thursday.=C2=A0=C2=A0 We will be >=C2=A0 addressing all the comments & hope to be rolling quite >=C2=A0 soon. >=C2=A0 > > >=C2=A0 > > >=C2=A0 Thanks, >=C2=A0 > > >=C2=A0 > > >=C2=A0 Nalini Elkins >=C2=A0 > > CEO and Founder >=C2=A0 > > Inside Products, Inc. >=C2=A0 > > www.insidethestack.com >=C2=A0 > > (831) 659-8360 >=C2=A0 > >=C2=A0 > >=C2=A0 > > >=C2=A0 -------------------------------------------- >=C2=A0 > > On Fri, 4/14/17, Templin, Fred L >=C2=A0 >=C2=A0 wrote: >=C2=A0 > > >=C2=A0 > > >=C2=A0 Subject: RE: Deprecation of IPv6 atomic fragments (some good >=C2=A0 news) >=C2=A0 > >=C2=A0 To: "Fernando >=C2=A0 Gont" , >=C2=A0 "6man@ietf.org" >=C2=A0 <6man@ietf.org> >=C2=A0 > >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools= .ietf.org" >=C2=A0 =C2=A0 > >=C2=A0 > generation@tools.ietf.org> >=C2=A0 > >=C2=A0 Date: Friday, April 14, 2017, 8:40 >=C2=A0 AM >=C2=A0 > > >=C2=A0 > >=C2=A0 Hi >=C2=A0 Fernando, >=C2=A0 > > >=C2=A0 > >=C2=A0 >=C2=A0 With the deprecation of atomic fragments, is >=C2=A0 > >=C2=A0 there another way to include >=C2=A0 > >=C2=A0 an >=C2=A0 > > >=C2=A0 Identification value in the header of an IPv6 packet? Do >=C2=A0 we >=C2=A0 > >=C2=A0 need a new >=C2=A0 > >=C2=A0 extension header or destination >=C2=A0 > >=C2=A0 option for that? >=C2=A0 > > >=C2=A0 > >=C2=A0 Thanks >=C2=A0 - >=C2=A0 > >=C2=A0 Fred >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > -----Original >=C2=A0 > >=C2=A0 Message----- >=C2=A0 > >=C2=A0 >=C2=A0 > From: ipv6 [mailto:ipv6-bounces@ietf.org] >=C2=A0 > >=C2=A0 On Behalf Of Fernando Gont >=C2=A0 > >=C2=A0 > Sent: >=C2=A0 > >=C2=A0 >=C2=A0 Friday, April 14, 2017 8:28 AM >=C2=A0 > >=C2=A0 >=C2=A0 > To: 6man@ietf.org >=C2=A0 > >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tool= s.ietf.org >=C2=A0 > >=C2=A0 > Subject: Deprecation of IPv6 >=C2=A0 atomic >=C2=A0 > >=C2=A0 fragments (some good >=C2=A0 news) >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > Folks, >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > Thought it might be good >=C2=A0 feedback for the >=C2=A0 > >=C2=A0 group. Juniper >=C2=A0 published a >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 vulnerability advisory with patches >=C2=A0 for the issue discussed >=C2=A0 > >=C2=A0 in >=C2=A0 RFC8021: >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > > >=C2=A0 > Besides providing >=C2=A0 > >=C2=A0 the >=C2=A0 rationale for the change in rfc2460bis and >=C2=A0 > >=C2=A0 > RFC7915, this kind of thing >=C2=A0 was one of the >=C2=A0 > >=C2=A0 motivations for >=C2=A0 working on >=C2=A0 > >=C2=A0 > such RFC. >=C2=A0 > >=C2=A0 > >=C2=A0 > > >=C2=A0 > Thanks! >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > Cheers, >=C2=A0 > >=C2=A0 >=C2=A0 > -- >=C2=A0 > >=C2=A0 > Fernando >=C2=A0 Gont >=C2=A0 > >=C2=A0 > e-mail: fernando@gont.com.ar >=C2=A0 > >=C2=A0 || fgont@si6networks.com >=C2=A0 > >=C2=A0 > PGP Fingerprint: 7809 84F5 >=C2=A0 322E 45C7 F1C9 >=C2=A0 > >=C2=A0 3945 96EE A9EF >=C2=A0 D076 FFF1 >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > >=C2=A0 > IETF IPv6 working group >=C2=A0 mailing list >=C2=A0 > >=C2=A0 > ipv6@ietf.org >=C2=A0 > >=C2=A0 > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > > >=C2=A0 > > >=C2=A0 > > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > >=C2=A0 IETF IPv6 working group mailing >=C2=A0 list >=C2=A0 > >=C2=A0 ipv6@ietf.org >=C2=A0 > >=C2=A0 Administrative Requests: https://www.ietf.org/mailman/li= stinfo/ipv6 >=C2=A0 > > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > > >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > IETF IPv6 working group mailing list >=C2=A0 > ipv6@ietf.org >=C2=A0 > Administrative Requests: https://www.ietf.org/mailman/listinfo/i= pv6 >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=20 >=20 =20 =20 From nobody Fri Apr 14 09:50:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43031294CE for ; Fri, 14 Apr 2017 09:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BKjE66aE9JIQ for ; Fri, 14 Apr 2017 09:49:59 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFA1129421 for <6man@ietf.org>; Fri, 14 Apr 2017 09:49:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3EGnw2Z022579; Fri, 14 Apr 2017 09:49:58 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3EGnmG2022512 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 14 Apr 2017 09:49:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 14 Apr 2017 09:49:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 14 Apr 2017 09:49:47 -0700 From: "Templin, Fred L" To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org> CC: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Subject: RE: Deprecation of IPv6 atomic fragments (some good news) Thread-Topic: Deprecation of IPv6 atomic fragments (some good news) Thread-Index: AQHStT1O1hK2AEEwp0Wezupmp4l/LKHFEMNA Date: Fri, 14 Apr 2017 16:49:47 +0000 Message-ID: <7726e86558b141d6891f5e18f3ce437f@XCH15-06-08.nw.nos.boeing.com> References: <1197525357.563762.1492187807985.ref@mail.yahoo.com> <1197525357.563762.1492187807985@mail.yahoo.com> In-Reply-To: <1197525357.563762.1492187807985@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:50:02 -0000 SGkgTmFsaW5pLA0KDQpJIGRvbid0IHdhbnQgdG8gYmUgbWlzdW5kZXJzdG9vZCAtIEkgc3VwcG9y dCB3aGF0IHlvdSBhcmUgcHJvcG9zaW5nLg0KSW4gdGVybXMgb2YgdHVubmVsaW5nLCBob3dldmVy LCB3ZSBhcmUgdXNpbmcgVExTIGluIHNvbWUgb2Ygb3VyIGludGVybmFsDQpjb2RlIGFuZCBpdCBs b29rcyBsaWtlIFRMUyBwcm92aWRlcyBhIDY0LWJpdCBzZXF1ZW5jZSBudW1iZXIgdGhhdCB3ZQ0K YXJlIHVzaW5nIGZvciBEUEQgKGFsc28gcmVvcmRlcmluZyBkZXRlY3Rpb24pLg0KDQpCdXQsIGFz IEkgdGhpbmsgeW91IGFyZSBpbXBseWluZywgdGhlIHR1bm5lbCBpcyBvbmx5IG9uZSBsaW5rIGlu IHdoYXQgbWF5DQpiZSBhbiBJUHY2IHBhdGggb3ZlciBtYW55IGxpbmtzLiBTbywgaXQgY291bGQg YmUgdGhhdCB0aGUgcmF3IElQdjYgcGFja2V0DQptYXkgc3RpbGwgd2FudCB0byBpbmNsdWRlIG9u ZSBvZiB5b3VyIG9wdGlvbnMgaW4gY2FzZSBkdXBsaWNhdGlvbiBtaWdodA0Kb2NjdXIgc29tZXdo ZXJlIGFsb25nIHRoZSByZW1haW5pbmcgSVB2NiBwYXRoIG9uY2UgdGhlIHBhY2tldA0KZW1lcmdl cyBmcm9tIHRoZSB0dW5uZWwuIFNvLCBJIHRoaW5rIGl0IGlzIE9LLg0KDQpUaGFua3MgLSBGcmVk DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmFsaW5pLmVsa2luc0Bp bnNpZGV0aGVzdGFjay5jb20gW21haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bV0NCj4gU2VudDogRnJpZGF5LCBBcHJpbCAxNCwgMjAxNyA5OjM3IEFNDQo+IFRvOiBuYWxpbmku ZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbTsgRmVybmFuZG8gR29udCA8ZmVybmFuZG9AZ29udC5j b20uYXI+OyA2bWFuQGlldGYub3JnOyBUZW1wbGluLCBGcmVkIEwNCj4gPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+IENjOiBkcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdl bmVyYXRpb25AdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IERlcHJlY2F0aW9uIG9mIElQ djYgYXRvbWljIGZyYWdtZW50cyAoc29tZSBnb29kIG5ld3MpDQo+IA0KPiBGcmVkLA0KPiANCj4g VmVyeSBpbnRlcmVzdGluZyBjb21tZW50cy4NCj4gDQo+IE9uZSB0aGluZywgdGhlIERlc3RpbmF0 aW9uIE9wdGlvbiBpcyBzZXQgYnkgdGhlIGVuZCBob3N0KHMpLiAgIE9mIGNvdXJzZSwgdGhlIGRl dmljZXMgaW4gdGhlIG1pZGRsZSwgaWYgdGhvc2UgYXJlIGRvaW5nIHRoZSBlbmNhcHN1bGF0aW9u DQo+IHJhdGhlciB0aGFuIHRoZSBlbmQgaG9zdCwgY291bGQgY2VydGFpbmx5IGV4YW1pbmUgdGhl IERlc3RpbmF0aW9uIE9wdGlvbi4NCj4gDQo+IEFzIGZhciBhcyBpbXBsZW1lbnRhdGlvbiwgd2Ug YXJlIHN0YXJ0aW5nIG9uIGNvZGUgaW4gdGhlIEZyZWVCU0Qga2VybmVsIGF0IHRoZSBlbmQgb2Yg bmV4dCB3ZWVrICYgSSBoYXZlIGFscmVhZHkgaGFkIHR3byBvdGhlcg0KPiByZXF1ZXN0cyBmb3Ig Y29kZSBzYW1wbGVzLiAgIEkgYmVsaWV2ZSB0aGF0IGF0IGxlYXN0IG9uZSBwZXJzb24gKG90aGVy IHRoYW4gdXMhKSBoYXMgYWxyZWFkeSBzdGFydGVkIG9uIGltcGxlbWVudGF0aW9uLiAgIExldCdz IHNlZSBob3cNCj4gdGhpcyByb2xscyENCj4gDQo+IFRoYW5rcywNCj4gDQo+IE5hbGluaSBFbGtp bnMNCj4gQ0VPIGFuZCBGb3VuZGVyDQo+IEluc2lkZSBQcm9kdWN0cywgSW5jLg0KPiB3d3cuaW5z aWRldGhlc3RhY2suY29tDQo+ICg4MzEpIDY1OS04MzYwDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBPbiBGcmksIDQvMTQvMTcsIFRlbXBsaW4s IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiAgU3ViamVj dDogUkU6IERlcHJlY2F0aW9uIG9mIElQdjYgYXRvbWljIGZyYWdtZW50cyAoc29tZSBnb29kIG5l d3MpDQo+ICBUbzogIm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tIiA8bmFsaW5pLmVs a2luc0BpbnNpZGV0aGVzdGFjay5jb20+LCAiRmVybmFuZG8gR29udCIgPGZlcm5hbmRvQGdvbnQu Y29tLmFyPiwNCj4gIjZtYW5AaWV0Zi5vcmciIDw2bWFuQGlldGYub3JnPg0KPiAgQ2M6ICJkcmFm dC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb25AdG9vbHMuaWV0Zi5vcmci IDxkcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLQ0KPiBnZW5lcmF0aW9uQHRvb2xz LmlldGYub3JnPg0KPiAgRGF0ZTogRnJpZGF5LCBBcHJpbCAxNCwgMjAxNywgOToyMiBBTQ0KPiAN Cj4gIEhpIE5hbGluaSwNCj4gDQo+ICBPSy4gQnV0LCB0dW5uZWwgZW5jYXBzdWxhdGlvbnMgZnJl cXVlbnRseQ0KPiAgaW5jbHVkZSAzMi1iaXQgSWRlbnRpZmljYXRpb24gdmFsdWVzDQo+ICAoR1JF LA0KPiAgR1VFLCBJUHNlYywgb3RoZXJzKSB3aGljaCBjYW4gYmUgdXNlZCBmb3IgRFBEIHNvIEkg d2FzDQo+ICB3b25kZXJpbmcgaWYgYQ0KPiAgc2ltaWxhciBmYWNpbGl0eSB3YXMNCj4gIGF2YWls YWJsZSBmb3IgcmF3IElQdjYgcGFja2V0cy4gSXQgc291bmRzIGxpa2Ugd2l0aCB0aGUNCj4gIFBT TiBmZWF0dXJlIHlvdXIgZG9jdW1lbnQgaXMgcHJvdmlkaW5nIHRoZXJlIGlzDQo+ICBvcHBvcnR1 bml0eSBmb3IgRFBEIGJ1dA0KPiAgaW4gYSBkaWZmZXJlbnQgd2F5DQo+ICB0aGFuIHdpZGVseS1k ZXBsb3llZCB0dW5uZWxpbmcgc3lzdGVtcyBjdXJyZW50bHkgZG8gaXQuDQo+IA0KPiAgSSB0aGlu ayB3ZSBoYWQgdGhpcyBzYW1lDQo+ICBjb252ZXJzYXRpb24gYXQgb25lIG9mIHRoZSByZWNlbnQg bWVldGluZ3MsIGJ1dA0KPiAgSSBhbSBsZWZ0IHdvbmRlcmluZyB3aGV0aGVyIGhhdmluZyB0d28N Cj4gIGRpZmZlcmVudCB3YXlzIG9mIGRvaW5nIERQRCB3aWxsDQo+ICBiZQ0KPiAgY29uZnVzaW5n IHRvIGltcGxlbWVudGVycy4gTWF5YmUgd2hhdCB5b3UgaGF2ZSBpcyBiZXR0ZXIsDQo+ICBidXQg d2lsbA0KPiAgd2lkZWx5LWRlcGxveWVkIG5ldHdvcmtpbmcgZ2VhciBiZQ0KPiAgb3ZlcmhhdWxl ZCB0byBwaWNrIHVwIHRoZSBuZXcNCj4gIGZlYXR1cmU/DQo+IA0KPiAgVGhhbmtzIC0gRnJlZA0K PiANCj4gID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4gRnJvbTogbmFsaW5pLmVs a2luc0BpbnNpZGV0aGVzdGFjay5jb20NCj4gIFttYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0 aGVzdGFjay5jb21dDQo+ICA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTQsIDIwMTcgOTowMCBBTQ0K PiAgPiBUbzogbmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb207DQo+ICBGZXJuYW5kbyBH b250IDxmZXJuYW5kb0Bnb250LmNvbS5hcj47DQo+ICA2bWFuQGlldGYub3JnOw0KPiAgVGVtcGxp biwgRnJlZCBMDQo+ICA+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiAgPiBDYzogZHJh ZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9uQHRvb2xzLmlldGYub3Jn DQo+ICA+IFN1YmplY3Q6IFJFOiBEZXByZWNhdGlvbiBvZiBJUHY2IGF0b21pYw0KPiAgZnJhZ21l bnRzIChzb21lIGdvb2QgbmV3cykNCj4gID4NCj4gID4gWW91IGNhbiB1c2UgdGhlIHNlcXVlbmNl IG51bWJlciAoUFNOKSBpbg0KPiAgY29tYmluYXRpb24gd2l0aCB0aGUgb3RoZXIgZmllbGRzDQo+ ICA+DQo+ICA+IFBTTlRQwqAgwqAgwqAgOiBQYWNrZXQgU2VxdWVuY2UgTnVtYmVyDQo+ICBUaGlz IFBhY2tldA0KPiAgPiBQU05MUsKgIMKgIMKgIDogUGFja2V0DQo+ICBTZXF1ZW5jZSBOdW1iZXIg TGFzdCBSZWNlaXZlZA0KPiAgPiBERUxUQVRMUg0KPiAgOiBEZWx0YSBUaW1lIExhc3QgUmVjZWl2 ZWQNCj4gID4gREVMVEFUTFMgOg0KPiAgRGVsdGEgVGltZSBMYXN0IFNlbnQNCj4gID4NCj4gID4g dG8gZ2V0IHF1aXRlIGEgZ29vZCBpZGVhIG9mIGR1cGxpY2F0ZQ0KPiAgcGFja2V0cy7CoCAgWW91 IGNhbiBhbHNvIGRpZmZlcmVudGlhdGUgZHVwbGljYXRlIHBhY2tldHMNCj4gIGZyb20gcmV0cmFu c21pc3Npb25zLg0KPiAgPg0KPiAgPiBUaGFua3MsDQo+ICA+DQo+ICA+IE5hbGluaSBFbGtpbnMN Cj4gID4gQ0VPIGFuZA0KPiAgRm91bmRlcg0KPiAgPiBJbnNpZGUgUHJvZHVjdHMsIEluYy4NCj4g ID4gd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQ0KPiAgPiAoODMxKSA2NTktODM2MA0KPiAgPg0KPiAg Pg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gID4g T24gRnJpLCA0LzE0LzE3LCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+ICB3cm90ZToNCj4gID4NCj4gID7CoCBTdWJqZWN0Og0KPiAgUkU6IERlcHJlY2F0aW9u IG9mIElQdjYgYXRvbWljIGZyYWdtZW50cyAoc29tZSBnb29kIG5ld3MpDQo+ICA+wqAgVG86ICJu YWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbSINCj4gIDxuYWxpbmkuZWxraW5zQGluc2lk ZXRoZXN0YWNrLmNvbT4sDQo+ICAiRmVybmFuZG8gR29udCIgPGZlcm5hbmRvQGdvbnQuY29tLmFy PiwNCj4gID4gIjZtYW5AaWV0Zi5vcmciDQo+ICA8Nm1hbkBpZXRmLm9yZz4NCj4gID7CoCBDYzog ImRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlvbkB0b29scy5pZXRm Lm9yZyINCj4gIDxkcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLQ0KPiAgPg0KPiAg Z2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZz4NCj4gID7CoCBEYXRlOiBGcmlkYXksIEFwcmlsIDE0 LCAyMDE3LCA4OjUzIEFNDQo+ICA+DQo+ICA+wqAgT2gsIEkganVzdCBsb29rZWQNCj4gIGFuZCBz YXcgdGhhdA0KPiAgPsKgIHRoZSBvcHRpb24gcHJlc2VudHMNCj4gIDE2LWJpdCBQYWNrZXQgU2Vx dWVuY2UgTnVtYmVycy4NCj4gID7CoCBJIHdhcw0KPiAgdGhpbmtpbmcgMzIgZm9yIHVzZSBjYXNl cyBzdWNoIGFzDQo+ICA+DQo+ICBEdXBsaWNhdGUgUGFja2V0IERldGVjdGlvbi4gSXMgdGhlcmUg YW55IHdheSB0bw0KPiAgPsKgIGdldCBhIDMyLWJpdCBJZGVudGlmaWNhdGlvbj8NCj4gID4NCj4g ID7CoCBUaGFua3MgLSBGcmVkDQo+ICA+DQo+ICA+wqAgPg0KPiAgLS0tLS1PcmlnaW5hbA0KPiAg PsKgIE1lc3NhZ2UtLS0tLQ0KPiAgPsKgID4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNl c0BpZXRmLm9yZ10NCj4gID7CoCBPbiBCZWhhbGYgT2YgVGVtcGxpbiwgRnJlZCBMDQo+ICA+wqAg PiBTZW50Og0KPiAgPg0KPiAgRnJpZGF5LCBBcHJpbCAxNCwgMjAxNyA4OjUwIEFNDQo+ICA+wqAg Pg0KPiAgVG86IG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tOw0KPiAgPsKgIEZlcm5h bmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPjsNCj4gID7CoCA2bWFuQGlldGYub3JnDQo+ ICA+wqAgPiBDYzogZHJhZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9u QHRvb2xzLmlldGYub3JnDQo+ICA+wqAgPiBTdWJqZWN0OiBSRTogRGVwcmVjYXRpb24gb2YgSVB2 Ng0KPiAgYXRvbWljDQo+ICA+wqAgZnJhZ21lbnRzIChzb21lIGdvb2QgbmV3cykNCj4gID7CoCA+ DQo+ICA+wqAgPiBWZXJ5DQo+ICBnb29kLiBUaGFua3MuDQo+ICA+wqAgPg0KPiAgPg0KPiAgPsKg ID4gRnJlZA0KPiAgPsKgID4NCj4gID7CoCA+ID4NCj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ICA+wqAgPiA+DQo+ICBGcm9tOiBuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNv bQ0KPiAgPsKgIFttYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb21dDQo+ICA+ wqAgPiA+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTQsIDIwMTcNCj4gIDg6NDUNCj4gID7CoCBBTQ0K PiAgPsKgID4NCj4gID4gVG86IEZlcm5hbmRvIEdvbnQgPGZlcm5hbmRvQGdvbnQuY29tLmFyPjsN Cj4gID7CoCA2bWFuQGlldGYub3JnOw0KPiAgPsKgIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4NCj4gID7CoCA+ID4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1kZXByZWNh dGUtYXRvbWZyYWctZ2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZw0KPiAgPsKgID4gPiBTdWJqZWN0 OiBSRTogRGVwcmVjYXRpb24gb2YNCj4gIElQdjYNCj4gID7CoCBhdG9taWMgZnJhZ21lbnRzIChz b21lIGdvb2QNCj4gIG5ld3MpDQo+ICA+wqAgPg0KPiAgPg0KPiAgPg0KPiAgPsKgID4gPiBGcmVk LA0KPiAgPsKgID4NCj4gID7CoCA+DQo+ICA+wqAgPiA+IEZvciBzZXF1ZW5jZSBudW1iZXJzIGlu DQo+ICBJUHY2LA0KPiAgPsKgIFlvdSBtYXkgd2lzaCB0byBsb29rIGF0DQo+ICA+wqAgPiA+DQo+ ICA+wqAgPg0KPiAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWlwcG0tNm1hbi1wZG0tb3B0aW9uLw0KPiAgPsKgID4gPg0KPiAgPsKgID4NCj4gID4gd2hpY2gg d2FzDQo+ICA+wqAgb24gdGhlIHRlbGVjaGF0IGFnZW5kYQ0KPiAgZm9yIFRodXJzZGF5LsKgwqAg V2Ugd2lsbCBiZQ0KPiAgPg0KPiAgYWRkcmVzc2luZyBhbGwgdGhlIGNvbW1lbnRzICYgaG9wZSB0 byBiZSByb2xsaW5nDQo+ICBxdWl0ZQ0KPiAgPsKgIHNvb24uDQo+ICA+DQo+ICA+ID4NCj4gID7C oCA+ID4NCj4gID7CoCBUaGFua3MsDQo+ICA+wqAgPg0KPiAgPg0KPiAgPsKgID4gPg0KPiAgPg0K PiAgTmFsaW5pIEVsa2lucw0KPiAgPsKgID4gPiBDRU8gYW5kDQo+ICBGb3VuZGVyDQo+ICA+wqAg PiA+IEluc2lkZSBQcm9kdWN0cywNCj4gIEluYy4NCj4gID7CoCA+ID4NCj4gIHd3dy5pbnNpZGV0 aGVzdGFjay5jb20NCj4gID7CoCA+ID4NCj4gICg4MzEpIDY1OS04MzYwDQo+ICA+wqAgPg0KPiAg PsKgID4NCj4gID7CoCA+ID4NCj4gID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ICA+wqAgPiA+IE9uIEZyaSwgNC8xNC8xNywgVGVtcGxpbiwgRnJl ZA0KPiAgTA0KPiAgPsKgIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiAgPsKgIHdyb3Rl Og0KPiAgPsKgID4NCj4gID4NCj4gID7CoCA+ID4NCj4gID4NCj4gIFN1YmplY3Q6IFJFOiBEZXBy ZWNhdGlvbiBvZiBJUHY2IGF0b21pYyBmcmFnbWVudHMgKHNvbWUNCj4gIGdvb2QNCj4gID7CoCBu ZXdzKQ0KPiAgPg0KPiAgPiA+wqAgVG86ICJGZXJuYW5kbw0KPiAgPg0KPiAgR29udCIgPGZlcm5h bmRvQGdvbnQuY29tLmFyPiwNCj4gID7CoCAiNm1hbkBpZXRmLm9yZyINCj4gID7CoCA8Nm1hbkBp ZXRmLm9yZz4NCj4gID7CoCA+ID7CoCBDYzogImRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRv bWZyYWctZ2VuZXJhdGlvbkB0b29scy5pZXRmLm9yZyINCj4gID4NCj4gIDxkcmFmdC1pZXRmLTZt YW4tZGVwcmVjYXRlLWF0b21mcmFnLQ0KPiAgPsKgID4NCj4gID7CoCA+IGdlbmVyYXRpb25AdG9v bHMuaWV0Zi5vcmc+DQo+ICA+wqAgPiA+wqAgRGF0ZTogRnJpZGF5LCBBcHJpbCAxNCwNCj4gIDIw MTcsIDg6NDANCj4gID7CoCBBTQ0KPiAgPg0KPiAgPiA+DQo+ICA+wqAgPiA+wqAgSGkNCj4gID7C oCBGZXJuYW5kbywNCj4gID7CoCA+DQo+ICA+DQo+ICA+wqAgPg0KPiAgPg0KPiAgPsKgIFdpdGgg dGhlIGRlcHJlY2F0aW9uIG9mIGF0b21pYyBmcmFnbWVudHMsIGlzDQo+ICA+wqAgPiA+wqAgdGhl cmUgYW5vdGhlciB3YXkgdG8NCj4gIGluY2x1ZGUNCj4gID7CoCA+ID7CoCBhbg0KPiAgPsKgID4g Pg0KPiAgPg0KPiAgSWRlbnRpZmljYXRpb24gdmFsdWUgaW4gdGhlIGhlYWRlciBvZiBhbiBJUHY2 IHBhY2tldD8gRG8NCj4gID7CoCB3ZQ0KPiAgPsKgID4gPg0KPiAgbmVlZCBhIG5ldw0KPiAgPsKg ID4gPsKgIGV4dGVuc2lvbg0KPiAgaGVhZGVyIG9yIGRlc3RpbmF0aW9uDQo+ICA+wqAgPiA+DQo+ ICBvcHRpb24gZm9yIHRoYXQ/DQo+ICA+wqAgPiA+DQo+ICA+wqAgPiA+wqAgVGhhbmtzDQo+ICA+ wqAgLQ0KPiAgPsKgID4gPg0KPiAgRnJlZA0KPiAgPsKgID4NCj4gID4NCj4gID4NCj4gID7CoCA+ ID7CoCA+DQo+ICAtLS0tLU9yaWdpbmFsDQo+ICA+wqAgPiA+DQo+ICBNZXNzYWdlLS0tLS0NCj4g ID7CoCA+DQo+ICA+wqAgPsKgID4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRm Lm9yZ10NCj4gID7CoCA+ID7CoCBPbiBCZWhhbGYgT2YgRmVybmFuZG8NCj4gIEdvbnQNCj4gID7C oCA+ID7CoCA+IFNlbnQ6DQo+ICA+wqAgPg0KPiAgPsKgID4NCj4gIEZyaWRheSwgQXByaWwgMTQs IDIwMTcgODoyOCBBTQ0KPiAgPg0KPiAgPg0KPiAgPsKgID7CoCA+IFRvOiA2bWFuQGlldGYub3Jn DQo+ICA+wqAgPiA+wqAgPiBDYzogZHJhZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1n ZW5lcmF0aW9uQHRvb2xzLmlldGYub3JnDQo+ICA+wqAgPiA+wqAgPiBTdWJqZWN0OiBEZXByZWNh dGlvbiBvZg0KPiAgSVB2Ng0KPiAgPsKgIGF0b21pYw0KPiAgPg0KPiAgPiA+wqAgZnJhZ21lbnRz IChzb21lIGdvb2QNCj4gID4NCj4gIG5ld3MpDQo+ICA+wqAgPiA+wqAgPg0KPiAgPsKgID4NCj4g ID7CoCA+wqAgPg0KPiAgRm9sa3MsDQo+ICA+wqAgPiA+wqAgPg0KPiAgPsKgID4gPsKgID4gVGhv dWdodCBpdCBtaWdodCBiZQ0KPiAgZ29vZA0KPiAgPsKgIGZlZWRiYWNrIGZvciB0aGUNCj4gID7C oCA+ID7CoCBncm91cC4gSnVuaXBlcg0KPiAgPsKgIHB1Ymxpc2hlZCBhDQo+ICA+wqAgPg0KPiAg PsKgID4NCj4gID7CoCA+ID7CoCB2dWxuZXJhYmlsaXR5DQo+ICBhZHZpc29yeSB3aXRoIHBhdGNo ZXMNCj4gID7CoCBmb3IgdGhlIGlzc3VlDQo+ICBkaXNjdXNzZWQNCj4gID7CoCA+ID7CoCBpbg0K PiAgPsKgIFJGQzgwMjE6DQo+ICA+wqAgPg0KPiAgPsKgID4gPGh0dHBzOi8va2IuanVuaXBlci5u ZXQvSW5mb0NlbnRlci9pbmRleD9wYWdlPWNvbnRlbnQmaWQ9SlNBMTA3ODAmYWN0cD1TVUJTQ1JJ UFRJT04+DQo+ICA+wqAgPiA+wqAgPg0KPiAgPg0KPiAgPiA+DQo+ICA+wqAgPiBCZXNpZGVzIHBy b3ZpZGluZw0KPiAgPsKgID4gPsKgIHRoZQ0KPiAgPg0KPiAgcmF0aW9uYWxlIGZvciB0aGUgY2hh bmdlIGluIHJmYzI0NjBiaXMgYW5kDQo+ICA+wqAgPiA+wqAgPiBSRkM3OTE1LCB0aGlzIGtpbmQg b2YNCj4gIHRoaW5nDQo+ICA+wqAgd2FzIG9uZSBvZiB0aGUNCj4gID7CoCA+ID7CoCBtb3RpdmF0 aW9ucyBmb3INCj4gID7CoCB3b3JraW5nIG9uDQo+ICA+wqAgPg0KPiAgPsKgID4gc3VjaCBSRkMu DQo+ICA+wqAgPiA+DQo+ICA+DQo+ICA+wqAgPiA+DQo+ICA+DQo+ICA+IFRoYW5rcyENCj4gID7C oCA+ID7CoCA+DQo+ICA+wqAgPiA+wqAgPiBDaGVlcnMsDQo+ICA+wqAgPg0KPiAgPsKgID7CoCA+ DQo+ICAtLQ0KPiAgPsKgID4gPsKgID4gRmVybmFuZG8NCj4gID7CoCBHb250DQo+ICA+wqAgPiA+ DQo+ICA+IGUtbWFpbDogZmVybmFuZG9AZ29udC5jb20uYXINCj4gID7CoCA+ID7CoCB8fCBmZ29u dEBzaTZuZXR3b3Jrcy5jb20NCj4gID7CoCA+ID7CoCA+IFBHUCBGaW5nZXJwcmludDogNzgwOQ0K PiAgODRGNQ0KPiAgPsKgIDMyMkUgNDVDNyBGMUM5DQo+ICA+wqAgPiA+wqAgMzk0NSA5NkVFIEE5 RUYNCj4gID7CoCBEMDc2IEZGRjENCj4gID7CoCA+DQo+ICA+wqAgPg0KPiAgPsKgID4gPsKgID4N Cj4gID7CoCA+ID4NCj4gID7CoCA+DQo+ICA+wqAgPiA+wqAgPg0KPiAgPg0KPiAgPg0KPiAgPsKg ID4NCj4gID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+wqAgPiA+wqAgPiBJRVRGIElQdjYgd29ya2lu Zw0KPiAgZ3JvdXANCj4gID7CoCBtYWlsaW5nIGxpc3QNCj4gID7CoCA+ID7CoCA+IGlwdjZAaWV0 Zi5vcmcNCj4gID7CoCA+ID7CoCA+IEFkbWluaXN0cmF0aXZlDQo+ICBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ICA+wqAgPg0KPiAgPsKgID4N Cj4gID4NCj4gID7CoCA+ID4NCj4gID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+wqAgPiA+DQo+ICA+ wqAgPg0KPiAgPg0KPiAgPsKgID4gPg0KPiAgPg0KPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gID7CoCA+ID7C oCBJRVRGIElQdjYgd29ya2luZyBncm91cA0KPiAgbWFpbGluZw0KPiAgPsKgIGxpc3QNCj4gID4N Cj4gID4gPsKgIGlwdjZAaWV0Zi5vcmcNCj4gID7CoCA+ID7CoCBBZG1pbmlzdHJhdGl2ZSBSZXF1 ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ICA+wqAg PiA+DQo+ICA+DQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgPsKgID4gPg0KPiAgPsKgID4NCj4gID7CoCA+ DQo+ICA+DQo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgPsKgID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZw0KPiAgbGlzdA0KPiAgPsKgID4gaXB2NkBpZXRmLm9yZw0KPiAgPsKgID4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAgPsKgID4NCj4gID4NCj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICA+DQo+ICA+DQo+IA0KPiAN Cg0K From nobody Fri Apr 14 09:58:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C362E1294EE for ; Fri, 14 Apr 2017 09:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 yegXupMQEaTT for ; Fri, 14 Apr 2017 09:58:47 -0700 (PDT) Received: from nm10-vm3.bullet.mail.gq1.yahoo.com (nm10-vm3.bullet.mail.gq1.yahoo.com [98.136.218.94]) (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 29F4B12946C for <6man@ietf.org>; Fri, 14 Apr 2017 09:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1492189126; bh=EbJNIKVSiJ4Pduwo+GSCQBEZa2M2LMsZDh7UF/97UrI=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=amsywTvLkORTt8819tUNoKm7QfwQWeoyW/LkgdKlWu3NHoaYDnS64tdrvL1IOsO+hVKZZUvIU+VjWjYzJlOHTu/HoRhTfcH4imt9MQQ5t59F8saVFoqiuKUAg2wbFzNSGJ2W7V+wJz0bTkNDeDIy4cvO/jxZ+qDcahzQoaEJcHcvxA6b9dQXx02Tx9QjAV53P4Z9gMNw9pTWP8XUHj8aBlCpAVwUTeeHDxDpC8POjy4Fyeu/T2pyqIdHupNLlmDk5OaRGfspkvT8jCKSI7w7seu1fcxMJe0yCVuJugug0buQXCYK/6zIG64Xm1YvDffcDyq2b3qAUn/fEHAqRneZHg== Received: from [216.39.60.180] by nm10.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:58:46 -0000 Received: from [98.137.12.214] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:58:46 -0000 Received: from [127.0.0.1] by omp1022.mail.gq1.yahoo.com with NNFMP; 14 Apr 2017 16:58:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 726438.73914.bm@omp1022.mail.gq1.yahoo.com X-YMail-OSG: _tSE9SkVM1l5Ip_jEd4lF77reI17a7nCwuXd4q0p9H8AFwJN4ItbglpVZR7xiPE EE5R3T27GNq5r5a9TtNiHZf4InPDjwgRPdHFniz0_WDj39TRsXEOC09IvWZ6uw_2EiqzEYBykQj5 naWamrCnqMV1UID69rTNZjOJjfZz5MfseP339pFxycRF594.HKuYC8pbuokTIpVslkOgpLS_9pYR jcJwJQu54SBpaaar3WF3Q5k7P2EYiRBbmIKK0em6f657Dw1afKM2Qw_36u41SAfKIXYWk2qViw_O j.hpjoGAy0Mo3cvm9L8JrOb13JLjmnTfiXbqZKlZXLG1bvCMpfGVaHEpYOByTTWLfAsoxxAKRXOu m7a80PGw6A2qevItiLpAXt1Ka5oBM0t0LjlFbi3SMgxSI6V157VHGfNZZMRV9Oik5Rw5MAfiTvgu eTigfjydVJScsvMAzRWV_20IPl9EQXr.hoO2Yi5lXUYlt.9AUSWWk8FPEh5qYKKgyt.0qef2Vo3k qY_XG9ucq_RS2gRtFkAY2s.Rc7g7yJM9V1CCJ Received: from jws300065.mail.gq1.yahoo.com by sendmailws125.mail.gq1.yahoo.com; Fri, 14 Apr 2017 16:58:46 +0000; 1492189126.343 Date: Fri, 14 Apr 2017 16:58:46 +0000 (UTC) From: Reply-To: To: "nalini.elkins@insidethestack.com" , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Fred LTemplin Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Message-ID: <437749081.545891.1492189126005@mail.yahoo.com> Subject: RE: Deprecation of IPv6 atomic fragments (some good news) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <437749081.545891.1492189126005.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9408 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 16:58:50 -0000 Fred, Of course! Also, our Destination Option can be used for traffic other than TLS. In f= act, any IPv6 traffic. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/14/17, Templin, Fred L wrote: Subject: RE: Deprecation of IPv6 atomic fragments (some good news) To: "nalini.elkins@insidethestack.com" ,= "Fernando Gont" , "6man@ietf.org" <6man@ietf.org> Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" Date: Friday, April 14, 2017, 9:49 AM =20 Hi Nalini, =20 I don't want to be misunderstood - I support what you are proposing. In terms of tunneling, however, we are using TLS in some of our internal code and it looks like TLS provides a 64-bit sequence number that we are using for DPD (also reordering detection). =20 But, as I think you are implying, the tunnel is only one link in what may be an IPv6 path over many links. So, it could be that the raw IPv6 packet may still want to include one of your options in case duplication might occur somewhere along the remaining IPv6 path once the packet emerges from the tunnel. So, I think it is OK. =20 Thanks - Fred =20 > -----Original Message----- > From: nalini.elkins@insidethestack.com [mailto:nalini.elkins@insidethestack.com] > Sent: Friday, April 14, 2017 9:37 AM > To: nalini.elkins@insidethestack.com; Fernando Gont ; 6man@ietf.org; Templin, Fred L > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org > Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=20 > Fred, >=20 > Very interesting comments. >=20 > One thing, the Destination Option is set by the end host(s).=C2=A0 Of course, the devices in the middle, if those are doing the encapsulation > rather than the end host, could certainly examine the Destination Option. >=20 > As far as implementation, we are starting on code in the FreeBSD kernel at the end of next week & I have already had two other > requests for code samples.=C2=A0 I believe that at least one person (other than us!) has already started on implementation.=C2=A0 Let's see how > this rolls! >=20 > Thanks, >=20 > Nalini Elkins > CEO and Founder > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 >=20 > -------------------------------------------- > On Fri, 4/14/17, Templin, Fred L wrote: >=20 >=C2=A0 Subject: RE: Deprecation of IPv6 atomic fragments (some good news) >=C2=A0 To: "nalini.elkins@insidethestack.com" , "Fernando Gont" , > "6man@ietf.org" <6man@ietf.org> >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org" generation@tools.ietf.org> >=C2=A0 Date: Friday, April 14, 2017, 9:22 AM >=20 >=C2=A0 Hi Nalini, >=20 >=C2=A0 OK. But, tunnel encapsulations frequently >=C2=A0 include 32-bit Identification values >=C2=A0 (GRE, >=C2=A0 GUE, IPsec, others) which can be used for DPD so I was >=C2=A0 wondering if a >=C2=A0 similar facility was >=C2=A0 available for raw IPv6 packets. It sounds like with the >=C2=A0 PSN feature your document is providing there is >=C2=A0 opportunity for DPD but >=C2=A0 in a different way >=C2=A0 than widely-deployed tunneling systems currently do it. >=20 >=C2=A0 I think we had this same >=C2=A0 conversation at one of the recent meetings, but >=C2=A0 I am left wondering whether having two >=C2=A0 different ways of doing DPD will >=C2=A0 be >=C2=A0 confusing to implementers. Maybe what you have is better, >=C2=A0 but will >=C2=A0 widely-deployed networking gear be >=C2=A0 overhauled to pick up the new >=C2=A0 feature? >=20 >=C2=A0 Thanks - Fred >=20 >=C2=A0 > -----Original Message----- >=C2=A0 > From: nalini.elkins@insidethestack.com >=C2=A0 [mailto:nalini.elkins@insidethestack.com] >=C2=A0 > Sent: Friday, April 14, 2017 9:00 AM >=C2=A0 > To: nalini.elkins@insidethestack.com; >=C2=A0 Fernando Gont ; >=C2=A0 6man@ietf.org; >=C2=A0 Templin, Fred L >=C2=A0 > >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.ietf.org >=C2=A0 > Subject: RE: Deprecation of IPv6 atomic >=C2=A0 fragments (some good news) >=C2=A0 > >=C2=A0 > You can use the sequence number (PSN) in >=C2=A0 combination with the other fields >=C2=A0 > >=C2=A0 > PSNTP=C2=A0 =C2=A0 =C2=A0 : Packet Sequence Number >=C2=A0 This Packet >=C2=A0 > PSNLR=C2=A0 =C2=A0 =C2=A0 : Packet >=C2=A0 Sequence Number Last Received >=C2=A0 > DELTATLR >=C2=A0 : Delta Time Last Received >=C2=A0 > DELTATLS : >=C2=A0 Delta Time Last Sent >=C2=A0 > >=C2=A0 > to get quite a good idea of duplicate >=C2=A0 packets.=C2=A0=C2=A0 You can also differentiate duplicate packets >=C2=A0 from retransmissions. >=C2=A0 > >=C2=A0 > Thanks, >=C2=A0 > >=C2=A0 > Nalini Elkins >=C2=A0 > CEO and >=C2=A0 Founder >=C2=A0 > Inside Products, Inc. >=C2=A0 > www.insidethestack.com >=C2=A0 > (831) 659-8360 >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------- >=C2=A0 > On Fri, 4/14/17, Templin, Fred L >=C2=A0 wrote: >=C2=A0 > >=C2=A0 >=C2=A0 Subject: >=C2=A0 RE: Deprecation of IPv6 atomic fragments (some good news) >=C2=A0 >=C2=A0 To: "nalini.elkins@insidethestack.com" >=C2=A0 , >=C2=A0 "Fernando Gont" , >=C2=A0 > "6man@ietf.org" >=C2=A0 <6man@ietf.org> >=C2=A0 >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generation@tools.i= etf.org" >=C2=A0 =C2=A0 > >=C2=A0 generation@tools.ietf.org> >=C2=A0 >=C2=A0 Date: Friday, April 14, 2017, 8:53 AM >=C2=A0 > >=C2=A0 >=C2=A0 Oh, I just looked >=C2=A0 and saw that >=C2=A0 >=C2=A0 the option presents >=C2=A0 16-bit Packet Sequence Numbers. >=C2=A0 >=C2=A0 I was >=C2=A0 thinking 32 for use cases such as >=C2=A0 > >=C2=A0 Duplicate Packet Detection. Is there any way to >=C2=A0 >=C2=A0 get a 32-bit Identification? >=C2=A0 > >=C2=A0 >=C2=A0 Thanks - Fred >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 -----Original >=C2=A0 >=C2=A0 Message----- >=C2=A0 >=C2=A0 > From: ipv6 [mailto:ipv6-bounces@ietf.org] >=C2=A0 >=C2=A0 On Behalf Of Templin, Fred L >=C2=A0 >=C2=A0 > Sent: >=C2=A0 > >=C2=A0 Friday, April 14, 2017 8:50 AM >=C2=A0 >=C2=A0 > >=C2=A0 To: nalini.elkins@insidethestack.com; >=C2=A0 >=C2=A0 Fernando Gont ; >=C2=A0 >=C2=A0 6man@ietf.org >=C2=A0 >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tools.= ietf.org >=C2=A0 >=C2=A0 > Subject: RE: Deprecation of IPv6 >=C2=A0 atomic >=C2=A0 >=C2=A0 fragments (some good news) >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > Very >=C2=A0 good. Thanks. >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > Fred >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 -----Original Message----- >=C2=A0 >=C2=A0 > > >=C2=A0 From: nalini.elkins@insidethestack.com >=C2=A0 >=C2=A0 [mailto:nalini.elkins@insidethestack.com] >=C2=A0 >=C2=A0 > > Sent: Friday, April 14, 2017 >=C2=A0 8:45 >=C2=A0 >=C2=A0 AM >=C2=A0 >=C2=A0 > >=C2=A0 > To: Fernando Gont ; >=C2=A0 >=C2=A0 6man@ietf.org; >=C2=A0 >=C2=A0 Templin, Fred L >=C2=A0 >=C2=A0 > > Cc: draft-ietf-6man-deprecate-atomfrag-generation@tool= s.ietf.org >=C2=A0 >=C2=A0 > > Subject: RE: Deprecation of >=C2=A0 IPv6 >=C2=A0 >=C2=A0 atomic fragments (some good >=C2=A0 news) >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > Fred, >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > > For sequence numbers in >=C2=A0 IPv6, >=C2=A0 >=C2=A0 You may wish to look at >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 > https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option= / >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 > which was >=C2=A0 >=C2=A0 on the telechat agenda >=C2=A0 for Thursday.=C2=A0=C2=A0 We will be >=C2=A0 > >=C2=A0 addressing all the comments & hope to be rolling >=C2=A0 quite >=C2=A0 >=C2=A0 soon. >=C2=A0 > >=C2=A0 > > >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 Thanks, >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 Nalini Elkins >=C2=A0 >=C2=A0 > > CEO and >=C2=A0 Founder >=C2=A0 >=C2=A0 > > Inside Products, >=C2=A0 Inc. >=C2=A0 >=C2=A0 > > >=C2=A0 www.insidethestack.com >=C2=A0 >=C2=A0 > > >=C2=A0 (831) 659-8360 >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 -------------------------------------------- >=C2=A0 >=C2=A0 > > On Fri, 4/14/17, Templin, Fred >=C2=A0 L >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 wrote: >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 Subject: RE: Deprecation of IPv6 atomic fragments (some >=C2=A0 good >=C2=A0 >=C2=A0 news) >=C2=A0 > >=C2=A0 > >=C2=A0 To: "Fernando >=C2=A0 > >=C2=A0 Gont" , >=C2=A0 >=C2=A0 "6man@ietf.org" >=C2=A0 >=C2=A0 <6man@ietf.org> >=C2=A0 >=C2=A0 > >=C2=A0 Cc: "draft-ietf-6man-deprecate-atomfrag-generati= on@tools.ietf.org" >=C2=A0 > >=C2=A0 =C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > generation@tools.ietf.org> >=C2=A0 >=C2=A0 > >=C2=A0 Date: Friday, April 14, >=C2=A0 2017, 8:40 >=C2=A0 >=C2=A0 AM >=C2=A0 > >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 Hi >=C2=A0 >=C2=A0 Fernando, >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 With the deprecation of atomic fragments, is >=C2=A0 >=C2=A0 > >=C2=A0 there another way to >=C2=A0 include >=C2=A0 >=C2=A0 > >=C2=A0 an >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 Identification value in the header of an IPv6 packet? Do >=C2=A0 >=C2=A0 we >=C2=A0 >=C2=A0 > > >=C2=A0 need a new >=C2=A0 >=C2=A0 > >=C2=A0 extension >=C2=A0 header or destination >=C2=A0 >=C2=A0 > > >=C2=A0 option for that? >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 Thanks >=C2=A0 >=C2=A0 - >=C2=A0 >=C2=A0 > > >=C2=A0 Fred >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 -----Original >=C2=A0 >=C2=A0 > > >=C2=A0 Message----- >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 >=C2=A0 > From: ipv6 [mailto:ipv6-bounces@ietf.org] >=C2=A0 >=C2=A0 > >=C2=A0 On Behalf Of Fernando >=C2=A0 Gont >=C2=A0 >=C2=A0 > >=C2=A0 > Sent: >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 Friday, April 14, 2017 8:28 AM >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 >=C2=A0 > To: 6man@ietf.org >=C2=A0 >=C2=A0 > >=C2=A0 > Cc: draft-ietf-6man-deprecate-atomfrag-generat= ion@tools.ietf.org >=C2=A0 >=C2=A0 > >=C2=A0 > Subject: Deprecation of >=C2=A0 IPv6 >=C2=A0 >=C2=A0 atomic >=C2=A0 > >=C2=A0 > >=C2=A0 fragments (some good >=C2=A0 > >=C2=A0 news) >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 >=C2=A0 > >=C2=A0 Folks, >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > Thought it might be >=C2=A0 good >=C2=A0 >=C2=A0 feedback for the >=C2=A0 >=C2=A0 > >=C2=A0 group. Juniper >=C2=A0 >=C2=A0 published a >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 vulnerability >=C2=A0 advisory with patches >=C2=A0 >=C2=A0 for the issue >=C2=A0 discussed >=C2=A0 >=C2=A0 > >=C2=A0 in >=C2=A0 >=C2=A0 RFC8021: >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > > >=C2=A0 >=C2=A0 > Besides providing >=C2=A0 >=C2=A0 > >=C2=A0 the >=C2=A0 > >=C2=A0 rationale for the change in rfc2460bis and >=C2=A0 >=C2=A0 > >=C2=A0 > RFC7915, this kind of >=C2=A0 thing >=C2=A0 >=C2=A0 was one of the >=C2=A0 >=C2=A0 > >=C2=A0 motivations for >=C2=A0 >=C2=A0 working on >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > such RFC. >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 > Thanks! >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > Cheers, >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 >=C2=A0 > >=C2=A0 -- >=C2=A0 >=C2=A0 > >=C2=A0 > Fernando >=C2=A0 >=C2=A0 Gont >=C2=A0 >=C2=A0 > > >=C2=A0 > e-mail: fernando@gont.com.ar >=C2=A0 >=C2=A0 > >=C2=A0 || fgont@si6networks.com >=C2=A0 >=C2=A0 > >=C2=A0 > PGP Fingerprint: 7809 >=C2=A0 84F5 >=C2=A0 >=C2=A0 322E 45C7 F1C9 >=C2=A0 >=C2=A0 > >=C2=A0 3945 96EE A9EF >=C2=A0 >=C2=A0 D076 FFF1 >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 >=C2=A0 > >=C2=A0 > IETF IPv6 working >=C2=A0 group >=C2=A0 >=C2=A0 mailing list >=C2=A0 >=C2=A0 > >=C2=A0 > ipv6@ietf.org >=C2=A0 >=C2=A0 > >=C2=A0 > Administrative >=C2=A0 Requests: https://www.ietf.org/mailman/listinfo/ipv6 >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 >=C2=A0 > >=C2=A0 IETF IPv6 working group >=C2=A0 mailing >=C2=A0 >=C2=A0 list >=C2=A0 > >=C2=A0 > >=C2=A0 ipv6@ietf.org >=C2=A0 >=C2=A0 > >=C2=A0 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >=C2=A0 >=C2=A0 > > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 >=C2=A0 > > >=C2=A0 >=C2=A0 > >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 >=C2=A0 > IETF IPv6 working group mailing >=C2=A0 list >=C2=A0 >=C2=A0 > ipv6@ietf.org >=C2=A0 >=C2=A0 > Administrative Requests: https://www.ietf.org/mailman/li= stinfo/ipv6 >=C2=A0 >=C2=A0 > >=C2=A0 > >=C2=A0 -------------------------------------------------------------------- >=C2=A0 > >=C2=A0 > >=20 >=20 =20 =20 From nobody Fri Apr 14 11:03:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1C1294F8 for ; Fri, 14 Apr 2017 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 yODPTLu1YxwM for ; Fri, 14 Apr 2017 11:03:17 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 E1C8C12783A for ; Fri, 14 Apr 2017 11:03:16 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l28so54183586wre.0 for ; Fri, 14 Apr 2017 11:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mPVoINKMnBlWTintXIRjpETcc/hX6E5/jy7yd7wd8lo=; b=OmdvUwB4tHax1aZmy7I8awmKoco7uV3M9h3Eg2QmogBRx3GTCyrkaGGBwR1hpc/v1E XtgEETZ61UKFJOHMH1JspOXUQCvsP9nwfpWQaPRuxVSuC+kusUvG2kZprX7KTGliW5fJ xpReztdDyKd1j687JeRaoxH81/M9MjAP6RMeOtLVPBw/W/DkpkZZBKJL64w8R3dBtoXC +O2+PKJecQral5eEE1Z5c1H5+EhD2hc4f2YAL4Lx4/DgvK7k9+txj/eZT6u2Vs6RNuTn EMBw3Ogj56vGTTNs1f4zHaGC8CsNug3uIA8aLmqcW1rgku5HRqeUDEcbk0ZJSB62nOaa 1y6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mPVoINKMnBlWTintXIRjpETcc/hX6E5/jy7yd7wd8lo=; b=CZjGYofJ+Zc1tEC+2V1FuQpwO1m3raEzNe+9lcnyVXc7ZKVpwO1uImgPNAZXnJ2W31 vQEncaZfyY5NJmb3UoUFGr1Ddfdy2wn/sPMoQ3PjiETeBFihdYuxtsM11Kp6bdOi8cSc oTuiEoUVyXJm7oKJ724f9EwB+fwlPv2Fr59GdTXyg7PDWJHT3zCWfuajvUHCGB1vyRrQ JxLW2FCW2wvVkXVpYFDrzC3PsnTXxGTTSvxB0OIbeGQNdyl+nXAZPh9rCMeqTtuUtd4L 9khjAH4YmFl+CXlAu4eQ2j+3hbYWHSnrPBLFEE9T+CHQb7S45avzT991REqavBeYnoWA 7QCQ== X-Gm-Message-State: AN3rC/49NGEPQLTyzVLqse2dQi8pSaFdZztLZr3018FcpmHYW9GRShcf 4n2eUAERTNjpfw== X-Received: by 10.223.164.65 with SMTP id e1mr8835934wra.105.1492192995465; Fri, 14 Apr 2017 11:03:15 -0700 (PDT) Received: from 213.66.20.149.in-addr.arpa (213.66.20.149.in-addr.arpa. [149.20.66.213]) by smtp.gmail.com with ESMTPSA id 43sm3050924wry.31.2017.04.14.11.03.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 11:03:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Route Information Options in IPv6 Neighbor Discovery From: Fred Baker In-Reply-To: Date: Fri, 14 Apr 2017 11:03:16 -0700 Cc: Fred Templin , james woodyatt , "ipv6@ietf.org" , Dave Thaler Content-Transfer-Encoding: quoted-printable Message-Id: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:03:19 -0000 > On Apr 14, 2017, at 4:56 AM, Mikael Abrahamsson = wrote: >=20 > On Wed, 12 Apr 2017, Templin, Fred L wrote: >=20 >> Please see below for an updated version of "Route Information Options >> in IPv6 Neighbor Discovery". Note that the title is changed since the = last >> version because we are now allowing RIOs to appear in other IPv6 ND >> messages besides just Redirects. In particular, we are now allowing = RIOs to >> also appear in Neighbor Solicitation (NS) and Advertisement (NA) = messages. >>=20 >> The rationale for leveraging NS/NA instead of RS/RA is given in = Section 4.2.6. >> The rest of document was updated to address the helpful input = received >> from colleagues at IETF98. Please review and post comments to the = list >> and/or the authors. >=20 > SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would be in scope for this documents security section. For instance, = what would an SAVI enabled L2 switch that inspects ND entries do when it = sees this RIO entry in ND? As specified, I think it would ignore them. It looks at the NA to = determine what {IP address, MAC address} or {IP address, MAC address, = Port #} association it should enforce. It has no illusion that this is = the only data present.= From nobody Fri Apr 14 11:04:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1F81294F5 for ; Fri, 14 Apr 2017 11:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 82F-bzpDSEQ2 for ; Fri, 14 Apr 2017 11:04:06 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 B78B812783A for ; Fri, 14 Apr 2017 11:04:05 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id l28so54192001wre.0 for ; Fri, 14 Apr 2017 11:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q+WSjsSfbwjMNEaWyPoKevwoST3h30x+sknTEn7VeIs=; b=o2x3bDw3ApwmqSeLbbqU4Y5JtADE1lQBgAQmPhSK8iJMRFsfMNVsy3ROA4/6UJH6uB YGowNbG6pWliDEp0ALafTgiAfyveM15uP85nGxAGtzQuZ6Xx4/zXs4fsF96Plr8mocEu QQabgvGSKB9+g3owySWZAIfXG0AFxynRpoo6lvxKnq7Rd8qMHybkPBXIoTiZFiRyUw1A PJU+mcsROOMsOHI2DHNrrK7W6in95ic9FMvQU74kOgbIuuAAkuFJ5fBnekk87TZR60T4 FGPmQfpJVbkZcht76+ztFBF6tn3EE82g7tNmYxgOmvY9kKdKsVdT/X6JoY1x3507MFUZ SlOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q+WSjsSfbwjMNEaWyPoKevwoST3h30x+sknTEn7VeIs=; b=rTag39G46OsXyn7UK/s/R/Y0V6OCDUesETrUosb/14ZPBXDsIpMBpuk1bLZ7LiC2jR yiTL+fUo0UE3vzXK/VqNAfV7P08J0EPLieCcQIs07sSiUfKRaEiwk+aKhsZyj2b/QoIQ 2SZ18yH0ryqW7dtI/mLolbQcLgl83dJAC7pgj9QxQiSyKS3ToCF/0/LDp5fTYHa5krgG XS7/KutxGTDxOKNHHbNuoz5JDBT8v/tX3bywTnOAxhVZ+II2mwMFqY1a9Dd7QH7wbJxk pxUEn+98frD2UwCGemY9sJzhPcE0urCNV1uUiNef9uXJpB75U3nFy8v8BGWAgOrajb3y fLqw== X-Gm-Message-State: AN3rC/7hwC27qoCHp2wYPgYAFjrnvqcdN0MBc05MVuxSaHTlkM2TuwgO mNC+VWnWaZ82NA== X-Received: by 10.223.145.106 with SMTP id j97mr7843125wrj.129.1492193044296; Fri, 14 Apr 2017 11:04:04 -0700 (PDT) Received: from 213.66.20.149.in-addr.arpa (213.66.20.149.in-addr.arpa. [149.20.66.213]) by smtp.gmail.com with ESMTPSA id 43sm3050924wry.31.2017.04.14.11.04.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 11:04:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Route Information Options in IPv6 Neighbor Discovery From: Fred Baker In-Reply-To: <2fa25981cbc141598852feb0b67a4f77@XCH15-06-08.nw.nos.boeing.com> Date: Fri, 14 Apr 2017 11:04:06 -0700 Cc: Mikael Abrahamsson , james woodyatt , "ipv6@ietf.org" , Dave Thaler Content-Transfer-Encoding: quoted-printable Message-Id: References: <2fa25981cbc141598852feb0b67a4f77@XCH15-06-08.nw.nos.boeing.com> To: Fred Templin X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:04:08 -0000 > On Apr 14, 2017, at 8:23 AM, Templin, Fred L = wrote: >=20 > Hi Mikael, >=20 >> -----Original Message----- >> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >> Sent: Friday, April 14, 2017 4:56 AM >> To: Templin, Fred L >> Cc: ipv6@ietf.org; james woodyatt ; Dave Thaler = >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery >>=20 >> On Wed, 12 Apr 2017, Templin, Fred L wrote: >>=20 >>> Please see below for an updated version of "Route Information = Options >>> in IPv6 Neighbor Discovery". Note that the title is changed since = the last >>> version because we are now allowing RIOs to appear in other IPv6 ND >>> messages besides just Redirects. In particular, we are now allowing = RIOs to >>> also appear in Neighbor Solicitation (NS) and Advertisement (NA) = messages. >>>=20 >>> The rationale for leveraging NS/NA instead of RS/RA is given in = Section 4.2.6. >>> The rest of document was updated to address the helpful input = received >>> from colleagues at IETF98. Please review and post comments to the = list >>> and/or the authors. >>=20 >> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would >> be in scope for this documents security section. >=20 > Can you send a pointer to the document? https://tools.ietf.org/html/rfc6620 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) https://tools.ietf.org/html/rfc6959 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 = bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) https://tools.ietf.org/html/rfc7039 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) https://tools.ietf.org/html/rfc7219 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7219) https://tools.ietf.org/html/rfc7513 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) https://tools.ietf.org/html/rfc8074 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) From nobody Fri Apr 14 11:21:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4B6129515 for ; Fri, 14 Apr 2017 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 KsUCztPkg3Kg for ; Fri, 14 Apr 2017 11:21:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8650D129434 for <6man@ietf.org>; Fri, 14 Apr 2017 11:21:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 55EFEE1E5; Fri, 14 Apr 2017 14:46:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AAE4D636BB; Fri, 14 Apr 2017 14:21:54 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" cc: "nalini.elkins\@insidethestack.com" , Fernando Gont , "6man\@ietf.org" <6man@ietf.org>, "draft-ietf-6man-deprecate-atomfrag-generation\@tools.ietf.org" Subject: Re: Deprecation of IPv6 atomic fragments (some good news) In-Reply-To: <51f620f289f64e90a334310c1a17d97d@XCH15-06-08.nw.nos.boeing.com> References: <1027338590.520049.1492185610385.ref@mail.yahoo.com> <1027338590.520049.1492185610385@mail.yahoo.com> <51f620f289f64e90a334310c1a17d97d@XCH15-06-08.nw.nos.boeing.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 18:21:56 -0000 --=-=-= Content-Type: text/plain Templin, Fred L wrote: > OK. But, tunnel encapsulations frequently include 32-bit Identification > values (GRE, GUE, IPsec, others) which can be used for DPD so I was > wondering if a similar facility was available for raw IPv6 packets. It > sounds like with the PSN feature your document is providing there is > opportunity for DPD but in a different way than widely-deployed > tunneling systems currently do it. You could insert an AH header with a reserved SPI# if you control the end points such that they can be verified to be willing to skip that. I'd rather like to update the IPv6 host requirements to say that unknown AH SPI# are to be skipped as if not even there. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljxE0IACgkQgItw+93Q 3WWvPAgAicZxmlOM4EXpFr+8eD1/wHOhSDO7BnS11xg0fvmJwaXv4FhmnjEQe1SF TReMokS1HXuC7etdoSzSqWU0b+fBfu0M7U+4dVMZ4+NZfmVuRWcpBpzbnIpyAu2F fxHEEo6g2gdPqdjblMXQmdqw4BdFIxOYBUilvlXctYB54bhDiVI+BFuYFx4AitFt PgZunhyCmflGxr9C/Ep34b8HyrHzfIVapfl+HsrS6EfYOvu/iWG/2oCBxEVfssoG 3Q4/Y/JauLaC2LRt71lNexjhh8SUnhUByA5kQuvZU8WSkSkh+TO2j9OyQ/hbIioj G2ILOAsjClXwnWcsc9LlBWxiuFZhlw== =qU6c -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 14 18:08:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1351129B20 for ; Fri, 14 Apr 2017 18:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oAuvv06_tYFg for ; Fri, 14 Apr 2017 18:08:23 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 92176129AA3 for ; Fri, 14 Apr 2017 18:08:23 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id f10so32245062uaa.2 for ; Fri, 14 Apr 2017 18:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=92uR9IwLIUTcZkf+haMcmA7i7RcDiptfxnUskBL8d9A=; b=JYCrQ0uT5Ltgdr0O17B8DrswuJSc10F937Ix57QtXILs32I42y/5jPWA2560UQ2jd/ JDdbaJgm78Cyr4//b2MHeHSyzNCIPj3rk+tl93qhWQIoLCyM0iQGEaZYXMpbUkfuHLXe C5PNzkDvLgOoDhlU9ihhcDI+0fjqx/xW6YI6WDA1XEsec/jXXM1/9j7rkhPNXGrfNGDu merGdxusZQUR2qusuyTGcg8pviIxLL9vG/Cg1qzR1IhDgHhws95YO/49zjEJRP9XOigb C3R+5BBzCYRx66R7ExQSHmfBM26Z8hLdYUEzl7IChzsHgoEbrtgtLUQEekNp1stk0C3+ D1aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=92uR9IwLIUTcZkf+haMcmA7i7RcDiptfxnUskBL8d9A=; b=hp8idNxDgleT2qvjhyeayTfT8p84DwiHs1GaKOd4GYZQi4G8BRExLzXlhKxxQSO+Qv HAaA7glTChUeOdrz++NKaNPZRZBjf37ug5pF+5hc/Fipc0UzgfTDwHKCrz+b/COsFk4m gt85W12iekaETggTw/DX/O+ctlcrOk3AJxJmzAO5zqmAGK/7GaJ7Tgk18Se566DN6Ybo yx144DUMOLFX7Cmi3gRp1xn7gGn0HVVpZCeCHvHvtDL/j9HyzM514hkJoV1NNyAO9RDE iymvbhcyk2onlPSHmvq+i/KoNzIg6tMDz/0PQniDMetcw/+pGF/jEZ69BF20FVXJFSp3 jKKw== X-Gm-Message-State: AN3rC/4mXNVfBv6YP8GyF8a4LOEY7acmzMBzQ9JHNrpVcaB0SjEg+rA7 27b+M8R57usjXNUqOUXdmp7UmyFnVvDf X-Received: by 10.176.8.21 with SMTP id a21mr4442695uaf.141.1492218502627; Fri, 14 Apr 2017 18:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Fri, 14 Apr 2017 18:07:52 -0700 (PDT) From: Mark Smith Date: Sat, 15 Apr 2017 11:07:52 +1000 Message-ID: Subject: RFC1122 - does it really apply to IPv6 hosts? To: 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 01:08:25 -0000 Or how much of it applies to IPv6 hosts? The reason I'm curious is because I wondered for a long time whether IPv6 nodes supported either of the strong or weak ES model, or whether IPv6 had selected only one of those models. My confusion had come about for a few reasons. - The one place I did find something that seemed to be somewhat related to strong/weak host model support in an IPv6 RFC is in RFC4291(bis), "IP Version 6 Addressing Architecture", "2.1. Addressing Model": "IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node." The first sentence seems to be suggesting strong ES model, however the second sentence seems to be then suggesting weak ES model. - RFC1122, being written in 1989 is before any specific IPv6 work as far as I know and where it is talking about Internet Protocols, only explicitly covers IPv4 and related protocols i.e., ARP. Understandably, it isn't written to be Internet Protocol version agnostic. - I've never come across any references to RFC1122 in any IPv6 and specifically any base IPv6 protocol RFCs. One place it could be expected to appear if it was relevant would be in RFC6434, "IPv6 Node Requirements", yet it doesn't. People have said in emails that RFC1122 applies to IPv6, and I'm fine with that. However they are informal statements, so I'm wondering if there is anywhere formal that says so? One thing that has prompted me to again wonder about it is this draft: "IPv6 Prefix Delegation for Hosts" https://tools.ietf.org/html/draft-templin-v6ops-pdhost-05 This draft is having to deal with a host following either of the weak or strong ES models. Where it gets complicated is in reference to things like MLD or ND DAD and when and how to perform them. It would be simpler in scenarios such as the above if all IPv6 hosts were only weak ES model or only strong ES model. Thanks very much, Mark. From nobody Fri Apr 14 20:02:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C3E129527 for ; Fri, 14 Apr 2017 20:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 akKldOf4ib67 for ; Fri, 14 Apr 2017 20:02:01 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 839F7127599 for ; Fri, 14 Apr 2017 20:02:01 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id s16so46641441pfs.0 for ; Fri, 14 Apr 2017 20:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=EAF2lnAiTBeL+OE7Hl+SuUqwK/Bs7f/71q2kehtsT4Q=; b=CM5+c5b9NezGa0QabWc1fTvWSevCUFg4kcKHv8W2U6wKMP2n15q3Zeu90TWqRb5Ln0 4Qi/9g8n5VoakJFQq5WoUypNQZaw8ildyhx6kGe2IlQpBvvBnIBtG7uDxxOQ3IO3QLCX qY80/kOdukEuYdE5k5wJgLttI6G63iQTtFM8Z6bIspEu/JdwB25TC1TTYxnz8wSf67Uh Szu3j9p+yhdYVk+02peWJey1fFzcl+xkH+w6Kif8Va/LjkfwAqGvsDNCzwI4UrT3yDVf P/Solpakir2dJYrFQkeA80xkH2uEa5MoiDe3giVN9A9uUEh+4O1rv+cSZwPk9R+e6ex3 7tOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EAF2lnAiTBeL+OE7Hl+SuUqwK/Bs7f/71q2kehtsT4Q=; b=YaeUalmjf7WnujIkqlnlPUxs5ETO3CNkTfWgdaCaBXmDAAOR6g0fRFLTM1oOzbYbsc QLkjhFEtLBP+fUGKG0nhl4MAgTQbCEvV8ZFYxYGDCxycUqww39dUWALcwyM/IhTsfYJZ xyDV10554oDnxnui/H6oHBnvtnjnjMbXUFvMwv02XmjEY2OOPHhnGrcdJcr/wWt7DZG4 Ipam4QRWD9LkS/9gbMtueivSJlTNh5VCiBIKfo0dRzf9Mu9pxiHxMYDWsMAsZvVvKxEI Q/RoC715gL2uTixGuTc6AorTMOut1RtlHunETfTEye5BB7uO7P5EnJ9KK4kjGk7azvL0 T7/g== X-Gm-Message-State: AN3rC/4n9wbszYHxcDXzecFKp4Tovt4MrI7D0HnJpIlWUJ5PtM72ClEC qgr70CIc6IKqcA== X-Received: by 10.84.211.137 with SMTP id c9mr935320pli.8.1492225321136; Fri, 14 Apr 2017 20:02:01 -0700 (PDT) Received: from ?IPv6:2406:e001:38c5:1:28cc:dc4c:9703:6781? ([2406:e001:38c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 133sm5415670pfy.106.2017.04.14.20.01.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 20:02:00 -0700 (PDT) Subject: Re: RFC1122 - does it really apply to IPv6 hosts? To: Mark Smith , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <454c1f9f-6bc9-38c4-66c3-f42b0af1abee@gmail.com> Date: Sat, 15 Apr 2017 15:02:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:02:03 -0000 Mark, We included some explicit verbiage about this in https://tools.ietf.org/html/rfc8028#section-1.1 because it seemed relevant. I don't think this is a correct RFC2119 usage, but I think the answer to your question is a definite MAYBE. Brian On 15/04/2017 13:07, Mark Smith wrote: > Or how much of it applies to IPv6 hosts? > > The reason I'm curious is because I wondered for a long time whether > IPv6 nodes supported either of the strong or weak ES model, or whether > IPv6 had selected only one of those models. > > My confusion had come about for a few reasons. > > > - The one place I did find something that seemed to be somewhat > related to strong/weak host model support in an IPv6 RFC is in > RFC4291(bis), "IP Version 6 Addressing Architecture", "2.1. > Addressing Model": > > "IPv6 addresses of all types are assigned to interfaces, not nodes. > An IPv6 unicast address refers to a single interface. Since each > interface belongs to a single node, any of that node's interfaces' > unicast addresses may be used as an identifier for the node." > > The first sentence seems to be suggesting strong ES model, however the > second sentence seems to be then suggesting weak ES model. > > > - RFC1122, being written in 1989 is before any specific IPv6 work as > far as I know and where it is talking about Internet Protocols, only > explicitly covers IPv4 and related protocols i.e., ARP. > Understandably, it isn't written to be Internet Protocol version > agnostic. > > > - I've never come across any references to RFC1122 in any IPv6 and > specifically any base IPv6 protocol RFCs. One place it could be > expected to appear if it was relevant would be in RFC6434, "IPv6 Node > Requirements", yet it doesn't. > > > People have said in emails that RFC1122 applies to IPv6, and I'm fine > with that. However they are informal statements, so I'm wondering if > there is anywhere formal that says so? > > One thing that has prompted me to again wonder about it is this draft: > > "IPv6 Prefix Delegation for Hosts" > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-05 > > This draft is having to deal with a host following either of the weak > or strong ES models. Where it gets complicated is in reference to > things like MLD or ND DAD and when and how to perform them. It would > be simpler in scenarios such as the above if all IPv6 hosts were only > weak ES model or only strong ES model. > > Thanks very much, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Apr 14 20:10:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4D129B7F for ; Fri, 14 Apr 2017 20:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 ZKoUUj7ig9Da for ; Fri, 14 Apr 2017 20:10:09 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 C35F6127A91 for ; Fri, 14 Apr 2017 20:10:08 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u2so3928099wmu.0 for ; Fri, 14 Apr 2017 20:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5TQTY1ZC5q037x6pUmmZuMSdBKR81hEEZ7nTaqI/9xc=; b=nTlxZ99ehpbqzgd9QUmzwbI1La84gxiMbSn34oMTKg5C9qWvajQOxM7mKXNpcwAArM UQi+8XcB7c7IGi1xZAJ1/2et5mtM+uhvt8dsq4OF090aE0ZSnVqtyEUFRnu8V0WQwyNx +UD5AQOOE5ms6mwfvng1UTncGUxLCGShPU43/sW7Po9hWEUAnsSo3ofA0xJohNeHpRC2 D9nyMsIUjBcGOwEs8OfTFjWCFhac+witZl4QFpNjSi9O0x+aII1ENbw2QiWLEYdNuewS HWM65176t5of+dZJh+c6d1x8rn/nUkRSpSwacUviiDyy3VMzmMphilqWB9EgV68BTBMP zG4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5TQTY1ZC5q037x6pUmmZuMSdBKR81hEEZ7nTaqI/9xc=; b=nuCMVM5YShZUvboCsVN9Nm67XMfBQxZTR40A9gFNRuslNSETWfQLYuUmUOxT7CTaDk yJOjp8hF52d+3JXAbrjdw32efUxYTADysVpaoAhj1q5f1VzGlm5eJGxw29CyoPg77ThR PsJCPO7py1GvHqCbnZH8cqSD5689KzBbE6aZMTGsuhaGa/3R7wvxExC40HRPzL3EBiar vb20r6gl6wQZxHJN67eTVteTeaZLjGo7PVLuTqASg4hzY0XI4048iOj+SY5BiJkLGCVz pM58NVT4zK7lUIxAxcTaOE8WvbRNb4wq1yvayyusWYBgJMHOcYRQqjyFkd7t42v6rIi+ ywww== X-Gm-Message-State: AN3rC/7oWoztNo1NOsBuoJXHX3R3UQ21n74LyMdbE5JJpl6dtv1Ucqyf M0eOD0O0QmMezw== X-Received: by 10.28.59.134 with SMTP id i128mr926624wma.49.1492225807339; Fri, 14 Apr 2017 20:10:07 -0700 (PDT) Received: from 246.66.20.149.in-addr.arpa (246.66.20.149.in-addr.arpa. [149.20.66.246]) by smtp.gmail.com with ESMTPSA id 13sm832135wmt.22.2017.04.14.20.10.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 20:10:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC1122 - does it really apply to IPv6 hosts? From: Fred Baker In-Reply-To: Date: Fri, 14 Apr 2017 20:10:10 -0700 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:10:10 -0000 > On Apr 14, 2017, at 6:07 PM, Mark Smith = wrote: >=20 > The reason I'm curious is because I wondered for a long time whether > IPv6 nodes supported either of the strong or weak ES model, or whether > IPv6 had selected only one of those models. You might take a look at the comments on the topic in RFC 7039, where = Joe Touch (IIRC) brought the question up. My take is that neither IPv4 = nor IPv6 really uses either as described there. The weak model says that = any address may be used as a source address on any interface; to my = knowledge, a host only originates messages using a given address on the = interface it is assigned to. The strong model, in 1122, says that the = host acts as if it were some number of virtual hosts, one per address, = and the virtual host only uses the interface that address is on. Again, = AFAIK, that is not the case in current equipment.= From nobody Fri Apr 14 20:15:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA761288B8; Fri, 14 Apr 2017 20:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 IZNdlCALAFU2; Fri, 14 Apr 2017 20:15:25 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 9FE531272E1; Fri, 14 Apr 2017 20:15:25 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id g23so2560276pfj.1; Fri, 14 Apr 2017 20:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xQYRH6gGm+ng4HH5TG5Np/RjwEoi2ijnX/n50KO/n5c=; b=YS+gJxZD7THlT9/+Cxb/idwhV8yk3qJ4DeovnkHPq9DvAxQo/5Vdjz6Tk2+LCwKebw XEmXcuL3kOSErrbs4V+dcVs6jUsWgCNTpH7+3NbcXyRIxWx7UtY0UvWt0Sv8tpM/IC4t CXg6AJnRB/N/lNOOFBUSV04XTjcUsJibxxergr04VT/XPYom+TfcZ9nuzqL+YTUQSN1z pIOlycK/4fDNxJUauoBkQyj0syy7W6PBalEaB1j5YBGAu4GrCRAflHK//fx0W0JtPfzz cE/G71ZNkaYvqM/aWjNPBKCL15WXrMztBneXwDXGxw52/6uE058loMAmnMQ6kyO54Xat 1AxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xQYRH6gGm+ng4HH5TG5Np/RjwEoi2ijnX/n50KO/n5c=; b=kUH4cRjFOPPmJQXGXvCgftl8fVRUPkDrHtuHiLGyGnRdVJ5MBEmUuo4nzFc5Z+jijV T6V696DkrqLw8wVZu1StgtDF5+xjpK4ZHezHqei1vH0lcLlAFOagTX2xwqLWXXyu4Bug YFRTYbgorHncvtK50HyvWRyOX1+0WZGSSBJFrmpeZwMEl2vnG7ZqbOumUpKlVTPuQuQi CBoVgtzHMX7z6YLA6H3wCszsJ8sYgV0H2NGYS3k5UPLQr68Mu06Q8EHIl8dkM/YOWwVc G48tZd2Eom8h1z37UyrwPREamE2Fn3p+yLogbCoGCSKfbobWNikW7rN08sbXjzFIjmzA LVYQ== X-Gm-Message-State: AN3rC/7ZM77AphDIcv3bdh5505OyiwIR8vsCtPE+rPrrNDuz7fiG4UAD JU1zbS0kPTy61ORQ X-Received: by 10.99.170.70 with SMTP id x6mr743979pgo.111.1492226125128; Fri, 14 Apr 2017 20:15:25 -0700 (PDT) Received: from ?IPv6:2406:e001:38c5:1:28cc:dc4c:9703:6781? ([2406:e001:38c5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z123sm5475978pfz.56.2017.04.14.20.15.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 20:15:24 -0700 (PDT) From: Brian E Carpenter Subject: =?UTF-8?Q?Traffic_class_&_fragments_[was_Mirja_K=c3=bchlewind's_Dis?= =?UTF-8?Q?cuss_on_draft-ietf-6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMEN?= =?UTF-8?B?VCld?= To: "Mirja Kuehlewind (IETF)" , Bob Hinden References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Cc: draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org Organization: University of Auckland Message-ID: Date: Sat, 15 Apr 2017 15:15:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:15:27 -0000 Mirja raised the issue of the ECN bits possibly being different in different fragments. The same is true of the DSCP bits, if there is a diffserv re-marker on the path. However, I realised that this is already stated by the existing text: >>> 7. Traffic Classes >>> >>> The 8-bit Traffic Class field in the IPv6 header is used by the >>> network for traffic management. The value of the Traffic Class bits >>> in a received packet might be different from the value sent by the >>> packet's source. For clarity, we could change that to >>> 7. Traffic Classes >>> >>> The 8-bit Traffic Class field in the IPv6 header is used by the >>> network for traffic management. The value of the Traffic Class bits >>> in a received packet or fragment might be different from the value >>> sent by the packet's source. The text also what happens when a packet is re-assembled: >>> The Per-Fragment Headers of the reassembled packet consists of all >>> headers up to, but not including, the Fragment header of the first >>> fragment packet... so the Traffic Class in the first fragment will always win. Obviously, any more sophisticated algorithm during re-assembly is out of scope for the promotion to Internet Standard, since it would be a new requirement. Brian From nobody Sat Apr 15 04:53:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61400127868; Sat, 15 Apr 2017 04:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 xMCrLh--HUjC; Sat, 15 Apr 2017 04:53:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15511242EA; Sat, 15 Apr 2017 04:53:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 5473A79FD9; Sat, 15 Apr 2017 07:53:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=c8E rE8HYVocNh7muTIQdx49XoIk=; b=D+MxrX5tuFq+syw2zhsYIYfQh13UmpZUzCY LXO/cgnY9pQEKLmfARL0W957rfQP+3PgCEVdGbs/KF1gx5sOjMctU1E316bsIydy 4Hr72VSwIheMZi0uhDfdtetrLKhzUw/OEEk8yEbBj2hOg7HFkO9sJFDHj1Bcfguc ju0uEulM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= t00BsGzmGW8VU1XzqP0ahcJRWQbGdxOtCCcly/CQHjq/JqdrypyJrtWvU49m53mO ulGUPJDtwhfrwq+9yBnLrrauWYSEevapKeSz6tsCLhFnbBtvFxc2+TndBZPPOVCF uS2TYlWFJC8QdP+594ns0rUdt9eAWyLGq1NQMZhkQCc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3B65179FD6; Sat, 15 Apr 2017 07:53:35 -0400 (EDT) Received: from mail-qt0-f174.google.com (unknown [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id BF40A79FD3; Sat, 15 Apr 2017 07:53:34 -0400 (EDT) Received: by mail-qt0-f174.google.com with SMTP id g60so11454216qtd.3; Sat, 15 Apr 2017 04:53:34 -0700 (PDT) X-Gm-Message-State: AN3rC/4TFafbU+Wy/Srw/k4pRGHSjKtPna8bCApR/oC57JTclgk2iEfn wfbbaBQjswWeKRnDkaytSqvU5kZFgw== X-Received: by 10.200.47.91 with SMTP id k27mr1585611qta.11.1492257214356; Sat, 15 Apr 2017 04:53:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Sat, 15 Apr 2017 04:53:13 -0700 (PDT) From: "C. M. Heard" Date: Sat, 15 Apr 2017 04:53:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Brian E Carpenter , "Mirja Kuehlewind (IETF)" , Bob Hinden Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 278607FA-21D2-11E7-9E38-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 11:53:39 -0000 On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >... >>>>>> ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> One question because I'm not sure if I interpret this correct to make it >>>>>> part of my discuss: >>>>>> Section 4.5: "The number and content of the headers preceding the >>>>>> Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained in >>>>>> the reassembled packet." >>>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is >>>>>> copied from the first fragment? This doesn't seem to be correct, however, >>>>>> also not sure what the correct answer is. I know this was not changed in >>>>>> this revision but maybe we can still get this right. >>>>> >>>>> When fragments are created most of the fields are copied from the IPv6 >>>>> headers (e.g., Source Address, Destination address, flow label, traffic >>>>> class, hop limit). Some like payload length, next header, and hop limi >>>>>t are modified. >>>>> >>>>> If I understand your question, the answer is yes, the ECN code point is >>>>> copied from the first fragment, but should be the same from all of the >>>>> fragments. That is inconsistent with the following guidance in RFC 3168 (see https://tools.ietf.org/html/rfc3168#section-5.3): 5.3. Fragmentation ECN-capable packets MAY have the DF (Don't Fragment) bit set. Reassembly of a fragmented packet MUST NOT lose indications of congestion. In other words, if any fragment of an IP packet to be reassembled has the CE codepoint set, then one of two actions MUST be taken: * Set the CE codepoint on the reassembled packet. However, this MUST NOT occur if any of the other fragments contributing to this reassembly carries the Not-ECT codepoint. * The packet is dropped, instead of being reassembled, for any other reason. If both actions are applicable, either MAY be chosen. Reassembly of a fragmented packet MUST NOT change the ECN codepoint when all of the fragments carry the same codepoint. >>>> My concern is that the ECN code point could be changed on one of the >>>> fragmented packets to signal congestion of a intermediate node and >>>> then when you reassemble this information gets lost. That seems wrong. >>> >>> That is an interesting idea, but I think out of scope for advancing this >>> document to Internet Standard. Then there is the question of how to >>> encode n of m fragments experienced congestion. Interesting future work. >> >> Yes there might be some more further work needed but that still makes the >> guidance in this text wrong. Maybe we can add some text that the Traffic >> Class may be handled differently because it could be changed on the path. > >Good point. It's not only ECN that can change; the DSCP can change too. >Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >for 2460bis to note this issue. It seems that we (6man WG) missed this because RFC 3168 was not marked as updating RFC 2460. But in effect it did so for IPv6 implementations of ECN, even though it was not written in an IP version-agnostic manner. At the very least text should be added to the description of the reassembly process that points the reader to RFC 3168 or its successor document. Mike Heard From nobody Sat Apr 15 05:29:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669F1286AB for ; Sat, 15 Apr 2017 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 ejeGTn2lNUW5 for ; Sat, 15 Apr 2017 05:29:39 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 9FA4B126DFB for ; Sat, 15 Apr 2017 05:29:39 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l189so42819929ywb.0 for ; Sat, 15 Apr 2017 05:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I8Xw1vH9vXxAQ4kGNgnJt+eKvOz3G7tWX2MCjfRYnNg=; b=VXUsq9L5kn64VvSpDKov72kCyOmlOLI/aLtTsZUcyLzRWClBjGIfji8gZw1gBjUivC QIPBx33VbjaHi4/Bg5Ewm9otmlNP7s/0qEWKS4mLvuB/n2RCt0gq0YoYkXWfw/qEHKPk PfLPNEX0PLJKsM2QVbAQzGlU/+K4eIRseOf8YKVlaQ2OiFHZDV7jhYLmWvhPeaFtMyWe AU8wheG/U7sh39ZRWKOuAoGq7z1/SqYZeIlZGSIv3EFFulN4qob+bOSl+Ysn9wX5F5hC ZrzYzE5G83q9jOYUyAugAqf6Jzesy9rxkeQrDlvVYQszh2ifE4bMelPUVBYjJAgombK1 l94w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I8Xw1vH9vXxAQ4kGNgnJt+eKvOz3G7tWX2MCjfRYnNg=; b=KM31SofC/EeZCW7XrjWKhg6yzk/IJCTJc07OaTvm8fpAddJ6Glyx4MQbxcg4+nz6iG Zii3JT2Z+YZJtmHxxIJnHRpLFy/xaPdTcR/Z0NzS79HAmMXeynWJ66qgd0zTftE+8rDn iEK0K4JLArW6XO/zr129ohA8dPDE1dkm3eUW7dXsFRtVRxYGn0guPTBC8vmU1Kmv1P3y 5qo0QfrpcHpMq1ELzHvGNPc6iFoQqJ3gEAhALL5C1++J8gSa+iaeiANflivttHFwRqsU DUttO/1mQ5gwllMdpAPs890lWWoIS0kmkQB8EIALJw8sgDdcxigS16WavKR1t95bbveV qLLg== X-Gm-Message-State: AN3rC/5zYzr202Gwsf47LLLeFwIQvwv7bd5btwjkjokYSKQ6SuPo6Y5R NQJCOBEucWtcv6xeysRjCVZIWtZ6nGhR X-Received: by 10.129.116.135 with SMTP id p129mr9410445ywc.271.1492259378242; Sat, 15 Apr 2017 05:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Sat, 15 Apr 2017 05:29:16 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Sat, 15 Apr 2017 21:29:16 +0900 Message-ID: Subject: Re: RFC1122 - does it really apply to IPv6 hosts? To: Fred Baker Cc: Mark Smith , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11373aca30cdbb054d33b6df" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 12:29:41 -0000 --001a11373aca30cdbb054d33b6df Content-Type: multipart/alternative; boundary=001a11373aca278447054d33b68c --001a11373aca278447054d33b68c Content-Type: text/plain; charset=UTF-8 On 15 April 2017 at 12:10, Fred Baker wrote: > > > On Apr 14, 2017, at 6:07 PM, Mark Smith wrote: > > > > The reason I'm curious is because I wondered for a long time whether > > IPv6 nodes supported either of the strong or weak ES model, or whether > > IPv6 had selected only one of those models. > > You might take a look at the comments on the topic in RFC 7039, where Joe > Touch (IIRC) brought the question up. My take is that neither IPv4 nor IPv6 > really uses either as described there. The weak model says that any address > may be used as a source address on any interface; to my knowledge, a host > only originates messages using a given address on the interface it is > assigned to. The strong model, in 1122, says that the host acts as if it > were some number of virtual hosts, one per address, and the virtual host > only uses the interface that address is on. Again, AFAIK, that is not the > case in current equipment. Linux is very weak ES model-y. We definitely saw Linux preferring non-tentative addresses on interface A when originating packets on interface B while interface B's addresses were undergoing DAD. A sysctl was added to override this (i.e. to implement RFC 6724 section 4 paragraph 2). --001a11373aca278447054d33b68c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 5 April 2017 at 12:10, Fred Baker <fredbaker.ietf@gmail.com>= wrote:

> On Apr 14, 2017, at 6:07 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>
> The reason I'm curious is because I wondered for a long time wheth= er
> IPv6 nodes supported either of the strong or weak ES model, or whether=
> IPv6 had selected only one of those models.

You might take a look at the comments on the topic in RFC 7039, wher= e Joe Touch (IIRC) brought the question up. My take is that neither IPv4 no= r IPv6 really uses either as described there. The weak model says that any = address may be used as a source address on any interface; to my knowledge, = a host only originates messages using a given address on the interface it i= s assigned to. The strong model, in 1122, says that the host acts as if it = were some number of virtual hosts, one per address, and the virtual host on= ly uses the interface that address is on. Again, AFAIK, that is not the cas= e in current equipment.

Linux is very weak = ES model-y.

We definitely saw Linux preferring non= -tentative addresses on interface A when originating packets on interface B= while interface B's addresses were undergoing DAD.=C2=A0 A sysctl was = added to override this (i.e. to implement RFC 6724 section 4 paragraph 2).<= /div>
--001a11373aca278447054d33b68c-- --001a11373aca30cdbb054d33b6df Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgnsYWYnnd1pWBZQqtb/e4Dn5nWRkGC6Zd gJfZZMRwT8AwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE1 MTIyOTM4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAFpSfqJ4fgCmA1Lfk2tsqwYqqsXEryR0+6zS+55zVJO6bLd3p8n8 s+Fmlo13hagqAdXWdsVWAND3mBPYljOQdtH8Wef/Za/2jzOmViXR3XMM2aMyHDyWLijfTNsYK7Q/ c//LYgkRPPW5IltvAZYbCcPYcQDKgBUamAWtxxtyd0a44WwMg99vuZrpb2RHJ8YxHBtL0JLTGSW9 2w/ymjIbfgNMrsoo0Xzvm+pxX41bM+Ghtcs8POeHv/1Ws53j7Zc1/fFl+/Ehl2N+IU0bUcv/teXE Dz9hCi2c8mn8SwvS1Q8Ta7Ozs1YcvQW4plPxZ4f2sOkzc4+6galElL1TczcbrmY= --001a11373aca30cdbb054d33b6df-- From nobody Sat Apr 15 06:38:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453FE1292CE for ; Sat, 15 Apr 2017 06:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 h0XggbMufrtM for ; Sat, 15 Apr 2017 06:38:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A9128DF3 for ; Sat, 15 Apr 2017 06:38:03 -0700 (PDT) Received: (qmail 27716 invoked from network); 15 Apr 2017 15:38:01 +0200 Received: from p5dec216f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.33.111) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Apr 2017 15:38:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 15 Apr 2017 15:38:00 +0200 Cc: Brian E Carpenter , Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "C. M. Heard" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 13:38:06 -0000 Hi Mike, thanks a lot! I=E2=80=99ve missed that rfc3168 actually discusses = fragmentation. I think in this case it clear what to do for the ECN = case. Thanks! Mirja > Am 15.04.2017 um 13:53 schrieb C. M. Heard : >=20 > On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >> ... >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> One question because I'm not sure if I interpret this correct to = make it >>>>>>> part of my discuss: >>>>>>> Section 4.5: "The number and content of the headers preceding = the >>>>>>> Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet." >>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) is >>>>>>> copied from the first fragment? This doesn't seem to be correct, = however, >>>>>>> also not sure what the correct answer is. I know this was not = changed in >>>>>>> this revision but maybe we can still get this right. >>>>>>=20 >>>>>> When fragments are created most of the fields are copied from the = IPv6 >>>>>> headers (e.g., Source Address, Destination address, flow label, = traffic >>>>>> class, hop limit). Some like payload length, next header, and = hop limi >>>>>> t are modified. >>>>>>=20 >>>>>> If I understand your question, the answer is yes, the ECN code = point is >>>>>> copied from the first fragment, but should be the same from all = of the >>>>>> fragments. >=20 > That is inconsistent with the following guidance in RFC 3168 (see > https://tools.ietf.org/html/rfc3168#section-5.3): >=20 > 5.3. Fragmentation >=20 > ECN-capable packets MAY have the DF (Don't Fragment) bit set. > Reassembly of a fragmented packet MUST NOT lose indications of > congestion. In other words, if any fragment of an IP packet to be > reassembled has the CE codepoint set, then one of two actions MUST = be > taken: >=20 > * Set the CE codepoint on the reassembled packet. However, this > MUST NOT occur if any of the other fragments contributing to > this reassembly carries the Not-ECT codepoint. >=20 > * The packet is dropped, instead of being reassembled, for any > other reason. >=20 > If both actions are applicable, either MAY be chosen. Reassembly of > a fragmented packet MUST NOT change the ECN codepoint when all of = the > fragments carry the same codepoint. >=20 >>>>> My concern is that the ECN code point could be changed on one of = the >>>>> fragmented packets to signal congestion of a intermediate node and >>>>> then when you reassemble this information gets lost. That seems = wrong. >>>>=20 >>>> That is an interesting idea, but I think out of scope for advancing = this >>>> document to Internet Standard. Then there is the question of how = to >>>> encode n of m fragments experienced congestion. Interesting future = work. >>>=20 >>> Yes there might be some more further work needed but that still = makes the >>> guidance in this text wrong. Maybe we can add some text that the = Traffic >>> Class may be handled differently because it could be changed on the = path. >>=20 >> Good point. It's not only ECN that can change; the DSCP can change = too. >> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >> for 2460bis to note this issue. >=20 > It seems that we (6man WG) missed this because RFC 3168 was not marked > as updating RFC 2460. But in effect it did so for IPv6 implementations > of ECN, even though it was not written in an IP version-agnostic = manner. >=20 > At the very least text should be added to the description of the > reassembly process that points the reader to RFC 3168 or its > successor document. >=20 > Mike Heard >=20 From nobody Sat Apr 15 06:50:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63329126DD9 for ; Sat, 15 Apr 2017 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 qGOUMR10YBVS for ; Sat, 15 Apr 2017 06:50:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4380C127ABE for ; Sat, 15 Apr 2017 06:50:01 -0700 (PDT) Received: (qmail 27979 invoked from network); 15 Apr 2017 15:49:59 +0200 Received: from p5dec216f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.33.111) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Apr 2017 15:49:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> Date: Sat, 15 Apr 2017 15:49:58 +0200 Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 13:50:03 -0000 Hi Brian, thanks for splitting the discussion up into it=E2=80=99s three piece. = However, i=E2=80=99m answering this one first because there is some = relation to the other one on HBH. Further see below. > Am 14.04.2017 um 04:28 schrieb Brian E Carpenter = : >=20 > And one more comment for today: > On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >=20 > ... >>> As it says in Section 4.8: >>>=20 >>> Defining new IPv6 extension headers is not recommended. There has = to >>> be a very clear justification why any new extension header is = needed >>> before it is standardized. Instead of defining new Extension >>> Headers, it is recommended that the Destination Options header is >>> used to carry optional information that must be examined only by a >>> packet's destination node(s), because they provide better handling >>> and backward compatibility. >>>=20 >> Yes, this text is the text I have problem with. I think I would = suggest to drop the first part and only have this part: >>=20 >> "It is recommended to rather use the Destination Options header=20 >> to carry optional information that must be examined only by a >> packet's destination node(s), instead of defining new Extension >> Headers, because they provide better handling >> and backward compatibility." >=20 > "Defining new IPv6 extension headers is not recommended" is a rather > mild statement. There were certainly some in the WG who wanted > a MUST NOT here. It's an operational and security concern: existing > middleboxes, especially firewalls, are allergic to extension headers > that they don't understand. This is unfortunate, since the design = model > was that the forwarding path should be transparent to all headers, = which > meant that new headers could be deployed between consenting adults > without any infrastructure issues. But this simply doesn't work in > the real world - that's the main reason we wrote RFC7045. I think it's > worth quoting this: >=20 > This combination of circumstances creates a "Catch-22" situation > [Heller] for the deployment of any newly standardised extension > header except for local use. It cannot be widely deployed because > existing middleboxes will drop it on many paths through the = Internet. > However, most middleboxes will not be updated to allow the new = header > to pass until it has been proved safe and useful on the open > Internet, which is impossible until the middleboxes have been > updated. >=20 > So, defining new IPv6 extension headers is not recommended, because > they probably won't work across the Internet. But it isn't a MUST NOT, > because if there was a compelling operational case, we could do it and > the middleboxes would follow. First of all yes, giving further explanation/background is definitely a = good thing to do, and maybe also provide a reference to rfc7045 if = appropriate. I think I agree that I would not like to make a normative statement = here, given that the circumstances are not due to the protocol design = itself but because of the current deployment situation we have (which in = theory could change in future). However, instead of making a clear recommendation to not every define a = new extension header, I think I would prefer if the text was phrased in = the a way that would make the risk clear, give a clear recommendation to = rather use destination options if suitable, and then say nothing else. Maybe you can work on some new text and then have a quick (?) check with = the wg which text is preferred. If there is clear consensus for one way = by the wg I will not further block this. However, please see my next mail. Mirja P.S.: My understanding from the text above is that the new extension = header will be dropped but not the whole packets. Is that right? Because = in this case there are still ways for experimentation. >=20 > RFC 7045 was intended to nudge middlebox developers in the right > direction, and similarly draft-ietf-opsec-ipv6-eh-filtering. But it's > an uphill battle. >=20 > Brian >=20 From nobody Sat Apr 15 07:01:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C271275AB for ; Sat, 15 Apr 2017 07:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 tG9RNEMwcaHh for ; Sat, 15 Apr 2017 07:01:18 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E63E1252BA for ; Sat, 15 Apr 2017 07:01:17 -0700 (PDT) Received: (qmail 28307 invoked from network); 15 Apr 2017 16:01:16 +0200 Received: from p5dec216f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.33.111) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Apr 2017 16:01:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 15 Apr 2017 16:01:15 +0200 Cc: draft-ietf-6man-rfc2460bis@ietf.org, otroan@employees.org, 6man WG , The IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 14:01:20 -0000 Hi again, (sorry I#ve sent an empty reply a moment ago. Here is my reply now.) see below. > Am 14.04.2017 um 04:12 schrieb Brian E Carpenter = : >=20 > Still jet lagged but let me try: > On 13/04/2017 23:19, Mirja Kuehlewind (IETF) wrote: >> Hi again, >>=20 >>=20 >>> Am 13.04.2017 um 03:45 schrieb Brian E Carpenter = : >>>=20 >>> On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote: >>> ... >>>>> NOTE: While [RFC2460] required that all nodes must examine and >>>>> process the Hop-by-Hop Options header, it is now expected that = nodes >>>>> along a packet's delivery path only examine and process the = Hop-by- >>>>> Hop Options header if explicitly configured to do so. >>>>>=20 >>>>> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >>>>=20 >>>> I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >>>=20 >>> I think I'm repeating myself due to jet lag, but this problem IMHO = has *nothing* to do with >>> the current definition of HbH. It's to do with the very nature of = HbH - something we are >>> asking *every* router in the Internet to do. The core routers in = transit providers will >>> never do that. Redefining the HbH header cannot change that; it's = intrinsic. >>>=20 >>> The above quoted Note was a WG consensus choice to resolve this = issue, iirc, adapted >>> from section 2.2 of RFC7045. >>=20 >> I might repeat myself as well but anyway. The above quoted text is = fine but it does not solve the problem we have in reality. If the = behavior would have been defined the way it is defined now from the = beginning that would have been fine. However, there are router out there = that put all packets that have the HBH header in the slow path which = makes the HBH header unusable in practice. Redefining the behavior in = the spec opens the door to fix that problem but the deploy router will = not go away quickly, leaving a risk that your packets go on the slow = path. Just because there is this risk, I would not recommend to use any = HBH option (as the document does). However, if HBH are not usable, how = can I then achieve the desired behavior (where some of the router on the = path are allow to inspect and process some information in the IP = extension header)? >=20 > I have no good answer. We got this wrong originally, so what can we do = in the Internet Standard except document the problem? We could actually deprecate the HBH header, and eventually define a new = one/assign a new number (at some later point). And this is exactly the = case where I see a new extension header coming up. As I said in my original discuss it=E2=80=99s just very unsatisfying to = change the HBH handling (correctly) and then say it=E2=80=99s not = recommended to use it. One more point: I recently realized is that given the destination option = and the HBH option use the same registry, it actually is very tempting = to simply use the destination option header with HBH options because no = current router will inspect it and only new boxes that support the new = feature (at the edge) may start looking into it. Just as another side = note on what we might see happening in future with this recommendation. >=20 > (I suspect that the real answer is that to install any kind of flow = state, we need to use an explicit flow state creation protocol, not hang = it off a packet header designed mainly for stateless processing. If that = sounds like a short explanation of why Integrated Services/RSVP failed, = it is. And it's surely out of scope for 2460bis.) I agree (I=E2=80=99m working on PLUS for this reason but that=E2=80=99s = a different topic). Nothing we have to or should address in this = document. But we could be more clear and go the next step and deprecate = HBH. I didn=E2=80=99t follow the document or wg discuss closely but to = my understanding the option to deprecate HBH was not really discuss in = the group. Was it? Mirja >=20 > Brian >=20 >=20 From nobody Sat Apr 15 07:16:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4A1292FC for ; Sat, 15 Apr 2017 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 HRiltuENxYoJ for ; Sat, 15 Apr 2017 07:16:53 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4097012896F for ; Sat, 15 Apr 2017 07:16:53 -0700 (PDT) Received: (qmail 28019 invoked from network); 15 Apr 2017 15:50:10 +0200 Received: from p5dec216f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.33.111) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Apr 2017 15:50:10 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 15 Apr 2017 15:50:10 +0200 Cc: draft-ietf-6man-rfc2460bis@ietf.org, otroan@employees.org, 6man WG , The IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <614FFDE0-28C3-472E-BDC4-1B142A33C1A5@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 14:16:55 -0000 > Am 14.04.2017 um 04:12 schrieb Brian E Carpenter = : >=20 > Still jet lagged but let me try: > On 13/04/2017 23:19, Mirja Kuehlewind (IETF) wrote: >> Hi again, >>=20 >>=20 >>> Am 13.04.2017 um 03:45 schrieb Brian E Carpenter = : >>>=20 >>> On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote: >>> ... >>>>> NOTE: While [RFC2460] required that all nodes must examine and >>>>> process the Hop-by-Hop Options header, it is now expected that = nodes >>>>> along a packet's delivery path only examine and process the = Hop-by- >>>>> Hop Options header if explicitly configured to do so. >>>>>=20 >>>>> Which means by default routers unless they have been configured to = process a particular option contained in an HBH option, shall forward = the packet as normal. Thereby rectifying the attack vector. >>>>=20 >>>> I=E2=80=99ve see this change and it=E2=80=99s a step in the right = direction but it doesn=E2=80=99t solve the problem given there are = already deployment that still put packets with an hop-by-hop header on = the slow path which still renders the hop-by-hop header as currently = defined unusable. >>>=20 >>> I think I'm repeating myself due to jet lag, but this problem IMHO = has *nothing* to do with >>> the current definition of HbH. It's to do with the very nature of = HbH - something we are >>> asking *every* router in the Internet to do. The core routers in = transit providers will >>> never do that. Redefining the HbH header cannot change that; it's = intrinsic. >>>=20 >>> The above quoted Note was a WG consensus choice to resolve this = issue, iirc, adapted >>> from section 2.2 of RFC7045. >>=20 >> I might repeat myself as well but anyway. The above quoted text is = fine but it does not solve the problem we have in reality. If the = behavior would have been defined the way it is defined now from the = beginning that would have been fine. However, there are router out there = that put all packets that have the HBH header in the slow path which = makes the HBH header unusable in practice. Redefining the behavior in = the spec opens the door to fix that problem but the deploy router will = not go away quickly, leaving a risk that your packets go on the slow = path. Just because there is this risk, I would not recommend to use any = HBH option (as the document does). However, if HBH are not usable, how = can I then achieve the desired behavior (where some of the router on the = path are allow to inspect and process some information in the IP = extension header)? >=20 > I have no good answer. We got this wrong originally, so what can we do = in the Internet Standard except document the problem? >=20 > (I suspect that the real answer is that to install any kind of flow = state, we need to use an explicit flow state creation protocol, not hang = it off a packet header designed mainly for stateless processing. If that = sounds like a short explanation of why Integrated Services/RSVP failed, = it is. And it's surely out of scope for 2460bis.) >=20 > Brian >=20 >=20 From nobody Sat Apr 15 11:13:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AAD128DF6; Sat, 15 Apr 2017 11:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 7rYmS0jGlkGC; Sat, 15 Apr 2017 11:13:17 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id BECE2127977; Sat, 15 Apr 2017 11:13:17 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 15 Apr 2017 18:13:17 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EBB9DD788B; Sat, 15 Apr 2017 11:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=LW6ISfCfci2NO310nXhkhOvQ+mU=; b= bgl2Jx4rVg3eYGnhwLC359ChUiUZ8RG60UMfLJ+F/XSo41Kt9ABcMuIKsz1XqpvV S8KwBVf7r2GYt0hRKAmE1gyYUcoIanBIrO8MVyFEsMYAqAVAVo5JrWj849VWJO8Y GG7pcSLHnBfIC2aGH9YmKkoPjvGP1OEbaoAzaSQZTUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=Y+SJH4sv1mWkolU72X7/BzQ IQX6FtS4fkQvARRP3+FE/r0JIq/XQ7gkSdOeXDWUbLkiVPMWyYerBKTwACMqBJBX HOjY43StTQeLvoo/43EDQb9Ym1OoEH8b24QRqPH4Uk/8t+T4q+oyFuvsReDF4Oys XiKjk2MKpUlankzfrfzg= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 762F5D788A; Sat, 15 Apr 2017 11:13:16 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B20C7A9C909E; Sat, 15 Apr 2017 20:13:13 +0200 (CEST) From: otroan@employees.org Message-Id: <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7B712628-845C-4618-8E3E-F41C239146E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Sat, 15 Apr 2017 20:13:12 +0200 In-Reply-To: Cc: Brian E Carpenter , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 18:13:19 -0000 --Apple-Mail=_7B712628-845C-4618-8E3E-F41C239146E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, [...] >> I have no good answer. We got this wrong originally, so what can we = do in the Internet Standard except document the problem? >=20 > We could actually deprecate the HBH header, and eventually define a = new one/assign a new number (at some later point). And this is exactly = the case where I see a new extension header coming up. >=20 > As I said in my original discuss it=E2=80=99s just very unsatisfying = to change the HBH handling (correctly) and then say it=E2=80=99s not = recommended to use it. The recommendation not to use it, is because the expectation that an = application can give all routers along the packet's delivery path = instructions, that will be adhered to is wrong. Essentially we're saying = that the HBH option should be mostly ignored, and I would expect mostly = have applicability within one administrative domain. > One more point: I recently realized is that given the destination = option and the HBH option use the same registry, it actually is very = tempting to simply use the destination option header with HBH options = because no current router will inspect it and only new boxes that = support the new feature (at the edge) may start looking into it. Just as = another side note on what we might see happening in future with this = recommendation. I don't understand why you see using a destination option solves = anything. That will just end up being subject to the same operational policies as = the HBH header. And note any packet that doesn't have the TCP or UDP header directly = following the IP header has a significantly higher drop probability = anyway. >> (I suspect that the real answer is that to install any kind of flow = state, we need to use an explicit flow state creation protocol, not hang = it off a packet header designed mainly for stateless processing. If that = sounds like a short explanation of why Integrated Services/RSVP failed, = it is. And it's surely out of scope for 2460bis.) >=20 > I agree (I=E2=80=99m working on PLUS for this reason but that=E2=80=99s = a different topic). Nothing we have to or should address in this = document. But we could be more clear and go the next step and deprecate = HBH. I didn=E2=80=99t follow the document or wg discuss closely but to = my understanding the option to deprecate HBH was not really discuss in = the group. Was it? Some people have even been discussing deprecating extension header = altogether. The working group decided not to deprecate the HBH header at this point. = As in, we still think it can be rescued. Cheers, Ole --Apple-Mail=_7B712628-845C-4618-8E3E-F41C239146E9 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY8mK5AAoJEL7aWKiYQt92NuAP/0v2ZUNO4NeEqCPQQOtZs2iS oNjX0i8FYDuXvepoD89k87TvGzDahxqyFQlGwA+JAmlcePah1dTiqaDZzWHyqNr4 y3ikoXnszuA/WGae7KHq5bdXSXF5aZTnywZQh0k2JlgPZPJB3IiMG6q2kYWgifOk 656cg7p9Yyb72x+16GZNNqTtVCv9L+x6Tt7QMLgJviIaYXGywOxNN63FSVFRE9d2 l8xYiJrU/UI+yQdwkHXMgnqIZnYhhYAQ4k6+NHOM/Zi8P8oLbuQiZZJlSArMOKNg Yj89i4hEIVHRmNszYw9aUKGEuo6eUjCAF0ZefTFRnhyJchef/uUC82iDTJ7q5a2M l122zzNAwBrqA3Q6WNpWFS8KZ5ue7Q5wXMyU7W7SKnU1VwvTDcB8MVcG2wrdm4hu 4Bd2aAznMFiLpoOwM9XnZg0sNkQwhdY5CIzU6IYR9/SFLL3XJ8XzvEaxNxmwqvJJ 5HCjPJzqewOs+UN1QGdsEENqaSo8/hOAkxhIqutf7zNUhu24bGMqEOxDdh+aZnFG aiVi2lxXsEJaNm04qG8K03k1QTy/cERpsdFaWw/LqSak9eBWiCWAuuxEBrnp1LW0 MHL5Aq1PvSoWfknL7vX0Q08pxh0kQneKlmOCAcu0yPxcsdqjMhcJvG78BtgPoN1q 9U4lCGv4Q8WuTOWQZpB/ =Phvy -----END PGP SIGNATURE----- --Apple-Mail=_7B712628-845C-4618-8E3E-F41C239146E9-- From nobody Sat Apr 15 11:51:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055E0129457; Sat, 15 Apr 2017 11:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 5yz3zjKU9zes; Sat, 15 Apr 2017 11:50:53 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 F08FC12943F; Sat, 15 Apr 2017 11:50:52 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id o21so65056527wrb.2; Sat, 15 Apr 2017 11:50:52 -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=Gf7QvU6Ml2EWIgXPYkgAohcWn/93RQE7bwn4ThZrReo=; b=pCKtrWkKkodtzteU5CLfTXPr5sRvhf/L7WT6tYSd0md2nnNLsJjXpPRRb0gy0ydOPy TiWviqicW8T3wRzq/+euEdcw9yAaoESGbPdEEeTeZ6lT1EogeUjUe1+ZQT3iarwHAYd9 tpjCZOnhUziEHSBDKIxFrp+62UY9ZU81zKyfrYg4f7gb8syEXjTG0YtZ7oS2CnWzsAmf vmcSW84hr8Rqd2nzcOr/+hzmqEA+UJLFcccTniwyQkdEwPIQcIvKEza5WTZ83PiGw1kP qHGsRX/1i84J24n1an2KnQA9/yz8onH7rcMtat18n09x5toDAOWpTHJts2VD2spfyRHj Egbg== 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=Gf7QvU6Ml2EWIgXPYkgAohcWn/93RQE7bwn4ThZrReo=; b=XyoJ1ER+tWboGcB+Tu5kYoZv+scj5K5Q4JEnA4R00mafsaWhCJ6z5hCCzfkmHXdJlK 3Z899E/QuixtAWeNrhSVOhm7NVeaHkemZ95Mv4yz1YyxH3J9+/oUA+FbKFeTC6REmrsk VGNcxnrl+IVLf45VO4zeklXjFckAEEo2VOEwRnyHRH2HXaoMBzzs+Is0lE/Gd3tZaoXO JivIEdX/4HuL8ftu2BPgw4UpTfeoJn2DAgNuYwrsfbkDGREhZpNJOXcqXzg36CEUq3b0 0ZNffkGWEDDqzqmkaGrdObNW8Eb1Jb/tIsKm2DLn+EjV+9H74Ht3KnRkJb5MQgVOS0Av a+xA== X-Gm-Message-State: AN3rC/4Vq6ZDFPKyp7hGzITFDuqa+5zZBOOoH35s4N9dVUnSdC7JKXde uxyOwRqMllqXmw== X-Received: by 10.223.153.230 with SMTP id y93mr11950902wrb.41.1492282251292; Sat, 15 Apr 2017 11:50:51 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:392d:735b:1554:21af? ([2601:647:4d01:db10:392d:735b:1554:21af]) by smtp.gmail.com with ESMTPSA id y72sm7368847wrc.51.2017.04.15.11.50.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 11:50:50 -0700 (PDT) From: Bob Hinden Message-Id: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BA382536-4467-4C82-A1AD-D10EC9B98BB2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Sat, 15 Apr 2017 11:50:44 -0700 In-Reply-To: Cc: Bob Hinden , Brian Carpenter , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man Chairs <6man-chairs@ietf.org> To: "C. M. Heard" References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 18:50:55 -0000 --Apple-Mail=_BA382536-4467-4C82-A1AD-D10EC9B98BB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, > On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >=20 > On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >> ... >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> One question because I'm not sure if I interpret this correct to = make it >>>>>>> part of my discuss: >>>>>>> Section 4.5: "The number and content of the headers preceding = the >>>>>>> Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet." >>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) is >>>>>>> copied from the first fragment? This doesn't seem to be correct, = however, >>>>>>> also not sure what the correct answer is. I know this was not = changed in >>>>>>> this revision but maybe we can still get this right. >>>>>>=20 >>>>>> When fragments are created most of the fields are copied from the = IPv6 >>>>>> headers (e.g., Source Address, Destination address, flow label, = traffic >>>>>> class, hop limit). Some like payload length, next header, and = hop limi >>>>>> t are modified. >>>>>>=20 >>>>>> If I understand your question, the answer is yes, the ECN code = point is >>>>>> copied from the first fragment, but should be the same from all = of the >>>>>> fragments. >=20 > That is inconsistent with the following guidance in RFC 3168 (see > https://tools.ietf.org/html/rfc3168#section-5.3): >=20 > 5.3. Fragmentation >=20 > ECN-capable packets MAY have the DF (Don't Fragment) bit set. > Reassembly of a fragmented packet MUST NOT lose indications of > congestion. In other words, if any fragment of an IP packet to be > reassembled has the CE codepoint set, then one of two actions MUST = be > taken: >=20 > * Set the CE codepoint on the reassembled packet. However, this > MUST NOT occur if any of the other fragments contributing to > this reassembly carries the Not-ECT codepoint. >=20 > * The packet is dropped, instead of being reassembled, for any > other reason. >=20 > If both actions are applicable, either MAY be chosen. Reassembly of > a fragmented packet MUST NOT change the ECN codepoint when all of = the > fragments carry the same codepoint. >=20 >>>>> My concern is that the ECN code point could be changed on one of = the >>>>> fragmented packets to signal congestion of a intermediate node and >>>>> then when you reassemble this information gets lost. That seems = wrong. >>>>=20 >>>> That is an interesting idea, but I think out of scope for advancing = this >>>> document to Internet Standard. Then there is the question of how = to >>>> encode n of m fragments experienced congestion. Interesting future = work. >>>=20 >>> Yes there might be some more further work needed but that still = makes the >>> guidance in this text wrong. Maybe we can add some text that the = Traffic >>> Class may be handled differently because it could be changed on the = path. >>=20 >> Good point. It's not only ECN that can change; the DSCP can change = too. >> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >> for 2460bis to note this issue. >=20 > It seems that we (6man WG) missed this because RFC 3168 was not marked > as updating RFC 2460. But in effect it did so for IPv6 implementations > of ECN, even though it was not written in an IP version-agnostic = manner. >=20 > At the very least text should be added to the description of the > reassembly process that points the reader to RFC 3168 or its > successor document. Do we have any evidence that the guidance in RFC 3168 regarding = reassembling IPv6 fragments is implemented? I don=E2=80=99t know, but = think if it there is evidence I agree some text should be added to = rfc2460bis, if not, then maybe not. Thanks, Bob --Apple-Mail=_BA382536-4467-4C82-A1AD-D10EC9B98BB2 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY8muFAAoJEK7rdBF357uo5qkIALneCsxyGGk7E9OVd3dRzf11 H2S8FyyLtO70cLvnZM84+Fc+sQc6vgp/Khq0owXUa8O0LC+Ohx4Gh9KDuljZS0w3 6tKKNIGQ2NMhMGSd4BXx7yI6EpR/JhWgtaTg7ueSByCAShj91+iS7y0HB3FR/FRN 9J0aEt7AN99tjX3v9q80TP61XNlT2e0Wco3FIX9f2JwB4TsNEqf+SdHzb3+wCoSr y13vH0r0itPsgxKtrL0h3b5ff5r+meKj9lIj9Z0N9DA4bUc3aHsMHr905qqP/77v Di5KJTA8Fhgfi/IQXZ8fpcjnR3Mx6WIENDzvclC6/tm7mzNe2oAGPGwFVHLPeo8= =pRMQ -----END PGP SIGNATURE----- --Apple-Mail=_BA382536-4467-4C82-A1AD-D10EC9B98BB2-- From nobody Sat Apr 15 14:02:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877D8129466; Sat, 15 Apr 2017 14:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 DSWiiBDz3uJQ; Sat, 15 Apr 2017 14:02:39 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 A587C127444; Sat, 15 Apr 2017 14:02:39 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id a188so19415616pfa.2; Sat, 15 Apr 2017 14:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ImSasWSkxnUg22jhyNiwMjgC39zQTLzP+fL/l4s81y4=; b=bCCNV1bov0tlvVjDeSiSaR1NgDwsEQmozYgU1/m3XsK6O7PozZ4aUsj6v6Z0Wt7uF6 uPs1MOhv6eEeW17r7mUt2AByjAo1MYWdKD7ARbdQSuxgBwoWlr4HPqRwTOHMP6MShRGr rJjYodD4Sor8FMmw0n49eU8B7RTx/B98ia3J54K6sNSWJV6iN45/uGAH60n19p1OIOIP ZlTNF8AzK5fLTcJgVQ4/T2h5jBRzcDpCIQNDEPE2eSGDj4/2Qtv6JYFFlHxr5Zyi+gsB p/2aDYvzjTUts/Uz+WiGM4YIh8DiECql9FQOHwsEao694LxMGaLoQ7Uva8yh1D6OR0DU hu0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ImSasWSkxnUg22jhyNiwMjgC39zQTLzP+fL/l4s81y4=; b=ouztgYm5Nfq0nyy9UluvLL1tAhTyWezUYj3LEZPPfUXpqC8yx5uWulziMXqg461b94 JWVmadhijekMlU1s/ewh0RE5Yi0b+OfgexYSUwkBKCq0DspEsIV30UUvbM0a6Na+C3Vp VUan//xaeaUALsn69Z4yet/jFT7zYfT/Klqgw55tv8ohxtDhtzxlh6/z3+iMkwFBipVg ZX+Emme+h+NBN7OtKmLVe494p8ROMiBw0pCdOt5uU4nN55+LSJ0GPVZ3d+r67OeOyKu4 8JyKi15bsa6AzzhbUSssvmQjx5Kdc8qLXiaQnBj2Jv3FsVtG5ObfRW6yGQTpPxWyknSY /k4A== X-Gm-Message-State: AN3rC/5wOzuVTvOOhASjsXM5AC9P2LteK/7v+8NQgaBog0M6xKX32Mcc CMzFqoEdx/WdeA== X-Received: by 10.98.206.205 with SMTP id y196mr4367792pfg.108.1492290159228; Sat, 15 Apr 2017 14:02:39 -0700 (PDT) Received: from [192.168.178.26] ([118.148.126.238]) by smtp.gmail.com with ESMTPSA id y29sm9966609pfj.90.2017.04.15.14.02.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 14:02:38 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: otroan@employees.org, "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <2dc9c403-0441-3d3f-d5d5-3186e670f91e@gmail.com> Date: Sun, 16 Apr 2017 09:02:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 21:02:41 -0000 Comment at the end: On 16/04/2017 06:13, otroan@employees.org wrote: > Mirja, >=20 > [...] >=20 >>> I have no good answer. We got this wrong originally, so what can we d= o in the Internet Standard except document the problem? >> >> We could actually deprecate the HBH header, and eventually define a ne= w one/assign a new number (at some later point). And this is exactly the = case where I see a new extension header coming up. >> >> As I said in my original discuss it=E2=80=99s just very unsatisfying t= o change the HBH handling (correctly) and then say it=E2=80=99s not recom= mended to use it. >=20 > The recommendation not to use it, is because the expectation that an ap= plication can give all routers along the packet's delivery path instructi= ons, that will be adhered to is wrong. Essentially we're saying that the = HBH option should be mostly ignored, and I would expect mostly have appli= cability within one administrative domain. >=20 >> One more point: I recently realized is that given the destination opti= on and the HBH option use the same registry, it actually is very tempting= to simply use the destination option header with HBH options because no = current router will inspect it and only new boxes that support the new fe= ature (at the edge) may start looking into it. Just as another side note = on what we might see happening in future with this recommendation. >=20 > I don't understand why you see using a destination option solves anythi= ng. > That will just end up being subject to the same operational policies as= the HBH header. > And note any packet that doesn't have the TCP or UDP header directly fo= llowing the IP header has a significantly higher drop probability anyway.= >=20 >>> (I suspect that the real answer is that to install any kind of flow s= tate, we need to use an explicit flow state creation protocol, not hang i= t off a packet header designed mainly for stateless processing. If that s= ounds like a short explanation of why Integrated Services/RSVP failed, it= is. And it's surely out of scope for 2460bis.) >> >> I agree (I=E2=80=99m working on PLUS for this reason but that=E2=80=99= s a different topic). Nothing we have to or should address in this docume= nt. But we could be more clear and go the next step and deprecate HBH. I = didn=E2=80=99t follow the document or wg discuss closely but to my unders= tanding the option to deprecate HBH was not really discuss in the group. = Was it? >=20 > Some people have even been discussing deprecating extension header alto= gether. > The working group decided not to deprecate the HBH header at this point= =2E As in, we still think it can be rescued. I just went through the IANA registry. At the moment there are: 4 standards-track HbH options (jumbogram, router alert, RPL, MPL) 3 Experimental HbH options (Quick Start, SMF-DPD, IP-DFF) 1 US-DOD option (CALIPSO) I really don't see deprecation of all these as a possibility. RPL and MPL= are recent work; deprecating router alert would deprecate RSVP for IPv6.= RPL, MPL, and jumbograms are all clearly "consenting adults" scenarios w= here packets will not cross the Internet. Brian From nobody Sat Apr 15 15:07:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54413126D74; Sat, 15 Apr 2017 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 A8Ij1ZTKcqgG; Sat, 15 Apr 2017 15:07:32 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 2FD34124217; Sat, 15 Apr 2017 15:07:32 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id 34so18336249pgx.3; Sat, 15 Apr 2017 15:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=e5Bm0z6qdFzH3GVHmzXGaM6jnznYa522eBd17v01ny8=; b=h89NOD71uns7HQjRSZ3xN+WKa4GZNe1BwttuSupSek4whSM35DyQRJfpFfstP5dKZy S0+WfoHUFSZDvOHWHtbZPzlbIxZveFTxHgLVNLnmz92/pLFv5idzbONFKL6q9sxKkt4k 9gF3Pqt1bS0Fy8y833mNpSPRnHPgdHc1O7ZLPKLGDoMX/Og8+haRXfAhEfiROWfkC8Eb TkY9MrL2F7cIcDUASD80gxckf0JxX+E7mrI1OQ5DFIsBU7LLRVo27nq+C6PiDRCRcl/P SHkxfr+TAENtGel3QCpqn/vSXtgDegEDXlnYvnE8xF5cJTh3+rnJd9nhUDS+aj9JjxlP 0Plw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=e5Bm0z6qdFzH3GVHmzXGaM6jnznYa522eBd17v01ny8=; b=tVAkF0OctAMdWaYxXD09qhj5oM2JwQM4Ojk1SAe837J7QCniRXX8L0tYVhI5yRcYb7 RU7xMOpvMo23bU6o5Nhaa5B3T97NfP1+EFPavbHXBhpdCw6pqcdjXqmjfORNFN57j9CP eSepaghVJ0ps3wwxf6HjZR3oRz6lAeunFZkoPkbbxygDooB8kyJoeOtGdxvRwoSSSHfB 9Ax6FRyRdB8oWA8IYTad1SpoJcK/Jd25axnERQSXvKbqAWSXk4LD8mJ+gLNSm+X1V/8s YiHZU16tD5RAIne/bfXTp6zoIlAorrt9GrGcavEjT+7pXxaxhBd1KFsMpXH9mjW0los4 jO0w== X-Gm-Message-State: AN3rC/5Na5HmFnJ8s6tSDJMIl5NKgkAzhJiXUPwVeuNjFi0rq3ErMEyW DM5hS4cOex4hYA== X-Received: by 10.84.169.67 with SMTP id g61mr5966435plb.51.1492294051680; Sat, 15 Apr 2017 15:07:31 -0700 (PDT) Received: from [192.168.178.26] ([118.148.126.238]) by smtp.gmail.com with ESMTPSA id o10sm10035807pfe.78.2017.04.15.15.07.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 15:07:30 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden , "C. M. Heard" References: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> Cc: "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 16 Apr 2017 10:07:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 22:07:34 -0000 > Do we have any evidence that the guidance in RFC 3168 regarding reassem= bling IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is evidence I agree some text should be added to rfc2460bis, if = not, then maybe not. In any case, somebody needs to submit an erratum for RFC 3168, since it l= acks "Updates: 2460". Regards Brian On 16/04/2017 06:50, Bob Hinden wrote: > Mike, >=20 >> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >> >> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>> ... >>>>>>>> ----------------------------------------------------------------= ------ >>>>>>>> COMMENT: >>>>>>>> ----------------------------------------------------------------= ------ >>>>>>>> >>>>>>>> One question because I'm not sure if I interpret this correct to= make it >>>>>>>> part of my discuss: >>>>>>>> Section 4.5: "The number and content of the headers preceding th= e >>>>>>>> Fragment >>>>>>>> header of different fragments of the same original packet may >>>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>>> header in each fragment packet, are processed when the packets >>>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>>> those headers in the Offset zero fragment packet are retained i= n >>>>>>>> the reassembled packet." >>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class fiel= d) is >>>>>>>> copied from the first fragment? This doesn't seem to be correct,= however, >>>>>>>> also not sure what the correct answer is. I know this was not ch= anged in >>>>>>>> this revision but maybe we can still get this right. >>>>>>> >>>>>>> When fragments are created most of the fields are copied from the= IPv6 >>>>>>> headers (e.g., Source Address, Destination address, flow label, t= raffic >>>>>>> class, hop limit). Some like payload length, next header, and ho= p limi >>>>>>> t are modified. >>>>>>> >>>>>>> If I understand your question, the answer is yes, the ECN code po= int is >>>>>>> copied from the first fragment, but should be the same from all o= f the >>>>>>> fragments. >> >> That is inconsistent with the following guidance in RFC 3168 (see >> https://tools.ietf.org/html/rfc3168#section-5.3): >> >> 5.3. Fragmentation >> >> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >> Reassembly of a fragmented packet MUST NOT lose indications of >> congestion. In other words, if any fragment of an IP packet to be >> reassembled has the CE codepoint set, then one of two actions MUST b= e >> taken: >> >> * Set the CE codepoint on the reassembled packet. However, this >> MUST NOT occur if any of the other fragments contributing to >> this reassembly carries the Not-ECT codepoint. >> >> * The packet is dropped, instead of being reassembled, for any >> other reason. >> >> If both actions are applicable, either MAY be chosen. Reassembly of= >> a fragmented packet MUST NOT change the ECN codepoint when all of th= e >> fragments carry the same codepoint. >> >>>>>> My concern is that the ECN code point could be changed on one of t= he >>>>>> fragmented packets to signal congestion of a intermediate node and= >>>>>> then when you reassemble this information gets lost. That seems wr= ong. >>>>> >>>>> That is an interesting idea, but I think out of scope for advancing= this >>>>> document to Internet Standard. Then there is the question of how t= o >>>>> encode n of m fragments experienced congestion. Interesting future= work. >>>> >>>> Yes there might be some more further work needed but that still make= s the >>>> guidance in this text wrong. Maybe we can add some text that the Tra= ffic >>>> Class may be handled differently because it could be changed on the = path. >>> >>> Good point. It's not only ECN that can change; the DSCP can change to= o. >>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >>> for 2460bis to note this issue. >> >> It seems that we (6man WG) missed this because RFC 3168 was not marked= >> as updating RFC 2460. But in effect it did so for IPv6 implementations= >> of ECN, even though it was not written in an IP version-agnostic manne= r. >> >> At the very least text should be added to the description of the >> reassembly process that points the reader to RFC 3168 or its >> successor document. >=20 > Do we have any evidence that the guidance in RFC 3168 regarding reassem= bling IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is evidence I agree some text should be added to rfc2460bis, if = not, then maybe not. >=20 > Thanks, > Bob >=20 >=20 From nobody Sat Apr 15 15:14:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E982F1292D3; Sat, 15 Apr 2017 15:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 lv-FdTYAihPW; Sat, 15 Apr 2017 15:14:35 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 26B4C1287A5; Sat, 15 Apr 2017 15:14:35 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 34so18349339pgx.3; Sat, 15 Apr 2017 15:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=G9Fu3J0Kr4ABXGKRZ7rzWDEveO/qT/02PdS9Hq+uRtA=; b=Zi0hkeM7KsvCq2A1pvNid8uw9LcmeZkkS1nmFEWuc/2Ef7F+jU3aQjJIjQHDMt9FOv yb/001Xrqfy5OvhIFc6BAGHddX+uBOlAoaGDaXsO3LsH01Ql2qwrOHaoyA30rPi7lT74 Zkr3Zt8prj1J9mifdESZxrs/OMOY2uhGz7C6jWU3NQEO7EVblVhlSLyNu28CeSSqCdHH /zAZX7W6ug+Yl1oO5bww4sq7Ub58o7XYF8o0gKWwAzoOfDJBgxwMLCpL5z8n6WnKZLr1 b85Da/2uA8hXo3MvKjRW017/gvhyu0x5N0nJ5l00Pfc2tSb5gnu3FuzlZZsE/asWCved L0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=G9Fu3J0Kr4ABXGKRZ7rzWDEveO/qT/02PdS9Hq+uRtA=; b=m0voT4FFODDV7HRxu1LEc32cG/em1+YstwFCVKqF8ay2Y3ioXWM2AIAkH0tx3cvh7E qlbJlTd9rTxUHIAMjYLP6TwDpfsEPRBs1BeCXdv7oDE42nTvVThb9mkpun/Xpfd1qzu+ rvXxRxsvYq2BghkrlI546jZWO8s4kT5iYZPTA5DLHRprzY5RFZbA0FZvxMqYnIFGnyyA LleHeFr8eFXf8GyKi7oCs7IhvLov5qXuPj4uvxryA7v7RXGPa2gAZnVD5VFM4IaRtvLb O5oaubGtfqK9Y4HS4gOlZYGIABXf5jHcLIfQ97lRfBNSSB+ojFM3kfsSk0n1pVnfPFYY nGLQ== X-Gm-Message-State: AN3rC/7IhCMQpbzWvqjvxZP9FzVFFBAsBCaNKCAVDrO0TtxnYU6F/zU1 ehj6MRCROmJe9Hq5 X-Received: by 10.98.93.25 with SMTP id r25mr2144740pfb.103.1492294474502; Sat, 15 Apr 2017 15:14:34 -0700 (PDT) Received: from [192.168.178.26] ([118.148.126.238]) by smtp.gmail.com with ESMTPSA id g5sm10081388pfe.12.2017.04.15.15.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Apr 2017 15:14:34 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> Date: Sun, 16 Apr 2017 10:14:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 22:14:37 -0000 On 16/04/2017 01:49, Mirja Kuehlewind (IETF) wrote: > Hi Brian, >=20 > thanks for splitting the discussion up into it=E2=80=99s three piece. H= owever, i=E2=80=99m answering this one first because there is some relati= on to the other one on HBH. Further see below. >=20 >> Am 14.04.2017 um 04:28 schrieb Brian E Carpenter : >> >> And one more comment for today: >> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >> >> ... >>>> As it says in Section 4.8: >>>> >>>> Defining new IPv6 extension headers is not recommended. There has = to >>>> be a very clear justification why any new extension header is neede= d >>>> before it is standardized. Instead of defining new Extension >>>> Headers, it is recommended that the Destination Options header is >>>> used to carry optional information that must be examined only by a >>>> packet's destination node(s), because they provide better handling >>>> and backward compatibility. >>>> >>> Yes, this text is the text I have problem with. I think I would sugge= st to drop the first part and only have this part: >>> >>> "It is recommended to rather use the Destination Options header=20 >>> to carry optional information that must be examined only by a >>> packet's destination node(s), instead of defining new Extension >>> Headers, because they provide better handling >>> and backward compatibility." >> >> "Defining new IPv6 extension headers is not recommended" is a rather >> mild statement. There were certainly some in the WG who wanted >> a MUST NOT here. It's an operational and security concern: existing >> middleboxes, especially firewalls, are allergic to extension headers >> that they don't understand. This is unfortunate, since the design mode= l >> was that the forwarding path should be transparent to all headers, whi= ch >> meant that new headers could be deployed between consenting adults >> without any infrastructure issues. But this simply doesn't work in >> the real world - that's the main reason we wrote RFC7045. I think it's= >> worth quoting this: >> >> This combination of circumstances creates a "Catch-22" situation >> [Heller] for the deployment of any newly standardised extension >> header except for local use. It cannot be widely deployed because >> existing middleboxes will drop it on many paths through the Internet= =2E >> However, most middleboxes will not be updated to allow the new heade= r >> to pass until it has been proved safe and useful on the open >> Internet, which is impossible until the middleboxes have been >> updated. >> >> So, defining new IPv6 extension headers is not recommended, because >> they probably won't work across the Internet. But it isn't a MUST NOT,= >> because if there was a compelling operational case, we could do it and= >> the middleboxes would follow. >=20 > First of all yes, giving further explanation/background is definitely a= good thing to do, and maybe also provide a reference to rfc7045 if appro= priate. >=20 > I think I agree that I would not like to make a normative statement her= e, given that the circumstances are not due to the protocol design itself= but because of the current deployment situation we have (which in theory= could change in future). >=20 > However, instead of making a clear recommendation to not every define a= new extension header, I think I would prefer if the text was phrased in = the a way that would make the risk clear, give a clear recommendation to = rather use destination options if suitable, and then say nothing else. >=20 > Maybe you can work on some new text and then have a quick (?) check wit= h the wg which text is preferred. If there is clear consensus for one way= by the wg I will not further block this. I think I will leave that for the document editor. A large part of RFC704= 5 is about this issue but Bob can probably see best how to integrate it h= ere. >=20 > However, please see my next mail. >=20 > Mirja >=20 > P.S.: My understanding from the text above is that the new extension he= ader will be dropped but not the whole packets. Is that right? Because in= this case there are still ways for experimentation. No, the firewalls simply drop packets that they don't like. (This is the = main reason why SHIM6 is undeployable. But more seriously, it means that = even IPv6 fragmentation is impossible on some paths.) That's why we reall= y need draft-ietf-opsec-ipv6-eh-filtering to progress, so that there is c= onsistent guidance. Brian >=20 >=20 >> >> RFC 7045 was intended to nudge middlebox developers in the right >> direction, and similarly draft-ietf-opsec-ipv6-eh-filtering. But it's >> an uphill battle. >> >> Brian >> >=20 > . >=20 From nobody Sun Apr 16 04:41:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F7126E3A; Sun, 16 Apr 2017 04:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 KA9DAb7v-Grb; Sun, 16 Apr 2017 04:40:56 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 6B50D124D6C; Sun, 16 Apr 2017 04:40:56 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 16 Apr 2017 11:40:54 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0BA00D788D; Sun, 16 Apr 2017 04:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=OJ/4h778OPhmGAwU+Mgpuk6rqWA=; b= Mdz/wkj8pWII2J6RkYbntQaNGHf7gMNvq+pSbNkchXrMIx6I836BUKq+R/ioYdIr yjRNrQHCSYqrtCnjQT6lLx1O9yIVFNunwduuwu3rgjNgWdi/UmmxRW/GRuJH1aUH ympLn8UCvH1Qm74X08g3g+1Km28FHHGF2ALFs5ug4aE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=XxWB3AVHv9/Y1TE7g6vlN2P BfE24+oUodxLpqT7Ts7u9uVc0zjI5xob5ipUMdmD55lGf8D8V7zUL4O+dbLtZLmD Bs/2XGDpjXd5ty9wpYBK41ZK4YO5h+tHL/kStN1c6NAiAkxg+6X1ZMI1t9/dZGt5 quFVh6bc9/myxA4y9/zs= Received: from h.hanazo.no (77.16.75.18.tmi.telenormobil.no [77.16.75.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id AAF60D788B; Sun, 16 Apr 2017 04:40:53 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DE2EAA9D5EA2; Sun, 16 Apr 2017 13:40:51 +0200 (CEST) From: otroan@employees.org Message-Id: <0BFEC23F-6298-4CDE-A3C2-1D376E660A5A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_62BF0D32-2018-4D86-A9A6-5D34CEBE190E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Sun, 16 Apr 2017 13:40:51 +0200 In-Reply-To: <2dc9c403-0441-3d3f-d5d5-3186e670f91e@gmail.com> Cc: "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , The IESG , 6man-chairs@ietf.org To: Brian E Carpenter References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> <2dc9c403-0441-3d3f-d5d5-3186e670f91e@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 11:40:58 -0000 --Apple-Mail=_62BF0D32-2018-4D86-A9A6-5D34CEBE190E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I just went through the IANA registry. At the moment there are: >=20 > 4 standards-track HbH options (jumbogram, router alert, RPL, MPL) > 3 Experimental HbH options (Quick Start, SMF-DPD, IP-DFF) > 1 US-DOD option (CALIPSO) >=20 > I really don't see deprecation of all these as a possibility. RPL and = MPL are recent work; deprecating router alert would deprecate RSVP for = IPv6. RPL, MPL, and jumbograms are all clearly "consenting adults" = scenarios where packets will not cross the Internet. Thanks Brian. Cheers, Ole --Apple-Mail=_62BF0D32-2018-4D86-A9A6-5D34CEBE190E 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY81hDAAoJEL7aWKiYQt92E6oQAKjLFk3V6oktf/5+t7oK2zoB bHS4CokjgxWGTUrtVRkLtfZVKCFvuXm9VsfcxxboMq4URRmUb2PPDUSbVXlIaknA Ps6oKTLjBdLdv1ShzZNaS2YPDCHhLMC8cE46aGqaYJZycFuEIfaH4uDO3HFyl8EK c8nkhrE3PxGV28kCe1H+nhZb47Ul7mLk2y8IMv4igT6xaY1rLS7u6fwCuyOINFyC QPisJOFdtsRzKfJIc+QqoYfgkSFJDwKXXmac+GrK8MCCUSuOKlIc/I/vDR+r316s R+eEK7urazPdfZk181r2VL6Qyf5YO8NVuCTQWXs44EE7ZrYy9oBtjwDYET33vzEo o1froTSGsZGx8bTY6fBR2vbnFwXqlSBz90TD9I3eglf3rbzJoRXaTjfQnfP8IVOM 2rktu5kv9WhF5sYwB6OK+ucQNo9wuN57lNbDyoRXO6v8CFnaFKigiLxODu3YDK9a hyFooF+yHbX4+eTdV9Z/R7PHkac30c9hW1NIgpS8Lu5VYIuw1DtjQwcxmob0CXE8 JufEs5ewz5VS0Ee0tRFoPGFhvL/XAXkWLVklq8gFWT9UCXp4kw0jfw3Z184aPhM1 2ZzIDeRWarkW7ogMUJfUeX54qzZNLECksvXP7CWwsaAg5pD8vH3yaEW7Kn+D2npl 7rUWtUgr3z5mLlpanjxW =i0Qt -----END PGP SIGNATURE----- --Apple-Mail=_62BF0D32-2018-4D86-A9A6-5D34CEBE190E-- From nobody Sun Apr 16 04:57:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C76112741D; Sun, 16 Apr 2017 04:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 ollbV_iZYV2m; Sun, 16 Apr 2017 04:57:46 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id AC7CA126E3A; Sun, 16 Apr 2017 04:57:45 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 16 Apr 2017 11:57:45 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8F342D788D; Sun, 16 Apr 2017 04:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=sOsLLop5eiIik0g7p8Dx5BNECxg=; b= fttDaOXs1ePwEInA13EFkyvC3ssZIEM5vQ1RN6krcVdmb2O/y77jVJ4I33RcXiXN wTR3w9GyHyVlOoO71Znf6YT/L1lU2dyShFR5yUjjYl6+YY/Ay9hUP0pH53NTX56c mKWULEhVSHHD337n2L0UoNLlhUHn2yz855p4T82MHig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=HSWaK3d4sLZyYU33UkI9iav u77TtgG5NwogwQYv5bVYwZ2bD82WVpkAxE6JwjnM+ihrvfbkruf9j+YrmwkmKWBT epMd1SCcWtGUSfYqUxYI/qV9dQsXCykN2935Rhf5ikMyL3knWGlhCrPBkx5huPff 8B+6E8201G7wo43+2uz4= Received: from h.hanazo.no (77.16.75.18.tmi.telenormobil.no [77.16.75.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DC14AD788A; Sun, 16 Apr 2017 04:57:44 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 415BCA9D9065; Sun, 16 Apr 2017 13:57:40 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_30E1672A-2670-4364-B346-512BA12B11C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Sun, 16 Apr 2017 13:57:38 +0200 In-Reply-To: <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> Cc: "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , IESG , 6man-chairs@ietf.org To: Brian E Carpenter References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 11:57:48 -0000 --Apple-Mail=_30E1672A-2670-4364-B346-512BA12B11C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, Mirja, >>> This combination of circumstances creates a "Catch-22" situation >>> [Heller] for the deployment of any newly standardised extension >>> header except for local use. It cannot be widely deployed because >>> existing middleboxes will drop it on many paths through the = Internet. >>> However, most middleboxes will not be updated to allow the new = header >>> to pass until it has been proved safe and useful on the open >>> Internet, which is impossible until the middleboxes have been >>> updated. >>>=20 >>> So, defining new IPv6 extension headers is not recommended, because >>> they probably won't work across the Internet. But it isn't a MUST = NOT, >>> because if there was a compelling operational case, we could do it = and >>> the middleboxes would follow. >>=20 >> First of all yes, giving further explanation/background is definitely = a good thing to do, and maybe also provide a reference to rfc7045 if = appropriate. >>=20 >> I think I agree that I would not like to make a normative statement = here, given that the circumstances are not due to the protocol design = itself but because of the current deployment situation we have (which in = theory could change in future). >>=20 >> However, instead of making a clear recommendation to not every define = a new extension header, I think I would prefer if the text was phrased = in the a way that would make the risk clear, give a clear recommendation = to rather use destination options if suitable, and then say nothing = else. >>=20 >> Maybe you can work on some new text and then have a quick (?) check = with the wg which text is preferred. If there is clear consensus for one = way by the wg I will not further block this. >=20 > I think I will leave that for the document editor. A large part of = RFC7045 is about this issue but Bob can probably see best how to = integrate it here. I think what is in the document already is representing the working = group consensus. The issues of new / unknown extension headers, and how to distinguish = these from new transport protocols have been discussed from many angles. = The two main reasons for the strong recommendation against new extension = headers are: - most uses are already accommodated with the 3 existing containers = options (routing. hbh and destination) - sharing the same number space with IP protocols, makes it hard for = intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. There is already an opening / provision in the text for new extension = headers. The text only asks for these considerations to be made, before = proposing new ones. >> P.S.: My understanding from the text above is that the new extension = header will be dropped but not the whole packets. Is that right? Because = in this case there are still ways for experimentation. >=20 > No, the firewalls simply drop packets that they don't like. (This is = the main reason why SHIM6 is undeployable. But more seriously, it means = that even IPv6 fragmentation is impossible on some paths.) That's why we = really need draft-ietf-opsec-ipv6-eh-filtering to progress, so that = there is consistent guidance. Dropping only a header as in deleting it, would violate the = specification. And would certainly violate the expectation hosts have = from network behaviour. The opsec-ipv6-eh-filterting draft is at best dangerous and is = prohibitive of future evolution. I would strongly object to its = publication. With regards to Brian's point. No IETF recommendation will make much of = a difference if the network policy in place is to inspect transport = header information. Packets which do not have the transport header will = be subject to a higher drop probability. If there is any comfort IPv4 = fragments suffer a worse faith than IPv6 ones (in IPv4ng transport ports = are used for forwarding). Best regards, Ole --Apple-Mail=_30E1672A-2670-4364-B346-512BA12B11C4 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY81wzAAoJEL7aWKiYQt92+/EP/AhQEtyIKLPyOKL70QGELBUW 6nlVwCmVBFAKGoF9WZsj4GaEMHZxO9xp6bn8A4TJ6IGxnvjegfwBZWzaHBPJOhtj ZQeo+hWtS4sZ4xSdZIPBPM2DdZvU+JdhsrQtZ8vLS73sZRXZi9fGO8vPBcaFJI0E qdTBxZrpRTI8O/IM5dSmV9Q1YVeFblhpEXKrH/WtwMK4m79HQ9jC/Dn2fwZs7aX/ nEalcfvhiIWI7GBSOqc2DyeemBJoMM8f/RJzHrEZSGqbD0jn+wBIH+T48CskfutV ra+0tVaejo8drO0sUSX1Kxu23GUI4/TUzKYErzr6tP3DXFxi+Dk07J8ObThRX+IO 7zR9RKk7XJA4kb3uL7VvuCZd+r2XO23K5MGWIzFxEuM8KVQ6SmXi/vgmW++vTO9A xdlV1VJ6qp0cw7vsN5B/oDIIU7WrPsbdQupt319h3y37XbvQAC3BwPgjAWtchDlB tP4mIxADWli/Bg3qHhbnqDLgDmG14k8oplt3JRZO+NRS3cViLr+gASIuTNup2BnU x0h0haAOC4UGE6An7j0PYn8ed+071mGKUCsrwP5bJe7uw++fNXPl5yTn8ba8RB1F jrRlvLF6vVONXdG4L8u90lq3BhJLRzKdF+LzMY41D57Ng8G+otTnwmBIYkanH8bI wszJKLCdYH3yI2+DpPN6 =9+Tg -----END PGP SIGNATURE----- --Apple-Mail=_30E1672A-2670-4364-B346-512BA12B11C4-- From nobody Sun Apr 16 05:20:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38153124D6C for ; Sun, 16 Apr 2017 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 ni43dGEGIbGX for ; Sun, 16 Apr 2017 05:20:29 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 255C4127868 for ; Sun, 16 Apr 2017 05:20:28 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 16 Apr 2017 12:20:27 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6F49BD788D; Sun, 16 Apr 2017 05:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=SgyvGroIOY6KzUJdiF/4mnexkrI=; b= OzdvXZLddAHEw7qhWE8Quu0vcQ9tXMlN/D2Uaa8gMiojzlI9YKuudf9EoG85nDuF sAQ0r7O5NrMeJvYptIAB48LrY+rxAkivl9DOm3e0/iJx21Bh+1RxyYo1Wb0x30+i N4dG8ve6eGu1devdd0z/j6CmqB75xPYeNxiFa+SbNEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=M6t00vaD3lbnAC2G9g4Egfq cOJCvPLlceMdV5MvLHHjdDRBNLjGx3LaBvjQo38Kbp4u7N5VILrG08sPiBTYEL7W GOIXQaJY3+HiHPD/EQutkfg/JO5AIebhpHhTKsEI/mgUQ+nHdSu4WTH/pleDOtDw eMNx8rW4jWnW6NxypSjE= Received: from h.hanazo.no (77.16.75.18.tmi.telenormobil.no [77.16.75.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 65577D788A; Sun, 16 Apr 2017 05:20:26 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E64DCA9DD1E7; Sun, 16 Apr 2017 14:20:19 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6D5B9B8B-E0EC-4F0A-AF68-BB1CB0B0BC87"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Date: Sun, 16 Apr 2017 14:20:18 +0200 In-Reply-To: Cc: 6man WG , "Leddy, John" To: Robert Raszuk References: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 12:20:31 -0000 --Apple-Mail=_6D5B9B8B-E0EC-4F0A-AF68-BB1CB0B0BC87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Robert, >=20 > Let's observe that your claim is only partially correct. >=20 > Talking to real hardware designers I came to know that it cost nothing = to get into first 150-200 bytes of packet. >=20 > Yes aftee that you face cliff effect. >=20 > But are we really that concerned about headers beyond that ? If it wasn't clear, my point was: Even in _software_ looking deep into = the packet has a cost. Even when packets are DMA'ed directly into L3 cache. If of course depends. Both in software and in hardware having to do = pointer chasing is expensive (which you have to do for extension = headers, fixed offset is of course much cheaper). We have built hardware platforms that can get parse a complete packet at = line rate, so there is no fixed maximum parsable header size as such. I'll see if I can get some real measurements next week for fun. That = would be on a modern Intel platform with VPP. Best regards, Ole >=20 > On Apr 13, 2017 5:06 PM, wrote: > > As more of the service delivery path includes complex virtualized = environments with programmable data planes and general software based = IPV6 forwarding, the cost/benefit tradeoffs for implementing EH = processing changes =E2=80=93 even HbH. > > > > If the standard is heavily skewed toward more traditional Vendor = based ASIC/NPU forwarding preferences for their implementations, it does = future IPV6 development a disservice. > > > > Enabling some of these EH features to be configurable makes sense so = current constrained routers won=E2=80=99t be non-compliant with 2460bis = and therefore =E2=80=9Cmiddle boxes=E2=80=9D themselves, without = banning/deprecating/withholding and generally shutting down future work = in this area. >=20 > Indeed, and if there was an actual real use for a particular hop by = hop option that would obviously be implemented and supported. > today we don't see much use of it, which is also one reason why it is = filtered / not well supported. >=20 > So I would certainly be supportive of new and useful uses of the hop = by hop header. And much more so than workarounds like requiring routers = to parse deep into packets. Workarounds which are likely to just trigger = the weapons race. >=20 > Btw, even for high performance software routers there is a cost to = parse deeply into the packet. The memory subsystem is bottleneck, and = while processing packet #1 and #2 we prefetch cachelines for packet #3 = and #4. If it turns out that when processing packet #1 we need to fetch = one or more cache lines we have already lost. >=20 > Cheers, > Ole >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --Apple-Mail=_6D5B9B8B-E0EC-4F0A-AF68-BB1CB0B0BC87 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY82GDAAoJEL7aWKiYQt92zwsP/3QS3O9hLOhVE5fck5cF20Eu 0bpJjpp7xR4fHhzD48yTJ/gT0blDF3NcEBvkBvCdSd9Spz6Yt7KZ2lAniv9dACe1 OBqAb6jQzBRru4UudyXcdQeIuKMEXzC/HyMI7KZCBqVEaVsl38zvpkOWaWkFoXOc VaO3iqvbU8MiqhGwUQC8E25eM72LESWP+r7e4wOPefK9Y5wcmawh19wly7MOAiCH IGsxO8zNmSZSCI9Ahk8IbG0jdfFBEieXUW8yS7uvw9A7gywk3j0PQHHqLk6i0UiK htDUTR0/uSGcz3d1gRylgkVIA9Wc8+dnwfPnsGbwGYV/b8H0pZgggLMLg3nYm3vE I1ZNO7ksEjkTISoAV+ZsXeTc8D6jfg75WMkXKQnDA5Sb0YTidQ8m+Jrea91JdozA AhHnWP8ei8JhYnLVX2nFjbqQghGc8fbI7UZH6CyZ9KZcaIr8907TZa/ld9twcsH3 UQxBFYExTYBSHt8Wp+WMAi+PuNOik+BBybm00XCCBK4/MHpvlel5K1NICRhUk6Xh 4TteVV2Xj35S59R3Zxl4iigy68t8PYxvrLgzp6RxrDmKirx4dCOglmT360LElTcj rBrtFq4lFmvysnkxBy+zVr4pwJ4GFcr+l40PvQ3OSrge/cD1uQ+aLm2lo4offsgU iHntCjEWnaXV3Nhl/5ei =D2JW -----END PGP SIGNATURE----- --Apple-Mail=_6D5B9B8B-E0EC-4F0A-AF68-BB1CB0B0BC87-- From nobody Sun Apr 16 06:04:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF23B128B91 for ; Sun, 16 Apr 2017 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 c3tDNnYX0Q-t for ; Sun, 16 Apr 2017 06:04:46 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA13128B90 for ; Sun, 16 Apr 2017 06:04:46 -0700 (PDT) X-AuditID: 60721c4c-b47ff7000000bcc0-93-58f36be98982 Received: from VAADCEX47.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id AF.A9.48320.9EB63F85; Sun, 16 Apr 2017 09:04:43 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX47.cable.comcast.com (147.191.103.224) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 16 Apr 2017 09:04:40 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Sun, 16 Apr 2017 09:04:40 -0400 From: "Leddy, John" To: "otroan@employees.org" , Robert Raszuk CC: "6man WG" , "Leddy, John" Subject: Re: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Thread-Topic: [Tsv-art] TSV-ART review of draft-ietf-6man-rfc2460bis-09 Thread-Index: AQHSs6u9Y8ciS/x/aUKn/8KdY1N6M6HCruUAgACC74CABL6JKoAADE6A Date: Sun, 16 Apr 2017 13:04:40 +0000 Message-ID: <0FC09934-85E4-402F-8537-84F38CA98B4E@cable.comcast.com> References: <15D0891B-2F2E-46A4-8CCB-803D31ECB0EC@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.252] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsWSUOxpofs6+3OEwa79WhYvz75nspjctoLN omlhE7MDs8fBYx8ZPZYs+cnksXvjAqYA5igum5TUnMyy1CJ9uwSujKdH/zAVXDGseNy3gaWB cYNBFyMnh4SAiUT/w0ssXYxcHEIC25kk/q25C+UcYpR4euUxE4RzklFi38+TrCAtbAI6EjOm XQOzRQTCJNavOsYCYjMLuEp8X3qEuYuRg0NYwE2i5bUqRIm7xJlp21kgbDeJP6sOgbWyCKhK HFzSwAZi8wq4SGz98ZMJxBYSWM0s8b1NAsTmFHCU2PVxBTOIzSggJvH91BomiFXiEreezGeC +EBAYsme88wQtqjEy8f/wOaLCuhJzNz5lxEiriNx9voTKNtAYuvSfSwQtqLEv9nrWUBOZhbQ lFi/Sx9ivIPEmvn/oL5SlJjS/ZAd4kxBiZMzn0C1ikscPrKDdQKj9CwkF81CmDQLyaRZSCbN QjJpASPrKka5ssTElOTcjPzSEgMjveTEpJxUveT83OTE4hIQvYkRFPNFMj47GD9N8zjEKMDB qMTDy5/6OUKINbGsuDIXGFEczEoivEf8gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5vW7eihAS SE8sSc1OTS1ILYLJMnFwSjUwWkhwqMo2Rws73uuJPjtxBrN1ic764yqBV3X+nfdSmuB/UFso fEGT7r6aNxHzZ9f3pUicKo2doJeaph938gyTxhbr4qw9392/6xpMtJk1+duM+dPWtEq/YIr1 5ufi1OGOao0rMbXh/nlRIV3yrUhJXuKqj05tDx/eP7Tay7O9a32Gxj1GMzMlluKMREMt5qLi RACw3tFN9QIAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 13:04:48 -0000 T2xlLA0KDQpSZWFsIGRhdGEgaXMgYWx3YXlzIGhlbHBmdWwsIEkgdW5kZXJzdGFuZCBtb3JlIHdv cmsgcmVxdWlyZXMgbW9yZSBjeWNsZXMsIGJ1dCBJIHdhbnQgdG8gbG9vayBhdCB0aGUgb3ZlcmFs bCB3b3JrLg0KDQpNeSBpbnRlcmVzdCBpcyBpbiBsb29raW5nIGF0IHdoZXJlIHdlIGNhbiByZWR1 Y2UgdGhlIG92ZXJhbGwgYW1vdW50IG9mIHdvcmsgcmVxdWlyZWQgYnkgcmVkZXNpZ25pbmcgaG93 IHNvbWUgb2Ygb3VyIGFwcGxpY2F0aW9uIHBsYXRmb3JtcyB3b3JrLg0KVGhpbmdzIGxpa2Ugc3Rh dGUgZnVsbCBGVy9MQuKAmXMsIE5BVHMsIEFwcGxpY2F0aW9uIFByb3hpZXMsIFR1bm5lbHMgZW5j YXAvZGVjYXBz4oCmIGFyZSBleHBlbnNpdmUgYW5kIGFkZCBhIGxvdCBvZiBjb21wbGV4aXR5IGlu IHRoZSBkZXNpZ24gYW5kIG9wZXJhdGlvbiBvZiB0aGUgc3lzdGVtcy4gIEhvdyBleHBlbnNpdmUg YXJlIHRoZXNlIGZ1bmN0aW9ucyBpbiBBU0lDcyBvciBzb2Z0d2FyZSBmb3J3YXJkaW5nPw0KDQpJ 4oCZdmUgc2VlbiB2aXJ0dWFsaXplZCBFbmNhcCBwcm9kdWN0cyAo4oCcYmFzZWQgb24gc3RhbmRh cmRz4oCdKSB0aGF0IGhhdmUgYSBzZXJpZXMgb2YgaGVhZGVyIGVuY2FwL2RlY2FwIG9uIGRpc3Ry aWJ1dGVkIG5vZGVzIHRoYXQgYXJlIGp1c3QgYW1hemluZyB0byBjb25zaWRlcjogDQpFdGhlcm5l dCwgSVAgZW5jYXAsIEVTUCwgVURQLCBNUExTLCBHUkUsIFZMWExBTiwgTlNILCBFdGhlcm5ldCwg SVAgLT4gaW4gYWxsIHNlcmllcyBvZiBjb21iaW5hdGlvbnMsIGR1cGxpY2F0aW9uIGFuZCBvcmRl cmluZy4gIFRocm93IGluIGEgZmV3IE5BVHMvTEJzL0ZXcy9Qcm94aWVzIGFsb25nIHRoZSBwYXRo IGZvciBwcm9jZXNzaW5nLiAgRm9yZ2V0IGFib3V0IHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0 byBtYWtlIFBNVFVEIHdvcmsgaW4gdGhlc2UgZW52aXJvbm1lbnRzLg0KDQpXZSBhcmUgbG9va2lu ZyB0byBzaW1wbGlmeSB0aGlzIGJ5IGRvaW5nIOKAnGEgbGl0dGxlIG1vcmXigJ0gd29yayBhdCB0 aGUgTmV0d29yayBsYXllciB3aGVyZSBhcHByb3ByaWF0ZSwgbm90IG5lY2Vzc2FyaWx5IGV2ZXJ5 IG5vZGUuDQpQdXNoIHN0YXRlIHRvIHRoZSBhcHBsaWNhdGlvbi9jbGllbnRzIGZvciBmbG93cy9z ZXNzaW9ucyBhbmQgY2FycnkgdGhhdCBzdGF0ZSBpbiB0aGUgcGFja2V0cyB0aGF0IGNhbiBiZSBw cm9jZXNzZWQgaW4gc3RhbmRhcmQgd2F5cy4NCklQVjYgZ2l2ZXMgdXMgdGhlIGFiaWxpdHkgdG8g c3RhcnQgc2ltcGxpZnlpbmcganVzdCBiZWNhdXNlIHRoZSBhZGRyZXNzIHNwYWNlIGlzIGxhcmdl ciwgYnV0IHRoZXJlIGlzIG11Y2ggbW9yZSBwb3NzaWJsZSBhbmQgbmVlZGVkLg0KDQpJIHVuZGVy c3RhbmQgbWFueSBvZiB0aGVzZSBmdW5jdGlvbnMgbWF5IGJlIGNvbnNpZGVyZWQg4oCcbWlkZGxl IGJveOKAnSBmdW5jdGlvbnMsIG15IGdvYWwgaXMgdG8gcmVtb3ZlIGFzIG1hbnkg4oCcbWlkZGxl IGJveGVz4oCdIGFzIHBvc3NpYmxlIGluIG91ciBpbmZyYXN0cnVjdHVyZSwNCg0KSm9obg0KDQpP biA0LzE2LzE3LCA4OjIwIEFNLCAib3Ryb2FuQGVtcGxveWVlcy5vcmciIDxvdHJvYW5AZW1wbG95 ZWVzLm9yZz4gd3JvdGU6DQoNCiAgICBSb2JlcnQsDQogICAgDQogICAgPiANCiAgICA+IExldCdz IG9ic2VydmUgdGhhdCB5b3VyIGNsYWltIGlzIG9ubHkgcGFydGlhbGx5IGNvcnJlY3QuDQogICAg PiANCiAgICA+IFRhbGtpbmcgdG8gcmVhbCBoYXJkd2FyZSBkZXNpZ25lcnMgSSBjYW1lIHRvIGtu b3cgdGhhdCBpdCBjb3N0IG5vdGhpbmcgdG8gZ2V0IGludG8gZmlyc3QgMTUwLTIwMCBieXRlcyBv ZiBwYWNrZXQuDQogICAgPiANCiAgICA+IFllcyBhZnRlZSB0aGF0IHlvdSBmYWNlIGNsaWZmIGVm ZmVjdC4NCiAgICA+IA0KICAgID4gQnV0IGFyZSB3ZSByZWFsbHkgdGhhdCBjb25jZXJuZWQgYWJv dXQgaGVhZGVycyBiZXlvbmQgdGhhdCA/DQogICAgDQogICAgDQogICAgSWYgaXQgd2Fzbid0IGNs ZWFyLCBteSBwb2ludCB3YXM6IEV2ZW4gaW4gX3NvZnR3YXJlXyBsb29raW5nIGRlZXAgaW50byB0 aGUgcGFja2V0IGhhcyBhIGNvc3QuDQogICAgRXZlbiB3aGVuIHBhY2tldHMgYXJlIERNQSdlZCBk aXJlY3RseSBpbnRvIEwzIGNhY2hlLg0KICAgIA0KICAgIElmIG9mIGNvdXJzZSBkZXBlbmRzLiBC b3RoIGluIHNvZnR3YXJlIGFuZCBpbiBoYXJkd2FyZSBoYXZpbmcgdG8gZG8gcG9pbnRlciBjaGFz aW5nIGlzIGV4cGVuc2l2ZSAod2hpY2ggeW91IGhhdmUgdG8gZG8gZm9yIGV4dGVuc2lvbiBoZWFk ZXJzLCBmaXhlZCBvZmZzZXQgaXMgb2YgY291cnNlIG11Y2ggY2hlYXBlcikuDQogICAgV2UgaGF2 ZSBidWlsdCBoYXJkd2FyZSBwbGF0Zm9ybXMgdGhhdCBjYW4gZ2V0IHBhcnNlIGEgY29tcGxldGUg cGFja2V0IGF0IGxpbmUgcmF0ZSwgc28gdGhlcmUgaXMgbm8gZml4ZWQgbWF4aW11bSBwYXJzYWJs ZSBoZWFkZXIgc2l6ZSBhcyBzdWNoLg0KICAgIA0KICAgIEknbGwgc2VlIGlmIEkgY2FuIGdldCBz b21lIHJlYWwgbWVhc3VyZW1lbnRzIG5leHQgd2VlayBmb3IgZnVuLiBUaGF0IHdvdWxkIGJlIG9u IGEgbW9kZXJuIEludGVsIHBsYXRmb3JtIHdpdGggVlBQLg0KICAgIA0KICAgIEJlc3QgcmVnYXJk cywNCiAgICBPbGUNCiAgICANCiAgICA+IA0KICAgID4gT24gQXByIDEzLCAyMDE3IDU6MDYgUE0s IDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4gd3JvdGU6DQogICAgPiA+IEFzIG1vcmUgb2YgdGhlIHNl cnZpY2UgZGVsaXZlcnkgcGF0aCBpbmNsdWRlcyBjb21wbGV4IHZpcnR1YWxpemVkIGVudmlyb25t ZW50cyB3aXRoIHByb2dyYW1tYWJsZSBkYXRhIHBsYW5lcyBhbmQgZ2VuZXJhbCBzb2Z0d2FyZSBi YXNlZCBJUFY2IGZvcndhcmRpbmcsIHRoZSBjb3N0L2JlbmVmaXQgdHJhZGVvZmZzIGZvciBpbXBs ZW1lbnRpbmcgRUggcHJvY2Vzc2luZyBjaGFuZ2VzIOKAkyBldmVuIEhiSC4NCiAgICA+ID4NCiAg ICA+ID4gSWYgdGhlIHN0YW5kYXJkIGlzIGhlYXZpbHkgc2tld2VkIHRvd2FyZCBtb3JlIHRyYWRp dGlvbmFsIFZlbmRvciBiYXNlZCBBU0lDL05QVSBmb3J3YXJkaW5nIHByZWZlcmVuY2VzIGZvciB0 aGVpciBpbXBsZW1lbnRhdGlvbnMsIGl0IGRvZXMgZnV0dXJlIElQVjYgZGV2ZWxvcG1lbnQgYSBk aXNzZXJ2aWNlLg0KICAgID4gPg0KICAgID4gPiBFbmFibGluZyBzb21lIG9mIHRoZXNlIEVIIGZl YXR1cmVzIHRvIGJlIGNvbmZpZ3VyYWJsZSBtYWtlcyBzZW5zZSBzbyBjdXJyZW50IGNvbnN0cmFp bmVkIHJvdXRlcnMgd29u4oCZdCBiZSBub24tY29tcGxpYW50IHdpdGggMjQ2MGJpcyBhbmQgdGhl cmVmb3JlIOKAnG1pZGRsZSBib3hlc+KAnSB0aGVtc2VsdmVzLCB3aXRob3V0IGJhbm5pbmcvZGVw cmVjYXRpbmcvd2l0aGhvbGRpbmcgYW5kIGdlbmVyYWxseSBzaHV0dGluZyBkb3duIGZ1dHVyZSB3 b3JrIGluIHRoaXMgYXJlYS4NCiAgICA+IA0KICAgID4gSW5kZWVkLCBhbmQgaWYgdGhlcmUgd2Fz IGFuIGFjdHVhbCByZWFsIHVzZSBmb3IgYSBwYXJ0aWN1bGFyIGhvcCBieSBob3Agb3B0aW9uIHRo YXQgd291bGQgb2J2aW91c2x5IGJlIGltcGxlbWVudGVkIGFuZCBzdXBwb3J0ZWQuDQogICAgPiB0 b2RheSB3ZSBkb24ndCBzZWUgbXVjaCB1c2Ugb2YgaXQsIHdoaWNoIGlzIGFsc28gb25lIHJlYXNv biB3aHkgaXQgaXMgZmlsdGVyZWQgLyBub3Qgd2VsbCBzdXBwb3J0ZWQuDQogICAgPiANCiAgICA+ IFNvIEkgd291bGQgY2VydGFpbmx5IGJlIHN1cHBvcnRpdmUgb2YgbmV3IGFuZCB1c2VmdWwgdXNl cyBvZiB0aGUgaG9wIGJ5IGhvcCBoZWFkZXIuIEFuZCBtdWNoIG1vcmUgc28gdGhhbiB3b3JrYXJv dW5kcyBsaWtlIHJlcXVpcmluZyByb3V0ZXJzIHRvIHBhcnNlIGRlZXAgaW50byBwYWNrZXRzLiBX b3JrYXJvdW5kcyB3aGljaCBhcmUgbGlrZWx5IHRvIGp1c3QgdHJpZ2dlciB0aGUgd2VhcG9ucyBy YWNlLg0KICAgID4gDQogICAgPiBCdHcsIGV2ZW4gZm9yIGhpZ2ggcGVyZm9ybWFuY2Ugc29mdHdh cmUgcm91dGVycyB0aGVyZSBpcyBhIGNvc3QgdG8gcGFyc2UgZGVlcGx5IGludG8gdGhlIHBhY2tl dC4gVGhlIG1lbW9yeSBzdWJzeXN0ZW0gaXMgYm90dGxlbmVjaywgYW5kIHdoaWxlIHByb2Nlc3Np bmcgcGFja2V0ICMxIGFuZCAjMiB3ZSBwcmVmZXRjaCBjYWNoZWxpbmVzIGZvciBwYWNrZXQgIzMg YW5kICM0LiBJZiBpdCB0dXJucyBvdXQgdGhhdCB3aGVuIHByb2Nlc3NpbmcgcGFja2V0ICMxIHdl IG5lZWQgdG8gZmV0Y2ggb25lIG9yIG1vcmUgY2FjaGUgbGluZXMgd2UgaGF2ZSBhbHJlYWR5IGxv c3QuDQogICAgPiANCiAgICA+IENoZWVycywNCiAgICA+IE9sZQ0KICAgID4gDQogICAgPiANCiAg ICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCiAgICA+IGlwdjZAaWV0Zi5vcmcNCiAgICA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCiAgICA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgPiANCiAgICANCiAgICANCg0K From nobody Sun Apr 16 08:38:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABBA126C22; Sun, 16 Apr 2017 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 kGHWWB7HwgkC; Sun, 16 Apr 2017 08:38:11 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 6C9651200F1; Sun, 16 Apr 2017 08:38:11 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id c55so72498800wrc.3; Sun, 16 Apr 2017 08:38:11 -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=fyJ06siiSOlECarEOdbYuScHnuf6EeoqwtvjMAXSbG4=; b=ZBySuOn3SQ5h474Fcw1AZZK3EnX6nmxoIOQ56QrTmq+NTBHHFIgD9g80pVuMSvrqiN 90Ajdcg7lIOVk2UM7UeVB8pMW3LcEYwXFEpxlROyLqm09DVrk/uZT1393JIWuQNbhQwx gO9MFP0e1NDBMydkxsYcFw7zY/L8/gzE/raGfO8/Q+hNf8UMQFHjC1wGFfR8bPb2r2Ru pGN3NT0cK4O0wUJGYmjBtJZPZWv45VBx5gl73JpXeFexBA0TIWuq2gk1Pocz1f9zagBc BZxrS6uYrkLE1oP7dd+aXNV9HzvhiEfktT4XgD1YWijJCYqFrysg/48zL6jiUzaOzg3Y KOdA== 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=fyJ06siiSOlECarEOdbYuScHnuf6EeoqwtvjMAXSbG4=; b=VevBWYlCFWXsuJAOEsMBvES4ReQ2MKcl4h5xRQHqntWnqQ9G5NMoVkMzeLDdq/CiTL Q6CrvD6rIFBrAlBsB80irNOTv2GYKsCRcf182hypRmsBzeTw0CxZCosf2j74378bfgIT 05f5trGd7Eg8ODntFTZfvr7UexymNkgN8/Wp6snim7Qk/7dWUIAtal5QQVj1LFVPsOYy X7vxUYBwxlDRBL5+dlEByzDuYRJvYmJaC5PPOuYA/WgabeyCY7fAGgZ2b6zsJ5x35yzj uJ4D6A4bJsEeVDyW4EyHwo2U7m9KJXVrhE2rXojiyyLEicIqH7T3+uVOtQOdUaDft5Gp i6yQ== X-Gm-Message-State: AN3rC/4ZtFrGUPXzpwwPGaF7MTJUE8MyQsysB9uTXn9cKFsKpTvsmO/U zrbOykqhkQEIxw== X-Received: by 10.223.128.200 with SMTP id 66mr16227139wrl.197.1492357089880; Sun, 16 Apr 2017 08:38:09 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:7dbc:7389:c3ea:20fe? ([2601:647:4d01:db10:7dbc:7389:c3ea:20fe]) by smtp.gmail.com with ESMTPSA id b188sm6875677wmh.6.2017.04.16.08.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Apr 2017 08:38:08 -0700 (PDT) From: Bob Hinden Message-Id: <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_188C7D55-CD88-45C7-9B47-C99F1F411251"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Sun, 16 Apr 2017 08:38:01 -0700 In-Reply-To: Cc: Bob Hinden , Brian Carpenter , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man-chairs@ietf.org To: =?utf-8?Q?Ole_Tr=C3=B8an?= References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Apr 2017 15:38:14 -0000 --Apple-Mail=_188C7D55-CD88-45C7-9B47-C99F1F411251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >=20 > Brian, Mirja, >=20 >>>> This combination of circumstances creates a "Catch-22" situation >>>> [Heller] for the deployment of any newly standardised extension >>>> header except for local use. It cannot be widely deployed because >>>> existing middleboxes will drop it on many paths through the = Internet. >>>> However, most middleboxes will not be updated to allow the new = header >>>> to pass until it has been proved safe and useful on the open >>>> Internet, which is impossible until the middleboxes have been >>>> updated. >>>>=20 >>>> So, defining new IPv6 extension headers is not recommended, because >>>> they probably won't work across the Internet. But it isn't a MUST = NOT, >>>> because if there was a compelling operational case, we could do it = and >>>> the middleboxes would follow. >>>=20 >>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>=20 >>> I think I agree that I would not like to make a normative statement = here, given that the circumstances are not due to the protocol design = itself but because of the current deployment situation we have (which in = theory could change in future). >>>=20 >>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>=20 >>> Maybe you can work on some new text and then have a quick (?) check = with the wg which text is preferred. If there is clear consensus for one = way by the wg I will not further block this. >>=20 >> I think I will leave that for the document editor. A large part of = RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >=20 > I think what is in the document already is representing the working = group consensus. > The issues of new / unknown extension headers, and how to distinguish = these from new transport protocols have been discussed from many angles. = The two main reasons for the strong recommendation against new extension = headers are: > - most uses are already accommodated with the 3 existing containers = options (routing. hbh and destination) > - sharing the same number space with IP protocols, makes it hard for = intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >=20 > There is already an opening / provision in the text for new extension = headers. The text only asks for these considerations to be made, before = proposing new ones. I agree. I also note that the text in this section was derived from RFC6564, = which updated RFC2460. Specifically from Section 3 of RFC6564: Mindful of the need for compatibility with existing IPv6 deployments, new IPv6 extension headers MUST NOT be created or specified, unless no existing IPv6 extension header can be used by specifying a new option for that existing IPv6 extension header. New extension headers are allowed (just not recommended) and the next = paragraph in the Section specifies a format that should be used for new = Extension headers. I think there is a lot of flexibility going forward. Bob >=20 >>> P.S.: My understanding from the text above is that the new extension = header will be dropped but not the whole packets. Is that right? Because = in this case there are still ways for experimentation. >>=20 >> No, the firewalls simply drop packets that they don't like. (This is = the main reason why SHIM6 is undeployable. But more seriously, it means = that even IPv6 fragmentation is impossible on some paths.) That's why we = really need draft-ietf-opsec-ipv6-eh-filtering to progress, so that = there is consistent guidance. >=20 > Dropping only a header as in deleting it, would violate the = specification. And would certainly violate the expectation hosts have = from network behaviour. >=20 > The opsec-ipv6-eh-filterting draft is at best dangerous and is = prohibitive of future evolution. I would strongly object to its = publication. >=20 > With regards to Brian's point. No IETF recommendation will make much = of a difference if the network policy in place is to inspect transport = header information. Packets which do not have the transport header will = be subject to a higher drop probability. If there is any comfort IPv4 = fragments suffer a worse faith than IPv6 ones (in IPv4ng transport ports = are used for forwarding). >=20 > Best regards, > Ole --Apple-Mail=_188C7D55-CD88-45C7-9B47-C99F1F411251 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY84/ZAAoJEK7rdBF357uoV6IH/2g/L4jjGuqcJuqMQla4lTQw pnb5hHDevkizISQShvnLSkhENuCiitts+QbAJKvPQwlefdwDLud3cAGwJfHznJ5q 6naB3bviggFzThCMD/oEg7xn6P9GuqfOY+ITIBIiSsfvsMMRGfPiuOleNIXWAKBI PHMONZcby21NBV6Joz6GI1k9XM8wiGLFfdD6rvYpTnlO+rbpqMJD47CypMEycHWq EJTZZVWSIS4uhJBSOKqjPdewA+K2NtfmzFobxnEIY2kNOFNoeNxqQtdGafUQ5bcj eK/fb9A9ZyFylmrVNGmPQYWT4MeOw4b2m+bGHNuEHxFINWr+5Qu0oJ5/Lcn1Pao= =cT7+ -----END PGP SIGNATURE----- --Apple-Mail=_188C7D55-CD88-45C7-9B47-C99F1F411251-- From nobody Sun Apr 16 17:10:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE3E129417 for ; Sun, 16 Apr 2017 17:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jcem90EmcYR for ; Sun, 16 Apr 2017 17:10:30 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 849C9129412 for ; Sun, 16 Apr 2017 17:10:30 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id g60so25471620qtd.3 for ; Sun, 16 Apr 2017 17:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D0a4wcg8/C6AmwT/Lz0MIebT4Ed/XZ+LD8G+1VaFkrg=; b=FdrzANXWnNbjmdFuYHuTKdDsfcWqF7efejRXB0ONiWWbW1JF+yF79YnIsO2b1dj2aR Uloy7OuMMpXQj1FkLN7iPkGg/Q7C+TZa30mu6OW3HUF/kLSrlMf3rmxLBIifr/lbcRdc 39MRYAZ/HoBI+RK5a0iyBQEcsCf4w2w3XLjBMLdQ/70lMconUHjMq/hptxE+w6Tyt+UI cLfCyloK6ar5JBc2ql8u/ekjrWaEvtL2oN1Hu+Pv7YxBT81/+nPC/LH8DbV3IaUx7HBX oDMgvRZ1LeQqUg4johNj7iYrXxphv7o/ad7ViW4B1NvbiO9F1TUeVWnIGfwH7gFO82mM /HPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D0a4wcg8/C6AmwT/Lz0MIebT4Ed/XZ+LD8G+1VaFkrg=; b=eRwBS3V7TLhm7vrNdMm/sOcJ3V/Wtgw20m1FMLbK3R0le4edDYBvj028kfA4rF/skP KJeKeapf9hKIF5nppAU4hESN25YAtI/HQNy2ZBunGlId8YX71KibtMv186Kh1BpPaWV4 ssQD0NqUAKvdaoCGSq8sQWzofxwb1a7EcyZwtgpot99jJCx0NbQmrvr6JrvxoZLxfhJU UXPLrpZZJCiz9xHR3d6FfYHmXUYW5w0rp7MopdnbKjbuCU9fAsfIfOaw2TrQpoCTYUn5 rgeeRrX9X470WII8CXLRxWmnznAy38EZYbXHEyMzjzn/HNDFz7czYpbVcr9xurICZiSy V5IA== X-Gm-Message-State: AN3rC/4GuNHRD4GjO3eLurBKaN6igVuYadpFQ0oZ7oPunsrcxGMM6ZZK lFX9xRO1nae1Jm7R+1XqnjQS4pKCqw== X-Received: by 10.200.34.144 with SMTP id f16mr7322020qta.186.1492387829529; Sun, 16 Apr 2017 17:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Sun, 16 Apr 2017 17:10:28 -0700 (PDT) In-Reply-To: <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <870ca7b4-2ea5-83e8-699e-4f13071a7453@gmail.com> <9632609F-3B70-4DAA-A8C5-440DB9F73B70@employees.org> From: Tom Herbert Date: Sun, 16 Apr 2017 17:10:28 -0700 Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Ole Troan Cc: "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, 6man-chairs@ietf.org, 6man WG , The IESG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 00:10:32 -0000 On Sat, Apr 15, 2017 at 11:13 AM, wrote: > Mirja, > > [...] > >>> I have no good answer. We got this wrong originally, so what can we do = in the Internet Standard except document the problem? >> >> We could actually deprecate the HBH header, and eventually define a new = one/assign a new number (at some later point). And this is exactly the case= where I see a new extension header coming up. >> >> As I said in my original discuss it=E2=80=99s just very unsatisfying to = change the HBH handling (correctly) and then say it=E2=80=99s not recommend= ed to use it. > > The recommendation not to use it, is because the expectation that an appl= ication can give all routers along the packet's delivery path instructions,= that will be adhered to is wrong. Essentially we're saying that the HBH op= tion should be mostly ignored, and I would expect mostly have applicability= within one administrative domain. > >> One more point: I recently realized is that given the destination option= and the HBH option use the same registry, it actually is very tempting to = simply use the destination option header with HBH options because no curren= t router will inspect it and only new boxes that support the new feature (a= t the edge) may start looking into it. Just as another side note on what we= might see happening in future with this recommendation. > > I don't understand why you see using a destination option solves anything= . > That will just end up being subject to the same operational policies as t= he HBH header. > And note any packet that doesn't have the TCP or UDP header directly foll= owing the IP header has a significantly higher drop probability anyway. > >>> (I suspect that the real answer is that to install any kind of flow sta= te, we need to use an explicit flow state creation protocol, not hang it of= f a packet header designed mainly for stateless processing. If that sounds = like a short explanation of why Integrated Services/RSVP failed, it is. And= it's surely out of scope for 2460bis.) >> >> I agree (I=E2=80=99m working on PLUS for this reason but that=E2=80=99s = a different topic). Nothing we have to or should address in this document. = But we could be more clear and go the next step and deprecate HBH. I didn= =E2=80=99t follow the document or wg discuss closely but to my understandin= g the option to deprecate HBH was not really discuss in the group. Was it? > > Some people have even been discussing deprecating extension header altoge= ther. > The working group decided not to deprecate the HBH header at this point. = As in, we still think it can be rescued. > Ole, I hope HBH can be rescued also! The alternative to putting L3 information in seems to be to embed the information somewhere in the transport layer. Mobile throughput guidance (draft-flinck-mobile-throughput-guidance) suggests to put this in TCP options, PLUS suggested to put this data in protocol header in UDP payload, and we have seen other similar proposals. In these proposals, the intent was that intermediate devices would perform DPI into transport layer or the payload, and in some cases it was even suggested that intermediate devices might modify UDP payload etc. Personally, I think these violate the end to end model, but there were arguments that they don't. I believe HBH options (and really all EH) is a classic chicken an egg problem: they are not supported in the Internet because no one uses them, and no one uses them because they're not supported in the Internet. This stalemate may be changing though in some networks that have control over the devices so that HBH could be meaningfully deployed (the allowance that routers may ignore them is critical for this). I imagine this why the issue of EH insertion versus tunneling is so important as HBH can be very useful for transit over particular networks. Tom > Cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sun Apr 16 20:57:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D684B127076; Sun, 16 Apr 2017 20:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 6aSUiCJvyfz9; Sun, 16 Apr 2017 20:57:32 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 51AAE1201F2; Sun, 16 Apr 2017 20:57:32 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id f10so47014333uaa.2; Sun, 16 Apr 2017 20:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9qSpwBJiuyxckedV/XhoXy+EnzY8fg3sSjqfpbHew2Y=; b=koQH4LQu5efIp09KuO0r9mNRqoaMjKpA+MTZh5gByON6oNd3K4MebJqfQH/18KvNZq BMRBTfE7lHGfdKHPZnUEoPkWYK09towaJapkV22gJLsFyv4InhatGc/xxx/+FZYwM9UU VYMML1UANN89k0iY2H+0N8XtKjUtdae27AbsQgeD85rtC0BUIWsHoGtG8VHpLxARBL/p ATxzuUVNQ6/Kz7/emT7GAqHngvIHPxhfhfit2JKa4G36Isc/51zH10WCZNfkDaAUBr7a mG39LB3asugJTAjtLfYuMLQ5BYg41LWTQnBVqhURTmjW6vv8dHmBoPx0PC8PJ3ZL1LQb EN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9qSpwBJiuyxckedV/XhoXy+EnzY8fg3sSjqfpbHew2Y=; b=RTc8sKRoroZ7x/y+tgpLiPq62UPgA+j6D/eEUv0tsoZBsBUpte5VnVF34aXQZJ4rB/ NoiNvqI2KLw0zk33IeTv8MDrckyfwDxPGPJr8wfOaqDqh95C/2BKCsMvVhJhVGtvK0Qc 4IbYqLax7fzXrg71bKN7XFYhS7MWhI1BkKmsIhCkfqEsV+iR5rrBVJI+ykMZV/8t+yoh Nmx3tcdDdF6fyLPlB5YSaKtAOCLrDA4ij7uaUTw6p9/25p9o9nH/EzgXHI+ASQYgTqo+ WXGZqJCHMT0cXNPb+euD4+Nf1i8HV454jNOuUbEmkRGzB8jqdkX8bfSxQhxpQE7AIoY1 1Ggw== X-Gm-Message-State: AN3rC/42ozlpJfWg5rDxuoKW6PFs6iCIPFqx2ByKpaAyabf5U5e1JNkj emdm7wWhIl0XGHqDsckVn6IWLw/+bw== X-Received: by 10.176.81.246 with SMTP id h51mr9047506uaa.75.1492401451160; Sun, 16 Apr 2017 20:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.123.214 with HTTP; Sun, 16 Apr 2017 20:57:30 -0700 (PDT) In-Reply-To: <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> From: Suresh Krishnan Date: Sun, 16 Apr 2017 23:57:30 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden Cc: =?UTF-8?Q?Ole_Tr=C3=B8an?= , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , "Mirja Kuehlewind (IETF)" , IESG , Brian Carpenter , 6man-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 03:57:34 -0000 Hi Mirja/Bob, On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden wrote: > Hi, > >> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >> >> Brian, Mirja, >> >>>>> This combination of circumstances creates a "Catch-22" situation >>>>> [Heller] for the deployment of any newly standardised extension >>>>> header except for local use. It cannot be widely deployed because >>>>> existing middleboxes will drop it on many paths through the Internet. >>>>> However, most middleboxes will not be updated to allow the new header >>>>> to pass until it has been proved safe and useful on the open >>>>> Internet, which is impossible until the middleboxes have been >>>>> updated. >>>>> >>>>> So, defining new IPv6 extension headers is not recommended, because >>>>> they probably won't work across the Internet. But it isn't a MUST NOT= , >>>>> because if there was a compelling operational case, we could do it an= d >>>>> the middleboxes would follow. >>>> >>>> First of all yes, giving further explanation/background is definitely = a good thing to do, and maybe also provide a reference to rfc7045 if approp= riate. >>>> >>>> I think I agree that I would not like to make a normative statement he= re, given that the circumstances are not due to the protocol design itself = but because of the current deployment situation we have (which in theory co= uld change in future). >>>> >>>> However, instead of making a clear recommendation to not every define = a new extension header, I think I would prefer if the text was phrased in t= he a way that would make the risk clear, give a clear recommendation to rat= her use destination options if suitable, and then say nothing else. >>>> >>>> Maybe you can work on some new text and then have a quick (?) check wi= th the wg which text is preferred. If there is clear consensus for one way = by the wg I will not further block this. >>> >>> I think I will leave that for the document editor. A large part of RFC7= 045 is about this issue but Bob can probably see best how to integrate it h= ere. >> >> I think what is in the document already is representing the working grou= p consensus. >> The issues of new / unknown extension headers, and how to distinguish th= ese from new transport protocols have been discussed from many angles. The = two main reasons for the strong recommendation against new extension header= s are: >> - most uses are already accommodated with the 3 existing containers opti= ons (routing. hbh and destination) >> - sharing the same number space with IP protocols, makes it hard for int= ermediate devices depending on parsing the header chain to find transport i= nformation if new headers were introduced. >> >> There is already an opening / provision in the text for new extension he= aders. The text only asks for these considerations to be made, before propo= sing new ones. > > I agree. > > I also note that the text in this section was derived from RFC6564, which= updated RFC2460. Specifically from Section 3 of RFC6564: > > Mindful of the need for compatibility with existing IPv6 deployments, > new IPv6 extension headers MUST NOT be created or specified, unless > no existing IPv6 extension header can be used by specifying a new > option for that existing IPv6 extension header. Yes. This text was arrived at after a lot of discussion in the 6man WG during the development of the draft that became RFC6564. > > New extension headers are allowed (just not recommended) and the next par= agraph in the Section specifies a format that should be used for new Extens= ion headers. I think there is a lot of flexibility going forward. Yep. I think the above warning is issued because a node processing an unknown extension header will simply drop it, and this makes incremental deployability of these new extension headers difficult over the Internet. Thanks Suresh From nobody Sun Apr 16 21:43:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFB312947A for ; Sun, 16 Apr 2017 21:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=swm.pp.se 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 IRNFV0mCJNYm for ; Sun, 16 Apr 2017 21:43:32 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6102129461 for ; Sun, 16 Apr 2017 21:43:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 18914A6; Mon, 17 Apr 2017 06:43:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492404230; bh=dFVM+SJwb2Hp8NjfN2gdawUJ51VL+KaWOuwz+jBLyj4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=thuMM6JEEa1iNhQqw93abXME9mVLMG6QW4y3TEHVHyv7nKj0DVY5nXfqUVzuQD2tb fGUc8Ng3t5dSlV8I6nLBo0sNhfHzw0mUXX16VBnIKq10kra2XdtLUS9Lwyw8KCMmSL djYsDGUzP5o/K2wzQLx/jEC8OGU5fIU3Tn99rpL4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F32C2A5; Mon, 17 Apr 2017 06:43:49 +0200 (CEST) Date: Mon, 17 Apr 2017 06:43:49 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: Fred Templin , james woodyatt , "ipv6@ietf.org" , Dave Thaler Subject: Re: Route Information Options in IPv6 Neighbor Discovery In-Reply-To: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> Message-ID: References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 04:43:35 -0000 On Fri, 14 Apr 2017, Fred Baker wrote: >> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine would be in scope for this documents security section. For instance, what would an SAVI enabled L2 switch that inspects ND entries do when it sees this RIO entry in ND? > > As specified, I think it would ignore them. It looks at the NA to > determine what {IP address, MAC address} or {IP address, MAC address, > Port #} association it should enforce. It has no illusion that this is > the only data present. So the question becomes, is this desired behaviour? Sounds to me that there needs to be SAVI document enhancement for this RIO in ND then, for things to continue functioning properly (as I imagine if something sends RIO in ND to somewhere, there is expectation that any antispoofing device should allow for return traffic as well). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Apr 16 23:19:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45981273E2 for ; Sun, 16 Apr 2017 23:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 udKu2Uxwc934 for ; Sun, 16 Apr 2017 23:19:00 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 1ADD3127010 for ; Sun, 16 Apr 2017 23:19:00 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 63so7643095pgh.0 for ; Sun, 16 Apr 2017 23:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ArCzibi8ULYWl7pKCbLl/ELNU5vCHbaF2DzeVPEK0j0=; b=FlI0DguxaAcP+gpwKntHwyaZD8i/vvt+mfFbDDm5hu2te8YPDfP9BJV6sFRgddMl05 Fx+UW+LTKmnA6dwsnSv6HKqbbZaivADZ6v+PqGyZi81w+cs+12s+wEA0ZDBm/RBGyybE KW1kWnNBJaZKJ6Z3IbJgLe3T5Wjz2N7/qQIAogPer/TpRCXNkyOWDGn3xXlL6wATHxUs fpU8CwiNyjAz4t/z6QDFTlTuN2byXmc9u5EIHCgKRFJwC+6HcNN0CXGD3Q1bRU1+onLO 6vPQYzAwtNfpFESLqzo4hpbm763/vwqdMNm/gmmp3gecytdityKdJpWcx/bmbXzC3002 PZNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ArCzibi8ULYWl7pKCbLl/ELNU5vCHbaF2DzeVPEK0j0=; b=hW4uppGgnWe2IiqQCN8nEypJfXY6j2gYOEMvM53LlzHRopg+6U3DW4r6cZjk6g3v7v Y36hHZlx1M8rSylluVKM9LmoQ1ZPwV4gEMrJBhe4VOzdl/mgfbBpNmaAc4X3WFVzMpdz zfWYgZ1en0aF/sjS69IH03NWVoLA6xpTCVa3N0IBxluV/XCcsQeFs3EZoIj6FiL6BcRt 5Xw5CyJfIOPGPgRxHY+1fopyNw6DHEVHjQFPpIPYVhDzQuWr1/6Zumy6a3voCLvTEj64 VAoNcspys0KqUpoK5RDki27I9L9x9YwXxKLneYvfhBFGuvUPX+3JGi/4ZSOD1B3QDq2N qMVg== X-Gm-Message-State: AN3rC/6ytzkUBJ/RvHeazFwE4gmGZGtQBLkYNw3IhttyjqDgoAT1OEBW 3v9A16AF894mJw== X-Received: by 10.98.24.68 with SMTP id 65mr9821636pfy.191.1492409939632; Sun, 16 Apr 2017 23:18:59 -0700 (PDT) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 133sm15387989pfy.106.2017.04.16.23.18.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Apr 2017 23:18:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Route Information Options in IPv6 Neighbor Discovery From: Fred Baker In-Reply-To: Date: Sun, 16 Apr 2017 23:19:16 -0700 Cc: Fred Templin , james woodyatt , "ipv6@ietf.org" , Dave Thaler Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 06:19:02 -0000 > On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson = wrote: >=20 > On Fri, 14 Apr 2017, Fred Baker wrote: >=20 >>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would be in scope for this documents security section. For instance, = what would an SAVI enabled L2 switch that inspects ND entries do when it = sees this RIO entry in ND? >>=20 >> As specified, I think it would ignore them. It looks at the NA to = determine what {IP address, MAC address} or {IP address, MAC address, = Port #} association it should enforce. It has no illusion that this is = the only data present. >=20 > So the question becomes, is this desired behaviour? Sounds to me that = there needs to be SAVI document enhancement for this RIO in ND then, for = things to continue functioning properly (as I imagine if something sends = RIO in ND to somewhere, there is expectation that any antispoofing = device should allow for return traffic as well). Please feel free to make specific suggestions. https://tools.ietf.org/html/rfc6620 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) https://tools.ietf.org/html/rfc6959 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 = bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) https://tools.ietf.org/html/rfc7039 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) https://tools.ietf.org/html/rfc7219 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7219) https://tools.ietf.org/html/rfc7513 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) https://tools.ietf.org/html/rfc8074 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) From nobody Mon Apr 17 09:00:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879313152D; Mon, 17 Apr 2017 09:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Ey2Skk0pfTEz; Mon, 17 Apr 2017 09:00:08 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FFD131513; Mon, 17 Apr 2017 09:00:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id F0AA56D255; Mon, 17 Apr 2017 12:00:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=smLpLB3Tc/v2yCxAPJPJsoKdA NE=; b=kNt/Fpls9opoy5qJeciLolca1TuwRBWD7hEWP9dPwkFL+UrJXe9JYU24H in0n/HXK5mxIPdlWXFBGc34yzm7UHc7pzlgfDJ09Dk+EL7jso/jrwth3K0hz0+XE hzL/fm1hkDhHbvDYgbDX9+lo0Oc7+HbqJKEaJq7VxIlvzHmZHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=bZkCmrhDgcAUqxQNC96 RbI5fbOR3ZcHKVHLBEZaFjlLpdXTmHJAEwJ+39y6d6p6OJDX4zaD4Za8Ht+He/Pt NqyZ+fF5110NzgRJ2PDg79kHl4jhDkOyynBqmW7ClNT59dK2gxbq7kTjr0gUDNiG BUKc+qUAl/xWebenw0rIrFkE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C54356D254; Mon, 17 Apr 2017 12:00:05 -0400 (EDT) Received: from mail-qk0-f170.google.com (unknown [209.85.220.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 57AB76D23A; Mon, 17 Apr 2017 12:00:03 -0400 (EDT) Received: by mail-qk0-f170.google.com with SMTP id d131so108020882qkc.3; Mon, 17 Apr 2017 09:00:03 -0700 (PDT) X-Gm-Message-State: AN3rC/5DPj4vXL96chSWATsRwxKJm0ZmNmJZaNAb5HVja4tqr2zyUslM Cpt8NLcHN7bxhjNnUmafdnDxeFCGfw== X-Received: by 10.55.82.68 with SMTP id g65mr8978041qkb.116.1492444801437; Mon, 17 Apr 2017 09:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 08:59:41 -0700 (PDT) From: "C. M. Heard" Date: Mon, 17 Apr 2017 08:59:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: 6MAN <6man@ietf.org>, tsvwg Cc: Bob Hinden , Brian Carpenter , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: EB069A54-2386-11E7-93C6-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 16:00:11 -0000 [ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ] On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: > On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>> ... >>>>>>>> ------------------------------------------------------------------= ---- >>>>>>>> COMMENT: >>>>>>>> ------------------------------------------------------------------= ---- >>>>>>>> >>>>>>>> One question because I'm not sure if I interpret this correct to m= ake it >>>>>>>> part of my discuss: >>>>>>>> Section 4.5: "The number and content of the headers preceding the >>>>>>>> Fragment >>>>>>>> header of different fragments of the same original packet may >>>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>>> header in each fragment packet, are processed when the packets >>>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>>> those headers in the Offset zero fragment packet are retained in >>>>>>>> the reassembled packet." >>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field)= is >>>>>>>> copied from the first fragment? This doesn't seem to be correct, h= owever, >>>>>>>> also not sure what the correct answer is. I know this was not chan= ged in >>>>>>>> this revision but maybe we can still get this right. >>>>>>> >>>>>>> When fragments are created most of the fields are copied from the I= Pv6 >>>>>>> headers (e.g., Source Address, Destination address, flow label, tra= ffic >>>>>>> class, hop limit). Some like payload length, next header, and hop = limi >>>>>>> t are modified. >>>>>>> >>>>>>> If I understand your question, the answer is yes, the ECN code poin= t is >>>>>>> copied from the first fragment, but should be the same from all of = the >>>>>>> fragments. >> >> That is inconsistent with the following guidance in RFC 3168 (see >> https://tools.ietf.org/html/rfc3168#section-5.3): >> >> 5.3. Fragmentation >> >> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >> Reassembly of a fragmented packet MUST NOT lose indications of >> congestion. In other words, if any fragment of an IP packet to be >> reassembled has the CE codepoint set, then one of two actions MUST be >> taken: >> >> * Set the CE codepoint on the reassembled packet. However, this >> MUST NOT occur if any of the other fragments contributing to >> this reassembly carries the Not-ECT codepoint. >> >> * The packet is dropped, instead of being reassembled, for any >> other reason. >> >> If both actions are applicable, either MAY be chosen. Reassembly of >> a fragmented packet MUST NOT change the ECN codepoint when all of the >> fragments carry the same codepoint. >> >>>>>> My concern is that the ECN code point could be changed on one of the >>>>>> fragmented packets to signal congestion of a intermediate node and >>>>>> then when you reassemble this information gets lost. That seems wron= g. >>>>> >>>>> That is an interesting idea, but I think out of scope for advancing t= his >>>>> document to Internet Standard. Then there is the question of how to >>>>> encode n of m fragments experienced congestion. Interesting future w= ork. >>>> >>>> Yes there might be some more further work needed but that still makes = the >>>> guidance in this text wrong. Maybe we can add some text that the Traff= ic >>>> Class may be handled differently because it could be changed on the pa= th. >>> >>> Good point. It's not only ECN that can change; the DSCP can change too. >>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >>> for 2460bis to note this issue. >> >> It seems that we (6man WG) missed this because RFC 3168 was not marked >> as updating RFC 2460. But in effect it did so for IPv6 implementations >> of ECN, even though it was not written in an IP version-agnostic manner. >> >> At the very least text should be added to the description of the >> reassembly process that points the reader to RFC 3168 or its >> successor document. > > Do we have any evidence that the guidance in RFC 3168 regarding reassembl= ing > IPv6 fragments is implemented? I don=E2=80=99t know, but think if it the= re is > evidence I agree some text should be added to rfc2460bis, if not, then > maybe not. Since I lack the expertise to answer that question, I'm hoping that someone in TSVWG will see this message and do so. Regardless of the answer to that question, my position would be that since 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of the Traffic Class field, the following modification to 2460bis Section 4.5 would be an appropriate way to deal with Mirja's comment: OLD: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. NEW: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet; however, nodes that support Explicit Congestion Notification [RFC3168] may use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. Note that this would not cause 2460bis itself to levy an additional requirement on how IPv6 nodes reassemble fragmented packets. It would simply be making note of a requirement that is already levied by RFC 3168. Thanks and regards, Mike Heard From nobody Mon Apr 17 09:15:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3AF131583; Mon, 17 Apr 2017 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Cl1gitk3J0Wu; Mon, 17 Apr 2017 09:15:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E47C13158E; Mon, 17 Apr 2017 09:15:42 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 343326D5D7; Mon, 17 Apr 2017 12:15:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=Tnv68YVu7Mpw 8q1n26YToZoBgDk=; b=WbsvWcrzvGGRtZuGDCwCqkK9aYHNckyfAmXp8DmVKOuP EdKvqSCVJs9hjjdx927/w0T6J0S1MknIejbQ3YmW/+ZpOqX2K9IfP/hZvZLaHwlI 3/P8KMNfVoVgWzoMOKOGSuEhMXWfdksnJs4gOfSe26HPja0veweDjxxfeyyP19E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=MPNiZQ yEoacFRiAQcC7LG4lq2KoEvZ8twQWDkbc2kUb/Q5CUh5Y2i2rpuUiv+TJK/sqVob eakc+04IvSyjQNdUk5guR5Pau1qRsSMLpYVInIBSbLuYG6SURk0yENuZRsU/UOw4 NSHwY8VxNfnXcd/xaj53vlOK60hsAIdHCVsIE= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2BE0F6D5D6; Mon, 17 Apr 2017 12:15:41 -0400 (EDT) Received: from mail-qk0-f181.google.com (unknown [209.85.220.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 669226D5D0; Mon, 17 Apr 2017 12:15:40 -0400 (EDT) Received: by mail-qk0-f181.google.com with SMTP id f133so108431338qke.2; Mon, 17 Apr 2017 09:15:40 -0700 (PDT) X-Gm-Message-State: AN3rC/6T5MsK4R+88Jqw+PTINPeMSw2O7xKnM9Atn/nMyidCygD4Ck9B tRdWv5150QZWKfvOkH7AxsR1PDzStg== X-Received: by 10.233.223.6 with SMTP id t6mr8664870qkf.191.1492445739849; Mon, 17 Apr 2017 09:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 09:15:19 -0700 (PDT) In-Reply-To: References: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> From: "C. M. Heard" Date: Mon, 17 Apr 2017 09:15:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Brian E Carpenter Cc: Bob Hinden , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 198FD8A2-2389-11E7-BDCC-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 16:15:47 -0000 On Sat, Apr 15, 2017 at 3:07 PM, Brian E Carpenter wrote: >> Do we have any evidence that the guidance in RFC 3168 regarding >> reassembling IPv6 fragments is implemented? I don=E2=80=99t know, but t= hink if >> it there is evidence I agree some text should be added to rfc2460bis, if >> not, then maybe not. > > In any case, somebody needs to submit an erratum for RFC 3168, since it > lacks "Updates: 2460". I started to do that and then noticed that RFC 3168 also lacks "Updates: 79= 1". Instead, RFC 3168 updates RFC 2474, which in turn obsoletes RFC 1349, which in turn updates RFC 791 (and several other IPv4 RFCs). But RFC 2474 itself lacks "Updates: 2460". So maybe the erratum should be filed against RFC 247= 4. On the other hand, all that RFC 2460 Section 7 does with respect to the Traffic Class field is to define a set of general requirements and defer al= l the details to future RFCs. So tt's not clear to me whether RFC 2474 does, = in fact, update RFC 2460. I'll leave the decision on whether to file the errat= um to someone else who has better skills at navigating these tangled webs. Mike Heard From nobody Mon Apr 17 10:44:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B5A1316FF; Mon, 17 Apr 2017 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dell.com header.b=OEL0cik0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=ooWZq514 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 B7PiCUKOTR0L; Mon, 17 Apr 2017 10:44:48 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39896131713; Mon, 17 Apr 2017 10:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492451085; x=1523987085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uYWI23RK3DpCBDjflwXGY2aOi+55N8MO7BJZbWrSclM=; b=OEL0cik0sdi2hyjmPWm6Dk1rzDpq4frcZydeBEobOUZzJJU9pheRY2W2 cjNMQXx7UHOGa1UGrbnNoKJaN2M0hYf5ZF+Z3Wju7Lg8JoF8ahU6w+EWi n20M2JObg7WJ07R5G2IsvTWo6/hffWW7cfEHebzpBna3Gf4wlGrO3la7i 8=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 12:44:44 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 23:44:43 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3HHibst028986 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Apr 2017 13:44:42 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3HHibst028986 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492451082; bh=eDfEiRSzraZ+wDE7pnTumlIlW1Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ooWZq514aIRbeWx7h8uyV0TIYYfC4v83ypV95fZaypxUyEQLAsUVK4sBE3ai4OWwX Vp7TshuotovddFh4I3ZH2QuU8eLNk9p0I5r3To/21eDiOPnF5168W4lVT+y6Si9DRc jrmiHQ/NpQu/9yaMACl7r5FTZFdH68vnJKqzePR0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3HHibst028986 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 17 Apr 2017 13:44:24 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3HHiMf6030754 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 17 Apr 2017 13:44:23 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0266.001; Mon, 17 Apr 2017 13:44:22 -0400 To: "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg CC: "draft-ietf-6man-rfc2460bis@ietf.org" , Bob Hinden , "Mirja Kuehlewind (IETF)" , IESG , "6man Chairs" <6man-chairs@ietf.org> Subject: =?utf-8?B?UkU6IFt0c3Z3Z10gIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRy?= =?utf-8?B?YWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA5OiAod2l0aCBESVNDVVNTIGFu?= =?utf-8?Q?d_COMMENT)?= Thread-Topic: =?utf-8?B?W3RzdndnXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHSt5O2XmG3ecLMEEGFzIpNOX7b0KHJ0i7Q Date: Mon, 17 Apr 2017 17:44:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:44:51 -0000 RXh0cmFjdGluZyB0aGUga2V5IHBvcnRpb25zIG9mIHRleHQ6DQoNCj4+VGhhdCBpcyBpbmNvbnNp c3RlbnQgd2l0aCB0aGUgZm9sbG93aW5nIGd1aWRhbmNlIGluIFJGQyAzMTY4IChzZWUNCj4+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPj4NCj4+IDUu My4gIEZyYWdtZW50YXRpb24NCj4+DQo+PiAgIEVDTi1jYXBhYmxlIHBhY2tldHMgTUFZIGhhdmUg dGhlIERGIChEb24ndCBGcmFnbWVudCkgYml0IHNldC4NCj4+ICAgUmVhc3NlbWJseSBvZiBhIGZy YWdtZW50ZWQgcGFja2V0IE1VU1QgTk9UIGxvc2UgaW5kaWNhdGlvbnMgb2YNCj4+ICAgY29uZ2Vz dGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBhbnkgZnJhZ21lbnQgb2YgYW4gSVAgcGFja2V0IHRv IGJlDQo+PiAgIHJlYXNzZW1ibGVkIGhhcyB0aGUgQ0UgY29kZXBvaW50IHNldCwgdGhlbiBvbmUg b2YgdHdvIGFjdGlvbnMgTVVTVCBiZQ0KPj4gICB0YWtlbjoNCj4+DQo+PiAgICAgICogU2V0IHRo ZSBDRSBjb2RlcG9pbnQgb24gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4gIEhvd2V2ZXIsIHRoaXMN Cj4+ICAgICAgICBNVVNUIE5PVCBvY2N1ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBj b250cmlidXRpbmcgdG8NCj4+ICAgICAgICB0aGlzIHJlYXNzZW1ibHkgY2FycmllcyB0aGUgTm90 LUVDVCBjb2RlcG9pbnQuDQo+Pg0KPj4gICAgICAqIFRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgaW5z dGVhZCBvZiBiZWluZyByZWFzc2VtYmxlZCwgZm9yIGFueQ0KPj4gICAgICAgIG90aGVyIHJlYXNv bi4NCj4+DQo+PiAgIElmIGJvdGggYWN0aW9ucyBhcmUgYXBwbGljYWJsZSwgZWl0aGVyIE1BWSBi ZSBjaG9zZW4uICBSZWFzc2VtYmx5IG9mDQo+PiAgIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBO T1QgY2hhbmdlIHRoZSBFQ04gY29kZXBvaW50IHdoZW4gYWxsIG9mIHRoZQ0KPj4gICBmcmFnbWVu dHMgY2FycnkgdGhlIHNhbWUgY29kZXBvaW50Lg0KDQo+IFJlZ2FyZGxlc3Mgb2YgdGhlIGFuc3dl ciB0byB0aGF0IHF1ZXN0aW9uLCBteSBwb3NpdGlvbiB3b3VsZCBiZSB0aGF0IHNpbmNlDQo+IDI0 NjBiaXMgYWxyZWFkeSBkZWZlcnMgdG8gUkZDIDI0NzQgYW5kIFJGQyAzMTY4IHJlZ2FyZGluZyB0 aGUgaGFuZGxpbmcgb2YNCj4gdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQsIHRoZSBmb2xsb3dpbmcg bW9kaWZpY2F0aW9uIHRvIDI0NjBiaXMgU2VjdGlvbiA0LjUNCj4gd291bGQgYmUgYW4gYXBwcm9w cmlhdGUgd2F5IHRvIGRlYWwgd2l0aCBNaXJqYSdzIGNvbW1lbnQ6DQo+IA0KPiBPTEQ6DQo+ICAg ICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBG cmFnbWVudA0KPiAgICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2Ft ZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ICAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMg YXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gICAgICAgaGVhZGVyIGluIGVh Y2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCj4gICAg ICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5 LiAgT25seQ0KPiAgICAgICB0aG9zZSBoZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVu dCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ICAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQu DQo+IE5FVzoNCj4gICAgICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBw cmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ICAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21l bnRzIG9mIHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tldCBtYXkNCj4gICAgICAgZGlmZmVyLiAgV2hh dGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiAgICAg ICBoZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUg cGFja2V0cw0KPiAgICAgICBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFnbWVudHMg Zm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ICAgICAgIHRob3NlIGhlYWRlcnMgaW4gdGhlIE9mZnNl dCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQgaW4NCj4gICAgICAgdGhlIHJlYXNz ZW1ibGVkIHBhY2tldDsgaG93ZXZlciwgbm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxpY2l0DQo+ICAg ICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBtYXkgdXNlIGluZm9ybWF0aW9u IGluIHRoZQ0KPiAgICAgICBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsIGZyYWdtZW50IHBh Y2tldHMgdG8gcmVjb25zdHJ1Y3QgdGhlDQo+ICAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4g dGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gDQo+IE5vdGUgdGhhdCB0aGlzIHdvdWxkIG5vdCBj YXVzZSAyNDYwYmlzIGl0c2VsZiB0byBsZXZ5IGFuIGFkZGl0aW9uYWwNCj4gcmVxdWlyZW1lbnQg b24gaG93IElQdjYgbm9kZXMgcmVhc3NlbWJsZSBmcmFnbWVudGVkIHBhY2tldHMuIEl0IHdvdWxk DQo+IHNpbXBseSBiZSBtYWtpbmcgbm90ZSBvZiBhIHJlcXVpcmVtZW50IHRoYXQgaXMgYWxyZWFk eSBsZXZpZWQgYnkNCj4gUkZDIDMxNjguDQoNCkluIHdoaWNoIGNhc2UsIHRoZSBSRkMgMzE2OCBy ZXF1aXJlbWVudCBzaG91bGQgYmUgc3RhdGVkIGUuZy46DQoNCk9MRDoNCiAgICAgIFRoZSBudW1i ZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KICAg ICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVudHMgb2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFj a2V0IG1heQ0KICAgICAgZGlmZmVyLiAgV2hhdGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJl Y2VkaW5nIHRoZSBGcmFnbWVudA0KICAgICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0 LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCiAgICAgIGFycml2ZSwgcHJpb3IgdG8g cXVldWVpbmcgdGhlIGZyYWdtZW50cyBmb3IgcmVhc3NlbWJseS4gIE9ubHkNCiAgICAgIHRob3Nl IGhlYWRlcnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQg aW4NCiAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQpORVc6DQogICAgICBUaGUgbnVtYmVy IGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCiAgICAg IGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tl dCBtYXkNCiAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNl ZGluZyB0aGUgRnJhZ21lbnQNCiAgICAgIGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwg YXJlIHByb2Nlc3NlZCB3aGVuIHRoZSBwYWNrZXRzDQogICAgICBhcnJpdmUsIHByaW9yIHRvIHF1 ZXVlaW5nIHRoZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQogICAgICB0aG9zZSBo ZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGlu DQogICAgICB0aGUgcmVhc3NlbWJsZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBv cnQgRXhwbGljaXQNCiAgICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBtYXkg dXNlIGluZm9ybWF0aW9uIGluIHRoZQ0KICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBmcm9tIGFu eSBvciBhbGwgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdA0KICAgICAgdGhlIFRyYWZm aWMgQ2xhc3MgZmllbGQgaW4gdGhlIHJlYXNzZW1ibGVkIHBhY2tldCBpbiBvcmRlciB0byBtZWV0 DQogICAgICBSRkMgMzE2OCdzIHJlcXVpcmVtZW50cywgZS5nLiwgdGhhdCByZWFzc2VtYmx5IG5v dCBsb3NlIGluZGljYXRpb25zDQogICAgICBvZiBjb25nZXN0aW9uLCBzZWUgU2VjdGlvbiA1LjMg b2YgUkZDIDMxNjggZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQoNClBvaW50aW5nIHRoZSBp bXBsZW1lbnRlciBhdCBTZWN0aW9uIDUuMyBvZiBSRkMgMzE2OCBpcyBiZXR0ZXIgdGhhbg0KaG9w aW5nIHNoZSBmaWd1cmVzIG91dCBvbiBoZXIgb3duIHRoYXQgc2hlIG91Z2h0IHRvIHRha2UgYSBs b29rIGF0IGl0IC4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQy4gTS4gSGVhcmQNCj4gU2VudDogTW9uZGF5LCBBcHJpbCAxNywgMjAxNyAxMjow MCBQTQ0KPiBUbzogNk1BTiA8Nm1hbkBpZXRmLm9yZz47IHRzdndnIDx0c3Z3Z0BpZXRmLm9yZz4N Cj4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzQGlldGYub3JnOyBCb2IgSGluZGVuDQo+ IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1 ZWhsZXdpbmQubmV0PjsNCj4gSUVTRyA8aWVzZ0BpZXRmLm9yZz47IDZtYW4gQ2hhaXJzIDw2bWFu LWNoYWlyc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt0c3Z3Z10gTWlyamEgS8O8aGxld2lu ZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtDQo+IDA5OiAod2l0aCBE SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gWyBUU1ZXRyBhZGRlZCB0byBzb2xpY2l0IGFkdmlj ZSBvbiBpbXBsZW1lbnRhdGlvbiBvZiBSRkMgMzE4NiBTZWN0aW9uIDUuMyBdDQo+IA0KPiBPbiBT YXQsIEFwciAxNSwgMjAxNyBhdCAxMTo1MCBBTSwgQm9iIEhpbmRlbiB3cm90ZToNCj4gPiBPbiBB cHIgMTUsIDIwMTcsIGF0IDQ6NTMgQU0sIEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdy b3RlOg0KPiA+PiBPbiBGcmksIDE0IEFwciAyMDE3IDE0OjI4OjQ0ICsxMjAwIEJyaWFuIEUgQ2Fy cGVudGVyIHdyb3RlOg0KPiA+Pj4gT24gMTMvMDQvMjAxNyAyMzozNiwgTWlyamEgS3VlaGxld2lu ZCAoSUVURikgd3JvdGU6DQo+ID4+PiAuLi4NCj4gPj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4+Pj4+PiBDT01NRU5UOg0KPiA+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+IE9uZSBxdWVzdGlvbiBiZWNhdXNlIEknbSBub3Qgc3VyZSBpZiBJIGludGVycHJl dCB0aGlzIGNvcnJlY3QgdG8NCj4gbWFrZSBpdA0KPiA+Pj4+Pj4+PiBwYXJ0IG9mIG15IGRpc2N1 c3M6DQo+ID4+Pj4+Pj4+IFNlY3Rpb24gNC41OiAiVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0 aGUgaGVhZGVycyBwcmVjZWRpbmcNCj4gdGhlDQo+ID4+Pj4+Pj4+IEZyYWdtZW50DQo+ID4+Pj4+ Pj4+ICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5hbCBw YWNrZXQgbWF5DQo+ID4+Pj4+Pj4+ICBkaWZmZXIuICBXaGF0ZXZlciBoZWFkZXJzIGFyZSBwcmVz ZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4+Pj4+ICBoZWFkZXIgaW4gZWFjaCBm cmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFja2V0cw0KPiA+Pj4+Pj4+ PiAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5 LiAgT25seQ0KPiA+Pj4+Pj4+PiAgdGhvc2UgaGVhZGVycyBpbiB0aGUgT2Zmc2V0IHplcm8gZnJh Z21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiA+Pj4+Pj4+PiAgdGhlIHJlYXNzZW1ibGVk IHBhY2tldC4iDQo+ID4+Pj4+Pj4+IERvZXMgdGhpcyBtZWFuIHRoZSBFQ04gY29kZXBvaW50IChw YXJ0IG9mIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkKQ0KPiBpcw0KPiA+Pj4+Pj4+PiBjb3BpZWQg ZnJvbSB0aGUgZmlyc3QgZnJhZ21lbnQ/IFRoaXMgZG9lc24ndCBzZWVtIHRvIGJlIGNvcnJlY3Qs DQo+IGhvd2V2ZXIsDQo+ID4+Pj4+Pj4+IGFsc28gbm90IHN1cmUgd2hhdCB0aGUgY29ycmVjdCBh bnN3ZXIgaXMuIEkga25vdyB0aGlzIHdhcyBub3QNCj4gY2hhbmdlZCBpbg0KPiA+Pj4+Pj4+PiB0 aGlzIHJldmlzaW9uIGJ1dCBtYXliZSB3ZSBjYW4gc3RpbGwgZ2V0IHRoaXMgcmlnaHQuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBXaGVuIGZyYWdtZW50cyBhcmUgY3JlYXRlZCBtb3N0IG9mIHRoZSBm aWVsZHMgYXJlIGNvcGllZCBmcm9tIHRoZQ0KPiBJUHY2DQo+ID4+Pj4+Pj4gaGVhZGVycyAoZS5n LiwgU291cmNlIEFkZHJlc3MsIERlc3RpbmF0aW9uIGFkZHJlc3MsIGZsb3cgbGFiZWwsDQo+IHRy YWZmaWMNCj4gPj4+Pj4+PiBjbGFzcywgaG9wIGxpbWl0KS4gIFNvbWUgbGlrZSBwYXlsb2FkIGxl bmd0aCwgbmV4dCBoZWFkZXIsIGFuZCBob3ANCj4gbGltaQ0KPiA+Pj4+Pj4+IHQgYXJlIG1vZGlm aWVkLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24s IHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGUgRUNOIGNvZGUNCj4gcG9pbnQgaXMNCj4gPj4+Pj4+PiBj b3BpZWQgZnJvbSB0aGUgZmlyc3QgZnJhZ21lbnQsIGJ1dCBzaG91bGQgYmUgdGhlIHNhbWUgZnJv bSBhbGwgb2YNCj4gdGhlDQo+ID4+Pj4+Pj4gZnJhZ21lbnRzLg0KPiA+Pg0KPiA+PiBUaGF0IGlz IGluY29uc2lzdGVudCB3aXRoIHRoZSBmb2xsb3dpbmcgZ3VpZGFuY2UgaW4gUkZDIDMxNjggKHNl ZQ0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzE2OCNzZWN0aW9uLTUuMyk6 DQo+ID4+DQo+ID4+IDUuMy4gIEZyYWdtZW50YXRpb24NCj4gPj4NCj4gPj4gICBFQ04tY2FwYWJs ZSBwYWNrZXRzIE1BWSBoYXZlIHRoZSBERiAoRG9uJ3QgRnJhZ21lbnQpIGJpdCBzZXQuDQo+ID4+ ICAgUmVhc3NlbWJseSBvZiBhIGZyYWdtZW50ZWQgcGFja2V0IE1VU1QgTk9UIGxvc2UgaW5kaWNh dGlvbnMgb2YNCj4gPj4gICBjb25nZXN0aW9uLiAgSW4gb3RoZXIgd29yZHMsIGlmIGFueSBmcmFn bWVudCBvZiBhbiBJUCBwYWNrZXQgdG8gYmUNCj4gPj4gICByZWFzc2VtYmxlZCBoYXMgdGhlIENF IGNvZGVwb2ludCBzZXQsIHRoZW4gb25lIG9mIHR3byBhY3Rpb25zIE1VU1QgYmUNCj4gPj4gICB0 YWtlbjoNCj4gPj4NCj4gPj4gICAgICAqIFNldCB0aGUgQ0UgY29kZXBvaW50IG9uIHRoZSByZWFz c2VtYmxlZCBwYWNrZXQuICBIb3dldmVyLCB0aGlzDQo+ID4+ICAgICAgICBNVVNUIE5PVCBvY2N1 ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBjb250cmlidXRpbmcgdG8NCj4gPj4gICAg ICAgIHRoaXMgcmVhc3NlbWJseSBjYXJyaWVzIHRoZSBOb3QtRUNUIGNvZGVwb2ludC4NCj4gPj4N Cj4gPj4gICAgICAqIFRoZSBwYWNrZXQgaXMgZHJvcHBlZCwgaW5zdGVhZCBvZiBiZWluZyByZWFz c2VtYmxlZCwgZm9yIGFueQ0KPiA+PiAgICAgICAgb3RoZXIgcmVhc29uLg0KPiA+Pg0KPiA+PiAg IElmIGJvdGggYWN0aW9ucyBhcmUgYXBwbGljYWJsZSwgZWl0aGVyIE1BWSBiZSBjaG9zZW4uICBS ZWFzc2VtYmx5IG9mDQo+ID4+ICAgYSBmcmFnbWVudGVkIHBhY2tldCBNVVNUIE5PVCBjaGFuZ2Ug dGhlIEVDTiBjb2RlcG9pbnQgd2hlbiBhbGwgb2YNCj4gdGhlDQo+ID4+ICAgZnJhZ21lbnRzIGNh cnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4NCj4gPj4+Pj4+IE15IGNvbmNlcm4gaXMgdGhh dCB0aGUgRUNOIGNvZGUgcG9pbnQgY291bGQgYmUgY2hhbmdlZCBvbiBvbmUgb2YNCj4gdGhlDQo+ ID4+Pj4+PiBmcmFnbWVudGVkIHBhY2tldHMgdG8gc2lnbmFsIGNvbmdlc3Rpb24gb2YgYSBpbnRl cm1lZGlhdGUgbm9kZSBhbmQNCj4gPj4+Pj4+IHRoZW4gd2hlbiB5b3UgcmVhc3NlbWJsZSB0aGlz IGluZm9ybWF0aW9uIGdldHMgbG9zdC4gVGhhdCBzZWVtcw0KPiB3cm9uZy4NCj4gPj4+Pj4NCj4g Pj4+Pj4gVGhhdCBpcyBhbiBpbnRlcmVzdGluZyBpZGVhLCBidXQgSSB0aGluayBvdXQgb2Ygc2Nv cGUgZm9yIGFkdmFuY2luZyB0aGlzDQo+ID4+Pj4+IGRvY3VtZW50IHRvIEludGVybmV0IFN0YW5k YXJkLiAgVGhlbiB0aGVyZSBpcyB0aGUgcXVlc3Rpb24gb2YgaG93IHRvDQo+ID4+Pj4+IGVuY29k ZSBuIG9mIG0gZnJhZ21lbnRzIGV4cGVyaWVuY2VkIGNvbmdlc3Rpb24uICBJbnRlcmVzdGluZyBm dXR1cmUNCj4gd29yay4NCj4gPj4+Pg0KPiA+Pj4+IFllcyB0aGVyZSBtaWdodCBiZSBzb21lIG1v cmUgZnVydGhlciB3b3JrIG5lZWRlZCBidXQgdGhhdCBzdGlsbA0KPiBtYWtlcyB0aGUNCj4gPj4+ PiBndWlkYW5jZSBpbiB0aGlzIHRleHQgd3JvbmcuIE1heWJlIHdlIGNhbiBhZGQgc29tZSB0ZXh0 IHRoYXQgdGhlDQo+IFRyYWZmaWMNCj4gPj4+PiBDbGFzcyBtYXkgYmUgaGFuZGxlZCBkaWZmZXJl bnRseSBiZWNhdXNlIGl0IGNvdWxkIGJlIGNoYW5nZWQgb24gdGhlDQo+IHBhdGguDQo+ID4+Pg0K PiA+Pj4gR29vZCBwb2ludC4gSXQncyBub3Qgb25seSBFQ04gdGhhdCBjYW4gY2hhbmdlOyB0aGUg RFNDUCBjYW4gY2hhbmdlIHRvby4NCj4gPj4+IEJvdGggUkZDMjQ3NCAoZGlmZnNlcnYpIGFuZCBF Q04gY2FtZSBhZnRlciBSRkMyNDYwLCBzbyBpdCdzIGxvZ2ljYWwNCj4gPj4+IGZvciAyNDYwYmlz IHRvIG5vdGUgdGhpcyBpc3N1ZS4NCj4gPj4NCj4gPj4gSXQgc2VlbXMgdGhhdCB3ZSAoNm1hbiBX RykgbWlzc2VkIHRoaXMgYmVjYXVzZSBSRkMgMzE2OCB3YXMgbm90DQo+IG1hcmtlZA0KPiA+PiBh cyB1cGRhdGluZyBSRkMgMjQ2MC4gQnV0IGluIGVmZmVjdCBpdCBkaWQgc28gZm9yIElQdjYgaW1w bGVtZW50YXRpb25zDQo+ID4+IG9mIEVDTiwgZXZlbiB0aG91Z2ggaXQgd2FzIG5vdCB3cml0dGVu IGluIGFuIElQIHZlcnNpb24tYWdub3N0aWMgbWFubmVyLg0KPiA+Pg0KPiA+PiBBdCB0aGUgdmVy eSBsZWFzdCB0ZXh0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZGVzY3JpcHRpb24gb2YgdGhlDQo+ ID4+IHJlYXNzZW1ibHkgcHJvY2VzcyB0aGF0IHBvaW50cyB0aGUgcmVhZGVyIHRvIFJGQyAzMTY4 IG9yIGl0cw0KPiA+PiBzdWNjZXNzb3IgZG9jdW1lbnQuDQo+ID4NCj4gPiBEbyB3ZSBoYXZlIGFu eSBldmlkZW5jZSB0aGF0IHRoZSBndWlkYW5jZSBpbiBSRkMgMzE2OCByZWdhcmRpbmcNCj4gcmVh c3NlbWJsaW5nDQo+ID4gSVB2NiBmcmFnbWVudHMgaXMgaW1wbGVtZW50ZWQ/ICBJIGRvbuKAmXQg a25vdywgYnV0IHRoaW5rIGlmIGl0IHRoZXJlIGlzDQo+ID4gZXZpZGVuY2UgSSBhZ3JlZSBzb21l IHRleHQgc2hvdWxkIGJlIGFkZGVkIHRvIHJmYzI0NjBiaXMsIGlmIG5vdCwgdGhlbg0KPiA+IG1h eWJlIG5vdC4NCj4gDQo+IFNpbmNlIEkgbGFjayB0aGUgZXhwZXJ0aXNlIHRvIGFuc3dlciB0aGF0 IHF1ZXN0aW9uLCBJJ20gaG9waW5nIHRoYXQgc29tZW9uZQ0KPiBpbiBUU1ZXRyB3aWxsIHNlZSB0 aGlzIG1lc3NhZ2UgYW5kIGRvIHNvLg0KPiANCj4gUmVnYXJkbGVzcyBvZiB0aGUgYW5zd2VyIHRv IHRoYXQgcXVlc3Rpb24sIG15IHBvc2l0aW9uIHdvdWxkIGJlIHRoYXQgc2luY2UNCj4gMjQ2MGJp cyBhbHJlYWR5IGRlZmVycyB0byBSRkMgMjQ3NCBhbmQgUkZDIDMxNjggcmVnYXJkaW5nIHRoZSBo YW5kbGluZyBvZg0KPiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCwgdGhlIGZvbGxvd2luZyBtb2Rp ZmljYXRpb24gdG8gMjQ2MGJpcyBTZWN0aW9uIDQuNQ0KPiB3b3VsZCBiZSBhbiBhcHByb3ByaWF0 ZSB3YXkgdG8gZGVhbCB3aXRoIE1pcmphJ3MgY29tbWVudDoNCj4gDQo+IE9MRDoNCj4gICAgICAg VGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBwcmVjZWRpbmcgdGhlIEZyYWdt ZW50DQo+ICAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9y aWdpbmFsIHBhY2tldCBtYXkNCj4gICAgICAgZGlmZmVyLiAgV2hhdGV2ZXIgaGVhZGVycyBhcmUg cHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiAgICAgICBoZWFkZXIgaW4gZWFjaCBm cmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFja2V0cw0KPiAgICAgICBh cnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBP bmx5DQo+ICAgICAgIHRob3NlIGhlYWRlcnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBh Y2tldCBhcmUgcmV0YWluZWQgaW4NCj4gICAgICAgdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4g TkVXOg0KPiAgICAgICBUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNl ZGluZyB0aGUgRnJhZ21lbnQNCj4gICAgICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVudHMg b2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFja2V0IG1heQ0KPiAgICAgICBkaWZmZXIuICBXaGF0ZXZl ciBoZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ICAgICAgIGhl YWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRoZSBwYWNr ZXRzDQo+ICAgICAgIGFycml2ZSwgcHJpb3IgdG8gcXVldWVpbmcgdGhlIGZyYWdtZW50cyBmb3Ig cmVhc3NlbWJseS4gIE9ubHkNCj4gICAgICAgdGhvc2UgaGVhZGVycyBpbiB0aGUgT2Zmc2V0IHpl cm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiAgICAgICB0aGUgcmVhc3NlbWJs ZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBvcnQgRXhwbGljaXQNCj4gICAgICAg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gW1JGQzMxNjhdIG1heSB1c2UgaW5mb3JtYXRpb24gaW4g dGhlDQo+ICAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgZnJvbSBhbGwgZnJhZ21lbnQgcGFja2V0 cyB0byByZWNvbnN0cnVjdCB0aGUNCj4gICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBpbiB0aGUg cmVhc3NlbWJsZWQgcGFja2V0Lg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgd291bGQgbm90IGNhdXNl IDI0NjBiaXMgaXRzZWxmIHRvIGxldnkgYW4gYWRkaXRpb25hbA0KPiByZXF1aXJlbWVudCBvbiBo b3cgSVB2NiBub2RlcyByZWFzc2VtYmxlIGZyYWdtZW50ZWQgcGFja2V0cy4gSXQgd291bGQNCj4g c2ltcGx5IGJlIG1ha2luZyBub3RlIG9mIGEgcmVxdWlyZW1lbnQgdGhhdCBpcyBhbHJlYWR5IGxl dmllZCBieQ0KPiBSRkMgMzE2OC4NCj4gDQo+IFRoYW5rcyBhbmQgcmVnYXJkcywNCj4gDQo+IE1p a2UgSGVhcmQNCg0K From nobody Mon Apr 17 10:56:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639BC13172E; Mon, 17 Apr 2017 10:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 o4Sfp6imhYcp; Mon, 17 Apr 2017 10:55:59 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8313172B; Mon, 17 Apr 2017 10:55:59 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 88F531B016FC; Mon, 17 Apr 2017 20:50:58 +0100 (BST) Message-ID: <58F50184.5010408@erg.abdn.ac.uk> Date: Mon, 17 Apr 2017 18:55:16 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" CC: 6MAN <6man@ietf.org>, tsvwg , draft-ietf-6man-rfc2460bis@ietf.org, Bob Hinden , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> Subject: Re: [tsvwg] Mirja =?UTF-8?B?S8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJh?= =?UTF-8?B?ZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5kIEM=?= =?UTF-8?B?T01NRU5UKQ==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:56:03 -0000 It is good to include text. The offered text seems to step back from the current normative text in RFC3168 (which I think does apply to RFC2460). The key requirement from secton 5.3, is that "Reassembly of a fragmented packet MUST NOT lose indications of congestion." i.e., the network layer does not ignore CE marks in fragments. AT the very least, I think the text needs to explicitly point to that section. Gorry On 17/04/2017, 16:59, C. M. Heard wrote: > [ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ] > > On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>> ... >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> COMMENT: >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> One question because I'm not sure if I interpret this correct to make it >>>>>>>>> part of my discuss: >>>>>>>>> Section 4.5: "The number and content of the headers preceding the >>>>>>>>> Fragment >>>>>>>>> header of different fragments of the same original packet may >>>>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>>>> header in each fragment packet, are processed when the packets >>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>>>> those headers in the Offset zero fragment packet are retained in >>>>>>>>> the reassembled packet." >>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is >>>>>>>>> copied from the first fragment? This doesn't seem to be correct, however, >>>>>>>>> also not sure what the correct answer is. I know this was not changed in >>>>>>>>> this revision but maybe we can still get this right. >>>>>>>> When fragments are created most of the fields are copied from the IPv6 >>>>>>>> headers (e.g., Source Address, Destination address, flow label, traffic >>>>>>>> class, hop limit). Some like payload length, next header, and hop limi >>>>>>>> t are modified. >>>>>>>> >>>>>>>> If I understand your question, the answer is yes, the ECN code point is >>>>>>>> copied from the first fragment, but should be the same from all of the >>>>>>>> fragments. >>> That is inconsistent with the following guidance in RFC 3168 (see >>> https://tools.ietf.org/html/rfc3168#section-5.3): >>> >>> 5.3. Fragmentation >>> >>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>> Reassembly of a fragmented packet MUST NOT lose indications of >>> congestion. In other words, if any fragment of an IP packet to be >>> reassembled has the CE codepoint set, then one of two actions MUST be >>> taken: >>> >>> * Set the CE codepoint on the reassembled packet. However, this >>> MUST NOT occur if any of the other fragments contributing to >>> this reassembly carries the Not-ECT codepoint. >>> >>> * The packet is dropped, instead of being reassembled, for any >>> other reason. >>> >>> If both actions are applicable, either MAY be chosen. Reassembly of >>> a fragmented packet MUST NOT change the ECN codepoint when all of the >>> fragments carry the same codepoint. >>> >>>>>>> My concern is that the ECN code point could be changed on one of the >>>>>>> fragmented packets to signal congestion of a intermediate node and >>>>>>> then when you reassemble this information gets lost. That seems wrong. >>>>>> That is an interesting idea, but I think out of scope for advancing this >>>>>> document to Internet Standard. Then there is the question of how to >>>>>> encode n of m fragments experienced congestion. Interesting future work. >>>>> Yes there might be some more further work needed but that still makes the >>>>> guidance in this text wrong. Maybe we can add some text that the Traffic >>>>> Class may be handled differently because it could be changed on the path. >>>> Good point. It's not only ECN that can change; the DSCP can change too. >>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical >>>> for 2460bis to note this issue. >>> It seems that we (6man WG) missed this because RFC 3168 was not marked >>> as updating RFC 2460. But in effect it did so for IPv6 implementations >>> of ECN, even though it was not written in an IP version-agnostic manner. >>> >>> At the very least text should be added to the description of the >>> reassembly process that points the reader to RFC 3168 or its >>> successor document. >> Do we have any evidence that the guidance in RFC 3168 regarding reassembling >> IPv6 fragments is implemented? I don’t know, but think if it there is >> evidence I agree some text should be added to rfc2460bis, if not, then >> maybe not. > Since I lack the expertise to answer that question, I'm hoping that someone > in TSVWG will see this message and do so. > > Regardless of the answer to that question, my position would be that since > 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of > the Traffic Class field, the following modification to 2460bis Section 4.5 > would be an appropriate way to deal with Mirja's comment: > > OLD: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > NEW: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet; however, nodes that support Explicit > Congestion Notification [RFC3168] may use information in the > Traffic Class field from all fragment packets to reconstruct the > Traffic Class field in the reassembled packet. > > Note that this would not cause 2460bis itself to levy an additional > requirement on how IPv6 nodes reassemble fragmented packets. It would > simply be making note of a requirement that is already levied by > RFC 3168. > > Thanks and regards, > > Mike Heard From nobody Mon Apr 17 12:58:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E6A129416; Mon, 17 Apr 2017 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 3f-1jPuRwEDb; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 489B61200FC; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id a188so26788323pfa.2; Mon, 17 Apr 2017 12:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Z/2p11JWnzMFIVSteRg8QXbvfOGOrrueYLEgDbqfWH8=; b=l+3P7tPsxgc6k7xLuTGCEEEP9ZrK/Xhi0puMHTQIcp0r+1AXc4/kzAPyMDq/0Vczzj UT0TbD0ZAjxaB2FZbgk23P6R7veryTNnzH1tTJKgDP0h7wdJ4go2G37894BCCGsbPF0m AWcTrCCEa1tFPR8KMcl8y+k9MagSHlgH1hrDDh51gfYCYxqHpZ+fUVObogk6N8vcEXle L8E915/FvrC7AkbqYCHatrzld2VSqQCtKtaHv/OPzIIwXiCvAOKP+gc1AwIHMn2AroP1 M1xtpUe5WIz+CR66Pya0K90QWIAhDv5j9hrJHXZKAD6cIi9UYr3bYUcMfQuClrx7eX58 6sVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Z/2p11JWnzMFIVSteRg8QXbvfOGOrrueYLEgDbqfWH8=; b=fpUQocJOcUJ9sPbHTTgItevKUWUYtJ5c/C0+wYrFVzPrwpgvpGAk2PT3Jua6t1z4IE G/vsWq/wzSttchH/TEcEAD7Rv5LfvMSr4z8ZOQ2TrvgxjK6tI+otlLFmbbGdfXeDetTV JRtsgcDg6sf2noSi6dEYWTxEqeBW2YXlmEL+XCa7S2lZS4eEhD1uLhJHOC8ElnBMOK3a RBCHCUMBYBLX03pGmMswUU4AUCbw9lI5cU4x87o9ye8VqkRNrI1twoqMhURmU+TANBAA gzCapEKxhFisnx/5FG+GXlji3vaBM2hO+Nxp7QhShD44Kxg2vWMqt1qjuyckFNVP00Ca LGYg== X-Gm-Message-State: AN3rC/4AqSnkiZgUm195a70sAyz1A/I9gmyY/IsMTIu+edtFzzGsAAy6 4TtAbNE7yic6bF8SlQw= X-Received: by 10.98.12.72 with SMTP id u69mr13534924pfi.47.1492459099557; Mon, 17 Apr 2017 12:58:19 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f5sm19637763pgn.50.2017.04.17.12.58.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 12:58:18 -0700 (PDT) Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg References: Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Date: Tue, 18 Apr 2017 07:58:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:58:23 -0000 In line... On 18/04/2017 05:44, Black, David wrote: > Extracting the key portions of text: >=20 >>> That is inconsistent with the following guidance in RFC 3168 (see >>> https://tools.ietf.org/html/rfc3168#section-5.3): >>> >>> 5.3. Fragmentation >>> >>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>> Reassembly of a fragmented packet MUST NOT lose indications of >>> congestion. In other words, if any fragment of an IP packet to be >>> reassembled has the CE codepoint set, then one of two actions MUST = be >>> taken: >>> >>> * Set the CE codepoint on the reassembled packet. However, this= >>> MUST NOT occur if any of the other fragments contributing to >>> this reassembly carries the Not-ECT codepoint. >>> >>> * The packet is dropped, instead of being reassembled, for any >>> other reason. >>> >>> If both actions are applicable, either MAY be chosen. Reassembly o= f >>> a fragmented packet MUST NOT change the ECN codepoint when all of t= he >>> fragments carry the same codepoint. >=20 >> Regardless of the answer to that question, my position would be that s= ince >> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling= of >> the Traffic Class field, the following modification to 2460bis Section= 4.5 >> would be an appropriate way to deal with Mirja's comment: >> >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from all fragment packets to reconstruct the= >> Traffic Class field in the reassembled packet. >> >> Note that this would not cause 2460bis itself to levy an additional >> requirement on how IPv6 nodes reassemble fragmented packets. It would >> simply be making note of a requirement that is already levied by >> RFC 3168. >=20 > In which case, the RFC 3168 requirement should be stated e.g.: >=20 > OLD: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > NEW: > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet; however, nodes that support Explicit > Congestion Notification [RFC3168] may use information in the > Traffic Class field from any or all fragment packets to reconstru= ct > the Traffic Class field in the reassembled packet in order to mee= t > RFC 3168's requirements, e.g., that reassembly not lose indicatio= ns > of congestion, see Section 5.3 of RFC 3168 for additional informa= tion. >=20 > Pointing the implementer at Section 5.3 of RFC 3168 is better than > hoping she figures out on her own that she ought to take a look at it .= Yes. This is correct. Brian >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard >> Sent: Monday, April 17, 2017 12:00 PM >> To: 6MAN <6man@ietf.org>; tsvwg >> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >> ; Mirja Kuehlewind (IETF) ;= >> IESG ; 6man Chairs <6man-chairs@ietf.org> >> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-6man= -rfc2460bis- >> 09: (with DISCUSS and COMMENT) >> >> [ TSVWG added to solicit advice on implementation of RFC 3186 Section = 5.3 ] >> >> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>> ... >>>>>>>>>> --------------------------------------------------------------= -------- >>>>>>>>>> COMMENT: >>>>>>>>>> --------------------------------------------------------------= -------- >>>>>>>>>> >>>>>>>>>> One question because I'm not sure if I interpret this correct = to >> make it >>>>>>>>>> part of my discuss: >>>>>>>>>> Section 4.5: "The number and content of the headers preceding >> the >>>>>>>>>> Fragment >>>>>>>>>> header of different fragments of the same original packet may= >>>>>>>>>> differ. Whatever headers are present, preceding the Fragment= >>>>>>>>>> header in each fragment packet, are processed when the packet= s >>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only= >>>>>>>>>> those headers in the Offset zero fragment packet are retained= in >>>>>>>>>> the reassembled packet." >>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class fi= eld) >> is >>>>>>>>>> copied from the first fragment? This doesn't seem to be correc= t, >> however, >>>>>>>>>> also not sure what the correct answer is. I know this was not >> changed in >>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>> >>>>>>>>> When fragments are created most of the fields are copied from t= he >> IPv6 >>>>>>>>> headers (e.g., Source Address, Destination address, flow label,= >> traffic >>>>>>>>> class, hop limit). Some like payload length, next header, and = hop >> limi >>>>>>>>> t are modified. >>>>>>>>> >>>>>>>>> If I understand your question, the answer is yes, the ECN code >> point is >>>>>>>>> copied from the first fragment, but should be the same from all= of >> the >>>>>>>>> fragments. >>>> >>>> That is inconsistent with the following guidance in RFC 3168 (see >>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>> >>>> 5.3. Fragmentation >>>> >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>> congestion. In other words, if any fragment of an IP packet to be= >>>> reassembled has the CE codepoint set, then one of two actions MUST= be >>>> taken: >>>> >>>> * Set the CE codepoint on the reassembled packet. However, thi= s >>>> MUST NOT occur if any of the other fragments contributing to >>>> this reassembly carries the Not-ECT codepoint. >>>> >>>> * The packet is dropped, instead of being reassembled, for any >>>> other reason. >>>> >>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>> a fragmented packet MUST NOT change the ECN codepoint when all of >> the >>>> fragments carry the same codepoint. >>>> >>>>>>>> My concern is that the ECN code point could be changed on one of= >> the >>>>>>>> fragmented packets to signal congestion of a intermediate node a= nd >>>>>>>> then when you reassemble this information gets lost. That seems >> wrong. >>>>>>> >>>>>>> That is an interesting idea, but I think out of scope for advanci= ng this >>>>>>> document to Internet Standard. Then there is the question of how= to >>>>>>> encode n of m fragments experienced congestion. Interesting futu= re >> work. >>>>>> >>>>>> Yes there might be some more further work needed but that still >> makes the >>>>>> guidance in this text wrong. Maybe we can add some text that the >> Traffic >>>>>> Class may be handled differently because it could be changed on th= e >> path. >>>>> >>>>> Good point. It's not only ECN that can change; the DSCP can change = too. >>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical= >>>>> for 2460bis to note this issue. >>>> >>>> It seems that we (6man WG) missed this because RFC 3168 was not >> marked >>>> as updating RFC 2460. But in effect it did so for IPv6 implementatio= ns >>>> of ECN, even though it was not written in an IP version-agnostic man= ner. >>>> >>>> At the very least text should be added to the description of the >>>> reassembly process that points the reader to RFC 3168 or its >>>> successor document. >>> >>> Do we have any evidence that the guidance in RFC 3168 regarding >> reassembling >>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if it= there is >>> evidence I agree some text should be added to rfc2460bis, if not, the= n >>> maybe not. >> >> Since I lack the expertise to answer that question, I'm hoping that so= meone >> in TSVWG will see this message and do so. >> >> Regardless of the answer to that question, my position would be that s= ince >> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handling= of >> the Traffic Class field, the following modification to 2460bis Section= 4.5 >> would be an appropriate way to deal with Mirja's comment: >> >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in= >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from all fragment packets to reconstruct the= >> Traffic Class field in the reassembled packet. >> >> Note that this would not cause 2460bis itself to levy an additional >> requirement on how IPv6 nodes reassemble fragmented packets. It would >> simply be making note of a requirement that is already levied by >> RFC 3168. >> >> Thanks and regards, >> >> Mike Heard >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Mon Apr 17 13:21:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53F8129445; Mon, 17 Apr 2017 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 sghKDXHJTGYr; Mon, 17 Apr 2017 13:21:43 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 615C2128A32; Mon, 17 Apr 2017 13:21:43 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id g23so12195919pfj.1; Mon, 17 Apr 2017 13:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NH5XlAOY1MMusjZeA0HLofJZNCmoTbP/yB7CLwONqms=; b=LRK+sIMz9pD7cW9o7caV1cqIc6gNtbsCh1wW2f5lP6H1t8R7SM0nZuBwLyN2eQCvaN W2dt4KChjfwotFwMN76kQQiVOU1G/SD43ZFXzb09nY8/YGFjbDKpUKRItcOrZ+3m5brR avx1jNQ6PISqXm2b4LCvn/3lKWquIGkiwST1mA+RB2MgSRT07mpOGCJWYYK51+ksU3io mrf6NzKjwOu9lQKKWJFkTPQx4c9Spoct811VvxSm6uOLz3dDq8YU4QNCv2jl7SLtyRul 3J6BGkEi5588eqnvsEGgMIesm3gslej8WTBM0IhsyAVFNbIXErriisSfsivAf0aoDonN WfCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NH5XlAOY1MMusjZeA0HLofJZNCmoTbP/yB7CLwONqms=; b=Kd2LtKDNhGTQY2MstxNfQo2qTny+DMRVKrGcEsG9OuyokNmo4c2jpg4OuiSptF52x0 OFGB7r3586sPfWSF9ijzWlyYIJevYwwEISfn2wLRZKvMSw+1cDxAP0RoP9yWgbYPEo10 eHvSWQsYZjrf87xK/6V/Z8/HFUabJW5vugs0MIXEurjGcuVFF+ET1XdJrb/vDN27FGbH 0hBNdTp/iBP5QoqujieIKePBo+pcBvl++G6GvytzmNWs6qviBx638BmGt4bbbOxpW69o SS1mntKbgjjgA+Cc4HNLE3HZ4MNiYcFvW3nhHb91Kv8FM4HKuki8qquk5bCEyBsrfL9V LDKw== X-Gm-Message-State: AN3rC/6gsaY6BeuiDH92VGGf+XfkDH9vRD72MvhB3RZkEHOmsuTfgDv8 KzSLKpqRKj0QteuJ/fs= X-Received: by 10.99.103.3 with SMTP id b3mr14020442pgc.39.1492460502800; Mon, 17 Apr 2017 13:21:42 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t3sm9936524pfi.127.2017.04.17.13.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 13:21:41 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "C. M. Heard" References: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> Cc: Bob Hinden , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0071275d-33d9-f0a6-8867-ee447d4e16f8@gmail.com> Date: Tue, 18 Apr 2017 08:21:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:21:45 -0000 On 18/04/2017 04:15, C. M. Heard wrote: > On Sat, Apr 15, 2017 at 3:07 PM, Brian E Carpenter wrote: >>> Do we have any evidence that the guidance in RFC 3168 regarding >>> reassembling IPv6 fragments is implemented? I don=E2=80=99t know, bu= t think if >>> it there is evidence I agree some text should be added to rfc2460bis,= if >>> not, then maybe not. >> >> In any case, somebody needs to submit an erratum for RFC 3168, since i= t >> lacks "Updates: 2460". >=20 > I started to do that and then noticed that RFC 3168 also lacks "Updates= : 791". > Instead, RFC 3168 updates RFC 2474, which in turn obsoletes RFC 1349, w= hich > in turn updates RFC 791 (and several other IPv4 RFCs). But RFC 2474 its= elf > lacks "Updates: 2460". So maybe the erratum should be filed against RFC= 2474. > On the other hand, all that RFC 2460 Section 7 does with respect to the= > Traffic Class field is to define a set of general requirements and defe= r all > the details to future RFCs. So tt's not clear to me whether RFC 2474 do= es, in > fact, update RFC 2460. I'll leave the decision on whether to file the e= rratum > to someone else who has better skills at navigating these tangled webs.= RFC 2474 adds to RFC 2460; it doesn't change any of the behaviour defined= by 2460, so it isn't IMHO a case for "Updates". If we had a tag "Extends", t= hen "Extends: 2460" would be appropriate. RFC 3168 changes the RFC 2460 algorithm for reassembly, so IMHO it's an "= Updates: 2460". Brian From nobody Mon Apr 17 13:28:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634A3129454; Mon, 17 Apr 2017 13:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Qdt44Si5_zft; Mon, 17 Apr 2017 13:27:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D087F128C82; Mon, 17 Apr 2017 13:27:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DFC7EB80CFC; Mon, 17 Apr 2017 13:27:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 8096 on The IPv6-Specific MIB Modules Are Obsolete X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipv6@ietf.org Message-Id: <20170417202736.DFC7EB80CFC@rfc-editor.org> Date: Mon, 17 Apr 2017 13:27:36 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:27:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8096 Title: The IPv6-Specific MIB Modules Are Obsolete Author: B. Fenner Status: Informational Stream: IETF Date: April 2017 Mailbox: fenner@fenron.com Pages: 65 Characters: 117298 Obsoletes: RFC 2452, RFC 2454, RFC 2465, RFC 2466 I-D Tag: draft-ietf-6man-ipv6-mibs-obsolete-02.txt URL: https://www.rfc-editor.org/info/rfc8096 DOI: 10.17487/RFC8096 In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic. This document is a product of the IPv6 Maintenance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 17 14:09:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6812EB34; Mon, 17 Apr 2017 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 Cs_9vJXCSVYo; Mon, 17 Apr 2017 14:08:59 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 3A43A129449; Mon, 17 Apr 2017 14:08:53 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id o22so46319671iod.3; Mon, 17 Apr 2017 14:08:53 -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=4lIxCMWlELmRBkU9ZUJxS6vckUg7Ev4UdhkR3eA8n4k=; b=lDX06CRT1yApQj0oXlIJTW+GBcrIuW+FPEBP1cj01VRXqdFPZcMY5+e5aa/NHhJ0IH lA4xnkUZyl5pfvdeGy7uxUcgwunVqHYWgoRVDvXG2kmOSKynT0SCWteG/8VURHBDy5xd UTvfZdL0PSe9GmAkP9tt3HZpju/N1KgD+a4ornLbzr3jbGwtSl9U9lP6G4ONIGOqBNY+ 2lpPv+caG+/QU0ldr0WdspxigvmDPOOhuGnTfxuRek8Yn4FzSoDUcXuMPIPFwD6MTN+N h6I9c0kBRQXWXqQmtE8C14cluvTmtI11khqA7UTMxDm2eIn91x9akH4QOI0RIiSTONWH cGzA== 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=4lIxCMWlELmRBkU9ZUJxS6vckUg7Ev4UdhkR3eA8n4k=; b=BEHfG5xrfCO+Sg1kTqaBEKFiNjDWzq2RFlcL3U2XXuWsAucvMBB0H0hMdsj5Fc06ie 0j0etPAAJiiuCHrl7212qZNyK++Wawp9vv2brjePAufoIPHGIcjM46UVXXLjCawY8VCz 3HTAkQj1esCIu3kemvtM9Bn8dqfU8CV89L+oBCrg7OWB6gayOoaYPCrV2GO1vF4gMudg kmGUjGWs6JGngLoafTtO+upzF3S57Szx/t4IWb+JRIBEPgpDDitDOF9hnVi23HrvCcGE seHfNudVI0JmXZWAgsMmc+F5JDD5dw7LYqMU/mrAKWs1qRSziS1/slq2EtR8U22FjnCJ q1HQ== X-Gm-Message-State: AN3rC/73Ghv+IpN5IHTNlN97RqRV6BCU3ZDQhrVHwj3HZ6JWbLGajhBq +oGqmr1hszp05ZCTok4= X-Received: by 10.107.9.73 with SMTP id j70mr11818590ioi.211.1492463332401; Mon, 17 Apr 2017 14:08:52 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r197sm3885268ita.11.2017.04.17.14.08.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 14:08:51 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_d?= =?utf-8?Q?raft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Mon, 17 Apr 2017 14:08:48 -0700 In-Reply-To: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Cc: Bob Hinden , "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> To: Brian Carpenter References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:09:03 -0000 --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, After reading through the discussion, I think a new paragraph (after the = text that says how to construct a reassembled packet) like the following = would be appropriate. Nodes that support Explicit Congestion Notification [RFC3168] should use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. See Section 5.3 of RFC3168 for more information. I don=E2=80=99t think we need to quote what RFC3168 says, just point the = the correct section. This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, = so it shouldn't be making any new requirements. Comments? Bob > On Apr 17, 2017, at 12:58 PM, Brian E Carpenter = wrote: >=20 > In line... >=20 > On 18/04/2017 05:44, Black, David wrote: >> Extracting the key portions of text: >>=20 >>>> That is inconsistent with the following guidance in RFC 3168 (see >>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>=20 >>>> 5.3. Fragmentation >>>>=20 >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>> congestion. In other words, if any fragment of an IP packet to be >>>> reassembled has the CE codepoint set, then one of two actions MUST = be >>>> taken: >>>>=20 >>>> * Set the CE codepoint on the reassembled packet. However, = this >>>> MUST NOT occur if any of the other fragments contributing to >>>> this reassembly carries the Not-ECT codepoint. >>>>=20 >>>> * The packet is dropped, instead of being reassembled, for any >>>> other reason. >>>>=20 >>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>> a fragmented packet MUST NOT change the ECN codepoint when all of = the >>>> fragments carry the same codepoint. >>=20 >>> Regardless of the answer to that question, my position would be that = since >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>> would be an appropriate way to deal with Mirja's comment: >>>=20 >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from all fragment packets to reconstruct = the >>> Traffic Class field in the reassembled packet. >>>=20 >>> Note that this would not cause 2460bis itself to levy an additional >>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>> simply be making note of a requirement that is already levied by >>> RFC 3168. >>=20 >> In which case, the RFC 3168 requirement should be stated e.g.: >>=20 >> OLD: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet. >> NEW: >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet; however, nodes that support Explicit >> Congestion Notification [RFC3168] may use information in the >> Traffic Class field from any or all fragment packets to = reconstruct >> the Traffic Class field in the reassembled packet in order to = meet >> RFC 3168's requirements, e.g., that reassembly not lose = indications >> of congestion, see Section 5.3 of RFC 3168 for additional = information. >>=20 >> Pointing the implementer at Section 5.3 of RFC 3168 is better than >> hoping she figures out on her own that she ought to take a look at it = . >=20 > Yes. This is correct. >=20 > Brian >=20 >>=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard >>> Sent: Monday, April 17, 2017 12:00 PM >>> To: 6MAN <6man@ietf.org>; tsvwg >>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>> ; Mirja Kuehlewind (IETF) = ; >>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on = draft-ietf-6man-rfc2460bis- >>> 09: (with DISCUSS and COMMENT) >>>=20 >>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ] >>>=20 >>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>> ... >>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>> COMMENT: >>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>=20 >>>>>>>>>>> One question because I'm not sure if I interpret this = correct to >>> make it >>>>>>>>>>> part of my discuss: >>>>>>>>>>> Section 4.5: "The number and content of the headers = preceding >>> the >>>>>>>>>>> Fragment >>>>>>>>>>> header of different fragments of the same original packet = may >>>>>>>>>>> differ. Whatever headers are present, preceding the = Fragment >>>>>>>>>>> header in each fragment packet, are processed when the = packets >>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. = Only >>>>>>>>>>> those headers in the Offset zero fragment packet are = retained in >>>>>>>>>>> the reassembled packet." >>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) >>> is >>>>>>>>>>> copied from the first fragment? This doesn't seem to be = correct, >>> however, >>>>>>>>>>> also not sure what the correct answer is. I know this was = not >>> changed in >>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>=20 >>>>>>>>>> When fragments are created most of the fields are copied from = the >>> IPv6 >>>>>>>>>> headers (e.g., Source Address, Destination address, flow = label, >>> traffic >>>>>>>>>> class, hop limit). Some like payload length, next header, = and hop >>> limi >>>>>>>>>> t are modified. >>>>>>>>>>=20 >>>>>>>>>> If I understand your question, the answer is yes, the ECN = code >>> point is >>>>>>>>>> copied from the first fragment, but should be the same from = all of >>> the >>>>>>>>>> fragments. >>>>>=20 >>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>=20 >>>>> 5.3. Fragmentation >>>>>=20 >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>> taken: >>>>>=20 >>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>> MUST NOT occur if any of the other fragments contributing to >>>>> this reassembly carries the Not-ECT codepoint. >>>>>=20 >>>>> * The packet is dropped, instead of being reassembled, for any >>>>> other reason. >>>>>=20 >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of >>> the >>>>> fragments carry the same codepoint. >>>>>=20 >>>>>>>>> My concern is that the ECN code point could be changed on one = of >>> the >>>>>>>>> fragmented packets to signal congestion of a intermediate node = and >>>>>>>>> then when you reassemble this information gets lost. That = seems >>> wrong. >>>>>>>>=20 >>>>>>>> That is an interesting idea, but I think out of scope for = advancing this >>>>>>>> document to Internet Standard. Then there is the question of = how to >>>>>>>> encode n of m fragments experienced congestion. Interesting = future >>> work. >>>>>>>=20 >>>>>>> Yes there might be some more further work needed but that still >>> makes the >>>>>>> guidance in this text wrong. Maybe we can add some text that the >>> Traffic >>>>>>> Class may be handled differently because it could be changed on = the >>> path. >>>>>>=20 >>>>>> Good point. It's not only ECN that can change; the DSCP can = change too. >>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's = logical >>>>>> for 2460bis to note this issue. >>>>>=20 >>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>> marked >>>>> as updating RFC 2460. But in effect it did so for IPv6 = implementations >>>>> of ECN, even though it was not written in an IP version-agnostic = manner. >>>>>=20 >>>>> At the very least text should be added to the description of the >>>>> reassembly process that points the reader to RFC 3168 or its >>>>> successor document. >>>>=20 >>>> Do we have any evidence that the guidance in RFC 3168 regarding >>> reassembling >>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is >>>> evidence I agree some text should be added to rfc2460bis, if not, = then >>>> maybe not. >>>=20 >>> Since I lack the expertise to answer that question, I'm hoping that = someone >>> in TSVWG will see this message and do so. >>>=20 >>> Regardless of the answer to that question, my position would be that = since >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>> would be an appropriate way to deal with Mirja's comment: >>>=20 >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained = in >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from all fragment packets to reconstruct = the >>> Traffic Class field in the reassembled packet. >>>=20 >>> Note that this would not cause 2460bis itself to levy an additional >>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>> simply be making note of a requirement that is already levied by >>> RFC 3168. >>>=20 >>> Thanks and regards, >>>=20 >>> Mike Heard >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY9S7hAAoJEK7rdBF357uomFwH/3N51BqKi/gqGoGSywcBUVgQ dIrCFcjVS7Gw79KBqCQP7aDD2WL38wtrxpnwQnvHH4xwrrgsRKAGRED91N+XJMyZ rrBhdpfpY3BGkvR+Kc3urUG/3wM4pa4oaMcZ2v07IXv8RnNFt75pCQCD9SLiMDHK vZwjIcKQNuBIbV1zRrrgCw2Uw2aPXcMO2F2HOiPlaK6Jf7GFj9TXVZsa63QsTAlS BgzC/5DbzSfz8LfRtw53ZMJoczNV7OaLPs4Pjs6IrDkmftHsQ7kTUS/lpvfZOOsP 5X6SUzc7tAuNLJRexFXLO59US0WVHSzsdkdmp0G1ENZAPlgKYLLAv2BfR5+5hew= =G1He -----END PGP SIGNATURE----- --Apple-Mail=_7BBF44EB-21A1-4E8E-AC1A-CFACAE8F93E2-- From nobody Mon Apr 17 14:21:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6E128D8B; Mon, 17 Apr 2017 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 mzJb4o80FZnU; Mon, 17 Apr 2017 14:21:11 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835BE126CE8; Mon, 17 Apr 2017 14:21:11 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 243C4720EF; Mon, 17 Apr 2017 17:21:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=tFa7HcNOzV2suCtMif5EeO6Wu9k=; b=VsCCVv vFv3GwZWGciuPF60rOuASjeoK3GFv8lLjKVKXs2AoKXpt8Ke9I0r/X989ha5/gFS n6A6oTN0p/+UPbCeyveB70Bh8GecxOlDDyli7RbqyATEN2wGJbFlZs2Xc5c6GC4I ILC08gtSEwSj4H47HDafoIPMtpI6SEF8/CzsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=P44cKDUwA3jTwrsQzV/yICds4uD7nuNB YR9SmbX2VUAOXGRRo/DKcwyZXrw1kSqtogVCWs4nSlXVYEHRMkUkqWVHuh4TNo1t nM/v2U7x5aZbqD6Kufo045cRWFICTtzz5LBy+iCOBjWYprD9I0Z+o5dtwTn7QRxU 5sPnO2xUGs8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1C7E3720EE; Mon, 17 Apr 2017 17:21:10 -0400 (EDT) Received: from mail-qt0-f173.google.com (unknown [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id A0249720ED; Mon, 17 Apr 2017 17:21:09 -0400 (EDT) Received: by mail-qt0-f173.google.com with SMTP id g60so45047264qtd.3; Mon, 17 Apr 2017 14:21:09 -0700 (PDT) X-Gm-Message-State: AN3rC/7AI9pFFxilOO6SDlWUtEfYREyU0zLmGosFJKJQvu7rKMJXO3YF 8VPYFChFxEZOBvSsz6PMP8Rtosy3pA== X-Received: by 10.237.60.77 with SMTP id u13mr10478858qte.267.1492464069290; Mon, 17 Apr 2017 14:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 14:20:48 -0700 (PDT) In-Reply-To: <0071275d-33d9-f0a6-8867-ee447d4e16f8@gmail.com> References: <05A79674-5D9C-44EA-B768-E82F04956D41@gmail.com> <0071275d-33d9-f0a6-8867-ee447d4e16f8@gmail.com> From: "C. M. Heard" Date: Mon, 17 Apr 2017 14:20:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Brian E Carpenter Cc: Bob Hinden , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c190326b0b2de054d635e9f X-Pobox-Relay-ID: C6A1EEC0-23B3-11E7-B44D-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:21:13 -0000 --94eb2c190326b0b2de054d635e9f Content-Type: text/plain; charset=UTF-8 On Mon, Apr 17, 2017 at 1:21 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > RFC 2474 adds to RFC 2460; it doesn't change any of the behaviour defined > by > 2460, so it isn't IMHO a case for "Updates". If we had a tag "Extends", > then > "Extends: 2460" would be appropriate. > > RFC 3168 changes the RFC 2460 algorithm for reassembly, so IMHO it's an > "Updates: 2460". > I buy that and I just submitted the erratum. Thanks //cmh --94eb2c190326b0b2de054d635e9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 17, 2017 at 1:21 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
RFC 247= 4 adds to RFC 2460; it doesn't change any of the behaviour defined by 2460, so it isn't IMHO a case for "Updates". If we had a tag = "Extends", then
"Extends: 2460" would be appropriate.

RFC 3168 changes the RFC 2460 algorithm for reassembly, so IMHO it's an= "Updates: 2460".<= br>

I buy that and I just sub= mitted the erratum.

Thanks

//cmh

--94eb2c190326b0b2de054d635e9f-- From nobody Mon Apr 17 14:36:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7939124D68; Mon, 17 Apr 2017 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 V3oyVnqsWNsB; Mon, 17 Apr 2017 14:36:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFC8129B16; Mon, 17 Apr 2017 14:36:33 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7325972389; Mon, 17 Apr 2017 17:36:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=21bWDqpIUiIwzPAfO1I6P4aER0Y=; b=doajVx kP2NwMZ+m5t9LX6h+i68DGcbDj+8y6WxcnaKMT15ZaeNUbedzbcOBZUqFfNpdZOd +047EY+y7GaVn7w2FGdqfUDFThxBp7qItgPXcHAyKC+JTmNcdXsF2ivAw6TFBRT3 G04fX+myX/R/vuSqCFAk4Onpd/YwGyXM1Tols= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=Dapz9qhzdkYrG2scIIhf+rp9NHDoinQh dgYtsODI34tftzeyQMIEUy3ES+rtx6TAdfzXbmGt8t3p4rKAfobXOokOgsc1xyQ3 CsRDB6orGsvGRjThByVH6WgPNe1RGjn36Y48/j5ZvHSdgTfM+8SqDHSBDPjtNoxS 67P6f+DhmEQ= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 6A74572388; Mon, 17 Apr 2017 17:36:32 -0400 (EDT) Received: from mail-qt0-f182.google.com (unknown [209.85.216.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id DB56472386; Mon, 17 Apr 2017 17:36:31 -0400 (EDT) Received: by mail-qt0-f182.google.com with SMTP id y33so28236272qta.2; Mon, 17 Apr 2017 14:36:31 -0700 (PDT) X-Gm-Message-State: AN3rC/64CPstvwDfXXoBk4GNvXTLfJ7P22ewGX2L15FqWMURitUqdI73 SrPp5qYgII/MNjb0RrDHmzP/aGBneg== X-Received: by 10.237.60.77 with SMTP id u13mr10527574qte.267.1492464991469; Mon, 17 Apr 2017 14:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Mon, 17 Apr 2017 14:36:11 -0700 (PDT) In-Reply-To: References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> From: "C. M. Heard" Date: Mon, 17 Apr 2017 14:36:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden Cc: Brian Carpenter , "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c190326a8055a054d639558 X-Pobox-Relay-ID: EC549A9E-23B5-11E7-A6D2-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 21:36:37 -0000 --94eb2c190326a8055a054d639558 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bob, I agree with you on all points. This is a good solution. Mike Heard On Mon, Apr 17, 2017 at 2:08 PM, Bob Hinden wrote: > Hi, > > After reading through the discussion, I think a new paragraph (after the > text that says how to construct a reassembled packet) like the following > would be appropriate. > > Nodes that support Explicit Congestion Notification [RFC3168] > should use information in the Traffic Class field from all > fragment packets to reconstruct the Traffic Class field in the > reassembled packet. See Section 5.3 of RFC3168 for more > information. > > I don=E2=80=99t think we need to quote what RFC3168 says, just point the = the > correct section. > > This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, so= it shouldn't be > making any new requirements. > > Comments? > > Bob > > > On Apr 17, 2017, at 12:58 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > In line... > > > > On 18/04/2017 05:44, Black, David wrote: > >> Extracting the key portions of text: > >> > >>>> That is inconsistent with the following guidance in RFC 3168 (see > >>>> https://tools.ietf.org/html/rfc3168#section-5.3): > >>>> > >>>> 5.3. Fragmentation > >>>> > >>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. > >>>> Reassembly of a fragmented packet MUST NOT lose indications of > >>>> congestion. In other words, if any fragment of an IP packet to be > >>>> reassembled has the CE codepoint set, then one of two actions MUST = be > >>>> taken: > >>>> > >>>> * Set the CE codepoint on the reassembled packet. However, this > >>>> MUST NOT occur if any of the other fragments contributing to > >>>> this reassembly carries the Not-ECT codepoint. > >>>> > >>>> * The packet is dropped, instead of being reassembled, for any > >>>> other reason. > >>>> > >>>> If both actions are applicable, either MAY be chosen. Reassembly o= f > >>>> a fragmented packet MUST NOT change the ECN codepoint when all of t= he > >>>> fragments carry the same codepoint. > >> > >>> Regardless of the answer to that question, my position would be that > since > >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handlin= g > of > >>> the Traffic Class field, the following modification to 2460bis Sectio= n > 4.5 > >>> would be an appropriate way to deal with Mirja's comment: > >>> > >>> OLD: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet. > >>> NEW: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet; however, nodes that support Explicit > >>> Congestion Notification [RFC3168] may use information in the > >>> Traffic Class field from all fragment packets to reconstruct the > >>> Traffic Class field in the reassembled packet. > >>> > >>> Note that this would not cause 2460bis itself to levy an additional > >>> requirement on how IPv6 nodes reassemble fragmented packets. It would > >>> simply be making note of a requirement that is already levied by > >>> RFC 3168. > >> > >> In which case, the RFC 3168 requirement should be stated e.g.: > >> > >> OLD: > >> The number and content of the headers preceding the Fragment > >> header of different fragments of the same original packet may > >> differ. Whatever headers are present, preceding the Fragment > >> header in each fragment packet, are processed when the packets > >> arrive, prior to queueing the fragments for reassembly. Only > >> those headers in the Offset zero fragment packet are retained in > >> the reassembled packet. > >> NEW: > >> The number and content of the headers preceding the Fragment > >> header of different fragments of the same original packet may > >> differ. Whatever headers are present, preceding the Fragment > >> header in each fragment packet, are processed when the packets > >> arrive, prior to queueing the fragments for reassembly. Only > >> those headers in the Offset zero fragment packet are retained in > >> the reassembled packet; however, nodes that support Explicit > >> Congestion Notification [RFC3168] may use information in the > >> Traffic Class field from any or all fragment packets to reconstru= ct > >> the Traffic Class field in the reassembled packet in order to mee= t > >> RFC 3168's requirements, e.g., that reassembly not lose indicatio= ns > >> of congestion, see Section 5.3 of RFC 3168 for additional > information. > >> > >> Pointing the implementer at Section 5.3 of RFC 3168 is better than > >> hoping she figures out on her own that she ought to take a look at it = . > > > > Yes. This is correct. > > > > Brian > > > >> > >> Thanks, --David > >> > >>> -----Original Message----- > >>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard > >>> Sent: Monday, April 17, 2017 12:00 PM > >>> To: 6MAN <6man@ietf.org>; tsvwg > >>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden > >>> ; Mirja Kuehlewind (IETF) = ; > >>> IESG ; 6man Chairs <6man-chairs@ietf.org> > >>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on > draft-ietf-6man-rfc2460bis- > >>> 09: (with DISCUSS and COMMENT) > >>> > >>> [ TSVWG added to solicit advice on implementation of RFC 3186 Section > 5.3 ] > >>> > >>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: > >>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: > >>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: > >>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: > >>>>>> ... > >>>>>>>>>>> ------------------------------------------------------------ > ---------- > >>>>>>>>>>> COMMENT: > >>>>>>>>>>> ------------------------------------------------------------ > ---------- > >>>>>>>>>>> > >>>>>>>>>>> One question because I'm not sure if I interpret this correct > to > >>> make it > >>>>>>>>>>> part of my discuss: > >>>>>>>>>>> Section 4.5: "The number and content of the headers preceding > >>> the > >>>>>>>>>>> Fragment > >>>>>>>>>>> header of different fragments of the same original packet may > >>>>>>>>>>> differ. Whatever headers are present, preceding the Fragment > >>>>>>>>>>> header in each fragment packet, are processed when the packet= s > >>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Only > >>>>>>>>>>> those headers in the Offset zero fragment packet are retained > in > >>>>>>>>>>> the reassembled packet." > >>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class > field) > >>> is > >>>>>>>>>>> copied from the first fragment? This doesn't seem to be > correct, > >>> however, > >>>>>>>>>>> also not sure what the correct answer is. I know this was not > >>> changed in > >>>>>>>>>>> this revision but maybe we can still get this right. > >>>>>>>>>> > >>>>>>>>>> When fragments are created most of the fields are copied from > the > >>> IPv6 > >>>>>>>>>> headers (e.g., Source Address, Destination address, flow label= , > >>> traffic > >>>>>>>>>> class, hop limit). Some like payload length, next header, and > hop > >>> limi > >>>>>>>>>> t are modified. > >>>>>>>>>> > >>>>>>>>>> If I understand your question, the answer is yes, the ECN code > >>> point is > >>>>>>>>>> copied from the first fragment, but should be the same from al= l > of > >>> the > >>>>>>>>>> fragments. > >>>>> > >>>>> That is inconsistent with the following guidance in RFC 3168 (see > >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): > >>>>> > >>>>> 5.3. Fragmentation > >>>>> > >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. > >>>>> Reassembly of a fragmented packet MUST NOT lose indications of > >>>>> congestion. In other words, if any fragment of an IP packet to be > >>>>> reassembled has the CE codepoint set, then one of two actions MUST > be > >>>>> taken: > >>>>> > >>>>> * Set the CE codepoint on the reassembled packet. However, thi= s > >>>>> MUST NOT occur if any of the other fragments contributing to > >>>>> this reassembly carries the Not-ECT codepoint. > >>>>> > >>>>> * The packet is dropped, instead of being reassembled, for any > >>>>> other reason. > >>>>> > >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of > >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of > >>> the > >>>>> fragments carry the same codepoint. > >>>>> > >>>>>>>>> My concern is that the ECN code point could be changed on one o= f > >>> the > >>>>>>>>> fragmented packets to signal congestion of a intermediate node > and > >>>>>>>>> then when you reassemble this information gets lost. That seems > >>> wrong. > >>>>>>>> > >>>>>>>> That is an interesting idea, but I think out of scope for > advancing this > >>>>>>>> document to Internet Standard. Then there is the question of ho= w > to > >>>>>>>> encode n of m fragments experienced congestion. Interesting > future > >>> work. > >>>>>>> > >>>>>>> Yes there might be some more further work needed but that still > >>> makes the > >>>>>>> guidance in this text wrong. Maybe we can add some text that the > >>> Traffic > >>>>>>> Class may be handled differently because it could be changed on t= he > >>> path. > >>>>>> > >>>>>> Good point. It's not only ECN that can change; the DSCP can change > too. > >>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logica= l > >>>>>> for 2460bis to note this issue. > >>>>> > >>>>> It seems that we (6man WG) missed this because RFC 3168 was not > >>> marked > >>>>> as updating RFC 2460. But in effect it did so for IPv6 > implementations > >>>>> of ECN, even though it was not written in an IP version-agnostic > manner. > >>>>> > >>>>> At the very least text should be added to the description of the > >>>>> reassembly process that points the reader to RFC 3168 or its > >>>>> successor document. > >>>> > >>>> Do we have any evidence that the guidance in RFC 3168 regarding > >>> reassembling > >>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if i= t there is > >>>> evidence I agree some text should be added to rfc2460bis, if not, th= en > >>>> maybe not. > >>> > >>> Since I lack the expertise to answer that question, I'm hoping that > someone > >>> in TSVWG will see this message and do so. > >>> > >>> Regardless of the answer to that question, my position would be that > since > >>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handlin= g > of > >>> the Traffic Class field, the following modification to 2460bis Sectio= n > 4.5 > >>> would be an appropriate way to deal with Mirja's comment: > >>> > >>> OLD: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet. > >>> NEW: > >>> The number and content of the headers preceding the Fragment > >>> header of different fragments of the same original packet may > >>> differ. Whatever headers are present, preceding the Fragment > >>> header in each fragment packet, are processed when the packets > >>> arrive, prior to queueing the fragments for reassembly. Only > >>> those headers in the Offset zero fragment packet are retained in > >>> the reassembled packet; however, nodes that support Explicit > >>> Congestion Notification [RFC3168] may use information in the > >>> Traffic Class field from all fragment packets to reconstruct the > >>> Traffic Class field in the reassembled packet. > >>> > >>> Note that this would not cause 2460bis itself to levy an additional > >>> requirement on how IPv6 nodes reassemble fragmented packets. It would > >>> simply be making note of a requirement that is already levied by > >>> RFC 3168. > >>> > >>> Thanks and regards, > >>> > >>> Mike Heard > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > --94eb2c190326a8055a054d639558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bob,

I agree with you on all points. Th= is is a good solution.

Mike Heard

On Mon, Apr 17, 2017 at 2:08 PM, Bob Hinden <bob.= hinden@gmail.com> wrote:
Hi= ,

After reading through the discussion, I think a new paragraph (after the te= xt that says how to construct a reassembled packet) like the following woul= d be appropriate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nodes that support Explicit Congestion No= tification [RFC3168]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should use information in the Traffic Cla= ss field from all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fragment packets to reco= nstruct the Traffic Class field in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reassembled packet.=C2=A0 See Sect= ion 5.3 of RFC3168 for more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.

I don=E2=80=99t think we need to quote what RFC3168 says, just point the th= e correct section.

This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, so i= t shouldn't be making any new requirements.

Comments?

Bob

> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> In line...
>
> On 18/04/2017 05:44, Black, David wrote:
>> Extracting the key portions of text:
>>
>>>> That is inconsistent with the following guidance in RFC 31= 68 (see
>>>> https://tools.ietf.org/html/rfc= 3168#section-5.3):
>>>>
>>>> 5.3.=C2=A0 Fragmentation
>>>>
>>>>=C2=A0 ECN-capable packets MAY have the DF (Don't Fragm= ent) bit set.
>>>>=C2=A0 Reassembly of a fragmented packet MUST NOT lose indi= cations of
>>>>=C2=A0 congestion.=C2=A0 In other words, if any fragment of= an IP packet to be
>>>>=C2=A0 reassembled has the CE codepoint set, then one of tw= o actions MUST be
>>>>=C2=A0 taken:
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0* Set the CE codepoint on the reassembl= ed packet.=C2=A0 However, this
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT occur if any of the oth= er fragments contributing to
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this reassembly carries the Not-= ECT codepoint.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0* The packet is dropped, instead of bei= ng reassembled, for any
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0other reason.
>>>>
>>>>=C2=A0 If both actions are applicable, either MAY be chosen= .=C2=A0 Reassembly of
>>>>=C2=A0 a fragmented packet MUST NOT change the ECN codepoin= t when all of the
>>>>=C2=A0 fragments carry the same codepoint.
>>
>>> Regardless of the answer to that question, my position would b= e that since
>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of
>>> the Traffic Class field, the following modification to 2460bis= Section 4.5
>>> would be an appropriate way to deal with Mirja's comment:<= br> >>>
>>> OLD:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>>> NEW:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes tha= t support Explicit
>>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use = information in the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from all fragment pack= ets to reconstruct the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field in the reassembled pac= ket.
>>>
>>> Note that this would not cause 2460bis itself to levy an addit= ional
>>> requirement on how IPv6 nodes reassemble fragmented packets. I= t would
>>> simply be making note of a requirement that is already levied = by
>>> RFC 3168.
>>
>> In which case, the RFC 3168 requirement should be stated e.g.:
>>
>> OLD:
>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers precedin= g the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same orig= inal packet may
>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, pr= eceding the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed = when the packets
>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for re= assembly.=C2=A0 Only
>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment pack= et are retained in
>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>> NEW:
>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers precedin= g the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same orig= inal packet may
>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, pr= eceding the Fragment
>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed = when the packets
>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for re= assembly.=C2=A0 Only
>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment pack= et are retained in
>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes that su= pport Explicit
>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use info= rmation in the
>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from any or all fragment p= ackets to reconstruct
>>=C2=A0 =C2=A0 =C2=A0 the Traffic Class field in the reassembled pac= ket in order to meet
>>=C2=A0 =C2=A0 =C2=A0 RFC 3168's requirements, e.g., that reasse= mbly not lose indications
>>=C2=A0 =C2=A0 =C2=A0 of congestion, see Section 5.3 of RFC 3168 for= additional information.
>>
>> Pointing the implementer at Section 5.3 of RFC 3168 is better than=
>> hoping she figures out on her own that she ought to take a look at= it .
>
> Yes. This is correct.
>
>=C2=A0 =C2=A0Brian
>
>>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: tsvwg [mailto:= tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard
>>> Sent: Monday, April 17, 2017 12:00 PM
>>> To: 6MAN <6man@ietf.org>; tsvwg <tsvwg@ietf.org> >>> Cc: dra= ft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden
>>> <bob.hinden@gmail.c= om>; Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>;
>>> IESG <iesg@ietf.org>= ;; 6man Chairs <6man-chairs@ietf= .org>
>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on dra= ft-ietf-6man-rfc2460bis-
>>> 09: (with DISCUSS and COMMENT)
>>>
>>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ]
>>>
>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard <heard@pobox.com> wrote:
>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter w= rote:
>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote= :
>>>>>> ...
>>>>>>>>>>> ------------------------------= ----------------------------------------
>>>>>>>>>>> COMMENT:
>>>>>>>>>>> ------------------------------= ----------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> One question because I'm n= ot sure if I interpret this correct to
>>> make it
>>>>>>>>>>> part of my discuss:
>>>>>>>>>>> Section 4.5: "The number = and content of the headers preceding
>>> the
>>>>>>>>>>> Fragment
>>>>>>>>>>> header of different fragments = of the same original packet may
>>>>>>>>>>> differ.=C2=A0 Whatever headers= are present, preceding the Fragment
>>>>>>>>>>> header in each fragment packet= , are processed when the packets
>>>>>>>>>>> arrive, prior to queueing the = fragments for reassembly.=C2=A0 Only
>>>>>>>>>>> those headers in the Offset ze= ro fragment packet are retained in
>>>>>>>>>>> the reassembled packet."<= br> >>>>>>>>>>> Does this mean the ECN codepoi= nt (part of the Traffic Class field)
>>> is
>>>>>>>>>>> copied from the first fragment= ? This doesn't seem to be correct,
>>> however,
>>>>>>>>>>> also not sure what the correct= answer is. I know this was not
>>> changed in
>>>>>>>>>>> this revision but maybe we can= still get this right.
>>>>>>>>>>
>>>>>>>>>> When fragments are created most of= the fields are copied from the
>>> IPv6
>>>>>>>>>> headers (e.g., Source Address, Des= tination address, flow label,
>>> traffic
>>>>>>>>>> class, hop limit).=C2=A0 Some like= payload length, next header, and hop
>>> limi
>>>>>>>>>> t are modified.
>>>>>>>>>>
>>>>>>>>>> If I understand your question, the= answer is yes, the ECN code
>>> point is
>>>>>>>>>> copied from the first fragment, bu= t should be the same from all of
>>> the
>>>>>>>>>> fragments.
>>>>>
>>>>> That is inconsistent with the following guidance in RF= C 3168 (see
>>>>> https://tools.ietf.org/html/rfc3168#section-5.3):
>>>>>
>>>>> 5.3.=C2=A0 Fragmentation
>>>>>
>>>>>=C2=A0 ECN-capable packets MAY have the DF (Don't F= ragment) bit set.
>>>>>=C2=A0 Reassembly of a fragmented packet MUST NOT lose = indications of
>>>>>=C2=A0 congestion.=C2=A0 In other words, if any fragmen= t of an IP packet to be
>>>>>=C2=A0 reassembled has the CE codepoint set, then one o= f two actions MUST be
>>>>>=C2=A0 taken:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0* Set the CE codepoint on the reass= embled packet.=C2=A0 However, this
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT occur if any of the= other fragments contributing to
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0this reassembly carries the = Not-ECT codepoint.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0* The packet is dropped, instead of= being reassembled, for any
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0other reason.
>>>>>
>>>>>=C2=A0 If both actions are applicable, either MAY be ch= osen.=C2=A0 Reassembly of
>>>>>=C2=A0 a fragmented packet MUST NOT change the ECN code= point when all of
>>> the
>>>>>=C2=A0 fragments carry the same codepoint.
>>>>>
>>>>>>>>> My concern is that the ECN code point = could be changed on one of
>>> the
>>>>>>>>> fragmented packets to signal congestio= n of a intermediate node and
>>>>>>>>> then when you reassemble this informat= ion gets lost. That seems
>>> wrong.
>>>>>>>>
>>>>>>>> That is an interesting idea, but I think o= ut of scope for advancing this
>>>>>>>> document to Internet Standard.=C2=A0 Then = there is the question of how to
>>>>>>>> encode n of m fragments experienced conges= tion.=C2=A0 Interesting future
>>> work.
>>>>>>>
>>>>>>> Yes there might be some more further work need= ed but that still
>>> makes the
>>>>>>> guidance in this text wrong. Maybe we can add = some text that the
>>> Traffic
>>>>>>> Class may be handled differently because it co= uld be changed on the
>>> path.
>>>>>>
>>>>>> Good point. It's not only ECN that can change;= the DSCP can change too.
>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460= , so it's logical
>>>>>> for 2460bis to note this issue.
>>>>>
>>>>> It seems that we (6man WG) missed this because RFC 316= 8 was not
>>> marked
>>>>> as updating RFC 2460. But in effect it did so for IPv6= implementations
>>>>> of ECN, even though it was not written in an IP versio= n-agnostic manner.
>>>>>
>>>>> At the very least text should be added to the descript= ion of the
>>>>> reassembly process that points the reader to RFC 3168 = or its
>>>>> successor document.
>>>>
>>>> Do we have any evidence that the guidance in RFC 3168 rega= rding
>>> reassembling
>>>> IPv6 fragments is implemented?=C2=A0 I don=E2=80=99t know,= but think if it there is
>>>> evidence I agree some text should be added to rfc2460bis, = if not, then
>>>> maybe not.
>>>
>>> Since I lack the expertise to answer that question, I'm ho= ping that someone
>>> in TSVWG will see this message and do so.
>>>
>>> Regardless of the answer to that question, my position would b= e that since
>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of
>>> the Traffic Class field, the following modification to 2460bis= Section 4.5
>>> would be an appropriate way to deal with Mirja's comment:<= br> >>>
>>> OLD:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet.
>>> NEW:
>>>=C2=A0 =C2=A0 =C2=A0 The number and content of the headers prec= eding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same = original packet may
>>>=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present= , preceding the Fragment
>>>=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are proces= sed when the packets
>>>=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments fo= r reassembly.=C2=A0 Only
>>>=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero fragment = packet are retained in
>>>=C2=A0 =C2=A0 =C2=A0 the reassembled packet; however, nodes tha= t support Explicit
>>>=C2=A0 =C2=A0 =C2=A0 Congestion Notification [RFC3168] may use = information in the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field from all fragment pack= ets to reconstruct the
>>>=C2=A0 =C2=A0 =C2=A0 Traffic Class field in the reassembled pac= ket.
>>>
>>> Note that this would not cause 2460bis itself to levy an addit= ional
>>> requirement on how IPv6 nodes reassemble fragmented packets. I= t would
>>> simply be making note of a requirement that is already levied = by
>>> RFC 3168.
>>>
>>> Thanks and regards,
>>>
>>> Mike Heard
>>
>> ------------------------------------------------------------<= wbr>--------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------<= wbr>--------
>>
>


--94eb2c190326a8055a054d639558-- From nobody Mon Apr 17 16:47:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7976126D74 for ; Mon, 17 Apr 2017 16:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 r2V5UJu0PCK2 for ; Mon, 17 Apr 2017 16:47:07 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD66124D68 for ; Mon, 17 Apr 2017 16:47:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3HNl4Md011650; Mon, 17 Apr 2017 16:47:04 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3HNl24x011643 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 17 Apr 2017 16:47:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Apr 2017 16:47:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 17 Apr 2017 16:47:02 -0700 From: "Templin, Fred L" To: Fred Baker , Mikael Abrahamsson CC: james woodyatt , "ipv6@ietf.org" , "Dave Thaler" Subject: RE: Route Information Options in IPv6 Neighbor Discovery Thread-Topic: Route Information Options in IPv6 Neighbor Discovery Thread-Index: AdKz02OPoeaHB7mXSI2gKFT6CIowLQDYdB/0ABIAnAAAFYoRkA== Date: Mon, 17 Apr 2017 23:47:01 +0000 Message-ID: <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:47:10 -0000 I have a question on how SAVI interacts with the IPv6 Redirect function in = general. When a Router Redirects a Source to a Target, the Source has discovered som= ething that it did not know before, namely that a target IPv6 prefix is reachable = via the Target directly without having to go through the Router. Armed with this knowledge however, what is to stop the Source from sending = packets with spoofed IPv6 source addresses via the Target? And, this is an issue fo= r standard IPv6 Redirect for a singleton destination and not just for Redirects that i= nclude RIOs. That said, there is a way for the Source to tell the Target about the sourc= e address(es) it intends to use by including the source addresses or prefixes in RIOs in = a NS sent to the Target before any data packets are sent. And, if the Source lies abo= ut any of its addresses any SAVI L2 devices that examine the NS messages can drop the= m. Thanks - Fred=20 > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Sunday, April 16, 2017 11:19 PM > To: Mikael Abrahamsson > Cc: Templin, Fred L ; james woodyatt ; ipv6@ietf.org; Dave Thaler > > Subject: Re: Route Information Options in IPv6 Neighbor Discovery >=20 >=20 > > On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson wrot= e: > > > > On Fri, 14 Apr 2017, Fred Baker wrote: > > > >>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine wo= uld be in scope for this documents security section. For > instance, what would an SAVI enabled L2 switch that inspects ND entries d= o when it sees this RIO entry in ND? > >> > >> As specified, I think it would ignore them. It looks at the NA to dete= rmine what {IP address, MAC address} or {IP address, MAC > address, Port #} association it should enforce. It has no illusion that t= his is the only data present. > > > > So the question becomes, is this desired behaviour? Sounds to me that t= here needs to be SAVI document enhancement for this RIO > in ND then, for things to continue functioning properly (as I imagine if = something sends RIO in ND to somewhere, there is expectation > that any antispoofing device should allow for return traffic as well). >=20 > Please feel free to make specific suggestions. >=20 > https://tools.ietf.org/html/rfc6620 > 6620 FCFS SAVI: First-Come, First-Served Source Address Validation > Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. > Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) > (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) >=20 > https://tools.ietf.org/html/rfc6959 > 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. > McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 byte= s) > (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) >=20 > https://tools.ietf.org/html/rfc7039 > 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. > Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: > TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) >=20 > https://tools.ietf.org/html/rfc7219 > 7219 SEcure Neighbor Discovery (SEND) Source Address Validation > Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. > (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: > 10.17487/RFC7219) >=20 > https://tools.ietf.org/html/rfc7513 > 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. > Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 bytes) > (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) >=20 > https://tools.ietf.org/html/rfc8074 > 8074 Source Address Validation Improvement (SAVI) for Mixed Address > Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. > Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) > (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) >=20 >=20 From nobody Mon Apr 17 17:37:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3821126C2F for ; Mon, 17 Apr 2017 17:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 lFIla8dD8pJv for ; Mon, 17 Apr 2017 17:37:14 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 C7E23128768 for ; Mon, 17 Apr 2017 17:37:14 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id i5so72588825pfc.2 for ; Mon, 17 Apr 2017 17:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:reply-to:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9MJsTMP6B/hDJgSsC7V2vjO3p/F9lA3ZQB5iBGl9np8=; b=u21BiRi83+fFWJEYgwtZnIYrk0aAnFJ+qDBN1pfxZDV+OLPw9HaU7L5pME2QjGS7pJ 1GXTXAIzb9AE+QpyJ7CU+59EsALfsb+GN22uUplagDaUUWVsLVVSKvaap9keL/zRskTv lQYqBk2K4eXgqhRRhl8ZmtpM0BskDe4WcRFju9sf9MyMdJKZcH6rOXYHjS7rJKtxb0AT uejHMFBQYYdlaOz6N5yWTkKfrDMrhLEoRSvxp0dBCiHamG6fiudHE33ItZDIg/bl0qqn zQNay63nLnYQ7KchD7HnwHgAWO2aY21S4D6HEj/Qb4T3CzdQIoBVve5gH8JHvolYPUYQ 6VTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:reply-to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9MJsTMP6B/hDJgSsC7V2vjO3p/F9lA3ZQB5iBGl9np8=; b=Q2vrNuULGeCRuhp2KaabCIrl16GxMLJtJ5IL6TnHV8PyuWXoaGnGiM4GvbyGizTBOK K0F4W71mo1ebOp78Ue1wmoGUB05geGjll/NMHMVpsQjTRbNF+pDo02GmDkMhunuLz1a3 usCMfypNziofcuekBTjo6UMlfdYfRGHP5yqBqSYP9sSdAnJZ0y6xefZD1+TCa5xOSTOH bsuZ3syfiAig8PFT9/YRRCyGwZkpgqhPHtzzZBV6cOONGl7f+BUfX9//f1Pq/7Exkg32 5qqS6rTFE/g8K9+YEUhEXiMpb7PYCda/xlO82s37oC8vX+V56oa25RQBdOOneFvPUfZl lsIQ== X-Gm-Message-State: AN3rC/4P6qKu5kAl8KJzZWLIysRL3yvJa1dwOA0reImRn25gubVlHS0Z Q35hOe7ABxDKRBeP X-Received: by 10.84.229.76 with SMTP id d12mr19449320pln.14.1492475834084; Mon, 17 Apr 2017 17:37:14 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o23sm20140935pfi.100.2017.04.17.17.37.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 17:37:13 -0700 (PDT) Subject: Fwd: [tsvwg] [Editorial Errata Reported] RFC3168 (4997) References: <20170417211852.C3968B81069@rfc-editor.org> To: 6man Reply-To: 6man From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <20170417211852.C3968B81069@rfc-editor.org> Message-ID: <4d688a9b-a892-7724-366b-fae2b8be6212@gmail.com> Date: Tue, 18 Apr 2017 12:37:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170417211852.C3968B81069@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:37:17 -0000 -------- Forwarded Message -------- Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (4997) Date: Mon, 17 Apr 2017 14:18:52 -0700 (PDT) From: RFC Errata System To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com CC: heard@pobox.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3168&eid=4997 -------------------------------------- Type: Editorial Reported by: C. M. Heard Section: Header Original Text ------------- Updates: 2474, 2401, 793 Corrected Text -------------- Updates: 2474, 2460, 2401, 793 Notes ----- RFC 3168 updates RFC 2460 but does not indicate this in its header block. Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460. There are other missing Updates: fields; see e.g. Erratum 2660. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Apr 17 17:38:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B2129401; Mon, 17 Apr 2017 17:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 rFNbR36LiqyA; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 1CA5B126C2F; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id a188so27687228pfa.2; Mon, 17 Apr 2017 17:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oPu5m61HwrvsKOIhI5E0aP+tuxuDW2SNltPFe76dH0U=; b=qW/Moe3FKmS34YqU2Fso3ps4fNLJVTFLq5UQhueOfM93NT/Qh8DIq+74/S/K0evWRd hxXg+Zoh4ytM6sSzXCdTbA23Dggg5JcbuBDCjMOMa3cLGmPcyk1QPqUSVjVyBtjFUyo8 bbtd6QQQfyRkLygNzqjV5ccahapqrJuJPF6a1VPmqiva8SUGqnzmdKJpMgP7tbgc5g3K xfafUOgUUxPG8FUVpxV5Hyhm6NvfHjc/pVFZ7TQid7NZF3eoMbzan7+Kw30gVaXVhhdd iHhPqsQKZWcJ6UixsoXNCMIXr14qxoalpXUpIbODW21/VQtCKlcUH2BtNN5G+JO3jYCM kccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=oPu5m61HwrvsKOIhI5E0aP+tuxuDW2SNltPFe76dH0U=; b=VlKGi7VtX2VO74ov32d9NRRycQLB1zER0DypONfm1BWvkJiGTSb8aiD0/aP0n6pjdf JJk1EXVrnf22dHUitPxXH/AZnm9AkLDBiTTqnnaIsIzfpJpUXNR6GTE0jvWDcJBupOxS ggqouguk7o3emlNWlmv4f32dwYDUE5vvVYsiM9qdECZ1+R1tRHEjsLzTmNVFEU1K2q7y 1IUHJcWrbUWKSchfU4T4gYSj/vTHvRTzulEiE9ZBYWFtOyAHG3+L0XAWGriZWy1TXBZA +3y6wIFA9exXAWY84CQhfXIbhCmDzRVcm/vEC29i3r/2voCdWtVveSAIs4qGkOYmi3EM V6+w== X-Gm-Message-State: AN3rC/4zAGx2n8PRafTEzZ43MNRzSpIqp16IVMY1bYvu8goHJ4Qt19xi c1jd3wuwf1U1Bg== X-Received: by 10.99.109.75 with SMTP id i72mr12306200pgc.215.1492475932613; Mon, 17 Apr 2017 17:38:52 -0700 (PDT) Received: from ?IPv6:2406:e001:3f9b:1:28cc:dc4c:9703:6781? ([2406:e001:3f9b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l22sm17218141pfi.2.2017.04.17.17.38.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 17:38:52 -0700 (PDT) Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> Cc: "Black, David" , "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> Date: Tue, 18 Apr 2017 12:38:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:38:56 -0000 wfm=20 On 18/04/2017 09:08, Bob Hinden wrote: > Hi, >=20 > After reading through the discussion, I think a new paragraph (after th= e text that says how to construct a reassembled packet) like the followin= g would be appropriate. >=20 > Nodes that support Explicit Congestion Notification [RFC3168] > should use information in the Traffic Class field from all > fragment packets to reconstruct the Traffic Class field in the= > reassembled packet. See Section 5.3 of RFC3168 for more > information. >=20 > I don=E2=80=99t think we need to quote what RFC3168 says, just point th= e the correct section. >=20 > This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN, = so it shouldn't be making any new requirements. >=20 > Comments? >=20 > Bob >=20 >> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter wrote: >> >> In line... >> >> On 18/04/2017 05:44, Black, David wrote: >>> Extracting the key portions of text: >>> >>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>> >>>>> 5.3. Fragmentation >>>>> >>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>> congestion. In other words, if any fragment of an IP packet to be= >>>>> reassembled has the CE codepoint set, then one of two actions MUST= be >>>>> taken: >>>>> >>>>> * Set the CE codepoint on the reassembled packet. However, thi= s >>>>> MUST NOT occur if any of the other fragments contributing to >>>>> this reassembly carries the Not-ECT codepoint. >>>>> >>>>> * The packet is dropped, instead of being reassembled, for any >>>>> other reason. >>>>> >>>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>>> a fragmented packet MUST NOT change the ECN codepoint when all of = the >>>>> fragments carry the same codepoint. >>> >>>> Regardless of the answer to that question, my position would be that= since >>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handli= ng of >>>> the Traffic Class field, the following modification to 2460bis Secti= on 4.5 >>>> would be an appropriate way to deal with Mirja's comment: >>>> >>>> OLD: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet. >>>> NEW: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet; however, nodes that support Explicit >>>> Congestion Notification [RFC3168] may use information in the >>>> Traffic Class field from all fragment packets to reconstruct th= e >>>> Traffic Class field in the reassembled packet. >>>> >>>> Note that this would not cause 2460bis itself to levy an additional >>>> requirement on how IPv6 nodes reassemble fragmented packets. It woul= d >>>> simply be making note of a requirement that is already levied by >>>> RFC 3168. >>> >>> In which case, the RFC 3168 requirement should be stated e.g.: >>> >>> OLD: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in= >>> the reassembled packet. >>> NEW: >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in= >>> the reassembled packet; however, nodes that support Explicit >>> Congestion Notification [RFC3168] may use information in the >>> Traffic Class field from any or all fragment packets to reconstr= uct >>> the Traffic Class field in the reassembled packet in order to me= et >>> RFC 3168's requirements, e.g., that reassembly not lose indicati= ons >>> of congestion, see Section 5.3 of RFC 3168 for additional inform= ation. >>> >>> Pointing the implementer at Section 5.3 of RFC 3168 is better than >>> hoping she figures out on her own that she ought to take a look at it= . >> >> Yes. This is correct. >> >> Brian >> >>> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Heard= >>>> Sent: Monday, April 17, 2017 12:00 PM >>>> To: 6MAN <6man@ietf.org>; tsvwg >>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>> ; Mirja Kuehlewind (IETF) ; >>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-6m= an-rfc2460bis- >>>> 09: (with DISCUSS and COMMENT) >>>> >>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sectio= n 5.3 ] >>>> >>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>> ... >>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>> COMMENT: >>>>>>>>>>>> ------------------------------------------------------------= ---------- >>>>>>>>>>>> >>>>>>>>>>>> One question because I'm not sure if I interpret this correc= t to >>>> make it >>>>>>>>>>>> part of my discuss: >>>>>>>>>>>> Section 4.5: "The number and content of the headers precedin= g >>>> the >>>>>>>>>>>> Fragment >>>>>>>>>>>> header of different fragments of the same original packet ma= y >>>>>>>>>>>> differ. Whatever headers are present, preceding the Fragmen= t >>>>>>>>>>>> header in each fragment packet, are processed when the packe= ts >>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. Onl= y >>>>>>>>>>>> those headers in the Offset zero fragment packet are retaine= d in >>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Class = field) >>>> is >>>>>>>>>>>> copied from the first fragment? This doesn't seem to be corr= ect, >>>> however, >>>>>>>>>>>> also not sure what the correct answer is. I know this was no= t >>>> changed in >>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>> >>>>>>>>>>> When fragments are created most of the fields are copied from= the >>>> IPv6 >>>>>>>>>>> headers (e.g., Source Address, Destination address, flow labe= l, >>>> traffic >>>>>>>>>>> class, hop limit). Some like payload length, next header, an= d hop >>>> limi >>>>>>>>>>> t are modified. >>>>>>>>>>> >>>>>>>>>>> If I understand your question, the answer is yes, the ECN cod= e >>>> point is >>>>>>>>>>> copied from the first fragment, but should be the same from a= ll of >>>> the >>>>>>>>>>> fragments. >>>>>> >>>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>> >>>>>> 5.3. Fragmentation >>>>>> >>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>> congestion. In other words, if any fragment of an IP packet to b= e >>>>>> reassembled has the CE codepoint set, then one of two actions MUS= T be >>>>>> taken: >>>>>> >>>>>> * Set the CE codepoint on the reassembled packet. However, th= is >>>>>> MUST NOT occur if any of the other fragments contributing to= >>>>>> this reassembly carries the Not-ECT codepoint. >>>>>> >>>>>> * The packet is dropped, instead of being reassembled, for any= >>>>>> other reason. >>>>>> >>>>>> If both actions are applicable, either MAY be chosen. Reassembly= of >>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of= >>>> the >>>>>> fragments carry the same codepoint. >>>>>> >>>>>>>>>> My concern is that the ECN code point could be changed on one = of >>>> the >>>>>>>>>> fragmented packets to signal congestion of a intermediate node= and >>>>>>>>>> then when you reassemble this information gets lost. That seem= s >>>> wrong. >>>>>>>>> >>>>>>>>> That is an interesting idea, but I think out of scope for advan= cing this >>>>>>>>> document to Internet Standard. Then there is the question of h= ow to >>>>>>>>> encode n of m fragments experienced congestion. Interesting fu= ture >>>> work. >>>>>>>> >>>>>>>> Yes there might be some more further work needed but that still >>>> makes the >>>>>>>> guidance in this text wrong. Maybe we can add some text that the= >>>> Traffic >>>>>>>> Class may be handled differently because it could be changed on = the >>>> path. >>>>>>> >>>>>>> Good point. It's not only ECN that can change; the DSCP can chang= e too. >>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logic= al >>>>>>> for 2460bis to note this issue. >>>>>> >>>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>>> marked >>>>>> as updating RFC 2460. But in effect it did so for IPv6 implementat= ions >>>>>> of ECN, even though it was not written in an IP version-agnostic m= anner. >>>>>> >>>>>> At the very least text should be added to the description of the >>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>> successor document. >>>>> >>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>> reassembling >>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think if = it there is >>>>> evidence I agree some text should be added to rfc2460bis, if not, t= hen >>>>> maybe not. >>>> >>>> Since I lack the expertise to answer that question, I'm hoping that = someone >>>> in TSVWG will see this message and do so. >>>> >>>> Regardless of the answer to that question, my position would be that= since >>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the handli= ng of >>>> the Traffic Class field, the following modification to 2460bis Secti= on 4.5 >>>> would be an appropriate way to deal with Mirja's comment: >>>> >>>> OLD: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet. >>>> NEW: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained i= n >>>> the reassembled packet; however, nodes that support Explicit >>>> Congestion Notification [RFC3168] may use information in the >>>> Traffic Class field from all fragment packets to reconstruct th= e >>>> Traffic Class field in the reassembled packet. >>>> >>>> Note that this would not cause 2460bis itself to levy an additional >>>> requirement on how IPv6 nodes reassemble fragmented packets. It woul= d >>>> simply be making note of a requirement that is already levied by >>>> RFC 3168. >>>> >>>> Thanks and regards, >>>> >>>> Mike Heard >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >=20 From nobody Mon Apr 17 17:42:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E76B128768 for ; Mon, 17 Apr 2017 17:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 yURsxsZc-u1V for ; Mon, 17 Apr 2017 17:41:59 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 E841B126C2F for ; Mon, 17 Apr 2017 17:41:58 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id 63so19189521pgh.0 for ; Mon, 17 Apr 2017 17:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FdujEAC2wn2wkVdcWnogd7aZWKELZ9SgiFoEIrsVclw=; b=lRQuL8+IeGnoGnDE3XbZVUVZuAg0UcOprFMzjoLS5eJYor8zXl4y2j7ZVS9TwZi6QZ 8//Z5PU4PJllWlOX2jVS4GkRYFnaAqKfh6XDmg+9662SkB5KXUN+e0lqv/nlb3/G+JbH hIH+T0D4DWHKGLP8xWO3/axiWHNBaJTFsHM8zPKHDdp1xfRaTi1rtEphKijIicUieqo8 IszC/LsDbPhj/xWffcTnEyjvMeUFP2YsXI2wYNJR/jJgM3RTSSmLZcm6bDE62i16Rsyt eJJAALgxoxuMJzA7yJoAHfv+G09j8j5/1N/yZz0tr7kOAd0kh+A++0y2fBWxq7eRWRjn sLaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FdujEAC2wn2wkVdcWnogd7aZWKELZ9SgiFoEIrsVclw=; b=DQZeOiSBOhuVSidTLxIy6C9At/98bV7QjvHXScLErsj0Xc13MEkkPXoEnh9MEkDjXk EpXZOeVfZlimHt6YgOIxdaFKkKmVHkp8NQzt/WOn2khxQizUXgdaAuw5qIW6iqlRh0G+ 3+ZhMrI4Szyg3vs+RA+2XpHoNb27dFac5vfoSRmn9FB/suVRf4bOKVE1EgkrlPpRTyvT DpqOMINvHZLOZgWPZqN0pMR6r8clSg0+RCDgJQ4JaPGCb8geav+TRvYOQSR15F2YE+aC ULqzOgRlwbymvz6J552OIAjBwbehDzgOq0QxNPIrh2w1XfGjGCOGsQIFtHBB3ykn0Eai jeOQ== X-Gm-Message-State: AN3rC/6j6p1gCFO2Xm1zL2vB7q7QkysvTVU2xuIStUenNyneAlTm+HE2 A+tZlX5DHFkD9w== X-Received: by 10.99.45.197 with SMTP id t188mr15170856pgt.209.1492476118526; Mon, 17 Apr 2017 17:41:58 -0700 (PDT) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id y123sm20147974pfg.52.2017.04.17.17.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 17:41:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Route Information Options in IPv6 Neighbor Discovery From: Fred Baker In-Reply-To: <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> Date: Mon, 17 Apr 2017 17:41:55 -0700 Cc: Mikael Abrahamsson , james woodyatt , "ipv6@ietf.org" , Dave Thaler Content-Transfer-Encoding: quoted-printable Message-Id: <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> To: Fred Templin X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:42:01 -0000 We have essentially the same problem with IPv4 Source Guard, as several = companies call the technology. It has been deployed since 2004 or = thereabouts as proprietary technology, but operates essentially as = SAVI/DHCP does. We don't observe the issue you raise. A redirect in essence is router A telling some host that router B in the = same subnet that would be a better choice - that router A's next hop for = the indicated address is router B, and the host can be a good citizen by = sending that traffic to B in the first place. If they're in the same = subnet and the host can talk with both of them, the host is going to use = the same source address and the same interface. SAVI is thrilled, and if = the host does as it is told, we reduced message rate on the LAN a little = bit. Further discussion of SAVI should probably go to savi@ietf.org... > On Apr 17, 2017, at 4:47 PM, Templin, Fred L = wrote: >=20 > I have a question on how SAVI interacts with the IPv6 Redirect = function in general. > When a Router Redirects a Source to a Target, the Source has = discovered something > that it did not know before, namely that a target IPv6 prefix is = reachable via the > Target directly without having to go through the Router. >=20 > Armed with this knowledge however, what is to stop the Source from = sending packets > with spoofed IPv6 source addresses via the Target? And, this is an = issue for standard > IPv6 Redirect for a singleton destination and not just for Redirects = that include RIOs. >=20 > That said, there is a way for the Source to tell the Target about the = source address(es) > it intends to use by including the source addresses or prefixes in = RIOs in a NS sent > to the Target before any data packets are sent. And, if the Source = lies about any of > its addresses any SAVI L2 devices that examine the NS messages can = drop them. >=20 > Thanks - Fred=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] >> Sent: Sunday, April 16, 2017 11:19 PM >> To: Mikael Abrahamsson >> Cc: Templin, Fred L ; james woodyatt = ; ipv6@ietf.org; Dave Thaler >> >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery >>=20 >>=20 >>> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson = wrote: >>>=20 >>> On Fri, 14 Apr 2017, Fred Baker wrote: >>>=20 >>>>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would be in scope for this documents security section. For >> instance, what would an SAVI enabled L2 switch that inspects ND = entries do when it sees this RIO entry in ND? >>>>=20 >>>> As specified, I think it would ignore them. It looks at the NA to = determine what {IP address, MAC address} or {IP address, MAC >> address, Port #} association it should enforce. It has no illusion = that this is the only data present. >>>=20 >>> So the question becomes, is this desired behaviour? Sounds to me = that there needs to be SAVI document enhancement for this RIO >> in ND then, for things to continue functioning properly (as I imagine = if something sends RIO in ND to somewhere, there is expectation >> that any antispoofing device should allow for return traffic as = well). >>=20 >> Please feel free to make specific suggestions. >>=20 >> https://tools.ietf.org/html/rfc6620 >> 6620 FCFS SAVI: First-Come, First-Served Source Address Validation >> Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. >> Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) >>=20 >> https://tools.ietf.org/html/rfc6959 >> 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. >> McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 = bytes) >> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) >>=20 >> https://tools.ietf.org/html/rfc7039 >> 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, = J. >> Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: >> TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: = 10.17487/RFC7039) >>=20 >> https://tools.ietf.org/html/rfc7219 >> 7219 SEcure Neighbor Discovery (SEND) Source Address Validation >> Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. >> (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: >> 10.17487/RFC7219) >>=20 >> https://tools.ietf.org/html/rfc7513 >> 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. = J. >> Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 = bytes) >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) >>=20 >> https://tools.ietf.org/html/rfc8074 >> 8074 Source Address Validation Improvement (SAVI) for Mixed Address >> Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. >> Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) >>=20 >>=20 >=20 >=20 From nobody Mon Apr 17 18:07:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79231200DF for ; Mon, 17 Apr 2017 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 znwB3BY9zj-q for ; Mon, 17 Apr 2017 18:07:31 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC641200C5 for ; Mon, 17 Apr 2017 18:07:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3I17Vh4043640; Mon, 17 Apr 2017 18:07:31 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3I17Ndu043238 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 17 Apr 2017 18:07:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Apr 2017 18:07:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Mon, 17 Apr 2017 18:07:22 -0700 From: "Templin, Fred L" To: Fred Baker CC: Mikael Abrahamsson , james woodyatt , "ipv6@ietf.org" , Dave Thaler Subject: RE: Route Information Options in IPv6 Neighbor Discovery Thread-Topic: Route Information Options in IPv6 Neighbor Discovery Thread-Index: AdKz02OPoeaHB7mXSI2gKFT6CIowLQDYdB/0ABIAnAAAFYoRkAAQ+GSAAA4dLlA= Date: Tue, 18 Apr 2017 01:07:22 +0000 Message-ID: <9270857bc53146988fff10f58a869242@XCH15-06-08.nw.nos.boeing.com> References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> In-Reply-To: <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 01:07:34 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Monday, April 17, 2017 5:42 PM > To: Templin, Fred L > Cc: Mikael Abrahamsson ; james woodyatt ; ipv6@ietf.org; Dave Thaler > > Subject: Re: Route Information Options in IPv6 Neighbor Discovery >=20 > We have essentially the same problem with IPv4 Source Guard, as several c= ompanies call the technology. It has been deployed since > 2004 or thereabouts as proprietary technology, but operates essentially a= s SAVI/DHCP does. We don't observe the issue you raise. >=20 > A redirect in essence is router A telling some host that router B in the = same subnet that would be a better choice - that router A's next > hop for the indicated address is router B, and the host can be a good cit= izen by sending that traffic to B in the first place. If they're in > the same subnet and the host can talk with both of them, the host is goin= g to use the same source address and the same interface. > SAVI is thrilled, and if the host does as it is told, we reduced message = rate on the LAN a little bit. The issue is what happens if, after the redirection, the Source (what you a= re calling the "host") starts sending packets with IPv6 source addresses other than the on= e(s) it has configured from an on-link prefix. The Target (what you are calling "router= B") would have no way of knowing what IPv6 source addresses are allowed to emanate fr= om the Source. What I am suggesting is that the Source could first tell the Ta= rget about the source addresses/prefixes it is authorized to use by sending the Target= an NS message, and any L2 SAVI gear can simply drop the message if the Source lie= s. Thanks - Fred > Further discussion of SAVI should probably go to savi@ietf.org... >=20 > > On Apr 17, 2017, at 4:47 PM, Templin, Fred L wrote: > > > > I have a question on how SAVI interacts with the IPv6 Redirect function= in general. > > When a Router Redirects a Source to a Target, the Source has discovered= something > > that it did not know before, namely that a target IPv6 prefix is reacha= ble via the > > Target directly without having to go through the Router. > > > > Armed with this knowledge however, what is to stop the Source from send= ing packets > > with spoofed IPv6 source addresses via the Target? And, this is an issu= e for standard > > IPv6 Redirect for a singleton destination and not just for Redirects th= at include RIOs. > > > > That said, there is a way for the Source to tell the Target about the s= ource address(es) > > it intends to use by including the source addresses or prefixes in RIOs= in a NS sent > > to the Target before any data packets are sent. And, if the Source lies= about any of > > its addresses any SAVI L2 devices that examine the NS messages can drop= them. > > > > Thanks - Fred > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > >> Sent: Sunday, April 16, 2017 11:19 PM > >> To: Mikael Abrahamsson > >> Cc: Templin, Fred L ; james woodyatt ; ipv6@ietf.org; Dave Thaler > >> > >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery > >> > >> > >>> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson wr= ote: > >>> > >>> On Fri, 14 Apr 2017, Fred Baker wrote: > >>> > >>>>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would be in scope for this documents security section. For > >> instance, what would an SAVI enabled L2 switch that inspects ND entrie= s do when it sees this RIO entry in ND? > >>>> > >>>> As specified, I think it would ignore them. It looks at the NA to de= termine what {IP address, MAC address} or {IP address, MAC > >> address, Port #} association it should enforce. It has no illusion tha= t this is the only data present. > >>> > >>> So the question becomes, is this desired behaviour? Sounds to me that= there needs to be SAVI document enhancement for this > RIO > >> in ND then, for things to continue functioning properly (as I imagine = if something sends RIO in ND to somewhere, there is > expectation > >> that any antispoofing device should allow for return traffic as well). > >> > >> Please feel free to make specific suggestions. > >> > >> https://tools.ietf.org/html/rfc6620 > >> 6620 FCFS SAVI: First-Come, First-Served Source Address Validation > >> Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. > >> Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) > >> > >> https://tools.ietf.org/html/rfc6959 > >> 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. > >> McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 by= tes) > >> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) > >> > >> https://tools.ietf.org/html/rfc7039 > >> 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. > >> Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: > >> TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) > >> > >> https://tools.ietf.org/html/rfc7219 > >> 7219 SEcure Neighbor Discovery (SEND) Source Address Validation > >> Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. > >> (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: > >> 10.17487/RFC7219) > >> > >> https://tools.ietf.org/html/rfc7513 > >> 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J= . > >> Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 bytes= ) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) > >> > >> https://tools.ietf.org/html/rfc8074 > >> 8074 Source Address Validation Improvement (SAVI) for Mixed Address > >> Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. > >> Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) > >> > >> > > > > >=20 From nobody Tue Apr 18 00:18:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018221315D0; Tue, 18 Apr 2017 00:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 T2-t9gtg998x; Tue, 18 Apr 2017 00:18:27 -0700 (PDT) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (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 57AE6131541; Tue, 18 Apr 2017 00:18:27 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p11im-asmtp003.me.com by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OOL00A00FYMU300@st13p11im-asmtp003.me.com>; Tue, 18 Apr 2017 07:18:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1492499888; bh=XKi1GtFR3ssq2E1gwynu/GtXs9pmNW4rOEB9eDSX5CA=; h=From:Content-type:MIME-version:Subject:Message-id:To:Date; b=kuGaOhR6gvWsGHcTn95o5xXn4IyVG6KUdo0FzH3NX1UxAz/V+H/P0U+lrrHK1FHrl meJmbbIqQ1Q7eFrH2cyrnI/615X4YBP7Zxz1D/tTglg0Ns4KF7Z++VxrAD/1rf8FF8 +0J/KblszPL5p+icj9P9vvEmyGoGU6pFPB4kQ/kdt401pXBLAVel8ZgZerIgtqgjfE mH5bOHleyiUyHQjJCnvbwzOkFA7moUf5a1hFHPMfgrV++ZSgttNCpWTyqTIZAQUWcf hQ8MRdNnInVnCi94OVlISbpHH96wLMZIi1+gos50usAaWZd8EYz45A1yyOFvqZj+Ek uvT+AKkJ1Pfqg== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OOL0061KGA68U40@st13p11im-asmtp003.me.com>; Tue, 18 Apr 2017 07:18:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-18_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1704180063 From: Gunter Van De Velde Content-type: multipart/alternative; boundary="Apple-Mail=_766784FF-9485-435A-BB33-568A06584210" MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 Message-id: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> To: 6man@ietf.org, v6ops@ietf.org Date: Tue, 18 Apr 2017 09:18:05 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:18:29 -0000 --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear 6man, v6ops, Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. Please send your feedback to OPSEC email list, where discussion around = this document should take place. Kind Regards, G/ > Begin forwarded message: >=20 > From: Gunter Van De Velde > Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 > Date: 12 April 2017 at 09:39:28 GMT+2 > To: opsec@ietf.org >=20 > This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6 = . > If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >=20 > I will close the call on 26 April 2017 >=20 > G/=20 > Sent from iCloud > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear 6man, v6ops,

Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC = for this document may be of interest to both 6man as v6ops.

Please send your feedback to OPSEC email = list, where discussion around this document should take = place.

Kind = Regards,
G/

Begin forwarded message:

From: = Gunter Van De Velde <guntervandeveldecc@icloud.com>
Subject: = [OPSEC] WGLC for = draft-ietf-opsec-v6
Date: = 12 April 2017 at 09:39:28 = GMT+2
To: = opsec@ietf.org

This is to open a two week WGLC = for https://tools.ietf.org/html/draft-ietf-opsec-v6.
If you have not read it, please = do so now. You may send nits to the author, but substantive discussion = should go to the list.

I will close the = call on 26 April 2017

G/ 
Sent from =
iCloud
___________________________________________= ____
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

= --Apple-Mail=_766784FF-9485-435A-BB33-568A06584210-- From nobody Tue Apr 18 00:31:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5050313178F for ; Tue, 18 Apr 2017 00:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=google.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 fvmpSPYBW6ln for ; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 7139A131560 for <6man@ietf.org>; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id 62so5964960ybg.2 for <6man@ietf.org>; Tue, 18 Apr 2017 00:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o++/Pl1+atiDNUlAbkRsso/JlcwCkC42MbYLSR1a9ao=; b=Xu5kiN77e8Vv05c2+HD9+bS30LhBomRf/gfayq9Wr4CCx7uQJxiMxbkz9/WMYNelRo ozKI1ywUejFCEEsSD5LDMqtEZU79R+Sgljxx2BIHXVKaQ8VoW6dQZCFVZcsYgo5TxkPY fAb0NVAas8K3WSICsZ8trqQX05gQuuXnQuVXeqDKQF2ZnefeytgXdxLScG4TiFzbFJWH hsdCqahA8Idk23lr66heno669s4IX+COp3Z+6VaCTDxJZRlcJgm5oL3ofCBV44ezTYXZ V3x8OKwRhVO3AE9WwLGsewbYxWYMyk+5/2UCTY3fM+txeWFo06iXHXWGV1f59aeST+jU H3HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o++/Pl1+atiDNUlAbkRsso/JlcwCkC42MbYLSR1a9ao=; b=poNYClHnYRAXPoAgIeiBh4ScahjOCIzx3pCt3Vo6FV4xfJTqGnRn+7n9kiseEKGbo4 1IRIrE/cLfNP51TdMbyL1oI/BY2+z2rTI/Ot1wMpXVxJJ2MlzecxbX1wfwEWNdb+KIwq n8RfXaNwVLulDfOjmRKaJFnSGe8+6zBfW79sChfbShn9rDx1OiGYWh7P1xYMAwMoil2H B5bM0pfUwAlY2ertSCh5ti4Nf7xwe0ABQITS9F0PH4roX/p986r0ec1EiYr5tSRxiwdC nT5JolaaO2A3PM2p3CMqTua3SlReLr9k93sSutz7duhobNco0GTcJ000Z5L4bZi2Ffmz BXgg== X-Gm-Message-State: AN3rC/7QtYzgWwqhS+Wd8k6yMbR6HjsoCUz8V7e6U/mPtF4Tb6I5BPOU FJPwpYGg9v8zR0ny9y+tkqnLAw1j3loP X-Received: by 10.37.87.134 with SMTP id l128mr18469850ybb.85.1492500668380; Tue, 18 Apr 2017 00:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Tue, 18 Apr 2017 00:30:47 -0700 (PDT) In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Erik Kline Date: Tue, 18 Apr 2017 16:30:47 +0900 Message-ID: Subject: Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 To: Gunter Van De Velde Cc: 6man <6man@ietf.org>, "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113e6eee32d8c0054d6be419" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:31:11 -0000 --001a113e6eee32d8c0054d6be419 Content-Type: multipart/alternative; boundary=001a113e6eee2acd23054d6be418 --001a113e6eee2acd23054d6be418 Content-Type: text/plain; charset=UTF-8 2.1.2. Use of ULAs Still? Really? On 18 April 2017 at 16:18, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > Dear 6man, v6ops, > > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > > Kind Regards, > G/ > > Begin forwarded message: > > *From: *Gunter Van De Velde > *Subject: **[OPSEC] WGLC for draft-ietf-opsec-v6* > *Date: *12 April 2017 at 09:39:28 GMT+2 > *To: *opsec@ietf.org > > This is to open a two week WGLC for https://tools.ietf.org/ > html/draft-ietf-opsec-v6. > If you have not read it, please do so now. You may send nits to the > author, but substantive discussion should go to the list. > > I will close the call on 26 April 2017 > > G/ > > Sent from iCloud > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113e6eee2acd23054d6be418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2.1.2.=C2=A0 Use of ULAs

Sti= ll?=C2=A0 Really?

On 18 April 2017 at 16:18, Gunter Van De Velde <gu= ntervandeveldecc@icloud.com> wrote:
Dear 6man, v6ops,

Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC W= GLC for this document may be of interest to both 6man as v6ops.
<= br>
Please send your feedback to OPSEC email list, where discussion aro= und this document should take place.

Kind Regards,=
G/

Begin forwarded = message:

From: Gunter V= an De Velde <guntervandeveldecc@icloud.com>
Subject: [OPSEC] WGL= C for draft-ietf-opsec-v6
Date: 12 April 2017 at 09:39:28 GMT+2
To: <= a href=3D"mailto:opsec@ietf.org" target=3D"_blank">opsec@ietf.org

This is to open a two week WGLC for=C2=A0https://tool= s.ietf.org/html/draft-ietf-opsec-v6.
If you have not read i= t, please do so now. You may send nits to the author, but substantive discu= ssion should go to the list.

I will close the call on 26 A= pril 2017

G/=C2=A0
Sent from iCloud
____________________= ___________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsec


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


--001a113e6eee2acd23054d6be418-- --001a113e6eee32d8c0054d6be419 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQggXY5kGM7X/stWUIIVZHczEc4XGATbRrh zmdvm0QabKswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE4 MDczMTA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABUI1HCQShBBUPzor9OwSljSG89rU5nMer93cI/OKXlrsYm3jpWQ ZZtEQzBhyxpEgFOqhI7nU6hd9JlSa9UtQULlJUdLNz0kaqE//A0rChfdhxtDwt7pXmtj8BGupQIi 4FP/w5XCUdPjYu/mM8LqNlIJXNKrki3udmV59xiZrmBGQMpCpez3UFz50nfqPoOE3z7XZ9X128Dw XSDG/70NiREf+BhYnl646lGCGTMWIXHkbYvOYA8HPVFFUWSSNmca93PZUTXBvp5Jzn6ZirWebIwK d/uAlSq5W74F0JOIbzzSqvZ1Nj5uP5jAktPMYet/u6lBF73e0jlD2MeemtjFEgI= --001a113e6eee32d8c0054d6be419-- From nobody Tue Apr 18 00:51:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17BB1317DF for ; Tue, 18 Apr 2017 00:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8a1zqTgXY8-2 for ; Tue, 18 Apr 2017 00:51:42 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 22A2B1317E6 for <6man@ietf.org>; Tue, 18 Apr 2017 00:51:41 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id r69so70978155vke.2 for <6man@ietf.org>; Tue, 18 Apr 2017 00:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=o0Pazzmr3JUJJAueR9nW7PbqfH1OK0ptbJzpzSq4qYy0lbs0OmhUjxnNfxzSFi9M43 akEg8D0gF2uD0Dwy6gUPJBAtH8lgXHtKHw5xQ3+MBnpJiqBuEClh45PkZkGT6TNlnlut uMFS/dBlSYJ5Tub14TQ+Ve7QUFu9B2PBOr3IJrPUOE/qMEslAEFZumqZ/EtNcYYwRUqv Vp7sfyqcfCLKxyL4q4CAMmjhARAtwd9SYE8YRiS/njg438bqfgs/RttV3u4f5vXs0PEl L/HnG0sAPvoFIY/ItsoyGyXD4xTQERPsp3Z/yMwrhabuYxWMmm0rgFdSByJkRDbnDP5X H6Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mDwgh9I/9bu36KvVHZ4jH4OzP1kVjib45PQ1UVQtJfQ=; b=M4L3GVNVl+4BfihEE0oI76mv1UZvnC/BPAapoTMuYO/ne4ISgJhiqQkRsJ6/aAUmRM qHBimIFsdHrsJA+GhAk7A0LZ6NjQchpQFGMDTyvgV+Pqvim+WlMApt/6v0Y+QmDhZhx0 rpGmaSSNsUJwsYYR2SGi35s914lp0tHeIfuyXGq5+FKy5R1xdaD3LpZgtwUZ9Zn5jcHJ q+a/ZE/u0bcjRlXenPAvpMPMwWvKEjznv142/YFKx8SwrGxlTikGo6KFL+q8fFUPyiqS aOeOEjpLJPP/Hcr2q+oOr46yGmp/NSI07xKj/BmyeNHMJi0JmP897Hi/v3LcE+7qE+yR r2Dg== X-Gm-Message-State: AN3rC/7hgmkE8pSwWmsHtcXCKTCf+vjBB1cYDZ7Ly12pRBDQZ+uYPiml JGwe63eGfRNMtfTZzigvPNnmHCmTkej+ X-Received: by 10.31.146.12 with SMTP id u12mr4233404vkd.102.1492501899987; Tue, 18 Apr 2017 00:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.110.200 with HTTP; Tue, 18 Apr 2017 00:51:19 -0700 (PDT) In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> From: Lorenzo Colitti Date: Tue, 18 Apr 2017 16:51:19 +0900 Message-ID: Subject: Re: [v6ops] Fwd: [OPSEC] WGLC for draft-ietf-opsec-v6 To: Gunter Van De Velde Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a1142f13093ca92054d6c2d3a Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 07:51:44 -0000 --001a1142f13093ca92054d6c2d3a Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde < guntervandeveldecc@icloud.com> wrote: > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this > document may be of interest to both 6man as v6ops. > > Please send your feedback to OPSEC email list, where discussion around > this document should take place. > I share Erik's concern around the ULA section. The has been controversial for years. For example, see the thread starting at https://www.ietf.org/mail-archive/web/opsec/current/msg02012.html . The vast majority of the text in 2.1.2 has not changed in any substantial way since that heated debate, as shown by the diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-opsec- v6-08.txt&url2=draft-ietf-opsec-v6-11.txt . Do we really have to have that debate again? --001a1142f13093ca92054d6c2d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 18, 2017 at 4:18 PM, Gunter Van De Velde <guntervandev= eldecc@icloud.com> wrote:
Due to the = IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this docum= ent may be of interest to both 6man as v6ops.

Please sen= d your feedback to OPSEC email list, where discussion around this document = should take place.

I shar= e Erik's concern around the ULA section. The has been controversial for= years. For example, see the thread starting at=C2=A0h= ttps://www.ietf.org/mail-archive/web/opsec/current/msg02012.html<= /a> .


Do we really have to have that debate again?
--001a1142f13093ca92054d6c2d3a-- From nobody Tue Apr 18 01:18:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F108C131803; Tue, 18 Apr 2017 01:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 VyLtvEzzxvVU; Tue, 18 Apr 2017 01:18:45 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 73935131802; Tue, 18 Apr 2017 01:18:45 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 08:18:44 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id F1CA5D788B; Tue, 18 Apr 2017 01:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=jF0ILG3gQ31F4GyevJNrtzifVwg=; b= HrmaupHZEhu/lYEQ2z11K9D6AXRCGbmBhMa/d0GLwDkSHhaZ9Xc+TZna/niCTgLo AfFRlnJ/Yuq68GjtmqErLpXfff37Kly4SIDKsz2xV7x31/mWAWoskvnmiRGo+KG+ c3BMA1EPSaRfJxQeQdkmvB6T1ZrMEi21PO8h09VwW84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=ZthPxr+1DNrZMeWKj/TRc1F eW6hX1KqA08HvrgM7njIjIq1d/SWWWyNh9/C8lONS++aeJiS0i5znCFtBtiMpNvX 6FRncfGXL4BsfGwVZ7jJcitXR/Uwv2J2Ms7UI8VaaQdrQ0rExfxh1pNajsE4NxYj Ar1XZ/jpPbhWBO4W/EXs= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 951F4D788A; Tue, 18 Apr 2017 01:18:43 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 948BFAA06E4E; Tue, 18 Apr 2017 10:18:41 +0200 (CEST) From: otroan@employees.org Message-Id: <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 10:18:40 +0200 In-Reply-To: <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Cc: 6man@ietf.org, "v6ops@ietf.org Operations" , Gunter Van De Velde To: opsec@ietf.ortg References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 08:18:47 -0000 --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few initial comments. Draft is not quite ready. Section 2.1.3: 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. The ping pong attack is mitigated in RFC4443. I am not convinced there is justification that this document should = recommend /127 for "security reasons". Section 2.1.4: The description of the IID needs to be updated with the latest = recommendations in 4291bis etc. The IID is no longer recommend to be created by MAC address for = example. It might also be worth clarifying that the operator can only control = a host's choice of IID / privacy by disabling SLAAC altogether. Section 2.1.6: "DNS is often used for malware activities"... That just doesn't read = well. I presume you aren't proposing to disable DNS? ;-) Section 2.2: I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... Section 2.2.2: This section should be updated to reflect the new text in 2460bis. The = reference to hbh-header-handling is no longer needed. Section 2.2.3 s/Fragment Extension Header/Fragment header Same for Hop by Hop options header. Please get the names of the = headers correct. Section 2.3.2: Consider Secure DHCPv6? Section 2.3.3: I don't think those individual drafts are "actively" discussing = methods to rate limit RA anymore. Wirth update / rewrite with summary = from those discussions. Section 2.7.2 Remove the historic tunnel mechanisms? ISATAP, Teredo, 6to4? Section 2.7.2.7: DS-lite is not a translation mechanism. Section 2.7.2.8 s/tunnel and encapsulation/encapsulation and translation/ Section 2.7.3.1: Why in an IPv6 document? Section 3.1: In general update references. e.g. ipv6-eh-filtering is outdated. I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. The advice in ipv6-eh-filtering is essentially to ossify the network. Section 5: Reference to balanced-ipv6-security... I don't think it is worth = referencing an expired draft. Why not summarise the points in a = paragraph? Ole > On 18 Apr 2017, at 09:18, Gunter Van De Velde = wrote: >=20 > Dear 6man, v6ops, >=20 > Due to the IPv6 focus of "draft-ietf-opsec-v6" the OPSEC WGLC for this = document may be of interest to both 6man as v6ops. >=20 > Please send your feedback to OPSEC email list, where discussion around = this document should take place. >=20 > Kind Regards, > G/ >=20 >> Begin forwarded message: >>=20 >> From: Gunter Van De Velde >> Subject: [OPSEC] WGLC for draft-ietf-opsec-v6 >> Date: 12 April 2017 at 09:39:28 GMT+2 >> To: opsec@ietf.org >>=20 >> This is to open a two week WGLC for = https://tools.ietf.org/html/draft-ietf-opsec-v6. >> If you have not read it, please do so now. You may send nits to the = author, but substantive discussion should go to the list. >>=20 >> I will close the call on 26 April 2017 >>=20 >> G/ >> Sent from iCloud >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9cvhAAoJEL7aWKiYQt92qIIQAIpTcBsbFUQmgNojyrHoiwyx MGXLjt2eHD7BkY0y1Gkz4AVEdqOFNcDRyKnT4KvaaW2GEpSs4SqsZjY9xZbHq8CN xKcLA8Mt/PDBuuUMZvA1jWZnOspCa6u4YetE4s4O+wzPOf+KEj0Tc9qJqcQlRTFT tkLsercYcFBPMZGDPWWdn9sGl2VawrqNDDLkcsJ5eWOSmBboogAWUYOQVgPYPaJf IVOYXzDNEleZ0p1AKLtZddiQJvHxwPmblXbhpdbdzF/naNEiTJzg/QJ+KIFMR1fk LVcXt2Ah+fYQTfSObV/sXbBxrnbPqX4aUZG7Yqhqm4yzIP/FXoiLalu6RiBdPyAU Q8Y5gyhWLClNgbAF1I/M9gz5nYNF6W4eyiCSSVxDoCmHopwOrl3Tcy3aVZaohpB4 AHi6knLUjNqhKBc11GX028asTM99GgojK8cPVZFqCSegrNUDAKyK/NOBxuQSLluH 8JAy7Gn5BdW2iOiiCX5lUcxKMC+bzXk6kcUlwYigWS3DD1gxryZPcXws0goC2heK XbRyzujfHLacWMQTCAKN6ECssMxrwZkzF0vSKWNr5FnwAfaVowDHlcn7I9TLcsHU No9+BFBEbmrG7ypwnc4p+WzbjbwteWIB3xnQXM1Eh41/ay5dZvKNnuD0snv4P36o mVKz5tkQbTT6s9Ilsbxd =pcg9 -----END PGP SIGNATURE----- --Apple-Mail=_DE90BA24-E781-4B99-8A9A-4ABA677A6721-- From nobody Tue Apr 18 04:10:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EC312EAAD; Tue, 18 Apr 2017 04:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 HorlItuqbVIo; Tue, 18 Apr 2017 04:10:50 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F04512EAAA; Tue, 18 Apr 2017 04:10:50 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3C29880142; Tue, 18 Apr 2017 13:10:47 +0200 (CEST) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: otroan@employees.org, opsec@ietf.ortg References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Cc: Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Date: Tue, 18 Apr 2017 12:10:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:10:53 -0000 On 04/18/2017 09:18 AM, otroan@employees.org wrote: > A few initial comments. Draft is not quite ready. > > Section 2.1.3: > 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. Agreed on this. > The ping pong attack is mitigated in RFC4443. I must be missing something.. what does RFC4443 have to do with this? A ping pong attack does not require the attack packets to be ICMPv6 echo requests... > I am not convinced there is justification that this document should recommend /127 for "security reasons". Besides ping-pong, there's NCE. While I do agree that the real solution to the above two issues is *not* to use a /127, this document being an operational one, I can see why the authors may want to recommend /127. > Section 2.2: > I am not sure that extension headers are one of the most critical differentiators between IPv4 and IPv6. IPv4 had variable length options... The packet structure does make a big difference. For instance, it's trivial to find (in IPv4-based packets) the upper layer protocol type and protocol header, while in IPv6 it actually isn't. > Section 2.3.2: > Consider Secure DHCPv6? Question: is that doable? (i.e., widely supported) > Section 3.1: > In general update references. e.g. ipv6-eh-filtering is outdated. > I question referencing opsec-ipv6-eh-filtering. It has wrong and outdated advice. E.g. on section of HBH header. > The advice in ipv6-eh-filtering is essentially to ossify the network. Have you read the I-D? Because the I-D boils down to: "pass all EHs unless they are known to be very harmdful". Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 04:39:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE6F12EB0A; Tue, 18 Apr 2017 04:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 vuDwlVznUuhP; Tue, 18 Apr 2017 04:39:28 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8366212EB07; Tue, 18 Apr 2017 04:39:28 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 11:39:27 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 32EFCD788B; Tue, 18 Apr 2017 04:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=MEeFQNqvGE5Vfsua+UUSMzhRvew=; b= ng7oLgsBlAjDFQu63miRdNbFKFCv/xTV+ZqLMk/GafkjG7/a+IwtTMVUjzZa15rk eIXnox4UsweFQfY/BIgq067FXc+B6bSNh8EaA3msPZdW2LZYvH1cKG8VDtX/laAZ YFJYtDdvQH+RYT+duIzT7iz8VBnraiE5ljq5S0jXu1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=YPvLRvv592mqK3bb7PGwSHA m14ezUYAL6gvkny3BYZfqQwwwHuGeXUq5PEFmkNmTDufrAMfS912u83wARsKaHv7 nucjFAPpAO1xBJWxuMmVKQ+U6nqv09blL8UCNViNQiW1SComa1ZZEVvhtYhTzUvb /IJ3cQEzuhgZ7tP1SZ74= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B1B77D788A; Tue, 18 Apr 2017 04:39:26 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 82F40AA3DF0B; Tue, 18 Apr 2017 13:39:24 +0200 (CEST) From: otroan@employees.org Message-Id: <2E8529D6-0CC8-4C59-88D3-12891011E1AD@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 13:39:23 +0200 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Cc: opsec@ietf.ortg, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:39:32 -0000 --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Apr 2017, at 13:10, Fernando Gont wrote: >=20 > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >>=20 >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. >=20 > Agreed on this. >=20 >=20 >> The ping pong attack is mitigated in RFC4443. >=20 > I must be missing something.. what does RFC4443 have to do with this? = A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... https://tools.ietf.org/html/rfc4443#section-3.1 One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. Most implementations I'm aware of now implement this. >> I am not convinced there is justification that this document should = recommend /127 for "security reasons". >=20 > Besides ping-pong, there's NCE. While I do agree that the real = solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. Neighbour cache exhaustion has to be mitigated anyway. On router-router links that's a relatively simple problem compared to = links with hosts. I'm still not convinced that /127 should be recommended over any of the = other addressing models for router to router links. /64, link-local only, /128s. >> Section 2.2: >> I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... >=20 > The packet structure does make a big difference. For instance, it's > trivial to find (in IPv4-based packets) the upper layer protocol type > and protocol header, while in IPv6 it actually isn't. It isn't supposed to be. >> Section 2.3.2: >> Consider Secure DHCPv6? >=20 > Question: is that doable? (i.e., widely supported) You expect this document to have a short lifetime? (Which I guess is the exact problem of publishing this type of advice as = an IETF RFC). >> Section 3.1: >> In general update references. e.g. ipv6-eh-filtering is outdated. >> I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. >> The advice in ipv6-eh-filtering is essentially to ossify the = network. >=20 > Have you read the I-D? Because the I-D boils down to: "pass all EHs > unless they are known to be very harmdful". Hmm, I see the latest opsec version has put this right, thanks. I must have read the earlier individual draft, cause that said "should = drop HBH". Best regards, Ole --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9frsAAoJEL7aWKiYQt92PFUQAJwkVo7+HJoh9mo6WXb2SEns 7jHBTB9L057Wb6UKtKrZqxo6S/SkFZcHWX18uU0hOFr10vCn2g4ipXHcNFDT/gI+ hlpB+tNvzEsYL7y88mBzKmv4ZDUt5IMJqd7nVfySI+oaBQwbZyq8ee4+T2r1xOgl TRgJbGm760cJVsRYsz6dQZgcnBCNRy+ZfY0d+92j5XfzTFx8/Y2/XV4IFopUteco XrpnQUgqPFNvgLzy42T8XrFmnZq19ykLDPqXK+X5eRi+ryUSpsLDgW0hx/YNhF8D ExW1zeGx10FtTAelVir8Nrvk9HupLUPe6z14PVZt70GCDvyOIBcFrVX+M/sau+yS 0eeicuSYIyfIwclgejKIsMk73T9HkwYKyeFh55Mn203ep3PpPdZq8mcjqnaxVHK9 qyIFFCWtoMgztJZvpr6mOWp8TR3x4Cq2Y/3T6M1P0Sqjk/E9bv1PFqVfBhcey2Z/ VdXXQ7CjM2v0EEfBTt5JzQzGtGlpqzvYqdS+WNnuOUZ2Pm5BA1gP2vjGxbrQYyGL lhzLJB2igqWdpfkrAt1kVNPCjVpGGEMWZ3avr8k/8aLfe1hbOiZ3+URfarzpUjeS qoomW5WqGMJlbMceMlNtVf8YhD9qALp44j7KKNeCKhmz3d21d/9Tqeui/rE/kGch aC4O0bPFNQ2Mib1Vj05k =qlCS -----END PGP SIGNATURE----- --Apple-Mail=_38C16313-E875-4047-B1B6-C54E70D9D88E-- From nobody Tue Apr 18 04:44:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806F212EAF6; Tue, 18 Apr 2017 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 kip--Hzj8hW3; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A8129481; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 11:44:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 1DBD9D788B; Tue, 18 Apr 2017 04:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=yhQgaSTwtKWUDSSleodGkfbxePY=; b= q13bhEs4npatv82KBDKrd+CmsB4qAm2xEDT/miLKv5zZPq+efZFWoSQE3LPUSZtm Kma76DIh95shECkDY+lDG5eKKCJWeqWnKTk2dwBVTOAjtAKAS/spy1pWVNaJbdAH TQJaT+Jvh/WM8MhbIBLxk8Yck5oUeQWkQdRCEoz3utg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=r6rflq/j3c7N1irgYXSwB8Q ZiMCn5IulXjW8OpwoIR2L6PkCXY8NjcbX5cs5mVoW/tFUr1gEyrpAo+PxAiQ1iC4 nu3NPqbLxiZLGPL0VC+W4s7hAgbEbvX7IFgPE5cxKK/yizpJNNvxwW3lTDB+shqW GvwmQTBcRs4HrKgm0JSQ= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 63663D788A; Tue, 18 Apr 2017 04:44:46 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DD2F8AA3FB43; Tue, 18 Apr 2017 13:44:44 +0200 (CEST) From: otroan@employees.org Message-Id: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 13:44:44 +0200 In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:44:49 -0000 --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC Content-Type: multipart/alternative; boundary="Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C" --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > On 18 Apr 2017, at 13:10, Fernando Gont wrote: >=20 > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >>=20 >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. >=20 > Agreed on this. >=20 >=20 >> The ping pong attack is mitigated in RFC4443. >=20 > I must be missing something.. what does RFC4443 have to do with this? = A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... https://tools.ietf.org/html/rfc4443#section-3.1 = One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link. Most implementations I'm aware of now implement this. >> I am not convinced there is justification that this document should = recommend /127 for "security reasons". >=20 > Besides ping-pong, there's NCE. While I do agree that the real = solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. Neighbour cache exhaustion has to be mitigated anyway. On router-router links that's a relatively simple problem compared to = links with hosts. I'm still not convinced that /127 should be recommended over any of the = other addressing models for router to router links. /64, link-local only, /128s. >> Section 2.2: >> I am not sure that extension headers are one of the most critical = differentiators between IPv4 and IPv6. IPv4 had variable length = options... >=20 > The packet structure does make a big difference. For instance, it's > trivial to find (in IPv4-based packets) the upper layer protocol type > and protocol header, while in IPv6 it actually isn't. It isn't supposed to be. >> Section 2.3.2: >> Consider Secure DHCPv6? >=20 > Question: is that doable? (i.e., widely supported) You expect this document to have a short lifetime? (Which I guess is the exact problem of publishing this type of advice as = an IETF RFC). >> Section 3.1: >> In general update references. e.g. ipv6-eh-filtering is outdated. >> I question referencing opsec-ipv6-eh-filtering. It has wrong and = outdated advice. E.g. on section of HBH header. >> The advice in ipv6-eh-filtering is essentially to ossify the network. >=20 > Have you read the I-D? Because the I-D boils down to: "pass all EHs > unless they are known to be very harmdful". Hmm, I see the latest opsec version has put this right, thanks. I must have read the earlier individual draft, cause that said "should = drop HBH". Best regards, Ole --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 18 Apr 2017, at 13:10, Fernando = Gont <fgont@si6networks.com> wrote:

On 04/18/2017 09:18 AM, otroan@employees.org wrote:
A few initial comments. Draft is not quite = ready.

Section 2.1.3:
6164 = does not _recommend_ /127 it _permits_ /127 on p2p links.

Agreed on this.


The ping = pong attack is mitigated in RFC4443.

I must be missing something.. what does RFC4443 have to do = with this? A
ping pong attack does not require the attack = packets to be ICMPv6 echo
requests...

https://tools.ietf.org/html/rfc4443#section-3.1
  One specific = case in which a Destination Unreachable message is sent
  with a code 3 is = in response to a packet received by a router from a
  point-to-point = link, destined to an address within a subnet assigned
  to that same = link (other than one of the receiving router's own
  addresses). =  In such a case, the packet MUST NOT be forwarded back
  onto the arrival = link.

Most implementations I'm aware of now implement = this.

I am not convinced there is justification that this document = should recommend /127 for "security reasons".

Besides ping-pong, there's NCE. = While I do agree that the real solution
to the above two = issues is *not* to use a /127, this document being an
operational one, I can see why the authors may want to = recommend /127.

Neighbour cache exhaustion has to be mitigated = anyway.
On router-router links = that's a relatively simple problem compared to links with = hosts.
I'm still not convinced that = /127 should be recommended over any of the other addressing models for = router to router links.
/64, link-local only, /128s.

Section 2.2:
I am not sure that extension headers are one of the most = critical differentiators between IPv4 and IPv6. IPv4 had variable length = options...

The packet = structure does make a big difference. For instance, it's
trivial to find (in IPv4-based packets) the upper layer = protocol type
and protocol header, while in IPv6 it = actually isn't.

It isn't supposed to be.

Section 2.3.2:
Consider Secure DHCPv6?

Question: is that doable? (i.e., widely supported)

You expect this document to = have a short lifetime?
(Which I guess is the exact problem of publishing this = type of advice as an IETF RFC).

Section 3.1:
In general update references. e.g. ipv6-eh-filtering is = outdated.
I question referencing opsec-ipv6-eh-filtering. = It has wrong and outdated advice. E.g. on section of HBH header.
The advice in ipv6-eh-filtering is essentially to ossify the = network.

Have you read the = I-D? Because the I-D boils down to: "pass all EHs
unless = they are known to be very harmdful".

Hmm, I see the latest opsec = version has put this right, thanks.
I must have read the earlier individual draft, cause = that said "should drop HBH".

Best regards,
Ole= --Apple-Mail=_F43B491F-8D9F-458A-88A9-93C1771CFF4C-- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9fwsAAoJEL7aWKiYQt925cQP/0VXnKmWVBwsBsv4TG6QeGWA Ro+pucXspLl6nwv5QZKYtuGOSe13QzrQFo/lBN7bh5MV6YCfTxdxTvSUFBfb3Cms 2xtye4MyZppKNXLwjnPd57kapsPLpm2YGPG545F6Ccmy88YcnySlMxlSSSwbmYt8 52fpfV+wPEjR9kCO65MzUAyv0yXBv6aG5O3n64PMuTVSzik8ZijwH8Vh2ZfixAEz 0W1bgqxTCtf3GU2Sxx+5cenhhxt9dTbyKgA8hiwbQjikW2zzKdFYHAwuBJbWT+sQ Omudl8eQm6zGJxx3OlxP2hCTDI1v8GFUBX0zyTNPPO/jUWqpmzTxSXcFd8lP10j+ lY5v0RmsdytE8FsPiDpMOorT2qsuz2nS3zyKGErwSBjodcmf27h2c9ZqGKxosqFM GG51DbR4cvuyV6WxoDtOALvpMEZutwiR0JdBSG22hCoJX8KDz0p9TddzEux8pc5l APwpEHa9uh1sZ9sgCdncYQrgQBJOpfoALJIGC2OcEQeMEH6UM8npLueppvB1J/ul F612k+xluMFHj6XrYMLhRfTEoo2Qi6w/R7nnIn7XNQf5qas89TzrCQivq0Tj0Ur5 MdzUo/IEqpvKNSIczJUmgp779bX6/xpljy1Td7GbBtwjusWcs3KxazmWJPFc4itH HTmkfsaUzZk/P0ed9b0F =1jo3 -----END PGP SIGNATURE----- --Apple-Mail=_7D6D9090-7387-493C-9B2C-DAE1936B11BC-- From nobody Tue Apr 18 05:03:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5C01204DA; Tue, 18 Apr 2017 05:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zza2UiP5fj93; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 8B33A12EB3A; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id q78so43456704vke.3; Tue, 18 Apr 2017 05:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NPKEny7QXgzG7tZ3DhNn+ztgj4AxLdybqMGCs0mSszg=; b=I7qLpUPT0fi0ebuEHkcmjzxNCguJj8uUNnICaulIjFysiyhPaGrWbtH2w3tm/299Rw Tyfasu8z44xsB+vjBFsCiJKIZbL6gw54G2ES83DW4zmmgp0kWbSF+kxTLIle9AmA0tJi NIk8K2cc78UNH8se9cUERBsV/ZXCZbgeVIokYvfpxEUyP8qdcSPt8ObXWOqLNTOEude8 Y0cXXv302hIvHVrj3eebeEI1M9c2n3EoT6F6GsVHuWVPDMNjoCttoXBo2ipm3DkMVp7H nFRFZRQA+GEs4x/Qaz6jVAZUJv+r9KXKshS3bIEJpRZJ7YFQ1Va14U51fdg/GmxsxqVq PgCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NPKEny7QXgzG7tZ3DhNn+ztgj4AxLdybqMGCs0mSszg=; b=sx2dJEjKiEpPmZ2fzV6b3OEliNTgaQgi2u0EiXOXxoR4ugTpdzbHb5I/CAnlDqM1Rb g0nUF2P4t6bBfRun3RsJY5w6Dq7SYSjRq4uDIPSBH7OLjYo/9OdSwF2YXcOSOkhJI9+v pqJQWotbGOSLWjcMxXN6C9zSMGyeniZAibJdIHpTC8fqViMxJ+PJjYFK9acEjzwXDezg +9qZV9FrNHsDz27C42pv416h5ZHWa7intonRc0EA0V/ON3arwovwN67ZDh2zXOle4p6U 0KJTDuObjiCz4PB9wb96U9Zt5RswpQal1zKGTqN9THmbHKCD+fC1WH3rVGTQysI1PBAh 1xRw== X-Gm-Message-State: AN3rC/5cxpC3ar+H4nnqg2kEE/o/fl4Ax7zhMcrEKtMpJtT14dpboxBV 67stk9KLHCCeK7GC/AiwaIh6wXXrhg== X-Received: by 10.31.60.65 with SMTP id j62mr8230097vka.25.1492517011513; Tue, 18 Apr 2017 05:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.177 with HTTP; Tue, 18 Apr 2017 05:03:01 -0700 (PDT) In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> From: Mark Smith Date: Tue, 18 Apr 2017 22:03:01 +1000 Message-ID: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: Fernando Gont Cc: Ole Troan , opsec@ietf.ortg, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:03:39 -0000 On 18 April 2017 at 21:10, Fernando Gont wrote: > On 04/18/2017 09:18 AM, otroan@employees.org wrote: >> A few initial comments. Draft is not quite ready. >> >> Section 2.1.3: >> 6164 does not _recommend_ /127 it _permits_ /127 on p2p links. > > Agreed on this. > > >> The ping pong attack is mitigated in RFC4443. > > I must be missing something.. what does RFC4443 have to do with this? A > ping pong attack does not require the attack packets to be ICMPv6 echo > requests... > "One specific case in which a Destination Unreachable message is sent with a code 3 is in response to a packet received by a router from a point-to-point link, destined to an address within a subnet assigned to that same link (other than one of the receiving router's own addresses). In such a case, the packet MUST NOT be forwarded back onto the arrival link." > >> I am not convinced there is justification that this document should recommend /127 for "security reasons". > > Besides ping-pong, there's NCE. While I do agree that the real solution > to the above two issues is *not* to use a /127, this document being an > operational one, I can see why the authors may want to recommend /127. > > However, there aren't many places to hide IIDs in a /127. It's likely the operator (being humans) will assign /127s sequentially. If an attacker finds one, they'll easily find the IIDs in it, and find the IIDs in all of the adjacent ones. A TCP SYN attack on the BGP process becomes easy. GTSM mitigates this, however if the router interface IID can't be easily discovered (c.f., RFC7217), then the attacker can't send malicious packets to the device in the first place. The advice should be something like choose a /64 or shorter in the addressing plan for for /127 assignment, and then to randomly assign (using a computer or dice!) /127s from within it. Alternatively, have /64s on the inter-router links, RFC7217 IIDs on their interfaces, and then have edge ACLs only permit packets to these addresses and drop packets to all other ones within the /64. It also should be pointed out that address scopes limit the severity of the threat. It's unlikely that /127s are needed from the ULA address space, as the threat of ND cache attacks is likely to be a lot lower because hosts and their end-users that can successfully send packets to ULA addresses are going to be more trusted to not launch an ND cache attack - they have a vested interest in the network staying available. Regards, Mark. From nobody Tue Apr 18 06:11:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDAB12EBBB; Tue, 18 Apr 2017 06:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 giy4j33YWZqD; Tue, 18 Apr 2017 06:11:33 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0951274D0; Tue, 18 Apr 2017 06:11:32 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D9ADB80D2A; Tue, 18 Apr 2017 15:11:30 +0200 (CEST) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Date: Tue, 18 Apr 2017 13:12:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:11:35 -0000 Hi, Ole, On 04/18/2017 12:44 PM, otroan@employees.org wrote: >>> The ping pong attack is mitigated in RFC4443. >> >> I must be missing something.. what does RFC4443 have to do with this? A >> ping pong attack does not require the attack packets to be ICMPv6 echo >> requests... > > https://tools.ietf.org/html/rfc4443#section-3.1 > One specific case in which a Destination Unreachable message is sent > with a code 3 is in response to a packet received by a router from a > point-to-point link, destined to an address within a subnet assigned > to that same link (other than one of the receiving router's own > addresses). In such a case, the packet MUST NOT be forwarded back > onto the arrival link. > > Most implementations I'm aware of now implement this. Why wouldn't an attacker send *any* packet meant for the p2p link, but that not correspond to the address of any of the two endpoints? i.e., I don't see the need to focus on a specific kind of packet... I guess I'm missing something? >>> I am not convinced there is justification that this document should >>> recommend /127 for "security reasons". >> >> Besides ping-pong, there's NCE. While I do agree that the real solution >> to the above two issues is *not* to use a /127, this document being an >> operational one, I can see why the authors may want to recommend /127. > > Neighbour cache exhaustion has to be mitigated anyway. > On router-router links that's a relatively simple problem compared to > links with hosts. > I'm still not convinced that /127 should be recommended over any of the > other addressing models for router to router links. > /64, link-local only, /128s. How do you mitigate it when the implementation does not limit the number of NC entries? (i.e., operationally) >>> Section 2.2: >>> I am not sure that extension headers are one of the most critical >>> differentiators between IPv4 and IPv6. IPv4 had variable length >>> options... >> >> The packet structure does make a big difference. For instance, it's >> trivial to find (in IPv4-based packets) the upper layer protocol type >> and protocol header, while in IPv6 it actually isn't. > > It isn't supposed to be. Which for people running networks translates to "broken by design". >>> Section 2.3.2: >>> Consider Secure DHCPv6? >> >> Question: is that doable? (i.e., widely supported) > > You expect this document to have a short lifetime? > (Which I guess is the exact problem of publishing this type of advice as > an IETF RFC). I didn't even think about the lifetime. But I wouldn't suggest a mitigation that isn't doable at the time of publication. If Secure DHCPv6 is not widely implemented, this would be like saying "secure ND with SEND" ("yeah... in your dreams!"). FWIW, I do support this document. I think it contains valuable and much needed information. >>> Section 3.1: >>> In general update references. e.g. ipv6-eh-filtering is outdated. >>> I question referencing opsec-ipv6-eh-filtering. It has wrong and >>> outdated advice. E.g. on section of HBH header. >>> The advice in ipv6-eh-filtering is essentially to ossify the network. >> >> Have you read the I-D? Because the I-D boils down to: "pass all EHs >> unless they are known to be very harmdful". > > Hmm, I see the latest opsec version has put this right, thanks. > I must have read the earlier individual draft, cause that said "should > drop HBH". We've certainly been improving th document as part of the process. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 06:15:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D4512EBD5; Tue, 18 Apr 2017 06:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 6RIgZyp2WSJS; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A553412EB9C; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:15:38 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2D5EFD788D; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=VRRaZZt47pYL+C8HqUQlxUV+4A8=; b= qRofvgPqgmbdeHJuLshgb/LHYBH/DXLNyrnfWVC60DDcV27OzBZGGVqtBpxMuv+M GpXYLa9Cz/Cf78DRI+oG/DqvTaAkru9qtqIpb2/hvBPbN85mpPNhi5AThQQCvzbc KPt8yDDV317sZeQmhTObSZ7s2bYcP1VWe3mcIXxhdMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=GmL5CuWPXegXUNSl0kbxp7N 3xYNN5yOBZGJk7hS1gxapPYRbzisYF6K1k0ORqagxlroaIb6RSnAMiCOkIL0qxVJ qoaMWeRuYkux1rM3/b13aUO2yUgNPtJnD44d5KHJUgZQ8mLA6ugOpRLk3NxUWibE NL9f3xxlK2eQKFU4evI0= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 0187DD788B; Tue, 18 Apr 2017 06:15:38 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7383CAA599EB; Tue, 18 Apr 2017 15:15:36 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 15:15:35 +0200 In-Reply-To: <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: opsec@ietf.org, Gunter Van De Velde , "v6ops@ietf.org Operations" , 6man@ietf.org To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:15:40 -0000 --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fernando, >>>> The ping pong attack is mitigated in RFC4443. >>>=20 >>> I must be missing something.. what does RFC4443 have to do with = this? A >>> ping pong attack does not require the attack packets to be ICMPv6 = echo >>> requests... >>=20 >> https://tools.ietf.org/html/rfc4443#section-3.1 >> One specific case in which a Destination Unreachable message is sent >> with a code 3 is in response to a packet received by a router from a >> point-to-point link, destined to an address within a subnet assigned >> to that same link (other than one of the receiving router's own >> addresses). In such a case, the packet MUST NOT be forwarded back >> onto the arrival link. >>=20 >> Most implementations I'm aware of now implement this. >=20 > Why wouldn't an attacker send *any* packet meant for the p2p link, but > that not correspond to the address of any of the two endpoints? >=20 > i.e., I don't see the need to focus on a specific kind of packet... I > guess I'm missing something? Yes, you are missing something. RFC4443 specifies what behaviour should be if a router receives a packet = on a point to point link that would end up being forwarded back out the = same link. The specified behaviour is drop and send destination = unreachable. That solves the problem for any packet obviously. And any prefix length = assigned to the link. Cheers, Ole --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hF3AAoJEL7aWKiYQt92qK0P/jzKw4Kw6gaw/J06uvjnuGLP yCa0NQOhIW92Txx4YXNkbP/6YpAdiPNkxfFoDva6FUmSkKPZ05EgQhKH/bdfo/2g BoQgs8WjDidVnk2YApf69UJ2gUD2VNVYai7eOIrVwdmdF9EXLadGKHXR5JTum9VT gSR8iuyhbtF2QqT2ZU14Yq1a05to61FmdPN0gX9knqCvsyag9phEQV8H2CUta/kn XrnqKHQM9KohvX3YhdmpsB95slFRePfDZfNobm2bPxGoWwAuqpP5Cr5GCQGBceYA OPRjFqkxb9fNYeDYKbRLJUWlcPfe3RMe63XVYryr2vMmFVrsgJCp/0k4mqPiHlwv dO2YLUwzelaiUDWWzDwKC11PK2fphIXmWuPe8KYqtcGMRrXwdQoDnDKw4TZydfqG cBKtxY9t2lQKOoPiGn888fPW24jPNiVk/ks9pf1alvfO99GnNWBjjWgYEljpy9dZ nPdwH1ZYOFaiJ86gK9f82QSz7/BWS/uWUIk66tRicQ9Z3YE5BcqtceyjxhPAegCu p+LaKbqAQWnKJGyXpSfCy7bJDSCCkFupu2std99JTPhqoquzvdG4VGiaBsr1LAVE zuSK3MJxeGuzoxqDGg3TT6Exj3Q+NWSOIAqO3Z3cxvUGc/0RygYcTJ/0Ljzdi8LL 9ZKMWpNJNryByg2WGPSC =w9er -----END PGP SIGNATURE----- --Apple-Mail=_68508FCA-D028-472E-9889-BEFFA75A61E4-- From nobody Tue Apr 18 06:27:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2912EBFD; Tue, 18 Apr 2017 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 j6afuF0QdKh0; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2245D12EBFB; Tue, 18 Apr 2017 06:27:34 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 48AC68013E; Tue, 18 Apr 2017 15:27:32 +0200 (CEST) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Date: Tue, 18 Apr 2017 14:27:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:27:40 -0000 On 04/18/2017 02:15 PM, otroan@employees.org wrote: > Fernando, > >>>>> The ping pong attack is mitigated in RFC4443. >>>> >>>> I must be missing something.. what does RFC4443 have to do with >>>> this? A ping pong attack does not require the attack packets to >>>> be ICMPv6 echo requests... >>> >>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>> in which a Destination Unreachable message is sent with a code 3 >>> is in response to a packet received by a router from a >>> point-to-point link, destined to an address within a subnet >>> assigned to that same link (other than one of the receiving >>> router's own addresses). In such a case, the packet MUST NOT be >>> forwarded back onto the arrival link. >>> >>> Most implementations I'm aware of now implement this. >> >> Why wouldn't an attacker send *any* packet meant for the p2p link, >> but that not correspond to the address of any of the two >> endpoints? >> >> i.e., I don't see the need to focus on a specific kind of packet... >> I guess I'm missing something? > > Yes, you are missing something. RFC4443 specifies what behaviour > should be if a router receives a packet on a point to point link that > would end up being forwarded back out the same link. The specified > behaviour is drop and send destination unreachable. That solves the > problem for any packet obviously. And any prefix length assigned to > the link. How could RFC4443 possibly address this for all packets without formally updating RFC2460? P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, as noted, no matter where this "patch" is specified, such doc should certainly update RFC2460. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 06:31:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD665129453; Tue, 18 Apr 2017 06:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 I6l-0-hm_RvI; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 448B4127866; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 18 Apr 2017 13:31:19 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 05262D788D; Tue, 18 Apr 2017 06:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=Y2KtCjM84UDsyN4JUvzhwk2HKyM=; b= THcf0psYM5eTzk/HoyHztlsP47niUb+KbWjaEmH7PvTm/HGvFpOKrTcMVdeBjFb+ d26UxTOjmcanUjZ3poqPXKAYHmcIPBuNvfF6ubS2H1HCXqCxgF3zWr+ipZP9EMBb Og3YMMcrva7L3oHdg1IS7i3LVD3Ui7CSulFlCNzpMss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=UFfxg+UuDTAwQCiFkQvrXkd hK2JJFvJrNHzw2wNtx7gKEz3bk1BPIkPEdQi63zNAMKR1RzVNBEdxPHMsjKfQ7JS 5t3k90VBZ8njWHQsZqTYQGIGJdN7R6o2zKN1dd7ktOjvdQKLKWL3zK42YBRr4vl0 lyE3wDazOiOPCS+tXSZ8= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8BE8ED788E; Tue, 18 Apr 2017 06:31:18 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0CF52AA5DDE1; Tue, 18 Apr 2017 15:31:17 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 Date: Tue, 18 Apr 2017 15:31:16 +0200 In-Reply-To: <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" To: Fernando Gont References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:31:21 -0000 --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>>>> The ping pong attack is mitigated in RFC4443. >>>>>=20 >>>>> I must be missing something.. what does RFC4443 have to do with >>>>> this? A ping pong attack does not require the attack packets to >>>>> be ICMPv6 echo requests... >>>>=20 >>>> https://tools.ietf.org/html/rfc4443#section-3.1 One specific case >>>> in which a Destination Unreachable message is sent with a code 3 >>>> is in response to a packet received by a router from a >>>> point-to-point link, destined to an address within a subnet >>>> assigned to that same link (other than one of the receiving >>>> router's own addresses). In such a case, the packet MUST NOT be >>>> forwarded back onto the arrival link. >>>>=20 >>>> Most implementations I'm aware of now implement this. >>>=20 >>> Why wouldn't an attacker send *any* packet meant for the p2p link, >>> but that not correspond to the address of any of the two >>> endpoints? >>>=20 >>> i.e., I don't see the need to focus on a specific kind of packet... >>> I guess I'm missing something? >>=20 >> Yes, you are missing something. RFC4443 specifies what behaviour >> should be if a router receives a packet on a point to point link that >> would end up being forwarded back out the same link. The specified >> behaviour is drop and send destination unreachable. That solves the >> problem for any packet obviously. And any prefix length assigned to >> the link. >=20 > How could RFC4443 possibly address this for all packets without = formally > updating RFC2460? >=20 > P.S.: For a specification pov, this shouldn't be buried in RFC4443, = and, > as noted, no matter where this "patch" is specified, such doc should > certainly update RFC2460. You will probably save everyone a lot of energy if you just admit you = had missed it, and moved on. Ole --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY9hUkAAoJEL7aWKiYQt92OZgP/i/uokmPW9y4T3dsmjjJkrpE sNjL2XvmUUnEFf9cULpgJMem0Xw6JmsLrehafvsfffAhLHZIYvL+qA8TIRdSFSJ3 TnSGyPIeIaTBNKAggQzCuqnfRsEuRZFxpB1zq878Q6RFwiwpOljxeOX4SdE8vI7r fbjxk94YigsO1fA7qMW69nsbZkZF7aAdnY7oP3+BF0aUZQEamxTshCb1DgpbfI62 KKSDqMHxmlBEvzCYBLohw8RdAkMjRUqnHaoPrpVV/fswwOLfGunGIP3O/LVZJWfX OJH6LNnBptqcwHpz6acxOnstgTR2+xqfpa+etviiQsZCjoW1jl8OlBmQvtqEwmb0 N2kT4N1ebyv4kLzVV239kbPJAHPRoTBs67eZ2AiXaDiFGsaDO4edpXJFc4+0b+Li PW9LZRQToYg5j6MVXhcakG8Ajt56rnWtE+AuWbgFzMru1wmc900jA7kXPMyYrq6l NRBJICP0FEkP1/emHuCUbZBEuPWMnu5rbqONWQswpweHnhS2HfFWtpqZaTOZzHdI Ff3oWteQjBXhlq1dY/Mqw6BQ4LTV6oxSQCFJrv5T8VyLNgWIc7MeSwlRiz5K26vw zmK1pT7Zk8CFfiKopmbrKk9naBAy14nN1XNZ5PavGegU0xEPW/dF/TVttUbG8oTu UKlfZ+XOoi8kGKTcxG1l =MlFa -----END PGP SIGNATURE----- --Apple-Mail=_6D08AD0D-4666-4CCC-AD63-6E0D388D21C2-- From nobody Tue Apr 18 07:39:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EE5131883; Tue, 18 Apr 2017 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 xS2ToyMvilZO; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA881317D0; Tue, 18 Apr 2017 07:39:21 -0700 (PDT) Received: from [100.78.23.17] (unknown [94.117.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3EF9C80890; Tue, 18 Apr 2017 16:39:19 +0200 (CEST) Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: otroan@employees.org References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> Cc: Gunter Van De Velde , opsec@ietf.org, 6man@ietf.org, "v6ops@ietf.org Operations" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 18 Apr 2017 15:15:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:39:24 -0000 On 04/18/2017 02:31 PM, otroan@employees.org wrote: >>> >>> Yes, you are missing something. RFC4443 specifies what behaviour >>> should be if a router receives a packet on a point to point link that >>> would end up being forwarded back out the same link. The specified >>> behaviour is drop and send destination unreachable. That solves the >>> problem for any packet obviously. And any prefix length assigned to >>> the link. >> >> How could RFC4443 possibly address this for all packets without formally >> updating RFC2460? >> >> P.S.: For a specification pov, this shouldn't be buried in RFC4443, and, >> as noted, no matter where this "patch" is specified, such doc should >> certainly update RFC2460. > > You will probably save everyone a lot of energy if you just admit you had missed it, and moved on. Huh? I obviously missed it. But this should still be in RFC2460 (or rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding for IPv6 packets. Having important requirements spread into a number of documents where they don't belong doesn't help, and in the long run takes more energy (and creates more problems) than spending the energy in doing what is right. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Apr 18 08:03:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7393128D40 for ; Tue, 18 Apr 2017 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 2L5kR6bVNva6 for ; Tue, 18 Apr 2017 08:02:51 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 D043312EC4C for ; Tue, 18 Apr 2017 08:02:45 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u2so57532647wmu.0 for ; Tue, 18 Apr 2017 08:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=d4Vg/CFuQ87d6w0QVStJRJE/3k06N35IQak/UYasP5U=; b=WxSDZWawkWv3mZTpzWPPwXQXvWhHP2waOwA3TQnyqwgxe8KrU+EohBp2a+yV1uOAxv zsg1UwE39r7J6Eeofi23WiwMe1qgY0cI8RzFHKsz+6sRChT8L4X/hDfyt+R+bXAIiHuG nJZUs0eibpQ90ow44iIDMkCO7o9bPfC1UZM4fC+ZmJ0yeNuGlSGBNskQFVbU/nk0x2ob QPBn6nOUk5We0R+/Y92UHyBXBfnL9akv/9lUt+6GqSaUmPsGplfe7dsxcVJzWi9KkQ0f n6Zv0OHmY0pOxiZ0Fi4lxjEgotfZ32p8KwlATY0S+SjQJzCwdElwkZoRojewu5AwOz8n p7MA== 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:date:references:cc:to :message-id; bh=d4Vg/CFuQ87d6w0QVStJRJE/3k06N35IQak/UYasP5U=; b=DZ4Abm+++0FLjwfXQ0vleLQiEGHJ1zQLfyVhexILA66u59Qeb234RHl2ZtsB+Su1Ob esNczmYixRwBT5ynta//3pJgUCJxalDsk6FsWHzPD7xhJ27BJNy3QSEGf6q7SpZynep9 w2QkludEoZcVDI8Ud8PiDDy0o9JEyORzEeC2gqioeW+T9ieOz5F/kRE9DykOudtTOwcV e913xs6ic4N4qJ+84uxePMeKYxyxU6teOhZM7lEYzeRDj0rnT3Xknv4pL31BYFhbJwdZ 25RTz8fljmvVWMAmS4AXnwIihX9zwPIKboNRs4RY6K3J2keE+WNaTEXb2agRFst+N0b1 LCXQ== X-Gm-Message-State: AN3rC/7qOMM6NHPSNSDv2j9R/boO2yNdunhRtaLZP1EWyTKCW4AGOLDN tADKf4NszQWJi6N0oDw= X-Received: by 10.28.208.74 with SMTP id h71mr9822043wmg.36.1492527764018; Tue, 18 Apr 2017 08:02:44 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:fdde:c4bf:2da2:6744? ([2601:647:4d01:db10:fdde:c4bf:2da2:6744]) by smtp.gmail.com with ESMTPSA id o77sm19190571wrc.38.2017.04.18.08.02.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 08:02:42 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_B068960E-5B0C-4673-96B4-2AC06E31BCF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: Last Call: (Benchmarking Methodology for IPv6 Transition Technologies) to Informational RFC Date: Tue, 18 Apr 2017 08:02:38 -0700 References: <149252470353.16122.4815057235609635083.idtracker@ietfa.amsl.com> Cc: Bob Hinden To: IPv6 List Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:02:54 -0000 --Apple-Mail=_B068960E-5B0C-4673-96B4-2AC06E31BCF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8479E54-F9D2-4B39-96D9-F0C307999D6A" --Apple-Mail=_F8479E54-F9D2-4B39-96D9-F0C307999D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, please send comments to the appropriate list. Bob > Begin forwarded message: >=20 > From: The IESG > Subject: Last Call: = (Benchmarking = Methodology for IPv6 Transition Technologies) to Informational RFC > Date: April 18, 2017 at 7:11:43 AM PDT > To: "IETF-Announce" > Cc: bmwg-chairs@ietf.org, Al Morton , bmwg@ietf.org, = draft-ietf-bmwg-ipv6-tran-tech-benchmarking@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the Benchmarking Methodology WG > (bmwg) to consider the following document: > - 'Benchmarking Methodology for IPv6 Transition Technologies' > as Informational > RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-05-02. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > There are benchmarking methodologies addressing the performance of > network interconnect devices that are IPv4- or IPv6-capable, but the > IPv6 transition technologies are outside of their scope. This > document provides complementary guidelines for evaluating the > performance of IPv6 transition technologies. More specifically, > this document targets IPv6 transition technologies that employ > encapsulation or translation mechanisms, as dual-stack nodes can be > very well tested using the recommendations of RFC2544 and RFC5180. > The methodology also includes a metric for benchmarking load > scalability. >=20 >=20 >=20 >=20 > The file can be obtained via > = https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-tran-tech-benchmarki= ng/ >=20 > IESG discussion can be tracked via > = https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-tran-tech-benchmarki= ng/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 --Apple-Mail=_F8479E54-F9D2-4B39-96D9-F0C307999D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI, please send comments to the appropriate list.

Bob

Begin = forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Subject: = Last Call: = <draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06.txt> (Benchmarking = Methodology for IPv6 Transition Technologies) to Informational = RFC
Date: = April 18, 2017 at 7:11:43 AM = PDT
To: = "IETF-Announce" <ietf-announce@ietf.org>
Cc: bmwg-chairs@ietf.org, Al Morton <acmorton@att.com>, bmwg@ietf.org, draft-ietf-bmwg-ipv6-tran-tech-benchmarking@ietf.org
Reply-To: = ietf@ietf.org


The IESG has = received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- = 'Benchmarking Methodology for IPv6 Transition Technologies'
=  <draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06.txt> as = Informational
RFC

The IESG = plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive = comments to the
ietf@ietf.org mailing lists by 2017-05-02. Exceptionally, = comments may be
sent to iesg@ietf.org instead. In either case, please retain = the
beginning of the Subject line to allow automated = sorting.

Abstract


  There are benchmarking = methodologies addressing the performance of
=   network interconnect devices that are IPv4- or IPv6-capable, = but the
  IPv6 transition technologies are = outside of their scope. This
  document = provides complementary guidelines for evaluating the
=   performance of IPv6 transition technologies.  More = specifically,
  this document targets IPv6 = transition technologies that employ
=   encapsulation or translation mechanisms, as dual-stack nodes = can be
  very well tested using the = recommendations of RFC2544 and RFC5180.
  The = methodology also includes a metric for benchmarking load
=   scalability.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-tran-tech= -benchmarking/

IESG discussion can be = tracked via
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ipv6-tran-tech= -benchmarking/ballot/


No IPR = declarations have been submitted directly on this I-D.





= --Apple-Mail=_F8479E54-F9D2-4B39-96D9-F0C307999D6A-- --Apple-Mail=_B068960E-5B0C-4673-96B4-2AC06E31BCF8 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY9iqPAAoJEK7rdBF357uossIH/iV2FxwoIuHjXoP6MdflRYxR TPl7MCfUz/W/yPBS8p0V/TCZ0ur/E2PwQHbWXFvXSqjWJHFn+4C10l5aBZvMO/NR UVUneQVYRXS4/EO5tZlQhPnx4ODA5H99A7HgyiqvZU6DVsTVxuxfVEY5y7pgQRRy 7wRi9OU2R8ynJCaPAoTHALdfZ021QgIbJzSbEVsmjVTfpmJB2syz3R8W6hVelTDt Q/8VFJT6xz4d2z3R+J9WcVC7pRXAINhtLzsFsrLczyhycKmG3YDrqf7mhp/pfnLi oC3ew9XuwonwQIcuQb45IaRgm1DRJNlPhyzEjbdrmtYlXOyxJcPyUriQY0U0oGQ= =ESdv -----END PGP SIGNATURE----- --Apple-Mail=_B068960E-5B0C-4673-96B4-2AC06E31BCF8-- From nobody Tue Apr 18 12:49:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739E612EB34 for ; Tue, 18 Apr 2017 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 nUwD3Ljct89l for ; Tue, 18 Apr 2017 12:49:17 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92DB1201F2 for <6man@ietf.org>; Tue, 18 Apr 2017 12:49:16 -0700 (PDT) Received: (qmail 6070 invoked from network); 18 Apr 2017 21:42:34 +0200 Received: from p5dec25a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Apr 2017 21:42:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_d?= =?utf-8?Q?raft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> Date: Tue, 18 Apr 2017 21:42:32 +0200 Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:49:19 -0000 Hi all, sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN = support, the reassembled packet should also do that correctly, no matter = if the nodes support ECN or not. Handling these fields correctly with = fragmentation does not mean that the nodes supports ECN. So this is not = optional=E2=80=A6 Mirja > Am 18.04.2017 um 02:38 schrieb Brian E Carpenter = : >=20 > wfm=20 > On 18/04/2017 09:08, Bob Hinden wrote: >> Hi, >>=20 >> After reading through the discussion, I think a new paragraph (after = the text that says how to construct a reassembled packet) like the = following would be appropriate. >>=20 >> Nodes that support Explicit Congestion Notification [RFC3168] >> should use information in the Traffic Class field from all >> fragment packets to reconstruct the Traffic Class field in = the >> reassembled packet. See Section 5.3 of RFC3168 for more >> information. >>=20 >> I don=E2=80=99t think we need to quote what RFC3168 says, just point = the the correct section. >>=20 >> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support = ECN, so it shouldn't be making any new requirements. >>=20 >> Comments? >>=20 >> Bob >>=20 >>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter = wrote: >>>=20 >>> In line... >>>=20 >>> On 18/04/2017 05:44, Black, David wrote: >>>> Extracting the key portions of text: >>>>=20 >>>>>> That is inconsistent with the following guidance in RFC 3168 (see >>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>=20 >>>>>> 5.3. Fragmentation >>>>>>=20 >>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>>> taken: >>>>>>=20 >>>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>>> MUST NOT occur if any of the other fragments contributing to >>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>=20 >>>>>> * The packet is dropped, instead of being reassembled, for any >>>>>> other reason. >>>>>>=20 >>>>>> If both actions are applicable, either MAY be chosen. Reassembly = of >>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of = the >>>>>> fragments carry the same codepoint. >>>>=20 >>>>> Regardless of the answer to that question, my position would be = that since >>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>>>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>>>> would be an appropriate way to deal with Mirja's comment: >>>>>=20 >>>>> OLD: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet. >>>>> NEW: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet; however, nodes that support Explicit >>>>> Congestion Notification [RFC3168] may use information in the >>>>> Traffic Class field from all fragment packets to reconstruct = the >>>>> Traffic Class field in the reassembled packet. >>>>>=20 >>>>> Note that this would not cause 2460bis itself to levy an = additional >>>>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>>>> simply be making note of a requirement that is already levied by >>>>> RFC 3168. >>>>=20 >>>> In which case, the RFC 3168 requirement should be stated e.g.: >>>>=20 >>>> OLD: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained = in >>>> the reassembled packet. >>>> NEW: >>>> The number and content of the headers preceding the Fragment >>>> header of different fragments of the same original packet may >>>> differ. Whatever headers are present, preceding the Fragment >>>> header in each fragment packet, are processed when the packets >>>> arrive, prior to queueing the fragments for reassembly. Only >>>> those headers in the Offset zero fragment packet are retained = in >>>> the reassembled packet; however, nodes that support Explicit >>>> Congestion Notification [RFC3168] may use information in the >>>> Traffic Class field from any or all fragment packets to = reconstruct >>>> the Traffic Class field in the reassembled packet in order to = meet >>>> RFC 3168's requirements, e.g., that reassembly not lose = indications >>>> of congestion, see Section 5.3 of RFC 3168 for additional = information. >>>>=20 >>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than >>>> hoping she figures out on her own that she ought to take a look at = it . >>>=20 >>> Yes. This is correct. >>>=20 >>> Brian >>>=20 >>>>=20 >>>> Thanks, --David >>>>=20 >>>>> -----Original Message----- >>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. = Heard >>>>> Sent: Monday, April 17, 2017 12:00 PM >>>>> To: 6MAN <6man@ietf.org>; tsvwg >>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>>> ; Mirja Kuehlewind (IETF) = ; >>>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on = draft-ietf-6man-rfc2460bis- >>>>> 09: (with DISCUSS and COMMENT) >>>>>=20 >>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ] >>>>>=20 >>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote: >>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>>> ... >>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> One question because I'm not sure if I interpret this = correct to >>>>> make it >>>>>>>>>>>>> part of my discuss: >>>>>>>>>>>>> Section 4.5: "The number and content of the headers = preceding >>>>> the >>>>>>>>>>>>> Fragment >>>>>>>>>>>>> header of different fragments of the same original packet = may >>>>>>>>>>>>> differ. Whatever headers are present, preceding the = Fragment >>>>>>>>>>>>> header in each fragment packet, are processed when the = packets >>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. = Only >>>>>>>>>>>>> those headers in the Offset zero fragment packet are = retained in >>>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic = Class field) >>>>> is >>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be = correct, >>>>> however, >>>>>>>>>>>>> also not sure what the correct answer is. I know this was = not >>>>> changed in >>>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>>>=20 >>>>>>>>>>>> When fragments are created most of the fields are copied = from the >>>>> IPv6 >>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow = label, >>>>> traffic >>>>>>>>>>>> class, hop limit). Some like payload length, next header, = and hop >>>>> limi >>>>>>>>>>>> t are modified. >>>>>>>>>>>>=20 >>>>>>>>>>>> If I understand your question, the answer is yes, the ECN = code >>>>> point is >>>>>>>>>>>> copied from the first fragment, but should be the same from = all of >>>>> the >>>>>>>>>>>> fragments. >>>>>>>=20 >>>>>>> That is inconsistent with the following guidance in RFC 3168 = (see >>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>=20 >>>>>>> 5.3. Fragmentation >>>>>>>=20 >>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>>>> taken: >>>>>>>=20 >>>>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>>>> MUST NOT occur if any of the other fragments contributing = to >>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>=20 >>>>>>> * The packet is dropped, instead of being reassembled, for = any >>>>>>> other reason. >>>>>>>=20 >>>>>>> If both actions are applicable, either MAY be chosen. = Reassembly of >>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all = of >>>>> the >>>>>>> fragments carry the same codepoint. >>>>>>>=20 >>>>>>>>>>> My concern is that the ECN code point could be changed on = one of >>>>> the >>>>>>>>>>> fragmented packets to signal congestion of a intermediate = node and >>>>>>>>>>> then when you reassemble this information gets lost. That = seems >>>>> wrong. >>>>>>>>>>=20 >>>>>>>>>> That is an interesting idea, but I think out of scope for = advancing this >>>>>>>>>> document to Internet Standard. Then there is the question of = how to >>>>>>>>>> encode n of m fragments experienced congestion. Interesting = future >>>>> work. >>>>>>>>>=20 >>>>>>>>> Yes there might be some more further work needed but that = still >>>>> makes the >>>>>>>>> guidance in this text wrong. Maybe we can add some text that = the >>>>> Traffic >>>>>>>>> Class may be handled differently because it could be changed = on the >>>>> path. >>>>>>>>=20 >>>>>>>> Good point. It's not only ECN that can change; the DSCP can = change too. >>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's = logical >>>>>>>> for 2460bis to note this issue. >>>>>>>=20 >>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>>>> marked >>>>>>> as updating RFC 2460. But in effect it did so for IPv6 = implementations >>>>>>> of ECN, even though it was not written in an IP version-agnostic = manner. >>>>>>>=20 >>>>>>> At the very least text should be added to the description of the >>>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>>> successor document. >>>>>>=20 >>>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>>> reassembling >>>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think = if it there is >>>>>> evidence I agree some text should be added to rfc2460bis, if not, = then >>>>>> maybe not. >>>>>=20 >>>>> Since I lack the expertise to answer that question, I'm hoping = that someone >>>>> in TSVWG will see this message and do so. >>>>>=20 >>>>> Regardless of the answer to that question, my position would be = that since >>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>>>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>>>> would be an appropriate way to deal with Mirja's comment: >>>>>=20 >>>>> OLD: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet. >>>>> NEW: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet; however, nodes that support Explicit >>>>> Congestion Notification [RFC3168] may use information in the >>>>> Traffic Class field from all fragment packets to reconstruct = the >>>>> Traffic Class field in the reassembled packet. >>>>>=20 >>>>> Note that this would not cause 2460bis itself to levy an = additional >>>>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>>>> simply be making note of a requirement that is already levied by >>>>> RFC 3168. >>>>>=20 >>>>> Thanks and regards, >>>>>=20 >>>>> Mike Heard >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Apr 18 12:58:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC22129442 for ; Tue, 18 Apr 2017 12:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 fY1B2ojdIta4 for ; Tue, 18 Apr 2017 12:58:23 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED96D127A91 for ; Tue, 18 Apr 2017 12:58:22 -0700 (PDT) Received: (qmail 7862 invoked from network); 18 Apr 2017 21:58:21 +0200 Received: from p5dec25a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Apr 2017 21:58:21 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 18 Apr 2017 21:58:20 +0200 Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , =?utf-8?Q?Ole_Tr=C3=B8an?= , IESG , Brian Carpenter , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:58:25 -0000 sorry it=E2=80=99s late here=E2=80=A6 s/formation/formulation/ s/no go advice/no good advice/ > Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) = : >=20 > This might be rather an editorial issue now but the formation in = RFC6564 is fully fine with me because it says =E2=80=9EMUST NOT unless = no option can be used=E2=80=9C. That=E2=80=99s basically what I = proposed. The formulation in 2460 however is "Defining new IPv6 = extension headers is not recommended.=E2=80=9C. I think this is = overstated and technically no go advise. >=20 > Mirja >=20 >=20 >> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan = : >>=20 >> Hi Mirja/Bob, >>=20 >>=20 >> On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden = wrote: >>> Hi, >>>=20 >>>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>>=20 >>>> Brian, Mirja, >>>>=20 >>>>>>> This combination of circumstances creates a "Catch-22" situation >>>>>>> [Heller] for the deployment of any newly standardised extension >>>>>>> header except for local use. It cannot be widely deployed = because >>>>>>> existing middleboxes will drop it on many paths through the = Internet. >>>>>>> However, most middleboxes will not be updated to allow the new = header >>>>>>> to pass until it has been proved safe and useful on the open >>>>>>> Internet, which is impossible until the middleboxes have been >>>>>>> updated. >>>>>>>=20 >>>>>>> So, defining new IPv6 extension headers is not recommended, = because >>>>>>> they probably won't work across the Internet. But it isn't a = MUST NOT, >>>>>>> because if there was a compelling operational case, we could do = it and >>>>>>> the middleboxes would follow. >>>>>>=20 >>>>>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>>>>=20 >>>>>> I think I agree that I would not like to make a normative = statement here, given that the circumstances are not due to the protocol = design itself but because of the current deployment situation we have = (which in theory could change in future). >>>>>>=20 >>>>>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>>>>=20 >>>>>> Maybe you can work on some new text and then have a quick (?) = check with the wg which text is preferred. If there is clear consensus = for one way by the wg I will not further block this. >>>>>=20 >>>>> I think I will leave that for the document editor. A large part of = RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >>>>=20 >>>> I think what is in the document already is representing the working = group consensus. >>>> The issues of new / unknown extension headers, and how to = distinguish these from new transport protocols have been discussed from = many angles. The two main reasons for the strong recommendation against = new extension headers are: >>>> - most uses are already accommodated with the 3 existing containers = options (routing. hbh and destination) >>>> - sharing the same number space with IP protocols, makes it hard = for intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >>>>=20 >>>> There is already an opening / provision in the text for new = extension headers. The text only asks for these considerations to be = made, before proposing new ones. >>>=20 >>> I agree. >>>=20 >>> I also note that the text in this section was derived from RFC6564, = which updated RFC2460. Specifically from Section 3 of RFC6564: >>>=20 >>> Mindful of the need for compatibility with existing IPv6 = deployments, >>> new IPv6 extension headers MUST NOT be created or specified, unless >>> no existing IPv6 extension header can be used by specifying a new >>> option for that existing IPv6 extension header. >>=20 >> Yes. This text was arrived at after a lot of discussion in the 6man = WG >> during the development of the draft that became RFC6564. >>=20 >>>=20 >>> New extension headers are allowed (just not recommended) and the = next paragraph in the Section specifies a format that should be used for = new Extension headers. I think there is a lot of flexibility going = forward. >>=20 >> Yep. I think the above warning is issued because a node processing an >> unknown extension header will simply drop it, and this makes >> incremental deployability of these new extension headers difficult >> over the Internet. >>=20 >> Thanks >> Suresh >>=20 >=20 From nobody Tue Apr 18 13:16:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA812EABC for ; Tue, 18 Apr 2017 13:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 zsKhL8efnQjm for ; Tue, 18 Apr 2017 13:16:41 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E2D128B8E for ; Tue, 18 Apr 2017 13:16:40 -0700 (PDT) Received: (qmail 7517 invoked from network); 18 Apr 2017 21:49:56 +0200 Received: from p5dec25a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Apr 2017 21:49:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 18 Apr 2017 21:49:55 +0200 Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , =?utf-8?Q?Ole_Tr=C3=B8an?= , IESG , Brian Carpenter , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:16:42 -0000 This might be rather an editorial issue now but the formation in RFC6564 = is fully fine with me because it says =E2=80=9EMUST NOT unless no option = can be used=E2=80=9C. That=E2=80=99s basically what I proposed. The = formulation in 2460 however is "Defining new IPv6 extension headers is = not recommended.=E2=80=9C. I think this is overstated and technically no = go advise. Mirja > Am 17.04.2017 um 05:57 schrieb Suresh Krishnan = : >=20 > Hi Mirja/Bob, >=20 >=20 > On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden = wrote: >> Hi, >>=20 >>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>=20 >>> Brian, Mirja, >>>=20 >>>>>> This combination of circumstances creates a "Catch-22" situation >>>>>> [Heller] for the deployment of any newly standardised extension >>>>>> header except for local use. It cannot be widely deployed = because >>>>>> existing middleboxes will drop it on many paths through the = Internet. >>>>>> However, most middleboxes will not be updated to allow the new = header >>>>>> to pass until it has been proved safe and useful on the open >>>>>> Internet, which is impossible until the middleboxes have been >>>>>> updated. >>>>>>=20 >>>>>> So, defining new IPv6 extension headers is not recommended, = because >>>>>> they probably won't work across the Internet. But it isn't a MUST = NOT, >>>>>> because if there was a compelling operational case, we could do = it and >>>>>> the middleboxes would follow. >>>>>=20 >>>>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>>>=20 >>>>> I think I agree that I would not like to make a normative = statement here, given that the circumstances are not due to the protocol = design itself but because of the current deployment situation we have = (which in theory could change in future). >>>>>=20 >>>>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>>>=20 >>>>> Maybe you can work on some new text and then have a quick (?) = check with the wg which text is preferred. If there is clear consensus = for one way by the wg I will not further block this. >>>>=20 >>>> I think I will leave that for the document editor. A large part of = RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >>>=20 >>> I think what is in the document already is representing the working = group consensus. >>> The issues of new / unknown extension headers, and how to = distinguish these from new transport protocols have been discussed from = many angles. The two main reasons for the strong recommendation against = new extension headers are: >>> - most uses are already accommodated with the 3 existing containers = options (routing. hbh and destination) >>> - sharing the same number space with IP protocols, makes it hard for = intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >>>=20 >>> There is already an opening / provision in the text for new = extension headers. The text only asks for these considerations to be = made, before proposing new ones. >>=20 >> I agree. >>=20 >> I also note that the text in this section was derived from RFC6564, = which updated RFC2460. Specifically from Section 3 of RFC6564: >>=20 >> Mindful of the need for compatibility with existing IPv6 = deployments, >> new IPv6 extension headers MUST NOT be created or specified, unless >> no existing IPv6 extension header can be used by specifying a new >> option for that existing IPv6 extension header. >=20 > Yes. This text was arrived at after a lot of discussion in the 6man WG > during the development of the draft that became RFC6564. >=20 >>=20 >> New extension headers are allowed (just not recommended) and the next = paragraph in the Section specifies a format that should be used for new = Extension headers. I think there is a lot of flexibility going forward. >=20 > Yep. I think the above warning is issued because a node processing an > unknown extension header will simply drop it, and this makes > incremental deployability of these new extension headers difficult > over the Internet. >=20 > Thanks > Suresh >=20 From nobody Tue Apr 18 13:43:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BEE127876 for ; Tue, 18 Apr 2017 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 dtrJ1DvsbAmw for ; Tue, 18 Apr 2017 13:43:00 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCDC1243FE for ; Tue, 18 Apr 2017 13:43:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3IKgxVN033871; Tue, 18 Apr 2017 13:42:59 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3IKgsQ2033470 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 18 Apr 2017 13:42:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Apr 2017 13:42:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Tue, 18 Apr 2017 13:42:53 -0700 From: "Templin, Fred L" To: Fred Baker CC: Mikael Abrahamsson , james woodyatt , "ipv6@ietf.org" , Dave Thaler Subject: RE: Route Information Options in IPv6 Neighbor Discovery Thread-Topic: Route Information Options in IPv6 Neighbor Discovery Thread-Index: AdKz02OPoeaHB7mXSI2gKFT6CIowLQDYdB/0ABIAnAAAFYoRkAAQ+GSAABsW9kA= Date: Tue, 18 Apr 2017 20:42:53 +0000 Message-ID: <5ce85dd13f1741de95ee722d0ec23dd9@XCH15-06-08.nw.nos.boeing.com> References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> In-Reply-To: <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:43:02 -0000 Hi Fred, A comment about SAVI/DHCP. RFC7513 seems to suggest DHCP snooping, i.e., some device on the path from the DHCP server to client examines the content= s of DHCP messages. Unfortunately, the DHCPv6 Security specification mandates the use of encryption: https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-21.txt Does it mean that Secure DHCPv6 will be incompatible with SAVI? Thanks - Fred > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Monday, April 17, 2017 5:42 PM > To: Templin, Fred L > Cc: Mikael Abrahamsson ; james woodyatt ; ipv6@ietf.org; Dave Thaler > > Subject: Re: Route Information Options in IPv6 Neighbor Discovery >=20 > We have essentially the same problem with IPv4 Source Guard, as several c= ompanies call the technology. It has been deployed since > 2004 or thereabouts as proprietary technology, but operates essentially a= s SAVI/DHCP does. We don't observe the issue you raise. >=20 > A redirect in essence is router A telling some host that router B in the = same subnet that would be a better choice - that router A's next > hop for the indicated address is router B, and the host can be a good cit= izen by sending that traffic to B in the first place. If they're in > the same subnet and the host can talk with both of them, the host is goin= g to use the same source address and the same interface. > SAVI is thrilled, and if the host does as it is told, we reduced message = rate on the LAN a little bit. >=20 > Further discussion of SAVI should probably go to savi@ietf.org... >=20 > > On Apr 17, 2017, at 4:47 PM, Templin, Fred L wrote: > > > > I have a question on how SAVI interacts with the IPv6 Redirect function= in general. > > When a Router Redirects a Source to a Target, the Source has discovered= something > > that it did not know before, namely that a target IPv6 prefix is reacha= ble via the > > Target directly without having to go through the Router. > > > > Armed with this knowledge however, what is to stop the Source from send= ing packets > > with spoofed IPv6 source addresses via the Target? And, this is an issu= e for standard > > IPv6 Redirect for a singleton destination and not just for Redirects th= at include RIOs. > > > > That said, there is a way for the Source to tell the Target about the s= ource address(es) > > it intends to use by including the source addresses or prefixes in RIOs= in a NS sent > > to the Target before any data packets are sent. And, if the Source lies= about any of > > its addresses any SAVI L2 devices that examine the NS messages can drop= them. > > > > Thanks - Fred > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > >> Sent: Sunday, April 16, 2017 11:19 PM > >> To: Mikael Abrahamsson > >> Cc: Templin, Fred L ; james woodyatt ; ipv6@ietf.org; Dave Thaler > >> > >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery > >> > >> > >>> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson wr= ote: > >>> > >>> On Fri, 14 Apr 2017, Fred Baker wrote: > >>> > >>>>> SAVI (https://tools.ietf.org/wg/savi/) has document that I imagine = would be in scope for this documents security section. For > >> instance, what would an SAVI enabled L2 switch that inspects ND entrie= s do when it sees this RIO entry in ND? > >>>> > >>>> As specified, I think it would ignore them. It looks at the NA to de= termine what {IP address, MAC address} or {IP address, MAC > >> address, Port #} association it should enforce. It has no illusion tha= t this is the only data present. > >>> > >>> So the question becomes, is this desired behaviour? Sounds to me that= there needs to be SAVI document enhancement for this > RIO > >> in ND then, for things to continue functioning properly (as I imagine = if something sends RIO in ND to somewhere, there is > expectation > >> that any antispoofing device should allow for return traffic as well). > >> > >> Please feel free to make specific suggestions. > >> > >> https://tools.ietf.org/html/rfc6620 > >> 6620 FCFS SAVI: First-Come, First-Served Source Address Validation > >> Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. > >> Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) > >> > >> https://tools.ietf.org/html/rfc6959 > >> 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. > >> McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 by= tes) > >> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) > >> > >> https://tools.ietf.org/html/rfc7039 > >> 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. > >> Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: > >> TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) > >> > >> https://tools.ietf.org/html/rfc7219 > >> 7219 SEcure Neighbor Discovery (SEND) Source Address Validation > >> Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. > >> (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: > >> 10.17487/RFC7219) > >> > >> https://tools.ietf.org/html/rfc7513 > >> 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J= . > >> Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 bytes= ) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) > >> > >> https://tools.ietf.org/html/rfc8074 > >> 8074 Source Address Validation Improvement (SAVI) for Mixed Address > >> Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. > >> Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) > >> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) > >> > >> > > > > >=20 From nobody Tue Apr 18 13:46:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8461243FE for ; Tue, 18 Apr 2017 13:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 iFZoImMY052F for ; Tue, 18 Apr 2017 13:46:45 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 342841200FC for ; Tue, 18 Apr 2017 13:46:45 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id s64so1872149pgb.1 for ; Tue, 18 Apr 2017 13:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FybG2fgJv+sMJ9EgVvwOTIm5dCOIRNvsKHA3f/N2Suc=; b=ZWFDpVgAoxdsUPMZlzGWDJQOOdPQkIwX9SXFQ6Fn7AbghMBpXCwQ33lYGa8M8zeBqK arMe0nGU9BJB4/PSmfM4fUlWgGO4NuGg04a373pofCjZhzSBEsMifvBHLl2g3cRAsof1 UTzgRW55inPrSv5R2Tmm/E1lQ4+9Yt04U8QO7ycAGSuK4ZHcef+umdmjUMM83eFHTPkC +5ry+2/wavbJrBinahFUpiuo1Nr9bupUpyRjvTvNoD4mnawydVTpZJxx3weoWBUn/zAj /pcYNOCFtQBJcWroy23JXLuxR6Fnyym36YBhf5ajPZDAsCnitole+E3tZkUq6DsOUv65 kYEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FybG2fgJv+sMJ9EgVvwOTIm5dCOIRNvsKHA3f/N2Suc=; b=uFLEA0KePcptSAe22B/W4qb7XFjobKsPqzUh89nJas28QJuXamCCwMrLk7ceRz9eYJ pQ3IzEbE+zIXPyTTQdw1Tq7YZ7YGP9MaLvOubvj/QdUv2Ey6WQ3DcGn1fYsOtjuhN9Hp ACyfFp5Qii+I/SEmr+fmtWHAh6aDO84i7V2azMxhpK+3UOeirGW27DyvztM6OfHiNtdq tuh3KNNk1n7LCd8vXff7WBL2T8iv0w5qBcsNo0UdtUzfaTRvMaZJP1eyj0TfhECasTN9 mfitWMURIo6gJBFflnrvroaTEmrBaeydJttsLS/yMrp5MCCSDTRi3Icg70CKc4c9iFGi U5qA== X-Gm-Message-State: AN3rC/5WI53WiNERwVMurRYx0uAikIoTFgbgugzcxsNxly2o9cBMtg2c heRIGUum1yfJRA== X-Received: by 10.84.168.4 with SMTP id e4mr25687204plb.138.1492548404789; Tue, 18 Apr 2017 13:46:44 -0700 (PDT) Received: from [192.168.1.13] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id w85sm241796pfk.62.2017.04.18.13.46.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 13:46:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Route Information Options in IPv6 Neighbor Discovery From: Fred Baker In-Reply-To: <5ce85dd13f1741de95ee722d0ec23dd9@XCH15-06-08.nw.nos.boeing.com> Date: Tue, 18 Apr 2017 13:46:42 -0700 Cc: Mikael Abrahamsson , james woodyatt , "ipv6@ietf.org" , Dave Thaler Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C3DB700-B389-4796-AA1E-38172A5A89B0@gmail.com> <12c8ae91db234098a4bb402c08630364@XCH15-06-08.nw.nos.boeing.com> <62ADCA5F-1319-4771-AD48-A449077AD11E@gmail.com> <5ce85dd13f1741de95ee722d0ec23dd9@XCH15-06-08.nw.nos.boeing.com> To: Fred Templin X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:46:48 -0000 > On Apr 18, 2017, at 1:42 PM, Templin, Fred L = wrote: >=20 > Hi Fred, >=20 > A comment about SAVI/DHCP. RFC7513 seems to suggest DHCP snooping, = i.e., > some device on the path from the DHCP server to client examines the = contents > of DHCP messages. Unfortunately, the DHCPv6 Security specification = mandates > the use of encryption: >=20 > https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-21.txt >=20 > Does it mean that Secure DHCPv6 will be incompatible with SAVI? Great question for savi@ietf.org. > Thanks - Fred >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] >> Sent: Monday, April 17, 2017 5:42 PM >> To: Templin, Fred L >> Cc: Mikael Abrahamsson ; james woodyatt = ; ipv6@ietf.org; Dave Thaler >> >> Subject: Re: Route Information Options in IPv6 Neighbor Discovery >>=20 >> We have essentially the same problem with IPv4 Source Guard, as = several companies call the technology. It has been deployed since >> 2004 or thereabouts as proprietary technology, but operates = essentially as SAVI/DHCP does. We don't observe the issue you raise. >>=20 >> A redirect in essence is router A telling some host that router B in = the same subnet that would be a better choice - that router A's next >> hop for the indicated address is router B, and the host can be a good = citizen by sending that traffic to B in the first place. If they're in >> the same subnet and the host can talk with both of them, the host is = going to use the same source address and the same interface. >> SAVI is thrilled, and if the host does as it is told, we reduced = message rate on the LAN a little bit. >>=20 >> Further discussion of SAVI should probably go to savi@ietf.org... >>=20 >>> On Apr 17, 2017, at 4:47 PM, Templin, Fred L = wrote: >>>=20 >>> I have a question on how SAVI interacts with the IPv6 Redirect = function in general. >>> When a Router Redirects a Source to a Target, the Source has = discovered something >>> that it did not know before, namely that a target IPv6 prefix is = reachable via the >>> Target directly without having to go through the Router. >>>=20 >>> Armed with this knowledge however, what is to stop the Source from = sending packets >>> with spoofed IPv6 source addresses via the Target? And, this is an = issue for standard >>> IPv6 Redirect for a singleton destination and not just for Redirects = that include RIOs. >>>=20 >>> That said, there is a way for the Source to tell the Target about = the source address(es) >>> it intends to use by including the source addresses or prefixes in = RIOs in a NS sent >>> to the Target before any data packets are sent. And, if the Source = lies about any of >>> its addresses any SAVI L2 devices that examine the NS messages can = drop them. >>>=20 >>> Thanks - Fred >>>=20 >>>> -----Original Message----- >>>> From: Fred Baker [mailto:fredbaker.ietf@gmail.com] >>>> Sent: Sunday, April 16, 2017 11:19 PM >>>> To: Mikael Abrahamsson >>>> Cc: Templin, Fred L ; james woodyatt = ; ipv6@ietf.org; Dave Thaler >>>> >>>> Subject: Re: Route Information Options in IPv6 Neighbor Discovery >>>>=20 >>>>=20 >>>>> On Apr 16, 2017, at 9:43 PM, Mikael Abrahamsson = wrote: >>>>>=20 >>>>> On Fri, 14 Apr 2017, Fred Baker wrote: >>>>>=20 >>>>>>> SAVI (https://tools.ietf.org/wg/savi/) has document that I = imagine would be in scope for this documents security section. For >>>> instance, what would an SAVI enabled L2 switch that inspects ND = entries do when it sees this RIO entry in ND? >>>>>>=20 >>>>>> As specified, I think it would ignore them. It looks at the NA to = determine what {IP address, MAC address} or {IP address, MAC >>>> address, Port #} association it should enforce. It has no illusion = that this is the only data present. >>>>>=20 >>>>> So the question becomes, is this desired behaviour? Sounds to me = that there needs to be SAVI document enhancement for this >> RIO >>>> in ND then, for things to continue functioning properly (as I = imagine if something sends RIO in ND to somewhere, there is >> expectation >>>> that any antispoofing device should allow for return traffic as = well). >>>>=20 >>>> Please feel free to make specific suggestions. >>>>=20 >>>> https://tools.ietf.org/html/rfc6620 >>>> 6620 FCFS SAVI: First-Come, First-Served Source Address Validation >>>> Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. >>>> Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT=3D84010 bytes) >>>> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) >>>>=20 >>>> https://tools.ietf.org/html/rfc6959 >>>> 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. >>>> McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT=3D62217 = bytes) >>>> (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) >>>>=20 >>>> https://tools.ietf.org/html/rfc7039 >>>> 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, = J. >>>> Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: >>>> TXT=3D31946 bytes) (Status: INFORMATIONAL) (DOI: = 10.17487/RFC7039) >>>>=20 >>>> https://tools.ietf.org/html/rfc7219 >>>> 7219 SEcure Neighbor Discovery (SEND) Source Address Validation >>>> Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. >>>> (Format: TXT=3D90423 bytes) (Status: PROPOSED STANDARD) (DOI: >>>> 10.17487/RFC7219) >>>>=20 >>>> https://tools.ietf.org/html/rfc7513 >>>> 7513 Source Address Validation Improvement (SAVI) Solution for = DHCP. J. >>>> Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT=3D123735 = bytes) >>>> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) >>>>=20 >>>> https://tools.ietf.org/html/rfc8074 >>>> 8074 Source Address Validation Improvement (SAVI) for Mixed Address >>>> Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. >>>> Levy-Abegnoli, Ed.. February 2017. (Format: TXT=3D23910 bytes) >>>> (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 From nobody Tue Apr 18 14:18:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B568512944A; Tue, 18 Apr 2017 14:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=c+4lhMJb; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=RqsrY5yR 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 hyG-qi2Kq_AL; Tue, 18 Apr 2017 14:17:44 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCD912778E; Tue, 18 Apr 2017 14:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492550264; x=1524086264; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y3r7d5cA7Id+Vwd9cNs6BkO9XPTPEUy1ZPL3olwu+ug=; b=c+4lhMJbknPapImMCfyGrDrwYr1rjpCcgomPfZy1XBGqGCKE1fKRdtP+ dquU+wkJW9GCReGa/zhNviPq7neqtPTdNGsKGA8lX9Ahv3b/wic47IF31 L9D+IvEk3jBvqU7UVWyoUP7Nk8ARA3XOK+iU7TgBfTHfaLA30Yf9OdlzU 0=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 16:17:43 -0500 From: "Black, David" Cc: "C. M. Heard" , 6MAN <6man@ietf.org>, tsvwg , "draft-ietf-6man-rfc2460bis@ietf.org" , "Mirja Kuehlewind (IETF)" , IESG , 6man Chairs <6man-chairs@ietf.org>, "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 03:11:40 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3ILHdt1020212 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 17:17:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3ILHdt1020212 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492550262; bh=3VKTc2DkqmeWZ72fa4PnnZXxZRU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RqsrY5yRMGYK7A4uS+Q8H95aMTBfLOYJiZEMmCqBE1oJPVFzUQWwAABfeO8zrwtxJ Ws/txxPWuPN1wlMVry9BMc2hBOSaE/eu7BB7o5r9N0qtnhsYyHpGLX58rIql3G8vHZ ZQ0wdcvzNf8jenBacYCmPMC1QEwpMY4lUQ4ev1LE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com v3ILHdt1020212 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 18 Apr 2017 17:16:51 -0400 Received: from MXHUB301.corp.emc.com (MXHUB301.corp.emc.com [10.146.3.27]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3ILHGJH023943 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 18 Apr 2017 17:17:16 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB301.corp.emc.com ([10.146.3.27]) with mapi id 14.03.0266.001; Tue, 18 Apr 2017 17:17:16 -0400 To: Brian E Carpenter , Bob Hinden Subject: =?utf-8?B?UkU6IFt0c3Z3Z10gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJh?= =?utf-8?B?ZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5k?= =?utf-8?Q?_COMMENT)?= Thread-Topic: =?utf-8?B?W3RzdndnXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLTZtYW4tcmZjMjQ2MGJpcy0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09N?= =?utf-8?Q?MENT)?= Thread-Index: AQHSt7T6ZLGWXOT01k+EpGAdOQo8CqHKUUAAgAA6rQCAARXb0A== Date: Tue, 18 Apr 2017 21:17:16 +0000 Message-ID: References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> In-Reply-To: <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:17:48 -0000 VGhlIGxvd2VyIGNhc2UgInNob3VsZCIgaW4gdGhlIHByb3Bvc2VkIG5ldyBwYXJhZ3JhcGggY291 bGQgYmUgbWlzLXJlYWQgYXMgd2Vha2VuaW5nIFJGQyAzMTY4J3MgIk1VU1QgTk9UIGxvc2UgaW5k aWNhdGlvbnMgb2YgY29uZ2VzdGlvbiIgcmVxdWlyZW1lbnQuDQoNCkkgd291bGQgcmVtb3ZlIHRo YXQgb25lIHdvcmQgKCJzaG91bGQiKSBmcm9tIHRoZSBwcm9wb3NlZCBuZXcgcGFyYWdyYXBoIHRv IGF2b2lkIHRoYXQgcG9zc2libGUgY29uZnVzaW9uLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFp bHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBBcHJpbCAx NywgMjAxNyA4OjM5IFBNDQo+IFRvOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4N Cj4gQ2M6IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT47IEMuIE0uIEhlYXJkIDxo ZWFyZEBwb2JveC5jb20+Ow0KPiA2TUFOIDw2bWFuQGlldGYub3JnPjsgdHN2d2cgPHRzdndnQGll dGYub3JnPjsgZHJhZnQtaWV0Zi02bWFuLQ0KPiByZmMyNDYwYmlzQGlldGYub3JnOyBNaXJqYSBL dWVobGV3aW5kIChJRVRGKSA8aWV0ZkBrdWVobGV3aW5kLm5ldD47IElFU0cNCj4gPGllc2dAaWV0 Zi5vcmc+OyA2bWFuIENoYWlycyA8Nm1hbi1jaGFpcnNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJl OiBbdHN2d2ddIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtNm1hbi1y ZmMyNDYwYmlzLQ0KPiAwOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IHdmbQ0K PiBPbiAxOC8wNC8yMDE3IDA5OjA4LCBCb2IgSGluZGVuIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ ID4gQWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSBkaXNjdXNzaW9uLCBJIHRoaW5rIGEgbmV3IHBh cmFncmFwaCAoYWZ0ZXIgdGhlDQo+IHRleHQgdGhhdCBzYXlzIGhvdyB0byBjb25zdHJ1Y3QgYSBy ZWFzc2VtYmxlZCBwYWNrZXQpIGxpa2UgdGhlIGZvbGxvd2luZw0KPiB3b3VsZCBiZSBhcHByb3By aWF0ZS4NCj4gPg0KPiA+ICAgICAgICAgIE5vZGVzIHRoYXQgc3VwcG9ydCBFeHBsaWNpdCBDb25n ZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0NCj4gPiAgICAgICAgICBzaG91bGQgdXNlIGlu Zm9ybWF0aW9uIGluIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsDQo+ID4gICAgICAg ICAgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUgVHJhZmZpYyBDbGFzcyBmaWVs ZCBpbiB0aGUNCj4gPiAgICAgICAgICByZWFzc2VtYmxlZCBwYWNrZXQuICBTZWUgU2VjdGlvbiA1 LjMgb2YgUkZDMzE2OCBmb3IgbW9yZQ0KPiA+ICAgICAgICAgIGluZm9ybWF0aW9uLg0KPiA+DQo+ ID4gSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gcXVvdGUgd2hhdCBSRkMzMTY4IHNheXMsIGp1 c3QgcG9pbnQgdGhlIHRoZQ0KPiBjb3JyZWN0IHNlY3Rpb24uDQo+ID4NCj4gPiBUaGlzIGFsc28g ZG9lc27igJl0IGVmZmVjdCBub2RlcyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBFQ04sIHNvIGl0IHNo b3VsZG4ndCBiZQ0KPiBtYWtpbmcgYW55IG5ldyByZXF1aXJlbWVudHMuDQo+ID4NCj4gPiBDb21t ZW50cz8NCj4gPg0KPiA+IEJvYg0KPiA+DQo+ID4+IE9uIEFwciAxNywgMjAxNywgYXQgMTI6NTgg UE0sIEJyaWFuIEUgQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdy b3RlOg0KPiA+Pg0KPiA+PiBJbiBsaW5lLi4uDQo+ID4+DQo+ID4+IE9uIDE4LzA0LzIwMTcgMDU6 NDQsIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPj4+IEV4dHJhY3RpbmcgdGhlIGtleSBwb3J0aW9u cyBvZiB0ZXh0Og0KPiA+Pj4NCj4gPj4+Pj4gVGhhdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUg Zm9sbG93aW5nIGd1aWRhbmNlIGluIFJGQyAzMTY4IChzZWUNCj4gPj4+Pj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPiA+Pj4+Pg0KPiA+Pj4+PiA1 LjMuICBGcmFnbWVudGF0aW9uDQo+ID4+Pj4+DQo+ID4+Pj4+ICBFQ04tY2FwYWJsZSBwYWNrZXRz IE1BWSBoYXZlIHRoZSBERiAoRG9uJ3QgRnJhZ21lbnQpIGJpdCBzZXQuDQo+ID4+Pj4+ICBSZWFz c2VtYmx5IG9mIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBOT1QgbG9zZSBpbmRpY2F0aW9ucyBv Zg0KPiA+Pj4+PiAgY29uZ2VzdGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBhbnkgZnJhZ21lbnQg b2YgYW4gSVAgcGFja2V0IHRvIGJlDQo+ID4+Pj4+ICByZWFzc2VtYmxlZCBoYXMgdGhlIENFIGNv ZGVwb2ludCBzZXQsIHRoZW4gb25lIG9mIHR3byBhY3Rpb25zIE1VU1QNCj4gYmUNCj4gPj4+Pj4g IHRha2VuOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgKiBTZXQgdGhlIENFIGNvZGVwb2ludCBvbiB0 aGUgcmVhc3NlbWJsZWQgcGFja2V0LiAgSG93ZXZlciwgdGhpcw0KPiA+Pj4+PiAgICAgICBNVVNU IE5PVCBvY2N1ciBpZiBhbnkgb2YgdGhlIG90aGVyIGZyYWdtZW50cyBjb250cmlidXRpbmcgdG8N Cj4gPj4+Pj4gICAgICAgdGhpcyByZWFzc2VtYmx5IGNhcnJpZXMgdGhlIE5vdC1FQ1QgY29kZXBv aW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgKiBUaGUgcGFja2V0IGlzIGRyb3BwZWQsIGluc3Rl YWQgb2YgYmVpbmcgcmVhc3NlbWJsZWQsIGZvciBhbnkNCj4gPj4+Pj4gICAgICAgb3RoZXIgcmVh c29uLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgSWYgYm90aCBhY3Rpb25zIGFyZSBhcHBsaWNhYmxlLCBl aXRoZXIgTUFZIGJlIGNob3Nlbi4gIFJlYXNzZW1ibHkgb2YNCj4gPj4+Pj4gIGEgZnJhZ21lbnRl ZCBwYWNrZXQgTVVTVCBOT1QgY2hhbmdlIHRoZSBFQ04gY29kZXBvaW50IHdoZW4gYWxsDQo+IG9m IHRoZQ0KPiA+Pj4+PiAgZnJhZ21lbnRzIGNhcnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4+ DQo+ID4+Pj4gUmVnYXJkbGVzcyBvZiB0aGUgYW5zd2VyIHRvIHRoYXQgcXVlc3Rpb24sIG15IHBv c2l0aW9uIHdvdWxkIGJlIHRoYXQNCj4gc2luY2UNCj4gPj4+PiAyNDYwYmlzIGFscmVhZHkgZGVm ZXJzIHRvIFJGQyAyNDc0IGFuZCBSRkMgMzE2OCByZWdhcmRpbmcgdGhlIGhhbmRsaW5nDQo+IG9m DQo+ID4+Pj4gdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQsIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0 aW9uIHRvIDI0NjBiaXMgU2VjdGlvbiA0LjUNCj4gPj4+PiB3b3VsZCBiZSBhbiBhcHByb3ByaWF0 ZSB3YXkgdG8gZGVhbCB3aXRoIE1pcmphJ3MgY29tbWVudDoNCj4gPj4+Pg0KPiA+Pj4+IE9MRDoN Cj4gPj4+PiAgICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2Vk aW5nIHRoZSBGcmFnbWVudA0KPiA+Pj4+ICAgICAgaGVhZGVyIG9mIGRpZmZlcmVudCBmcmFnbWVu dHMgb2YgdGhlIHNhbWUgb3JpZ2luYWwgcGFja2V0IG1heQ0KPiA+Pj4+ICAgICAgZGlmZmVyLiAg V2hhdGV2ZXIgaGVhZGVycyBhcmUgcHJlc2VudCwgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiA+ Pj4+ICAgICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdo ZW4gdGhlIHBhY2tldHMNCj4gPj4+PiAgICAgIGFycml2ZSwgcHJpb3IgdG8gcXVldWVpbmcgdGhl IGZyYWdtZW50cyBmb3IgcmVhc3NlbWJseS4gIE9ubHkNCj4gPj4+PiAgICAgIHRob3NlIGhlYWRl cnMgaW4gdGhlIE9mZnNldCB6ZXJvIGZyYWdtZW50IHBhY2tldCBhcmUgcmV0YWluZWQgaW4NCj4g Pj4+PiAgICAgIHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQo+ID4+Pj4gTkVXOg0KPiA+Pj4+ICAg ICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBwcmVjZWRpbmcgdGhlIEZy YWdtZW50DQo+ID4+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUg c2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+Pj4gICAgICBkaWZmZXIuICBXaGF0ZXZlciBo ZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4gICAgICBo ZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNzZWQgd2hlbiB0aGUgcGFj a2V0cw0KPiA+Pj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRz IGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4+ICAgICAgdGhvc2UgaGVhZGVycyBpbiB0aGUg T2Zmc2V0IHplcm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBpbg0KPiA+Pj4+ICAgICAg dGhlIHJlYXNzZW1ibGVkIHBhY2tldDsgaG93ZXZlciwgbm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxp Y2l0DQo+ID4+Pj4gICAgICBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0gbWF5IHVz ZSBpbmZvcm1hdGlvbiBpbiB0aGUNCj4gPj4+PiAgICAgIFRyYWZmaWMgQ2xhc3MgZmllbGQgZnJv bSBhbGwgZnJhZ21lbnQgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUNCj4gPj4+PiAgICAgIFRy YWZmaWMgQ2xhc3MgZmllbGQgaW4gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gPj4+Pg0KPiA+ Pj4+IE5vdGUgdGhhdCB0aGlzIHdvdWxkIG5vdCBjYXVzZSAyNDYwYmlzIGl0c2VsZiB0byBsZXZ5 IGFuIGFkZGl0aW9uYWwNCj4gPj4+PiByZXF1aXJlbWVudCBvbiBob3cgSVB2NiBub2RlcyByZWFz c2VtYmxlIGZyYWdtZW50ZWQgcGFja2V0cy4gSXQNCj4gd291bGQNCj4gPj4+PiBzaW1wbHkgYmUg bWFraW5nIG5vdGUgb2YgYSByZXF1aXJlbWVudCB0aGF0IGlzIGFscmVhZHkgbGV2aWVkIGJ5DQo+ ID4+Pj4gUkZDIDMxNjguDQo+ID4+Pg0KPiA+Pj4gSW4gd2hpY2ggY2FzZSwgdGhlIFJGQyAzMTY4 IHJlcXVpcmVtZW50IHNob3VsZCBiZSBzdGF0ZWQgZS5nLjoNCj4gPj4+DQo+ID4+PiBPTEQ6DQo+ ID4+PiAgICAgIFRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5n IHRoZSBGcmFnbWVudA0KPiA+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBv ZiB0aGUgc2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+PiAgICAgIGRpZmZlci4gIFdoYXRl dmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+ICAg ICAgaGVhZGVyIGluIGVhY2ggZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhl IHBhY2tldHMNCj4gPj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21l bnRzIGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGluIHRo ZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+PiAgICAg IHRoZSByZWFzc2VtYmxlZCBwYWNrZXQuDQo+ID4+PiBORVc6DQo+ID4+PiAgICAgIFRoZSBudW1i ZXIgYW5kIGNvbnRlbnQgb2YgdGhlIGhlYWRlcnMgcHJlY2VkaW5nIHRoZSBGcmFnbWVudA0KPiA+ Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZyYWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5h bCBwYWNrZXQgbWF5DQo+ID4+PiAgICAgIGRpZmZlci4gIFdoYXRldmVyIGhlYWRlcnMgYXJlIHBy ZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+ICAgICAgaGVhZGVyIGluIGVhY2gg ZnJhZ21lbnQgcGFja2V0LCBhcmUgcHJvY2Vzc2VkIHdoZW4gdGhlIHBhY2tldHMNCj4gPj4+ICAg ICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWluZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5 LiAgT25seQ0KPiA+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFn bWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+PiAgICAgIHRoZSByZWFzc2VtYmxlZCBw YWNrZXQ7IGhvd2V2ZXIsIG5vZGVzIHRoYXQgc3VwcG9ydCBFeHBsaWNpdA0KPiA+Pj4gICAgICBD b25nZXN0aW9uIE5vdGlmaWNhdGlvbiBbUkZDMzE2OF0gbWF5IHVzZSBpbmZvcm1hdGlvbiBpbiB0 aGUNCj4gPj4+ICAgICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBmcm9tIGFueSBvciBhbGwgZnJhZ21l bnQgcGFja2V0cyB0byByZWNvbnN0cnVjdA0KPiA+Pj4gICAgICB0aGUgVHJhZmZpYyBDbGFzcyBm aWVsZCBpbiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0IGluIG9yZGVyIHRvIG1lZXQNCj4gPj4+ICAg ICAgUkZDIDMxNjgncyByZXF1aXJlbWVudHMsIGUuZy4sIHRoYXQgcmVhc3NlbWJseSBub3QgbG9z ZSBpbmRpY2F0aW9ucw0KPiA+Pj4gICAgICBvZiBjb25nZXN0aW9uLCBzZWUgU2VjdGlvbiA1LjMg b2YgUkZDIDMxNjggZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uDQo+ID4+Pg0KPiA+Pj4gUG9p bnRpbmcgdGhlIGltcGxlbWVudGVyIGF0IFNlY3Rpb24gNS4zIG9mIFJGQyAzMTY4IGlzIGJldHRl ciB0aGFuDQo+ID4+PiBob3Bpbmcgc2hlIGZpZ3VyZXMgb3V0IG9uIGhlciBvd24gdGhhdCBzaGUg b3VnaHQgdG8gdGFrZSBhIGxvb2sgYXQgaXQgLg0KPiA+Pg0KPiA+PiBZZXMuIFRoaXMgaXMgY29y cmVjdC4NCj4gPj4NCj4gPj4gICBCcmlhbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcywgLS1E YXZpZA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZy b206IHRzdndnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEMu IE0uDQo+IEhlYXJkDQo+ID4+Pj4gU2VudDogTW9uZGF5LCBBcHJpbCAxNywgMjAxNyAxMjowMCBQ TQ0KPiA+Pj4+IFRvOiA2TUFOIDw2bWFuQGlldGYub3JnPjsgdHN2d2cgPHRzdndnQGlldGYub3Jn Pg0KPiA+Pj4+IENjOiBkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpc0BpZXRmLm9yZzsgQm9iIEhp bmRlbg0KPiA+Pj4+IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pcmphIEt1ZWhsZXdpbmQgKElF VEYpDQo+IDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsNCj4gPj4+PiBJRVNHIDxpZXNnQGlldGYub3Jn PjsgNm1hbiBDaGFpcnMgPDZtYW4tY2hhaXJzQGlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6IFJl OiBbdHN2d2ddIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtNm1hbi0N Cj4gcmZjMjQ2MGJpcy0NCj4gPj4+PiAwOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g Pj4+Pg0KPiA+Pj4+IFsgVFNWV0cgYWRkZWQgdG8gc29saWNpdCBhZHZpY2Ugb24gaW1wbGVtZW50 YXRpb24gb2YgUkZDIDMxODYgU2VjdGlvbg0KPiA1LjMgXQ0KPiA+Pj4+DQo+ID4+Pj4gT24gU2F0 LCBBcHIgMTUsIDIwMTcgYXQgMTE6NTAgQU0sIEJvYiBIaW5kZW4gd3JvdGU6DQo+ID4+Pj4+IE9u IEFwciAxNSwgMjAxNywgYXQgNDo1MyBBTSwgQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT4g d3JvdGU6DQo+ID4+Pj4+PiBPbiBGcmksIDE0IEFwciAyMDE3IDE0OjI4OjQ0ICsxMjAwIEJyaWFu IEUgQ2FycGVudGVyIHdyb3RlOg0KPiA+Pj4+Pj4+IE9uIDEzLzA0LzIwMTcgMjM6MzYsIE1pcmph IEt1ZWhsZXdpbmQgKElFVEYpIHdyb3RlOg0KPiA+Pj4+Pj4+IC4uLg0KPiA+Pj4+Pj4+Pj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4+Pj4gQ09NTUVOVDoNCj4gPj4+Pj4+Pj4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBPbmUgcXVlc3Rpb24g YmVjYXVzZSBJJ20gbm90IHN1cmUgaWYgSSBpbnRlcnByZXQgdGhpcyBjb3JyZWN0DQo+IHRvDQo+ ID4+Pj4gbWFrZSBpdA0KPiA+Pj4+Pj4+Pj4+Pj4gcGFydCBvZiBteSBkaXNjdXNzOg0KPiA+Pj4+ Pj4+Pj4+Pj4gU2VjdGlvbiA0LjU6ICJUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFk ZXJzDQo+IHByZWNlZGluZw0KPiA+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gRnJhZ21lbnQNCj4g Pj4+Pj4+Pj4+Pj4+IGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9mIHRoZSBzYW1lIG9y aWdpbmFsIHBhY2tldA0KPiBtYXkNCj4gPj4+Pj4+Pj4+Pj4+IGRpZmZlci4gIFdoYXRldmVyIGhl YWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUNCj4gRnJhZ21lbnQNCj4gPj4+Pj4+Pj4+ Pj4+IGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRo ZQ0KPiBwYWNrZXRzDQo+ID4+Pj4+Pj4+Pj4+PiBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRo ZSBmcmFnbWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ID4+Pj4+Pj4+Pj4+PiB0aG9zZSBo ZWFkZXJzIGluIHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlDQo+IHJldGFpbmVk IGluDQo+ID4+Pj4+Pj4+Pj4+PiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0LiINCj4gPj4+Pj4+Pj4+ Pj4+IERvZXMgdGhpcyBtZWFuIHRoZSBFQ04gY29kZXBvaW50IChwYXJ0IG9mIHRoZSBUcmFmZmlj IENsYXNzDQo+IGZpZWxkKQ0KPiA+Pj4+IGlzDQo+ID4+Pj4+Pj4+Pj4+PiBjb3BpZWQgZnJvbSB0 aGUgZmlyc3QgZnJhZ21lbnQ/IFRoaXMgZG9lc24ndCBzZWVtIHRvIGJlDQo+IGNvcnJlY3QsDQo+ ID4+Pj4gaG93ZXZlciwNCj4gPj4+Pj4+Pj4+Pj4+IGFsc28gbm90IHN1cmUgd2hhdCB0aGUgY29y cmVjdCBhbnN3ZXIgaXMuIEkga25vdyB0aGlzIHdhcyBub3QNCj4gPj4+PiBjaGFuZ2VkIGluDQo+ ID4+Pj4+Pj4+Pj4+PiB0aGlzIHJldmlzaW9uIGJ1dCBtYXliZSB3ZSBjYW4gc3RpbGwgZ2V0IHRo aXMgcmlnaHQuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IFdoZW4gZnJhZ21lbnRzIGFy ZSBjcmVhdGVkIG1vc3Qgb2YgdGhlIGZpZWxkcyBhcmUgY29waWVkDQo+IGZyb20gdGhlDQo+ID4+ Pj4gSVB2Ng0KPiA+Pj4+Pj4+Pj4+PiBoZWFkZXJzIChlLmcuLCBTb3VyY2UgQWRkcmVzcywgRGVz dGluYXRpb24gYWRkcmVzcywgZmxvdw0KPiBsYWJlbCwNCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+ Pj4+Pj4+IGNsYXNzLCBob3AgbGltaXQpLiAgU29tZSBsaWtlIHBheWxvYWQgbGVuZ3RoLCBuZXh0 IGhlYWRlciwgYW5kDQo+IGhvcA0KPiA+Pj4+IGxpbWkNCj4gPj4+Pj4+Pj4+Pj4gdCBhcmUgbW9k aWZpZWQuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IElmIEkgdW5kZXJzdGFuZCB5b3Vy IHF1ZXN0aW9uLCB0aGUgYW5zd2VyIGlzIHllcywgdGhlIEVDTiBjb2RlDQo+ID4+Pj4gcG9pbnQg aXMNCj4gPj4+Pj4+Pj4+Pj4gY29waWVkIGZyb20gdGhlIGZpcnN0IGZyYWdtZW50LCBidXQgc2hv dWxkIGJlIHRoZSBzYW1lIGZyb20NCj4gYWxsIG9mDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+Pj4+Pj4+ IGZyYWdtZW50cy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGF0IGlzIGluY29uc2lzdGVudCB3aXRo IHRoZSBmb2xsb3dpbmcgZ3VpZGFuY2UgaW4gUkZDIDMxNjggKHNlZQ0KPiA+Pj4+Pj4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjgjc2VjdGlvbi01LjMpOg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IDUuMy4gIEZyYWdtZW50YXRpb24NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgRUNOLWNhcGFi bGUgcGFja2V0cyBNQVkgaGF2ZSB0aGUgREYgKERvbid0IEZyYWdtZW50KSBiaXQgc2V0Lg0KPiA+ Pj4+Pj4gIFJlYXNzZW1ibHkgb2YgYSBmcmFnbWVudGVkIHBhY2tldCBNVVNUIE5PVCBsb3NlIGlu ZGljYXRpb25zIG9mDQo+ID4+Pj4+PiAgY29uZ2VzdGlvbi4gIEluIG90aGVyIHdvcmRzLCBpZiBh bnkgZnJhZ21lbnQgb2YgYW4gSVAgcGFja2V0IHRvIGJlDQo+ID4+Pj4+PiAgcmVhc3NlbWJsZWQg aGFzIHRoZSBDRSBjb2RlcG9pbnQgc2V0LCB0aGVuIG9uZSBvZiB0d28gYWN0aW9ucw0KPiBNVVNU IGJlDQo+ID4+Pj4+PiAgdGFrZW46DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICogU2V0IHRoZSBD RSBjb2RlcG9pbnQgb24gdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4gIEhvd2V2ZXIsIHRoaXMNCj4g Pj4+Pj4+ICAgICAgIE1VU1QgTk9UIG9jY3VyIGlmIGFueSBvZiB0aGUgb3RoZXIgZnJhZ21lbnRz IGNvbnRyaWJ1dGluZyB0bw0KPiA+Pj4+Pj4gICAgICAgdGhpcyByZWFzc2VtYmx5IGNhcnJpZXMg dGhlIE5vdC1FQ1QgY29kZXBvaW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAqIFRoZSBwYWNr ZXQgaXMgZHJvcHBlZCwgaW5zdGVhZCBvZiBiZWluZyByZWFzc2VtYmxlZCwgZm9yIGFueQ0KPiA+ Pj4+Pj4gICAgICAgb3RoZXIgcmVhc29uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICBJZiBib3RoIGFj dGlvbnMgYXJlIGFwcGxpY2FibGUsIGVpdGhlciBNQVkgYmUgY2hvc2VuLiAgUmVhc3NlbWJseSBv Zg0KPiA+Pj4+Pj4gIGEgZnJhZ21lbnRlZCBwYWNrZXQgTVVTVCBOT1QgY2hhbmdlIHRoZSBFQ04g Y29kZXBvaW50IHdoZW4gYWxsDQo+IG9mDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+PiAgZnJhZ21lbnRz IGNhcnJ5IHRoZSBzYW1lIGNvZGVwb2ludC4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gTXkgY29u Y2VybiBpcyB0aGF0IHRoZSBFQ04gY29kZSBwb2ludCBjb3VsZCBiZSBjaGFuZ2VkIG9uDQo+IG9u ZSBvZg0KPiA+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4+IGZyYWdtZW50ZWQgcGFja2V0cyB0byBzaWdu YWwgY29uZ2VzdGlvbiBvZiBhIGludGVybWVkaWF0ZQ0KPiBub2RlIGFuZA0KPiA+Pj4+Pj4+Pj4+ IHRoZW4gd2hlbiB5b3UgcmVhc3NlbWJsZSB0aGlzIGluZm9ybWF0aW9uIGdldHMgbG9zdC4gVGhh dA0KPiBzZWVtcw0KPiA+Pj4+IHdyb25nLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoYXQg aXMgYW4gaW50ZXJlc3RpbmcgaWRlYSwgYnV0IEkgdGhpbmsgb3V0IG9mIHNjb3BlIGZvciBhZHZh bmNpbmcNCj4gdGhpcw0KPiA+Pj4+Pj4+Pj4gZG9jdW1lbnQgdG8gSW50ZXJuZXQgU3RhbmRhcmQu ICBUaGVuIHRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZg0KPiBob3cgdG8NCj4gPj4+Pj4+Pj4+IGVu Y29kZSBuIG9mIG0gZnJhZ21lbnRzIGV4cGVyaWVuY2VkIGNvbmdlc3Rpb24uICBJbnRlcmVzdGlu Zw0KPiBmdXR1cmUNCj4gPj4+PiB3b3JrLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBZZXMgdGhl cmUgbWlnaHQgYmUgc29tZSBtb3JlIGZ1cnRoZXIgd29yayBuZWVkZWQgYnV0IHRoYXQgc3RpbGwN Cj4gPj4+PiBtYWtlcyB0aGUNCj4gPj4+Pj4+Pj4gZ3VpZGFuY2UgaW4gdGhpcyB0ZXh0IHdyb25n LiBNYXliZSB3ZSBjYW4gYWRkIHNvbWUgdGV4dCB0aGF0IHRoZQ0KPiA+Pj4+IFRyYWZmaWMNCj4g Pj4+Pj4+Pj4gQ2xhc3MgbWF5IGJlIGhhbmRsZWQgZGlmZmVyZW50bHkgYmVjYXVzZSBpdCBjb3Vs ZCBiZSBjaGFuZ2VkIG9uDQo+IHRoZQ0KPiA+Pj4+IHBhdGguDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBHb29kIHBvaW50LiBJdCdzIG5vdCBvbmx5IEVDTiB0aGF0IGNhbiBjaGFuZ2U7IHRoZSBEU0NQ IGNhbiBjaGFuZ2UNCj4gdG9vLg0KPiA+Pj4+Pj4+IEJvdGggUkZDMjQ3NCAoZGlmZnNlcnYpIGFu ZCBFQ04gY2FtZSBhZnRlciBSRkMyNDYwLCBzbyBpdCdzIGxvZ2ljYWwNCj4gPj4+Pj4+PiBmb3Ig MjQ2MGJpcyB0byBub3RlIHRoaXMgaXNzdWUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSXQgc2VlbXMg dGhhdCB3ZSAoNm1hbiBXRykgbWlzc2VkIHRoaXMgYmVjYXVzZSBSRkMgMzE2OCB3YXMgbm90DQo+ ID4+Pj4gbWFya2VkDQo+ID4+Pj4+PiBhcyB1cGRhdGluZyBSRkMgMjQ2MC4gQnV0IGluIGVmZmVj dCBpdCBkaWQgc28gZm9yIElQdjYgaW1wbGVtZW50YXRpb25zDQo+ID4+Pj4+PiBvZiBFQ04sIGV2 ZW4gdGhvdWdoIGl0IHdhcyBub3Qgd3JpdHRlbiBpbiBhbiBJUCB2ZXJzaW9uLWFnbm9zdGljDQo+ IG1hbm5lci4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBdCB0aGUgdmVyeSBsZWFzdCB0ZXh0IHNob3Vs ZCBiZSBhZGRlZCB0byB0aGUgZGVzY3JpcHRpb24gb2YgdGhlDQo+ID4+Pj4+PiByZWFzc2VtYmx5 IHByb2Nlc3MgdGhhdCBwb2ludHMgdGhlIHJlYWRlciB0byBSRkMgMzE2OCBvciBpdHMNCj4gPj4+ Pj4+IHN1Y2Nlc3NvciBkb2N1bWVudC4NCj4gPj4+Pj4NCj4gPj4+Pj4gRG8gd2UgaGF2ZSBhbnkg ZXZpZGVuY2UgdGhhdCB0aGUgZ3VpZGFuY2UgaW4gUkZDIDMxNjggcmVnYXJkaW5nDQo+ID4+Pj4g cmVhc3NlbWJsaW5nDQo+ID4+Pj4+IElQdjYgZnJhZ21lbnRzIGlzIGltcGxlbWVudGVkPyAgSSBk b27igJl0IGtub3csIGJ1dCB0aGluayBpZiBpdCB0aGVyZSBpcw0KPiA+Pj4+PiBldmlkZW5jZSBJ IGFncmVlIHNvbWUgdGV4dCBzaG91bGQgYmUgYWRkZWQgdG8gcmZjMjQ2MGJpcywgaWYgbm90LCB0 aGVuDQo+ID4+Pj4+IG1heWJlIG5vdC4NCj4gPj4+Pg0KPiA+Pj4+IFNpbmNlIEkgbGFjayB0aGUg ZXhwZXJ0aXNlIHRvIGFuc3dlciB0aGF0IHF1ZXN0aW9uLCBJJ20gaG9waW5nIHRoYXQNCj4gc29t ZW9uZQ0KPiA+Pj4+IGluIFRTVldHIHdpbGwgc2VlIHRoaXMgbWVzc2FnZSBhbmQgZG8gc28uDQo+ ID4+Pj4NCj4gPj4+PiBSZWdhcmRsZXNzIG9mIHRoZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiwg bXkgcG9zaXRpb24gd291bGQgYmUgdGhhdA0KPiBzaW5jZQ0KPiA+Pj4+IDI0NjBiaXMgYWxyZWFk eSBkZWZlcnMgdG8gUkZDIDI0NzQgYW5kIFJGQyAzMTY4IHJlZ2FyZGluZyB0aGUgaGFuZGxpbmcN Cj4gb2YNCj4gPj4+PiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCwgdGhlIGZvbGxvd2luZyBtb2Rp ZmljYXRpb24gdG8gMjQ2MGJpcyBTZWN0aW9uIDQuNQ0KPiA+Pj4+IHdvdWxkIGJlIGFuIGFwcHJv cHJpYXRlIHdheSB0byBkZWFsIHdpdGggTWlyamEncyBjb21tZW50Og0KPiA+Pj4+DQo+ID4+Pj4g T0xEOg0KPiA+Pj4+ICAgICAgVGhlIG51bWJlciBhbmQgY29udGVudCBvZiB0aGUgaGVhZGVycyBw cmVjZWRpbmcgdGhlIEZyYWdtZW50DQo+ID4+Pj4gICAgICBoZWFkZXIgb2YgZGlmZmVyZW50IGZy YWdtZW50cyBvZiB0aGUgc2FtZSBvcmlnaW5hbCBwYWNrZXQgbWF5DQo+ID4+Pj4gICAgICBkaWZm ZXIuICBXaGF0ZXZlciBoZWFkZXJzIGFyZSBwcmVzZW50LCBwcmVjZWRpbmcgdGhlIEZyYWdtZW50 DQo+ID4+Pj4gICAgICBoZWFkZXIgaW4gZWFjaCBmcmFnbWVudCBwYWNrZXQsIGFyZSBwcm9jZXNz ZWQgd2hlbiB0aGUgcGFja2V0cw0KPiA+Pj4+ICAgICAgYXJyaXZlLCBwcmlvciB0byBxdWV1ZWlu ZyB0aGUgZnJhZ21lbnRzIGZvciByZWFzc2VtYmx5LiAgT25seQ0KPiA+Pj4+ICAgICAgdGhvc2Ug aGVhZGVycyBpbiB0aGUgT2Zmc2V0IHplcm8gZnJhZ21lbnQgcGFja2V0IGFyZSByZXRhaW5lZCBp bg0KPiA+Pj4+ICAgICAgdGhlIHJlYXNzZW1ibGVkIHBhY2tldC4NCj4gPj4+PiBORVc6DQo+ID4+ Pj4gICAgICBUaGUgbnVtYmVyIGFuZCBjb250ZW50IG9mIHRoZSBoZWFkZXJzIHByZWNlZGluZyB0 aGUgRnJhZ21lbnQNCj4gPj4+PiAgICAgIGhlYWRlciBvZiBkaWZmZXJlbnQgZnJhZ21lbnRzIG9m IHRoZSBzYW1lIG9yaWdpbmFsIHBhY2tldCBtYXkNCj4gPj4+PiAgICAgIGRpZmZlci4gIFdoYXRl dmVyIGhlYWRlcnMgYXJlIHByZXNlbnQsIHByZWNlZGluZyB0aGUgRnJhZ21lbnQNCj4gPj4+PiAg ICAgIGhlYWRlciBpbiBlYWNoIGZyYWdtZW50IHBhY2tldCwgYXJlIHByb2Nlc3NlZCB3aGVuIHRo ZSBwYWNrZXRzDQo+ID4+Pj4gICAgICBhcnJpdmUsIHByaW9yIHRvIHF1ZXVlaW5nIHRoZSBmcmFn bWVudHMgZm9yIHJlYXNzZW1ibHkuICBPbmx5DQo+ID4+Pj4gICAgICB0aG9zZSBoZWFkZXJzIGlu IHRoZSBPZmZzZXQgemVybyBmcmFnbWVudCBwYWNrZXQgYXJlIHJldGFpbmVkIGluDQo+ID4+Pj4g ICAgICB0aGUgcmVhc3NlbWJsZWQgcGFja2V0OyBob3dldmVyLCBub2RlcyB0aGF0IHN1cHBvcnQg RXhwbGljaXQNCj4gPj4+PiAgICAgIENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XSBt YXkgdXNlIGluZm9ybWF0aW9uIGluIHRoZQ0KPiA+Pj4+ICAgICAgVHJhZmZpYyBDbGFzcyBmaWVs ZCBmcm9tIGFsbCBmcmFnbWVudCBwYWNrZXRzIHRvIHJlY29uc3RydWN0IHRoZQ0KPiA+Pj4+ICAg ICAgVHJhZmZpYyBDbGFzcyBmaWVsZCBpbiB0aGUgcmVhc3NlbWJsZWQgcGFja2V0Lg0KPiA+Pj4+ DQo+ID4+Pj4gTm90ZSB0aGF0IHRoaXMgd291bGQgbm90IGNhdXNlIDI0NjBiaXMgaXRzZWxmIHRv IGxldnkgYW4gYWRkaXRpb25hbA0KPiA+Pj4+IHJlcXVpcmVtZW50IG9uIGhvdyBJUHY2IG5vZGVz IHJlYXNzZW1ibGUgZnJhZ21lbnRlZCBwYWNrZXRzLiBJdA0KPiB3b3VsZA0KPiA+Pj4+IHNpbXBs eSBiZSBtYWtpbmcgbm90ZSBvZiBhIHJlcXVpcmVtZW50IHRoYXQgaXMgYWxyZWFkeSBsZXZpZWQg YnkNCj4gPj4+PiBSRkMgMzE2OC4NCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcyBhbmQgcmVnYXJkcywN Cj4gPj4+Pg0KPiA+Pj4+IE1pa2UgSGVhcmQNCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+PiBpcHY2QGlldGYu b3JnDQo+ID4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4NCj4g Pg0KDQo= From nobody Tue Apr 18 17:51:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2FC126D74 for ; Tue, 18 Apr 2017 17:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0rCAiZ9ShyFT for ; Tue, 18 Apr 2017 17:51:41 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40597129454 for <6man@ietf.org>; Tue, 18 Apr 2017 17:51:40 -0700 (PDT) Received: (qmail 13716 invoked from network); 19 Apr 2017 02:51:38 +0200 Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Apr 2017 02:51:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_d?= =?utf-8?Q?raft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> Date: Wed, 19 Apr 2017 02:51:36 +0200 Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 00:51:44 -0000 Hi again, I should probably have been more constructive here. I=E2=80=99d like to = propose the following text: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet; however, the Traffic Class field from=20 any or all fragments may differ. Handling of Explicit Congestion Notification [RFC3168] is described in Section 5.3 of=20 RFC 3168, ensuring that reassembly does not lose indications of congestion. Do we also need to say something about DiffServ? Mirja > Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi all, >=20 > sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN = support, the reassembled packet should also do that correctly, no matter = if the nodes support ECN or not. Handling these fields correctly with = fragmentation does not mean that the nodes supports ECN. So this is not = optional=E2=80=A6 >=20 > Mirja >=20 >=20 >> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter = : >>=20 >> wfm=20 >> On 18/04/2017 09:08, Bob Hinden wrote: >>> Hi, >>>=20 >>> After reading through the discussion, I think a new paragraph (after = the text that says how to construct a reassembled packet) like the = following would be appropriate. >>>=20 >>> Nodes that support Explicit Congestion Notification [RFC3168] >>> should use information in the Traffic Class field from all >>> fragment packets to reconstruct the Traffic Class field in = the >>> reassembled packet. See Section 5.3 of RFC3168 for more >>> information. >>>=20 >>> I don=E2=80=99t think we need to quote what RFC3168 says, just point = the the correct section. >>>=20 >>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support = ECN, so it shouldn't be making any new requirements. >>>=20 >>> Comments? >>>=20 >>> Bob >>>=20 >>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter = wrote: >>>>=20 >>>> In line... >>>>=20 >>>> On 18/04/2017 05:44, Black, David wrote: >>>>> Extracting the key portions of text: >>>>>=20 >>>>>>> That is inconsistent with the following guidance in RFC 3168 = (see >>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>=20 >>>>>>> 5.3. Fragmentation >>>>>>>=20 >>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>>>> taken: >>>>>>>=20 >>>>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>>>> MUST NOT occur if any of the other fragments contributing to >>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>=20 >>>>>>> * The packet is dropped, instead of being reassembled, for any >>>>>>> other reason. >>>>>>>=20 >>>>>>> If both actions are applicable, either MAY be chosen. = Reassembly of >>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all = of the >>>>>>> fragments carry the same codepoint. >>>>>=20 >>>>>> Regardless of the answer to that question, my position would be = that since >>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>>>>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>>=20 >>>>>> OLD: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet. >>>>>> NEW: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet; however, nodes that support Explicit >>>>>> Congestion Notification [RFC3168] may use information in the >>>>>> Traffic Class field from all fragment packets to reconstruct = the >>>>>> Traffic Class field in the reassembled packet. >>>>>>=20 >>>>>> Note that this would not cause 2460bis itself to levy an = additional >>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>>>>> simply be making note of a requirement that is already levied by >>>>>> RFC 3168. >>>>>=20 >>>>> In which case, the RFC 3168 requirement should be stated e.g.: >>>>>=20 >>>>> OLD: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet. >>>>> NEW: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained = in >>>>> the reassembled packet; however, nodes that support Explicit >>>>> Congestion Notification [RFC3168] may use information in the >>>>> Traffic Class field from any or all fragment packets to = reconstruct >>>>> the Traffic Class field in the reassembled packet in order to = meet >>>>> RFC 3168's requirements, e.g., that reassembly not lose = indications >>>>> of congestion, see Section 5.3 of RFC 3168 for additional = information. >>>>>=20 >>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than >>>>> hoping she figures out on her own that she ought to take a look at = it . >>>>=20 >>>> Yes. This is correct. >>>>=20 >>>> Brian >>>>=20 >>>>>=20 >>>>> Thanks, --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. = Heard >>>>>> Sent: Monday, April 17, 2017 12:00 PM >>>>>> To: 6MAN <6man@ietf.org>; tsvwg >>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>>>> ; Mirja Kuehlewind (IETF) = ; >>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on = draft-ietf-6man-rfc2460bis- >>>>>> 09: (with DISCUSS and COMMENT) >>>>>>=20 >>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 = Section 5.3 ] >>>>>>=20 >>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard = wrote: >>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>>>> ... >>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> One question because I'm not sure if I interpret this = correct to >>>>>> make it >>>>>>>>>>>>>> part of my discuss: >>>>>>>>>>>>>> Section 4.5: "The number and content of the headers = preceding >>>>>> the >>>>>>>>>>>>>> Fragment >>>>>>>>>>>>>> header of different fragments of the same original packet = may >>>>>>>>>>>>>> differ. Whatever headers are present, preceding the = Fragment >>>>>>>>>>>>>> header in each fragment packet, are processed when the = packets >>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. = Only >>>>>>>>>>>>>> those headers in the Offset zero fragment packet are = retained in >>>>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic = Class field) >>>>>> is >>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be = correct, >>>>>> however, >>>>>>>>>>>>>> also not sure what the correct answer is. I know this was = not >>>>>> changed in >>>>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> When fragments are created most of the fields are copied = from the >>>>>> IPv6 >>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow = label, >>>>>> traffic >>>>>>>>>>>>> class, hop limit). Some like payload length, next header, = and hop >>>>>> limi >>>>>>>>>>>>> t are modified. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN = code >>>>>> point is >>>>>>>>>>>>> copied from the first fragment, but should be the same = from all of >>>>>> the >>>>>>>>>>>>> fragments. >>>>>>>>=20 >>>>>>>> That is inconsistent with the following guidance in RFC 3168 = (see >>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>>=20 >>>>>>>> 5.3. Fragmentation >>>>>>>>=20 >>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>>>> reassembled has the CE codepoint set, then one of two actions = MUST be >>>>>>>> taken: >>>>>>>>=20 >>>>>>>> * Set the CE codepoint on the reassembled packet. However, = this >>>>>>>> MUST NOT occur if any of the other fragments contributing = to >>>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>>=20 >>>>>>>> * The packet is dropped, instead of being reassembled, for = any >>>>>>>> other reason. >>>>>>>>=20 >>>>>>>> If both actions are applicable, either MAY be chosen. = Reassembly of >>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all = of >>>>>> the >>>>>>>> fragments carry the same codepoint. >>>>>>>>=20 >>>>>>>>>>>> My concern is that the ECN code point could be changed on = one of >>>>>> the >>>>>>>>>>>> fragmented packets to signal congestion of a intermediate = node and >>>>>>>>>>>> then when you reassemble this information gets lost. That = seems >>>>>> wrong. >>>>>>>>>>>=20 >>>>>>>>>>> That is an interesting idea, but I think out of scope for = advancing this >>>>>>>>>>> document to Internet Standard. Then there is the question = of how to >>>>>>>>>>> encode n of m fragments experienced congestion. Interesting = future >>>>>> work. >>>>>>>>>>=20 >>>>>>>>>> Yes there might be some more further work needed but that = still >>>>>> makes the >>>>>>>>>> guidance in this text wrong. Maybe we can add some text that = the >>>>>> Traffic >>>>>>>>>> Class may be handled differently because it could be changed = on the >>>>>> path. >>>>>>>>>=20 >>>>>>>>> Good point. It's not only ECN that can change; the DSCP can = change too. >>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's = logical >>>>>>>>> for 2460bis to note this issue. >>>>>>>>=20 >>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>>>>> marked >>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 = implementations >>>>>>>> of ECN, even though it was not written in an IP = version-agnostic manner. >>>>>>>>=20 >>>>>>>> At the very least text should be added to the description of = the >>>>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>>>> successor document. >>>>>>>=20 >>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>>>> reassembling >>>>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think = if it there is >>>>>>> evidence I agree some text should be added to rfc2460bis, if = not, then >>>>>>> maybe not. >>>>>>=20 >>>>>> Since I lack the expertise to answer that question, I'm hoping = that someone >>>>>> in TSVWG will see this message and do so. >>>>>>=20 >>>>>> Regardless of the answer to that question, my position would be = that since >>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the = handling of >>>>>> the Traffic Class field, the following modification to 2460bis = Section 4.5 >>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>>=20 >>>>>> OLD: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet. >>>>>> NEW: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet; however, nodes that support Explicit >>>>>> Congestion Notification [RFC3168] may use information in the >>>>>> Traffic Class field from all fragment packets to reconstruct = the >>>>>> Traffic Class field in the reassembled packet. >>>>>>=20 >>>>>> Note that this would not cause 2460bis itself to levy an = additional >>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It = would >>>>>> simply be making note of a requirement that is already levied by >>>>>> RFC 3168. >>>>>>=20 >>>>>> Thanks and regards, >>>>>>=20 >>>>>> Mike Heard >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------- >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Tue Apr 18 20:05:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023BD129417; Tue, 18 Apr 2017 20:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 Myu86OTQ_C_V; Tue, 18 Apr 2017 20:05:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B4E128D44; Tue, 18 Apr 2017 20:05:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 9FE4983E47; Tue, 18 Apr 2017 23:04:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=MyDKDwG0p436 RwhI1et0dvU7Ejk=; b=JZYS3xWJU2w0WQxiuBNoQf1yj2ZFRPcN6oSQziqTo2uA 6Lnhfi9qqzm7dYzDSF1i3t6f1F6TvLJ2qFgnxy7XGS/Q/74Q+4HiDtsOQ8ZmAZ5Q 7gPiGoGPFlfugSgXLzT7dMBDrTvrWNDoMmMZK2a9YmNmJV8sK0V9uyoGrvKoI/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=sUD5xY l3lHWt9yoIsAv8q+X3XnPKSA7F9R3yF6gBAy9+G6979qeTU0PIHnbczX769D5LQy c+r5ymjJFricPZxOo6ZoAd+vHZPxXsMLU99HtYYur04ptDHnnj7u+/aLqPqGmYhp v0vCTAxyp5F2zFjW6L9Uvi7CJtEDW8H6vbte0= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 963FD83E45; Tue, 18 Apr 2017 23:04:56 -0400 (EDT) Received: from mail-qt0-f170.google.com (unknown [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id E4A8A83E41; Tue, 18 Apr 2017 23:04:55 -0400 (EDT) Received: by mail-qt0-f170.google.com with SMTP id m36so9535043qtb.0; Tue, 18 Apr 2017 20:04:55 -0700 (PDT) X-Gm-Message-State: AN3rC/5mtibui+WlSqm4FOb2Z9rzDLS9+ZLVNQ9LkeR1sM9uORgbwg8H Vkgm6//lcF7TWQrooE/OrLPhsYvJWg== X-Received: by 10.200.45.167 with SMTP id p36mr571229qta.265.1492571095588; Tue, 18 Apr 2017 20:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Tue, 18 Apr 2017 20:04:35 -0700 (PDT) In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> From: "C. M. Heard" Date: Tue, 18 Apr 2017 20:04:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" Cc: Brian E Carpenter , Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: F7441072-24AC-11E7-8E3D-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:05:03 -0000 On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote: > sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN sup= port, > the reassembled packet should also do that correctly, no matter if > the nodes support ECN or not. Handling these fields correctly with > fragmentation does not mean that the nodes supports ECN. So this is > not optional=E2=80=A6 This seems confused (or else I am confused). We are discussing issues related to reassembly of fragmented packets, and that is a process that takes place in end systems only, not in forwarding nodes. It is true that if an end system (aka host) supports ECN per RFC 3168, then received packets that it reassembles must have the CE bit pattern set if any fragment has the CE bit pattern set, provided that all fragments contain either CE or ECT(0)/ECT(1). The text that we are working on is intended to say that -- indirectly, by referring to the Section 5.3 of RFC 3168. But, unless ECN is mandatory-to-implement for all IPv6 nodes, end systems are not obliged to support it -- and I see no such mandate in the IPv6 node requirements document. In that case ECN indications will simply be ignored. No purpose is served by levying a requirement on the IPv6 module to preserve an indication that will not be used. Mike Heard From nobody Tue Apr 18 20:15:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA1F129409; Tue, 18 Apr 2017 20:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 OPi3_QNztodQ; Tue, 18 Apr 2017 20:15:07 -0700 (PDT) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (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 969CC12708C; Tue, 18 Apr 2017 20:15:07 -0700 (PDT) Received: by mail-pg0-x244.google.com with SMTP id 34so1939927pgx.3; Tue, 18 Apr 2017 20:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=d1AQdJFtnyE9qQu6UFH5p/9+OUHjGHJQztbwidxBSKw=; b=Dg/8KApLu9gdvl4r4vd1a7SBwHOXQzhde6TSg1yDbiWY2tAxIi+c7kFnAQL2xmxzzI E//6HADVknzIGi+aIEY8sRBvNnqIqbRKUEHUzz0tky0uu87ZCrS1WWeR23hpVoRCQdtN 6/d4F6QLrnSl2KUPECABDBMxqBi/vgz+FwUuaUFCZrdaAxEfC7xgmPQgj1ikr+eahrWg AMWhqVN3Hl5ZlBy1TfPTP2o+2GhrzTsQyywrspnQOegtlDF9L2z7Dd/LtQsipaU4Duni UPbM4am+a/UeJTkTojQRq0ZqmsZ9+FdfFEDZ3xLWszoq3aC2rGBrJW+4StuMfo3WgGv5 uphA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=d1AQdJFtnyE9qQu6UFH5p/9+OUHjGHJQztbwidxBSKw=; b=du0qzBCUcjMhZTas7kPteFk6RglH4mYSej1zOfutPzoT1Ld6FXMxWCvQUMRU69fjFO LIJi5BwN6dvReJ9a+XGR/sH5NyqybeOrc/EQnSan96qdjupS7LG4hawHWNYDxMs/yQ7J VDonBL0iCmgSyG09TCe7tFlwgFj3+xllt2kbDtc5PRZEcwMWZWGh9i1iHc46KFJvB6LP 687hQa2vxrK/0E3iZambnIy34Yio3kRgQLTvPsjXDy5vSHEE6pXYUY8b0XU7iTcm59ur B1YzjNt7ZpSoWtswKLciSGL02SaIpUYz5deHmQro8BXc84NpXa7inbqxo2YhyrjKwe5y 3lIQ== X-Gm-Message-State: AN3rC/42VPsshq3BsRSgQSil5EUEl9nZCNMM7N/QnCXIhhP7/j5qcXVa 1FEPZva5QtNrBA== X-Received: by 10.98.145.18 with SMTP id l18mr746957pfe.173.1492571707190; Tue, 18 Apr 2017 20:15:07 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b5sm1000708pfb.21.2017.04.18.20.15.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 20:15:06 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" , Suresh Krishnan References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , =?UTF-8?Q?Ole_Tr=c3=b8an?= , IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> Date: Wed, 19 Apr 2017 15:15:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:15:09 -0000 In reality "MUST NOT unless..." means about the same as "SHOULD NOT" so I think we agree that this is editorial. Aligning the language with RFC65= 64 makes a lot of sense to me. Brian On 19/04/2017 07:58, Mirja Kuehlewind (IETF) wrote: > sorry it=E2=80=99s late here=E2=80=A6 >=20 > s/formation/formulation/ > s/no go advice/no good advice/ >=20 >> Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) : >> >> This might be rather an editorial issue now but the formation in RFC65= 64 is fully fine with me because it says =E2=80=9EMUST NOT unless no opti= on can be used=E2=80=9C. That=E2=80=99s basically what I proposed. The fo= rmulation in 2460 however is "Defining new IPv6 extension headers is not = recommended.=E2=80=9C. I think this is overstated and technically no go a= dvise. >> >> Mirja >> >> >>> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan : >>> >>> Hi Mirja/Bob, >>> >>> >>> On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden w= rote: >>>> Hi, >>>> >>>>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>>> >>>>> Brian, Mirja, >>>>> >>>>>>>> This combination of circumstances creates a "Catch-22" situation= >>>>>>>> [Heller] for the deployment of any newly standardised extension >>>>>>>> header except for local use. It cannot be widely deployed becau= se >>>>>>>> existing middleboxes will drop it on many paths through the Inte= rnet. >>>>>>>> However, most middleboxes will not be updated to allow the new h= eader >>>>>>>> to pass until it has been proved safe and useful on the open >>>>>>>> Internet, which is impossible until the middleboxes have been >>>>>>>> updated. >>>>>>>> >>>>>>>> So, defining new IPv6 extension headers is not recommended, beca= use >>>>>>>> they probably won't work across the Internet. But it isn't a MUS= T NOT, >>>>>>>> because if there was a compelling operational case, we could do = it and >>>>>>>> the middleboxes would follow. >>>>>>> >>>>>>> First of all yes, giving further explanation/background is defini= tely a good thing to do, and maybe also provide a reference to rfc7045 if= appropriate. >>>>>>> >>>>>>> I think I agree that I would not like to make a normative stateme= nt here, given that the circumstances are not due to the protocol design = itself but because of the current deployment situation we have (which in = theory could change in future). >>>>>>> >>>>>>> However, instead of making a clear recommendation to not every de= fine a new extension header, I think I would prefer if the text was phras= ed in the a way that would make the risk clear, give a clear recommendati= on to rather use destination options if suitable, and then say nothing el= se. >>>>>>> >>>>>>> Maybe you can work on some new text and then have a quick (?) che= ck with the wg which text is preferred. If there is clear consensus for o= ne way by the wg I will not further block this. >>>>>> >>>>>> I think I will leave that for the document editor. A large part of= RFC7045 is about this issue but Bob can probably see best how to integra= te it here. >>>>> >>>>> I think what is in the document already is representing the working= group consensus. >>>>> The issues of new / unknown extension headers, and how to distingui= sh these from new transport protocols have been discussed from many angle= s. The two main reasons for the strong recommendation against new extensi= on headers are: >>>>> - most uses are already accommodated with the 3 existing containers= options (routing. hbh and destination) >>>>> - sharing the same number space with IP protocols, makes it hard fo= r intermediate devices depending on parsing the header chain to find tran= sport information if new headers were introduced. >>>>> >>>>> There is already an opening / provision in the text for new extensi= on headers. The text only asks for these considerations to be made, befor= e proposing new ones. >>>> >>>> I agree. >>>> >>>> I also note that the text in this section was derived from RFC6564, = which updated RFC2460. Specifically from Section 3 of RFC6564: >>>> >>>> Mindful of the need for compatibility with existing IPv6 deployment= s, >>>> new IPv6 extension headers MUST NOT be created or specified, unless= >>>> no existing IPv6 extension header can be used by specifying a new >>>> option for that existing IPv6 extension header. >>> >>> Yes. This text was arrived at after a lot of discussion in the 6man W= G >>> during the development of the draft that became RFC6564. >>> >>>> >>>> New extension headers are allowed (just not recommended) and the nex= t paragraph in the Section specifies a format that should be used for new= Extension headers. I think there is a lot of flexibility going forward.= >>> >>> Yep. I think the above warning is issued because a node processing an= >>> unknown extension header will simply drop it, and this makes >>> incremental deployability of these new extension headers difficult >>> over the Internet. >>> >>> Thanks >>> Suresh >>> >> >=20 >=20 From nobody Tue Apr 18 20:19:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBC12940F; Tue, 18 Apr 2017 20:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 X21iF-J3n-Pc; Tue, 18 Apr 2017 20:18:58 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 4FD7412708C; Tue, 18 Apr 2017 20:18:58 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 63so1964686pgh.0; Tue, 18 Apr 2017 20:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kpQ7Or5Vj2VpeaHkIzmhJoiOnQ/sUajL7XBdsEbZS7I=; b=tfHkcp0bGcUzp6fgCiF4Du5ATrMdeHHIjKDrKtcu64tsdbzCXvg9WySbuYu8rglSn2 ItO9xIb6Bvlf2igh+juLet7Bf6aVWkgnwwU021wrpWi6gPNATLMRfGjCQobDcQwKoMq+ ooUvhblesMuZ46R7lPohCfN3N4cwen6qDSbj0gVWcgJWXRVf7szK2Inu4ppVnupqBA/1 GJOzfNXjLIl9Hu4G306hRTMXLBdp++PNO2jwGWGuCBovB18+Pa8rvAaze6pjbqZXsKY7 x6VQ8haZqJUgL4DGymwWC7qZBApJLA10mu2xE4k7qGUalGrl0GH7wkt7kEMR6SxjYTlw 9v1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=kpQ7Or5Vj2VpeaHkIzmhJoiOnQ/sUajL7XBdsEbZS7I=; b=BfwFDGm3WM1tMtlcEwP8aoSg6ObBksfGGBFVU+tZrpZ9DXI7AOrOD5pEZiqG2XGeA1 afuuZnnbfRJn56uMiyqkdPH1ZwQV+MJ4bsyaBbKA97SYl1Nm0UBaYb1d8w5ZKUtphGOW IQp6QtaTKApdr+mtoNUrL3C9LBgXNTXI36cZeMKxtw4Pp6sP7wjmRwBLTgTymvKUpfjM VUwavSFYESxZYNaXeYfhOgjV0YL2KdTxHAEwQr+KuqgzlQnHLoc/H1KIbXw0dF3Nomtm k0THyk2O5fi+TLlmqZMem9O/cQDQbdq9bmiRaQI19aSlYk8U6iiw1pTAvHjIu3TWZ9UN wyQw== X-Gm-Message-State: AN3rC/7UbhENWO4h6lx9lcKNdH6hyRTX+ZtcsDQTxWg2dHZTD14F0W4i 9wsuBbVKmV8znw== X-Received: by 10.84.205.70 with SMTP id o6mr976633plh.63.1492571937861; Tue, 18 Apr 2017 20:18:57 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x6sm1003558pge.47.2017.04.18.20.18.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 20:18:57 -0700 (PDT) Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <15e15419-67ca-5033-c53e-a5919079959e@gmail.com> Date: Wed, 19 Apr 2017 15:18:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:19:01 -0000 Mirja, Reassembly takes place in the destination node, which either does or does= n't support ECN. So I don't see your issue: if the node doesn't support ECN, the bits are = ignored anyway. Brian On 19/04/2017 07:42, Mirja Kuehlewind (IETF) wrote: > Hi all, >=20 > sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN s= upport, the reassembled packet should also do that correctly, no matter i= f the nodes support ECN or not. Handling these fields correctly with frag= mentation does not mean that the nodes supports ECN. So this is not optio= nal=E2=80=A6 >=20 > Mirja >=20 >=20 >> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter : >> >> wfm=20 >> On 18/04/2017 09:08, Bob Hinden wrote: >>> Hi, >>> >>> After reading through the discussion, I think a new paragraph (after = the text that says how to construct a reassembled packet) like the follow= ing would be appropriate. >>> >>> Nodes that support Explicit Congestion Notification [RFC3168]= >>> should use information in the Traffic Class field from all >>> fragment packets to reconstruct the Traffic Class field in th= e >>> reassembled packet. See Section 5.3 of RFC3168 for more >>> information. >>> >>> I don=E2=80=99t think we need to quote what RFC3168 says, just point = the the correct section. >>> >>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support ECN= , so it shouldn't be making any new requirements. >>> >>> Comments? >>> >>> Bob >>> >>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter wrote: >>>> >>>> In line... >>>> >>>> On 18/04/2017 05:44, Black, David wrote: >>>>> Extracting the key portions of text: >>>>> >>>>>>> That is inconsistent with the following guidance in RFC 3168 (see= >>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>> >>>>>>> 5.3. Fragmentation >>>>>>> >>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>> congestion. In other words, if any fragment of an IP packet to b= e >>>>>>> reassembled has the CE codepoint set, then one of two actions MUS= T be >>>>>>> taken: >>>>>>> >>>>>>> * Set the CE codepoint on the reassembled packet. However, th= is >>>>>>> MUST NOT occur if any of the other fragments contributing to= >>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>> >>>>>>> * The packet is dropped, instead of being reassembled, for any= >>>>>>> other reason. >>>>>>> >>>>>>> If both actions are applicable, either MAY be chosen. Reassembly= of >>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all of= the >>>>>>> fragments carry the same codepoint. >>>>> >>>>>> Regardless of the answer to that question, my position would be th= at since >>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the hand= ling of >>>>>> the Traffic Class field, the following modification to 2460bis Sec= tion 4.5 >>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>> >>>>>> OLD: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets= >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet. >>>>>> NEW: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets= >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet; however, nodes that support Explicit >>>>>> Congestion Notification [RFC3168] may use information in the >>>>>> Traffic Class field from all fragment packets to reconstruct t= he >>>>>> Traffic Class field in the reassembled packet. >>>>>> >>>>>> Note that this would not cause 2460bis itself to levy an additiona= l >>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It wo= uld >>>>>> simply be making note of a requirement that is already levied by >>>>>> RFC 3168. >>>>> >>>>> In which case, the RFC 3168 requirement should be stated e.g.: >>>>> >>>>> OLD: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained i= n >>>>> the reassembled packet. >>>>> NEW: >>>>> The number and content of the headers preceding the Fragment >>>>> header of different fragments of the same original packet may >>>>> differ. Whatever headers are present, preceding the Fragment >>>>> header in each fragment packet, are processed when the packets >>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>> those headers in the Offset zero fragment packet are retained i= n >>>>> the reassembled packet; however, nodes that support Explicit >>>>> Congestion Notification [RFC3168] may use information in the >>>>> Traffic Class field from any or all fragment packets to reconst= ruct >>>>> the Traffic Class field in the reassembled packet in order to m= eet >>>>> RFC 3168's requirements, e.g., that reassembly not lose indicat= ions >>>>> of congestion, see Section 5.3 of RFC 3168 for additional infor= mation. >>>>> >>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than >>>>> hoping she figures out on her own that she ought to take a look at = it . >>>> >>>> Yes. This is correct. >>>> >>>> Brian >>>> >>>>> >>>>> Thanks, --David >>>>> >>>>>> -----Original Message----- >>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. Hea= rd >>>>>> Sent: Monday, April 17, 2017 12:00 PM >>>>>> To: 6MAN <6man@ietf.org>; tsvwg >>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>>>> ; Mirja Kuehlewind (IETF) ; >>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf-= 6man-rfc2460bis- >>>>>> 09: (with DISCUSS and COMMENT) >>>>>> >>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sect= ion 5.3 ] >>>>>> >>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote:= >>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>>>> ... >>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>> ----------------------------------------------------------= ------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question because I'm not sure if I interpret this corr= ect to >>>>>> make it >>>>>>>>>>>>>> part of my discuss: >>>>>>>>>>>>>> Section 4.5: "The number and content of the headers preced= ing >>>>>> the >>>>>>>>>>>>>> Fragment >>>>>>>>>>>>>> header of different fragments of the same original packet = may >>>>>>>>>>>>>> differ. Whatever headers are present, preceding the Fragm= ent >>>>>>>>>>>>>> header in each fragment packet, are processed when the pac= kets >>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. O= nly >>>>>>>>>>>>>> those headers in the Offset zero fragment packet are retai= ned in >>>>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Clas= s field) >>>>>> is >>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be co= rrect, >>>>>> however, >>>>>>>>>>>>>> also not sure what the correct answer is. I know this was = not >>>>>> changed in >>>>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>>>> >>>>>>>>>>>>> When fragments are created most of the fields are copied fr= om the >>>>>> IPv6 >>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow la= bel, >>>>>> traffic >>>>>>>>>>>>> class, hop limit). Some like payload length, next header, = and hop >>>>>> limi >>>>>>>>>>>>> t are modified. >>>>>>>>>>>>> >>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN c= ode >>>>>> point is >>>>>>>>>>>>> copied from the first fragment, but should be the same from= all of >>>>>> the >>>>>>>>>>>>> fragments. >>>>>>>> >>>>>>>> That is inconsistent with the following guidance in RFC 3168 (se= e >>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>> >>>>>>>> 5.3. Fragmentation >>>>>>>> >>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>>>> reassembled has the CE codepoint set, then one of two actions MU= ST be >>>>>>>> taken: >>>>>>>> >>>>>>>> * Set the CE codepoint on the reassembled packet. However, t= his >>>>>>>> MUST NOT occur if any of the other fragments contributing t= o >>>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>> >>>>>>>> * The packet is dropped, instead of being reassembled, for an= y >>>>>>>> other reason. >>>>>>>> >>>>>>>> If both actions are applicable, either MAY be chosen. Reassembl= y of >>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all o= f >>>>>> the >>>>>>>> fragments carry the same codepoint. >>>>>>>> >>>>>>>>>>>> My concern is that the ECN code point could be changed on on= e of >>>>>> the >>>>>>>>>>>> fragmented packets to signal congestion of a intermediate no= de and >>>>>>>>>>>> then when you reassemble this information gets lost. That se= ems >>>>>> wrong. >>>>>>>>>>> >>>>>>>>>>> That is an interesting idea, but I think out of scope for adv= ancing this >>>>>>>>>>> document to Internet Standard. Then there is the question of= how to >>>>>>>>>>> encode n of m fragments experienced congestion. Interesting = future >>>>>> work. >>>>>>>>>> >>>>>>>>>> Yes there might be some more further work needed but that stil= l >>>>>> makes the >>>>>>>>>> guidance in this text wrong. Maybe we can add some text that t= he >>>>>> Traffic >>>>>>>>>> Class may be handled differently because it could be changed o= n the >>>>>> path. >>>>>>>>> >>>>>>>>> Good point. It's not only ECN that can change; the DSCP can cha= nge too. >>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's log= ical >>>>>>>>> for 2460bis to note this issue. >>>>>>>> >>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not >>>>>> marked >>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 implement= ations >>>>>>>> of ECN, even though it was not written in an IP version-agnostic= manner. >>>>>>>> >>>>>>>> At the very least text should be added to the description of the= >>>>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>>>> successor document. >>>>>>> >>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>>>> reassembling >>>>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think i= f it there is >>>>>>> evidence I agree some text should be added to rfc2460bis, if not,= then >>>>>>> maybe not. >>>>>> >>>>>> Since I lack the expertise to answer that question, I'm hoping tha= t someone >>>>>> in TSVWG will see this message and do so. >>>>>> >>>>>> Regardless of the answer to that question, my position would be th= at since >>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the hand= ling of >>>>>> the Traffic Class field, the following modification to 2460bis Sec= tion 4.5 >>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>> >>>>>> OLD: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets= >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet. >>>>>> NEW: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets= >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>> the reassembled packet; however, nodes that support Explicit >>>>>> Congestion Notification [RFC3168] may use information in the >>>>>> Traffic Class field from all fragment packets to reconstruct t= he >>>>>> Traffic Class field in the reassembled packet. >>>>>> >>>>>> Note that this would not cause 2460bis itself to levy an additiona= l >>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It wo= uld >>>>>> simply be making note of a requirement that is already levied by >>>>>> RFC 3168. >>>>>> >>>>>> Thanks and regards, >>>>>> >>>>>> Mike Heard >>>>> >>>>> -------------------------------------------------------------------= - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= >>>>> -------------------------------------------------------------------= - >>>>> >>>> >>> >> >=20 >=20 From nobody Tue Apr 18 21:02:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F21D1200DF; Tue, 18 Apr 2017 21:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 dfC1IO2hCfgR; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 CE56D126CF6; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id a188so1855081pfa.2; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=mSVkhc1P+UMjd3DjE5jqKdcSammtpfVLakd3nXTMT540l58gVqvLKEexMgf36dGmMA hCuxoqkYKX3YnN10dVHa4Iqt+uyURq+5iylXoEz4F9wFPMJHUjqBxpUvzbQZYalvjDrc mWkTnNqy8Y/htKqRQ5A0/EmAbYj5taQFPt8tgxIOoWMvyfV2tJVhGAxTQLpdZsKH0nST R1N2CCbHXbOasN2gjt25KHQ9oY6/lCpxHu8usNE10WGsVdEeO9cDd8/zZUoVUO9aASpc WEq2STns6c8l9SKolxaAmFNjYr0uLfTtFNI0kOJYUXMML1hkOaLoXUZgFA1lg9KmrIwj QOvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4+RnCCMSY4QLUn2YKL6B+5CQfjMeD0F85oDxQGe3etI=; b=efjBoGMB5cSxJT76wPDUIw/OweQXNExN24rg06bwt9xfqd52eCSC+R4oF2+IjPRaYs t3a+0KXvIDGogI6qeb882Vm+00v9lzA5fjx/4sdH5AjN1o0k9wZk/rOkwAubgnWxpa+7 /6fA4MnO5EdNAsQVmJ2OAEouWCzxguNn2FB7PWLmhPvFz3onEdzICfQNSQw6SCaHav71 cIV5lTxbes5g9pZg3ahBpsy75lt6v9VcITCfo0P0qZy9qNqo/tQ2+fpb7MMEaLG7c5JM Xa0Sjfo+QpvcN45HzNGeDRJDCEiSn7UNEimMc02dd6ZrAJ89+jqE7QkwYD+SLV6AM1Pp BQzQ== X-Gm-Message-State: AN3rC/4urD4XNhjybd9dyP28dy+CXroVSTKqFPjkqyn55YFDLE5I/v2q W8qtNEMbwVlW8A== X-Received: by 10.98.71.202 with SMTP id p71mr899509pfi.39.1492574576291; Tue, 18 Apr 2017 21:02:56 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m4sm1152766pfi.74.2017.04.18.21.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:02:55 -0700 (PDT) Subject: ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] To: Gunter Van De Velde , "opsec@ietf.org" References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> Cc: Lorenzo Colitti , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 16:02:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:02:58 -0000 There are several issues in this section, not just the NAT: > 2.1.2. Use of ULAs > > ULAs are intended for scenarios where IP addresses will not have > global scope so they should not appear in the global BGP routing > table. We need to align that with the clarification in draft-bchv-rfc6890bis: ULAs are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. > ULAs could be useful for infrastructure hiding as described in > RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 > [RFC7404] could also be used. LL addresses don't help if you have multiple LANs. I suggest simply deleting the second sentence; it will confuse people. > Although ULAs are supposed to be used > in conjunction with global addresses for hosts that desire external > connectivity Change that to ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Then I suggest deleting *all* the rest of the section, but add this at the end: Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Thus the whole section would read (with a little more editing): 2.1.2. Use of Unique Local Addresses Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where IP addresses are not globally reachable, despite formally having global scope. They must not appear in the routing system outside the administrative domain where they are considered valid. Therefore, packets with ULA source and/or destination addresses MUST be filtered at the domain boundary. ULAs are assigned within pseudo-random /48 prefixes created as specified in [RFC4193]. They could be useful for infrastructure hiding as described in [RFC4864]. ULAs may be used for internal communication, in conjunction with globally reachable unicast addresses (GUAs) for hosts that also require external connectivity through a firewall. For this reason, no form of address translation is required in conjunction with ULAs. Using ULAs as described here might simplify the filtering rules needed at the domain boundary, by allowing a regime in which only hosts that require external connectivity possess a globally reachable address. However, this does not remove the need for careful design of the filtering rules. Brian From nobody Tue Apr 18 21:17:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A971279E5; Tue, 18 Apr 2017 21:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 aPKfj2O7rzvz; Tue, 18 Apr 2017 21:17:25 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 1193E1200DF; Tue, 18 Apr 2017 21:17:25 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id o123so2148494pga.1; Tue, 18 Apr 2017 21:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cMdLbycZG6F7GqLkh3PumTofjsZDPp86gwy2Fp3LJvw=; b=K3y/c08QWRgNObaVXTVUK3jzTWtkVKDAK3+7bOHax2wR9HwLRQOeCkM87muZcuUF21 gJXMYvJwFWii/1YJaGPs7RTL8llWn0zzuo1Pnpm5UhKWRA9bVcQqD1Bo0U4QrjwCx8No fKGlgzr7IkqN3SMCyh31TLhkHGPsRr2gr2Uqr+RNKW/TZ6vmbVgNyWD98ZG0mWbArwbA ZN4xfDFANSL20rPIHQikXC7nxay5tYu0NxG/weQoSMEwciRpOQ2iAOExkSP+HMzgvu7U XYOCqfUo2hJ1emO4nFYSGv3DT2QbARueqM99DapDzPwqZuEv28cE9fW43BNCg1kyQIYy OB+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cMdLbycZG6F7GqLkh3PumTofjsZDPp86gwy2Fp3LJvw=; b=EE1Fg/VC18oF0Mjjelgv399fCFSdbctwhziGp72tglry4nQbJItQJeOJ+vrWSCPDQ5 HYludqrlf277URXozj8idyI3f2LkxoFVb1LZvzxOnISMML7Pmngfr8BPmCTInjXVNJ2Q hXeeB21k1tSd8TJmKVu6pvpXxXyPNwak8/MajHyOQyUbHQdDWMjaCSP5mASnALsNaUBx 0pON5CX5RcdFaeFbjBbYAvUOCdmS1e/qZd6C0axILjY6so50dGB/iKi7qHbyFWZ/7lhA HnUOFktZPKHPh41xiu+MhWLxUlcdnnMqnFXy46fq+mB32cllYwyYaHG2P22XQFf9SFTk D9hQ== X-Gm-Message-State: AN3rC/4jP3BB7l0S+Zibwhlp7yCSWbItvdFNvkQ2lScTPbFHhL9QTKLT BSFU1i3Rix0YHpF/ X-Received: by 10.84.236.8 with SMTP id q8mr1241444plk.104.1492575444428; Tue, 18 Apr 2017 21:17:24 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id n67sm1232069pfk.44.2017.04.18.21.17.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:17:23 -0700 (PDT) Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com> Date: Wed, 19 Apr 2017 16:17:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:17:28 -0000 On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote: > Hi again, >=20 > I should probably have been more constructive here. I=E2=80=99d like to= propose the following text: >=20 > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet; however, the Traffic Class field from=20 > any or all fragments may differ. Handling of Explicit > Congestion Notification [RFC3168] is described in Section 5.3 of=20 > RFC 3168, ensuring that reassembly does not lose indications > of congestion. >=20 > Do we also need to say something about DiffServ? I think not. The existing text says that the DSCP bits in the first fragment, win and that's fine. If one of the later fragments has been re-marked for some reason, there is no reason to take any notice. (Specifically: we can assume that the transport header is in the first fragment, and any meaningful re-marking would be based on the transport header. Any re-marking of the later fragments is bogus.) Brian > Mirja >=20 >=20 >=20 >=20 >> Am 18.04.2017 um 21:42 schrieb Mirja Kuehlewind (IETF) : >> >> Hi all, >> >> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN = support, the reassembled packet should also do that correctly, no matter = if the nodes support ECN or not. Handling these fields correctly with fra= gmentation does not mean that the nodes supports ECN. So this is not opti= onal=E2=80=A6 >> >> Mirja >> >> >>> Am 18.04.2017 um 02:38 schrieb Brian E Carpenter : >>> >>> wfm=20 >>> On 18/04/2017 09:08, Bob Hinden wrote: >>>> Hi, >>>> >>>> After reading through the discussion, I think a new paragraph (after= the text that says how to construct a reassembled packet) like the follo= wing would be appropriate. >>>> >>>> Nodes that support Explicit Congestion Notification [RFC3168]= >>>> should use information in the Traffic Class field from all >>>> fragment packets to reconstruct the Traffic Class field in th= e >>>> reassembled packet. See Section 5.3 of RFC3168 for more >>>> information. >>>> >>>> I don=E2=80=99t think we need to quote what RFC3168 says, just point= the the correct section. >>>> >>>> This also doesn=E2=80=99t effect nodes that don=E2=80=99t support EC= N, so it shouldn't be making any new requirements. >>>> >>>> Comments? >>>> >>>> Bob >>>> >>>>> On Apr 17, 2017, at 12:58 PM, Brian E Carpenter wrote: >>>>> >>>>> In line... >>>>> >>>>> On 18/04/2017 05:44, Black, David wrote: >>>>>> Extracting the key portions of text: >>>>>> >>>>>>>> That is inconsistent with the following guidance in RFC 3168 (se= e >>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>> >>>>>>>> 5.3. Fragmentation >>>>>>>> >>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>>> congestion. In other words, if any fragment of an IP packet to = be >>>>>>>> reassembled has the CE codepoint set, then one of two actions MU= ST be >>>>>>>> taken: >>>>>>>> >>>>>>>> * Set the CE codepoint on the reassembled packet. However, th= is >>>>>>>> MUST NOT occur if any of the other fragments contributing to= >>>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>> >>>>>>>> * The packet is dropped, instead of being reassembled, for any= >>>>>>>> other reason. >>>>>>>> >>>>>>>> If both actions are applicable, either MAY be chosen. Reassembl= y of >>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all o= f the >>>>>>>> fragments carry the same codepoint. >>>>>> >>>>>>> Regardless of the answer to that question, my position would be t= hat since >>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the han= dling of >>>>>>> the Traffic Class field, the following modification to 2460bis Se= ction 4.5 >>>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>>> >>>>>>> OLD: >>>>>>> The number and content of the headers preceding the Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets= >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet. >>>>>>> NEW: >>>>>>> The number and content of the headers preceding the Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets= >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet; however, nodes that support Explicit >>>>>>> Congestion Notification [RFC3168] may use information in the >>>>>>> Traffic Class field from all fragment packets to reconstruct t= he >>>>>>> Traffic Class field in the reassembled packet. >>>>>>> >>>>>>> Note that this would not cause 2460bis itself to levy an addition= al >>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It w= ould >>>>>>> simply be making note of a requirement that is already levied by >>>>>>> RFC 3168. >>>>>> >>>>>> In which case, the RFC 3168 requirement should be stated e.g.: >>>>>> >>>>>> OLD: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained i= n >>>>>> the reassembled packet. >>>>>> NEW: >>>>>> The number and content of the headers preceding the Fragment >>>>>> header of different fragments of the same original packet may >>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>> header in each fragment packet, are processed when the packets >>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>> those headers in the Offset zero fragment packet are retained i= n >>>>>> the reassembled packet; however, nodes that support Explicit >>>>>> Congestion Notification [RFC3168] may use information in the >>>>>> Traffic Class field from any or all fragment packets to reconst= ruct >>>>>> the Traffic Class field in the reassembled packet in order to m= eet >>>>>> RFC 3168's requirements, e.g., that reassembly not lose indicat= ions >>>>>> of congestion, see Section 5.3 of RFC 3168 for additional infor= mation. >>>>>> >>>>>> Pointing the implementer at Section 5.3 of RFC 3168 is better than= >>>>>> hoping she figures out on her own that she ought to take a look at= it . >>>>> >>>>> Yes. This is correct. >>>>> >>>>> Brian >>>>> >>>>>> >>>>>> Thanks, --David >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of C. M. He= ard >>>>>>> Sent: Monday, April 17, 2017 12:00 PM >>>>>>> To: 6MAN <6man@ietf.org>; tsvwg >>>>>>> Cc: draft-ietf-6man-rfc2460bis@ietf.org; Bob Hinden >>>>>>> ; Mirja Kuehlewind (IETF) ; >>>>>>> IESG ; 6man Chairs <6man-chairs@ietf.org> >>>>>>> Subject: Re: [tsvwg] Mirja K=C3=BChlewind's Discuss on draft-ietf= -6man-rfc2460bis- >>>>>>> 09: (with DISCUSS and COMMENT) >>>>>>> >>>>>>> [ TSVWG added to solicit advice on implementation of RFC 3186 Sec= tion 5.3 ] >>>>>>> >>>>>>> On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote: >>>>>>>> On Apr 15, 2017, at 4:53 AM, C. M. Heard wrote= : >>>>>>>>> On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote: >>>>>>>>>> On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote: >>>>>>>>>> ... >>>>>>>>>>>>>>> ---------------------------------------------------------= ------------- >>>>>>>>>>>>>>> COMMENT: >>>>>>>>>>>>>>> ---------------------------------------------------------= ------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One question because I'm not sure if I interpret this cor= rect to >>>>>>> make it >>>>>>>>>>>>>>> part of my discuss: >>>>>>>>>>>>>>> Section 4.5: "The number and content of the headers prece= ding >>>>>>> the >>>>>>>>>>>>>>> Fragment >>>>>>>>>>>>>>> header of different fragments of the same original packet= may >>>>>>>>>>>>>>> differ. Whatever headers are present, preceding the Frag= ment >>>>>>>>>>>>>>> header in each fragment packet, are processed when the pa= ckets >>>>>>>>>>>>>>> arrive, prior to queueing the fragments for reassembly. = Only >>>>>>>>>>>>>>> those headers in the Offset zero fragment packet are reta= ined in >>>>>>>>>>>>>>> the reassembled packet." >>>>>>>>>>>>>>> Does this mean the ECN codepoint (part of the Traffic Cla= ss field) >>>>>>> is >>>>>>>>>>>>>>> copied from the first fragment? This doesn't seem to be c= orrect, >>>>>>> however, >>>>>>>>>>>>>>> also not sure what the correct answer is. I know this was= not >>>>>>> changed in >>>>>>>>>>>>>>> this revision but maybe we can still get this right. >>>>>>>>>>>>>> >>>>>>>>>>>>>> When fragments are created most of the fields are copied f= rom the >>>>>>> IPv6 >>>>>>>>>>>>>> headers (e.g., Source Address, Destination address, flow l= abel, >>>>>>> traffic >>>>>>>>>>>>>> class, hop limit). Some like payload length, next header,= and hop >>>>>>> limi >>>>>>>>>>>>>> t are modified. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If I understand your question, the answer is yes, the ECN = code >>>>>>> point is >>>>>>>>>>>>>> copied from the first fragment, but should be the same fro= m all of >>>>>>> the >>>>>>>>>>>>>> fragments. >>>>>>>>> >>>>>>>>> That is inconsistent with the following guidance in RFC 3168 (s= ee >>>>>>>>> https://tools.ietf.org/html/rfc3168#section-5.3): >>>>>>>>> >>>>>>>>> 5.3. Fragmentation >>>>>>>>> >>>>>>>>> ECN-capable packets MAY have the DF (Don't Fragment) bit set. >>>>>>>>> Reassembly of a fragmented packet MUST NOT lose indications of >>>>>>>>> congestion. In other words, if any fragment of an IP packet to= be >>>>>>>>> reassembled has the CE codepoint set, then one of two actions M= UST be >>>>>>>>> taken: >>>>>>>>> >>>>>>>>> * Set the CE codepoint on the reassembled packet. However, t= his >>>>>>>>> MUST NOT occur if any of the other fragments contributing t= o >>>>>>>>> this reassembly carries the Not-ECT codepoint. >>>>>>>>> >>>>>>>>> * The packet is dropped, instead of being reassembled, for an= y >>>>>>>>> other reason. >>>>>>>>> >>>>>>>>> If both actions are applicable, either MAY be chosen. Reassemb= ly of >>>>>>>>> a fragmented packet MUST NOT change the ECN codepoint when all = of >>>>>>> the >>>>>>>>> fragments carry the same codepoint. >>>>>>>>> >>>>>>>>>>>>> My concern is that the ECN code point could be changed on o= ne of >>>>>>> the >>>>>>>>>>>>> fragmented packets to signal congestion of a intermediate n= ode and >>>>>>>>>>>>> then when you reassemble this information gets lost. That s= eems >>>>>>> wrong. >>>>>>>>>>>> >>>>>>>>>>>> That is an interesting idea, but I think out of scope for ad= vancing this >>>>>>>>>>>> document to Internet Standard. Then there is the question o= f how to >>>>>>>>>>>> encode n of m fragments experienced congestion. Interesting= future >>>>>>> work. >>>>>>>>>>> >>>>>>>>>>> Yes there might be some more further work needed but that sti= ll >>>>>>> makes the >>>>>>>>>>> guidance in this text wrong. Maybe we can add some text that = the >>>>>>> Traffic >>>>>>>>>>> Class may be handled differently because it could be changed = on the >>>>>>> path. >>>>>>>>>> >>>>>>>>>> Good point. It's not only ECN that can change; the DSCP can ch= ange too. >>>>>>>>>> Both RFC2474 (diffserv) and ECN came after RFC2460, so it's lo= gical >>>>>>>>>> for 2460bis to note this issue. >>>>>>>>> >>>>>>>>> It seems that we (6man WG) missed this because RFC 3168 was not= >>>>>>> marked >>>>>>>>> as updating RFC 2460. But in effect it did so for IPv6 implemen= tations >>>>>>>>> of ECN, even though it was not written in an IP version-agnosti= c manner. >>>>>>>>> >>>>>>>>> At the very least text should be added to the description of th= e >>>>>>>>> reassembly process that points the reader to RFC 3168 or its >>>>>>>>> successor document. >>>>>>>> >>>>>>>> Do we have any evidence that the guidance in RFC 3168 regarding >>>>>>> reassembling >>>>>>>> IPv6 fragments is implemented? I don=E2=80=99t know, but think = if it there is >>>>>>>> evidence I agree some text should be added to rfc2460bis, if not= , then >>>>>>>> maybe not. >>>>>>> >>>>>>> Since I lack the expertise to answer that question, I'm hoping th= at someone >>>>>>> in TSVWG will see this message and do so. >>>>>>> >>>>>>> Regardless of the answer to that question, my position would be t= hat since >>>>>>> 2460bis already defers to RFC 2474 and RFC 3168 regarding the han= dling of >>>>>>> the Traffic Class field, the following modification to 2460bis Se= ction 4.5 >>>>>>> would be an appropriate way to deal with Mirja's comment: >>>>>>> >>>>>>> OLD: >>>>>>> The number and content of the headers preceding the Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets= >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet. >>>>>>> NEW: >>>>>>> The number and content of the headers preceding the Fragment >>>>>>> header of different fragments of the same original packet may >>>>>>> differ. Whatever headers are present, preceding the Fragment >>>>>>> header in each fragment packet, are processed when the packets= >>>>>>> arrive, prior to queueing the fragments for reassembly. Only >>>>>>> those headers in the Offset zero fragment packet are retained = in >>>>>>> the reassembled packet; however, nodes that support Explicit >>>>>>> Congestion Notification [RFC3168] may use information in the >>>>>>> Traffic Class field from all fragment packets to reconstruct t= he >>>>>>> Traffic Class field in the reassembled packet. >>>>>>> >>>>>>> Note that this would not cause 2460bis itself to levy an addition= al >>>>>>> requirement on how IPv6 nodes reassemble fragmented packets. It w= ould >>>>>>> simply be making note of a requirement that is already levied by >>>>>>> RFC 3168. >>>>>>> >>>>>>> Thanks and regards, >>>>>>> >>>>>>> Mike Heard >>>>>> >>>>>> ------------------------------------------------------------------= -- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >>>>>> ------------------------------------------------------------------= -- >>>>>> >>>>> >>>> >>> >> >=20 >=20 From nobody Tue Apr 18 21:29:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033C0127B73; Tue, 18 Apr 2017 21:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 W3F6rgDnnLWn; Tue, 18 Apr 2017 21:29:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9137126579; Tue, 18 Apr 2017 21:29:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3079082E5E; Wed, 19 Apr 2017 00:29:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=mWE8mv1Zj6Hc Bz0EVednVFgyVDc=; b=JOhEKvaTq7cU1ndX4+IPGYkoS0FI87alGqOHzpiZKPGn jqBNmMiWpeZCxGSsHoXug5ksRH1ybfvkQHdNpCHGD+p2YRNB0L41/aLB6ySU5WsV c6djpNYANZ7qSC5viqPX4tATd94sYE8OrnVKZSQHNhCPOPnlcxeCoIZPnfQ7Fx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=EF0nZN KGN8yM5yzQRgg8z6P0jgUStKSP8lTsSVd3zdkv88YomdF4SYU0X19ZCFI57WlaSV /yIwLoi5E3ymlobf+9fCqLXBXlOawaitkz6qo9KiLDucKbIYcoO14d2js2FyiV5U toz3m/RNQ3eTilp624mIBYqLAopvehuaQghHk= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 217F382E5D; Wed, 19 Apr 2017 00:29:33 -0400 (EDT) Received: from mail-qt0-f173.google.com (unknown [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 9136B82E59; Wed, 19 Apr 2017 00:29:32 -0400 (EDT) Received: by mail-qt0-f173.google.com with SMTP id c45so10352029qtb.1; Tue, 18 Apr 2017 21:29:32 -0700 (PDT) X-Gm-Message-State: AN3rC/6VGujNdz/v1uAzWoBKI7hYx14AUc6LRsHbO84aFFHG4NvNA6xR iwVNURg2HN3b3smxxTV9PFMjx3+RFg== X-Received: by 10.200.47.91 with SMTP id k27mr676220qta.11.1492576172151; Tue, 18 Apr 2017 21:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Tue, 18 Apr 2017 21:29:11 -0700 (PDT) In-Reply-To: <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com> References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com> From: "C. M. Heard" Date: Tue, 18 Apr 2017 21:29:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Brian E Carpenter Cc: "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: C9311084-24B8-11E7-AFBF-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:29:36 -0000 On Tue, Apr 18, 2017 at 9:17 PM, Brian E Carpenter wrote: > On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote: >> Hi again, >> >> I should probably have been more constructive here. I=E2=80=99d like to = propose the following text: >> >> The number and content of the headers preceding the Fragment >> header of different fragments of the same original packet may >> differ. Whatever headers are present, preceding the Fragment >> header in each fragment packet, are processed when the packets >> arrive, prior to queueing the fragments for reassembly. Only >> those headers in the Offset zero fragment packet are retained in >> the reassembled packet; however, the Traffic Class field from >> any or all fragments may differ. Handling of Explicit >> Congestion Notification [RFC3168] is described in Section 5.3 of >> RFC 3168, ensuring that reassembly does not lose indications >> of congestion. >> >> Do we also need to say something about DiffServ? > > I think not. The existing text says that the DSCP bits in the first > fragment, win and that's fine. If one of the later fragments has been > re-marked for some reason, there is no reason to take any notice. > > (Specifically: we can assume that the transport header is in the first > fragment, and any meaningful re-marking would be based on the transport > header. Any re-marking of the later fragments is bogus.) Do end systems even care what the DSCP bits are? //cmh From nobody Tue Apr 18 21:34:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E445D12943F; Tue, 18 Apr 2017 21:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 sQ57vRX1O0X2; Tue, 18 Apr 2017 21:34:07 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 5E3AD127B73; Tue, 18 Apr 2017 21:34:07 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id g2so2199728pge.2; Tue, 18 Apr 2017 21:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=EkX5B6tX6R4q65+UkDL/ysQOrZV3MRQRQnHMleRXoXA=; b=W4vnZ2/NBWhKb9+WQ9IoplIkYOVc7i6pcF+Anjr1RLt3kGRGsHpzk0Bh1J5QuYnOlr LCQ0wFCoP8tbasDBLBDkK5O8Zp/yRpOkhq3R+X7qYXMtcsrwqOXXVgRWEb4fPDL9rO9t lqU3gIHv1mMQWQidbxzQbXK9LQNqiXZ6YBh9Z484X5n3U21H2RiPZ8pQZFlj1HJPSr9D 9hviIIyjuaXa71TKKNYuH/A5gBg6Pq92IpUROMejSEZAB7JsOkqzQ3YO5qpeEgeHYfwv HEV4xdJdabuxt6Fw2wv3Woz3h0H/MYQjHMsqVAsFtB3pDnunP4SRO30V7di/5Xzn11JS tlBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EkX5B6tX6R4q65+UkDL/ysQOrZV3MRQRQnHMleRXoXA=; b=dGxt0/CWsNV9xGJ8VHCn1IJYIHbZ75CHzwsa5oZAZqdCULHu38BYFERWpYZ7UzoNKN PIWVSSsgiCcZPEMOxGLtevGSes2/+8HMV5etWIKXzJ+oLFgxFkKaU2tiEcCjShGTHDRt 1u8UEaiImrroiQdDGhjkLUff1WgKTMng8PxLbSsiPHibR+Ujt/AgNopSU3m4x+rOfu61 snhI+6d8w22kHuvYZlZp+uLceO7oxeA9H6n8yyNCuBeCGtmAO++i0e+z0Pkk0KgTCFyB Bd3ZNOUKBSGixvj3df+ZDX6/znCxdZJDFmn8OO6CnXbP4FM+E26MFTZVC5t1jSfdm62B ICsw== X-Gm-Message-State: AN3rC/7Zp3TsPFuMWpMydX0JFqcReyMdmI6dXdV9m03IBhd9OLFZgGL0 WLk1ppg2B9YRJg== X-Received: by 10.99.99.2 with SMTP id x2mr987469pgb.46.1492576447012; Tue, 18 Apr 2017 21:34:07 -0700 (PDT) Received: from ?IPv6:2406:e001:5724:1:28cc:dc4c:9703:6781? ([2406:e001:5724:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x9sm1296525pff.98.2017.04.18.21.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 21:34:06 -0700 (PDT) Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "C. M. Heard" References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> <4123b311-7dbb-0d17-9534-388a4477d280@gmail.com> Cc: "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , "Black, David" , IESG , 6man Chairs <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <21ac4ad4-5858-7cc8-4b21-808c292f72c5@gmail.com> Date: Wed, 19 Apr 2017 16:34:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 04:34:09 -0000 On 19/04/2017 16:29, C. M. Heard wrote: > On Tue, Apr 18, 2017 at 9:17 PM, Brian E Carpenter wrote: >> On 19/04/2017 12:51, Mirja Kuehlewind (IETF) wrote: >>> Hi again, >>> >>> I should probably have been more constructive here. I=E2=80=99d like = to propose the following text: >>> >>> The number and content of the headers preceding the Fragment >>> header of different fragments of the same original packet may >>> differ. Whatever headers are present, preceding the Fragment >>> header in each fragment packet, are processed when the packets >>> arrive, prior to queueing the fragments for reassembly. Only >>> those headers in the Offset zero fragment packet are retained in >>> the reassembled packet; however, the Traffic Class field from >>> any or all fragments may differ. Handling of Explicit >>> Congestion Notification [RFC3168] is described in Section 5.3 of >>> RFC 3168, ensuring that reassembly does not lose indications >>> of congestion. >>> >>> Do we also need to say something about DiffServ? >> >> I think not. The existing text says that the DSCP bits in the first >> fragment, win and that's fine. If one of the later fragments has been >> re-marked for some reason, there is no reason to take any notice. >> >> (Specifically: we can assume that the transport header is in the first= >> fragment, and any meaningful re-marking would be based on the transpor= t >> header. Any re-marking of the later fragments is bogus.) >=20 > Do end systems even care what the DSCP bits are? Yes, definitely if they're a tunnel end point (RFC 2983), and possibly if they want to do some sort of input-buffer queue management for real time traffic. Brian From nobody Tue Apr 18 23:49:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA25131527 for ; Tue, 18 Apr 2017 23:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 QLlDkVf3-EV3 for ; Tue, 18 Apr 2017 23:49:08 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882AD131529 for <6man@ietf.org>; Tue, 18 Apr 2017 23:49:07 -0700 (PDT) Received: (qmail 5774 invoked from network); 19 Apr 2017 08:49:05 +0200 Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Apr 2017 08:49:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D__Mirja_K=C3=BChlewind=27s_Discuss_on_?= =?utf-8?Q?draft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 19 Apr 2017 08:49:04 +0200 Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <754272E0-1DF9-4821-9111-A3AC7F691B7A@kuehlewind.net> References: <4875cabd-3529-418a-d70b-99f29560a79c@gmail.com> <5ecd436d-0466-94ad-4c9e-6dcbf27be53f@gmail.com> <6D7A1FEE-6EF2-4058-AFB3-A77177B68D5C@kuehlewind.net> To: "C. M. Heard" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 06:49:09 -0000 Yes and no. Of course if ECN is not supported, packet should not be ECN = marked. However, the IP layer might actually not know if is supported or = not (e.g. a UDP based protocol that is implemented in user-spaces that = uses ECN) and therefore my thinking is that it should reassemble the ECN = field correctly if ECN was set not matter what.=20 Mirja > Am 19.04.2017 um 05:04 schrieb C. M. Heard : >=20 > On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote: >> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN = support, >> the reassembled packet should also do that correctly, no matter if >> the nodes support ECN or not. Handling these fields correctly with >> fragmentation does not mean that the nodes supports ECN. So this is >> not optional=E2=80=A6 >=20 > This seems confused (or else I am confused). We are discussing issues > related to reassembly of fragmented packets, and that is a process = that > takes place in end systems only, not in forwarding nodes. >=20 > It is true that if an end system (aka host) supports ECN per RFC 3168, > then received packets that it reassembles must have the CE bit pattern > set if any fragment has the CE bit pattern set, provided that all > fragments contain either CE or ECT(0)/ECT(1). The text that we are > working on is intended to say that -- indirectly, by referring to the > Section 5.3 of RFC 3168. >=20 > But, unless ECN is mandatory-to-implement for all IPv6 nodes, end > systems are not obliged to support it -- and I see no such mandate > in the IPv6 node requirements document. In that case ECN indications > will simply be ignored. No purpose is served by levying a requirement > on the IPv6 module to preserve an indication that will not be used. >=20 > Mike Heard >=20 From nobody Wed Apr 19 00:01:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B79131527 for ; Wed, 19 Apr 2017 00:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7-aqh7_cXc84 for ; Wed, 19 Apr 2017 00:01:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184D012EC67 for ; Wed, 19 Apr 2017 00:01:02 -0700 (PDT) Received: (qmail 5984 invoked from network); 19 Apr 2017 08:54:19 +0200 Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Apr 2017 08:54:19 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> Date: Wed, 19 Apr 2017 08:54:17 +0200 Cc: Suresh Krishnan , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:01:05 -0000 The difference for me it that in one case a condition is specified, = while the other one is a general statememt. > Am 19.04.2017 um 05:15 schrieb Brian E Carpenter = : >=20 > In reality "MUST NOT unless..." means about the same as "SHOULD NOT" = so > I think we agree that this is editorial. Aligning the language with = RFC6564 > makes a lot of sense to me. >=20 > Brian > On 19/04/2017 07:58, Mirja Kuehlewind (IETF) wrote: >> sorry it=E2=80=99s late here=E2=80=A6 >>=20 >> s/formation/formulation/ >> s/no go advice/no good advice/ >>=20 >>> Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) = : >>>=20 >>> This might be rather an editorial issue now but the formation in = RFC6564 is fully fine with me because it says =E2=80=9EMUST NOT unless = no option can be used=E2=80=9C. That=E2=80=99s basically what I = proposed. The formulation in 2460 however is "Defining new IPv6 = extension headers is not recommended.=E2=80=9C. I think this is = overstated and technically no go advise. >>>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan = : >>>>=20 >>>> Hi Mirja/Bob, >>>>=20 >>>>=20 >>>> On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden = wrote: >>>>> Hi, >>>>>=20 >>>>>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>>>>=20 >>>>>> Brian, Mirja, >>>>>>=20 >>>>>>>>> This combination of circumstances creates a "Catch-22" = situation >>>>>>>>> [Heller] for the deployment of any newly standardised = extension >>>>>>>>> header except for local use. It cannot be widely deployed = because >>>>>>>>> existing middleboxes will drop it on many paths through the = Internet. >>>>>>>>> However, most middleboxes will not be updated to allow the new = header >>>>>>>>> to pass until it has been proved safe and useful on the open >>>>>>>>> Internet, which is impossible until the middleboxes have been >>>>>>>>> updated. >>>>>>>>>=20 >>>>>>>>> So, defining new IPv6 extension headers is not recommended, = because >>>>>>>>> they probably won't work across the Internet. But it isn't a = MUST NOT, >>>>>>>>> because if there was a compelling operational case, we could = do it and >>>>>>>>> the middleboxes would follow. >>>>>>>>=20 >>>>>>>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>>>>>>=20 >>>>>>>> I think I agree that I would not like to make a normative = statement here, given that the circumstances are not due to the protocol = design itself but because of the current deployment situation we have = (which in theory could change in future). >>>>>>>>=20 >>>>>>>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>>>>>>=20 >>>>>>>> Maybe you can work on some new text and then have a quick (?) = check with the wg which text is preferred. If there is clear consensus = for one way by the wg I will not further block this. >>>>>>>=20 >>>>>>> I think I will leave that for the document editor. A large part = of RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >>>>>>=20 >>>>>> I think what is in the document already is representing the = working group consensus. >>>>>> The issues of new / unknown extension headers, and how to = distinguish these from new transport protocols have been discussed from = many angles. The two main reasons for the strong recommendation against = new extension headers are: >>>>>> - most uses are already accommodated with the 3 existing = containers options (routing. hbh and destination) >>>>>> - sharing the same number space with IP protocols, makes it hard = for intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >>>>>>=20 >>>>>> There is already an opening / provision in the text for new = extension headers. The text only asks for these considerations to be = made, before proposing new ones. >>>>>=20 >>>>> I agree. >>>>>=20 >>>>> I also note that the text in this section was derived from = RFC6564, which updated RFC2460. Specifically from Section 3 of RFC6564: >>>>>=20 >>>>> Mindful of the need for compatibility with existing IPv6 = deployments, >>>>> new IPv6 extension headers MUST NOT be created or specified, = unless >>>>> no existing IPv6 extension header can be used by specifying a new >>>>> option for that existing IPv6 extension header. >>>>=20 >>>> Yes. This text was arrived at after a lot of discussion in the 6man = WG >>>> during the development of the draft that became RFC6564. >>>>=20 >>>>>=20 >>>>> New extension headers are allowed (just not recommended) and the = next paragraph in the Section specifies a format that should be used for = new Extension headers. I think there is a lot of flexibility going = forward. >>>>=20 >>>> Yep. I think the above warning is issued because a node processing = an >>>> unknown extension header will simply drop it, and this makes >>>> incremental deployability of these new extension headers difficult >>>> over the Internet. >>>>=20 >>>> Thanks >>>> Suresh >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Wed Apr 19 04:31:45 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F31294AB; Wed, 19 Apr 2017 04:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6man-rfc2?= =?utf-8?q?460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149260150373.29068.14422326644573949515.idtracker@ietfa.amsl.com> Date: Wed, 19 Apr 2017 04:31:43 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 11:31:44 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-6man-rfc2460bis-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm changing this discuss because I believe changes regarding any text in section 4.8 would mostly be editorial at this point if any. I would still like to see more background information explaining the situation and risks, rather than just giving a general recommendation that might even out-date in cases routers get updated accordingly in future. However, I holding this discuss, because the ECN issue I originally only raised as a question in the comment section really needs to be addressed. Hope to wrap this up soon. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My discuss was mainly on text in section 4.8 (also based on the tsv-art review -> Thanks Martin!): I find the recommendation to basically just not use hop-by-hop headers in section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it be maybe time to just deprecate the current hop-by-hop number an assign a new one? I know that also has deployment problem but maybe it's worth a try. I guess the assignment could happen in a new document though, but the deprecation could be done here. This related to this comment from Martin's review, also proposing a potential way forward: "- Section 4.8. "Defining New Extension Headers and Options": It says new hop-by-hop headers must never ever defined. This is problematic, as this closing the door forever, even if future instances of the IETF do would like to wish to define new hop-by-hop headers. A better way would have to say "that new hop-by-hop headers must have IETF consensus". - Section 4.8. "Defining New Extension Headers and Options": Also the „not recommended“ to define new extension headers looks strange, especially with the phrase "There has to be a very clear justification". The term "clear justification" is not an exact engineering specification. Why not using "technical protocol specification and real word use case required, plus IETF consensus"?" As a side note, there is at least one experimental RFC that defines a destination option to be inspected by a network device, given the know problems of hop-by-hop option which renders them unusable. One question because I'm not sure if I interpret this correct to make it part of my discuss: Section 4.5: "The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet." Does this mean the ECN codepoint (part of the Traffic Class field) is copied from the first fragment? This doesn't seem to be correct, however, also not sure what the correct answer is. I know this was not changed in this revision but maybe we can still get this right. From nobody Wed Apr 19 06:27:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B11127275 for ; Wed, 19 Apr 2017 06:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL2oBtYBZ-7X for ; Wed, 19 Apr 2017 06:27:17 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 2F4C812957C for <6man@ietf.org>; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id f133so19688710qke.2 for <6man@ietf.org>; Wed, 19 Apr 2017 06:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=M9zKJPhsqnK8XNWEIzvBfJUXP6S+47Nf6ziojRxNMLmY1v6NCvYNjkTdrAs14dGcT4 zyu7+CE/01crye0d2c3c13i36O5cKipw5pX+3mVvLBnDojIFLmX5q2mQ/6HJe36bB/eQ o/ZkGA+EZygwkT3v+7qGcGrwRuK6KyccAsTzBJ+kBwdMoQrF+yh3ik+QpEc0n+be7LWV zksTWd6V9f7+2iuKn2GRT1YWGOvvoy3et5w/Kt9f5BNe+7eLt4yJQK5d6wads0klVTQt W4+oRnx945PqEeL61VCuSsvaRw7BDkYu4O6IgRGAXSiVoA3J0obEIcm9R5GNhZZXEXiG EEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NaiZCxXPQ4mqykwTSBS7Y2NfyTkTfZtIUDm4TEDRZZY=; b=GeG7Lk+aqbKm1Yq9EjH/JyJ2sKCMzGzeSJhs65m+GBNl1t2JdumphHVzYYAJRYw1CF dtDaGLer2Phjjfn7wlsLqf+Ks2UGIqFu9gSWBGAoX1JUQybBFgMG1gnpy56IMvwm0Lh0 QEJ3SBe9pFYWgejI8qXTtwkXjH6YsxEeAKoU7zmKsVLAwCsQetgcYQ+XSAihm8yun78o gECcXYHI6IcMA8CGdGKAWZKZjk8k7Yq+nyX6NAMRJWAQs0UgcBX6Y/4Ho6PNo7iBgnm4 /X+7fUbBGkn5s2YV++BqamVzNvQ/kgkQZkWeuYsuPBEq3JUViDnKyUzizusjclCqt9CB /L8g== X-Gm-Message-State: AN3rC/6uEP65nr7tC3vmlbywKWzw5iOcsEfRsbmTg35TYBzjtd+ZQZNb LOG7zwxiWuPpcg== X-Received: by 10.55.115.67 with SMTP id o64mr2349407qkc.216.1492608427286; Wed, 19 Apr 2017 06:27:07 -0700 (PDT) Received: from [10.0.30.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t45sm236437qtt.9.2017.04.19.06.27.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 06:27:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] From: Ted Lemon In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Date: Wed, 19 Apr 2017 09:27:04 -0400 Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:27:19 -0000 This would be a huge improvement on the existing text=E2=80=94thanks for = writing it! > On Apr 19, 2017, at 12:02 AM, Brian E Carpenter = wrote: >=20 > There are several issues in this section, not just the NAT: >=20 >> 2.1.2. Use of ULAs >>=20 >> ULAs are intended for scenarios where IP addresses will not have >> global scope so they should not appear in the global BGP routing >> table.=20 >=20 > We need to align that with the clarification in draft-bchv-rfc6890bis: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. >=20 >> ULAs could be useful for infrastructure hiding as described in >> RFC4864 [RFC4864]. Alternatively Link-Local addresses RFC7404 >> [RFC7404] could also be used. >=20 > LL addresses don't help if you have multiple LANs. I suggest simply > deleting the second sentence; it will confuse people. >=20 >> Although ULAs are supposed to be used >> in conjunction with global addresses for hosts that desire external >> connectivity >=20 > Change that to >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Then I suggest deleting *all* the rest of the section, but add this > at the end: >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Thus the whole section would read (with a little more editing): >=20 > 2.1.2. Use of Unique Local Addresses >=20 > Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios > where IP addresses are not globally reachable, despite formally > having global scope. They must not appear in the routing system > outside the administrative domain where they are considered valid. > Therefore, packets with ULA source and/or destination addresses > MUST be filtered at the domain boundary. >=20 > ULAs are assigned within pseudo-random /48 prefixes created as > specified in [RFC4193]. They could be useful for infrastructure > hiding as described in [RFC4864]. >=20 > ULAs may be used for internal communication, in conjunction with > globally reachable unicast addresses (GUAs) for hosts that also > require external connectivity through a firewall. For this reason, > no form of address translation is required in conjunction with ULAs. >=20 > Using ULAs as described here might simplify the filtering rules > needed at the domain boundary, by allowing a regime in which > only hosts that require external connectivity possess a globally > reachable address. However, this does not remove the need for > careful design of the filtering rules. >=20 > Brian >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Apr 19 07:54:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B51129AE0 for ; Wed, 19 Apr 2017 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 A2VNW0gmMADV for ; Wed, 19 Apr 2017 07:54:37 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB84129ADC for ; Wed, 19 Apr 2017 07:54:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Cwe8uMJC2wcuYYUh+cnUYzDsjUw2WSewINTRZCVeNo3qMIMHbSZyvRos1e8D/AEc2gZO8FfrVm9kJ8Q6l4oDW+7ESyV6Zy2aUwkzDsOxvxjpU4lShzAWAlD4FJi1W6UmevMgd1aj1exDwy9coz0sCOpoBaK5g1l1OXuqEFdY48Y=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 11912 invoked from network); 19 Apr 2017 16:47:42 +0200 Received: from public-docking-pat-etx-mapped-0007.ethz.ch (HELO ?10.2.118.92?) (195.176.110.232) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Apr 2017 16:47:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> Date: Wed, 19 Apr 2017 13:22:45 +0200 Cc: Suresh Krishnan , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170419144742.11901.9620@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:54:39 -0000 Let me try to wrap this up. So what I learn is that HBH is used in = intra-domain scenarios and therefore must be further supported and = today=E2=80=99s routers are highly likely to drop packets with unknown = headers. In this sense I think the recommendation given could be further = clarified. Also I would rather see a discussion of the issue than just = given a specific recommendation forever, while people have still hope = that the situation might change (at least for HBH I assume). As such = I=E2=80=99ll go ahead and would like to propose new text for the = paragraphs in question, that is intended to conserve the current = recommendation but giving more background and phrase it more carefully. = Of course feel free to edit, I just thought it might be easier if I = simply propose some text: OLD: New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behaviour. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. Defining new IPv6 extension headers is not recommended. There has to be a very clear justification why any new extension header is needed before it is standardized. Instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility. NEW: Network nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. When using or defining new=20= hop-by-hop options this likely behaviour need to be taken into=20 account. While hop-by-hop option may be used for management purposes within one domain, measures should be take to detect these problem if hop-by-hop options are used end-to-end. Network notes further may be configured to drop packets with unknown=20= IPv6 extension headers. Therefore, instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s). Or alternatively the text from RFC6564 can be used directly instead of = this second paragraph. However, there are actually two paragraph in = RFC6564, one with a SHOULD and one with a MUST=E2=80=A6? "=E2=80=A6 Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for creation of a new IPv6 extension header MUST be accompanied by a specific explanation of why destination options could not be used to convey this information.=E2=80=9C and=20 "Mindful of the need for compatibility with existing IPv6 = deployments, new IPv6 extension headers MUST NOT be created or specified, unless no existing IPv6 extension header can be used by specifying a new option for that existing IPv6 extension header. Any proposal to create or specify a new IPv6 extension header MUST include a detailed technical explanation of why no existing IPv6 extension header can be used in the document proposing the new IPv6 extension header.=E2=80=9C There is also a paragraph on HBH in RFC6564 but given that routers are = not requirement anymore to process the HBH option, I assume that=E2=80=99s= not up-to-date anymore? I hope that helps! Mirja > Am 19.04.2017 um 05:15 schrieb Brian E Carpenter = : >=20 > In reality "MUST NOT unless..." means about the same as "SHOULD NOT" = so > I think we agree that this is editorial. Aligning the language with = RFC6564 > makes a lot of sense to me. >=20 > Brian > On 19/04/2017 07:58, Mirja Kuehlewind (IETF) wrote: >> sorry it=E2=80=99s late here=E2=80=A6 >>=20 >> s/formation/formulation/ >> s/no go advice/no good advice/ >>=20 >>> Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) = : >>>=20 >>> This might be rather an editorial issue now but the formation in = RFC6564 is fully fine with me because it says =E2=80=9EMUST NOT unless = no option can be used=E2=80=9C. That=E2=80=99s basically what I = proposed. The formulation in 2460 however is "Defining new IPv6 = extension headers is not recommended.=E2=80=9C. I think this is = overstated and technically no go advise. >>>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan = : >>>>=20 >>>> Hi Mirja/Bob, >>>>=20 >>>>=20 >>>> On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden = wrote: >>>>> Hi, >>>>>=20 >>>>>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>>>>=20 >>>>>> Brian, Mirja, >>>>>>=20 >>>>>>>>> This combination of circumstances creates a "Catch-22" = situation >>>>>>>>> [Heller] for the deployment of any newly standardised = extension >>>>>>>>> header except for local use. It cannot be widely deployed = because >>>>>>>>> existing middleboxes will drop it on many paths through the = Internet. >>>>>>>>> However, most middleboxes will not be updated to allow the new = header >>>>>>>>> to pass until it has been proved safe and useful on the open >>>>>>>>> Internet, which is impossible until the middleboxes have been >>>>>>>>> updated. >>>>>>>>>=20 >>>>>>>>> So, defining new IPv6 extension headers is not recommended, = because >>>>>>>>> they probably won't work across the Internet. But it isn't a = MUST NOT, >>>>>>>>> because if there was a compelling operational case, we could = do it and >>>>>>>>> the middleboxes would follow. >>>>>>>>=20 >>>>>>>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>>>>>>=20 >>>>>>>> I think I agree that I would not like to make a normative = statement here, given that the circumstances are not due to the protocol = design itself but because of the current deployment situation we have = (which in theory could change in future). >>>>>>>>=20 >>>>>>>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>>>>>>=20 >>>>>>>> Maybe you can work on some new text and then have a quick (?) = check with the wg which text is preferred. If there is clear consensus = for one way by the wg I will not further block this. >>>>>>>=20 >>>>>>> I think I will leave that for the document editor. A large part = of RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >>>>>>=20 >>>>>> I think what is in the document already is representing the = working group consensus. >>>>>> The issues of new / unknown extension headers, and how to = distinguish these from new transport protocols have been discussed from = many angles. The two main reasons for the strong recommendation against = new extension headers are: >>>>>> - most uses are already accommodated with the 3 existing = containers options (routing. hbh and destination) >>>>>> - sharing the same number space with IP protocols, makes it hard = for intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >>>>>>=20 >>>>>> There is already an opening / provision in the text for new = extension headers. The text only asks for these considerations to be = made, before proposing new ones. >>>>>=20 >>>>> I agree. >>>>>=20 >>>>> I also note that the text in this section was derived from = RFC6564, which updated RFC2460. Specifically from Section 3 of RFC6564: >>>>>=20 >>>>> Mindful of the need for compatibility with existing IPv6 = deployments, >>>>> new IPv6 extension headers MUST NOT be created or specified, = unless >>>>> no existing IPv6 extension header can be used by specifying a new >>>>> option for that existing IPv6 extension header. >>>>=20 >>>> Yes. This text was arrived at after a lot of discussion in the 6man = WG >>>> during the development of the draft that became RFC6564. >>>>=20 >>>>>=20 >>>>> New extension headers are allowed (just not recommended) and the = next paragraph in the Section specifies a format that should be used for = new Extension headers. I think there is a lot of flexibility going = forward. >>>>=20 >>>> Yep. I think the above warning is issued because a node processing = an >>>> unknown extension header will simply drop it, and this makes >>>> incremental deployability of these new extension headers difficult >>>> over the Internet. >>>>=20 >>>> Thanks >>>> Suresh >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Wed Apr 19 09:39:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610CA129B30; Wed, 19 Apr 2017 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 bwAu8lBY1_Hr; Wed, 19 Apr 2017 09:38:53 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1FB129B2F; Wed, 19 Apr 2017 09:38:53 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 46D5889BA3; Wed, 19 Apr 2017 12:38:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=YzmTiRoDSL1wIFJ4LedBV7oiA pU=; b=yWl3Z+DXFym9ns3hMPQfEAHEIAYD5bwvFlYs/uPB9Vj55/7g40+QdKKae PK75rmDN2IO55bga76O2FoeIokDZcjWd9c4OrM2zm++4urHoeT93SzPe/d6OOdUC uUjvXYlLvtkyVAKjbzKWk2oeA9TKQkRtGJh5+VmrDybIIJlZAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=P39bvhx4N6gsREnFPHR 3FHLRhnqdPKPSjBf9dzjjVtRnZwvBhtqEnwnYyype/i5nVp4NbIO/Ub4Y3OAcZb+ aeA4GuCkfHf/ElslIYSsQLT7uCHggjS9PDoIfVdTeYHjuZsGJXDrE4FMLmh+CiAa WVAF+sGHqqU9DgcHmcBqKNEw= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3CC1B89BA2; Wed, 19 Apr 2017 12:38:52 -0400 (EDT) Received: from mail-qk0-f176.google.com (unknown [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id B61DB89B9F; Wed, 19 Apr 2017 12:38:51 -0400 (EDT) Received: by mail-qk0-f176.google.com with SMTP id p68so24920922qke.1; Wed, 19 Apr 2017 09:38:51 -0700 (PDT) X-Gm-Message-State: AN3rC/5Q6b8doNt3BiPbKkY1Sd0+qXXKjYIOY2M1w4JS6gtY7tirGW0E js9BzC0a8MDkkFqTuep7xm/SRAXIgw== X-Received: by 10.55.78.201 with SMTP id c192mr3642885qkb.81.1492619931222; Wed, 19 Apr 2017 09:38:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Wed, 19 Apr 2017 09:38:30 -0700 (PDT) From: "C. M. Heard" Date: Wed, 19 Apr 2017 09:38:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: "Mirja Kuehlewind (IETF)" Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: ABAD80CC-251E-11E7-9406-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 16:38:55 -0000 On Tue, Apr 18, 2017 at 11:49 PM, Mirja Kuehlewind (IETF) wrote: > Yes and no. Of course if ECN is not supported, packet should not be > ECN marked. However, the IP layer might actually not know if is > supported or not (e.g. a UDP based protocol that is implemented in > user-spaces that uses ECN) and therefore my thinking is that it should > reassemble the ECN field correctly if ECN was set not matter what. A packet will not be ECN marked (i.e., will contain the not-ECT codepoint) if the **source flow** does not support ECN. That has nothing to do with whether the **destination node** supports ECN. If any of the transport protocols in the destination node are to support ECN in conformance with RFC 3168 -- including, of course, UDP-based protocols implemented in user space -- then of course the IPv6 module in that node must implement fragment reassembly in accordance with RFC 3168. No argument there. In that case the node would "support Explicit Congestion Notification [RFC3168]" and, under the text proposed by Bob Hinden (as modified by David Black), would "use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet" as specified in RFC 3168 Section 5.3. You seem to want the requirements of RFC 3168 Section 5.3 to apply to **all** IPv6 stacks, even those in nodes that have no ECN-capable transport modules. That might be a good thing for implementors to do in order to to ensure future extensibility, but those requirements are not part of RFC 2460 and so are out of scope for 2460bis, if it is to be eligible for Internet Standard status. In order to insist that those requirements go into 2460bis you would need to prove that there is an essential technical omission without them, and I don't think you can make that case. If you are able to make that case, the implication would be that 2460 does not meet the requirements for promotion to IS. Mike Heard >> Am 19.04.2017 um 05:04 schrieb C. M. Heard : >> >> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote: >>> sorry but this is wrong=E2=80=A6 if the actually sender indicates ECN s= upport, >>> the reassembled packet should also do that correctly, no matter if >>> the nodes support ECN or not. Handling these fields correctly with >>> fragmentation does not mean that the nodes supports ECN. So this is >>> not optional=E2=80=A6 >> >> This seems confused (or else I am confused). We are discussing issues >> related to reassembly of fragmented packets, and that is a process that >> takes place in end systems only, not in forwarding nodes. >> >> It is true that if an end system (aka host) supports ECN per RFC 3168, >> then received packets that it reassembles must have the CE bit pattern >> set if any fragment has the CE bit pattern set, provided that all >> fragments contain either CE or ECT(0)/ECT(1). The text that we are >> working on is intended to say that -- indirectly, by referring to the >> Section 5.3 of RFC 3168. >> >> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end >> systems are not obliged to support it -- and I see no such mandate >> in the IPv6 node requirements document. In that case ECN indications >> will simply be ignored. No purpose is served by levying a requirement >> on the IPv6 module to preserve an indication that will not be used. >> >> Mike Heard >> > From nobody Wed Apr 19 10:25:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5181129B52 for ; Wed, 19 Apr 2017 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 Oed2QJOY07qE for ; Wed, 19 Apr 2017 10:25:11 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1F2129B57 for <6man@ietf.org>; Wed, 19 Apr 2017 10:25:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=JOZnOa24E3HLuq1x0ZenSxbI/Ls5NH2D/6VVxu2tMnD9BnfoaT7L17Z+n5cxCWGri0naHz4Dwh9OWhY7t+X7u1iMA8Oq6HCgmHFImeIELIg9/oyW0kSkai+7doBYloc4kPeF4WvGRGi5OZlULxQJwnnzI1+JVmPBxfjsmqHHZOY=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 20105 invoked from network); 19 Apr 2017 19:25:07 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Apr 2017 19:25:07 +0200 Subject: =?UTF-8?Q?Re:_[tsvwg]_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-?= =?UTF-8?Q?6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "C. M. Heard" References: Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Wed, 19 Apr 2017 19:25:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170419172507.20094.45662@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:25:13 -0000 Hi Mike, I think we use the word 'support' differently and that's were the confusion comes from. However, see below. On 19.04.2017 18:38, C. M. Heard wrote: > On Tue, Apr 18, 2017 at 11:49 PM, Mirja Kuehlewind (IETF) wrote: >> Yes and no. Of course if ECN is not supported, packet should not be >> ECN marked. However, the IP layer might actually not know if is >> supported or not (e.g. a UDP based protocol that is implemented in >> user-spaces that uses ECN) and therefore my thinking is that it should >> reassemble the ECN field correctly if ECN was set not matter what. > > A packet will not be ECN marked (i.e., will contain the not-ECT > codepoint) if the **source flow** does not support ECN. That has > nothing to do with whether the **destination node** supports ECN. > > If any of the transport protocols in the destination node are to > support ECN in conformance with RFC 3168 -- including, of course, > UDP-based protocols implemented in user space -- then of course the > IPv6 module in that node must implement fragment reassembly in > accordance with RFC 3168. No argument there. In that case the node > would "support Explicit Congestion Notification [RFC3168]" and, > under the text proposed by Bob Hinden (as modified by David Black), > would "use information in the Traffic Class field from all fragment > packets to reconstruct the Traffic Class field in the reassembled > packet" as specified in RFC 3168 Section 5.3. > > You seem to want the requirements of RFC 3168 Section 5.3 to apply > to **all** IPv6 stacks, even those in nodes that have no ECN-capable > transport modules. Actually yes, because the IPv6 stack might not know anything about ECN-capable transport modules. So the only thing you can do is require it for all. But please see further below. That might be a good thing for implementors to do > in order to to ensure future extensibility, Yes :-) but those requirements are > not part of RFC 2460 and so are out of scope for 2460bis, if it is to > be eligible for Internet Standard status. So, yes this is not part of RFC2460 but as you noted correctly RFC3168 should have updated RFC2460 and as such this could be incorporated into 2460bis (as done with other updates as well). But please see further below. In order to insist that those > requirements go into 2460bis you would need to prove that there is an > essential technical omission without them, and I don't think you can > make that case. Not sure. Losing a congestion notification is a real problem. RFC3168 is standards track as well, and as you noted, probably should have updated RFC2460. But please see further below. If you are able to make that case, the implication > would be that 2460 does not meet the requirements for promotion to IS. I guess what we really need to check would be if most IPV6 stacks have implemented this behavior. If so it should be fine to add this to 2460bis, if not maybe not. But I just don't know... And now the big BUT... This is the text I proposed: "The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet; however, the Traffic Class field from any or all fragments may differ. Handling of Explicit Congestion Notification [RFC3168] is described in Section 5.3 of RFC 3168, ensuring that reassembly does not lose indications of congestion." This text does not make any normative statement on the question if the behavior specified in RFC3168 should be implemented or not. It only says please look at RFC3168 and make an informed decision if you want to confirm to the behavior that is specified in RFC3168 in addition to implementing the spec in this document. However, yes, this statement is true for all IPv6 implementation. I don't see a problem here... Mirja > > Mike Heard > >>> Am 19.04.2017 um 05:04 schrieb C. M. Heard : >>> >>> On Tue, Apr 18, 2017 at 12:42 PM, Mirja Kuehlewind (IETF) wrote: >>>> sorry but this is wrong… if the actually sender indicates ECN support, >>>> the reassembled packet should also do that correctly, no matter if >>>> the nodes support ECN or not. Handling these fields correctly with >>>> fragmentation does not mean that the nodes supports ECN. So this is >>>> not optional… >>> >>> This seems confused (or else I am confused). We are discussing issues >>> related to reassembly of fragmented packets, and that is a process that >>> takes place in end systems only, not in forwarding nodes. >>> >>> It is true that if an end system (aka host) supports ECN per RFC 3168, >>> then received packets that it reassembles must have the CE bit pattern >>> set if any fragment has the CE bit pattern set, provided that all >>> fragments contain either CE or ECT(0)/ECT(1). The text that we are >>> working on is intended to say that -- indirectly, by referring to the >>> Section 5.3 of RFC 3168. >>> >>> But, unless ECN is mandatory-to-implement for all IPv6 nodes, end >>> systems are not obliged to support it -- and I see no such mandate >>> in the IPv6 node requirements document. In that case ECN indications >>> will simply be ignored. No purpose is served by levying a requirement >>> on the IPv6 module to preserve an indication that will not be used. >>> >>> Mike Heard >>> >> > From nobody Wed Apr 19 10:55:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850A3129B8D; Wed, 19 Apr 2017 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 3Y05YonJpEJc; Wed, 19 Apr 2017 10:55:05 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFF6129B89; Wed, 19 Apr 2017 10:55:05 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2C6918A886; Wed, 19 Apr 2017 13:55:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=sasl; bh=6JU2f/Gs0td8 gkKvMOQ8qw6sOsk=; b=TtSmwyVzEZI18TYLuVg4I8Rj3xo7NWgrzcKJVqO79+NY C2MDZ1qpDIDovmK0P2qMaQFxupaSViyYWOYRZAihl1AzECN7pTcYZqGMZCl2BhnY zrp9IvE8+xFq58sWbz9CJRZ8jfuuvRAl8891KmftDj4Iy0aON04mvCnHUBid4k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; q=dns; s=sasl; b=etujrn GpsRg7g4QpTUEMrxzsgO9GxKLMI9L2cF3tAELUQXnYKTqSN1JjdlASgkf7DGkr9m jfm0qnteGmzQ4x2z70fB+CwNS74MHjHFP0/U2CrrTi8oq4Lr4YercOBStri3Zi6T YqxAcOhfShJqOJYWlEfAw0VcN3mvEoEBWfuws= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 210A88A885; Wed, 19 Apr 2017 13:55:04 -0400 (EDT) Received: from mail-qt0-f178.google.com (unknown [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 3A0B08A87C; Wed, 19 Apr 2017 13:55:03 -0400 (EDT) Received: by mail-qt0-f178.google.com with SMTP id m36so26193368qtb.0; Wed, 19 Apr 2017 10:55:03 -0700 (PDT) X-Gm-Message-State: AN3rC/6b4kzOrKug4b9psypFlMcs6k2ZD52t4o5Gl/0kyAsSnJySayMh KE3E63AU7gvATt2yTkbbzOYGY+9bQg== X-Received: by 10.237.37.142 with SMTP id x14mr3792360qtc.160.1492624502739; Wed, 19 Apr 2017 10:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Wed, 19 Apr 2017 10:54:42 -0700 (PDT) In-Reply-To: References: From: "C. M. Heard" Date: Wed, 19 Apr 2017 10:54:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , Bob Hinden , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 50801A38-2529-11E7-9E61-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 17:55:07 -0000 On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: > This text does not make any normative statement on the question if the > behavior specified in RFC3168 should be implemented or not. It only says > please look at RFC3168 and make an informed decision if you want to confi= rm > to the behavior that is specified in RFC3168 in addition to implementing = the > spec in this document. However, yes, this statement is true for all IPv6 > implementation. I don't see a problem here... Nor do I. As it happens I prefer the text proposed by Bob Hinden (with David Black's modification) but I believe that the effect is essentially th= e same as the text you proposed. So it seems that the discussion is boiling down to editorial issues, and I am happy to leave that between you, the shepherd, and the document editor. Thanks Mike Heard From nobody Wed Apr 19 13:55:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774D12E855 for ; Wed, 19 Apr 2017 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 QgX1Vu7MpX1O for ; Wed, 19 Apr 2017 13:55:11 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 37B37129442 for ; Wed, 19 Apr 2017 13:55:11 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id s22so16600584ybe.3 for ; Wed, 19 Apr 2017 13:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=EQfRdNxFW59edwxcSuJLuZ8XKeJfUGYdQbcwFWlkFg4=; b=PptTcTmS8MA2AaAvjTWW8ly3eEnAEmEooqtAH2/fSzCrDm8MMblpjpm+OpGJhcbToh ts6VOPuH9oXNXGiJolCS9JbrMFBQSR5Jvce0K6aww24n8EGqCBhIk9Zas9lUG3huBar5 aAD6241cuIz0DrP0ZgPCfLPdR582rw8EeWTY6/y3KRUxQm3dLpk50WBICsRyhXwqXd6V xlr7BXXwK/Lr+vUHMCzx9a1vtxCqspKoEj4Kr4FfJAcwZvelMeb4Yt+BFI2xG6P5XmO0 h2UGQ8z109jajKIoMPZK2+xYyUe/aw8kzNIt03SzNejFx7LlgfHlHxtsNKE8pZBlEu63 7j5w== 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:date:cc:to; bh=EQfRdNxFW59edwxcSuJLuZ8XKeJfUGYdQbcwFWlkFg4=; b=dlZhzgxBymBLCIU17bGj3rYI/px0XI9LSZ7eSwnmsPFoJJ2qACwYXqqUfspaXzETuB 74ZrKTLePw4jL3EADLwa+kW29AtZEbar1a/Sc4KJ5WnibVwM/8JlsKnZLPUjYRH4fvg0 1l4ZN5jYCZ5RkhtV17lr8AakdxZzowThQwNJq2/9BKGwmUbQj4U5qkT7GqxoHKk0qKAh m6rlb3rSn0oA76fepfPtyUL7o/hF+U/lbvWlxEAw9BtVxDXiPnqckuCm1XEPRaca66j9 Si4q9fEG1CSRdRLq97gkaqqGtKzVz1cx2q8Mey2003mTZTQwgWfdyy1KQ99dOMau8W1e QNTw== X-Gm-Message-State: AN3rC/7I5AyMikb5xKUSgR0NKF9Fm/JfIUPCR+j2KrUHzOYx5ZIKqC3B Vd/b/ShyFrBXhA== X-Received: by 10.98.135.71 with SMTP id i68mr4820203pfe.258.1492635310416; Wed, 19 Apr 2017 13:55:10 -0700 (PDT) Received: from [192.168.160.247] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id o124sm6168065pfb.92.2017.04.19.13.55.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 13:55:09 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_48F99684-4569-4484-BC42-4FFB2D4C52B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Revised and expanded rfc2460bis Security Considerations Message-Id: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Date: Wed, 19 Apr 2017 13:55:07 -0700 Cc: Bob Hinden , Eric Rescorla To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 20:55:17 -0000 --Apple-Mail=_48F99684-4569-4484-BC42-4FFB2D4C52B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, To resolve Eric Rescorla's Discuss, I revised and expanded rfc2460bis = Security Considerations section. I think it is much better and EKR is = happy with it. The current and proposed new text is below. Please review and comments. = I hope to publish a new draft at the end of the week. Thanks, Bob =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 10. Security Considerations OLD IPv6, from the viewpoint of the basic format and transmission of packets, has security properties similar to IPv4. Risks of corruption, forgery, and interception of packets, resulting in the exposure of private information, may be mitigated by use of the Security Architecture for the Internet Protocol [RFC4301] or encryption at higher layers of the protocol stack. NEW IPv6, from the viewpoint of the basic format and transmission of packets, has security properties that are similar to IPv4. These security issues include: o Eavesdropping, On-path elements can observe the contents and metadata of each IPv6 datagram. o Replay, where attacker records a sequence of messages off of the wire and plays them back to the party which originally received them. o Message insertion, where the attacker forges a message with some chosen set of properties and injects it into the network. o Message deletion, where the attacker remove a message from the wire. o Message modification, where the attacker removes a message from the wire, modifies it, and reinjects it into the network. o Man in the Middle attacks, where the attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender. o Denial of Service Attacks, where the attacker sends large amounts of legimate traffic to a destionation to overwhelm it. IPv6 packets can be protected from eavesdropping, packet modification, replay, and man in the middle attacks by use of the "Security Architecture for the Internet Protocol" [RFC4301]. In addition, upper-layer protocols such as TLS or SSH can be used to protect the application layer traffic running on top of IPv6. There is not any mechanism to protect against "denial of service attacks". Defending against these type of attacks is outside the scope of this specification. IPv6 addresses are much larger than IPv4 address making it much harder to scan the address space across the Internet and even on a single network link (e.g., Local Area Network). IPv6 addresses of nodes are expected to be more visible on the Internet as compared with IPv4 since the use of address translation technology is reduced. This creates some additional privacy issues such as making it easier to distinguish endpoints. The design of IPv6 extension headers architecture, while adding a lot of flexibility, also creates new security challenges. As noted below, issues relating the fragment extension header have been resolved, but it's clear that for any new extension header designed in the future, the security implications need to be examined throughly, and this needs to include how the new extension header works with existing extension headers. This version of the IPv6 specification resolves a number of security issues that were found with the previous version [RFC2460] of the IPv6 specification. These include: o Revised the text to handle the case of fragments that are whole datagrams (i.e., both the Fragment Offset field and the M flag are zero). If received they should be processed as a reassembled packet. Any other fragments that match should be processed independently. The Fragment creation process was modified to not create whole datagram fragments (Fragment Offset field and the M flag are zero). o Changed the text to require that IPv6 nodes must not create overlapping fragments. Also, when reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments) must be silently discarded. Includes clarification that no ICMP error message should be sent if overlapping fragments are received. 0 Revised the text to require that all headers through the first Upper-Layer Header are in the first fragment. o Removed the paragraph in Section 5 that required including a fragment header to outgoing packets if a ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. o Incorporated the updates from RFC5095 and RFC5871 to remove the description of the RH0 Routing Header, that the allocations guidelines for routing headers are specified in RFC5871, and removed RH0 Routing Header from the list of required extension headers. Security issues relating to other parts of IPv6 including addressing, ICMPv6, Path MTU Discovery, etc., are discussed in the appropriate specifications. --------- --Apple-Mail=_48F99684-4569-4484-BC42-4FFB2D4C52B3 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY986sAAoJEK7rdBF357uoprUH/j9OuCOf5JEgEFnZ8gfsnsRM g8L0MRBAMeMfRS0Ed+e1pUGSondExapmpR1L6GmD7BwTxn/Ig8PRa8CVjYxT0B1l UtuZyoa3THN6s/7NeNZZG/s9zmEu9N2I/Wwe/ydlOJNeuavEC0NfQikxG9HiqTMS h9O6KJGCaRhiPbZfFX5VEjhW3WXH0TpElS28PY3P0qVVfdng2m5vjRAcU6Z2AOKI Rmn4inupmRFl0Cg+BScg5eTmKAetcvscBup1msWa9WDwH9R7UwcKvaZ2uABzwmT0 flHUL6MGlpYM7tkvU0MTXyzA29v7oUPCHKq7nbxxcmU1FoTnI7l47ra1Yp6TMLk= =iO5E -----END PGP SIGNATURE----- --Apple-Mail=_48F99684-4569-4484-BC42-4FFB2D4C52B3-- From nobody Wed Apr 19 14:16:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8F0129ABE for ; Wed, 19 Apr 2017 14:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WeAuNw5ow6L5 for ; Wed, 19 Apr 2017 14:15:57 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 EFCA7129B67 for <6man@ietf.org>; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id 11so13612113ybw.1 for <6man@ietf.org>; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=slbvLTa8uctCuoLTjuo/yEW+kIUhpNPv4C6ajdUhqsTlUMbAnVv4IqtAtsyLujVne6 uUwMsko8eoPReIhecGdtJb+usV57i7/bn6UTCOrswaI6vtWqoasXICRoKjBm+KrlnsDq Zmx5QOCf2WEV97JBsEcJkPf/wrAHs/4OuOl+/6Lq0YgyOWGLD01TqFaOEVmJ9Awed0N9 W6/gGvOgyVk/P4cqWlWdCakvSzjZcr5WvdDd853Tj0uEeSHsnDYeeT7ihAr1wcA/Ye2D YKrbnPbCn1xBZKm7gQrR2E25XZyH+xHGM1wATIfrs3NFz+ZoBYJ5IkbiqCUD4htH08sz IR0w== 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:date:references:to :in-reply-to:message-id; bh=upV80KC12V4hIAaF9bCzrG0Fr/GPrVML96VHHbRohAM=; b=PKS/W+1Q6elHX/eRg0EsPRzkb1VCZu7Pose1wxGOPqaG6frdPExkdaLXIBC/ZCxVC8 LYbiQaaagGOZmZMXTlQGjKOQ4RGq68ZnSs1RR6XvJ+Kc6VuiQTFxx+ri/ypG0QCTjKxn SCcsFSryZoIElmWFiZCB+Y5DdFZkQe/GRptkPDdRsAj+Ho8gN71p0LiXKWLUQs+NLsjS qfxdEibJflhZIAOgTqZI+PD03jWU+akn6uG+bMP86Q5R9RJU0uAEO/pis7ykErkfH4zY +aAAlEISsUxky4tPF+ZHbzWrW9RNJdJisqbMnrEBq+6TIDGVkoRbLPBv2bnziCZrVQWC 3rUg== X-Gm-Message-State: AN3rC/60U1MWuvU9906fD2IJDkj3COiRvz3tjxIzcffNOmLNgi92XL+a r76s0O2o6Q78JOrxO3kZCA== X-Received: by 10.84.213.8 with SMTP id f8mr6368822pli.156.1492636555084; Wed, 19 Apr 2017 14:15:55 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2dd0:a83f:1f58:e25? ([2620:0:10e7:10:2dd0:a83f:1f58:e25]) by smtp.gmail.com with ESMTPSA id z123sm6223509pfz.56.2017.04.19.14.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:15:54 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] Date: Wed, 19 Apr 2017 14:15:53 -0700 References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> To: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> In-Reply-To: <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> Message-Id: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:15:59 -0000 --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter = wrote: >=20 > ULAs are intended for scenarios where IP addresses are not globally > reachable, despite formally having global scope. They must not appear > in the routing system outside the administrative domain where they > are considered valid. Therefore, packets with ULA source and/or > destination addresses MUST be filtered at the domain boundary. I don=E2=80=99t think it's quite right yet. It=E2=80=99s greatly = improved, but I have a quibble. ULA are intended for scenarios where IP addresses are not *publicly* = reachable. Nothing about them constrains their private routing or usage = over any geographic area. They may appear as source or destination in = packets in transit across any private routing system, including any = system organized in a private multilateral agreement between domain = administrators. Therefore, packets with ULA source and/or destination addresses MUST be = filtered at the public boundary of a routing domain, and SHOULD be = filtered at private boundaries to limit their reachability according to = local policy. I would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of = Unique Local Addresses like so: >> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. >>=20 >> Routing prefixes for ULA are /48 prefixes, and contain 40-bit = pseudo-random global identifiers. which are generated according to = [RFC4193]. They could be useful for infrastructure hiding as described = in [RFC4864]. They could also be useful for communication between hosts = in private routing domains, and private groups of autonomous routing = systems organized by multilateral agreement. Hosts that require = connectivity to the public Internet SHOULD communicate using publicly = routed general-unicast (GUA) addresses. No form of address translation = is required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public connectivity. >>=20 >> The usage of ULA as described here could simplify the filtering rules = needed at domain boundaries, by allowing a regime in which only hosts = that require communication with the public are assigned general-unicast = addresses (GUA). However, this does not remove the need for careful = design of filtering rules at domain boundaries. --james woodyatt > --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Apr 18, 2017, at 21:02, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

ULAs are intended = for scenarios where IP addresses are not globally
reachable, despite formally having global scope. = They must not appear
in the routing = system outside the administrative domain where they
are considered valid. Therefore, packets with = ULA source and/or
destination = addresses MUST be filtered at the domain = boundary.

I don=E2=80=99t think it's quite right = yet. It=E2=80=99s greatly improved, but I have a quibble.

ULA are intended for = scenarios where IP addresses are not *publicly* reachable. Nothing about = them constrains their private routing or usage over any geographic area. = They may appear as source or destination in packets in transit across = any private routing system, including any system organized in a private = multilateral agreement between domain administrators.

Therefore, packets with = ULA source and/or destination addresses MUST be filtered at the public = boundary of a routing domain, and SHOULD be filtered at private = boundaries to limit their reachability according to local = policy.

I = would amend Brian=E2=80=99s proposed text for =C2=A72.1.2 Use of Unique = Local Addresses like so:

Unique = Local Addresses (ULA) [RFC4193] are intended for scenarios where IP = addresses are not publicly reachable, despite their global address = scope. They MUST NOT appear in the default-free routing domain of the = public Internet, and gateways at the boundaries of private routing = domains SHOULD NOT forward packets from or to ULA addresses where = multilateral transit agreements do not explicitly recognize = them.

Routing = prefixes for ULA are /48 prefixes, and contain 40-bit pseudo-random = global identifiers. which are generated according to [RFC4193]. They = could be useful for infrastructure hiding as described in [RFC4864]. = They could also be useful for communication between hosts in private = routing domains, and private groups of autonomous routing systems = organized by multilateral agreement. Hosts that require connectivity to = the public Internet SHOULD communicate using publicly routed = general-unicast (GUA) addresses. No form of address translation is = required where ULA addresses for private connectivity are used in = conjunction with GUA addresses for public = connectivity.

The usage of ULA as = described here could simplify the filtering rules needed at domain = boundaries, by allowing a regime in which only hosts that require = communication with the public are assigned general-unicast addresses = (GUA). However, this does not remove the need for careful design of = filtering rules at domain boundaries.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_76074DC4-BCBE-4B93-A609-45A758EEBBA4-- From nobody Wed Apr 19 14:16:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA46124B0A; Wed, 19 Apr 2017 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 dOaJGEWoSOo4; Wed, 19 Apr 2017 14:16:45 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D4297129ABE; Wed, 19 Apr 2017 14:16:44 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w64so89933377wma.0; Wed, 19 Apr 2017 14:16:44 -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=bYKy9N0z3bcxHbbp30OXUT067+znJVFZzAf/HL/+DLo=; b=oLUBhg8RX+HoD/I3igPYRfG57Ne1eb00/aHAVuGl5/TD/M/LQrmj3V1kQIk1HHzZ7m QKEw0/odwxSQPJWAqGAMQfkHSSBlmDdEcq40Ia7j/tBKrNAXWqmQ03RVBPS4Z2P0Jqjx fNgjlPe84yswv7MYxN/MiuKoQL16ATxGZnpS4hnk0oGgQQfRgOdWbzsI3M9AFOH9Da08 BqrRKanX7Yjfg/qDDYm6bs8/WVCWyEBKd3eGDLZSIfFEbW+AxuxTswwzA4NgBqXtx0yC bskULb6TMJhnkOLIVrKSvi8BK9d5tOHR0w1spsb77TNf+OqXHokLlyP3pfOX/QRPwHrR Rpvw== 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=bYKy9N0z3bcxHbbp30OXUT067+znJVFZzAf/HL/+DLo=; b=q0EGrLPZbSY66GNLEIao+skCMGKUl+zy32U2pNUHAlc06eQw8CDwlVALtcXubprKkI XNx8nNlEC7e3cPdOjasMJhiqCIjlRo2hxsox0BIVQVQH/zhhDRZDvdFnWbTQujoYl4JB y89GFwBUjIZXrXYl8sONGpEA3z901yk4BEmDZDJeWlDDxzXKYFQeCwQlNPL+oAZnRuQW 5KMV+fYAM1Kdpem70JAZwKdUmzFAxCio3ihmPhMcPC8RY3Eu0GlJ/QOln/iAa88UaRSL 5/XWq9691y6LpaoVcCVm6k7lhzkLoM5WwnMn1gDhfNJxWpPeguyXOJnjCq6rKk/Kgo7u 8b9w== X-Gm-Message-State: AN3rC/5C7UTIdYfzLXkv8Hg14rQQBpptvA4x99/qaNSTjPUf6C0hpydv 1FwkfsvYrSls13GM9MY= X-Received: by 10.28.135.130 with SMTP id j124mr3759wmd.125.1492636603400; Wed, 19 Apr 2017 14:16:43 -0700 (PDT) Received: from [192.168.160.247] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id w76sm4816708wrb.49.2017.04.19.14.16.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:16:41 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_d?= =?utf-8?Q?raft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Wed, 19 Apr 2017 14:16:34 -0700 In-Reply-To: Cc: Bob Hinden , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , IESG , 6man Chairs <6man-chairs@ietf.org> To: "C. M. Heard" References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:16:47 -0000 --Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, > On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: >=20 > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >> This text does not make any normative statement on the question if = the >> behavior specified in RFC3168 should be implemented or not. It only = says >> please look at RFC3168 and make an informed decision if you want to = confirm >> to the behavior that is specified in RFC3168 in addition to = implementing the >> spec in this document. However, yes, this statement is true for all = IPv6 >> implementation. I don't see a problem here... >=20 > Nor do I. As it happens I prefer the text proposed by Bob Hinden (with > David Black's modification) but I believe that the effect is = essentially the > same as the text you proposed. So it seems that the discussion is = boiling > down to editorial issues, and I am happy to leave that between you, > the shepherd, and the document editor. The current text I have is: Nodes that support Explicit Congestion Notification [RFC3168] use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. See Section 5.3 of RFC3168 for more information. I continue to think this is clear and is unlikely to create any = confusion if ECN is a new requirement in IPv6 implementations. I think = it=E2=80=99s the appropriate change for moving to Internet Standard. It does resolve the issue that Mirja=E2=80=99s raised about there not = being any mention of ECN in the reassembly text. Thanks, Bob --Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY99OzAAoJEK7rdBF357uoiloH/jWKjkmqJCJhM+Th3zrMbA7W VvBr2FANhgQR1CED/Yv2TwlpYRdRGsJKwoMIIbJXQ2GJevoCfOx9ANTT8sfdD7Ty 6J25DZp1dx/Nqy593ENyl9Sz+o1yIUtcxfkgYz14fIjrT+HcFMUxXUMGqG0M3efB Q8Iu8W1C2Zp/N7pXmuAbYvvKUAfIokC5ZE22RPFofdRJ+HoeXYPlTEWfRleS3iMp 6zoOlPjvokf6ZuNNbMNh2GyB9p1j4GN4Zr7FziX1wSWJ32SwjOnPcyMEoHaCf+Iy unJP1mcTtdfND1F5o6s1CsMluqsLiYvQemh0ExTKv9QSpvpQM5a4MiCvNRbVL8I= =Y8s4 -----END PGP SIGNATURE----- --Apple-Mail=_D93F7A0A-3151-4DE2-A2A1-71FEFCE16F93-- From nobody Wed Apr 19 14:34:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B3412948E for ; Wed, 19 Apr 2017 14:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 unvyqVqBu4OJ for ; Wed, 19 Apr 2017 14:34:07 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9C1E2128CDC for ; Wed, 19 Apr 2017 14:34:07 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id r16so37704881ioi.2 for ; Wed, 19 Apr 2017 14:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QVDoS1GMHSRFB4KxgfGuvqW9hd9mbmg7NaZJH5uu/BA=; b=MJoUYSIQj3MzED9vJLNgzYJmv3kjWvDpdGjwng3/ypLeBzYncmW/5iVO7jZs0nhSRQ lCh6WnA/HTCQPsWoY5xpJEjDcll3+/4zyq7JYxd471oblK6L/9ECJSJ9LtDN+ASkbtul MQ603AW0N8iKcmmmaTPjms7xMBYQz6G+x8wqXnYAOHJzaMbyOQ8Q8cwhBLn/FSoR524v YBuaKgx90dq/O387iNwe5SmaQBUUvmk6iOruibem7k8yob8h78ycO4Kf6rxWq6cwn9gZ L5I9HUF0Zln3d7wCGftkoZ4Cw95BHRyAv17IeIC/GWNB8W4urdE56qiAL6KlMBcxSCaD vbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QVDoS1GMHSRFB4KxgfGuvqW9hd9mbmg7NaZJH5uu/BA=; b=nhazR7mCTqmX+HcUy3O4NzR1gVHiTXXzZCwif9X8fSKx5uiolD0zD/eUwu9Cuuy5j1 PIb5xESL3cObX8gexb9WJGID5IuLiIwEBF/mxjS+nXRo1LvKa5w+B3SMEwRR9BNPDDj4 YJPQRJkyKdUOMG4t1+aOdG8VJ5Id015Ng5DdvjBOWlSZ5xt6wGto1dIdob3rcL2GS0gJ TQVyegKTEirhbV9UCKZhEKc/76rPsTbb0K1cs7TuUq+bbAX2gZPHAa4UmM92KfOW6Kps JEEQNP67dmR/VLTC5HiAIYz6S81zbew6aqbmrnn/vIIVyUXxNzKJbz6VYSuXg1bARLcF 2paw== X-Gm-Message-State: AN3rC/7NTs6AhqWZ/eEaXd3IZsJfVnX8ADJkiRhj5mhuxaoCVAZS1qH8 q+Wqbox/mFrQ/Dla X-Received: by 10.98.216.134 with SMTP id e128mr4878777pfg.79.1492637645446; Wed, 19 Apr 2017 14:34:05 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:2dd0:a83f:1f58:e25? ([2620:0:10e7:10:2dd0:a83f:1f58:e25]) by smtp.gmail.com with ESMTPSA id p16sm6287186pgc.4.2017.04.19.14.34.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 14:34:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Revised and expanded rfc2460bis Security Considerations From: james woodyatt In-Reply-To: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Date: Wed, 19 Apr 2017 14:34:03 -0700 Cc: Eric Rescorla , IETF IPv6 Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:34:08 -0000 On Apr 19, 2017, at 13:55, Bob Hinden wrote: >=20 > The current and proposed new text is below. Please review and = comments. I hope to publish a new draft at the end of the week. Bravo! Alas, I have a nit. >> [...] These security issues include: >>=20 >> o Eavesdropping [...] >> o Replay [...] >> o Message insertion [...] >> o Message modification [...] >> o Man in the Middle attacks [...] >> o Denial of Service Attacks [...] >>=20 >> IPv6 packets can be protected from eavesdropping, packet = modification, replay, and man in the middle attacks by use of [...] p1. The order used to present the list of security issues should be also = be used to present the methods of protection. p2. The issue =E2=80=9Cmessage modification=E2=80=9D changes to = =E2=80=9Cpacket modification=E2=80=9D from one list to the next. I think = this should be clarified. p3. No further mention of =E2=80=9Cmessage insertion=E2=80=9D is made = after its appearance in the list of issues, even one similar to the = =E2=80=9Cdenial of service attack=E2=80=9D issue, to explain that no = defensive mechanism is defined, and it is left out of scope for this = specification. --james woodyatt From nobody Wed Apr 19 14:47:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF51243FE; Wed, 19 Apr 2017 14:47:54 -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_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 sQT_IyZK_RnZ; Wed, 19 Apr 2017 14:47:52 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 6391D120046; Wed, 19 Apr 2017 14:47:52 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id f10so31421992uaa.2; Wed, 19 Apr 2017 14:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bHJ4EQSJxY3xNkJCPdttesOF4l7vwsYbjac0cVrl4Tc=; b=qp87PV2NbAjGp3X+S4P1ghI+4xCvsr/cIgmJNE4OU2alXu+MFBZ0kqpbJ2kVP/8pdO blg/XSdXKbEpCcfaFJ216aGRe3x5D1DxHaubdj6R2IHC7/Gu6JVvWa8/Z+X9tjxTmVlw XXqZWQ8yEwfKoRz30mkblz4gn6upbk++sarCjTMlyINs1prx1PzNTa9iIgrDMBS5DhFf jKeGElhgPABLtBHDOhy/8kS0N/ZP0+ZqpVYbSnQxWNKxIKmqnlOezh9KoanNykcsX+iy n/GMEwkyUVZs4q5JMXOAfNRW4d+ifpoyRPmhjIAUOHfRwRZbweX77y91Kd4t9vzn4fg3 OJNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bHJ4EQSJxY3xNkJCPdttesOF4l7vwsYbjac0cVrl4Tc=; b=lsnZFlE1pyEyMIsiYHQrnNyqHhB9MF9pypv23H5ccTJfoIgiNAux06S0yUiDUbGg1e Gd+UUgP/JVDhZIQFCDv3+4s1V+emT/bXI+VDcwMHbFZv6L+tLc+uTeKRmAG/XJ2EmNia Q9K8ExMgaNYLDcg2fsSdV0aNYI4RPZGjh1NXOffo7UsaCuJpOExD+CYR6gMv84aciEGU eBtG72zukDU/ZlXVpdX37waS6M5jiG1z1eAE+4ECHw8mvG+CG7gXNCwSqGL5FKzkAtZ4 C7dh3F0lc32nAvQSOMBExB9aGTTZhDjZEYEzT/QJVGnkkyZlUSo/qP76MKWrqML1NPch QvoQ== X-Gm-Message-State: AN3rC/4nPfZ06FEnDJRVKVyVPp6ggRmvFhJtx+0KrSKko7nEGGWIrtxZ abe96ircln3LxKiPzgS16nZ/vB3o1w== X-Received: by 10.176.91.94 with SMTP id v30mr1933643uae.37.1492638471329; Wed, 19 Apr 2017 14:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.123.214 with HTTP; Wed, 19 Apr 2017 14:47:50 -0700 (PDT) Received: by 10.103.123.214 with HTTP; Wed, 19 Apr 2017 14:47:50 -0700 (PDT) In-Reply-To: References: From: Suresh Krishnan Date: Wed, 19 Apr 2017 17:47:50 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf?= =?UTF-8?Q?=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden Cc: "Mirja Kuehlewind (IETF)" , 6man-chairs@ietf.org, IESG , 6MAN <6man@ietf.org>, "draft-ietf-6man-rfc2460bis@ietf.org" , tsvwg , "C. M. Heard" Content-Type: multipart/alternative; boundary=f403045f907edc9c2d054d8bf935 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:47:54 -0000 --f403045f907edc9c2d054d8bf935 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: Mike, > On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: > > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >> This text does not make any normative statement on the question if the >> behavior specified in RFC3168 should be implemented or not. It only says >> please look at RFC3168 and make an informed decision if you want to confirm >> to the behavior that is specified in RFC3168 in addition to implementing the >> spec in this document. However, yes, this statement is true for all IPv6 >> implementation. I don't see a problem here... > > Nor do I. As it happens I prefer the text proposed by Bob Hinden (with > David Black's modification) but I believe that the effect is essentially the > same as the text you proposed. So it seems that the discussion is boiling > down to editorial issues, and I am happy to leave that between you, > the shepherd, and the document editor. The current text I have is: Nodes that support Explicit Congestion Notification [RFC3168] use information in the Traffic Class field from all fragment packets to reconstruct the Traffic Class field in the reassembled packet. See Section 5.3 of RFC3168 for more information. This looks good to me as well. My only concern with the previous version was that it sounded normative. Regards Suresh --f403045f907edc9c2d054d8bf935 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bob,=C2=A0

On Apr 19, 2017 5:16 PM, "Bob Hinden" <= bob.hinden@gmail.com> wrote:=
Mike,

> On Apr 19, 2017, at 10:54 AM, C. M. Heard <heard@pobox.com> wrote:
>
> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote:
>> This text does not make any normative statement on the question if= the
>> behavior specified in RFC3168 should be implemented or not. It onl= y says
>> please look at RFC3168 and make an informed decision if you want t= o confirm
>> to the behavior that is specified in RFC3168 in addition to implem= enting the
>> spec in this document. However, yes, this statement is true for al= l IPv6
>> implementation. I don't see a problem here...
>
> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with=
> David Black's modification) but I believe that the effect is essen= tially the
> same as the text you proposed. So it seems that the discussion is boil= ing
> down to editorial issues, and I am happy to leave that between you, > the shepherd, and the document editor.

The current text I have is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nodes that support Explicit Congestion No= tification [RFC3168]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use informatio= n in the Traffic Class field from all fragment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets to reconstruct the Traffic Class = field in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reassemb= led packet.=C2=A0 See Section 5.3 of RFC3168 for more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information.
=


This looks good to me as well. My only concern with the previous= version was that it sounded normative.=C2=A0

Regards=C2=A0
Suresh=C2=A0

--f403045f907edc9c2d054d8bf935-- From nobody Wed Apr 19 15:15:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DAC129BBF; Wed, 19 Apr 2017 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 D-v_44RrDoqq; Wed, 19 Apr 2017 15:15:18 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 F283F12950A; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id m36so31724130qtb.0; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=aAa/7HvZwtIO9iDkj9n8Wq/j6Z6d5qW/K1YhlFReMa5spVSM5Lo3a4Q/X/paYd+Nuv Np39u+hbcNpiaWwdoNzzefWslfbi6IZ6ToPpKoIp/36NQVLnWt6mS0rf+GCimKhS3Cen 8fF9sIibJZBxAx0h4hqPArvDKgXHbdmCvYMAbwq8FvJ9A8eHKdJgPObKwa3HaLqmzcnt xhwMegIcF9aKcMlEZYFRVzrrPTu2TeAfaGQRyRwHYfMldADWIA3Lx5Vkslkz5JFrnQSt QTRO51uS/COia7D1XcpThiQuOCqk8rKjPkIlayCIhLiLHXmxWtsz+r6PU0AuyGYbJ0Z6 5uLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vzEkAXCY7FJsIexOypcsXKg2PSMdDvJB6HZg5m7ycsY=; b=jspemVwp2VO3vuwU+SNgPdvphkDuVh6XSLFG5LFqU4Vky8Lm8tGOyBvVcKvJwKrEuR fKTekgg3b92fY7dE1QERLXZSB86zvu/ghOV2XLauFg6aL32+5gD4ZxZhcm+sFV4fg+o1 e9D/f4Pam0j6KQeLiVE+5G2KUF6+3IucVJxXAbvgEui75rkfK9GOCyKAgwKXUvc9Z50P J1BwjjiFtvc3FFDSkt+ae48nBDj10sSTPu6/YZ42EIdmN9Cr54tlz4+hrEk1dqHkMj68 DgSMJqhPUD7U9ephnpTEIY9uAHsxGZr3Zsr/BxUZHRR6oPxN1G4V67CrUKGdeUiDc4xR sHSQ== X-Gm-Message-State: AN3rC/4gahTRUbkhUCg27n5tMwpz7X306HebERuhpVEUdT0k9c953aRP UE+RsFpFtIMiG+BQtpvBPtFWaeHwWA== X-Received: by 10.237.57.170 with SMTP id m39mr4733481qte.163.1492640117020; Wed, 19 Apr 2017 15:15:17 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Wed, 19 Apr 2017 15:15:16 -0700 (PDT) In-Reply-To: References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <097C5D0E-5708-4CE4-989A-0174B11D1B25@employees.org> <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com> <20391B01-0677-4E55-B83F-B517A32B7066@employees.org> <6675ff16-7294-5623-1e44-7bd3d41aed2b@si6networks.com> <3edf94e6-3fde-03f8-21ec-f02b37fa83fa@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 19 Apr 2017 15:15:16 -0700 X-Google-Sender-Auth: pgHIftga7RlC6QZJwc-R8_B9WTQ Message-ID: Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6 To: Fernando Gont Cc: Ole Troan , Gunter Van De Velde , "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org Operations" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:15:19 -0000 At Tue, 18 Apr 2017 15:15:37 +0100, Fernando Gont wrote: > > You will probably save everyone a lot of energy if you just admit > > you had missed it, and moved on. > > Huh? > > I obviously missed it. But this should still be in RFC2460 (or > rfc2460bis, FWIW). RFC4443 is supposed to specify ICMPv6, nt forwarding > for IPv6 packets. > > Having important requirements spread into a number of documents where > they don't belong doesn't help, and in the long run takes more energy > (and creates more problems) than spending the energy in doing what is right. I see your point, but this is not the only case where a description in RFC4443 could also be in RFC2460 but isn't. Destination unreachable code 2 (Beyond scope of source address) is also related to forwarding, but it's not documented in RFC2460. Code 4 (Port unreachable) is a matter of upper layer consideration, but it's not documented in Section 8 of RFC2460. I'm sure there are more. In the ideal world we could make all these points perfect: everything is documented everywhere consistently with minimal redundancy or scattering but still avoiding to push everything in a single monster document. Obviously it's an impossible goal in the real world, and we should accept some level of redundancy or scattering (or even inconsistency as a matter of fact). In this particular case I personally think it's acceptable: the ICMPv6 specification is so fundamental, so I'd say it's reasonable to say that any serious implementer should read it carefully. There should always be someone who overlooks some particular point (like you missed this specific one), but that doesn't necessarily mean we should update the documentation so that that particular person would not have missed it. There would still be someone who miss it no matter redundantly we describe it. In that sense, I tend to agree with Ole. (But I wouldn't be opposed to making this in rfc2460bis either if that's the wg consensus, although at this moment no one else seems to think this is an issue to be fixed). -- JINMEI, Tatuya From nobody Wed Apr 19 15:47:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C02129B75 for ; Wed, 19 Apr 2017 15:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD2JJY0aAs85 for ; Wed, 19 Apr 2017 15:47:23 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 6828D129B63 for <6man@ietf.org>; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id g60so32203350qtd.3 for <6man@ietf.org>; Wed, 19 Apr 2017 15:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=LWo5QvaqyWu9LCNeu0Zx9M0gJTBuszzn38sRM82eo8brayV3j9xSpaoOeRF7fgZrtK hDU/miiOTrleinmc/Gj3SLGWO1tRwmx/a/bd6AO7TlsFhr/gYr3yCxs3188DBDhvkwU4 UOkB/D1mz3cALI88oGesjbRrrRaCMX+h/5wtcAUa6zu32Df/0Duysb/NGJ8yf8LEfxvx m334B/u89yFyfrhF2KCftQCfctNQw38kt5Noixc5pH8KJVyrBXLYTKm/tlQMdantmMPh 7PNYkL7nADOm46vCxQvpbV4G3s+4h47hw+eHLWl8jbCxaA1jJtaeErgm60XZUj1IOHZB NGLg== 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=E2woGOgy8yWSa+a4aikB5m5Bjiz8XnZVhJsGSL/Rw4o=; b=ln2AhisHIGj8j2sdthYiMgIDfWcV8qmOU7MDbxf73pCXQ47o/q39EJahUyKbhARbIU 69TIzEt+qiNO8q5RJTZX3c7/bMLw6iKHZCMt2C1vgJfZkPjhRUluQviB6HFDcCloCvXT 7y3dy5ETOgnFqq0OFija873b+50wXhcvxB0Y5P758Hi9fXxI+ZJEM5798C4O1QcVcl6i wv1SE5iQD1aCeqB9u5a2IRrRl2Z5l3TcKURLJwa3V4rWiAJtqMR4vaQoFinlyVkvgAsy cR2xTlL1M/DETgJEw4jUHbXeq7oWGEDvfAQoLOVFC0DpcqafiAJ6NONyfMzLXEqKK14/ ouNg== X-Gm-Message-State: AN3rC/7iYZQzCUHEUGuHaPoya7kLC1U32tC8rHxhZDiKwZqWMPHMFmvg DE7CI0dwNwCd/A== X-Received: by 10.200.37.136 with SMTP id e8mr5154297qte.30.1492642041608; Wed, 19 Apr 2017 15:47:21 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 144sm2900007qkj.35.2017.04.19.15.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 15:47:20 -0700 (PDT) From: Ted Lemon Message-Id: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] Date: Wed, 19 Apr 2017 18:47:19 -0400 In-Reply-To: <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> Cc: "opsec@ietf.org" , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> To: james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:47:26 -0000 --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios = where IP addresses are not publicly reachable, despite their global = address scope. They MUST NOT appear in the default-free routing domain = of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize them. Changing the first "globally" to "publicly" isn't necessary. Actually, = I think this whole change just makes things less clear. Publicly and = globally mean the same thing. ULAs are never globally reachable. If = you have more than one site, and route ULAs between them, the ULAs have = to be routed over your private links, not over the public internet. I = get that in principle it may be possible to route your ULAs over a link = that also carries global traffic and that is not "your link," but it = would be better to clarify this in an additional paragraph; by adding = the text where you have, you are going to confuse the heck out of any = reader who doesn't know what a "multilateral link" is. --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Apr 19, 2017, at 5:15 PM, james woodyatt <jhw@google.com> = wrote:
Unique Local Addresses (ULA) [RFC4193] are intended for = scenarios where IP addresses are not publicly reachable, despite their = global address scope. They MUST NOT appear in the default-free routing = domain of the public Internet, and gateways at the boundaries of private = routing domains SHOULD NOT forward packets from or to ULA addresses = where multilateral transit agreements do not explicitly recognize = them.

Changing the first "globally" to "publicly" isn't = necessary.  Actually, I think this whole change just makes things = less clear.   Publicly and globally mean the same thing.   = ULAs are never globally reachable.   If you have more than one = site, and route ULAs between them, the ULAs have to be routed over your = private links, not over the public internet.   I get that in = principle it may be possible to route your ULAs over a link that also = carries global traffic and that is not "your link," but it would be = better to clarify this in an additional paragraph; by adding the text = where you have, you are going to confuse the heck out of any reader who = doesn't know what a "multilateral link" is.

= --Apple-Mail=_BD63AD1E-19BD-4A8D-9935-CF2D37FB4045-- From nobody Wed Apr 19 15:51:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86F712E852 for ; Wed, 19 Apr 2017 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 WQgLIoqLXzxC for ; Wed, 19 Apr 2017 15:51:08 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A32129BBD for <6man@ietf.org>; Wed, 19 Apr 2017 15:51:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=WxrCB7MVbiIlSPSBhrEzmFuazYmKG1F+BhCQgyWM2RHljkKJSTEyl925Rbqnfgoa4c70Vyln7LJ8rsbkj12ewLDYLiHVtsG5I+XkIGIZQ0wdhHtPOCHGkldd7C/mGSGNfzYGZBcp0464kvN9M8N5tnO/Vy3uQ4bSE8ozlqTY+AE=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 7349 invoked from network); 20 Apr 2017 00:44:25 +0200 Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 20 Apr 2017 00:44:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D__Mirja_K=C3=BChlewind=27s_Discuss_on_?= =?utf-8?Q?draft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 20 Apr 2017 00:44:05 +0200 Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170419224425.7338.7651@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:51:09 -0000 Hi, I really don=E2=80=99t like the term "Nodes that support Explicit = Congestion Notification=E2=80=9C. I guess we understand something = different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that = word to avoid any confusion. Thanks, Mirja > Am 19.04.2017 um 23:47 schrieb Suresh Krishnan = : >=20 > Hi Bob,=20 >=20 > On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: > Mike, >=20 > > On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: > > > > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: > >> This text does not make any normative statement on the question if = the > >> behavior specified in RFC3168 should be implemented or not. It only = says > >> please look at RFC3168 and make an informed decision if you want to = confirm > >> to the behavior that is specified in RFC3168 in addition to = implementing the > >> spec in this document. However, yes, this statement is true for all = IPv6 > >> implementation. I don't see a problem here... > > > > Nor do I. As it happens I prefer the text proposed by Bob Hinden = (with > > David Black's modification) but I believe that the effect is = essentially the > > same as the text you proposed. So it seems that the discussion is = boiling > > down to editorial issues, and I am happy to leave that between you, > > the shepherd, and the document editor. >=20 > The current text I have is: >=20 > Nodes that support Explicit Congestion Notification [RFC3168] > use information in the Traffic Class field from all fragment > packets to reconstruct the Traffic Class field in the > reassembled packet. See Section 5.3 of RFC3168 for more > information. >=20 >=20 > This looks good to me as well. My only concern with the previous = version was that it sounded normative.=20 >=20 > Regards=20 > Suresh=20 >=20 From nobody Wed Apr 19 17:10:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B271E12EAC7; Wed, 19 Apr 2017 17:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 D-l0QNLey6Bu; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 7B6F112EAC9; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k87so44229524ioi.0; Wed, 19 Apr 2017 17:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=nD0YNrldyPrnH/7BO20sXQedBRpcCcukGgrN6pdwFvhfjnvSISucqEw9rFPl7Nx+Ri S7ltn7yyM/Rjx/gXNDNXKF1XHomGbKEw3BCVI/SI0agPml4eaUYSDMPT52WoCx5864kw ruCpNwb7cemvkssacRV9bZbepPZDg0ofWJhj5x7vEbMql6FE7LBFvoYwRpoaGuJsKW8x TdiykNNUoOEw9OUfAuOb4kGVbijewsK+ove8giVrjrqJ02aEFsvyUIjaxSMSSjh8oWE7 n9+QkNsEF01lnbC3UXSS4oDgdgiIhq6mGwtYXBVHSFXxj2ibehs6szGHS01ByuGKWJQk HSvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=qRBkmVlojpaC+zC9sQ6BJdIGagwKnd2/TW+vRijJ9kg=; b=EZereMZ+3DtC0j1KgjsMwtYtGpHxg9KlzrNDzflpIMJRnxZZGWduIfEFFHmBThrJqk 7Fu+Jo0c2PM2KumrVydEbD+4pUTQVLKv+MIVfQyn2YGTT7NT1euezTRN8iNee9nppVmq 3xfN9tMz5pjHMiz8SPVjGjbIyWvaQoE532zcK1lESak3MCbaIv1bv7DI1vZn92U6Avb9 mkYuRwBTeKXCtmz/EfqlRGrM4EG1nyflLk039u759HOxmNcncM/YSmD9eF2SzU8phSiA n0ouG5IE0t88cAWdhYcNeMn6FvD3VzKPAFT0OeW2N3qCArZBNVQRy4OvpdMswCI/t3Ro A/Ig== X-Gm-Message-State: AN3rC/7OGAkJB1NSr1jJjvYoA7y0TGJv0AeklWeJWgTis9sYfBqT3m1T Ey+fb21VIaBBxg== X-Received: by 10.99.9.66 with SMTP id 63mr5519822pgj.22.1492647040098; Wed, 19 Apr 2017 17:10:40 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id j73sm6499308pfe.108.2017.04.19.17.10.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 17:10:39 -0700 (PDT) Subject: Re: [v6ops] ULAs [was [OPSEC] WGLC for draft-ietf-opsec-v6] To: Ted Lemon , james woodyatt References: <55cb757e-ee2d-4818-9fc2-67d559006f34@me.com> <3E179F05-ACCD-4290-A65F-57E4202FAA15@icloud.com> <098b84a4-80d4-2404-72a1-5d1cd32a9968@gmail.com> <4E19A596-5B69-4535-A29A-D08874DDC365@google.com> <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Cc: "opsec@ietf.org" , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Apr 2017 12:10:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <32929141-250E-44FC-BC67-2B97B373872E@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 00:10:43 -0000 On 20/04/2017 10:47, Ted Lemon wrote: > On Apr 19, 2017, at 5:15 PM, james woodyatt wrote: >>>> Unique Local Addresses (ULA) [RFC4193] are intended for scenarios where IP addresses are not publicly reachable, despite their global address scope. They MUST NOT appear in the default-free routing domain of the public Internet, and gateways at the boundaries of private routing domains SHOULD NOT forward packets from or to ULA addresses where multilateral transit agreements do not explicitly recognize them. > > Changing the first "globally" to "publicly" isn't necessary. Actually, I think this whole change just makes things less clear. Publicly and globally mean the same thing. ULAs are never globally reachable. If you have more than one site, and route ULAs between them, the ULAs have to be routed over your private links, not over the public internet. I get that in principle it may be possible to route your ULAs over a link that also carries global traffic and that is not "your link," but it would be better to clarify this in an additional paragraph; by adding the text where you have, you are going to confuse the heck out of any reader who doesn't know what a "multilateral link" is. Also, "globally reachable" is a term of art in draft-bchv-rfc6890bis and in the new form of the IANA registry that it defines. Once that's final, there is work to do elsewhere (for example, the de facto meaning of "global" in the Python ipaddress module is plain wrong). So this is important terminology. I have no problem mentioning transit agreements, but I think James' SHOULD NOT should also be a MUST NOT. My routing friends tell me that there's no such thing as a true DFZ any more, too. Brian From nobody Wed Apr 19 17:14:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539DB12EACD for ; Wed, 19 Apr 2017 17:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 5hBIKiVta43b for ; Wed, 19 Apr 2017 17:13:59 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 E9AEA12EAD4 for ; Wed, 19 Apr 2017 17:13:58 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id k87so9177440ioi.0 for ; Wed, 19 Apr 2017 17:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vfCaKnsg4TjfxVzNj5+yhcb/Z3Lzukz9pj4qhyl3unE=; b=cyYmW3Lebap5+R2xfA8f5R+oZIB8Szq1D5svlZ1RieIigMX5C4r3HXAHKvQOJjh8j/ f0mPtkVMx1c3oUoZG5SKH3XoE5oMBbpWd3OzUqmgcyi8lgrssupzOQurqlB43maxFX7V It1kqFzsLyeqYg4Pr72Sk1+qMRRkp+9/cwPXaU873IwYLmW5XTX4gM/kKXxMD3j7yebt 5Kik1LBqwDmiZ8Q+adNZ1hZcG6tfDeKnkcMtZMTC0sfiAd/4rMHhB55Y6bRWn9Xh7m9W Oh4DDGQo3tfmsQ9WHVnzkU808fIVsq47czuW3Hhg2Zf5ihyvks2FPeqOM2vC3Gttf9yj zCng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=vfCaKnsg4TjfxVzNj5+yhcb/Z3Lzukz9pj4qhyl3unE=; b=GfZ1zNwkl4ES+EIskWQI33477CB7PTyXEjVRa21PpxdQUhTX947NJdf9xv9YxnSSLX 4M57gYQcD7PuXabdkOylqff1FPAyYO/PdJ5EwT5fAy0HoC3feiOAlSrJGq9TSTQ65/xb F8NCeJ6cJBi89iGYorxnl1oSA+P0PbRriPSJX5YIgASeHwcfK+Ctjf8Fy/eD2wMGrfTZ o72luIYPGjOb1b2ZYlOqWxjHXFPIiMVUMUp+txvV16huChkrecbk/fkAzPuHwmXmTFcQ +Qtd3MYhdJl47BErwa+VrysZJAA4ayv5fUL1o9V37sEVPxW4TTSEQchlVhiRMNufhiCm 8EyA== X-Gm-Message-State: AN3rC/5lmwElKRaRJxrwXmcUCdHhmm0rUDchRZp0w0SKYLnkt9HTZlBe Qvu8925etd+xDw== X-Received: by 10.98.129.193 with SMTP id t184mr5498096pfd.130.1492647238273; Wed, 19 Apr 2017 17:13:58 -0700 (PDT) Received: from [130.216.38.132] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.132]) by smtp.gmail.com with ESMTPSA id j73sm6505012pfe.108.2017.04.19.17.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 17:13:57 -0700 (PDT) Subject: Re: Revised and expanded rfc2460bis Security Considerations To: james woodyatt , Bob Hinden References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> Cc: Eric Rescorla , IETF IPv6 Mailing List From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 20 Apr 2017 12:14:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 00:14:01 -0000 On 20/04/2017 09:34, james woodyatt wrote: > On Apr 19, 2017, at 13:55, Bob Hinden wrote: >> >> The current and proposed new text is below. Please review and comment= s. I hope to publish a new draft at the end of the week. >=20 > Bravo! Alas, I have a nit. +1 Should we include references where they exist, e.g. for scanning attacks = and address privacy? Brian >=20 >>> [...] These security issues include: >>> >>> o Eavesdropping [...] >>> o Replay [...] >>> o Message insertion [...] >>> o Message modification [...] >>> o Man in the Middle attacks [...] >>> o Denial of Service Attacks [...] >>> >>> IPv6 packets can be protected from eavesdropping, packet modification= , replay, and man in the middle attacks by use of [...] >=20 > p1. The order used to present the list of security issues should be als= o be used to present the methods of protection. >=20 > p2. The issue =E2=80=9Cmessage modification=E2=80=9D changes to =E2=80=9C= packet modification=E2=80=9D from one list to the next. I think this shou= ld be clarified. >=20 > p3. No further mention of =E2=80=9Cmessage insertion=E2=80=9D is made a= fter its appearance in the list of issues, even one similar to the =E2=80= =9Cdenial of service attack=E2=80=9D issue, to explain that no defensive = mechanism is defined, and it is left out of scope for this specification.= >=20 >=20 > --james woodyatt >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Apr 19 17:51:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B43E1293EC; Wed, 19 Apr 2017 17:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=WbBLvaLe; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=M2SjlXJp 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 qZlVJinCb0Lz; Wed, 19 Apr 2017 17:51:21 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F91C126557; Wed, 19 Apr 2017 17:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1492649481; x=1524185481; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cRHzvUdushcIvz5qR8+4dbqYi2Cu03Ttxk8xRSJfYBU=; b=WbBLvaLeji6wzixzseR/jSWF7Q1q+LDJIc/DhjUzfzoiniAEVigjgVqP TZoUcBV0/hSxQCSXYfuPTBfN/v6yn6auMFLlrYkPPMKlFTGe3S+evy2zO n/3x5+3oFIac+Hmn37xXPxgZJY09fh+nmSM2DGpRsGCXR+DZoCNwK6/ag 8=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 19:51:20 -0500 From: "Black, David" Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 06:51:19 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3K0pFGx025773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 19 Apr 2017 20:51:18 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v3K0pFGx025773 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1492649479; bh=XmuOI+/iqRsZeyVpqmwUqO9Zyj0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=M2SjlXJpRSfHN7zTfrR+2w6XmvnEcBHnN3OAU3oXci6MTa86LF/JaFegMXIDHtJoN fueWIaq2ePskCnm9luQdCiYM6ugEnaSlxo3k+gK03D/Z++BULbvV856CbC1P0mIpUR o09uW9mlWK30FLBBpYDfwpWghhKbbtx8TlqTJR/g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v3K0pFGx025773 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 19 Apr 2017 20:50:49 -0400 Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v3K0ow5C006950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 19 Apr 2017 20:50:58 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0266.001; Wed, 19 Apr 2017 20:50:53 -0400 To: "Mirja Kuehlewind (IETF)" , Suresh Krishnan Subject: =?utf-8?B?UkU6IFt0c3Z3Z10gIE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRy?= =?utf-8?B?YWZ0LWlldGYtNm1hbi1yZmMyNDYwYmlzLTA5OiAod2l0aCBESVNDVVNTIGFu?= =?utf-8?Q?d_COMMENT)?= Thread-Topic: =?utf-8?B?W3RzdndnXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi02bWFuLXJmYzI0NjBiaXMtMDk6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHSuStgZu6NHGLLOU+TvYwkOtjBVaHNNH0AgAAIRQCAADhnAP//xdbdgABSnYD//9MTIA== Date: Thu, 20 Apr 2017 00:50:53 +0000 Message-ID: References: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net> In-Reply-To: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 00:51:23 -0000 QmFzZWQgb24gQnJpYW4ncyBjb21tZW50IG9uIERTQ1AsIG9ubHkgdGhlIEVDTiBwb3J0aW9uIG9m IHRoZSB0cmFmZmljIGNsYXNzIGZpZWxkIGlzIGludm9sdmVkLg0KDQpJIGFncmVlLCBidXQgb2Zm ZXIgc29tZSBtb3JlIGV4cGxhbmF0aW9uIGFib3V0IGFub3RoZXIgc2NlbmFyaW8uICBJIGNvdWxk IHNlZSBhIHRyYWZmaWMgc2hhcGVyIGNoYW5naW5nIEFGIGRyb3AgcHJlY2VkZW5jZSBvbiBzb21l IGZyYWdtZW50cyBidXQgbm90IG90aGVycyB3aXRob3V0IGxvb2tpbmcgdG8gc2VlIHdoZXRoZXIg b3Igbm90IGFueSBmcmFnbWVudCBjb250YWlucyBhIHRyYW5zcG9ydCBwcm90b2NvbCBoZWFkZXIu ICBPVE9ILCB0byBhIGZpcnN0IGFwcHJveGltYXRpb24sIGJlY2F1c2UgdGhhdCBzaGFwZXIncyBu b3QgbG9va2luZyBiZXlvbmQgdGhlIElQIGhlYWRlcnMsIHRoZSBsaWtlbGlob29kIG9mIGl0IHJl bWFya2luZyBhIGZpcnN0IGZyYWdtZW50IHNob3VsZCBiZSB0aGUgc2FtZSBhcyBpdHMgb3ZlcmFs bCByZW1hcmtpbmcgbGlrZWxpaG9vZCwgaGVuY2UgcmVhc3NlbWJseSBiYXNlZCBvbiB0aGUgRFND UCBpbiB0aGUgZmlyc3QgZnJhZ21lbnQgKGUuZy4sIGF0IGEgdHVubmVsIGVncmVzcykgc2hvdWxk IG9uIGF2ZXJhZ2UgcmVzdWx0IGluIHRoZSBzYW1lIGRlZ3JlZSBvZiByZW1hcmtpbmcgaW4gdGhl IHJlYXNzZW1ibGVkIHBhY2tldCBzdHJlYW0gYXMgd2FzIGluIHRoZSBmcmFnbWVudGVkIHBhY2tl dCBzdHJlYW0uICAgVGhlIHNoYXBlciBoYXMgY29uc2lzdGVudCBsb25nLXRlcm0gYmVoYXZpb3Is IHdoZXJlIGxvbmcgdGVybSBtZWFucyBtYW55LCBtYW55IFJUVHMgZm9yIHRoZSBmbG93cyBpbnZv bHZlZCwgc28gYW4gYXBwZWFsIHRvIHRoaW5ncyBhdmVyYWdpbmcgb3V0IGlzIHBsYXVzaWJsZS4g IEluIGNvbnRyYXN0LCBFQ04gb3BlcmF0ZXMgb24gUlRUIHRpbWVzY2FsZSwgbWFraW5nIHRoaXMg YXZlcmFnaW5nIHJhdGlvbmFsZSBpbmFwcGxpY2FibGUgdG8gRUNOLg0KDQpJIHdvdWxkIGNhbGwg RUNOIG91dCBleHBsaWNpdGx5Og0KDQogICAgICAgICAgTm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxp Y2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIFtSRkMzMTY4XQ0KICAgICAgICAgIHVz ZSBFQ04gIGluZm9ybWF0aW9uIGluIHRoZSBUcmFmZmljIENsYXNzIGZpZWxkIGZyb20gYWxsIGZy YWdtZW50DQogICAgICAgICAgcGFja2V0cyB0byByZWNvbnN0cnVjdCB0aGUgRUNOIHBvcnRpb24g b2YgdGhlIFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4NCiAgICAgICAgICB0aGUgcmVhc3NlbWJsZWQg cGFja2V0LiAgU2VlIFNlY3Rpb24gNS4zIG9mIFJGQzMxNjggZm9yIG1vcmUNCiAgICAgICAgICBp bmZvcm1hdGlvbi4NCg0KQmV5b25kIHRoYXQsIEkgaGF2ZSB0byBjb25jdXIgd2l0aCBzb21lIHBh cnQgb2YgTWlyamEncyB1bmRlcmx5aW5nIGNvbmNlcm4gYWJvdXQgd2hhdCAiTm9kZXMgdGhhdCBz dXBwb3J0IiBtZWFucy4gICBTdXBwb3NlIEkgaGF2ZSBhIHVzZXItbW9kZSBTQ1RQIGltcGxlbWVu dGF0aW9uIHRoYXQgdXNlcyBFQ04gaW4gdGhlIFVEUCBlbmNhcHN1bGF0aW9uICh0aGluayBXZWIg UlRDKSBhbmQgYW4gSVB2NiBrZXJuZWwtbW9kZSBpbXBsZW1lbnRhdGlvbiB0aGF0IHVzZXMgb25s eSB0aGUgZmlyc3QgZnJhZ21lbnQncyBFQ04gY29kZXBvaW50IGluIGRvaW5nIEVDTiByZWFzc2Vt Ymx5LiAgIENvbmdlc3Rpb24gaW5kaWNhdGlvbnMgaW4gb3RoZXIgdGhhbiB0aGUgZmlyc3QgZnJh Z21lbnQgYXJlIGxvc3QsIHdoaWNoIGlzIGJhZC4gIFRoZSBvcHRpb25zIGZvciBicmluZ2luZyBz dWNoIGFuIElQdjYgaW1wbGVtZW50YXRpb24gaW50byBjb21wbGlhbmNlIHdpdGggUkZDIDMxNjgg d2l0aG91dCBkb2luZyBhbGwtZnJhZ21lbnQgRUNOIHJlYXNzZW1ibHkgYXJlIG5vdCBwcmV0dHk6 DQoJLSBBbHdheXMgY2xlYXIgdGhlIEVDTiBmaWVsZCB0byBub3QtRUNUIChpLmUuLCAwMCkgb24g b3V0Ym91bmQgdHJhZmZpYy4gVGhpcyBzaG91bGQgYmxvY2sgYW55IG5lZ290aWF0aW9uIG9mIEVD TiBieSBoaWdoZXItbGV2ZWwgcHJvdG9jb2xzLg0KCS0gRHJvcCBhbnkgaW5ib3VuZCBmcmFnbWVu dGVkIHBhY2tldC4NClRoZSAiY29tcGxldGVseSBjb3JyZWN0IiBkZWZpbml0aW9uIG9mICJOb2Rl cyB0aGF0IGRvIG5vdCBzdXBwb3J0IEVDTiIgcHJvYmFibHkgaW5jbHVkZXMgY2xlYXJpbmcgdGhl IEVDTiBmaWVsZCB0byBub3QtRUNUIG9uIG91dGJvdW5kIHRyYWZmaWMgLSBpcyB0aGUgY29uY2Vy biB0aGF0IHdlJ3JlIGxvb2tpbmcgYXQgSVB2NiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhbGxvdyBF Q04gdXNhZ2UgaW4gb3V0Ym91bmQgdHJhZmZpYyBidXQgZG9uJ3QgZ2V0IEVDTiBjb3JyZWN0IGlu IGZyYWdtZW50IHJlYXNzZW1ibHkgZm9yIGluYm91bmQgdHJhZmZpYz8NCg0KVGhhbmtzLCAtLURh dmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0 bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamENCj4gS3VlaGxld2lu ZCAoSUVURikNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOSwgMjAxNyA2OjQ0IFBNDQo+IFRv OiBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+DQo+IENjOiBkcmFm dC1pZXRmLTZtYW4tcmZjMjQ2MGJpc0BpZXRmLm9yZzsgNk1BTiA8Nm1hbkBpZXRmLm9yZz47IHRz dndnDQo+IDx0c3Z3Z0BpZXRmLm9yZz47IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+OyBC b2IgSGluZGVuDQo+IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IElFU0cgPGllc2dAaWV0Zi5vcmc+ OyA2bWFuLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RzdndnXSBNaXJqYSBLw7xo bGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpcy0NCj4gMDk6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBIaSwNCj4gDQo+IEkgcmVhbGx5IGRvbuKA mXQgbGlrZSB0aGUgdGVybSAiTm9kZXMgdGhhdCBzdXBwb3J0IEV4cGxpY2l0IENvbmdlc3Rpb24N Cj4gTm90aWZpY2F0aW9u4oCcLiBJIGd1ZXNzIHdlIHVuZGVyc3RhbmQgc29tZXRoaW5nIGRpZmZl cmVudCB1bmRlciDigJ5zdXBwb3J04oCcDQo+IGJ1dCBtYXliZSBjYW4ganVzdCBhdm9pZCB0aGF0 IHdvcmQgdG8gYXZvaWQgYW55IGNvbmZ1c2lvbi4NCj4gDQo+IFRoYW5rcywNCj4gTWlyamENCj4g DQo+IA0KPiA+IEFtIDE5LjA0LjIwMTcgdW0gMjM6NDcgc2NocmllYiBTdXJlc2ggS3Jpc2huYW4N Cj4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+Og0KPiA+DQo+ID4gSGkgQm9iLA0KPiA+DQo+ ID4gT24gQXByIDE5LCAyMDE3IDU6MTYgUE0sICJCb2IgSGluZGVuIiA8Ym9iLmhpbmRlbkBnbWFp bC5jb20+IHdyb3RlOg0KPiA+IE1pa2UsDQo+ID4NCj4gPiA+IE9uIEFwciAxOSwgMjAxNywgYXQg MTA6NTQgQU0sIEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdyb3RlOg0KPiA+ID4NCj4g PiA+IE9uIFdlZCwgQXByIDE5LCAyMDE3IGF0IDEwOjI1IEFNLCBNaXJqYSBLw7xobGV3aW5kIHdy b3RlOg0KPiA+ID4+IFRoaXMgdGV4dCBkb2VzIG5vdCBtYWtlIGFueSBub3JtYXRpdmUgc3RhdGVt ZW50IG9uIHRoZSBxdWVzdGlvbiBpZiB0aGUNCj4gPiA+PiBiZWhhdmlvciBzcGVjaWZpZWQgaW4g UkZDMzE2OCBzaG91bGQgYmUgaW1wbGVtZW50ZWQgb3Igbm90LiBJdCBvbmx5DQo+IHNheXMNCj4g PiA+PiBwbGVhc2UgbG9vayBhdCBSRkMzMTY4IGFuZCBtYWtlIGFuIGluZm9ybWVkIGRlY2lzaW9u IGlmIHlvdSB3YW50IHRvDQo+IGNvbmZpcm0NCj4gPiA+PiB0byB0aGUgYmVoYXZpb3IgdGhhdCBp cyBzcGVjaWZpZWQgaW4gUkZDMzE2OCBpbiBhZGRpdGlvbiB0byBpbXBsZW1lbnRpbmcNCj4gdGhl DQo+ID4gPj4gc3BlYyBpbiB0aGlzIGRvY3VtZW50LiBIb3dldmVyLCB5ZXMsIHRoaXMgc3RhdGVt ZW50IGlzIHRydWUgZm9yIGFsbCBJUHY2DQo+ID4gPj4gaW1wbGVtZW50YXRpb24uIEkgZG9uJ3Qg c2VlIGEgcHJvYmxlbSBoZXJlLi4uDQo+ID4gPg0KPiA+ID4gTm9yIGRvIEkuIEFzIGl0IGhhcHBl bnMgSSBwcmVmZXIgdGhlIHRleHQgcHJvcG9zZWQgYnkgQm9iIEhpbmRlbiAod2l0aA0KPiA+ID4g RGF2aWQgQmxhY2sncyBtb2RpZmljYXRpb24pIGJ1dCBJIGJlbGlldmUgdGhhdCB0aGUgZWZmZWN0 IGlzIGVzc2VudGlhbGx5IHRoZQ0KPiA+ID4gc2FtZSBhcyB0aGUgdGV4dCB5b3UgcHJvcG9zZWQu IFNvIGl0IHNlZW1zIHRoYXQgdGhlIGRpc2N1c3Npb24gaXMgYm9pbGluZw0KPiA+ID4gZG93biB0 byBlZGl0b3JpYWwgaXNzdWVzLCBhbmQgSSBhbSBoYXBweSB0byBsZWF2ZSB0aGF0IGJldHdlZW4g eW91LA0KPiA+ID4gdGhlIHNoZXBoZXJkLCBhbmQgdGhlIGRvY3VtZW50IGVkaXRvci4NCj4gPg0K PiA+IFRoZSBjdXJyZW50IHRleHQgSSBoYXZlIGlzOg0KPiA+DQo+ID4gICAgICAgICAgTm9kZXMg dGhhdCBzdXBwb3J0IEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFtSRkMzMTY4XQ0K PiA+ICAgICAgICAgIHVzZSBpbmZvcm1hdGlvbiBpbiB0aGUgVHJhZmZpYyBDbGFzcyBmaWVsZCBm cm9tIGFsbCBmcmFnbWVudA0KPiA+ICAgICAgICAgIHBhY2tldHMgdG8gcmVjb25zdHJ1Y3QgdGhl IFRyYWZmaWMgQ2xhc3MgZmllbGQgaW4gdGhlDQo+ID4gICAgICAgICAgcmVhc3NlbWJsZWQgcGFj a2V0LiAgU2VlIFNlY3Rpb24gNS4zIG9mIFJGQzMxNjggZm9yIG1vcmUNCj4gPiAgICAgICAgICBp bmZvcm1hdGlvbi4NCj4gPg0KPiA+DQo+ID4gVGhpcyBsb29rcyBnb29kIHRvIG1lIGFzIHdlbGwu IE15IG9ubHkgY29uY2VybiB3aXRoIHRoZSBwcmV2aW91cyB2ZXJzaW9uDQo+IHdhcyB0aGF0IGl0 IHNvdW5kZWQgbm9ybWF0aXZlLg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+IFN1cmVzaA0KPiA+DQoN Cg== From nobody Wed Apr 19 19:19:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F558129B30; Wed, 19 Apr 2017 19:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 YXmmmJkHnyFW; Wed, 19 Apr 2017 19:19:38 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 40E15129470; Wed, 19 Apr 2017 19:19:38 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id z129so8107798wmb.1; Wed, 19 Apr 2017 19:19:38 -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=43/iu3Ve8lKY25pyW6Me+3So5lFgEKTLhd3CEsRCMvY=; b=RUAXEV1Ti5hPZItjgw4p6KHX3t5v0mgN5+QQ4i67HVEyxlCPREGYzhAytfddbZmj1Z Msiy2hEIP6K928rTML2z+uk2bpngfCgtKRnmXwziL0Sp4UMkzYGdSzZ5InkyQXppmHl0 rDOS9eyKxHtxuvENOTbjirOfsfeIQp9aXdwY5FYTPp5u0LyoMSl9kYUysahXuYa0mtTb aMtn5x0763P1TjjidvsyFL5dPRICpfcXWuoaSYU9cj+RnrVXv6McsPTN6lDlsndkSEs6 01yoNjg+ujS6cqpvIgqV9+V+8F8uu+aTPVmvvvqw6N873kz7qxovpi2WhYDnWCpkxd2z t6DA== 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=43/iu3Ve8lKY25pyW6Me+3So5lFgEKTLhd3CEsRCMvY=; b=KjATi+yGm9P0CsM4EXnWwc/8HhDx7+BfZPtrfNu1n/OaoyoicCSPqv0W0FW8cWpviU zyKFRF8OzaDtoLMKzaQIW6alm1oExMMvj6jXdcQLyKDs0qirQhZLPVDy1nH+Xi5CKBS7 rQMSJsIcTNQ204CLB8gJhIDkcrOsad9jdj0u7goBRo4WsuBn8m4DS6GBbICS72QViaS9 81UBf6OZo0zq3tW7P1zsex1M3RET8r3WQc6miEFt8dk++co1rcCCnpqXx+qjL6w6+Hwj 0zntpoFJWoz0hlEG6itbRIP/MSz27vWzdUJTgnYUMTfjIFXwctGXWQrxUBWYfYdit4dn mbYw== X-Gm-Message-State: AN3rC/6W8q/Azco1OUm0fnuwERG+BN0hu/eO/1YlbW//2a6Wf7RL2agB 3nOzCHExtJPiBpTVVxc= X-Received: by 10.28.57.138 with SMTP id g132mr697697wma.92.1492654776701; Wed, 19 Apr 2017 19:19:36 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:9cf5:b82e:11d6:5b43? ([2601:647:4d01:db10:9cf5:b82e:11d6:5b43]) by smtp.gmail.com with ESMTPSA id v23sm5015683wra.65.2017.04.19.19.19.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 19:19:34 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_=5Btsvwg=5D__Mirja_K=C3=BChlewind=27s_Discuss_on_?= =?utf-8?Q?draft-ietf-6man-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Wed, 19 Apr 2017 19:19:28 -0700 In-Reply-To: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net> Cc: Bob Hinden , Suresh Krishnan , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <2EEDA924-5DD8-4B2A-B682-BA0F603F3126@kuehlewind.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 02:19:40 -0000 --Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, > On Apr 19, 2017, at 3:44 PM, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi, >=20 > I really don=E2=80=99t like the term "Nodes that support Explicit = Congestion Notification=E2=80=9C. I guess we understand something = different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that = word to avoid any confusion. While I think it=E2=80=99s clear, alternatives might be =E2=80=9Cimplement= =E2=80=9D, =E2=80=9Cperform=E2=80=9D, =E2=80=9Cpractice=E2=80=9D, = =E2=80=9Ceffect=E2=80=9D, etc. Bob >=20 > Thanks, > Mirja >=20 >=20 >> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan = : >>=20 >> Hi Bob, >>=20 >> On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: >> Mike, >>=20 >>> On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: >>>=20 >>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >>>> This text does not make any normative statement on the question if = the >>>> behavior specified in RFC3168 should be implemented or not. It only = says >>>> please look at RFC3168 and make an informed decision if you want to = confirm >>>> to the behavior that is specified in RFC3168 in addition to = implementing the >>>> spec in this document. However, yes, this statement is true for all = IPv6 >>>> implementation. I don't see a problem here... >>>=20 >>> Nor do I. As it happens I prefer the text proposed by Bob Hinden = (with >>> David Black's modification) but I believe that the effect is = essentially the >>> same as the text you proposed. So it seems that the discussion is = boiling >>> down to editorial issues, and I am happy to leave that between you, >>> the shepherd, and the document editor. >>=20 >> The current text I have is: >>=20 >> Nodes that support Explicit Congestion Notification [RFC3168] >> use information in the Traffic Class field from all fragment >> packets to reconstruct the Traffic Class field in the >> reassembled packet. See Section 5.3 of RFC3168 for more >> information. >>=20 >>=20 >> This looks good to me as well. My only concern with the previous = version was that it sounded normative. >>=20 >> Regards >> Suresh >>=20 >=20 --Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+BqxAAoJEK7rdBF357uoFFgH/j/GqFXj09R0obBciYx/+rUm fKdOsEh7HYoIYlMNoQxxDyp2RVJcC5Ozh9ue0B1D3LTuobJJrQwfawcziLuvLLwP FaNNGByAFMzjRQWfhPxIdoGefLGUFnuc2VZnggw6ZFb9/KC81n/LdBNgWSWmbVJ9 2i9sjc5S7fuhU3LU1L3PV/rds6KSHb6vdBSIGy/sAnn7pVwTDUXEZwUFq/DEwZ8F SkTxhea3fBHPKdV4RNZ5iYfuOAIEtrNfpWnj4AgoCAlUyMq79KXhUg5uIifAKGlb CSAIr5+MhkKPE/VZAIDxSonUUYGk5nM4tP8kzDpnqEu3HFENW5ZYrNimQxKYSVs= =R9aq -----END PGP SIGNATURE----- --Apple-Mail=_E6CB7AD2-2D83-4A30-AF46-9FDFF2B8F8FD-- From nobody Thu Apr 20 02:29:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2BC12EBCA; Thu, 20 Apr 2017 02:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 SO1cbF6Ma4QS; Thu, 20 Apr 2017 02:29:23 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A602112EBCD; Thu, 20 Apr 2017 02:29:15 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 09:29:14 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6686ED788B; Thu, 20 Apr 2017 02:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=a9Glekkg05ZI5gg9ejX24SHfAwE=; b= JX1X77u3kTWPMOXpP+YUjQMAZnqSlaYsq2mR6MLErRNPZFvPvW4yOwrQGenvrjBN yZFIGeCCtcF0RE0nkDh+IqOwuLAZHnyrJ/SVE/aa1tT3Jk1kX9rJIlNOpcBqW1K/ uFF3mRjL3AP+boDxBY+lpoTbBV4mJf58ofB/jwcwLmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=BJn1dcoCi5T6zcVeCDBui8d S9NJbT/VYNEQAZkZ4t5zam7KXc/FO1bPFYJIjz8aV2EltRDNXaCplwRlz4NuQEJr DJVv2njx+AccphkGYgy7QL+e3pC0pGpEPmstuFU/iKqwZTjtYK2SjyNs4eSMvlBq QKd57kxChs1ZcIQWkxVI= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 82F1DD788A; Thu, 20 Apr 2017 02:29:13 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 993A8AC1C033; Thu, 20 Apr 2017 11:29:10 +0200 (CEST) From: otroan@employees.org Message-Id: <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_334D4E55-795B-43AB-9F89-EDC4AEC949B7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 11:29:09 +0200 In-Reply-To: <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> Cc: Brian E Carpenter , Suresh Krishnan , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , IESG , 6man-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:29:26 -0000 --Apple-Mail=_334D4E55-795B-43AB-9F89-EDC4AEC949B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja, > Let me try to wrap this up. So what I learn is that HBH is used in = intra-domain scenarios and therefore must be further supported and = today=E2=80=99s routers are highly likely to drop packets with unknown = headers. In this sense I think the recommendation given could be further = clarified. Also I would rather see a discussion of the issue than just = given a specific recommendation forever, while people have still hope = that the situation might change (at least for HBH I assume). As such = I=E2=80=99ll go ahead and would like to propose new text for the = paragraphs in question, that is intended to conserve the current = recommendation but giving more background and phrase it more carefully. = Of course feel free to edit, I just thought it might be easier if I = simply propose some text: "today's routers are highly likely to drop packets with unknown = headers". No, I do not think we have data supporting that. Packets with unknown headers are most likely to be dropped at the = destination or by the destination AS. Which makes sense and one would = expect. If extension headers / options were defined that were useful, = one would also expect that the destination would stop dropping them of = course. Chicken and egg. Dropping unknown extension headers in transit networks is relatively = rare. With the HBH being an exception, with almost a 40% drop. (Note = that there are no HBH option that would make a lot of sense across the = Internet, so again chicken and egg.) Data from: https://btv6.vyncke.org/exthdr/index.php?ds=3Dalexa2015&t=3Ddo With regards to your text, I certainly wouldn't say "Network nodes may = be configured to drop...". That's exactly the opposite of what we would = like to say. ;-) The current (OLD) text went through many many iterations in the working = group. I must say I still prefer that text, and I'm not sure what value = the new proposal adds. Adding new extension headers are of course still = permitted (within the number space available). This note I really there = as a "Reader beware, there are dangers in these waters". In the context of elevating 2460 I really don't think there is anything = wrong with the current text. We are limited by RFC6410 in what we can = do. If you want different and new behaviour there is of course nothing = stopping you from proposing that in a separate document. Best regards, Ole >=20 > OLD: > New hop-by-hop options are not recommended because nodes may be > configured to ignore the Hop-by-Hop Option header, drop packets > containing a hop-by-hop header, or assign packets containing a hop- > by-hop header to a slow processing path. Designers considering > defining new hop-by-hop options need to be aware of this likely > behaviour. There has to be a very clear justification why any new > hop-by-hop option is needed before it is standardized. >=20 > Defining new IPv6 extension headers is not recommended. There has = to > be a very clear justification why any new extension header is needed > before it is standardized. Instead of defining new Extension > Headers, it is recommended that the Destination Options header is > used to carry optional information that must be examined only by a > packet's destination node(s), because they provide better handling > and backward compatibility. >=20 >=20 > NEW: > Network nodes may be > configured to ignore the Hop-by-Hop Option header, drop packets > containing a hop-by-hop header, or assign packets containing a hop- > by-hop header to a slow processing path. When using or defining new > hop-by-hop options this likely behaviour need to be taken into > account. While hop-by-hop option may be used for management purposes > within one domain, measures should be take to detect these problem > if hop-by-hop options are used end-to-end. >=20 > Network notes further may be configured to drop packets with unknown > IPv6 extension headers. Therefore, instead of defining new Extension > Headers, it is recommended that the Destination Options header is > used to carry optional information that must be examined only by a > packet's destination node(s). >=20 > Or alternatively the text from RFC6564 can be used directly instead of = this second paragraph. However, there are actually two paragraph in = RFC6564, one with a SHOULD and one with a MUST=E2=80=A6? >=20 > "=E2=80=A6 Because of this, implementations SHOULD use > destination options as the preferred mechanism for encoding optional > destination information, and use a new extension header only if > destination options do not satisfy their needs. The request for > creation of a new IPv6 extension header MUST be accompanied by a > specific explanation of why destination options could not be used to > convey this information.=E2=80=9C >=20 > and >=20 > "Mindful of the need for compatibility with existing IPv6 = deployments, > new IPv6 extension headers MUST NOT be created or specified, unless > no existing IPv6 extension header can be used by specifying a new > option for that existing IPv6 extension header. Any proposal to > create or specify a new IPv6 extension header MUST include a = detailed > technical explanation of why no existing IPv6 extension header can = be > used in the document proposing the new IPv6 extension header.=E2=80=9C= >=20 > There is also a paragraph on HBH in RFC6564 but given that routers are = not requirement anymore to process the HBH option, I assume that=E2=80=99s= not up-to-date anymore? >=20 > I hope that helps! > Mirja >=20 >=20 >=20 >=20 >> Am 19.04.2017 um 05:15 schrieb Brian E Carpenter = : >>=20 >> In reality "MUST NOT unless..." means about the same as "SHOULD NOT" = so >> I think we agree that this is editorial. Aligning the language with = RFC6564 >> makes a lot of sense to me. >>=20 >> Brian >> On 19/04/2017 07:58, Mirja Kuehlewind (IETF) wrote: >>> sorry it=E2=80=99s late here=E2=80=A6 >>>=20 >>> s/formation/formulation/ >>> s/no go advice/no good advice/ >>>=20 >>>> Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) = : >>>>=20 >>>> This might be rather an editorial issue now but the formation in = RFC6564 is fully fine with me because it says =E2=80=9EMUST NOT unless = no option can be used=E2=80=9C. That=E2=80=99s basically what I = proposed. The formulation in 2460 however is "Defining new IPv6 = extension headers is not recommended.=E2=80=9C. I think this is = overstated and technically no go advise. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan = : >>>>>=20 >>>>> Hi Mirja/Bob, >>>>>=20 >>>>>=20 >>>>> On Sun, Apr 16, 2017 at 11:38 AM, Bob Hinden = wrote: >>>>>> Hi, >>>>>>=20 >>>>>>> On Apr 16, 2017, at 4:57 AM, otroan@employees.org wrote: >>>>>>>=20 >>>>>>> Brian, Mirja, >>>>>>>=20 >>>>>>>>>> This combination of circumstances creates a "Catch-22" = situation >>>>>>>>>> [Heller] for the deployment of any newly standardised = extension >>>>>>>>>> header except for local use. It cannot be widely deployed = because >>>>>>>>>> existing middleboxes will drop it on many paths through the = Internet. >>>>>>>>>> However, most middleboxes will not be updated to allow the = new header >>>>>>>>>> to pass until it has been proved safe and useful on the open >>>>>>>>>> Internet, which is impossible until the middleboxes have been >>>>>>>>>> updated. >>>>>>>>>>=20 >>>>>>>>>> So, defining new IPv6 extension headers is not recommended, = because >>>>>>>>>> they probably won't work across the Internet. But it isn't a = MUST NOT, >>>>>>>>>> because if there was a compelling operational case, we could = do it and >>>>>>>>>> the middleboxes would follow. >>>>>>>>>=20 >>>>>>>>> First of all yes, giving further explanation/background is = definitely a good thing to do, and maybe also provide a reference to = rfc7045 if appropriate. >>>>>>>>>=20 >>>>>>>>> I think I agree that I would not like to make a normative = statement here, given that the circumstances are not due to the protocol = design itself but because of the current deployment situation we have = (which in theory could change in future). >>>>>>>>>=20 >>>>>>>>> However, instead of making a clear recommendation to not every = define a new extension header, I think I would prefer if the text was = phrased in the a way that would make the risk clear, give a clear = recommendation to rather use destination options if suitable, and then = say nothing else. >>>>>>>>>=20 >>>>>>>>> Maybe you can work on some new text and then have a quick (?) = check with the wg which text is preferred. If there is clear consensus = for one way by the wg I will not further block this. >>>>>>>>=20 >>>>>>>> I think I will leave that for the document editor. A large part = of RFC7045 is about this issue but Bob can probably see best how to = integrate it here. >>>>>>>=20 >>>>>>> I think what is in the document already is representing the = working group consensus. >>>>>>> The issues of new / unknown extension headers, and how to = distinguish these from new transport protocols have been discussed from = many angles. The two main reasons for the strong recommendation against = new extension headers are: >>>>>>> - most uses are already accommodated with the 3 existing = containers options (routing. hbh and destination) >>>>>>> - sharing the same number space with IP protocols, makes it hard = for intermediate devices depending on parsing the header chain to find = transport information if new headers were introduced. >>>>>>>=20 >>>>>>> There is already an opening / provision in the text for new = extension headers. The text only asks for these considerations to be = made, before proposing new ones. >>>>>>=20 >>>>>> I agree. >>>>>>=20 >>>>>> I also note that the text in this section was derived from = RFC6564, which updated RFC2460. Specifically from Section 3 of RFC6564: >>>>>>=20 >>>>>> Mindful of the need for compatibility with existing IPv6 = deployments, >>>>>> new IPv6 extension headers MUST NOT be created or specified, = unless >>>>>> no existing IPv6 extension header can be used by specifying a new >>>>>> option for that existing IPv6 extension header. >>>>>=20 >>>>> Yes. This text was arrived at after a lot of discussion in the = 6man WG >>>>> during the development of the draft that became RFC6564. >>>>>=20 >>>>>>=20 >>>>>> New extension headers are allowed (just not recommended) and the = next paragraph in the Section specifies a format that should be used for = new Extension headers. I think there is a lot of flexibility going = forward. >>>>>=20 >>>>> Yep. I think the above warning is issued because a node processing = an >>>>> unknown extension header will simply drop it, and this makes >>>>> incremental deployability of these new extension headers difficult >>>>> over the Internet. >>>>>=20 >>>>> Thanks >>>>> Suresh >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 --Apple-Mail=_334D4E55-795B-43AB-9F89-EDC4AEC949B7 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+H9mAAoJEL7aWKiYQt92OJwP/2OKncMef2BCqnLrKRJOij+T e67g3i1dNlLoOwpNMYOmsOC+Af8pBbIPzFg4KVbNJtBSVKofmEKvbb9tOjaq1W98 7Cc18JvO8BsxaVeC6NVCghO5B04J8Ckd3+9pbFmDskdxXKyQPAlAwb9uz3SN7CCN smyPHoy8R4g+UM32Rgj0Wh3iDyPgkyDQh3KsUutvkH+lW1hKld/A8LVfJRFS3Ysv N1O9F//1q0/TfdMHcl4kRLboicds9ZWUQ5Z/MCh4WQVJE7FSEfUpjKgDhBtiCVbn h4Dj8q+F4H+HsrpdfLtm9Vg3265lSXL9g99NpMybDgH3JmUaNlXjxhvNN8mraq4V kf1Kfe2iwbbS9dzAAHCmAQ1wRAOc4UFyMdlQBraK0M3EPuuIMJfByta0mg2ZeZR2 DRASUiGO7VZ5VLnw1k7xJAchB5BVeklTFlLzYuiIqSPlsOYKkyCX2IQjpRbc9q4k xu3lkZJLRqkvlhRoChl3yOWLwCP65vmF+O7tgvucPtKzUjMo/dn/MBX1PbaL0Nv4 8m0eygyjP+XI2gOMR9HMUUoccSxIHv2Mt63nai7AIimadQ8T12zeNeNabkKXaNI+ CvwBlaHZ9eNyXUNbVnnoUkuDGPW/0QFOGdEwQ0UCov3dqbZBbaboFBeuW0MKHi6Q vHvXFMvV/Vc8hT0WQQG2 =g/sR -----END PGP SIGNATURE----- --Apple-Mail=_334D4E55-795B-43AB-9F89-EDC4AEC949B7-- From nobody Thu Apr 20 06:01:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4477A129435; Thu, 20 Apr 2017 06:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 CdlL9UUfYui3; Thu, 20 Apr 2017 06:01:26 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205E712426E; Thu, 20 Apr 2017 06:01:25 -0700 (PDT) Received: from [192.168.1.151] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3C83180124; Thu, 20 Apr 2017 15:01:22 +0200 (CEST) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: otroan@employees.org, "Mirja Kuehlewind (IETF)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , IESG , 6man-chairs@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> Date: Thu, 20 Apr 2017 14:01:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:01:28 -0000 Ole, On 04/20/2017 10:29 AM, otroan@employees.org wrote: > Mirja, > >> Let me try to wrap this up. So what I learn is that HBH is used in >> intra-domain scenarios and therefore must be further supported and >> today’s routers are highly likely to drop packets with unknown >> headers. In this sense I think the recommendation given could be >> further clarified. Also I would rather see a discussion of the >> issue than just given a specific recommendation forever, while >> people have still hope that the situation might change (at least >> for HBH I assume). As such I’ll go ahead and would like to propose >> new text for the paragraphs in question, that is intended to >> conserve the current recommendation but giving more background and >> phrase it more carefully. Of course feel free to edit, I just >> thought it might be easier if I simply propose some text: > > "today's routers are highly likely to drop packets with unknown > headers". No, I do not think we have data supporting that. > > Packets with unknown headers are most likely to be dropped at the > destination or by the destination AS. Which makes sense and one would > expect. If extension headers / options were defined that were useful, > one would also expect that the destination would stop dropping them > of course. Chicken and egg. > > Dropping unknown extension headers in transit networks is relatively > rare. With the HBH being an exception, with almost a 40% drop. (Note > that there are no HBH option that would make a lot of sense across > the Internet, so again chicken and egg.) Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World"), your statement is incorrect. Transit routers do filter packets with EHs, whether known or unknown. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 20 06:12:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF23F12943D for ; Thu, 20 Apr 2017 06:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 T-vGZ2qBROqu for ; Thu, 20 Apr 2017 06:12:23 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0514129516 for ; Thu, 20 Apr 2017 06:12:22 -0700 (PDT) Received: from [192.168.1.151] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D5F8180A6B; Thu, 20 Apr 2017 15:12:20 +0200 (CEST) Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Bob Hinden , IPv6 List References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Cc: Eric Rescorla From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 20 Apr 2017 14:11:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:12:25 -0000 Bob, Thanks for sharing the text! Two quick comments: On 04/19/2017 09:55 PM, Bob Hinden wrote: > NEW > > IPv6, from the viewpoint of the basic format and transmission of > packets, has security properties that are similar to IPv4. These > security issues include: > > o Eavesdropping, On-path elements can observe the contents and > metadata of each IPv6 datagram. Not sure what metadata implies here -- an eavesdropper can actually see the wwhole content of the packet. > o Denial of Service Attacks, where the attacker sends large > amounts of legimate traffic to a destionation to overwhelm it. s/legimate/legitimate/ and s/destionation/destination/ > IPv6 packets can be protected from eavesdropping, packet > modification, replay, and man in the middle attacks by use of the > "Security Architecture for the Internet Protocol" [RFC4301]. In > addition, upper-layer protocols such as TLS or SSH can be used to > protect the application layer traffic running on top of IPv6. You may want to add references for TLS and SSH. > IPv6 addresses are much larger than IPv4 address making it much > harder to scan the address space across the Internet and even on a > single network link (e.g., Local Area Network). You may want to reference RFC7707, and maybe RFC7721 -- the larger address space may not make address scans harder ... it all depends on how the IIDs are generated/selected > > IPv6 addresses of nodes are expected to be more visible on the > Internet as compared with IPv4 since the use of address translation > technology is reduced. This creates some additional privacy issues > such as making it easier to distinguish endpoints. Certainly you should ref RFC7721 here. > The design of IPv6 extension headers architecture, while adding a lot > of flexibility, also creates new security challenges. As noted > below, issues relating the fragment extension header have been > resolved, but it's clear that for any new extension header designed > in the future, the security implications need to be examined > throughly, and this needs to include how the new extension header > works with existing extension headers. Some references here are warranted.. e.g. regarding the use of EHs to circumvent security controls. > > This version of the IPv6 specification resolves a number of security > issues that were found with the previous version [RFC2460] of the > IPv6 specification. These include: > > o Revised the text to handle the case of fragments that are whole > datagrams (i.e., both the Fragment Offset field and the M flag > are zero). If received they should be processed as a > reassembled packet. Any other fragments that match should be > processed independently. The Fragment creation process was > modified to not create whole datagram fragments (Fragment > Offset field and the M flag are zero). I'd reference RFC8021 here -- which elaborated on the topic, and also describes specific attack vectors. > > o Changed the text to require that IPv6 nodes must not create > overlapping fragments. Also, when reassembling an IPv6 > datagram, if one or more its constituent fragments is > determined to be an overlapping fragment, the entire datagram > (and any constituent fragments) must be silently discarded. > Includes clarification that no ICMP error message should be > sent if overlapping fragments are received. Here the same: reference the appropriate RFC (by Suresh, IIRC) > 0 Revised the text to require that all headers through the first > Upper-Layer Header are in the first fragment. May want to reference RFC7112 here. > o Removed the paragraph in Section 5 that required including a > fragment header to outgoing packets if a ICMP Packet Too Big > message reporting a Next-Hop MTU less than 1280. Ref to RFC8021 here. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 20 06:16:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52331126DC2 for ; Thu, 20 Apr 2017 06:16:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A567E43pYKVz for ; Thu, 20 Apr 2017 06:16:42 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 C062F127444 for ; Thu, 20 Apr 2017 06:16:41 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 203so35765268ywe.0 for ; Thu, 20 Apr 2017 06:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RPrqOvxFN72pdnmBa6wG3i5cwT24Jq+8ZhYqhCy2msk=; b=opRpoff29fWCV2aBX4YbSwg7BixmqowbctkQS2xvxBd9mWe0RPXIOTn3qJADDSLR6A T1FlPC01qZl57vr99i0ToWkI1qds1RANxQUlK9Q5d4oez8olo65n5qu7IyXGNOeLLrUq zrQw1egHqD3UMf4NHc3ec6IDON5KIebgZPXUGs9FfWvfIXd13GJj1RrMbmLHnYI4L7ut PYn6mdUInXxH8e3ehKOC9y6he7oc5KG0oITO2WuEsywaLJ6fsyr33lzhMYJoUISocFqX k/YGQbV7vOq29d9neli0hxZe0PMsfVZtzwJQVNUlznv/lnduK35B7xiEQLHRp5c2BAz4 Mt2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPrqOvxFN72pdnmBa6wG3i5cwT24Jq+8ZhYqhCy2msk=; b=RCVqTMqFYtEDoXbsyTrmoO3sAGDJQxnbqMYuhlfOXQr3hB5uC9icTOe0gqgKwrClu8 XfzZ3Uk4sAKtbqEciWwd85zVQHga5/RKUz+uw/06dlhpoePu0j37QILjezvVkOMJ7TXE KPQo0WYPfjrJd/7pkGa3MTboPHH19B1axXEQVdMHfOQKSKEEE4ZqYU9jVjf3LrvxrRtG 9RQVT//OP+3/0xH+bBR+/yrcWiEc71n+2uSjw92ZwT4XaHdHX4wcCym9P2AZ2B7psV4k xrzPfiDngNuF+xXoqeAfk/KSS+rJGuInXzy/KxIG5mvtESbKZgqcNXwcDVdt2toHZimg jFuw== X-Gm-Message-State: AN3rC/4lY4m7lgXVijPDYL280zmAzYoNy7PSTNdgb+9GzbGed+nzGHby pjQ+4c1+zyZ2KAumMPU5BeL1Zb9tEA== X-Received: by 10.13.195.69 with SMTP id f66mr1402062ywd.276.1492694200821; Thu, 20 Apr 2017 06:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 20 Apr 2017 06:16:00 -0700 (PDT) In-Reply-To: References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> From: Eric Rescorla Date: Thu, 20 Apr 2017 09:16:00 -0400 Message-ID: Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Fernando Gont Cc: Bob Hinden , IPv6 List Content-Type: multipart/alternative; boundary=001a114e52ca995141054d98f387 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:16:45 -0000 --001a114e52ca995141054d98f387 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont wrote: > Bob, > > Thanks for sharing the text! Two quick comments: > > On 04/19/2017 09:55 PM, Bob Hinden wrote: > > NEW > > > > IPv6, from the viewpoint of the basic format and transmission of > > packets, has security properties that are similar to IPv4. These > > security issues include: > > > > o Eavesdropping, On-path elements can observe the contents and > > metadata of each IPv6 datagram. > > Not sure what metadata implies here -- an eavesdropper can actually see > the wwhole content of the packet. > Yes, but there are mechanisms for protecting the content which do not protect the metadata, so it's useful to call them both out. -Ekr > o Denial of Service Attacks, where the attacker sends large > > amounts of legimate traffic to a destionation to overwhelm it. > > s/legimate/legitimate/ and s/destionation/destination/ > > > > IPv6 packets can be protected from eavesdropping, packet > > modification, replay, and man in the middle attacks by use of the > > "Security Architecture for the Internet Protocol" [RFC4301]. In > > addition, upper-layer protocols such as TLS or SSH can be used to > > protect the application layer traffic running on top of IPv6. > > You may want to add references for TLS and SSH. > > > > > IPv6 addresses are much larger than IPv4 address making it much > > harder to scan the address space across the Internet and even on a > > single network link (e.g., Local Area Network). > > You may want to reference RFC7707, and maybe RFC7721 -- the larger > address space may not make address scans harder ... it all depends on > how the IIDs are generated/selected > > > > > > IPv6 addresses of nodes are expected to be more visible on the > > Internet as compared with IPv4 since the use of address translation > > technology is reduced. This creates some additional privacy issues > > such as making it easier to distinguish endpoints. > > Certainly you should ref RFC7721 here. > > > > > The design of IPv6 extension headers architecture, while adding a lot > > of flexibility, also creates new security challenges. As noted > > below, issues relating the fragment extension header have been > > resolved, but it's clear that for any new extension header designed > > in the future, the security implications need to be examined > > throughly, and this needs to include how the new extension header > > works with existing extension headers. > > Some references here are warranted.. e.g. regarding the use of EHs to > circumvent security controls. > > > > > > This version of the IPv6 specification resolves a number of security > > issues that were found with the previous version [RFC2460] of the > > IPv6 specification. These include: > > > > o Revised the text to handle the case of fragments that are whole > > datagrams (i.e., both the Fragment Offset field and the M flag > > are zero). If received they should be processed as a > > reassembled packet. Any other fragments that match should be > > processed independently. The Fragment creation process was > > modified to not create whole datagram fragments (Fragment > > Offset field and the M flag are zero). > > I'd reference RFC8021 here -- which elaborated on the topic, and also > describes specific attack vectors. > > > > > > o Changed the text to require that IPv6 nodes must not create > > overlapping fragments. Also, when reassembling an IPv6 > > datagram, if one or more its constituent fragments is > > determined to be an overlapping fragment, the entire datagram > > (and any constituent fragments) must be silently discarded. > > Includes clarification that no ICMP error message should be > > sent if overlapping fragments are received. > > Here the same: reference the appropriate RFC (by Suresh, IIRC) > > > > > 0 Revised the text to require that all headers through the first > > Upper-Layer Header are in the first fragment. > > May want to reference RFC7112 here. > > > > > o Removed the paragraph in Section 5 that required including a > > fragment header to outgoing packets if a ICMP Packet Too Big > > message reporting a Next-Hop MTU less than 1280. > > Ref to RFC8021 here. > > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a114e52ca995141054d98f387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont <fgont@si6networks.= com> wrote:
Bob,

Thanks for sharing the text! Two quick comments:

On 04/19/2017 09:55 PM, Bob Hinden wrote:
>=C2=A0 =C2=A0 NEW
>
>=C2=A0 =C2=A0 IPv6, from the viewpoint of the basic format and transmis= sion of
>=C2=A0 =C2=A0 packets, has security properties that are similar to IPv4= .=C2=A0 These
>=C2=A0 =C2=A0 security issues include:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Eavesdropping, On-path elements can = observe the contents and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 metadata of each IPv6 datagram.

Not sure what metadata implies here -- an eavesdropper can actually = see
the wwhole content of the packet.

Yes, = but there are mechanisms for protecting the content which do not protect th= e
metadata, so it's useful to call them both out.
<= br>
-Ekr


=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Denial of Service Attacks, where the= attacker sends large
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 amounts of legimate traffic to a des= tionation to overwhelm it.

s/legimate/legitimate/ and s/destionation/destination/


>=C2=A0 =C2=A0 IPv6 packets can be protected from eavesdropping, packet<= br> >=C2=A0 =C2=A0 modification, replay, and man in the middle attacks by us= e of the
>=C2=A0 =C2=A0 "Security Architecture for the Internet Protocol&quo= t; [RFC4301].=C2=A0 In
>=C2=A0 =C2=A0 addition, upper-layer protocols such as TLS or SSH can be= used to
>=C2=A0 =C2=A0 protect the application layer traffic running on top of I= Pv6.

You may want to add references for TLS and SSH.



>=C2=A0 =C2=A0 IPv6 addresses are much larger than IPv4 address making i= t much
>=C2=A0 =C2=A0 harder to scan the address space across the Internet and = even on a
>=C2=A0 =C2=A0 single network link (e.g., Local Area Network).

You may want to reference RFC7707, and maybe RFC7721 -- the larger address space may not make address scans harder ... it all depends on
how the IIDs are generated/selected


>
>=C2=A0 =C2=A0 IPv6 addresses of nodes are expected to be more visible o= n the
>=C2=A0 =C2=A0 Internet as compared with IPv4 since the use of address t= ranslation
>=C2=A0 =C2=A0 technology is reduced.=C2=A0 This creates some additional= privacy issues
>=C2=A0 =C2=A0 such as making it easier to distinguish endpoints.

Certainly you should ref RFC7721 here.



>=C2=A0 =C2=A0 The design of IPv6 extension headers architecture, while = adding a lot
>=C2=A0 =C2=A0 of flexibility, also creates new security challenges.=C2= =A0 As noted
>=C2=A0 =C2=A0 below, issues relating the fragment extension header have= been
>=C2=A0 =C2=A0 resolved, but it's clear that for any new extension h= eader designed
>=C2=A0 =C2=A0 in the future, the security implications need to be exami= ned
>=C2=A0 =C2=A0 throughly, and this needs to include how the new extensio= n header
>=C2=A0 =C2=A0 works with existing extension headers.

Some references here are warranted.. e.g. regarding the use of EHs t= o
circumvent security controls.


>
>=C2=A0 =C2=A0 This version of the IPv6 specification resolves a number = of security
>=C2=A0 =C2=A0 issues that were found with the previous version [RFC2460= ] of the
>=C2=A0 =C2=A0 IPv6 specification.=C2=A0 These include:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Revised the text to handle the case = of fragments that are whole
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datagrams (i.e., both the Fragment O= ffset field and the M flag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 are zero).=C2=A0 If received they sh= ould be processed as a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reassembled packet.=C2=A0 Any other = fragments that match should be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 processed independently.=C2=A0 The F= ragment creation process was
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 modified to not create whole datagra= m fragments (Fragment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Offset field and the M flag are zero= ).

I'd reference RFC8021 here -- which elaborated on the topic, and= also
describes specific attack vectors.


>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Changed the text to require that IPv= 6 nodes must not create
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 overlapping fragments.=C2=A0 Also, w= hen reassembling an IPv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datagram, if one or more its constit= uent fragments is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 determined to be an overlapping frag= ment, the entire datagram
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (and any constituent fragments) must= be silently discarded.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Includes clarification that no ICMP = error message should be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sent if overlapping fragments are re= ceived.

Here the same: reference the appropriate RFC (by Suresh, IIRC)



>=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 Revised the text to require that all= headers through the first
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Upper-Layer Header are in the first = fragment.

May want to reference RFC7112 here.



>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Removed the paragraph in Section 5 t= hat required including a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fragment header to outgoing packets = if a ICMP Packet Too Big
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message reporting a Next-Hop MTU les= s than 1280.

Ref to RFC8021 here.


Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a114e52ca995141054d98f387-- From nobody Thu Apr 20 06:21:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3A129533 for ; Thu, 20 Apr 2017 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 0mnbhmGmRePH for ; Thu, 20 Apr 2017 06:21:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A08129529 for ; Thu, 20 Apr 2017 06:21:35 -0700 (PDT) Received: from [192.168.1.150] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BD43D80CBE; Thu, 20 Apr 2017 15:21:33 +0200 (CEST) Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Eric Rescorla References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Cc: Bob Hinden , IPv6 List From: Fernando Gont Message-ID: <6cc8ec3f-f978-838e-5caa-37510e929220@si6networks.com> Date: Thu, 20 Apr 2017 14:20:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:21:39 -0000 On 04/20/2017 02:16 PM, Eric Rescorla wrote: > > > On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont > wrote: > > Bob, > > Thanks for sharing the text! Two quick comments: > > On 04/19/2017 09:55 PM, Bob Hinden wrote: > > NEW > > > > IPv6, from the viewpoint of the basic format and transmission of > > packets, has security properties that are similar to IPv4. These > > security issues include: > > > > o Eavesdropping, On-path elements can observe the contents and > > metadata of each IPv6 datagram. > > Not sure what metadata implies here -- an eavesdropper can actually see > the wwhole content of the packet. > > > Yes, but there are mechanisms for protecting the content which do not > protect the > metadata, so it's useful to call them both out. Fully agreed. Just meant that the statement above seemed to suggest that an eavesdropper can only see the metadata. -- I know that's not what the authors meant. Just that it might be read as such. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 20 06:25:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2077413144B for ; Thu, 20 Apr 2017 06:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCng-mSFcS-i for ; Thu, 20 Apr 2017 06:25:51 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 A454C129533 for ; Thu, 20 Apr 2017 06:25:51 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u70so38479407ywe.2 for ; Thu, 20 Apr 2017 06:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1L5mtgo0gQiC6g0lGSqvLVdfJ4hu7Jk9FzHreGjykg0=; b=ftAXuRE7+2tk0oMkTYGHfFGIDBVl3IcLXrSWeIp0xE6AZahV+VJAWpw8PTdGv04hXZ Z6t2u/nRJ4ykYDqRHqReWFflly3ICy+qGa5rTAFXHIbd+3snwLZujp252XsB/S5rcbG8 0y59yJ87l2vwHtALrVR+7Pmz0xAWA5XxnqNgcdet7PCHKYCK6AWJVftZsTICD9znYV9h lxysaOk9PWO4fRNkQt+tjnmhKH+koxszPpnQSxSDSJk33l/MNAI4a7agm03xTm7Hw1cM ipSfV/UGO9641ChtBSfZrW0qYaA7ff3WfwzzLXV0NnaJxYIXxMjkVeJwcwElzs0OhgDQ HRKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1L5mtgo0gQiC6g0lGSqvLVdfJ4hu7Jk9FzHreGjykg0=; b=LkNWkN+iu7ZsUpbUMYzgnAXwsgTMrMJX68DH1cmewV8H6sZOtXiuLZU8DZSNADJQFi bjBogxT0M6RwbMeIt5QyujAjSzG4K6JMiTIKw5q2DopAWf0hJfgz56g0moBomvCYkISF 17GU5x9bOJZj5anQpCx8fuPnP/inZzqBjDLqqJnoggR9yC0fISQwKh4rigekF/S2bBKR AT9pPorquVHTaM+kAXmfRWFDja2RVQ9jt5oQ9zYhcSrM8y8OYFBP+35cQLpA7TWdTU5y bWZ8qzeedDuggQjaryhF7v4Q+3GzBIUtmlxPqqF4ckKd7VR1H70pbLuX33VZFoL+pLAB xyag== X-Gm-Message-State: AN3rC/5sm1NGSokH++ZubbsjI57XJqAQbt3Z6Vf/xE+arBIJ+KWdZfJW 4Iqokhxp7ThrQmSGctcqgnZOdfkZfdgS X-Received: by 10.13.203.73 with SMTP id n70mr6686546ywd.71.1492694750885; Thu, 20 Apr 2017 06:25:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 20 Apr 2017 06:25:10 -0700 (PDT) In-Reply-To: <6cc8ec3f-f978-838e-5caa-37510e929220@si6networks.com> References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <6cc8ec3f-f978-838e-5caa-37510e929220@si6networks.com> From: Eric Rescorla Date: Thu, 20 Apr 2017 09:25:10 -0400 Message-ID: Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Fernando Gont Cc: Bob Hinden , IPv6 List Content-Type: multipart/alternative; boundary=001a114fd3d6629196054d9914ea Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:25:53 -0000 --001a114fd3d6629196054d9914ea Content-Type: text/plain; charset=UTF-8 On Thu, Apr 20, 2017 at 9:20 AM, Fernando Gont wrote: > On 04/20/2017 02:16 PM, Eric Rescorla wrote: > > > > > > On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont > > wrote: > > > > Bob, > > > > Thanks for sharing the text! Two quick comments: > > > > On 04/19/2017 09:55 PM, Bob Hinden wrote: > > > NEW > > > > > > IPv6, from the viewpoint of the basic format and transmission of > > > packets, has security properties that are similar to IPv4. > These > > > security issues include: > > > > > > o Eavesdropping, On-path elements can observe the contents > and > > > metadata of each IPv6 datagram. > > > > Not sure what metadata implies here -- an eavesdropper can actually > see > > the wwhole content of the packet. > > > > > > Yes, but there are mechanisms for protecting the content which do not > > protect the > > metadata, so it's useful to call them both out. > > Fully agreed. Just meant that the statement above seemed to suggest that > an eavesdropper can only see the metadata. -- I know that's not what the > authors meant. Just that it might be read as such. > > Well, it says "contents and metadata". Perhaps "the whole packet (including both contents and metadata)"? -Ekr Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a114fd3d6629196054d9914ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 20, 2017 at 9:20 AM, Fernando Gont <fgont@si6networks.= com> wrote:
On 04/20/2017 02:16 PM, Eric Rescorla wrote:
>
>
> On Thu, Apr 20, 2017 at 9:11 AM, Fernando Gont <fgont@si6networks.com
> <mailto:fgont@si6networks.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Bob,
>
>=C2=A0 =C2=A0 =C2=A0Thanks for sharing the text! Two quick comments: >
>=C2=A0 =C2=A0 =C2=A0On 04/19/2017 09:55 PM, Bob Hinden wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 NEW
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 IPv6, from the viewpoint of the b= asic format and transmission of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 packets, has security properties = that are similar to IPv4.=C2=A0 These
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 security issues include:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0o=C2=A0 Eavesdroppin= g, On-path elements can observe the contents and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 metadata of = each IPv6 datagram.
>
>=C2=A0 =C2=A0 =C2=A0Not sure what metadata implies here -- an eavesdrop= per can actually see
>=C2=A0 =C2=A0 =C2=A0the wwhole content of the packet.
>
>
> Yes, but there are mechanisms for protecting the content which do not<= br> > protect the
> metadata, so it's useful to call them both out.

Fully agreed. Just meant that the statement above seemed to suggest = that
an eavesdropper can only see the metadata. -- I know that's not what th= e
authors meant. Just that it might be read as such.


Well, it says "contents and metad= ata". Perhaps
"the whole packet (including both content= s and metadata)"?

-Ekr

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a114fd3d6629196054d9914ea-- From nobody Thu Apr 20 06:51:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BCB12954D for ; Thu, 20 Apr 2017 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 HjSlKEk79VlR for ; Thu, 20 Apr 2017 06:51:48 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE9D129431 for ; Thu, 20 Apr 2017 06:51:48 -0700 (PDT) Received: from [192.168.1.150] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 87CDA80D2A; Thu, 20 Apr 2017 15:51:46 +0200 (CEST) Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Brian E Carpenter , james woodyatt , Bob Hinden References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> Cc: Eric Rescorla , IETF IPv6 Mailing List From: Fernando Gont Message-ID: <3c35d05d-f666-1aef-d8a5-0f5809830d70@si6networks.com> Date: Thu, 20 Apr 2017 14:51:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:51:50 -0000 On 04/20/2017 01:14 AM, Brian E Carpenter wrote: > On 20/04/2017 09:34, james woodyatt wrote: >> On Apr 19, 2017, at 13:55, Bob Hinden wrote: >>> >>> The current and proposed new text is below. Please review and comments. I hope to publish a new draft at the end of the week. >> >> Bravo! Alas, I have a nit. > > +1 > > Should we include references where they exist, e.g. for scanning attacks and address privacy? That was in essence the same comment I made. I may provde some additional ones if needed. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Apr 20 08:47:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9088129AB8; Thu, 20 Apr 2017 08:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 TLo8cV30nuQR; Thu, 20 Apr 2017 08:47:17 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 41260127342; Thu, 20 Apr 2017 08:47:17 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id z129so11633509wmb.1; Thu, 20 Apr 2017 08:47:17 -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=pdg6ngHWtPs2l30ZWJjJpywANBt7hJkVc+krtXZkjDw=; b=FUL20bDIwyC3XsYiPQIDKTHS6RGwTTT+OkclmXMjZaFhJ5gPwhLEBV1Vv/ZVtKcSpp o8FzHd2DCRmonC9vdOBMaYxzUubgyUclxp1iw8/KwzZG34Z5GoEzgrt+IugQW8h3HL4J +VW+iMLOrEcvvSp1a6djvVSu0qK7m6Q25vxjeVwMhFb2hlUCN94UCNN2ITyoyzIa5z5N ZQyi4ADo2TlqBCrRH8OzvAqijso6CtqOM6zoigqlWWuo9vc6+a35BISWB+LrWJVpB1n0 /QmexgtE1nwv+dOeJPP+hlKzFN/annZMdZvDJhoBWQxuX80xRHyKY6OwnfhiIyIAJPJZ 1log== 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=pdg6ngHWtPs2l30ZWJjJpywANBt7hJkVc+krtXZkjDw=; b=X3TG0WyrZlgpIAK5Xz+kDM2+nvZh9xtEA+cwiV7ZjGIsOFFAT0Xe8f7ZCbNfkSyakp MX9V9Mp7aCCjqf1OYsJyzFempT06jEEHmAgz+WUY6wF9ZhrhmzGl1H9EU7pXzxykdHN8 RfseeAm9Q5WJ/MECJjty0I3NSyRTKt7ZUgH/9qx5ghwXFduEqKqxGlv9jV/0Y0vbzbP2 I1j2a3/efoRpPtgDknyZzppYzwlQUu6c2ENIv+/d//Yw52z5t1dfRkZZnZiolmykV7ij YQ5N7oEN5709dOcQVHTAKvvnI1EcktAvCYYr3dhj8R2o1Ou5D0MTdCbdwDuGc86hjpsJ Uk7g== X-Gm-Message-State: AN3rC/6tUEPQHqwWpAq7O1C8R8p6G8AoESAbHozBjH0QXJRnL04Aj9Sa NEUUQl6I1AEGweL9CMg= X-Received: by 10.28.221.212 with SMTP id u203mr3755693wmg.101.1492703235725; Thu, 20 Apr 2017 08:47:15 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:9cf5:b82e:11d6:5b43? ([2601:647:4d01:db10:9cf5:b82e:11d6:5b43]) by smtp.gmail.com with ESMTPSA id b31sm8141832wrb.7.2017.04.20.08.47.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 08:47:13 -0700 (PDT) From: Bob Hinden Message-Id: <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4D32A4E9-D9C4-40BF-A0E4-D35432BB4BC8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 08:47:08 -0700 In-Reply-To: <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> Cc: Bob Hinden , =?utf-8?Q?Ole_Tr=C3=B8an?= , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Suresh Krishnan , IESG , 6man-chairs@ietf.org To: Fernando Gont References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 15:47:19 -0000 --Apple-Mail=_4D32A4E9-D9C4-40BF-A0E4-D35432BB4BC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando, > On Apr 20, 2017, at 6:01 AM, Fernando Gont = wrote: >=20 >> =E2=80=A6. >>=20 >> Dropping unknown extension headers in transit networks is relatively >> rare. With the HBH being an exception, with almost a 40% drop. (Note >> that there are no HBH option that would make a lot of sense across >> the Internet, so again chicken and egg.) >=20 > Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 > Extension Headers in the Real World"), your statement is incorrect. >=20 > Transit routers do filter packets with EHs, whether known or unknown. I think this confirms that the current text which recommends against = defining new EH is correct. Thanks, Bob --Apple-Mail=_4D32A4E9-D9C4-40BF-A0E4-D35432BB4BC8 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+Nf8AAoJEK7rdBF357uocVEIALDpACZx9KwP91Mp2feri00g nlEBJEm08kbE4tZs1bStkjMYcqKqQV+6ZwEFRyHJ42tL8snFVXq5eRvMdDMyIy1u ZDzjYAgg6Tpb/zLOiB7+CLZw3oOKnIwRqZxSmdUiCv0BJCLUwSgh2QTcHuxW/S2u jYjybeeh+l04y/Lw3lJICIBFYRlhD6wYcFA6CbOGKeUnQeEP87PTnJzL+gGazs1O GU8jTaIl6XeLUEkfUpN82n7gFI83HWNeazlShNMjVWtHQQL27skEPFAJ0dgeVzXd IHwcjMxeziU5Dmw8YfFbL8J/ct0oaMOo9/bc0oddq+10hk1/Rr+8FnuXxo9K2CI= =C1pq -----END PGP SIGNATURE----- --Apple-Mail=_4D32A4E9-D9C4-40BF-A0E4-D35432BB4BC8-- From nobody Thu Apr 20 08:59:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37712FEAA; Thu, 20 Apr 2017 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 p7n1XLA118rP; Thu, 20 Apr 2017 08:59:06 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 669EF129C6C; Thu, 20 Apr 2017 08:59:06 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id h41so17868741ioi.1; Thu, 20 Apr 2017 08:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=TztJvCAUu4tU9YqH1K5GT3M2yc+WXGsLC3FywugLIbI=; b=fiapsjSk+a515byzVBI8jk5i0V+DT2SDk4oTUapGMWtrif8SI8UzHAaMhc6n3UHt37 +pj527PIF6nIvRctdWp11BuwNXiNe8aIHOHpD+xEFtgjoQLj3eAoGCU2PsWsyTAvK/bg pbXn3/WnaBexH4Gz5hUasFt1nuQ5FxLxMePJXbYQAmoL45JLmvvqrJRWytyMPO2qo/LS meNHkOHDNCjqPSmBy03Et8bCtDsvEO/VnwTHCcurXudzPf3KpRb7b1K/0DnlW9nJ2eLv alfc4JH4f+ssGhZs3Rb1QrwzKzg1Jsf/XPsOYtVD3Cvs34icZDTOqvmL/4eFS0Zc1CHv hdwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=TztJvCAUu4tU9YqH1K5GT3M2yc+WXGsLC3FywugLIbI=; b=h4T+ofIskv9lY0l0tmvvjD4coztAr8AG//W+by9RdGz+f/CC9HymQeqaeBgp1U1V2L 2i0lm2MVUy03JokFGQhNi4NbQMk8goAXkQfcVYxk8eFg8doRAi3mUUw0fYWPkeD3wxfh uNgN1m7/kKTA+Y979AQ633zkWXcKt5CXtwtkt36IjGAhQUqhOI3+WLzMpultyG7WK0Nw rHZRAdYoYGdjq1dIhPeQkf4vYXFIOzK7l+2NE36EaGgou1AtRwQ5LE04hAfHDEf6EJBu hlOnpvaKD4Dq4YFsVB0Jkc/bUPI7L/Z7t5V4+mRuB2cyji8X6+CW/EohTZcSzdduq9vI KQoQ== X-Gm-Message-State: AN3rC/6pfhRnLbmgzxMcUXcvUYZ0eoj7F5Aw2wvaxedu8jKJmm8kThp7 ojVjlhPQtjxOLQ== X-Received: by 10.98.13.134 with SMTP id 6mr8372460pfn.112.1492703945582; Thu, 20 Apr 2017 08:59:05 -0700 (PDT) Received: from [192.168.1.4] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id 128sm11355511pgi.49.2017.04.20.08.59.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 08:59:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Thu, 20 Apr 2017 08:59:02 -0700 Subject: Re: Mirja =?UTF-8?B?S8O8aGxld2luZCdz?= Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) From: Jeff Tantsura To: Bob Hinden , Fernando Gont CC: , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , <6man-chairs@ietf.org> Message-ID: Thread-Topic: Mirja =?UTF-8?B?S8O8aGxld2luZCdz?= Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT) References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> In-Reply-To: <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 15:59:09 -0000 somewhat oldish data points: http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf IPv6 Extension Header (8 bytes) =E2=80=93 Failure rate: 52.53 % IPv6 Extension Header (1 KBytes) =E2=80=93 Failure rate: 92.17 % =20 Cheers, Jeff =20 On 4/20/17, 08:47, "ipv6 on behalf of Bob Hinden" wrote: Fernando, =20 > On Apr 20, 2017, at 6:01 AM, Fernando Gont wr= ote: >=20 >> =E2=80=A6. >>=20 >> Dropping unknown extension headers in transit networks is relatively >> rare. With the HBH being an exception, with almost a 40% drop. (Note >> that there are no HBH option that would make a lot of sense across >> the Internet, so again chicken and egg.) >=20 > Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 > Extension Headers in the Real World"), your statement is incorrect. >=20 > Transit routers do filter packets with EHs, whether known or unknown. =20 I think this confirms that the current text which recommends against de= fining new EH is correct. =20 Thanks, Bob =20 =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 From nobody Thu Apr 20 09:15:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE41294E1; Thu, 20 Apr 2017 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 wPhzKf3dxxU7; Thu, 20 Apr 2017 09:15:02 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1CB128B88; Thu, 20 Apr 2017 09:15:02 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 16:15:02 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id C9C12D788A; Thu, 20 Apr 2017 09:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=N8grewHnxV2Gvw1jS/NMa6JELzw=; b= R/acoPFdowBeG3oaoqPJ/nZGLmdxzhlbUx2KADD9SVTsK9q9g6oh+4OtHkTEPKFT FRz2O6jiOY6Sbx0UpwM6mhISmXATlw5/jdw2w8PT8U7GEL/NGoZ1buhk2yI2HyCw YmLAkv3jByqZX4hbZ++LhUjZTSerhS5a2BdY2UQ5eGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=VtOUA1oDgg0HmSsKLYJd3l2 298kqzk78S5QEUKmX1fS0McoIPp+2UZNmLqBj/rRdiKVIQvC1jjfdBUxYILQoxcR ttoSfJWk/zVk1mnl3ZVSxYjgOXA5zM4GyrMdTpth4FaS56whn7tuZNFXCKIgppIY b4vGn7q4RO/kab7CCq30= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 9D6E6D788F; Thu, 20 Apr 2017 09:15:01 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DF0ECAC92B6A; Thu, 20 Apr 2017 18:14:58 +0200 (CEST) From: otroan@employees.org Message-Id: <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_044D0A01-64DD-4E14-BCFA-39A6739980E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 18:14:57 +0200 In-Reply-To: Cc: Bob Hinden , Fernando Gont , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org To: Jeff Tantsura References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:15:05 -0000 --Apple-Mail=_044D0A01-64DD-4E14-BCFA-39A6739980E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jeff, > somewhat oldish data points: > = http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf >=20 > IPv6 Extension Header (8 bytes) =E2=80=93 Failure rate: 52.53 % > IPv6 Extension Header (1 KBytes) =E2=80=93 Failure rate: 92.17 % Those numbers are alternative facts. They include the destination = system. It would be as if you reported a 99.5% failure rate of SCTP because the = end system didn't respond on the echo port. For reasons one can only speculate about the authors of RFC7872 chose to = show their numbers the same way. =46rom 7872: DO8 | Web | 11.88% | servers | (17.60%/20.80%) Which means a drop rate by intermediate systems of 2.4%. A little less = sensational. Cheers, Ole > Fernando, >=20 >> On Apr 20, 2017, at 6:01 AM, Fernando Gont = wrote: >>=20 >>> =E2=80=A6. >>>=20 >>> Dropping unknown extension headers in transit networks is relatively >>> rare. With the HBH being an exception, with almost a 40% drop. (Note >>> that there are no HBH option that would make a lot of sense across >>> the Internet, so again chicken and egg.) >>=20 >> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >> Extension Headers in the Real World"), your statement is incorrect. >>=20 >> Transit routers do filter packets with EHs, whether known or unknown. >=20 > I think this confirms that the current text which recommends = against defining new EH is correct. >=20 > Thanks, > Bob >=20 >=20 > = -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > = -------------------------------------------------------------------- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_044D0A01-64DD-4E14-BCFA-39A6739980E6 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+N6CAAoJEL7aWKiYQt92K/8P/2rKOqLXU1VTUblWf2Be7hQC 9I3qdvKgzutYQs607xPLMP1YLx455IWQlDCzyxADUW5BeMg26Vp9NWctA6E1h01q ehSmWIPpzk02yFmi29jsar0w+8taaNjmqORwCyhiJgdAMAzQ7Z2U9rGeJRwdfxTU bMr+dNGtmgxd3/KdSr83QiinkDRK+rpynWA5rtRn/mk47mYi86km7Z1pbzHrLMhj 2kO685UKJAXBaY6NDUBopXM1T8lxHb0qRYkNOF6snsFLlC8QoR+AwOzW/UrcV0LA DVGpges9u8p+8Oial4j/hhJgVOPWj3ftX4w4I9w/CpKzDo9c7ADxqhSOcswCj5Mr T6zd51QoyPOW74nOx0RDuQQiCRc3Wed5LB2IJFoafv7r2+sCCRtOV0Df/jnFvQX6 ha++HFyhnuNP/g3yUusZNL4M8XUz1r1b8I63tinwAaBKJcgJDIyAW93oaMUDsV/e cizKW0sVBMIyq34dKTVjKzDucuHiHjqgu66DJM6SpNNGO1QiZMfDuRIAm0xtr4gt L5S8ZFyGntNqIN5QwCcEC0XKmI7KHf1fmZmq9cXG0mubD+WKJiyFc6nKjlPIDrSl L+p6N27cqgFHol6wKOTf/7E4ayJvyAz7i4Zyy/RfgcUo1q2B8oSCv/5ZGNUD4aB6 ss/mBC2YBjMHVejJ+yU/ =uCKO -----END PGP SIGNATURE----- --Apple-Mail=_044D0A01-64DD-4E14-BCFA-39A6739980E6-- From nobody Thu Apr 20 09:29:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2364F129ADC; Thu, 20 Apr 2017 09:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 OR5hksAZm-Sq; Thu, 20 Apr 2017 09:29:47 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 F0FFA12422F; Thu, 20 Apr 2017 09:29:46 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id v75so8549899qkb.3; Thu, 20 Apr 2017 09:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uMOuktwYp0LrTiuLfwzhf3vgLljdW+M+Dn4YPM91WKE=; b=ptLcaimXmCk70RvWSsNJnkU6VP/EsP+xZpwg635rdQvR9f1BT63wVuwGcHjKGVK7aT JPhPWVdWuphSj6/xMsNONApeU+KQcBxHvMSI9fOfQvNSQmK0xJnysc4+IHigyGM8sOER ATXZt4tsayFkevDAewG0ZKHq7O7wkkygaeUjilOWz0vx6h1KIwGfkdfSZ3ZRl9THjaGN 9w4vg3RssypVnt/msNmb7MTOWDigy03sY+T8IBkV2UMhuc0lsF1Si1CJtOGFifeEYS4O Vpr5ZzgvBcMDUVkcL3v6z/MPjcvxwtXw/mxja8t1HvRLaq6K0x6KxJWCY1BWCIwqXMqe 2Qug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uMOuktwYp0LrTiuLfwzhf3vgLljdW+M+Dn4YPM91WKE=; b=dDsKbl8PxE8R+n6yylBaL9/2rKiqdwCUykm0E7boiQHa66N2dbpve/yFVj353ASXJH jGCRb5xMq+trfDJNx6W9SvaK88mOFTYN8d015Bwyw/nnE/q27fVWU2R/zw6JrUx9Drjy FQVMgqOuERNwzn0KwGaHqsDz8FL/3NKzmm4KJQWcPNu76RgoKUhVdC2ItH8+O0piHURc yzzIGN7XdxxOb6Z9m5eXidg50bXUTf/eBfjt6hzqYeGaNnV4rJnyRIycp+3CRGmLo9DO zRAB5RyWdZgfADyQW1dGHaoj1NViYkqzzimvrclUTMs5NQrEsiyKlRJty+0RvCatwgIy 367A== X-Gm-Message-State: AN3rC/6etEQfdSQBGg5hbUbRmNp8zhDtPsQG5iZCmKhVB8LPY27E/gSn dh6iKTaKHaADJ6si5G5DrAnRD9e8mQ== X-Received: by 10.55.167.72 with SMTP id q69mr3150599qke.193.1492705786099; Thu, 20 Apr 2017 09:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: fgont.si6networks@gmail.com Received: by 10.140.29.52 with HTTP; Thu, 20 Apr 2017 09:29:45 -0700 (PDT) Received: by 10.140.29.52 with HTTP; Thu, 20 Apr 2017 09:29:45 -0700 (PDT) In-Reply-To: <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> From: Fernando Gont Date: Thu, 20 Apr 2017 13:29:45 -0300 X-Google-Sender-Auth: bVlrFQR4RAgGa3EAqzBLRvj-m7A Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Ole Troan Cc: Suresh Krishnan , 6man-chairs@ietf.org, 6man WG , Jeff Tantsura , IESG , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, Bob Hinden Content-Type: multipart/alternative; boundary=001a114feb68227bd2054d9ba6f6 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:29:49 -0000 --001a114feb68227bd2054d9ba6f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, RFC7872 was a while document. It followed the normal publication process, and we did do our best to address which comments. If this was published as it was, is because we didn't find a better way to convey the info. So I'm not sure what your speculation is about, but this is not the first time that I see see trying to find obscure reasons, when in fact there aren't any. As a datapoints, I started measuring EH drops because there was a lot of talk about the topic, but no data. I spent quite a lot of time on tools and measurements, assuming that the numbers would be better -- but they just were not (without double-checking your math, a 2.5% drop rate by intermediate Asses is still quite bad. And in fact, such numbers could actually be worse (read RFC7872 for the rationale)). What I'm really curious is how/why you pretend that EHs work just fine and argue that there's no data (when we even have RFC7872 with data specifically about this) -- and also why at the time you opposed to publication of such document (something which would have made your claim of "this is just speculation, there's no data" valid). PS: Give how the term "alternative facts" is being employed in modern times, I'd probably agree with you that RFC7872 provides alternative facts, though. Thanks, Fernando El 20/4/2017 17:15, escribi=C3=B3: Jeff, > somewhat oldish data points: > http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf > > IPv6 Extension Header (8 bytes) =E2=80=93 Failure rate: 52.53 % > IPv6 Extension Header (1 KBytes) =E2=80=93 Failure rate: 92.17 % Those numbers are alternative facts. They include the destination system. It would be as if you reported a 99.5% failure rate of SCTP because the end system didn't respond on the echo port. For reasons one can only speculate about the authors of RFC7872 chose to show their numbers the same way. >From 7872: DO8 | Web | 11.88% | servers | (17.60%/20.80%) Which means a drop rate by intermediate systems of 2.4%. A little less sensational. Cheers, Ole > Fernando, > >> On Apr 20, 2017, at 6:01 AM, Fernando Gont wrote= : >> >>> =E2=80=A6. >>> >>> Dropping unknown extension headers in transit networks is relatively >>> rare. With the HBH being an exception, with almost a 40% drop. (Note >>> that there are no HBH option that would make a lot of sense across >>> the Internet, so again chicken and egg.) >> >> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >> Extension Headers in the Real World"), your statement is incorrect. >> >> Transit routers do filter packets with EHs, whether known or unknown. > > I think this confirms that the current text which recommends against defining new EH is correct. > > Thanks, > Bob > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a114feb68227bd2054d9ba6f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ole,

RF= C7872 was a while document. It followed the normal publication process, and= we did do our best to address which comments. If this was published as it = was, is because we didn't find a better way to convey the info. So I= 9;m not sure what your speculation is about, but this is not the first time= that I see see trying to find obscure reasons, when in fact there aren'= ;t any.

As a datapoints,= I started measuring EH drops because there was a lot of talk about the top= ic, but no data. I spent quite a lot of time on tools and measurements, ass= uming that the numbers would be better -- but they just were not (without d= ouble-checking your math, a 2.5% drop rate by intermediate Asses is still q= uite bad. And in fact, such numbers could actually be worse (read RFC7872 f= or the rationale)).

What= I'm really curious is how/why you pretend that EHs work just fine and = argue that there's no data (when we even have RFC7872 with data specifi= cally about this) -- and also why at the time you opposed to publication of= such document (something which would have made your claim of "this is= just speculation, there's no data" valid).

PS: Give how the term "alternative facts&= quot; is being employed in modern times, I'd probably agree with you th= at RFC7872 provides alternative facts, though.

<= /div>
Thanks,
Fernando






El 20/4/2017 17:15, <otroan@employees.org> escribi=C3=B3:
=
Jeff,

> somewhat oldish data points:
> http://www.iepg.org/20= 13-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf
>
> IPv6 Extension Header (8 bytes) =E2=80=93 Failure rate: 52.53 %
> IPv6 Extension Header (1 KBytes) =E2=80=93 Failure rate: 92.17 %

Those numbers are alternative facts. They include the destination sys= tem.
It would be as if you reported a 99.5% failure rate of SCTP because the end= system didn't respond on the echo port.

For reasons one can only speculate about the authors of RFC7872 chose to sh= ow their numbers the same way.

>From 7872:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 DO8
| Web=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 11.88%
| servers=C2=A0 | (17.60%/20.80%)

Which means a drop rate by intermediate systems of 2.4%. A little less sens= ational.

Cheers,
Ole

>=C2=A0 =C2=A0 Fernando,
>
>> On Apr 20, 2017, at 6:01 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>
>>> =E2=80=A6.
>>>
>>> Dropping unknown extension headers in transit networks is rela= tively
>>> rare. With the HBH being an exception, with almost a 40% drop.= (Note
>>> that there are no HBH option that would make a lot of sense ac= ross
>>> the Internet, so again chicken and egg.)
>>
>> Based on RFC7872 ("Observations on the Dropping of Packets wi= th IPv6
>> Extension Headers in the Real World"), your statement is inco= rrect.
>>
>> Transit routers do filter packets with EHs, whether known or unkno= wn.
>
>=C2=A0 =C2=A0 I think this confirms that the current text which recomme= nds against defining new EH is correct.
>
>=C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 Bob
>
>
>=C2=A0 =C2=A0 ----------------------------------------------------= ----------------
>=C2=A0 =C2=A0 IETF IPv6 working group mailing list
>=C2=A0 =C2=A0 ipv6@ietf.org
>=C2=A0 =C2=A0 Administrative Requests: https://www.iet= f.org/mailman/listinfo/ipv6
>=C2=A0 =C2=A0 ----------------------------------------------------= ----------------
>
>
>
> ------------------------------------------------------------= --------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------


--001a114feb68227bd2054d9ba6f6-- From nobody Thu Apr 20 10:09:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38BB129B35; Thu, 20 Apr 2017 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AehB48ghYhHO; Thu, 20 Apr 2017 10:09:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3989129B2F; Thu, 20 Apr 2017 10:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1988; q=dns/txt; s=iport; t=1492708190; x=1493917790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GRTyG7LSjjt+LkxvT1/7IAeIToBHYUwAvuTbEWZGex4=; b=Qw6JuqPQ+SYYciCdNHSr8PUpolqP1ENJ2xkJy1Kt4p3U1s14t8CI/Cvr joT9RD9k08fyUOXSEJwSneQ/wHeThBXZGtaELYK5b4SSAkeM5XB+P6pAi DsARStTFvIZdg4PUWWCl8sIQ0pV+xXXQJEL8j6d33nKlEMkVAbuwssIal A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AQAw6/hY/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFliB6IYYRkgg8hC4V4AhqDYz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CwULAgEIGAICJgICAh8GCxUFCwIEDgWKBAMNCA6qX?= =?us-ascii?q?4Imhy8Ng2YBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUiCCIJuglGCBoMGLoI?= =?us-ascii?q?xBYk1k0Q7AY45hEmRVYsQiQMBHziBBWMVRBEBhQmBSnWIIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208";a="413059533" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 17:09:49 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3KH9mPV002595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 17:09:49 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 13:09:48 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 13:09:48 -0400 From: "Stefano Previdi (sprevidi)" To: Bob Hinden CC: Fernando Gont , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?6man-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFu?= =?utf-8?Q?-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHSufjq+97r94diikaiouggLxQGJw== Date: Thu, 20 Apr 2017 17:09:48 +0000 Message-ID: <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> In-Reply-To: <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.217.160] Content-Type: text/plain; charset="utf-8" Content-ID: <842C8FCC725BD744AE1F5489FF91A317@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:09:52 -0000 DQo+IE9uIEFwciAyMCwgMjAxNywgYXQgNTo0NyBQTSwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBn bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gRmVybmFuZG8sDQo+IA0KPj4gT24gQXByIDIwLCAyMDE3 LCBhdCA2OjAxIEFNLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+IHdyb3Rl Og0KPj4gDQo+Pj4g4oCmLg0KPj4+IA0KPj4+IERyb3BwaW5nIHVua25vd24gZXh0ZW5zaW9uIGhl YWRlcnMgaW4gdHJhbnNpdCBuZXR3b3JrcyBpcyByZWxhdGl2ZWx5DQo+Pj4gcmFyZS4gV2l0aCB0 aGUgSEJIIGJlaW5nIGFuIGV4Y2VwdGlvbiwgd2l0aCBhbG1vc3QgYSA0MCUgZHJvcC4gKE5vdGUN Cj4+PiB0aGF0IHRoZXJlIGFyZSBubyBIQkggb3B0aW9uIHRoYXQgd291bGQgbWFrZSBhIGxvdCBv ZiBzZW5zZSBhY3Jvc3MNCj4+PiB0aGUgSW50ZXJuZXQsIHNvIGFnYWluIGNoaWNrZW4gYW5kIGVn Zy4pDQo+PiANCj4+IEJhc2VkIG9uIFJGQzc4NzIgKCJPYnNlcnZhdGlvbnMgb24gdGhlIERyb3Bw aW5nIG9mIFBhY2tldHMgd2l0aCBJUHY2DQo+PiBFeHRlbnNpb24gSGVhZGVycyBpbiB0aGUgUmVh bCBXb3JsZCIpLCB5b3VyIHN0YXRlbWVudCBpcyBpbmNvcnJlY3QuDQo+PiANCj4+IFRyYW5zaXQg cm91dGVycyBkbyBmaWx0ZXIgcGFja2V0cyB3aXRoIEVIcywgd2hldGhlciBrbm93biBvciB1bmtu b3duLg0KPiANCj4gSSB0aGluayB0aGlzIGNvbmZpcm1zIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCB3 aGljaCByZWNvbW1lbmRzIGFnYWluc3QgZGVmaW5pbmcgbmV3IEVIIGlzIGNvcnJlY3QuDQoNCg0K V2VsbCwgaW4gZmFjdCBJIGJlbGlldmUgaXTigJlzIHRoZSBleGFjdCBvcHBvc2l0ZS4NCg0KRGVm aW5pdGlvbiBvZiBuZXcgRUhzIG11c3QgYmUgZG9uZSBjYXJlZnVsbHkgYnV0IEkgZG9u4oCZdCBz ZWUgd2h5IGl0IHNob3VsZCBiZSBwcmV2ZW50ZWQsIGtub3dpbmcgYWxzbyB0aGF0IHRyYW5zaXQg cm91dGVycyB3b3VsZCBhbnl3YXkgZmlsdGVyIEVILXBhY2tldHMgb3V0IChoZW5jZSBtaXRpZ2F0 ZSB0aGUgaW1wYWN0IG9mIG5ldyBFSHMgaW50cm9kdWN0aW9uKS4NCg0KRUggaXMgcHJvYmFibHkg X3RoZV8gbW9zdCBpbm5vdmF0aXZlIGFuZCBwb3dlcmZ1bCBmZWF0dXJlIG9mIGlwdjYuIA0KDQpz Lg0KDQoNCj4gDQo+IFRoYW5rcywNCj4gQm9iDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Thu Apr 20 10:24:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBDC129B39; Thu, 20 Apr 2017 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 msvJ8IX7k2UH; Thu, 20 Apr 2017 10:23:55 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 7ED1E129B2D; Thu, 20 Apr 2017 10:23:53 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id o21so40110990wrb.2; Thu, 20 Apr 2017 10:23:53 -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=O3iMIHR0bzIbosJTGf4I+0nNHLpLFX3U9RHSrDc1yK0=; b=tCGijudyfv+tb5ty2ch1z8kPzANJeR3oBABbqI3rAFh/NrOS8fGFR4WIrmIfgDzDCR G7g4qCYm4SvzeuJ1YVDtTlDtBVq9xvRLBxNK/RnlkFNUA38amu/1VWqhP4NTP0bGL4dn 4yTxSOX/rpwkdJBFq9b+lCREmSad7t5Q7T/2a+91dNUQIdfDHVsTRBHjByfVaYylyDz4 ichs/Yn/vb24wh9kOZZl2X9lVm/U2B1KbAxS9TfAnvEw6N032hDvZ8OaU4chBUWXXEGv 55GO0Wcl9VpT3ATHV7vjbB/qpJZ8xetxDT2VrzQW+WYvom93g8stt6Kthg5wyGO4JI1N qWDw== 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=O3iMIHR0bzIbosJTGf4I+0nNHLpLFX3U9RHSrDc1yK0=; b=Y+T551K/6rNgbN6UrbCGfTnR/H5IVTs3CarcnHN8TcWzJ98QSorxoEfmjKj0gkpNLJ ExBg5w0URv9+Gxl8hdZbfisD+4QEs5b72WGOwvZc2qlrblyNY9W5MCkcEDDBuEPmjQqX 0ih30hH7tGlrUWnhI8YrhX7W5b0qqzSco+Pa7xjHAbVEPjjk2FI9iATCywHPrWKz9aKT h0qk134tUzwLCpsSbwj28ErRSLc+jlNnv5JqrILPmdeD3pI8O2bEIxxPbnhv02bT1gNB zAlP5Fbz4KIImScMR2zRm0yq2HVVI7Mm/++1Hms+Uf9ddEKeR0A5IardiqGG3vvft9iU k1Ew== X-Gm-Message-State: AN3rC/78xf0DqMcJXeBAAoaNYVddX72la82h7p92pLhJk1qm06Pnqd3H pqeXheJv7QlmVg== X-Received: by 10.223.176.36 with SMTP id f33mr3581480wra.124.1492709032022; Thu, 20 Apr 2017 10:23:52 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:9cf5:b82e:11d6:5b43? ([2601:647:4d01:db10:9cf5:b82e:11d6:5b43]) by smtp.gmail.com with ESMTPSA id w186sm8843519wme.26.2017.04.20.10.23.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 10:23:49 -0700 (PDT) From: Bob Hinden Message-Id: <64E307CB-A01D-4BDA-A369-289E1BD5C43A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_86A514B6-E149-4616-B4AE-F22C3B51CD5B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 10:23:44 -0700 In-Reply-To: <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com> Cc: Bob Hinden , Fernando Gont , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> To: "Stefano Previdi (sprevidi)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:23:57 -0000 --Apple-Mail=_86A514B6-E149-4616-B4AE-F22C3B51CD5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stefano, > On Apr 20, 2017, at 10:09 AM, Stefano Previdi (sprevidi) = wrote: >=20 >=20 >> On Apr 20, 2017, at 5:47 PM, Bob Hinden wrote: >>=20 >> Fernando, >>=20 >>> On Apr 20, 2017, at 6:01 AM, Fernando Gont = wrote: >>>=20 >>>> =E2=80=A6. >>>>=20 >>>> Dropping unknown extension headers in transit networks is = relatively >>>> rare. With the HBH being an exception, with almost a 40% drop. = (Note >>>> that there are no HBH option that would make a lot of sense across >>>> the Internet, so again chicken and egg.) >>>=20 >>> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >>> Extension Headers in the Real World"), your statement is incorrect. >>>=20 >>> Transit routers do filter packets with EHs, whether known or = unknown. >>=20 >> I think this confirms that the current text which recommends against = defining new EH is correct. >=20 >=20 > Well, in fact I believe it=E2=80=99s the exact opposite. >=20 > Definition of new EHs must be done carefully but I don=E2=80=99t see = why it should be prevented, knowing also that transit routers would = anyway filter EH-packets out (hence mitigate the impact of new EHs = introduction). The current text is: Defining new IPv6 extension headers is not recommended. There has to be a very clear justification why any new extension header is needed before it is standardized. Instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility. Following this text is the recommended format for new extension headers = if they are defined. I think is inline with what you said, that is =E2=80=9Cdone carefully=E2=80= =9D and not prevented. Bob >=20 > EH is probably _the_ most innovative and powerful feature of ipv6. >=20 > s. >=20 >=20 >>=20 >> Thanks, >> Bob >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 --Apple-Mail=_86A514B6-E149-4616-B4AE-F22C3B51CD5B 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+O6hAAoJEK7rdBF357uoXmYIALbledlnwLkCjM/Ak+AcF9WY oF1z5Pb+B8lXGSK5PSBprDE2DKkp6zmZPgbeK2JVe/rP5tqd9iRjeQJwLQTxbqUj TZI+zK9ct/W3esiPTDq47n5OVrGfUKTmLAqZA6cCwfRvuO66MeS34sftRaPLj3jY n8AyZcRr4QwzVel5ITtSFSFbCpftkWyeYwyITOh/9Qs+mWO6m8SaQnIyYB33b+8p pbtnADHQaQzPFkeIRE/h5nu+sxEP3HAdaN7eyugyBj/DYBU/zW/7rH6CH2bmbB3G OPW9129lnDz3bk9CwmiT7AKjBuVZ51rM3L73lPlBzivZPp5Z/HrMwVmclz+lQms= =PdCq -----END PGP SIGNATURE----- --Apple-Mail=_86A514B6-E149-4616-B4AE-F22C3B51CD5B-- From nobody Thu Apr 20 11:55:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB937129BA2; Thu, 20 Apr 2017 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 fsormkO8yuwl; Thu, 20 Apr 2017 11:54:59 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D83C413154E; Thu, 20 Apr 2017 11:54:52 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 18:54:52 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 21FBDD788D; Thu, 20 Apr 2017 11:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=KyA941rJVnMVScMMK4cEu9WAm6U=; b= GVhXB1RBPmNxBAszr1ibNHlKAGXpxB3W/B20LSdyjmRQ89YhwOyZcg/scEsIX+pY AvqqWLs+QmQLYtCpDWyy163j/5eXeioLs7nVo51+2KcUeuOIfbN51aDzqTbuehCk vMyjAWWH0GbfmzRK3wx6COoupIvkr+8pX5rB8Y1tgTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=LIeyAumSx049Hi5UiXIoc8Y yHFfRBWoV8XB61cTL1JVEhv7eDncLMXO9O1fgv+Eg+OCXg3OMWbS+HT6PYBpzB0U hIgwA56ojtA1pgQv+SLMeFCeoMMK99TJfvoLwhzAgpqVt33KUXw12O8zfLZuvjhw 1FZ2iXFX5sikjWgabb/8= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C1AC0D788B; Thu, 20 Apr 2017 11:54:51 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B02A3ACC0B09; Thu, 20 Apr 2017 20:54:49 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2B0C0710-ECEF-404C-A55E-1A6BA11C71E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 20:54:48 +0200 In-Reply-To: Cc: Suresh Krishnan , 6man-chairs@ietf.org, 6man WG , Jeff Tantsura , IESG , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, Bob Hinden To: Fernando Gont References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 18:55:02 -0000 --Apple-Mail=_2B0C0710-ECEF-404C-A55E-1A6BA11C71E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando, > RFC7872 was a while document. It followed the normal publication = process, and we did do our best to address which comments. If this was = published as it was, is because we didn't find a better way to convey = the info. So I'm not sure what your speculation is about, but this is = not the first time that I see see trying to find obscure reasons, when = in fact there aren't any. >=20 > As a datapoints, I started measuring EH drops because there was a lot = of talk about the topic, but no data. I spent quite a lot of time on = tools and measurements, assuming that the numbers would be better -- but = they just were not (without double-checking your math, a 2.5% drop rate = by intermediate Asses is still quite bad. And in fact, such numbers = could actually be worse (read RFC7872 for the rationale)). >=20 > What I'm really curious is how/why you pretend that EHs work just fine = and argue that there's no data (when we even have RFC7872 with data = specifically about this) -- and also why at the time you opposed to = publication of such document (something which would have made your claim = of "this is just speculation, there's no data" valid). I don't pretend EHs (or pretty much anything on the Internet) work just = fine. I only ask you to represent your measurements in an open and honest way. What the RFC does and even more so the presentation Jeff pointed at is = spreading FUD and does not in any way help the community. I do not think a drop rate in the area of 2.5% warrants: "today's routers are highly likely to drop packets with unknown = headers". And that's the problem with your sensationalist way of presenting the = data, people are left with the impression that EHs are not possible to = use. I don't know if 2.5% is a high number or not. In this from RIPE, 8-9% of = RIPE Atlas probes have problems with IPv4 fragmentation. https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters Ole >=20 > PS: Give how the term "alternative facts" is being employed in modern = times, I'd probably agree with you that RFC7872 provides alternative = facts, though. >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 >=20 >=20 > El 20/4/2017 17:15, escribi=C3=B3: > Jeff, >=20 > > somewhat oldish data points: > > = http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf > > > > IPv6 Extension Header (8 bytes) =E2=80=93 Failure rate: 52.53 % > > IPv6 Extension Header (1 KBytes) =E2=80=93 Failure rate: 92.17 % >=20 > Those numbers are alternative facts. They include the destination = system. > It would be as if you reported a 99.5% failure rate of SCTP because = the end system didn't respond on the echo port. >=20 > For reasons one can only speculate about the authors of RFC7872 chose = to show their numbers the same way. >=20 > >=46rom 7872: > DO8 > | Web | 11.88% > | servers | (17.60%/20.80%) >=20 > Which means a drop rate by intermediate systems of 2.4%. A little less = sensational. >=20 > Cheers, > Ole >=20 > > Fernando, > > > >> On Apr 20, 2017, at 6:01 AM, Fernando Gont = wrote: > >> > >>> =E2=80=A6. > >>> > >>> Dropping unknown extension headers in transit networks is = relatively > >>> rare. With the HBH being an exception, with almost a 40% drop. = (Note > >>> that there are no HBH option that would make a lot of sense across > >>> the Internet, so again chicken and egg.) > >> > >> Based on RFC7872 ("Observations on the Dropping of Packets with = IPv6 > >> Extension Headers in the Real World"), your statement is incorrect. > >> > >> Transit routers do filter packets with EHs, whether known or = unknown. > > > > I think this confirms that the current text which recommends = against defining new EH is correct. > > > > Thanks, > > Bob > > > > > > = -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > = -------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 >=20 --Apple-Mail=_2B0C0710-ECEF-404C-A55E-1A6BA11C71E0 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+QP4AAoJEL7aWKiYQt92rpEQALXOuWgxB6UHfemriW80i5cG MefdB/gFxQKSgayhDXkpwg+OHS+jbDNMVQFrD538mYC2ztHysam1AzRt/j3ACGB2 ALBPhgx74rMBUZWuWqt5b14zDbOu3bJBWn6xT3J9SLghSwozgnRuuYrxNnHvX7SN 0YmLsWn8AhfIL3hp1ZXPc6JdcANCatsuEDqfKbJ6KqUsbMhDkkxesHSIzscdztJL tieo1cObVz+GYNSOn3UZPhSpqkWtUpBf8XVkozI0PX0xKLiTCaIayRpi7XWHnnMv nTH2nZ55Se7JYD4IIqo6V+jY6htXFaqHMkoaYzJLfrv4Jn/80rN1cTD9kkliqa98 XXBYtEMffD/pq2R4LDNVn3mnFQZT37WDv5xUXCVYjwk6zNIl3fnmA/uHVY2DApSz HU5awqQmK/FP/5/kDG6SHFFzTjs1O5BNxhk9RarVEMO/XF0Zb8xBIOGp2ltxs7IK nFz+9yV+PRtIA4AC8i2LxbIeMcTV9RAIQ1D8o/5UAYEuc9m9kMUrWSGgBjkU76XB LaVUM8twCy3zZM8BnnYu4JH+9hiTR5eTlanzOqPlm0IfJxN9LxoAzOPBTUp4G3VB r9a7Cp0UEsoMJirx3sw1IAC7th7+2DfW+F3NBjRohikZv/bjv18CcHcGyrExwky+ r4wXBZQCKWAJntVyk5Vj =SK/M -----END PGP SIGNATURE----- --Apple-Mail=_2B0C0710-ECEF-404C-A55E-1A6BA11C71E0-- From nobody Thu Apr 20 12:43:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1B4129AAF for ; Thu, 20 Apr 2017 12:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 r53rRUsGFDIs for ; Thu, 20 Apr 2017 12:43:39 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 B442F129BFF for ; Thu, 20 Apr 2017 12:43:39 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id r16so80548656ioi.2 for ; Thu, 20 Apr 2017 12:43:39 -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=8rbN+UzBBeRGBM4IDV+k8/NgHfgKFjyELIwcJ/PFTFg=; b=LVErJKDiIZNPE/6UU0qBscaQwxlXom/NO6xnB/NfLhhGNjyxMp+NZafs10LSxyHrCD HyLhcJXsq+gaGjJZewEj1GYdGtrxDFP2q7QRZR7qk5mvgpxKZO7e0xvAAWGXWehq/hfF 4m+uATnrWS/osjDh8Rt2E4U93Prsaqf8cq0ihiRnjPDjflP+4f0Ro8CjSX+a7UYJqaqV OhkqaqgzTpLfa2GmU8wqC2PcG61ev1lIitmZR5KNHYLrKhXyJD9tdPHYNOloYDyBFOXx xB4FPJsO/ubfnBOVqGfn/mv1UPJUGxJG++wXRm41hp++ynBBlz3NmJOFHkKd2f+AaaNy iGlg== 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=8rbN+UzBBeRGBM4IDV+k8/NgHfgKFjyELIwcJ/PFTFg=; b=RFn4So4JIy23c83y0Th/qaqAatI+Jq1hXzxXcxTzOj51QpFreOKq0vQ1BdAZr4PCvK IDVTbRcrVfOFTeYn2AkrH6i22BZPRbpuX1fGuEtKEvfj+9Acskk1iPyuhoJ4FfcHcEYS n3k2+7S8OHzBTikgW01qIkzHp/W5NnWOnP/tSZiXkyZ0XzZzh5N1U85ia10yfJpCncYK TI0BMQCFv4jpYC3jkis1RNeTSG9JezpwKljKGSLB2ChO/khjW8z5jkoLO/Zg9xduhR2+ xiULrXsCZhAE4Q6v4/allzCpuFSvfoCFFEerWYflSLJ89nPLt08SUZRzo33rRoNjthdR DW9A== X-Gm-Message-State: AN3rC/5OyIyOer6a6PEmJ0ErSM3C4ZgOk94mlx2nFPT0+b8UYfbWO8BA SD67gGfDZnBjug== X-Received: by 10.107.58.135 with SMTP id h129mr12017393ioa.70.1492717417972; Thu, 20 Apr 2017 12:43:37 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id e81sm3089825ioe.18.2017.04.20.12.43.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 12:43:37 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9BFEB9EC-BBFA-48B0-BD79-8C2037F50D59"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Revised and expanded rfc2460bis Security Considerations Date: Thu, 20 Apr 2017 12:43:34 -0700 In-Reply-To: Cc: Bob Hinden , james woodyatt , Eric Rescorla , IPv6 List To: Brian Carpenter References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:43:41 -0000 --Apple-Mail=_9BFEB9EC-BBFA-48B0-BD79-8C2037F50D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Apr 19, 2017, at 5:14 PM, Brian E Carpenter = wrote: >=20 > On 20/04/2017 09:34, james woodyatt wrote: >> On Apr 19, 2017, at 13:55, Bob Hinden wrote: >>>=20 >>> The current and proposed new text is below. Please review and = comments. I hope to publish a new draft at the end of the week. >>=20 >> Bravo! Alas, I have a nit. >=20 > +1 >=20 Thanks. > Should we include references where they exist, e.g. for scanning = attacks and address privacy? Yes, Fernando has some good suggestions. Bob >=20 > Brian >=20 >>=20 >>>> [...] These security issues include: >>>>=20 >>>> o Eavesdropping [...] >>>> o Replay [...] >>>> o Message insertion [...] >>>> o Message modification [...] >>>> o Man in the Middle attacks [...] >>>> o Denial of Service Attacks [...] >>>>=20 >>>> IPv6 packets can be protected from eavesdropping, packet = modification, replay, and man in the middle attacks by use of [...] >>=20 >> p1. The order used to present the list of security issues should be = also be used to present the methods of protection. >>=20 >> p2. The issue =E2=80=9Cmessage modification=E2=80=9D changes to = =E2=80=9Cpacket modification=E2=80=9D from one list to the next. I think = this should be clarified. >>=20 >> p3. No further mention of =E2=80=9Cmessage insertion=E2=80=9D is made = after its appearance in the list of issues, even one similar to the = =E2=80=9Cdenial of service attack=E2=80=9D issue, to explain that no = defensive mechanism is defined, and it is left out of scope for this = specification. >>=20 >>=20 >> --james woodyatt >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 --Apple-Mail=_9BFEB9EC-BBFA-48B0-BD79-8C2037F50D59 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+Q9nAAoJEK7rdBF357uobioH/ixiyUOOuZvI1toW0rLAj3sm kBiSMJRK6pbMg5x7a8vYv1n88IVjLCKxtWc/iPL+z1B/qw6Rtoo+OTxuiL359EUR ej8n9/8MlKuKhsYVZ1L1/2HrkG2FOt7EahxWDDFAAIGEKaPSDYpA1gbuNb/vIPJz POYzODJMpeyp4D1BdLbtv5ZQiKzC5PQA/cuH7HCMnbtqQbpALO09uTW9yZ3lsAiv frKzBzOS7CxcmpusnfPIlAGFdyJrPVZ3MWuMWAGP+16JrNhoYrOLIe0M/CxQ20rt Zg7SSnbYzG5uF2RgdrUdK32Sgidjry5LAat743A8l8SQOpfuB/YgJxZYZrH7dY0= =4j0+ -----END PGP SIGNATURE----- --Apple-Mail=_9BFEB9EC-BBFA-48B0-BD79-8C2037F50D59-- From nobody Thu Apr 20 13:22:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B9129AEA; Thu, 20 Apr 2017 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 1-h3VIGfMUcy; Thu, 20 Apr 2017 13:22:24 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 4FF8E127869; Thu, 20 Apr 2017 13:22:24 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id h41so20412621ioi.1; Thu, 20 Apr 2017 13:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gfTUNo3jRWnZx2W7aSWK7NsJfI04stUkq70VrLbv65E=; b=Ag8dL2XL/yN1yOYaTEu3XI67F6ekKDbVyvXQ9Nj+gzvPzZHluuTSNNwcHNrW7ciQSy gAHLIA/AKPvAkpQP3NOfXME5m8gPTjO+dijZDe4cOeGS1l7yg9LPMXLWFwv7jawoc+TQ zije05J3nVcCAFuMRCDX+sCatth1INAgoifnlL8AJ9oOhh7qampDkzLGHqZ4uZi93Yji yjyIOqbrwhTK3jMafFSwDFKwb35hbOJfcCUM6PXOu4iwQMFfD82kIbkpn9DW7DzKC1JO g8xuOBhrXp+0n1VNbXDqWT7YUtj5zTHJ6hUoNsQzz/XkJZr8E+J7bn2wZmqDk8FNyTK6 mwOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=gfTUNo3jRWnZx2W7aSWK7NsJfI04stUkq70VrLbv65E=; b=IH+8nEP7nzvnPDfYA+hHZlQebk6ak0ptbMtNmYVHELFs5NcGHs9hVkrX4KASuHlqeH EQX2Bfm2RVVk4EzWFFQnfJ5hQIvj97RxajkqdZbm3lA39MUXIUZw5H65TBzYF7WKcrqi NEqyG1hEeKd3651SQ1nABU12fNfF+hyARtWBTUdC0VRVXZW1crsnt89wKVAUmcPHxuiu 0pMEZvwxV5sagE0VU05chzWmDvvtWTXwM0asujea/SZQFFs3eIEqr3d0M6DD3yfvgJmL luEiyTskw0s1LOojf17m3LIZj3UTeIiDv+9LYW9BuR6w5dmB5wYNcNh3eQ9d0dX97DZD 9Cjw== X-Gm-Message-State: AN3rC/5+kdb/3u/xvryEiZ06nsoyJ6p2oSc9WyFRjaw9nfO5cM+vchQQ AADX+6Zz01HuTw== X-Received: by 10.99.119.4 with SMTP id s4mr9185408pgc.71.1492719743264; Thu, 20 Apr 2017 13:22:23 -0700 (PDT) Received: from [192.168.178.21] ([118.149.101.128]) by smtp.gmail.com with ESMTPSA id c77sm4960087pfe.37.2017.04.20.13.22.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 13:22:22 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden , Fernando Gont References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 21 Apr 2017 08:22:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:22:26 -0000 On 21/04/2017 03:47, Bob Hinden wrote: > Fernando, >=20 >> On Apr 20, 2017, at 6:01 AM, Fernando Gont wro= te: >> >>> =E2=80=A6. >>> >>> Dropping unknown extension headers in transit networks is relatively >>> rare. With the HBH being an exception, with almost a 40% drop. (Note >>> that there are no HBH option that would make a lot of sense across >>> the Internet, so again chicken and egg.) >> >> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >> Extension Headers in the Real World"), your statement is incorrect. >> >> Transit routers do filter packets with EHs, whether known or unknown. >=20 > I think this confirms that the current text which recommends against de= fining new EH is correct. Hate to say it, but yes, IMHO that was a clear WG consensus and I don't t= hink the IESG has the right to override it. On 21/04/2017 05:09, Stefano Previdi (sprevidi) wrote: =2E.. > Definition of new EHs must be done carefully but I don=E2=80=99t see wh= y it should be prevented, which is exactly why the consensus is *not recommended* rather than *must= not*. Even without formally using RFC2119, the distinction is clear. Why are we re-litigating this? On 21/04/2017 06:54, otroan@employees.org wrote: =2E.. > I do not think a drop rate in the area of 2.5% warrants: > "today's routers are highly likely to drop packets with unknown headers= ". That's beside the point for 2460bis. The point is that unknown EHs are dr= opped on *some* paths, which makes deploying them tricky, regardless of the per= centage. Brian Brian From nobody Thu Apr 20 13:31:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C67129526; Thu, 20 Apr 2017 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 iyWw4pJmGjsA; Thu, 20 Apr 2017 13:31:29 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id F39F712943F; Thu, 20 Apr 2017 13:31:28 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Apr 2017 20:31:28 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 317C3D788A; Thu, 20 Apr 2017 13:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=sUuF+uPw6lRBYGAt2iZDd+SqAnc=; b= mBjKnP1tC8IUwU5wIYfIh0ZscgHEK/+Y5HcEYl7ntxcMe5yeswH1HHV2jjNaY/oj 0bbkaHvk944Q4r0u/F/aCdSn7WAqRRb8t1/YCAir76VOE6sSXwq+VjoitHCmthP6 4yQoqcy8JqjyU76+qkuh1jauCdbdsse6Li7es5RAFiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=LcNw4/OZscD0EmNgH3oXilM jvQnb5oN6GVtaR2/OO3drqYOfsuipNP0tHgDMkw7EDB5koBjDsSndbIlpB+85z3m vOF2W25BQr9XbMuGn2ronEePFGJfDIuW2AgDjTl/GUdYEMFWXW0bR8HpUBYQDs7E SGfgDU6+NH2qrjc9JtCk= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B8480D788F; Thu, 20 Apr 2017 13:31:27 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3491FACDD3C3; Thu, 20 Apr 2017 22:31:26 +0200 (CEST) From: otroan@employees.org Message-Id: <819143C5-5CB7-41F5-94B2-CA40611FFED7@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D5F14DFA-597A-4BEA-9B54-2B5A57DC00FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Thu, 20 Apr 2017 22:31:25 +0200 In-Reply-To: Cc: Bob Hinden , Fernando Gont , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org To: Brian E Carpenter References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:31:31 -0000 --Apple-Mail=_D5F14DFA-597A-4BEA-9B54-2B5A57DC00FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, >>>> =E2=80=A6. >>>>=20 >>>> Dropping unknown extension headers in transit networks is = relatively >>>> rare. With the HBH being an exception, with almost a 40% drop. = (Note >>>> that there are no HBH option that would make a lot of sense across >>>> the Internet, so again chicken and egg.) >>>=20 >>> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >>> Extension Headers in the Real World"), your statement is incorrect. >>>=20 >>> Transit routers do filter packets with EHs, whether known or = unknown. >>=20 >> I think this confirms that the current text which recommends against = defining new EH is correct. >=20 > Hate to say it, but yes, IMHO that was a clear WG consensus and I = don't think > the IESG has the right to override it. >=20 > On 21/04/2017 05:09, Stefano Previdi (sprevidi) wrote: > ... >> Definition of new EHs must be done carefully but I don=E2=80=99t see = why it should be prevented, >=20 > which is exactly why the consensus is *not recommended* rather than = *must not*. > Even without formally using RFC2119, the distinction is clear. >=20 > Why are we re-litigating this? >=20 > On 21/04/2017 06:54, otroan@employees.org wrote: > ... >> I do not think a drop rate in the area of 2.5% warrants: >> "today's routers are highly likely to drop packets with unknown = headers". >=20 > That's beside the point for 2460bis. The point is that unknown EHs are = dropped > on *some* paths, which makes deploying them tricky, regardless of the = percentage. of course. but it is a difference between something that is "fixable" = and something that is not. if you read my comments as suggesting anything but support for the = current text from the WG, then I apologise. Best regards, Ole --Apple-Mail=_D5F14DFA-597A-4BEA-9B54-2B5A57DC00FC 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+RqdAAoJEL7aWKiYQt92J3YP/1wuyJWaarZyOTfJCc+QkZv2 VKx1vV2Ala/gNw9+aB96ykUz+kmW1uwL+sYKFQSncFI5iil/CBS7NcBa47D/+eqY U+l6u8CAfXlZYcQj7MP+S1j9uefBDsyliPJ/JJStrHx6Bcf7uUle5B8onBQNzROu drPIzihDKoE/WNX8bdlQlp26qfSZ4M/NYVB9FB3h03Ld1Uit2dIqWtbog8ZLJnkF 9e/3XqRlnNLFgSrf2b2ulDv+xc1X6egl7xtmE+gibPpJg9gFe4q2Fq3LvrgmOZM2 cWsMSsap1ZfPqfLJAVHPZ7XMrzujA6CD0Rr+yXQ+GV2YCKxPjlXm05rwbirwvcB6 ozrqoIJPkvGM6qG7Ah7EfllsZOAVut+rAY/Suy5UL60+k41Pn4wKyBudvNrFpNr+ NY/vJtixvTVpj8Eu4QAeoo9NO4fr+RFp6jsvz8nzXnPZ8LOP1v53/bI7DZ29dY44 8N242mdie/fscQcw4As9sVgwERggS400EhbIL0i0WEXEiCUXhLvQf1Y5NakRwoIv GCQN50YMJDOjH2t0+domnXgb55T0LBVCdwMOur+k6hgiJZmTZjWdaeP8EpsbYn4v MttVJ9Aec1pqNk3zNdMERl7cd5pFITr2vGO/FXNkjKvq31VQU4eLA4MjrWbIxFyi VaUgZDzCBQGzRtGUNhZO =vLPs -----END PGP SIGNATURE----- --Apple-Mail=_D5F14DFA-597A-4BEA-9B54-2B5A57DC00FC-- From nobody Thu Apr 20 13:42:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B017129AF2 for ; Thu, 20 Apr 2017 13:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 n9C8jBSET1Ad for ; Thu, 20 Apr 2017 13:42:25 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 B88E713168D for ; Thu, 20 Apr 2017 13:42:21 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so82531679ioi.2 for ; Thu, 20 Apr 2017 13:42:21 -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=vFfPR8uxRSRJJ1/0cWv7YWaGByDAXtXQ4VjHw9cpbVI=; b=IGBvznuZVglWjBt7JtUzG7Bq+RNrFSYWxkNkW15ahqlJ7nf2WiM2/V7n9PCxGKLKu9 k2Z6HDeWtH7CkgxfKZ8ERauma6yktfdCTkiiGaCMl74NH52Ok747e7PLXbASwmpRTqxc HIxol90Ag80g83QwN0EKDUd9oO3MBlPCO/9u4BYF+xgHG0tqTDc5at5y3RIC/ll409jj R2J2yTXA64DbjdOwByi7SFt4DCHYNy+RIrAin2wSf638FYbZxvEkrM9cikrkZuzg84w2 8vDRfV3T7QsNcnq0jRTNBNN0Fcme8a1+ICSdIlE82a2YmTuaG31fvkovu3W7SLT4urEV dfvA== 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=vFfPR8uxRSRJJ1/0cWv7YWaGByDAXtXQ4VjHw9cpbVI=; b=t0rGuoPlL3FguF0XvAMytTssX84RGS8Z3CX4RiSRGP3V0rmV2A+kUagzeGsbr7zpax kxbr4NQItOK2WdNzZyOLHITv5pRy2edQBzhVxNNQMq0wdRBdas+UcT3UU1obDmLGZfCQ Od4QV/vq9sp+NnERGisM6d20Ch9ZdFj9hApqphdyCK8LVJQWfQh3dzbbIF2noIhsicdD 37vbX+SwEx49x2mHwbarSCvQKhwbI5+aLViNz+I2WbCwspx+hDAs6DL4o8IaPI0WnGeF mYy+4LmwuM4uskse8ChamaAeBRNcfTfFAVcFkTZyQPFjYAzR7z/Utce5rIT4l74AQALq Ejng== X-Gm-Message-State: AN3rC/7m3OMbicaWf02mH9mhJBcT9ulB7T30m5gbMzwa2/k8hpyRazhh txWg2e+OZbj1TQ== X-Received: by 10.36.40.81 with SMTP id h78mr6267474ith.44.1492720940198; Thu, 20 Apr 2017 13:42:20 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id l140sm132921itl.21.2017.04.20.13.42.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 13:42:19 -0700 (PDT) From: Bob Hinden Message-Id: <45E382A3-BB33-4016-B7FA-59E5A6AC6E81@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4E24D058-8B54-46ED-820A-543CFD0796F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Revised and expanded rfc2460bis Security Considerations Date: Thu, 20 Apr 2017 13:42:18 -0700 In-Reply-To: <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> Cc: Bob Hinden , Eric Rescorla , IPv6 List To: james woodyatt References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <75FB6A9A-1F04-497C-BE44-B05CFCFD395A@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:42:26 -0000 --Apple-Mail=_4E24D058-8B54-46ED-820A-543CFD0796F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 James, Thanks for the comments. Inline. Bob > On Apr 19, 2017, at 2:34 PM, james woodyatt wrote: >=20 > On Apr 19, 2017, at 13:55, Bob Hinden wrote: >>=20 >> The current and proposed new text is below. Please review and = comments. I hope to publish a new draft at the end of the week. >=20 > Bravo! Alas, I have a nit. Thanks, there are always =E2=80=9Cnits=E2=80=9D :-) >=20 >>> [...] These security issues include: >>>=20 >>> o Eavesdropping [...] >>> o Replay [...] >>> o Message insertion [...] >>> o Message modification [...] >>> o Man in the Middle attacks [...] >>> o Denial of Service Attacks [...] >>>=20 >>> IPv6 packets can be protected from eavesdropping, packet = modification, replay, and man in the middle attacks by use of [...] >=20 > p1. The order used to present the list of security issues should be = also be used to present the methods of protection. Will fix. >=20 > p2. The issue =E2=80=9Cmessage modification=E2=80=9D changes to = =E2=80=9Cpacket modification=E2=80=9D from one list to the next. I think = this should be clarified. Thanks, I will use =E2=80=9Cpacket=E2=80=9D, I think it fits the rest of = the document better. >=20 > p3. No further mention of =E2=80=9Cmessage insertion=E2=80=9D is made = after its appearance in the list of issues, even one similar to the = =E2=80=9Cdenial of service attack=E2=80=9D issue, to explain that no = defensive mechanism is defined, and it is left out of scope for this = specification. I will add that to the paragraph after the list. >=20 >=20 > --james woodyatt >=20 >=20 >=20 --Apple-Mail=_4E24D058-8B54-46ED-820A-543CFD0796F3 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+R0qAAoJEK7rdBF357uoUY4IAMByaoI5qmXzasDWnNKYUceI 0Y93lwLQJ5ucoWKRwfQjANWY/kJVvgZojVt0c6r8jut9Z9rTsFV3qap1SqeQXmzw Fle+YRTV1+RtenlB58MIE9/BHYlP6ewUrFaI2XsdaCD9KRzyI/cijjIxfdkWMJEo HoyUMeqEimS6wKx+eZGdXbeQsSvuz3jZ8cQ5PL/sZehJdGJQHXNlNdW3VgYa7Wqf AV8cp50HM5EkgHxdYfrCPLNAJvQzM3aE5s05SdU7xdr4dSD0O6h3rZD0JehYTUQ6 4V/Sbg9nUhEfQhgYMog9x7UFMw1ECcyrQ187ze9zAqABxnE8d8TeDumkWrtpPQs= =ozQs -----END PGP SIGNATURE----- --Apple-Mail=_4E24D058-8B54-46ED-820A-543CFD0796F3-- From nobody Thu Apr 20 13:44:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD4013167F for ; Thu, 20 Apr 2017 13:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 KRCw9i_g-O_O for ; Thu, 20 Apr 2017 13:44:24 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 6ADD013168D for ; Thu, 20 Apr 2017 13:44:23 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id o22so94669876iod.3 for ; Thu, 20 Apr 2017 13:44:23 -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=gz+LKpgIPGlL6T8Ky9SDtYpPk3LOLcMDUqsEHU3SjFM=; b=PG26MIUgXdHTEV3DKL8KLVOHX8Y35ObQ+akdIJVgvjze64+j/gT3AwYesG20uPsa5y TqT1R61bJz3kCz8EuhAa88sxSuu86wXGYz2yN9uY5XnPq54Sa3XGiGvbqtY6A2C/HAbr q5CzBxZN3CShclLFeRnanQrJ2fJCq+VO/fD33VOeWeNbFRZWOJQtxLcdhxGxAFvpi0le tVfEnw8MABXbsn9m8YJ7zmM9rToyRHCcimvbqHN2DYIDSSAXRPLWYfFg1qL7sKEoZpOW gYUHhm7s0M3EQlQ6c4gu21szOvl6f4n/y14OAYkWfuar9BM66cihf8+GiBpKwPeAMJyX LPZA== 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=gz+LKpgIPGlL6T8Ky9SDtYpPk3LOLcMDUqsEHU3SjFM=; b=SJgezpTFCtSs+P/rGlmsQZHk42I0RvlOkjmMnUGfzcwyFPXSre/ibt5z5dH2ZBO/CX Pq3P+L1A70QQZTQJbUVSZrJnR+flRspVKwnQm2w/LbJEJfse3JbNW1PKMLxMxk0P7X44 jBlc3BixROxVCwwEhOmmc96XlNH1d9BAqOyecANTixf4/7nugXFArErDf04QPwsGBD8Z iqz/NXrDYQDLJS9uczzFUVwqdBUCo5tNRmbYEeXeGs4TJEbt4TAw6+MQzn6xmNvLakWY 6jvvMjS5WPpA/Dksswht5/UI+xhzLu4fguQauHcMSQqZYqlsDICZwnqU0xomdaxWzDMK O+Fg== X-Gm-Message-State: AN3rC/6YFsBJ2XbIuRcvwWLLidJz6GVFz0UYalQoDEm9+mzggcGAixx4 IpMvmn0foM03Kg== X-Received: by 10.107.10.103 with SMTP id u100mr11159075ioi.76.1492721062439; Thu, 20 Apr 2017 13:44:22 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y139sm3169466ioy.50.2017.04.20.13.44.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 13:44:21 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4CDB7E71-0A93-4FDD-930A-975B627E771F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Revised and expanded rfc2460bis Security Considerations Date: Thu, 20 Apr 2017 13:44:20 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List , Eric Rescorla To: Fernando Gont References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:44:26 -0000 --Apple-Mail=_4CDB7E71-0A93-4FDD-930A-975B627E771F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando, Thanks for your comments. Comments in line. Bob > On Apr 20, 2017, at 6:11 AM, Fernando Gont = wrote: >=20 > Bob, >=20 > Thanks for sharing the text! Two quick comments: >=20 > On 04/19/2017 09:55 PM, Bob Hinden wrote: >> NEW >>=20 >> IPv6, from the viewpoint of the basic format and transmission of >> packets, has security properties that are similar to IPv4. These >> security issues include: >>=20 >> o Eavesdropping, On-path elements can observe the contents and >> metadata of each IPv6 datagram. >=20 > Not sure what metadata implies here -- an eavesdropper can actually = see > the wwhole content of the packet. >=20 I will update to what Ekr suggested, that is: "the whole packet = (including both contents and metadata)=E2=80=9D. >=20 >> o Denial of Service Attacks, where the attacker sends large >> amounts of legimate traffic to a destionation to overwhelm = it. >=20 > s/legimate/legitimate/ and s/destionation/destination/ >=20 >=20 I forgot to spell check before the last set of changes :-) >> IPv6 packets can be protected from eavesdropping, packet >> modification, replay, and man in the middle attacks by use of the >> "Security Architecture for the Internet Protocol" [RFC4301]. In >> addition, upper-layer protocols such as TLS or SSH can be used to >> protect the application layer traffic running on top of IPv6. >=20 > You may want to add references for TLS and SSH. I think both are well known, and are on the RFC Editors list of = keywords. >=20 >> IPv6 addresses are much larger than IPv4 address making it much >> harder to scan the address space across the Internet and even on a >> single network link (e.g., Local Area Network). >=20 > You may want to reference RFC7707, and maybe RFC7721 -- the larger > address space may not make address scans harder ... it all depends on > how the IIDs are generated/selected >=20 Adding RFC7721 seems reasonable. I note that with our move to non-MAC = based IIDs, it is much harder to scan than before. >=20 >>=20 >> IPv6 addresses of nodes are expected to be more visible on the >> Internet as compared with IPv4 since the use of address translation >> technology is reduced. This creates some additional privacy issues >> such as making it easier to distinguish endpoints. >=20 > Certainly you should ref RFC7721 here. >=20 OK >=20 >=20 >> The design of IPv6 extension headers architecture, while adding a = lot >> of flexibility, also creates new security challenges. As noted >> below, issues relating the fragment extension header have been >> resolved, but it's clear that for any new extension header designed >> in the future, the security implications need to be examined >> throughly, and this needs to include how the new extension header >> works with existing extension headers. >=20 > Some references here are warranted.. e.g. regarding the use of EHs to > circumvent security controls. >=20 I will add RFC7045. >=20 >>=20 >> This version of the IPv6 specification resolves a number of = security >> issues that were found with the previous version [RFC2460] of the >> IPv6 specification. These include: >>=20 >> o Revised the text to handle the case of fragments that are = whole >> datagrams (i.e., both the Fragment Offset field and the M = flag >> are zero). If received they should be processed as a >> reassembled packet. Any other fragments that match should be >> processed independently. The Fragment creation process was >> modified to not create whole datagram fragments (Fragment >> Offset field and the M flag are zero). >=20 > I'd reference RFC8021 here -- which elaborated on the topic, and also > describes specific attack vectors. RFC6946 made the update, so I think that is better. >=20 >=20 >>=20 >> o Changed the text to require that IPv6 nodes must not create >> overlapping fragments. Also, when reassembling an IPv6 >> datagram, if one or more its constituent fragments is >> determined to be an overlapping fragment, the entire datagram >> (and any constituent fragments) must be silently discarded. >> Includes clarification that no ICMP error message should be >> sent if overlapping fragments are received. >=20 > Here the same: reference the appropriate RFC (by Suresh, IIRC) RFC5722 >=20 >=20 >=20 >> 0 Revised the text to require that all headers through the = first >> Upper-Layer Header are in the first fragment. >=20 > May want to reference RFC7112 here. >=20 ACK >=20 >=20 >> o Removed the paragraph in Section 5 that required including a >> fragment header to outgoing packets if a ICMP Packet Too Big >> message reporting a Next-Hop MTU less than 1280. >=20 > Ref to RFC8021 here. ACK >=20 >=20 > Thanks! >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 --Apple-Mail=_4CDB7E71-0A93-4FDD-930A-975B627E771F 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+R2kAAoJEK7rdBF357uoKfIIAJQjRFX4WUztFJ7EAZ+0bjtv axUadta0DJVsWth5fN/HCCx3fCsQ/49pKUl1DPEQErIK95M81nRXXkLNBDx8iPZ3 QqZtDza20Sui0Gqay/DKmUGimZVB7EU4FQYMbLHgbfF3VB5oxF0XWuIYx1jdRTt6 qskRfCfiK6hCvpl1ll4OXbEgZM0T5iAsOicybJEairt07yPmU8pU0ifUwxJu5bVR XBo1zIvxjsK8boH+v0IwOguD+xOY9Cwsg/pzWdNKp0ydts95QTCT0qo8ksFZ6A0Q WcRX9Z1qnYu9VAEaKyp2Lv8zcJyjMDGnCBSZrb8cAL/ge40hx9XpVfI17GcCxp4= =rvRG -----END PGP SIGNATURE----- --Apple-Mail=_4CDB7E71-0A93-4FDD-930A-975B627E771F-- From nobody Thu Apr 20 14:21:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29512EAA7 for ; Thu, 20 Apr 2017 14:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 qDkXWQBEUEDs for ; Thu, 20 Apr 2017 14:21:30 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 05B0E13167E for ; Thu, 20 Apr 2017 14:21:27 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id o22so96207105iod.3 for ; Thu, 20 Apr 2017 14:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=RmfZIu4RRXzcMn/hykZRfkyGky8TyHN82fVUpL5k33c=; b=VP7n/k2bKYiPX1+4wKnkVsjGFdg+WItYQhgGBrhR2agg8exgElxOJNGRiqy03PKwHB n7F03fQT2zfAol8KJbNck5whRhn79zclWihlSI8fljX8gRTnKcW1XzBBCezuE1aYZvTf AtUgZYz1AF+bNWo0OXCv2q2hgUksRzDst5tHlUnd/9gqjsrcu3qvFG7Z739fC72qwPDK hsaIiKfrGqxHe0m+86VlxxRnT9wBWvAUXdFiYq1SC2Ik9MzxAAzMKsllcbTmS8am9G/Y gyPQCVKIMorIVnKyiT+Jp3NAKjiQEzObBcpOSizNnetD0boR2TUCcOq7XonQNNtpiGjy taWA== 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:date:cc:to; bh=RmfZIu4RRXzcMn/hykZRfkyGky8TyHN82fVUpL5k33c=; b=KTD+d91DPepW3oJ96MlSCoorqahoLjGC0J12x772TFEuV9bXW1npcxNqGqknOczPHQ 3xcWpD8ySFrqOoDq9KeeVmx7JeVUvDgnDWytT4/yBuungjBJ1wooZjUz70J/AcF0z7qG uJSo/eivF95p38pRzXS6Wd5Rk+w+rxqSaqlrU2TOu284mC0pIdBRrI45jobpba6gKFyz vSJajCtGjLxJNg5q7dUuWV1nugTn3R/fIb4DYnDREFqlvdzTPUI9f9bROHyhZyuzLNct l4MEcs3A2XRKMYraZdQ6KT2CJ+aJNOjKGZ8ddP2LqWuO/r+HShNdjJTmF63VCBC+3Ghn jpCw== X-Gm-Message-State: AN3rC/7ur4i3mUFqANqG+B+dVM1/PDmoNRAb4rzfoPjcCE5UaOJCywUn +ez/f2YBGnnM5A== X-Received: by 10.36.254.5 with SMTP id w5mr6590494ith.34.1492723286269; Thu, 20 Apr 2017 14:21:26 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y23sm214781ita.9.2017.04.20.14.21.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 14:21:25 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_AC6220E9-207C-4C6E-A45B-0068C6521EC3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Updated - Revised and expanded rfc2460bis Security Considerations Message-Id: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> Date: Thu, 20 Apr 2017 14:21:22 -0700 Cc: Bob Hinden , Eric Rescorla To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:21:33 -0000 --Apple-Mail=_AC6220E9-207C-4C6E-A45B-0068C6521EC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Based on the comments here is an updated Security Considerations = section. I think this resolves the issues raised in the email thread. Bob =E2=80=94=E2=80=94=E2=80=94=E2=80=94 10. Security Considerations OLD IPv6, from the viewpoint of the basic format and transmission of packets, has security properties similar to IPv4. Risks of corruption, forgery, and interception of packets, resulting in the exposure of private information, may be mitigated by use of the Security Architecture for the Internet Protocol [RFC4301] or encryption at higher layers of the protocol stack. NEW IPv6, from the viewpoint of the basic format and transmission of packets, has security properties that are similar to IPv4. These security issues include: o Eavesdropping, On-path elements can observe the whole packet (including both contents and metadata) of each IPv6 datagram. o Replay, where attacker records a sequence of packets off of the wire and plays them back to the party which originally received them. o Packet insertion, where the attacker forges a packet with some chosen set of properties and injects it into the network. o Packet deletion, where the attacker remove a packet from the wire. o Packet modification, where the attacker removes a packet from the wire, modifies it, and re-injects it into the network. o Man in the Middle attacks, where the attacker subverts the communication stream in order to pose as the sender to receiver and the receiver to the sender. o Denial of Service Attacks, where the attacker sends large amounts of legitimate traffic to a destination to overwhelm it. IPv6 packets can be protected from eavesdropping, replay, packet insertion, packet modification, and man in the middle attacks by use of the "Security Architecture for the Internet Protocol" [RFC4301]. In addition, upper-layer protocols such as TLS or SSH can be used to protect the application layer traffic running on top of IPv6. There is not any mechanism to protect against "denial of service attacks". Defending against these type of attacks is outside the scope of this specification. IPv6 addresses are significantly larger than IPv4 address making it much harder to scan the address space across the Internet and even on a single network link (e.g., Local Area Network). See [RFC7721] for more information. IPv6 addresses of nodes are expected to be more visible on the Internet as compared with IPv4 since the use of address translation technology is reduced. This creates some additional privacy issues such as making it easier to distinguish endpoints. See [RFC7721] for more information. The design of IPv6 extension headers architecture, while adding a lot of flexibility, also creates new security challenges. As noted below, issues relating the fragment extension header have been resolved, but it's clear that for any new extension header designed in the future, the security implications need to be examined throughly, and this needs to include how the new extension header works with existing extension headers. See [RFC7045] for more information. This version of the IPv6 specification resolves a number of security issues that were found with the previous version [RFC2460] of the IPv6 specification. These include: o Revised the text to handle the case of fragments that are whole datagrams (i.e., both the Fragment Offset field and the M flag are zero). If received they should be processed as a reassembled packet. Any other fragments that match should be processed independently. The Fragment creation process was modified to not create whole datagram fragments (Fragment Offset field and the M flag are zero). See [RFC6946] for more information. o Changed the text to require that IPv6 nodes must not create overlapping fragments. Also, when reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments) must be silently discarded. Includes clarification that no ICMP error message should be sent if overlapping fragments are received. See [RFC5722] for more information. 0 Revised the text to require that all headers through the first Upper-Layer Header are in the first fragment. See [RFC6946] for more information. o Removed the paragraph in Section 5 that required including a fragment header to outgoing packets if a ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. See [RFC7112] for more information. o Incorporated the updates from [RFC5095] and [RFC5871] to remove the description of the RH0 Routing Header, that the allocations guidelines for routing headers are specified in RFC5871, and removed RH0 Routing Header from the list of required extension headers. Security issues relating to other parts of IPv6 including addressing, ICMPv6, Path MTU Discovery, etc., are discussed in the appropriate specifications. --Apple-Mail=_AC6220E9-207C-4C6E-A45B-0068C6521EC3 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+SZTAAoJEK7rdBF357uoD8MH/2DM/JqMfLa803cc6PglAjlJ cd280+b1POvS7G43fX1PwZNUjxC8voTLJCp7jr8YuOvvc8pD3LFDyZMrcJCYp5/b PZqbeMQPX85/32gDh+0/INj9Jhw6rc4PIX9DqddGA2xYWIs/NWJQ/u5FGNdnjBx/ XhOB5csGgWG2aTwkypXiDSXcczCL+shwsMOpYGZP8IQs19EWi47JXvXYKz2zQOB9 XA90CZNqMPmQP95+cTwB0y0mcSmS4wQpUrxL9eeAyypIx1Z5H2gijMPrah7OiPx5 C9SQ55A7acR1PQtiFyD3Z4y5LwTeg4lBwoG8vbTCnnFobFfTsIoz+JFsZ6pBnnQ= =BtV9 -----END PGP SIGNATURE----- --Apple-Mail=_AC6220E9-207C-4C6E-A45B-0068C6521EC3-- From nobody Thu Apr 20 17:48:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3FE128B90; Thu, 20 Apr 2017 17:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 6vOmmkGvPJOJ; Thu, 20 Apr 2017 17:48:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 BD2D5128B4E; Thu, 20 Apr 2017 17:48:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id DBF1B24AE10; Fri, 21 Apr 2017 00:48:28 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 91D3116007E; Fri, 21 Apr 2017 00:48:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 74B6C160080; Fri, 21 Apr 2017 00:48:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NwrTKbx5APUR; Fri, 21 Apr 2017 00:48:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2320F16007E; Fri, 21 Apr 2017 00:48:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4AFCB6C59807; Fri, 21 Apr 2017 10:48:26 +1000 (AEST) To: otroan@employees.org Cc: Brian E Carpenter , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind \(IETF\)" , IESG , Fernando Gont , 6man-chairs@ietf.org From: Mark Andrews References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <819143C5-5CB7-41F5-94B2-CA40611FFED7@employees.org> Subject: Re: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= In-reply-to: Your message of "Thu, 20 Apr 2017 22:31:25 +0200." <819143C5-5CB7-41F5-94B2-CA40611FFED7@employees.org> Date: Fri, 21 Apr 2017 10:48:26 +1000 Message-Id: <20170421004826.4AFCB6C59807@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 00:48:36 -0000 We worry too much about the installed base. The installed base can always be fixed. It may take sometime but it can be done. You just have to be willing to deal with less than perfect for a while. A lot of this is just firewall setting. These can be changed. It just requires people to be willing to ask that changes be made. I've asked the US Military to fix their firewall settings because they were breaking legitimate DNS lookups. It took a month but the firewalls were fixed to allow the queries through. I've sent mail to Federal Ministers to get other firewalls in front of DNS servers fixed. It can be done. You just need to raise enough of a stink. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Apr 20 19:44:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1112940D; Thu, 20 Apr 2017 19:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 sdHzhTZTXT8W; Thu, 20 Apr 2017 19:43:54 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 32B431293FC; Thu, 20 Apr 2017 19:43:54 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id j59so26979432uad.0; Thu, 20 Apr 2017 19:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ZboL0j/mchREVtfwikKVwTlRBTmVj8GClXhSXdCYJDc=; b=irwLn1UZr/gq/QU3ivn/ulPIIzwun7EGfD6VYlzmBl437gNJ36f9WfokFs7SMmdfhC cdtDX4QwIk2KI/J/ToQIJ2rcWo3z/csQTNsrYhMtwC3BkXbVEPkbOzuDNHDgRdNii1E/ cQ004X+wVKTHtE9uLygSE6pZPIEQw6dbTCio81SsGrmnaR2j+FMIrv621gq5ae3icj5l oHreiN2UahbFhbGQb9LcpFRcZdbo6bDzlyhFq6333n/IqLazfW/YnsKIFGidxJhCSfVt kVA4rg/1spKK5awsmlmroRACQKlnLkWD4kdC/yUgdBImYEuhua7tLCKbtbOLRaCbBsWL dHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ZboL0j/mchREVtfwikKVwTlRBTmVj8GClXhSXdCYJDc=; b=VXRz4SP0denPi2PaSUgHDlTubcpxShbOh3kzYJhYIV+oIFFBdwz71CMMxWxAJKng0Q MjnITz4jslJJ+RFlA9DuP9kRklS0wq4V0yh0aFNqZDHvEY5bagQyhCgjCVY0ppJwrP6F bmNs7U8LZ0xDTu7F4WbBoUxbkzv1Sin+1cT3iT8T9lZIoyCd6uq6ZFtaEEjaBeq76SAo b2cQKq6RIRAOcXxqjESQd6ZpBlUHmYg62/R+RWEjzMsEBglSTntLzfA6aIc5b85BLS8g xPjk0yqp4oyGNCD5PheQgwFhM2XXvHoY6245IzjxDOXOGzNcjuU3bectctOlRJhDlCOj rWUA== X-Gm-Message-State: AN3rC/4K9seGjrmCrOL8w44P83wZPyEaCO2/G+f2qlueTZ6bEfaZyQxH l9eQX8tsZsBTohxED5h8AhUYD0/wQQ== X-Received: by 10.31.61.11 with SMTP id k11mr4800561vka.141.1492742632976; Thu, 20 Apr 2017 19:43:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.123.214 with HTTP; Thu, 20 Apr 2017 19:43:52 -0700 (PDT) From: Suresh Krishnan Date: Thu, 20 Apr 2017 22:43:52 -0400 Message-ID: Subject: =?UTF-8?Q?ECN_and_fragments_=28was_Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlewind=27?= =?UTF-8?Q?s_Discuss_on_draft=2Dietf=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_an?= =?UTF-8?Q?d_COMMENT=29=29?= To: "Mirja Kuehlewind (IETF)" Cc: Bob Hinden , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 02:43:56 -0000 Hi Mirja/all, Even though I like Bob's suggested text (with David's suggested change), I would like to suggest an alternate formulation that is generic (with ECN as an example) to see if it works. OLD: Only those headers in the Offset zero fragment packet are retained in the reassembled packet. NEW: Only those headers in the Offset zero fragment packet are retained in the reassembled packet. Other fields in the IPv6 header may also vary across the fragments being reassembled. Specifications that use these fields may provide alternate instructions if this basic mechanism of using the values from the Offset zero fragment is not sufficient. e.g. Section 5.3 of [RFC3168] describes how to combine the ECN bits from the different fragments to derive the ECN bits of the reassembled packet. I realize it is a bit verbose but I couldn't shorten it further. Thoughts/suggestions? Thanks Suresh On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF) wrote: > Hi, > > I really don=E2=80=99t like the term "Nodes that support Explicit Congest= ion Notification=E2=80=9C. I guess we understand something different under = =E2=80=9Esupport=E2=80=9C but maybe can just avoid that word to avoid any c= onfusion. > > Thanks, > Mirja > > >> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan : >> >> Hi Bob, >> >> On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: >> Mike, >> >> > On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: >> > >> > On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >> >> This text does not make any normative statement on the question if th= e >> >> behavior specified in RFC3168 should be implemented or not. It only s= ays >> >> please look at RFC3168 and make an informed decision if you want to c= onfirm >> >> to the behavior that is specified in RFC3168 in addition to implement= ing the >> >> spec in this document. However, yes, this statement is true for all I= Pv6 >> >> implementation. I don't see a problem here... >> > >> > Nor do I. As it happens I prefer the text proposed by Bob Hinden (with >> > David Black's modification) but I believe that the effect is essential= ly the >> > same as the text you proposed. So it seems that the discussion is boil= ing >> > down to editorial issues, and I am happy to leave that between you, >> > the shepherd, and the document editor. >> >> The current text I have is: >> >> Nodes that support Explicit Congestion Notification [RFC3168] >> use information in the Traffic Class field from all fragment >> packets to reconstruct the Traffic Class field in the >> reassembled packet. See Section 5.3 of RFC3168 for more >> information. >> >> >> This looks good to me as well. My only concern with the previous version= was that it sounded normative. >> >> Regards >> Suresh >> > From nobody Thu Apr 20 20:32:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDADB129467; Thu, 20 Apr 2017 20:32:31 -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, MIME_QP_LONG_LINE=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 yAkfhYHD3Zie; Thu, 20 Apr 2017 20:32:29 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 CA2BF129401; Thu, 20 Apr 2017 20:32:29 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id m34so6753306oik.2; Thu, 20 Apr 2017 20:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LE56A6l+ouyMsXvkVDE6hkDQlo7gtpxThwrT/Dj5oeA=; b=RapzBfz2PTwfXa5V/jAyZR8rtGa0f3yNI/Lhq1ntQBGSmOIBvS2aPllCgSVVCLqsU1 o4v2+uG3sy945aMTmc6AZHPrF4J8i8dgaHq8OlQqu7sd1q2VN4DfBeX88/t08rH7+zU5 HSpNzG5w3kwsmywNCz5CPdMhSHy69sgAIjLWTbeIvs8HGIhtHMyH308S9NvnY4a4tBKS Y2uR8I1LqhfNyy0FlGB6+DYzS2+JYpltFmSuROSqysZa7en1VnJ1imuqCj8TtBRgof7Z arSZTKoqugXiTK106RHgTC+14iyT0wi0D5nWl19Xel0WI4Wqwd3F4ibV9zvnCFHCXfdi SihQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LE56A6l+ouyMsXvkVDE6hkDQlo7gtpxThwrT/Dj5oeA=; b=iSaxKiS6GOjRWgKR3041KIKLE2L+GKaqql74NRQ9tuR47r3ljqVD212Piawtaotfvq EdKy/b3B2/HxP32uvZY3Ch3nOQBwNV0M8xFzZmCOq1z2uN4wCI5OaRWyWuP8SMwF2yz6 vy9OxNV0roZnbA6E/BDBD4QOHh0jxNB5bosXEEFHeovyCFx+RFfKEfyUjBaOGc98dPa2 5+A6u/CB+of/V8C6GLZ91T/cy9iKAqXZQQRzA+pFf4jGohNE7CvLriqNMsv/NCaEYLdd oaxlALsprA51fO2G/UwjoXOh5TpjJFVA7lpdBcswywrdI7R6ld6RHEnEvZfdQpoaFbPP zpYA== X-Gm-Message-State: AN3rC/52zs4BzfyNNpg1JLDk9YksntFCn9sahDYP3hGCLJ6023CgN2ig bnNYIqIIiJt7+Q== X-Received: by 10.84.222.12 with SMTP id w12mr13631605pls.115.1492745549129; Thu, 20 Apr 2017 20:32:29 -0700 (PDT) Received: from [192.168.1.32] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id p68sm12782541pfp.104.2017.04.20.20.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 20:32:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: =?utf-8?Q?Re:_ECN_and_fragments_=28was_Re:_[tsvwg]_Mirja_K=C3=BChl?= =?utf-8?Q?ewind's_Discuss_on_draft-ietf-6man-rfc2460bis-09:_=28wit?= =?utf-8?Q?h_DISCUSS_and_COMMENT=29=29?= From: Jeff Tantsura X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Thu, 20 Apr 2017 20:32:26 -0700 Cc: "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4E5E1E14-2AA8-485B-9ABD-9B3559A93835@gmail.com> References: To: Suresh Krishnan Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 03:32:32 -0000 Sounds good! Verbosity in this case a positive factor. Regards, Jeff > On Apr 20, 2017, at 19:43, Suresh Krishnan wro= te: >=20 > Hi Mirja/all, > Even though I like Bob's suggested text (with David's suggested > change), I would like to suggest an alternate formulation that is > generic (with ECN as an example) to see if it works. >=20 > OLD: > Only those headers in the Offset zero fragment packet are retained in= > the reassembled packet. >=20 > NEW: >=20 > Only those headers in the Offset zero fragment packet are retained in= > the reassembled packet. Other fields in the IPv6 header may also > vary across the fragments being reassembled. Specifications that > use these fields may provide alternate instructions if this basic > mechanism of using the values from the Offset zero fragment is not > sufficient. e.g. Section 5.3 of [RFC3168] describes how to combine > the ECN bits from the different fragments to derive the ECN bits of > the reassembled packet. >=20 > I realize it is a bit verbose but I couldn't shorten it further. > Thoughts/suggestions? >=20 > Thanks > Suresh >=20 > On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF) > wrote: >> Hi, >>=20 >> I really don=E2=80=99t like the term "Nodes that support Explicit Congest= ion Notification=E2=80=9C. I guess we understand something different under =E2= =80=9Esupport=E2=80=9C but maybe can just avoid that word to avoid any confu= sion. >>=20 >> Thanks, >> Mirja >>=20 >>=20 >>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan : >>>=20 >>> Hi Bob, >>>=20 >>> On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: >>> Mike, >>>=20 >>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: >>>>=20 >>>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >>>>> This text does not make any normative statement on the question if the= >>>>> behavior specified in RFC3168 should be implemented or not. It only sa= ys >>>>> please look at RFC3168 and make an informed decision if you want to co= nfirm >>>>> to the behavior that is specified in RFC3168 in addition to implementi= ng the >>>>> spec in this document. However, yes, this statement is true for all IP= v6 >>>>> implementation. I don't see a problem here... >>>>=20 >>>> Nor do I. As it happens I prefer the text proposed by Bob Hinden (with >>>> David Black's modification) but I believe that the effect is essentiall= y the >>>> same as the text you proposed. So it seems that the discussion is boili= ng >>>> down to editorial issues, and I am happy to leave that between you, >>>> the shepherd, and the document editor. >>>=20 >>> The current text I have is: >>>=20 >>> Nodes that support Explicit Congestion Notification [RFC3168] >>> use information in the Traffic Class field from all fragment >>> packets to reconstruct the Traffic Class field in the >>> reassembled packet. See Section 5.3 of RFC3168 for more >>> information. >>>=20 >>>=20 >>> This looks good to me as well. My only concern with the previous version= was that it sounded normative. >>>=20 >>> Regards >>> Suresh >>>=20 >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 21 01:16:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44734129440; Fri, 21 Apr 2017 01:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8N7iCYGyTJKq; Fri, 21 Apr 2017 01:16:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0982212948E; Fri, 21 Apr 2017 01:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3676; q=dns/txt; s=iport; t=1492762614; x=1493972214; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p+/Zsx0vljhwtoNIr87KOk/bAopxcxR0IM7SYX/zgnE=; b=bQGsX1kef1MRX6TtYKPBi9RWKRxpQdcT8zXC0T+cOGDcpX654DcqmKQa TNJYbR8CM9cUXWnph+E2WRwiyJVh/fhDcDrdBWJOzcBINmgqowvGiWHKV eBGSJ8e2iDgXFSVUywhvJC0vhw7e58QI0DBW7DiZ1mV8Px6qZatP4rrBn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQDfvvlY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFpiB6IYYRkgg8hC4V4AhqDaj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBIRE6CwULAgEIGAICJgICAh8GCxUFCwIEDgWKBAMNCA6qB?= =?us-ascii?q?IImhy0Ng2YBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUiCCIJuglGCBoMGLoI?= =?us-ascii?q?xBYk1k0Y7AY46hEmRVYsSiQMBHziBBWMVRBEBhFQcGYFKdYghgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="233811533" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2017 08:16:52 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3L8GqvW027204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2017 08:16:52 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Apr 2017 04:16:51 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Fri, 21 Apr 2017 04:16:51 -0400 From: "Stefano Previdi (sprevidi)" To: Bob Hinden CC: Fernando Gont , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?6man-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFu?= =?utf-8?Q?-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHSufrl72cja1EPJ0OqdlvmgyQvnaHPvlyA Date: Fri, 21 Apr 2017 08:16:51 +0000 Message-ID: <3ECC35A3-351F-42FA-9A1E-FFC3D00EAAFD@cisco.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <6532A4A6-D168-4E9A-A6E6-205E8D965A67@cisco.com> <64E307CB-A01D-4BDA-A369-289E1BD5C43A@gmail.com> In-Reply-To: <64E307CB-A01D-4BDA-A369-289E1BD5C43A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.81.87] Content-Type: text/plain; charset="utf-8" Content-ID: <1788F8AE3932644BA5F72A1D996BE208@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:16:57 -0000 DQo+IE9uIEFwciAyMCwgMjAxNywgYXQgNzoyMyBQTSwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBn bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gU3RlZmFubywNCj4gDQo+PiBPbiBBcHIgMjAsIDIwMTcs IGF0IDEwOjA5IEFNLCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSA8c3ByZXZpZGlAY2lzY28u Y29tPiB3cm90ZToNCj4+IA0KPj4gDQo+Pj4gT24gQXByIDIwLCAyMDE3LCBhdCA1OjQ3IFBNLCBC b2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gRmVybmFu ZG8sDQo+Pj4gDQo+Pj4+IE9uIEFwciAyMCwgMjAxNywgYXQgNjowMSBBTSwgRmVybmFuZG8gR29u dCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiDigKYuDQo+Pj4+ PiANCj4+Pj4+IERyb3BwaW5nIHVua25vd24gZXh0ZW5zaW9uIGhlYWRlcnMgaW4gdHJhbnNpdCBu ZXR3b3JrcyBpcyByZWxhdGl2ZWx5DQo+Pj4+PiByYXJlLiBXaXRoIHRoZSBIQkggYmVpbmcgYW4g ZXhjZXB0aW9uLCB3aXRoIGFsbW9zdCBhIDQwJSBkcm9wLiAoTm90ZQ0KPj4+Pj4gdGhhdCB0aGVy ZSBhcmUgbm8gSEJIIG9wdGlvbiB0aGF0IHdvdWxkIG1ha2UgYSBsb3Qgb2Ygc2Vuc2UgYWNyb3Nz DQo+Pj4+PiB0aGUgSW50ZXJuZXQsIHNvIGFnYWluIGNoaWNrZW4gYW5kIGVnZy4pDQo+Pj4+IA0K Pj4+PiBCYXNlZCBvbiBSRkM3ODcyICgiT2JzZXJ2YXRpb25zIG9uIHRoZSBEcm9wcGluZyBvZiBQ YWNrZXRzIHdpdGggSVB2Ng0KPj4+PiBFeHRlbnNpb24gSGVhZGVycyBpbiB0aGUgUmVhbCBXb3Js ZCIpLCB5b3VyIHN0YXRlbWVudCBpcyBpbmNvcnJlY3QuDQo+Pj4+IA0KPj4+PiBUcmFuc2l0IHJv dXRlcnMgZG8gZmlsdGVyIHBhY2tldHMgd2l0aCBFSHMsIHdoZXRoZXIga25vd24gb3IgdW5rbm93 bi4NCj4+PiANCj4+PiBJIHRoaW5rIHRoaXMgY29uZmlybXMgdGhhdCB0aGUgY3VycmVudCB0ZXh0 IHdoaWNoIHJlY29tbWVuZHMgYWdhaW5zdCBkZWZpbmluZyBuZXcgRUggaXMgY29ycmVjdC4NCj4+ IA0KPj4gDQo+PiBXZWxsLCBpbiBmYWN0IEkgYmVsaWV2ZSBpdOKAmXMgdGhlIGV4YWN0IG9wcG9z aXRlLg0KPj4gDQo+PiBEZWZpbml0aW9uIG9mIG5ldyBFSHMgbXVzdCBiZSBkb25lIGNhcmVmdWxs eSBidXQgSSBkb27igJl0IHNlZSB3aHkgaXQgc2hvdWxkIGJlIHByZXZlbnRlZCwga25vd2luZyBh bHNvIHRoYXQgdHJhbnNpdCByb3V0ZXJzIHdvdWxkIGFueXdheSBmaWx0ZXIgRUgtcGFja2V0cyBv dXQgKGhlbmNlIG1pdGlnYXRlIHRoZSBpbXBhY3Qgb2YgbmV3IEVIcyBpbnRyb2R1Y3Rpb24pLg0K PiANCj4gVGhlIGN1cnJlbnQgdGV4dCBpczoNCj4gDQo+ICAgRGVmaW5pbmcgbmV3IElQdjYgZXh0 ZW5zaW9uIGhlYWRlcnMgaXMgbm90IHJlY29tbWVuZGVkLiAgVGhlcmUgaGFzIHRvDQo+ICAgYmUg YSB2ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gd2h5IGFueSBuZXcgZXh0ZW5zaW9uIGhlYWRlciBp cyBuZWVkZWQNCj4gICBiZWZvcmUgaXQgaXMgc3RhbmRhcmRpemVkLiAgSW5zdGVhZCBvZiBkZWZp bmluZyBuZXcgRXh0ZW5zaW9uDQo+ICAgSGVhZGVycywgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0 aGUgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgaXMNCj4gICB1c2VkIHRvIGNhcnJ5IG9wdGlv bmFsIGluZm9ybWF0aW9uIHRoYXQgbXVzdCBiZSBleGFtaW5lZCBvbmx5IGJ5IGENCj4gICBwYWNr ZXQncyBkZXN0aW5hdGlvbiBub2RlKHMpLCBiZWNhdXNlIHRoZXkgcHJvdmlkZSBiZXR0ZXIgaGFu ZGxpbmcNCj4gICBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCj4gDQo+IEZvbGxvd2luZyB0 aGlzIHRleHQgaXMgdGhlIHJlY29tbWVuZGVkIGZvcm1hdCBmb3IgbmV3IGV4dGVuc2lvbiBoZWFk ZXJzIGlmIHRoZXkgYXJlIGRlZmluZWQuDQo+IA0KPiBJIHRoaW5rIGlzIGlubGluZSB3aXRoIHdo YXQgeW91IHNhaWQsIHRoYXQgaXMg4oCcZG9uZSBjYXJlZnVsbHnigJ0gYW5kIG5vdCBwcmV2ZW50 ZWQuDQoNCg0Kd2VsbCwgdGhlIHRleHQgc3RhcnRzIHdpdGgg4oCcRGVmaW5pbmcgbmV3IElQdjYg ZXh0ZW5zaW9uIGhlYWRlcnMgaXMgbm90IHJlY29tbWVuZGVkLuKAnSB3aGljaCBpcywgdG8gbWUs IGEgY2xlYXIgaW50ZW50aW9uIHRvIGNsb3NlIHRoZSBkb29yLg0KDQpBbnl3YXksIGl04oCZcyBq dXN0IG9uZSBtb3JlIGlzc3VlIG9uIHRoZSBsaXN0IHRoYXQgdGhpcyBkb2N1bWVudCBoYXMuDQoN CnMuDQoNCg0KDQo+IA0KPiBCb2INCj4gDQo+IA0KPj4gDQo+PiBFSCBpcyBwcm9iYWJseSBfdGhl XyBtb3N0IGlubm92YXRpdmUgYW5kIHBvd2VyZnVsIGZlYXR1cmUgb2YgaXB2Ni4NCj4+IA0KPj4g cy4NCj4+IA0KPj4gDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IEJvYg0KPj4+IA0KPj4+IA0KPj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ Pj4gaXB2NkBpZXRmLm9yZw0KPj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+ IA0KDQo= From nobody Fri Apr 21 01:22:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC677126CC7; Fri, 21 Apr 2017 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Vj-R8PGT1uFv; Fri, 21 Apr 2017 01:21:58 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72321288B8; Fri, 21 Apr 2017 01:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2974; q=dns/txt; s=iport; t=1492762917; x=1493972517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MGisOvW+y3K6+VnpyExIp40CW7NIPdoEC2K1dK5tpBE=; b=kFNaTzora3sE2G9pwkv44XtxFJuYF+TnotofEnBE4sYI0Obg+fpb/goN XsELPYnH69P85sLZuIpGLN3NX6+b1rl1t+lx6Chpn8ywzEyZnEbO0Xty4 poKUORGL7z5VnCTdKhY+OA4EM6U/h4agBk1R7/uw9TnEWWo12FjoC1DSX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQDYwPlY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFIIYgeiGGEZIIPIQuFeAIag2o/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBASEROgsFCwIBCBgCAiYCAgIfBgsVBQsCBA4FigQDDQgOq?= =?us-ascii?q?geCJoctDYNmAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VIgV0rC4JjglGCBhe?= =?us-ascii?q?Cby6CMQWJNZNGOwGOOoRJkVWLEokDAR84gQVjFUQRAYUJgUp1AYgggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="415518045" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2017 08:21:34 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3L8LYbe006403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2017 08:21:34 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Apr 2017 04:21:33 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Fri, 21 Apr 2017 04:21:33 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter CC: Bob Hinden , Fernando Gont , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?6man-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi02bWFu?= =?utf-8?Q?-rfc2460bis-09:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHSunhJ72cja1EPJ0OqdlvmgyQvnQ== Date: Fri, 21 Apr 2017 08:21:33 +0000 Message-ID: <53D314DF-2C83-4837-A9D2-AB776231BADC@cisco.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.81.87] Content-Type: text/plain; charset="utf-8" Content-ID: <3762ADBBD74080419B64BC0241AD6974@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 08:22:00 -0000 DQo+IE9uIEFwciAyMCwgMjAxNywgYXQgMTA6MjIgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMjEvMDQvMjAxNyAwMzo0 NywgQm9iIEhpbmRlbiB3cm90ZToNCj4+IEZlcm5hbmRvLA0KPj4gDQo+Pj4gT24gQXByIDIwLCAy MDE3LCBhdCA2OjAxIEFNLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+IHdy b3RlOg0KPj4+IA0KPj4+PiDigKYuDQo+Pj4+IA0KPj4+PiBEcm9wcGluZyB1bmtub3duIGV4dGVu c2lvbiBoZWFkZXJzIGluIHRyYW5zaXQgbmV0d29ya3MgaXMgcmVsYXRpdmVseQ0KPj4+PiByYXJl LiBXaXRoIHRoZSBIQkggYmVpbmcgYW4gZXhjZXB0aW9uLCB3aXRoIGFsbW9zdCBhIDQwJSBkcm9w LiAoTm90ZQ0KPj4+PiB0aGF0IHRoZXJlIGFyZSBubyBIQkggb3B0aW9uIHRoYXQgd291bGQgbWFr ZSBhIGxvdCBvZiBzZW5zZSBhY3Jvc3MNCj4+Pj4gdGhlIEludGVybmV0LCBzbyBhZ2FpbiBjaGlj a2VuIGFuZCBlZ2cuKQ0KPj4+IA0KPj4+IEJhc2VkIG9uIFJGQzc4NzIgKCJPYnNlcnZhdGlvbnMg b24gdGhlIERyb3BwaW5nIG9mIFBhY2tldHMgd2l0aCBJUHY2DQo+Pj4gRXh0ZW5zaW9uIEhlYWRl cnMgaW4gdGhlIFJlYWwgV29ybGQiKSwgeW91ciBzdGF0ZW1lbnQgaXMgaW5jb3JyZWN0Lg0KPj4+ IA0KPj4+IFRyYW5zaXQgcm91dGVycyBkbyBmaWx0ZXIgcGFja2V0cyB3aXRoIEVIcywgd2hldGhl ciBrbm93biBvciB1bmtub3duLg0KPj4gDQo+PiBJIHRoaW5rIHRoaXMgY29uZmlybXMgdGhhdCB0 aGUgY3VycmVudCB0ZXh0IHdoaWNoIHJlY29tbWVuZHMgYWdhaW5zdCBkZWZpbmluZyBuZXcgRUgg aXMgY29ycmVjdC4NCj4gDQo+IEhhdGUgdG8gc2F5IGl0LCBidXQgeWVzLCBJTUhPIHRoYXQgd2Fz IGEgY2xlYXIgV0cgY29uc2Vuc3VzIGFuZCBJIGRvbid0IHRoaW5rDQo+IHRoZSBJRVNHIGhhcyB0 aGUgcmlnaHQgdG8gb3ZlcnJpZGUgaXQuDQoNCg0Kd2VsbCwgdGhlcmXigJlzIGJlZW4gYW5vdGhl ciBXRyBjb25zZW5zdXMgdGhhdCBoYXMgYmVlbiBvdmVycmlkZGVuIGJ5IElFU0cgc28gd2hhdOKA mXMgdGhlIGFsZ29yaXRobSBleGFjdGx5ID8NCg0Kcy4NCg0KDQo+IA0KPiBPbiAyMS8wNC8yMDE3 IDA1OjA5LCBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSB3cm90ZToNCj4gLi4uDQo+PiBEZWZp bml0aW9uIG9mIG5ldyBFSHMgbXVzdCBiZSBkb25lIGNhcmVmdWxseSBidXQgSSBkb27igJl0IHNl ZSB3aHkgaXQgc2hvdWxkIGJlIHByZXZlbnRlZCwNCj4gDQo+IHdoaWNoIGlzIGV4YWN0bHkgd2h5 IHRoZSBjb25zZW5zdXMgaXMgKm5vdCByZWNvbW1lbmRlZCogcmF0aGVyIHRoYW4gKm11c3Qgbm90 Ki4NCj4gRXZlbiB3aXRob3V0IGZvcm1hbGx5IHVzaW5nIFJGQzIxMTksIHRoZSBkaXN0aW5jdGlv biBpcyBjbGVhci4NCj4gDQo+IFdoeSBhcmUgd2UgcmUtbGl0aWdhdGluZyB0aGlzPw0KPiANCj4g T24gMjEvMDQvMjAxNyAwNjo1NCwgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+IC4uLg0K Pj4gSSBkbyBub3QgdGhpbmsgYSBkcm9wIHJhdGUgaW4gdGhlIGFyZWEgb2YgMi41JSB3YXJyYW50 czoNCj4+ICJ0b2RheSdzIHJvdXRlcnMgYXJlIGhpZ2hseSBsaWtlbHkgdG8gZHJvcCBwYWNrZXRz IHdpdGggdW5rbm93biBoZWFkZXJzIi4NCj4gDQo+IFRoYXQncyBiZXNpZGUgdGhlIHBvaW50IGZv ciAyNDYwYmlzLiBUaGUgcG9pbnQgaXMgdGhhdCB1bmtub3duIEVIcyBhcmUgZHJvcHBlZA0KPiBv biAqc29tZSogcGF0aHMsIHdoaWNoIG1ha2VzIGRlcGxveWluZyB0aGVtIHRyaWNreSwgcmVnYXJk bGVzcyBvZiB0aGUgcGVyY2VudGFnZS4NCj4gDQo+ICAgIEJyaWFuDQo+IA0KPiANCj4gDQo+IA0K PiAgICBCcmlhbg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQo= From nobody Fri Apr 21 04:26:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402771270A0 for ; Fri, 21 Apr 2017 04:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-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=btconnect.onmicrosoft.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 0Pkc__DvzL5p for ; Fri, 21 Apr 2017 04:26:27 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0123.outbound.protection.outlook.com [104.47.0.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66574126DEE for ; Fri, 21 Apr 2017 04:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rjiBBVNeDGYidydS5gLuXpShL1JvkpZ7BZ7DTNIrJUw=; b=Vw6C4+k7JzE5cvXv1Lcu05Xzp0WTY8ZDbghPD5qinQfkSZnYUAq5jSiwOBGgPIoQyk5V3OAsMkSwsyql3a7TIs3L82iM8jqaRSPP1AYOBYu/GVgRgAB1J88VE8uVcq/Ci4h+cO4hMhduvteZBB9Uv+ue2DDaKkxHsCvUj846vRM= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 11:26:23 +0000 Message-ID: <01df01d2ba91$c9db9180$4001a8c0@gateway.2wire.net> From: t.petch To: Bob Hinden , IPv6 List References: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> Subject: Re: Updated - Revised and expanded rfc2460bis Security Considerations Date: Fri, 21 Apr 2017 12:23:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6PR0501CA0032.eurprd05.prod.outlook.com (10.168.78.146) To VI1PR0701MB3006.eurprd07.prod.outlook.com (10.173.72.148) X-MS-Office365-Filtering-Correlation-Id: 232c79c6-2f8f-41fe-c832-08d488a93dcd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:whjgwpO3TqP0ILNvfj9lTk4ClWp2JdFSMjRhG90bCMtOvLa+Rgm1dpV78bA/H7MgFg0Z+gm9GqS5vlfO64bwbowK/hr8WnMSJIKI60Z8sK1yEr4xcee6cbGfiYp+CrMi44MucPEAFYmf6BWh+C3SDCTO5+DmjlRQM7aP0Ka647dvbMpJdINurmqtI3xBWtHjdIh4RrrWYZkUR939IzHI6Quck1YsYQhLPUK8YUelEwjghw2HTA8xEMa7bS0FGU6Daf4kR1w/aTN2pVKfptjmXYFMtTrIKDMqnwl/OLsN2vMyfI9Q4sj9nb1uFXiau8O2TN8bPX20fdToETJ38Z5lyA==; 25:p4lNbEnILB26VOowY0dw7q78QxYKY8vZAlD1ON8YHWS8kSwW48k6XKKxugKUIBSNpdxfWjg0I9nXa6vtkS3vhXjcJcDlI6TfHVSbm7hG+I6+3VAMdCuLZCVzW06IAp16F/MGx9abxVZnvKxgu+ZPb1ZFdNtbMini3m2E4PbywRLIfjbxZGl80X7Xg6mMY0ddHfqYVpA5f5YMJItNsBsVLQmH9D00TIWBl1iYfmtaUPXl5Ou90w2vWx9WYqyurcC7P3FpEPnp0zn0uHY0Ifnn5uJAH6GWSgAXWTJB/HyMa4J+UY2HTQkXnINUt627/1DmVYhmrEo5uNvFxaacIypIrU7IvTO1RAAcidNOiiRI1es0sIADmdh2Et1E0PVKVLG7UQtpYu/Lm0YOl5ShRaKVhzFVRasvvOC7KMt6rOIvmB8AatC85xtvP/A/2loCAJZZMDsJfiluWfSVwMxPp6HxiVrqmfcXcH5Kw8cWLuLV8yw= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 31:m+muBLcOF2IDJCdz6YExbbxkSPj+WfNt9iOMgxsF0olI8NGIAyAOvzR+2BQkYo671ZsRl9dCSaE2Gkyuf7x6JyYEbcoUR9APgC+/DfVFNw0hc5TchKcflEWGT+j+EPcMMFORcClH79ZxrzWIOISRpU92rKvB+VdaSjJkuJjhkv2j9XVxaKqrBW7R+2pIKLJ7rxfWFX9hxCo5cS8Bae4Ber9qUeaTzxTONrKCLj3+VANjrOZ5+6Dywg9UfN1HHlju X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201703061421075)(201703161042150)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148)(6042181); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:rY1Em271TAd8d/hcBGXWVms01zkRsDoBq4ljcqqjcZpUqTNX5xN/UAkneXXWKBluzd7rZV6ca0sE+3LoiLLoIG5Xg2AUahC15iQIKI6CUCKd6cWUrwnInUMrcsbSHMwg4TQW5kljRH04RKTCbl5ZsYkg/PhVCkbkd1mjqi7VGT+i0/iB0wDuslO20nunFc4G5Z1FEKz3m9gGnzNfz/prXNYWFphFoiwMFP4HIhe5oU6azuP6SCgHCra9IkqFtJGad48iQUKqvFbMvaT7++Xq6+2zen3T+25OO+bu74JA6Oao+3dhwaW0Figg4P6oti5v6SPCDJuCK7Rx14Hg4a358QJxti73VY3QYUEgBt93KawX+mhgfjH1ccaleY8MTXPhMPnDJFhhzFhtejnwoJHKbDB39IlH4l98eBtqMT1IwKVI4LaSFnPnHPQw40DZiZp+q5nM+fkIq3GFxUSwHklwFn5+CRIdvTbkkQlKq7PiwFghaPhBkWXECJxB+REjYb0WR35/AxhKRc4OylUB5KXoMJvwLsLpDBcMHNvz/G7omdnYSFAxJOw7jHaBIRgUfTlicaYWVzzygKdZSzGn7xfGIch0benW8kZYLysfV069WMBPcmmsR1QYmuA7QuKrrLWa9m2YQBbJlT3fJaN2Ne14ix1aiKmgGbvCJuCfMyKYN5NDpGL0jAyDv31GI9sQCmrlh3yHdFDFTGSrN4ygCNabwbyeAEf5D8eHOjlXmmsB3SZJu8dH9QLy1nrji+mfjBy2ByINcueBCckxwgGe6G3aIg== X-Forefront-PRVS: 02843AA9E0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(230700001)(50466002)(81816999)(9686003)(38730400002)(25786009)(6496005)(4720700003)(33646002)(3846002)(6306002)(7736002)(6116002)(6666003)(76176999)(305945005)(53936002)(81686999)(50986999)(6246003)(229853002)(5660300001)(42186005)(14496001)(44736005)(6486002)(47776003)(84392002)(66066001)(62236002)(2906002)(86362001)(8676002)(15650500001)(81166006)(23676002)(189998001)(61296003)(50226002)(44716002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDY7MjM6ME5hTEF6c0ZFR2VSZEpnZUpNRnJmTzNH?= =?utf-8?B?aUhWYzFNZk5FbytKZ0EzdUI1VlpVeEVCakZBQ3pPdEh2cU1KNkVOQ3kzWTRY?= =?utf-8?B?UklnMTR0ZVcvUFRXODQvVE5EOW5rMTZEZ0V5aG12TmFxSU14VVNzZ1RJL2ZI?= =?utf-8?B?c1dOcEVoZysrQm0xdWNjdzNsTkRtekpIbnViZUtsK3hodksyZG5WQkpUVXEy?= =?utf-8?B?UktndGdTNk52SXdWMHRCQTRKK0F1Wnl4WGx6cVRmWFp2dGI1WFJnUVEvSVZa?= =?utf-8?B?UktxNk8xb0swdXdQb1RVZnVhZnlOYVdwdTlScnBwS1d1cE9YUGsvWC9lRFNV?= =?utf-8?B?cS80QjNnV3hCSHZ6UkZWY2l5eHREaXFjYWhraWdCOVB2NFcva2VKYmFDSyto?= =?utf-8?B?dmFxeXNrUVpXQTMrQkFEOTJtQlpNWmpTR015Y05zbm11eUR1QmFuTXUydGh6?= =?utf-8?B?VHJDbU8rdU14aDloLzI3ZE03bVZlckR5SnQwSnVFajdiNkdDQVV2WldKS0NS?= =?utf-8?B?MU5SczRCdXFJT0VuZzZqUjA2RmRNRXBlVGtSRmx0M2ZiS1kxbXMzZmVWMTRS?= =?utf-8?B?Z3djeXlHcW42RVdXVmdvZCtDNnA0clV5UGFSVWFZdmRhV25PbllwV2MxVko2?= =?utf-8?B?Zm8xeTZQaG9JSTNhR3Z4WWN5aFJoODhkMTZsd2xQYkJOdlFITE9sYXJrczEv?= =?utf-8?B?WXV4NUJ3OUJxUVl5V2wycjFHdkNHS2JLYkF4SHdSWERUZTJITXc4eGE1WTUv?= =?utf-8?B?UEJWU1F3WkR6WUhBdkpOdTVPcC90QnpQUE1mTXYwQ3MwbFFoSHV5bElkSHpG?= =?utf-8?B?dGZJUXc0em5ySHREdXYrTVNrd2xMVDBURElrMGplOGwzbkNnbmRnTzRxajdm?= =?utf-8?B?dS9BdVVMR2g1S2RGOHJOeG1KWGJXOFlpMkVtUGU4VmVxZkJEd3RnWGJJcGRO?= =?utf-8?B?a1JtNk91TWhmZWJDc3hEbTBUWEZRNFl4QWl4N2pzZ0o2bkgvQ3V0OUFhcWIy?= =?utf-8?B?ZjdBSG52aStCZm9nODd1UkwzbXQ2eHlCSERFZlZtaEVOTkZkTVZ2a2MySjVy?= =?utf-8?B?RzMrUlgzTTcyckV2cllRdzZyRzdFRU56bzJpa1Z6MkJ3SXA5NXF4SmxML0ox?= =?utf-8?B?UzNoRnMxbTluYTl6QWk5Y21EcGJuWVhRTys2MzA0Q256ekpDenhUQTZ1K3lu?= =?utf-8?B?OXFreHJ5cHJlMnJhWlZwNERxdGVaYUFDTmxRK29UWE9kUzlSVXUxbmhkK21H?= =?utf-8?B?bS9sRWVKeDEvUXAzcU5xakhkRzRWL0FBZ1VKMWFKcFMrVDd3NDZUQi9uNk5m?= =?utf-8?B?QVRyWXJXU1hGU2VRUEdiblQyM1FIQ3ZjaE9hRzRueE9YK2lTNUthK1VyMkVR?= =?utf-8?B?WFd4cUhidEYxUjFkMEFxOUc2ZmFGM0wwayswbkt3NGQ3eWhKNkp3STQ2Vk5P?= =?utf-8?Q?dOUtaqUZuSeK75U0qZqgZAPndO+sT?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:yJlrl6wnSTGS9JOJtRcVDIB9FQUTOVirtZ7W9n+ZDnE4e+26M60PFgPharEJjfLnbCMK8rYZN+MXp0oMW7dXa2g2BrbrWTBsnSvhKEMgTL/9pcOwde+nN7lw5vrc3StgnRLb+hsAlLSpE8W5jCs2kAyzpAc9o8rL7fuTHwi2Juy2h0++oiJlY0UFFIz8eLHvZf5wsGnboRcvsNEdfghGCqJoKiQoOu+e0y1a2kEv+6ed361ol2QpDYoqUqWD8++/l2SPvloqQ8n4CohAX8CT3dblgwH6wawjELWFQ+wfpLVmjQHvOvLhYSRNZpvFk6IJP1EntoyaZIABDxemV+UcxczWWQfb2vXh2wPQmxZC3u41RDKDSH+iEKzYOVdSJnKy7qlgdQSqemRUg/Vc4MFSNE8e01Ux0J6Id/QbEy4ney1KiDo+aU3PUbsyNncVWzM6ZfMhlBS5tiefuWiUfrnXUDV+gyysSMJQ2xNFAom3cFzs8S3SKtutttcdVjlf4MhhYh2f7qRmuPtEJ2PSsvjM4g==; 5:IIQT6BhoWhh4ZiwY0JfrZ3CqOdghm6OcCGBXdOD9QfasAG33mm4w7MRv2jvcab8mVaZrhqMuMMLpBoxH3ucUSEA6C5nInhrvsnRaussV2OVNUeQqeNjjmMycfZh6yH0L4N3y0/QF0ySKFr/FzotoFg==; 24:vnlNPJ5sL2EzZRHQP/70p8PIkTreZWSMTe0dlCUt7FEA3eCm/bWP0wG3ylzyGxUlplJFxFDMFaEEYBQ0pbwCAtB+bzuWLGIl8KMWjMtEZ8U= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 7:p4A/lmBbyJQ8CEM8oX5uEnC6DuS1Up/rh7MtXlTssvnDCZFAs2vlcSQbqAne75tRaZIpKVNorNTv+cNI20rX6IaYFkB2u/SxYwid4/EqVoWMuczhOnHrmkCebQTC711eK2flvuoYBQ+Ft9eEfCMnwoSTqrouvKjOuc5f0YzEONdAOmfJvsiDx9Ep6LMaFROhg52mQ3ta6tQ5qVAD+NVTp7ymgmuOzVbPp8xbzXMIjqAIUwMsT8alR+hajrP2XKgflgbWYNcYryfVEsetVGMKvayMhee5hLB9qpxc6D6YGQBme5ao28v8Any99vzu5BDJJ5IrqgfJF5Z8yRFoAMYAdw== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2017 11:26:23.0326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 11:26:29 -0000 Bob Kathleen raised a DISCUSS on the security considerations and since you have changed the subject line, she may not see this thread. I suggest adding her to the distribution list to see if she agrees at this stage (as opposed to being surprised later) Tom Petch ----- Original Message ----- From: "Bob Hinden" To: "IPv6 List" Cc: "Eric Rescorla" ; "Bob Hinden" Sent: Thursday, April 20, 2017 10:21 PM Subject: Updated - Revised and expanded rfc2460bis Security Considerations > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Apr 21 05:15:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58812948A; Fri, 21 Apr 2017 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nPI7gndpC3Br; Fri, 21 Apr 2017 05:15:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F98212704A; Fri, 21 Apr 2017 05:15:27 -0700 (PDT) Received: from [192.168.1.173] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 178A880763; Fri, 21 Apr 2017 14:15:24 +0200 (CEST) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: Bob Hinden References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Cc: =?UTF-8?Q?Ole_Tr=c3=b8an?= , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Suresh Krishnan , IESG , 6man-chairs@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 21 Apr 2017 12:24:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:15:29 -0000 On 04/20/2017 04:47 PM, Bob Hinden wrote: > Fernando, > >> On Apr 20, 2017, at 6:01 AM, Fernando Gont wrote: >> >>> …. >>> >>> Dropping unknown extension headers in transit networks is relatively >>> rare. With the HBH being an exception, with almost a 40% drop. (Note >>> that there are no HBH option that would make a lot of sense across >>> the Internet, so again chicken and egg.) >> >> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6 >> Extension Headers in the Real World"), your statement is incorrect. >> >> Transit routers do filter packets with EHs, whether known or unknown. > > I think this confirms that the current text which recommends against defining new EH is correct. Yes. Our best possible outcome is that we get *existing* EHs to *not* be filtered. I think it's *extremely* unlikely that one could get new EHs to work. So I fully support recommending against the definition of new EHs. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 21 05:15:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAA6129A9C; Fri, 21 Apr 2017 05:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 aA77TflCkK1T; Fri, 21 Apr 2017 05:15:28 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E9F129452; Fri, 21 Apr 2017 05:15:28 -0700 (PDT) Received: from [192.168.1.173] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E25AF809B2; Fri, 21 Apr 2017 14:15:25 +0200 (CEST) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: otroan@employees.org References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> Cc: Suresh Krishnan , 6man-chairs@ietf.org, 6man WG , Jeff Tantsura , IESG , "Mirja Kuehlewind (IETF)" , draft-ietf-6man-rfc2460bis@ietf.org, Bob Hinden From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7eead764-1267-e2f0-7768-9a690f666c67@si6networks.com> Date: Fri, 21 Apr 2017 12:59:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:15:30 -0000 Ole, On 04/20/2017 07:54 PM, otroan@employees.org wrote: > Fernando, > >> RFC7872 was a while document. It followed the normal publication >> process, and we did do our best to address which comments. If this >> was published as it was, is because we didn't find a better way to >> convey the info. So I'm not sure what your speculation is about, >> but this is not the first time that I see see trying to find >> obscure reasons, when in fact there aren't any. >> >> As a datapoints, I started measuring EH drops because there was a >> lot of talk about the topic, but no data. I spent quite a lot of >> time on tools and measurements, assuming that the numbers would be >> better -- but they just were not (without double-checking your >> math, a 2.5% drop rate by intermediate Asses is still quite bad. >> And in fact, such numbers could actually be worse (read RFC7872 for >> the rationale)). >> >> What I'm really curious is how/why you pretend that EHs work just >> fine and argue that there's no data (when we even have RFC7872 with >> data specifically about this) -- and also why at the time you >> opposed to publication of such document (something which would have >> made your claim of "this is just speculation, there's no data" >> valid). > > I don't pretend EHs (or pretty much anything on the Internet) work > just fine. I only ask you to represent your measurements in an open > and honest way. What the RFC does and even more so the presentation > Jeff pointed at is spreading FUD and does not in any way help the > community. To be honest I find your statement rather disrespectful, for at least these reasons: 1) The fact that you might have preferred to present the data in a different way, doesn't make the document or the authors dishonest. The document discusses the measurements in detail So anyone that *reads* the document will understand what the numbers mean. (*) 2) You've recently argued that wg documents are "owned" by the wg, and it's the wg that controls the changes to documents -- fair enough. Now, for this particular document, you blame *the authors* rather than the wg. Is that honest? (and no: I don't think there's anyone to blame) This wa a wg product. If you didn't like how the data were presented, you should have made your point, and we'd have modified the document. Instead, you simply opposed to publishing the document, rather than helping us improve it. But now you complain, and claim the document (or us, who knows) were dishonest. That's certainly not fair. 3) If you think data could have been represented in a better way, you should have made your point, and if the wg considered your point valid, we would have changed the I-D. (I wouldn't have had any issues in changing the doc accordingly, myself). Me, I think the value in the document is in providing data for a topic on which there was a lot of talk, but no data... so I couldn't care least about the outcome of the measurements. (*) The document originally just contained results for the drops, irrelevant of the AS. Then you asked about "where in the network do such packets occur", that's why we phrased it as "X of such drops occur at different ASes". Taking the look at the doc again (without looking at it for quite a while, I realize that if someone *quickly looks at the tables and doesn't read the text* might get confused. But there's nothing like dishonesty or intention in that. > I do not think a drop rate in the area of 2.5% warrants: "today's > routers are highly likely to drop packets with unknown headers". There are many aspects here. e.g.: 1) 2.5% is the best case scenario of all of them (we fail on "it's filtered by the dest AS" when in doubt, but this need not be the case). 2) You assume that the folk to which packets are destined has control over what his AS filters. This need not be the case. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 21 05:16:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE912E856; Fri, 21 Apr 2017 05:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1_PC2Z9kSxz5; Fri, 21 Apr 2017 05:15:29 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799EB12704A; Fri, 21 Apr 2017 05:15:29 -0700 (PDT) Received: from [192.168.1.173] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 939BD80622; Fri, 21 Apr 2017 14:15:27 +0200 (CEST) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: otroan@employees.org, Brian E Carpenter References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <819143C5-5CB7-41F5-94B2-CA40611FFED7@employees.org> Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 21 Apr 2017 13:03:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <819143C5-5CB7-41F5-94B2-CA40611FFED7@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:15:31 -0000 On 04/20/2017 09:31 PM, otroan@employees.org wrote: > > of course. but it is a difference between something that is "fixable" and something that is not. > if you read my comments as suggesting anything but support for the current text from the WG, then I apologise. I don't know what fixable is. Striclty speaking, lots of things are "fixable", including e.g. poverty, people dying of curable diseases, etc. Whether that's *feasible* is a different thing. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 21 05:16:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2BB12EAAC for ; Fri, 21 Apr 2017 05:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 vkHCNjLuXIW4 for ; Fri, 21 Apr 2017 05:15:35 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4071B12E856 for ; Fri, 21 Apr 2017 05:15:35 -0700 (PDT) Received: from [192.168.1.173] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7C52180763; Fri, 21 Apr 2017 14:15:33 +0200 (CEST) Subject: Re: Updated - Revised and expanded rfc2460bis Security Considerations To: Bob Hinden , IPv6 List References: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> Cc: Eric Rescorla From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <0ce63b70-9690-55f5-a27d-db934f1beea3@si6networks.com> Date: Fri, 21 Apr 2017 13:09:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:15:37 -0000 Hello, Bob, Thanks for sharing the text! Just a minor comment: On 04/20/2017 10:21 PM, Bob Hinden wrote: > > IPv6 addresses are significantly larger than IPv4 address making it > much harder to scan the address space across the Internet and even on > a single network link (e.g., Local Area Network). See [RFC7721] for > more information. Here I'd reference RFC7707 rather than RFC7721, since it's RFC7707 that discusses this topic in detail. Other than that the text looks great to me. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 21 06:01:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B981273B1 for ; Fri, 21 Apr 2017 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 HcUup137wyJm for ; Fri, 21 Apr 2017 06:01:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C91A124234 for ; Fri, 21 Apr 2017 06:01:45 -0700 (PDT) Received: from [192.168.1.173] (dsl-56-2.dsl.netsource.ie [213.79.56.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 42B0E80763; Fri, 21 Apr 2017 15:01:42 +0200 (CEST) Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Bob Hinden References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Cc: IPv6 List , Eric Rescorla From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3fbe67fc-ca5b-42f1-b9d8-4cd2f334256a@si6networks.com> Date: Fri, 21 Apr 2017 14:01:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:01:47 -0000 Hello, Bob, On 04/20/2017 09:44 PM, Bob Hinden wrote: >>> IPv6 packets can be protected from eavesdropping, packet >>> modification, replay, and man in the middle attacks by use of the >>> "Security Architecture for the Internet Protocol" [RFC4301]. In >>> addition, upper-layer protocols such as TLS or SSH can be used to >>> protect the application layer traffic running on top of IPv6. >> >> You may want to add references for TLS and SSH. > > I think both are well known, and are on the RFC Editors list of keywords. Fair enough. >>> IPv6 addresses are much larger than IPv4 address making it much >>> harder to scan the address space across the Internet and even on a >>> single network link (e.g., Local Area Network). >> >> You may want to reference RFC7707, and maybe RFC7721 -- the larger >> address space may not make address scans harder ... it all depends on >> how the IIDs are generated/selected >> > > Adding RFC7721 seems reasonable. For this particular case, I think referencing RFC7707 is better, since it's all about address scanning. For the most part, when it comes to this topic, RFC7721 just points to RFC7707. > I note that with our move to non-MAC based IIDs, it is much harder to scan than before. Fully agreed. ALthough there's still DHCPv6 which may or may not provide predictable addresses, and manually-configured addresses which generally are quite predictable. (all this being discussed in RFC77079. >>> This version of the IPv6 specification resolves a number of security >>> issues that were found with the previous version [RFC2460] of the >>> IPv6 specification. These include: >>> >>> o Revised the text to handle the case of fragments that are whole >>> datagrams (i.e., both the Fragment Offset field and the M flag >>> are zero). If received they should be processed as a >>> reassembled packet. Any other fragments that match should be >>> processed independently. The Fragment creation process was >>> modified to not create whole datagram fragments (Fragment >>> Offset field and the M flag are zero). >> >> I'd reference RFC8021 here -- which elaborated on the topic, and also >> describes specific attack vectors. > > RFC6946 made the update, so I think that is better. RFC6946 documents the rationale for processing atomic fragments as stand-alone (atomic) packets, while RFC8021 documents the rationale for not creating them (last sentence of the above paragraph). So probably it would be useful to reference the former for the first couple of sentences, and the latter for the last sentence. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Apr 21 07:31:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AB41294C5; Fri, 21 Apr 2017 07:31:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yeE-gn2yKT5P; Fri, 21 Apr 2017 07:31:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F36112009C; Fri, 21 Apr 2017 07:31:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1d1ZaR-0000HFC; Fri, 21 Apr 2017 16:31:03 +0200 Message-Id: To: ipv6@ietf.org Cc: Fernando Gont Cc: draft-ietf-6man-rfc2460bis@ietf.org, IESG , 6man-chairs@ietf.org Subject: Re: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> <7eea d764-1267-e2f0-7768-9a690f666c67@si6networks.com> In-reply-to: Your message of "Fri, 21 Apr 2017 12:59:56 +0100 ." <7eead764-1267-e2f0-7768-9a690f666c67@si6networks.com> Date: Fri, 21 Apr 2017 16:31:01 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 14:31:07 -0000 >> I do not think a drop rate in the area of 2.5% warrants: "today's >> routers are highly likely to drop packets with unknown headers". > >There are many aspects here. e.g.: > >1) 2.5% is the best case scenario of all of them (we fail on "it's >filtered by the dest AS" when in doubt, but this need not be the case). > >2) You assume that the folk to which packets are destined has control >over what his AS filters. This need not be the case. Note that I think that the current extension headers are by and large a failure. But absent that, your measurements seem to have an implicit assumption that anyone would spend resources on a feature that isn't used. So without a compelling use case for HBH or Dest. options, it makes a lot of sense to just drop those packets. You can see that clearly if you compare support for an extension header in a context where that header makes sense with one where it doesn't For example, support for fragmented DNS replies is way higher than support for fragmented TCP packets. So if you want to argue that the current internet is not transparent to various unused features, then yes that's true and has been known to be true for a couple of decades. That said, I doubt that any use case is compelling enough that wide spread support will develop. But using current filtering statistics to argue that such support will never develop goes a bit far. From nobody Fri Apr 21 07:52:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5B12951C for ; Fri, 21 Apr 2017 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 n2J3xxicb1vr for ; Fri, 21 Apr 2017 07:52:20 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 8EF8D129529 for ; Fri, 21 Apr 2017 07:52:20 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id m123so19279892wma.0 for ; Fri, 21 Apr 2017 07:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=vp67W/P48tRrsdkeNmCDCr9HQXKOlDJccnbvzMOqBzI=; b=BwLXwaWJ0YdYm8kaBOVMv0Da/DLKkjsEKWaAJiv6S23K5ZUSXy9ROCRtwFqKiznEJZ CWnxEVXlXTzWYRW/j1NVDfTLi/SUjyX4WXziCHYltLuy8Sa67ilb9w7UMx2D6XcMz/zM NfgtBJHBas9KPKqInFeErXOw1Ql5Dv26KE9Qu/9oDzvM7/lVEtlXPYb0E2lO52u6CUiJ LXQ2aq0pnqut8pmiH/0Vb51PKKMlIqhzP8NkuQOrKmW7Wn5i5KvoEkt1r1+lnD9Et/5Y UMQMqzVASSJT0PhT1RhbNMweXV2TaksCsNygaXhbAdrLuMmJ8vbfT51GwBbOJYLv9AoE C9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vp67W/P48tRrsdkeNmCDCr9HQXKOlDJccnbvzMOqBzI=; b=Rcdfwph6uTGZPlS+7JEyp0fZz+LUKeWELbQ2kuB5uTYYju/IAlAOE5wPL15dzCdcEK p+x8q8DNKjFIFOoMBQ4MCna5gee9Maw6z/xS7oFbJYhh4b8ooeW370/OFWmBNfBzifw+ ESlI2h8M2rm6yaI2jne+GxEgqqeM85eoac9UQ95smrtx5gha23hFKnyVxFCHzETkMATo RsK+I2PA+4OJu1uEi/02YQj9njQaLnuXzNtF0VfqFAo4TUa5NIGCUMrv4l7C3q8fVHhm 7DI7wVXm53X1iMXFv9Ons69PlBfIzpYudh2kHObimI0P8IKos00he27VVJ6SoMhz+imt 2XXA== X-Gm-Message-State: AN3rC/6G3NWzbjv1XFz6a+Nl21KXqmSnfahCKN70WpDNiTZcq7pZ1ys5 tUnY6WRJk+Df4OCTL3I= X-Received: by 10.28.152.80 with SMTP id a77mr8458600wme.116.1492786339117; Fri, 21 Apr 2017 07:52:19 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:f9e2:e96f:f90e:526d? ([2601:647:4d01:db10:f9e2:e96f:f90e:526d]) by smtp.gmail.com with ESMTPSA id z31sm3262805wrb.41.2017.04.21.07.52.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 07:52:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D978DF4B-AF36-4584-AE65-6BC90E71E1E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Updated - Revised and expanded rfc2460bis Security Considerations From: Bob Hinden X-Priority: 3 In-Reply-To: <01df01d2ba91$c9db9180$4001a8c0@gateway.2wire.net> Date: Fri, 21 Apr 2017 07:52:11 -0700 Cc: Bob Hinden , IPv6 List Message-Id: References: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> <01df01d2ba91$c9db9180$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 14:52:22 -0000 --Apple-Mail=_D978DF4B-AF36-4584-AE65-6BC90E71E1E6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Tom, I will forward it to her. Bob > On Apr 21, 2017, at 4:23 AM, t.petch wrote: > > Bob > > Kathleen raised a DISCUSS on the security considerations and since you > have changed the subject line, she may not see this thread. > > I suggest adding her to the distribution list to see if she agrees at > this stage (as opposed to being surprised later) > > Tom Petch > > > ----- Original Message ----- > From: "Bob Hinden" > To: "IPv6 List" > Cc: "Eric Rescorla" ; "Bob Hinden" > Sent: Thursday, April 20, 2017 10:21 PM > Subject: Updated - Revised and expanded rfc2460bis Security > Considerations > > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > --Apple-Mail=_D978DF4B-AF36-4584-AE65-6BC90E71E1E6 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+hycAAoJEK7rdBF357uozd4H/A6g6PZHLwDouGMoMgWtSEIZ 9z968DSGXIQSeVZIclG0opxx9Gi6OQkh0zMwC1ltcFrQ9jtNQN60+r1JEsmTaiaA 0zThUh1jnbz6ukjYHnlo9vw7bJp0aPftDiR0Rw7LwfuqHChdcV31jOB+/bJnrk1z aRdo3ZSst65A6VJaXZHTe7OjXlpwZ/Xw1qRXsdoi5SCNlWg7K8bVTyOtIv0zRTx0 /WninEEHR+8SLBwpu0NSkRwBmo5NgHqh8ibc3DdBsdrU70SSTEoN6HqVu0iaCD2V zsex5I88zb0LZk1ZNVJE6UTJ/NvemoBj8VW8eRzzIdXvaDjQjfu1iRccMKNIm2k= =nz0D -----END PGP SIGNATURE----- --Apple-Mail=_D978DF4B-AF36-4584-AE65-6BC90E71E1E6-- From nobody Fri Apr 21 08:34:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEDE129535; Fri, 21 Apr 2017 08:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ldBMpfvExOLp; Fri, 21 Apr 2017 08:34:36 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 D6B6B129510; Fri, 21 Apr 2017 08:34:35 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d80so9931695qke.3; Fri, 21 Apr 2017 08:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mOf6gPA6VwB28n30gsh8XRr+NWSRhjd3zd0YtqG2f4I=; b=Z6R0X037qpbynvZyt0EnZNrloR2rUGdX2fiZXmtg88mxqlP+KWuAgeoA+v81RLWYqH 9aVofD9HmWJ6r/iCoz5VWbfJB/NLtMjC49HP12Rip0nCfCutsmG7CXRG/YZJNiAUgEcU NPOyXGqU/H4vq9cxtX+wuxqwG9xIetyZ5eevJd31YIdJagIysyety091o0c1VBarXbvM MwdTbwHrkxgmbxiw4I6aXXyb37fiWIOn2MuAu13IugozoXbVNrPkVB+tvTc/DyNSjctL jGGTcXvg1t9OCGWGK0YUPdBhem9pwxR5uNR1S3ntNV8DUyPwBfr0+2Tg9YCdxrl5ntAc Ci/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mOf6gPA6VwB28n30gsh8XRr+NWSRhjd3zd0YtqG2f4I=; b=RFRM1vyNUzzUG7xQ+6kxtZsexDcgZ3EPwALhc3fGlop8PopCY0L3Jas4bptWFp6Tim gP1GPMSiAtuOqif5MXvx5BKHLHSNXilPnjGYZtSlQN1IIlT/iXTR3MbFsBhFTTDLWte3 mPbJEOOdxKYnRR57JLVgWnHvKMMV2vTpSpPn04lxtcxi2SQnzLUsaxnp9qLJyP9mT4Zn vLDYtOzSqi9Wvn8oO7QKv6peBCFoPN7i9A22kqDwseEXmVhd+XxiVmvv5ZDebMBYoJPC 0ao4YWSlb7jBZeEBM8Vumod6NgSUEBgEb5AyOSsOCg8ryLrpNwp5fWx6yynReIUPFa2i uBLA== X-Gm-Message-State: AN3rC/4jG2z/hDj/b05I18XkTDfUv1WGOmVJt+SpP15BNGIT1zxHGWY1 zyJMFpdeMfarJB94QBY355hdjiOkDQ== X-Received: by 10.233.237.194 with SMTP id c185mr13021244qkg.177.1492788874170; Fri, 21 Apr 2017 08:34:34 -0700 (PDT) MIME-Version: 1.0 Sender: fgont.si6networks@gmail.com Received: by 10.140.29.52 with HTTP; Fri, 21 Apr 2017 08:34:31 -0700 (PDT) Received: by 10.140.29.52 with HTTP; Fri, 21 Apr 2017 08:34:31 -0700 (PDT) In-Reply-To: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <06A2E959-B7A2-4D3D-84EF-4F997178775F@employees.org> <7eead764-1267-e2f0-7768-9a690f666c67@si6networks.com> From: Fernando Gont Date: Fri, 21 Apr 2017 12:34:31 -0300 X-Google-Sender-Auth: mYvYqT0M_g2Dk2k2-Deo0ZhLCbs Message-ID: Subject: =?UTF-8?Q?Re=3A_Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6ma?= =?UTF-8?Q?n=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Philip Homburg Cc: draft-ietf-6man-rfc2460bis@ietf.org, The IESG , ipv6@ietf.org, 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=94eb2c097a1091da11054daefea7 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:34:38 -0000 --94eb2c097a1091da11054daefea7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Phillip, Apologies for top-posting (mobile phone, and quoting capabilities are awful). Just wanted to clarify a few things: 1) RFC7872 simply provides data about drop rates, and does not speculate about the reasons for such packet drops. 2) While I'm inclined to think that deploying new EHs would be harder than getting the existing EHs to work, there's no way.I can predict the future. Nor do I claim I can tell what may or.may not happen. 3) I do believe that getting closer to the ops folks and trying to understand why they do what they do (rather than simply trashing them for "breaking the Internet") is probably one of the most sensible things to do if we want the situation to improve. 4) I think rfc2460bis is correct in the advise being provided in this area ("defining new EHs is not recommended"). Thanks! Cheers, Fernando El 21/4/2017 15:31, "Philip Homburg" escribi=C3=B3: > >> I do not think a drop rate in the area of 2.5% warrants: "today's > >> routers are highly likely to drop packets with unknown headers". > > > >There are many aspects here. e.g.: > > > >1) 2.5% is the best case scenario of all of them (we fail on "it's > >filtered by the dest AS" when in doubt, but this need not be the case). > > > >2) You assume that the folk to which packets are destined has control > >over what his AS filters. This need not be the case. > > Note that I think that the current extension headers are by and large a > failure. > > But absent that, your measurements seem to have an implicit assumption th= at > anyone would spend resources on a feature that isn't used. So without a > compelling use case for HBH or Dest. options, it makes a lot of sense to > just drop those packets. > > You can see that clearly if you compare support for an extension header i= n > a > context where that header makes sense with one where it doesn't > > For example, support for fragmented DNS replies is way higher than suppor= t > for fragmented TCP packets. > > So if you want to argue that the current internet is not transparent to > various unused features, then yes that's true and has been known to be tr= ue > for a couple of decades. > > That said, I doubt that any use case is compelling enough that wide sprea= d > support will develop. But using current filtering statistics to argue tha= t > such support will never develop goes a bit far. > --94eb2c097a1091da11054daefea7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Phillip,

Apologies for top-posting (mobile phone, and quoting capabilities are awfu= l).

Just wanted to clari= fy a few things:

1) RFC7= 872 simply provides data about drop rates, and does not speculate about the= reasons for such packet drops.

2) While I'm inclined to think that deploying new EHs would b= e harder than getting the existing EHs to work, there's no way.I can pr= edict the future. Nor do I claim I can tell what may or.may not happen.

3) I do believe that gettin= g closer to the ops folks and trying to understand why they do what they do= (rather than simply trashing them for "breaking the Internet") i= s probably one of the most sensible things to do if we want the situation t= o improve.

4) I think rf= c2460bis is correct in the advise being provided in this area ("defini= ng new EHs is not recommended").

Thanks!

Ch= eers,
Fernando




<= /div>

El 21/= 4/2017 15:31, "Philip Homburg" <pch-ipv6-ietf-4@u-1.phicoh.com> escribi=C3=B3:
>> I do not thi= nk a drop rate in the area of 2.5% warrants: "today's
>> routers are highly likely to drop packets with unknown headers&quo= t;.
>
>There are many aspects here. e.g.:
>
>1) 2.5% is the best case scenario of all of them (we fail on "it&#= 39;s
>filtered by the dest AS" when in doubt, but this need not be the c= ase).
>
>2) You assume that the folk to which packets are destined has control >over what his AS filters. This need not be the case.

Note that I think that the current extension headers are by and large a
failure.

But absent that, your measurements seem to have an implicit assumption that=
anyone would spend resources on a feature that isn't used. So without a=
compelling use case for HBH or Dest. options, it makes a lot of sense to just drop those packets.

You can see that clearly if you compare support for an extension header in = a
context where that header makes sense with one where it doesn't

For example, support for fragmented DNS replies is way higher than support<= br> for fragmented TCP packets.

So if you want to argue that the current internet is not transparent to
various unused features, then yes that's true and has been known to be = true
for a couple of decades.

That said, I doubt that any use case is compelling enough that wide spread<= br> support will develop. But using current filtering statistics to argue that<= br> such support will never develop goes a bit far.
--94eb2c097a1091da11054daefea7-- From nobody Fri Apr 21 10:27:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410AE129AF4; Fri, 21 Apr 2017 10:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JZukMd64qqDG; Fri, 21 Apr 2017 10:27:37 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 74804129AFC; Fri, 21 Apr 2017 10:27:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id r16so122134306ioi.2; Fri, 21 Apr 2017 10:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bve0PtFq0pdDsQ3ER+J6nkGXTq4mUIRBeJeu0xMr8JE=; b=cFTmIzzbm8131SjXBZi6Mr/PYuK75Mb3xHPSKmhsdHC3xkH9kiyySNFSLbohf5Pdjj ecpBzohxDVi95q8j+8Odvi2z1mZGXEwQKYDB46ShexnSizy16/4LsW8ozcgAsnZmLwPC Rq9w3l/Wc4Xnao2+UScttmnsKrTRg+3I0JSrYHL/EZv+E0eqoqMcYdtgFJw7CXm1UOVP hBTojhvYVZ9kRuVTRAqGtWCFB/JhBfd4q2DbxbN0Iad9H6op2FVolNyduo9ZB9Dfay7o vRRiQI3OfCho9egDDvNBz2Y8MlFK/1F2wA+tIKyIVLkgoK2PdAX2uUtIuenjqRXcNA5l zY+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bve0PtFq0pdDsQ3ER+J6nkGXTq4mUIRBeJeu0xMr8JE=; b=ceBEa9Nk7rC8GD7RjETlKFuRnNVb+rfAxYgfEk/+mHsLcV7K+zxqr7IiX72vwoZ1M/ RYYO4q7khyVBlWBP2MdM4fLXKWFJidWEnRs+Fy7J0Pzr7pi8Qw9Pv/JVqNyeJrSSeALP PpL27TWzFnj6eJ9jYG5etm7eR3GhbiEDUjY0ByXE0a8YWYkqi/0iHckLHl8Bh51oTyZu uhLZ/whGHUG1D7h52XbyUlBD3bceSgq7lOi6U5LQFco96R4OLXrBv19vMaZMNPVZodi0 7aovl95dL2ZVuSHZ4IuOmJEgqHvM0br+pLnXHgxlvTmuTQFu3GiiqFVEZPNAlJelfeqA Eelg== X-Gm-Message-State: AN3rC/4GoPcY1v6OGfmwYcI4s1I0zX8mqjy6DnzJDNgA58VQ4J684eTC tR6afbz+S8yYSscUtthCze4iu8YQLw== X-Received: by 10.107.33.135 with SMTP id h129mr18036692ioh.57.1492795566406; Fri, 21 Apr 2017 10:26:06 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.170.4 with HTTP; Fri, 21 Apr 2017 10:26:05 -0700 (PDT) In-Reply-To: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> From: Robert Raszuk Date: Fri, 21 Apr 2017 19:26:05 +0200 X-Google-Sender-Auth: lkSQzeIqRCoSvLwBMyoRyPuUDxQ Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Fernando Gont Cc: Bob Hinden , draft-ietf-6man-rfc2460bis@ietf.org, IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a1140f5e8755c5a054db08d5e Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:27:39 -0000 --001a1140f5e8755c5a054db08d5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I think this confirms that the current text which recommends against > defining new EH is correct. > > Yes. Our best possible outcome is that we get *existing* EHs to *not* be > filtered. I think it's *extremely* unlikely that one could get new EHs > to work. So I fully support recommending against the definition of new EH= s. > =E2=80=8BAll this means that instead of endorsing deployment of IPv6 you gu= ys are just shutting it down for a lot of customers and networks. With no future innovation in transport protocol what will happen is that it is now IPv6 which will be encapsulated in MPLS or IPv4+MPLS and carried over. Great progress indeed ! Cheers, R. PS. Perhaps most folks voting against SRH insertion in any transit node in the Internet or making recommendation against defining any new EHs are just completely detached from real hardware development, P4 programming, flexible packet processors coming as we speak from various vendors etc ... What are you guys using in your networks ? Optimistically assuming that you actually even have real networks to operate. It's like an attempt here to make a perfect baloon for any air travel and never add anything to it as it may fall. --001a1140f5e8755c5a054db08d5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
> I think t= his confirms that the current text which recommends against defining new EH= is correct.

Yes. Our best possible outcome is that we get *existing* EHs to *not= * be
filtered. I think it's *extremely* unlikely that one could get new EHs<= br> to work. So I fully support recommending against the definition of new EHs.=


=E2=80=8BAll this means that instead of endorsing deployment of I= Pv6 you guys are just shutting it down for a lot of customers and networks.= =C2=A0

With no future = innovation in transport protocol what will happen is that it is now IPv6 wh= ich will be encapsulated in MPLS or IPv4+MPLS and carried over.=C2=A0
=

Great progress indeed !

Cheers,
R.

PS.=C2=A0<= /div>

Perhaps most folks vot= ing against SRH insertion in any transit node in the Internet or making rec= ommendation against defining any new EHs are just completely detached from = real hardware development, P4 programming, flexible packet processors comin= g as we speak from various vendors etc ... What are you guys using in your = networks ? Optimistically assuming that you actually even have real network= s to operate. =C2=A0

I= t's like an attempt here to make a perfect baloon for any air travel an= d never add anything to it as it may fall.=C2=A0
--001a1140f5e8755c5a054db08d5e-- From nobody Fri Apr 21 12:38:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4712441E; Fri, 21 Apr 2017 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 ywQ9goqK_zj0; Fri, 21 Apr 2017 12:38:41 -0700 (PDT) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 3547012706D; Fri, 21 Apr 2017 12:38:41 -0700 (PDT) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 21 Apr 2017 19:38:41 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B1B43D788D; Fri, 21 Apr 2017 12:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=me/0/gP7owSWHZYUJPm6cQi8sIE=; b= sqskOjhQVafVI3Cw2Hv32cwIYRD29xjOgOKcJ/bTertLHKx2pHe9NH9Rui8R1Psx odfOiFWEweZvstfcFKWMV3fd4QhZ8Ks9xd2iKv+1U9kUOaj4EM7PpPafMDjvTuTw zMeNzhFawG6cF4u5L9bY68VyWSkJBLRfxuOSjgjHhFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=asC8TUqHMwlZzsNZcwoA1Td sg+2D7bom+jo2VzJHPL2jw6O4r2C5aNP5yFDsKylnPzabUCa7Fw71KPfzNz92nzZ bwqjncT7iqdFVD2jjiOoJ5uTBBHOfRLpJ2O4Bp0hlX5tkDaEZxtGyz0w7Ejqqfx8 8kO6/ocZSEuQtZ5ZyH+4= Received: from h.hanazo.no (77.16.72.83.tmi.telenormobil.no [77.16.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BEF43D788B; Fri, 21 Apr 2017 12:38:39 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D2EF2AE2A598; Fri, 21 Apr 2017 21:38:36 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_090D3BD8-D1D2-4138-A2D4-31D5C2A1EA0D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6m?= =?utf-8?Q?an-rfc2460bis-09=3A_=28with_DISCUSS_and_COMMENT=29?= Date: Fri, 21 Apr 2017 21:38:36 +0200 In-Reply-To: Cc: Fernando Gont , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org To: Robert Raszuk References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:38:42 -0000 --Apple-Mail=_090D3BD8-D1D2-4138-A2D4-31D5C2A1EA0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, > > I think this confirms that the current text which recommends against = defining new EH is correct. >=20 > Yes. Our best possible outcome is that we get *existing* EHs to *not* = be > filtered. I think it's *extremely* unlikely that one could get new EHs > to work. So I fully support recommending against the definition of new = EHs. >=20 >=20 > =E2=80=8BAll this means that instead of endorsing deployment of IPv6 = you guys are just shutting it down for a lot of customers and networks. >=20 > With no future innovation in transport protocol what will happen is = that it is now IPv6 which will be encapsulated in MPLS or IPv4+MPLS and = carried over. >=20 > Great progress indeed ! >=20 > Cheers, > R. >=20 > PS. >=20 > Perhaps most folks voting against SRH insertion in any transit node in = the Internet or making recommendation against defining any new EHs are = just completely detached from real hardware development, P4 programming, = flexible packet processors coming as we speak from various vendors etc = ... What are you guys using in your networks ? Optimistically assuming = that you actually even have real networks to operate. >=20 > It's like an attempt here to make a perfect baloon for any air travel = and never add anything to it as it may fall. This is really not what those changes in 2460bis are intended to do. Within the context of elevating 2460 to Internet standard, we can't add = new features. That does in no way stop anyone from proposing _new_ work. Of any sort. Best regards, Ole --Apple-Mail=_090D3BD8-D1D2-4138-A2D4-31D5C2A1EA0D 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY+l+8AAoJEL7aWKiYQt92HM4P/iB5hOM6QyudA4Dt8yijxS3w Ws/XMWCrnvtSdUZ8/jSNUubKWD6JziJJf6QZWTtAys8ScA6A5WYqpWgrwzgAVZAu fNTFQKrJiciNAw6EdMaM/yrpZIjqMRegfcdWfBenKafR9d4bKrEaxzfDM1nd20It ygzJcEmrsjqzphsmPWmYnhLgogFnXwPXGskSxsWJhpZwPSowBzbMAcPOHp0IETKH Hcq5NMK+jMbL3Fap4ZTmrxA+9iwinhtYgWte/Y1d5/BN27ZlP7axdSzOhtn0+FaT XwAK9v/iHi/HHQCreb6pEGWp4jmZnOe/+XEVGpx4TIY44A5qeJf2UTiYWsk0ea+e PQdnOc6+DAf0Bl57yey6dNtoqSwHgAMEboTeH9Gd/3NIFqyr6xhcgFdVwCo8snZX vz6akZjZSOh1DayvWCt0mdeliCwBJctYUt/HkRaKF/SowKg6PaLqcWXq/jDXwPG0 2NufAbBb4rA3IzjKg9Sy2Z9pdWzS93AWz8HTqrfya633QHpJVvT41+zpppoQPm2c QBjjUzzTLctvzZ9d8GElsmTMfYURWGqQABTCT4goY9eKGbCiL4y220z1RjlqE+G9 Z0dLEuR9dNkP5DQvzUomvb/m9iYVlAMRq5m+pR3HNttxIjnY1N7CFc21fs0gDhow 8IGr+Ro1e2IrLqw8pqia =B200 -----END PGP SIGNATURE----- --Apple-Mail=_090D3BD8-D1D2-4138-A2D4-31D5C2A1EA0D-- From nobody Fri Apr 21 13:10:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46931296D2; Fri, 21 Apr 2017 13:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GB3dkOebgHs9; Fri, 21 Apr 2017 13:09:50 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 5E382129B33; Fri, 21 Apr 2017 13:09:50 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id a103so133136535ioj.1; Fri, 21 Apr 2017 13:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DnroOFQXX/BSJVaaDZTBYos6WstPRPOf2PwgkopesiQ=; b=hvmhQwCt8I+IR8HHyj4Mavm3m3c4md1HqnyqCVLpufSfAxelkfVES/9j5OgP1S1H4j xmMl+hcTtdC/6KYqqs19imv77vMZ4S9cMqWPzpb2LiAU0TNxB1ZNgiKMHTfo4V09cExW R/dmejWtCoriwZLNmXTI/r9FMrqGTSD9hA3xxLknzVmNoq/5OjrpdDfV1ky7v9oNiV7e e3W3ztbYkbiZnX2RW5xukp1EdP+N6f63x5QcfYQYSYWNDPwOYOuE9FIOjwqQA5JYy9z8 Nr/44YdZLfF8vOMbDK9qS8LuS9z1fqhMoVFVulXgkXDwlBoUZAnbZcCv7uuNCc//SQiy oQlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DnroOFQXX/BSJVaaDZTBYos6WstPRPOf2PwgkopesiQ=; b=FRDq3fwIlvyQoyY93/VEIkMsEWOtNAB3/KfLVSrS5edrhnpDsCrF7j1uPtZAPuRm4k YH8+VlxXivxP2jLx3EtV/u5+6UaZhY4STH2YV11/OptV7gWe+fCGs5qZNvoyt+wFIaMz n8w/auyyXqjsRsg7FALcDLScXazWFHk09tDYfvGW9nobEX7O3yQwwn1nky991hf2T/Ug di9BXV0Pku4mNMzByYAr5RV4X/Y/iaOOGFmsVZszrbrFXYdYM9gCm8Dc7yEhRvxSY2SZ WnD4BEpEaUc9c8f3vI5Bpbg9sSHLQJGYvziDNwzk/Z42R4DIuRqqRa3VDFBFDLbYWlpr WXVQ== X-Gm-Message-State: AN3rC/70onQTyNUm/Yot/BadP70b2XK0Ipzrv5Szw+ySjyvLjs8i4rjw AVvi5YnRZp4DqSToqQcbPxBVA8aH8w== X-Received: by 10.107.33.135 with SMTP id h129mr18857405ioh.57.1492805375102; Fri, 21 Apr 2017 13:09:35 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.170.4 with HTTP; Fri, 21 Apr 2017 13:09:33 -0700 (PDT) In-Reply-To: References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <248F8BA5-48D6-4933-B45F-7F1B20477C2C@employees.org> <3C06A5F9-19B9-48E1-BB67-57D540E5E38D@kuehlewind.net> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> From: Robert Raszuk Date: Fri, 21 Apr 2017 22:09:33 +0200 X-Google-Sender-Auth: J42UtezWmFxyC1tSukN8pKmHNac Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: otroan@employees.org Cc: Fernando Gont , draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a1140f5e81a17dd054db2d60a Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 20:09:52 -0000 --001a1140f5e81a17dd054db2d60a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Ole,=E2=80=8B > That does in no way stop anyone from proposing _new_ work. Of any sort. > > Best regards, > Ole > =E2=80=8BVery true ! Anyone can propose anything in IETF. But with the text additions which I have seen here recently the bar to move from individual's draft proposal to WG doc then via all LCs to Standards Track RFC just went up significantly higher especially for SRH and EH elements. =E2=80=8B And that's my point. Cheers, R. --001a1140f5e81a17dd054db2d60a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Ole,=E2=80=8B
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">That does in no way stop anyone from proposin= g _new_ work. Of any sort.

Best regards,
Ole
=C2=A0
=E2=80=8BVery = true ! Anyone can propose anything in IETF.=C2=A0

But with the text additions which I = have seen here recently the bar to move from individual's draft proposa= l to WG doc then via all LCs to Standards Track RFC just went up significan= tly higher especially for SRH and EH elements. =E2=80=8B

And that's my point.=C2=A0

Cheers,
R.

--001a1140f5e81a17dd054db2d60a-- From nobody Fri Apr 21 14:02:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13C21293F2 for ; Fri, 21 Apr 2017 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 NCi2QeykCoXu for ; Fri, 21 Apr 2017 14:02:54 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 27520126C89 for ; Fri, 21 Apr 2017 14:02:54 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id k87so136043557ioi.0 for ; Fri, 21 Apr 2017 14:02:54 -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=rmju82m1R2zZtuhrgGWoZT3bv9scpRuKjJZ1RsK017s=; b=Kb5ckIxBc2/XFNmjQuRCbFH32B5VWtD99E3/Ldre0UkEdPS9Yo5DsQykX/IHsAgIpH P4xlkFtPaMVOcfgqnH3S8Z0XeeZrqmt+Qni9JCQ22XXbRsz8yopCzFmN22CmAyq64Fhn Y5FBDJhV28xjZu9PhzAmIzFJ/wDqcunjXznbOquQJ1gjyu6m8KFLzCDabdlJTma/YfRt O5qFajwtqkzOMR9aH3MHhmNWkPNrbg0Nx6zPZpVjgkLJjjTIo+esFqsI7ormX4LqHk0y AWGCcUDIVftJTSa7Pv2GH8cNfS+W8UmBayjJnVU81xG22BVbZSnaST8/bhiSAIzR1b7T shjQ== 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=rmju82m1R2zZtuhrgGWoZT3bv9scpRuKjJZ1RsK017s=; b=q6gqaFl5Myz8bYFrNv17W6IUHR22Sh108PWwceD4jZuUYIfnX8ml/5VOwFdb6g1NjF 0/caUuiceemoid7U0jhkJ1lNy+Niz2m1pPoMgK+LrELGlVegspl5GXLNbQkTpOuXcI1R vJAVV0ParcTgHhOHrbaJmwgLOZz/lvaO2i/DifUbaykyteuTc/QbSLOK8KqAehRYsxbZ 1uflhpyDaTdZsTHngg6NwpjTXMqVvRlA5XXe5TpJXL3dGZQzpB5dgnTYMI8zzISCOofj zuYDC3w1RIJRo/NdQd1QWeg+SxnrNrboWVf97S5iJugM3AUNYhilBlqgcllibGAgKGXF BUig== X-Gm-Message-State: AN3rC/7TINYbOJgWZUCRbTMY8S2zbf80BCY9/M1hj1HUXB0avlwuJW3X eZqbG/yllgMdOQ== X-Received: by 10.107.191.67 with SMTP id p64mr17880292iof.236.1492808573401; Fri, 21 Apr 2017 14:02:53 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g132sm1222563ita.7.2017.04.21.14.02.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 14:02:52 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7082A9B7-39E1-47C6-9874-18822AAA8C17"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Updated - Revised and expanded rfc2460bis Security Considerations Date: Fri, 21 Apr 2017 14:02:49 -0700 In-Reply-To: <0ce63b70-9690-55f5-a27d-db934f1beea3@si6networks.com> Cc: Bob Hinden , IPv6 List , Eric Rescorla To: Fernando Gont References: <7533CCE9-4992-45E6-84C5-A024C3BD5F3C@gmail.com> <0ce63b70-9690-55f5-a27d-db934f1beea3@si6networks.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 21:02:56 -0000 --Apple-Mail=_7082A9B7-39E1-47C6-9874-18822AAA8C17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Fernando, > On Apr 21, 2017, at 5:09 AM, Fernando Gont wrote: > > Hello, Bob, > > Thanks for sharing the text! Just a minor comment: > > On 04/20/2017 10:21 PM, Bob Hinden wrote: >> >> IPv6 addresses are significantly larger than IPv4 address making it >> much harder to scan the address space across the Internet and even on >> a single network link (e.g., Local Area Network). See [RFC7721] for >> more information. > > Here I'd reference RFC7707 rather than RFC7721, since it's RFC7707 that > discusses this topic in detail. OK. > > Other than that the text looks great to me. Thanks, I will submit a new draft today with these security considerations. Bob > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > --Apple-Mail=_7082A9B7-39E1-47C6-9874-18822AAA8C17 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+nN7AAoJEK7rdBF357uo9W8IAK6xWGfWi7o3Nsxz2BnvJIaF 3RvOOM2+XyUodcBJWixEBPf+qeNVHb6cpLjEuiSgT0pTBIh6luimgJO6sykm3bw7 IhaXn6Mezhx00YTb2ectnZ5UwT5w8ZgSL0e2AwH9QaNAYJVxX2aMsF2aRnF73Ng8 ulZQDCq7hlxWU18Hx/1srBedckbOuJWNx/xD7tbArqamNlH5wPhmGjaO6JU1Sc2N sEUpHlqgjn+ke0+EbChUsNVj+g574iG1foarYuzQE3YK5NQSOs0i69/BUwkmF8cq u2xbMPeijtMlma+vU5GbthqxI2vWCwLPXXAXhKA4glN2YIKYtJkyZLmu3bi/5iY= =fELN -----END PGP SIGNATURE----- --Apple-Mail=_7082A9B7-39E1-47C6-9874-18822AAA8C17-- From nobody Fri Apr 21 15:18:22 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41317128D40; Fri, 21 Apr 2017 15:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc2460bis-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281309523.25767.11597718692733511732@ietfa.amsl.com> Date: Fri, 21 Apr 2017 15:18:15 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:18:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Authors : Stephen E. Deering <> Robert M. Hinden Filename : draft-ietf-6man-rfc2460bis-10.txt Pages : 44 Date : 2017-04-21 Abstract: This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 21 15:24:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB7D1243FE for ; Fri, 21 Apr 2017 15:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 N9bDwDQmUcYV for ; Fri, 21 Apr 2017 15:24:09 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 DDC5E127A91 for ; Fri, 21 Apr 2017 15:24:08 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id a140so2062631ita.0 for ; Fri, 21 Apr 2017 15:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=3jJqGt7sSqcN5dlGCp7+9fth5Kg93moeJHbkgR49F7U=; b=vepQDgBpvjYw+helTDgHIaHr4TpDGUjGL5E98fjVj8YZlJhRCFrkkGt5/51RxRtNjB tiCf+8l/eriYyEJV2LpdqcVY60mQGpo0F1g2dUgxIE0VwGd6F4C1ZsTT2GU+JN5mcQTV vyULZjqBx41oIoXRSaHBJWSGh0oEvIR+T3i8uJrlrqdO/gvd4XpfKo42rtWb4lTgsfPd PLb4DNKrUOyNsp4Bm+ruusYlcfPZyCd2g1KUFaA8u3hvjvZUdbeTGbSqFK0HrOZMhec6 FpxyBXucruGuH1qdh2kafHeDX3VUy72Gp7Ca6zWblxhBP0OTI/HmDhKc9QuTLe6689TO fh2Q== 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:date:cc:to; bh=3jJqGt7sSqcN5dlGCp7+9fth5Kg93moeJHbkgR49F7U=; b=RC/6bbTPY9DSROTgHQ20BFfuWD1M00E3B9PxNNHOBPzrjmILMgQTItkRKfPaxi0ICZ JTVXQIaRULuHZ2DEzkYXwsD7lClRyYHFTX/qRsZVrdl9dQEqyRIm1mt77/UPQG8tLpF7 lKdUeaoyeFDoWigD8GlF15pHf+K2r9an6h4G1n/LPBP7XP8f/3G2d8E/zfdT+2V6Ufax CgDlVhBdeL2LRFNQIjRsDvH7RlglciYBQYp/cdw7DBalu7mJGt4gXVaNaE69GpewC6GZ Rd5bSnATGBSvpLnFMWSFmnGL7Wp72FApz59OPcpQboLoZ7pHI4gknC3VTKFs7NbhVaCd 3DJQ== X-Gm-Message-State: AN3rC/5WD15Upm2ybf31KVRLIDemqyeyhFZO/q6TMuWkn93/feQbKhGY +ZMJqNc0pQRgIQ== X-Received: by 10.36.58.9 with SMTP id m9mr1187186itm.2.1492813448190; Fri, 21 Apr 2017 15:24:08 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id n85sm909994ioi.6.2017.04.21.15.24.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 15:24:07 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_2A4BA241-9BE8-4A47-AF91-B4457CE58F6C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Message-Id: <86C2C04E-3CB0-4840-AB26-8DF0BB06D3CE@gmail.com> Date: Fri, 21 Apr 2017 15:24:04 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:24:11 -0000 --Apple-Mail=_2A4BA241-9BE8-4A47-AF91-B4457CE58F6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the -10 version of 6man working group draft of rfc2460bis. = Links below. The changes in this draft are: Revised and expanded Security Consideration Section based on IESG Discuss comments. Editorial changes from IESG review comments. A diff from the -09 version can be found at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-10 Please review the changes. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc2460bis-10.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc2460bis > Revision: 10 > Title: Internet Protocol, Version 6 (IPv6) = Specification > Document date: 2017-04-21 > Group: 6man > Pages: 44 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-10.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-10 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-10 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-10 >=20 > Abstract: > This document specifies version 6 of the Internet Protocol (IPv6). > It obsoletes RFC2460 --Apple-Mail=_2A4BA241-9BE8-4A47-AF91-B4457CE58F6C 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY+oaFAAoJEK7rdBF357uoX2sH/A1gI5gsXVNj5SS8BqLgEz5R 4loJr2c38KnY9kRPrduWvDIn9XAF9yZeNLWAYCP94lzuSEOdwBMUVRqdQQlIS2YP /t2IMWiGtKQxSwjEEUEkKR7OxmzjkEgb+qKtU6S5NMS1VJrPbugsjgS16UR8/koU xn3tMYX4uPqA31quhD0hQnh7UnfVF94EjIY2WciObBuUZQH6VarAZTC0kqwj2jGT EV8s3jSxXJ8OwOFZtZ8AdEXXlmWfjceRcFrLhH5mFtYOt1ShuuDqSGmJa1TtalFD dHiqF8ZeX8Xi/wptlMHNeh4jPaMiC1JkoEh1g6A8Hg8RGMQ9SRB1F8Eqfe9WbS8= =w++t -----END PGP SIGNATURE----- --Apple-Mail=_2A4BA241-9BE8-4A47-AF91-B4457CE58F6C-- From nobody Fri Apr 21 15:39:09 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7065129407; Fri, 21 Apr 2017 15:39:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Eric Rescorla's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281434180.25836.10818713217769164593.idtracker@ietfa.amsl.com> Date: Fri, 21 Apr 2017 15:39:01 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 22:39:02 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-6man-rfc2460bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I get that this document is from a period before the style became as uniformly to upper-casify RFC2119 keywords, but but it seems like it might be a good idea to do that here. It's a little hard to determine what is normative here, but S 4. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload Given that 6434-bis seems to have backed away from IPsec, this document needs to as well. S 4.4. Assuming I am reading this document correctly (and I've never implemented v6 so I could be crazy), in order to implement the routing header you need to decrement Segments Left, but the document does not seem to say that. S 4.5. As I read this document the order of headers is only strongly recommended, but the rules about fragmentation seem to absolutely require a specific order: The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Is there a reason why the rules are not MUST? S 4.5. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. If fragments follow different paths (not crazy) then the hop limit will be different, right? So perhaps "not expected" is a bit strong. S 8.4. Response packets that carry Routing headers that were derived by reversing the Routing header of the received packet IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header from the received packet have been verified by the responder. It's not clear to me how this works. If, as I suggest above, the routing header gets changed in transit, how do you measure the integrity and authenticity? Even if that is not the case, and you use something like IPsec to provide integrity, why do you trust whatever claims the sender makes about routing. From nobody Fri Apr 21 16:18:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44B0127071; Fri, 21 Apr 2017 16:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 o1tXO2ys9th2; Fri, 21 Apr 2017 16:18:16 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 B87DF1242F5; Fri, 21 Apr 2017 16:18:16 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id k87so34722316ioi.0; Fri, 21 Apr 2017 16:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=srGHt5B0zClZDqQ37KTVO2TnPjU75swR55A4U+r5VPU=; b=TpMCJNhRSpflDrr4+ui5drJKTgtkQTIz7V9/bc/R4EILas/PDu7fx28Bc61b9rmAX/ sdIaYbjSL8Qbfz8M4ebZb0EB7BO+9D8OjrVjTDL2DVA8L8Gfq4dsyLLBBtnPjZfykzGm p4XWorVSvThzq8eDAGtdVwDaCUiOGwnzKfgqXNILoxo3Bjd4gJqzrn09f9+hTW5tYLJV DJ8gknSs3gjeYTmlE8cKrE9FCPvt3LnCqolWGTO+QYYocIE9Mqv2y0r6/Fw/iMuyu6sx P5zktMCDCpWKy/TEKZ23M4FLE31OfaAgFPRkKf3Ms7Nf1iUvFcFoUKO/5HakgaVwlw0X gLtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=srGHt5B0zClZDqQ37KTVO2TnPjU75swR55A4U+r5VPU=; b=G2/XQU3fvlnj9hflCDDpA5d6CbAuEkijIFtrSPiDxcvjOzQGVwrxKiPCp3cZwWp3zf vgdaQzw4eovXgC0ow2RKOpJO/5ULZM5lHybu+DBQas7npyHhy6dYqv2MDKHcEC87mGrd LGiFlVZgnu34X2hJOBt46d/RD5/4+DOb2/ywQ8uVlwzz5q5uC/haEmZbN3DWHBPbM4l/ j/ohDQaA8pfoYth1n32TJ2svtdsGJzDF8viY7S7Zo0gZyP/t78lqmXMzK9mSJ1J57Fly SRzWRQ2AWfT0CxzTXeqP+mEgM3OAVDsslRhKHX6nLN2ME/8GkAR15n5fLAasJM6DSHFm H5qw== X-Gm-Message-State: AN3rC/5WnC0uMm8Bo+isTZPW78Wfwc/mptpAzYSrUk6RH2ETJablPM+P DjVNkecP0tEucQ== X-Received: by 10.98.28.68 with SMTP id c65mr4700619pfc.124.1492816696048; Fri, 21 Apr 2017 16:18:16 -0700 (PDT) Received: from ?IPv6:2406:e007:58b4:1:28cc:dc4c:9703:6781? ([2406:e007:58b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q1sm17876256pfc.35.2017.04.21.16.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 16:18:15 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: "Stefano Previdi (sprevidi)" References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <58B249A0-2F0B-4AD6-890D-BB0F0594DEE1@kuehlewind.net> <0c7d3a7b-99c9-dbef-d6cc-9a4a94cb9c9f@gmail.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <53D314DF-2C83-4837-A9D2-AB776231BADC@cisco.com> Cc: Bob Hinden , Fernando Gont , "draft-ietf-6man-rfc2460bis@ietf.org" , IPv6 List , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <86222e93-146b-3532-640a-c31fa4eceee2@gmail.com> Date: Sat, 22 Apr 2017 11:18:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <53D314DF-2C83-4837-A9D2-AB776231BADC@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:18:19 -0000 On 21/04/2017 20:21, Stefano Previdi (sprevidi) wrote: >=20 >> On Apr 20, 2017, at 10:22 PM, Brian E Carpenter wrote: >> >> On 21/04/2017 03:47, Bob Hinden wrote: >>> Fernando, >>> >>>> On Apr 20, 2017, at 6:01 AM, Fernando Gont w= rote: >>>> >>>>> =E2=80=A6. >>>>> >>>>> Dropping unknown extension headers in transit networks is relativel= y >>>>> rare. With the HBH being an exception, with almost a 40% drop. (Not= e >>>>> that there are no HBH option that would make a lot of sense across >>>>> the Internet, so again chicken and egg.) >>>> >>>> Based on RFC7872 ("Observations on the Dropping of Packets with IPv6= >>>> Extension Headers in the Real World"), your statement is incorrect. >>>> >>>> Transit routers do filter packets with EHs, whether known or unknown= =2E >>> >>> I think this confirms that the current text which recommends against = defining new EH is correct. >> >> Hate to say it, but yes, IMHO that was a clear WG consensus and I don'= t think >> the IESG has the right to override it. >=20 >=20 > well, there=E2=80=99s been another WG consensus that has been overridde= n by IESG so what=E2=80=99s the algorithm exactly ? It's fine if IESG review raises an issue and the WG agrees to the suggest= ed change. But in this case I don't personally see any change in the WG's= collective opinion. See the first two bullets at https://www.ietf.org/iesg/statement/discuss-criteria.html (Full disclosure: I was IETF Chair when those criteria were agreed and pu= blished.) Brian >> >> On 21/04/2017 05:09, Stefano Previdi (sprevidi) wrote: >> ... >>> Definition of new EHs must be done carefully but I don=E2=80=99t see = why it should be prevented, >> >> which is exactly why the consensus is *not recommended* rather than *m= ust not*. >> Even without formally using RFC2119, the distinction is clear. >> >> Why are we re-litigating this? >> >> On 21/04/2017 06:54, otroan@employees.org wrote: >> ... >>> I do not think a drop rate in the area of 2.5% warrants: >>> "today's routers are highly likely to drop packets with unknown heade= rs". >> >> That's beside the point for 2460bis. The point is that unknown EHs are= dropped >> on *some* paths, which makes deploying them tricky, regardless of the = percentage. >> >> Brian >> >> >> >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Fri Apr 21 16:34:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303AF128B93; Fri, 21 Apr 2017 16:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 RVZl_Zxhvfa3; Fri, 21 Apr 2017 16:34:30 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 A6064120046; Fri, 21 Apr 2017 16:34:30 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id z67so926946itb.0; Fri, 21 Apr 2017 16:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=v3DOz3B2W5rloTYwkiZUCiw/g+M+/CJwyy5JJgRIQqY=; b=T2Zl73aax0nvh23g66hLjSY9NGipvlA2OdpsSBESh/rOeTQaMJXdf0SK9cObL85PFy wL6TM2Fo0CYJ0h70UyLoAYo6P3ZYar7TBtBW8K3+4Z89Kxd0r97C6nVowB/42LgSRrTe VkxXOqXFn53GvcdK6HZMlSKlUEQOHAxSRarF9CXgaxckjvrosGXcCHEOB1fqXWwfZIEN XB1gOhntPonwo6uKJtCS5EP5mqTV147wWGHrDkB85kWbA94ev/qJj7ZrvLJb7wQePEUa wtGz3ZymSeA0LNDWguDrSkM9bm6fjgK0CKN5YrHWQ/4F15Of9VHokyrgWrlnhqO4W/Wl Lqmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=v3DOz3B2W5rloTYwkiZUCiw/g+M+/CJwyy5JJgRIQqY=; b=jhcoPl8WNc3Ns2UYk9QAwjDrt15dVzwSTVZTEi5Hs8GkQSPZuewtl53nGxkr46hDLL eX7PdvLtyTQtlGXUFzrojqjAtebmt0msHScI1pWWwInoKbGgwQsILJxGranV20MOWWS/ 3zHi68IdvFPWIGDyq2jQvI0fDi1IaSHIVfFPVoQUz9tAXgqtejYKLyqpFw0m3lqzGBmd 3QtA0B7cUSAjl+iM0IfSYhir9XwoLSGLAQ2qFazVIRpVcnecCjwJmI9w8oypeiCR8g8h qbLWFn5dV0deSmCn5Xcb3mNfOgHL3jOhcw6yGDju6YDxBzRl12Cnpc7thkvej7jDK+Iy MeNQ== X-Gm-Message-State: AN3rC/452IdUdYWkitlRHk0SqqT5aWKfU/Ccuq5JsMV20eVf9pN80KZp GVtA2QABjzn1fA== X-Received: by 10.99.115.90 with SMTP id d26mr7375539pgn.101.1492817669880; Fri, 21 Apr 2017 16:34:29 -0700 (PDT) Received: from ?IPv6:2406:e007:58b4:1:28cc:dc4c:9703:6781? ([2406:e007:58b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w5sm6002084pfd.23.2017.04.21.16.34.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 16:34:28 -0700 (PDT) Subject: =?UTF-8?Q?Re:_Mirja_K=c3=bchlewind's_Discuss_on_draft-ietf-6man-rfc?= =?UTF-8?Q?2460bis-09:_=28with_DISCUSS_and_COMMENT=29?= To: Robert Raszuk , otroan@employees.org References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , Fernando Gont , 6man-chairs@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <60bf60a7-269b-03c2-21c2-a00d85a2c3c4@gmail.com> Date: Sat, 22 Apr 2017 11:34:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 23:34:32 -0000 On 22/04/2017 08:09, Robert Raszuk wrote: > =E2=80=8BHi Ole,=E2=80=8B >=20 >=20 >> That does in no way stop anyone from proposing _new_ work. Of any sort= =2E >> >> Best regards, >> Ole >> >=20 > =E2=80=8BVery true ! Anyone can propose anything in IETF. >=20 > But with the text additions which I have seen here recently the bar to = move > from individual's draft proposal to WG doc then via all LCs to Standard= s > Track RFC just went up significantly higher especially for SRH and EH > elements. =E2=80=8B >=20 > And that's my point. But *our* point, for some definition of 'our', is that by making the Internet-wide situation clear, we are in fact clearing the way for carefu= l definition of local-use mechanisms. At the moment, as we've clearly seen from discussion of the SRH, we simply can't have that discussion because of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicker we get that settled and approved by the IESG, the quicker we can look seriously at draft-voyer-6man-extension-header-insertion. You might ask yourself why no IPv4 options have been defined since 2007 (Quick Start) and before that, 1997 (Router Alert). The same reason: they= don't survive a trip across the Internet. Brian From nobody Fri Apr 21 21:16:16 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8812944A; Fri, 21 Apr 2017 21:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ines Robles To: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org Subject: Rtgdir last call review of draft-ietf-6man-rfc1981bis-06 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149283456181.25913.15133934620501134310@ietfa.amsl.com> Date: Fri, 21 Apr 2017 21:16:01 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 04:16:02 -0000 Reviewer: Ines Robles Review result: Has Nits Document: draft-ietf-6man-rfc1981bis-06.txt Reviewer: Ines Robles Review Date: April 21, 2017 Intended status: Standards Track Summary: This document describes Path MTU Discovery for IP version 6 I believe the draft is technically good. I have no “Major” issues with this I-D. I have some minor comments. Comments: 1- I think that it would be nice to add a graphical example that describes the process of the Path MTU Discovery (including a Packet Too Big Message). e.g. Figure 1 of RFC 5927[1]. 2- Section 1: 2.1- I would add a reference when you mention black hole connection. What about section 2.1 of [2] or [3]? 3- Section 2: 3.1- EMTU_S => When it is defined, it references RFC6691. But this term is not mentioned in RFC6691. I would add additionally a reference to RFC 1122 [4] which defines EMTU_S. 3.2- I would add also the same references for EMTU_R. 4.Section 3: 4.1- In the first paragraph, I would add a reference to ICMPv6 the first time that ICMPv6 Packet Too Big message is mentioned. And I would add here also "(ICMPv6 PTB)" since it used further in the document. 4.2- In the first paragraph: "...to send smaller fragments or ..." --> I think it would be clearer "to send smaller packets or..." 4.3- Second Paragraph: "...process ends when the node's estimate..." -> "...process ends when the source node's estimate..."? 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but is in fact..." -> "...but it is in fact..." 5. Section 4: 4.1- about this: "The node MUST reduce the size of the packets it is sending along the path". I would add an explanation to which size the packet should be reduced (maybe based in an initial example) 6.Section 5: 6.1- I would add a reference to RFC 1122 [4] when MMS_S is mentioned. 6.2- Section 5.5: "Some transport protocols are not allowed to repacketize when doing a retransmission..." I would add some examples. 7. Section 6: 7.1- What about to mention Blind Performance-Degrading Attack [5]? From nobody Sat Apr 22 00:28:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33C7126C83; Sat, 22 Apr 2017 00:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uaErC7MHWInx; Sat, 22 Apr 2017 00:28:14 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 EF7DF126DED; Sat, 22 Apr 2017 00:28:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r16so135869472ioi.2; Sat, 22 Apr 2017 00:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4UHOwEIOptFxQIqy+yBmyI0FkPbKOxPXtXob/Lkx+mo=; b=t/8IEIumdErMV3P0G8eTskBKPaM7iFMR1nGeuhYmOiPL+Aarh7R6K+wdnB4mpV6CCg HxVNPvOo+YGMl4fLAx4kp1nSf8MfVruuVM8H5PX3fzLGpIKYAWKZzsB+pQMfJxFAaq4Y mzK6c0lXF3o9KC4znZFlbXlu//exNwhaE29Sz5qO+lreP9p5gENN9G80FW/p2WZ3UqNR Dz6WVhzRvpY0gpdlwxOS1GO3/+1x/4QLNxibxYeUKYouDqLT7D/Fm7Diacl80Og06e8v BSUuOTtbCAOo/1Eip6qXtqrHLAWgYXTw+4K46tXK8Ud8DRzGylxT5g4D6EXfNjujXXAk 6q/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4UHOwEIOptFxQIqy+yBmyI0FkPbKOxPXtXob/Lkx+mo=; b=nNZ7brAxP9tGyN0Zabn/EjhQkvEcewYbliMMzPHOl8LEh0MLrscxMoN1ubsJ4xa3gr k6qLG3G64kJVXU0WE0YlGstyxARQKMJjgTaJ1sQC/hOTgCQApxARhQXISWB7Y/Mh2YbY rdnuvUS8avgil+CXbtMJgHoJCx1KGUGDdsbPliKQf6O56FH3QqWHOSS1J8a1V5Kq+sVG qH6WYTr94kiYjdylC4DD4jbd0+r7oxlGxduqjybi2x8TMi4mi6bzb6bADaELGyAHuA3e jJm6mbxLO94NhE1TJf9BRZ7uRoROMtqM6P5RKMyHvooXOZqdHdou3LBi9NNvSnC7fOfm U/Pg== X-Gm-Message-State: AN3rC/7eIrj2rgoR2Vxe0fN18N07P7Y2ktqLHPDs72ZkWtsiFkTZdqEB WQu9qFtebZae7X1ZOALErgh7wLkJ5A== X-Received: by 10.107.16.135 with SMTP id 7mr412610ioq.228.1492846093306; Sat, 22 Apr 2017 00:28:13 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.170.4 with HTTP; Sat, 22 Apr 2017 00:28:12 -0700 (PDT) In-Reply-To: <60bf60a7-269b-03c2-21c2-a00d85a2c3c4@gmail.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <4AE56E75-78D4-43EA-8118-8195FD8A3D08@kuehlewind.net> <4fc2ef36-cd17-58f1-8089-a5645f08ad45@gmail.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <60bf60a7-269b-03c2-21c2-a00d85a2c3c4@gmail.com> From: Robert Raszuk Date: Sat, 22 Apr 2017 09:28:12 +0200 X-Google-Sender-Auth: hgAzAaVsFZQxtuW4i0J4iRo6yio Message-ID: Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2D6man=2Drf?= =?UTF-8?Q?c2460bis=2D09=3A_=28with_DISCUSS_and_COMMENT=29?= To: Brian E Carpenter Cc: otroan@employees.org, draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , Fernando Gont , 6man-chairs@ietf.org, stefano previdi Content-Type: multipart/alternative; boundary=001a113fe9c218a15c054dbc5151 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 07:28:16 -0000 --001a113fe9c218a15c054dbc5151 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, In every other email I see a concern about "Internet" or "Internet-wide" behavior. To me Internet is a collection of *independent* chain of Autonomous Systems. As name indicates those domains are **autonomous** and can do whatever they like to do with packets they carry. If they do not choose to do right things customers will avoid them, there will be no revenue and they will disappear from Internet map. Pure and simple. I find it very bizarre that IETF is trying to be a judge or policer to dictate on what each AS can or can not do in their own network. Moreover it also apparently is putting least common denominator rule which states that all 50000 ASes should do MUST only be limited to what the weakest AS can do with either old or incapable vendors to support innovation. I was apparently very wrong assuming for all those years that IETF focus is to make sure that protocol extensions we define are as best as we are collectively able to do .. rather then community to worry what hardware vendors will manage to support or not support in what we define. So what will happen ... we will either have waves of proprietary features which will be hard to interoperate even within single AS or that definition of such things will take a spin outside of IETF via various forums, consortium, foundations etc ... Do we really all here endorse such direction ? Have a great weekend, Robert. On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 22/04/2017 08:09, Robert Raszuk wrote: > > =E2=80=8BHi Ole,=E2=80=8B > > > > > >> That does in no way stop anyone from proposing _new_ work. Of any sort= . > >> > >> Best regards, > >> Ole > >> > > > > =E2=80=8BVery true ! Anyone can propose anything in IETF. > > > > But with the text additions which I have seen here recently the bar to > move > > from individual's draft proposal to WG doc then via all LCs to Standard= s > > Track RFC just went up significantly higher especially for SRH and EH > > elements. =E2=80=8B > > > > And that's my point. > > But *our* point, for some definition of 'our', is that by making the > Internet-wide situation clear, we are in fact clearing the way for carefu= l > definition of local-use mechanisms. At the moment, as we've clearly seen > from discussion of the SRH, we simply can't have that discussion because > of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicker > we get that settled and approved by the IESG, the quicker we can look > seriously at draft-voyer-6man-extension-header-insertion. > > You might ask yourself why no IPv4 options have been defined since 2007 > (Quick Start) and before that, 1997 (Router Alert). The same reason: they > don't survive a trip across the Internet. > > Brian > > --001a113fe9c218a15c054dbc5151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,=C2=A0

In every other email I see a concern about &q= uot;Internet" or "Internet-wide" behavior.=C2=A0

To me Internet is a collection of= *independent* chain of Autonomous Systems. As name indicates those domains= are *autonomous*=C2=A0and can do whatever they like to do with pack= ets they carry. If they do not choose to do right things customers will avo= id them, there will be no revenue and they will disappear from Internet map= . Pure and simple.=C2=A0

I find it very bizarre that IETF is trying to be a judge or policer to d= ictate on what each AS can or can not do in their own network. Moreover it = also apparently is putting least common denominator rule which states that = all 50000 ASes should do MUST only be limited to what the weakest AS can do= with either old or incapable vendors to support innovation.=C2=A0

I was apparently very wrong as= suming for all those years that IETF focus is to make sure that protocol ex= tensions we define are as best as we are collectively able to do .. rather = then community to worry what hardware vendors will manage to support or not= support in what we define.=C2=A0

So what will happen ... we will either have waves of propriet= ary features which will be hard to interoperate even within single AS or th= at definition of such things will take a spin outside of IETF via various f= orums, consortium, foundations etc ... Do we really all here endorse such d= irection ?=C2=A0

Have = a great weekend,
Robert.


On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 22/04/2017 08:09, Robert Raszuk wrote:=
> =E2=80=8BHi Ole,=E2=80=8B
>
>
>> That does in no way stop anyone from proposing _new_ work. Of any = sort.
>>
>> Best regards,
>> Ole
>>
>
> =E2=80=8BVery true ! Anyone can propose anything in IETF.
>
> But with the text additions which I have seen here recently the bar to= move
> from individual's draft proposal to WG doc then via all LCs to Sta= ndards
> Track RFC just went up significantly higher especially for SRH and EH<= br> > elements. =E2=80=8B
>
> And that's my point.

But *our* point, for some definition of 'our', is that by ma= king the
Internet-wide situation clear, we are in fact clearing the way for careful<= br> definition of local-use mechanisms. At the moment, as we've clearly see= n
from discussion of the SRH, we simply can't have that discussion becaus= e
of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicker
we get that settled and approved by the IESG, the quicker we can look
seriously at draft-voyer-6man-extension-header-insertion.

You might ask yourself why no IPv4 options have been defined since 2007
(Quick Start) and before that, 1997 (Router Alert). The same reason: they don't survive a trip across the Internet.

=C2=A0 =C2=A0 Brian


--001a113fe9c218a15c054dbc5151-- From nobody Sat Apr 22 05:24:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2FF1293D6 for ; Sat, 22 Apr 2017 05:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 T8MAMHjKPSQR for ; Sat, 22 Apr 2017 05:24:38 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE5712704A for <6man@ietf.org>; Sat, 22 Apr 2017 05:24:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=Xx5y//Tuk/bA7f9rkPOYXWkEVOwtSlq+NuJCi5bq4EgJhio+fadaI+dw2/vGYHq1yzQpaAHCk9EmdNUcWdDXomyyseXp1f7rANeCZsfIuxiaaTgeUg815/GSQ5+4Pgg4W7VT9GXrXZDywKO3Pgse/KmoyIs2gY3TdGvdD4vo+Qo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 25885 invoked from network); 22 Apr 2017 13:57:54 +0200 Received: from p5dec23d1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.35.209) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 Apr 2017 13:57:54 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_ECN_and_fragments_=28was_Re=3A_=5Btsvwg=5D_Mirja_?= =?utf-8?Q?K=C3=BChlewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_?= =?utf-8?Q?=28with_DISCUSS_and_COMMENT=29=29?= From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 22 Apr 2017 13:57:54 +0200 Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , 6man-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170422115754.25874.92735@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 12:24:39 -0000 Hi Suresh, thanks this text is fine for me.=20 I=E2=80=99d like propose three tiny editorial only changes/nits:=20 s/Other/Further,/ s/this basic/the basic/ s/sufficient. e.g./sufficient, e.g./ Only those headers in the Offset zero fragment packet are retained = in the reassembled packet. Further, fields in the IPv6 header may also vary across the fragments being reassembled. Specifications that use these fields may provide alternate instructions if the basic mechanism of using the values from the Offset zero fragment is not sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine the ECN bits from the different fragments to derive the ECN bits of the reassembled packet. And I would be even more happier if we could add a few more words to the = last sentence: ... e.g. Section 5.3 of [RFC3168] describes how to combine the ECN bits from the different fragments to derive the ECN bits of the reassembled packet such that no congestion indications are = lost. Thanks! Mirja > Am 21.04.2017 um 04:43 schrieb Suresh Krishnan = : >=20 > Hi Mirja/all, > Even though I like Bob's suggested text (with David's suggested > change), I would like to suggest an alternate formulation that is > generic (with ECN as an example) to see if it works. >=20 > OLD: > Only those headers in the Offset zero fragment packet are = retained in > the reassembled packet. >=20 > NEW: >=20 > Only those headers in the Offset zero fragment packet are = retained in > the reassembled packet. Other fields in the IPv6 header may also > vary across the fragments being reassembled. Specifications that > use these fields may provide alternate instructions if this basic > mechanism of using the values from the Offset zero fragment is = not > sufficient. e.g. Section 5.3 of [RFC3168] describes how to = combine > the ECN bits from the different fragments to derive the ECN bits = of > the reassembled packet. >=20 > I realize it is a bit verbose but I couldn't shorten it further. > Thoughts/suggestions? >=20 > Thanks > Suresh >=20 > On Wed, Apr 19, 2017 at 6:44 PM, Mirja Kuehlewind (IETF) > wrote: >> Hi, >>=20 >> I really don=E2=80=99t like the term "Nodes that support Explicit = Congestion Notification=E2=80=9C. I guess we understand something = different under =E2=80=9Esupport=E2=80=9C but maybe can just avoid that = word to avoid any confusion. >>=20 >> Thanks, >> Mirja >>=20 >>=20 >>> Am 19.04.2017 um 23:47 schrieb Suresh Krishnan = : >>>=20 >>> Hi Bob, >>>=20 >>> On Apr 19, 2017 5:16 PM, "Bob Hinden" wrote: >>> Mike, >>>=20 >>>> On Apr 19, 2017, at 10:54 AM, C. M. Heard wrote: >>>>=20 >>>> On Wed, Apr 19, 2017 at 10:25 AM, Mirja K=C3=BChlewind wrote: >>>>> This text does not make any normative statement on the question if = the >>>>> behavior specified in RFC3168 should be implemented or not. It = only says >>>>> please look at RFC3168 and make an informed decision if you want = to confirm >>>>> to the behavior that is specified in RFC3168 in addition to = implementing the >>>>> spec in this document. However, yes, this statement is true for = all IPv6 >>>>> implementation. I don't see a problem here... >>>>=20 >>>> Nor do I. As it happens I prefer the text proposed by Bob Hinden = (with >>>> David Black's modification) but I believe that the effect is = essentially the >>>> same as the text you proposed. So it seems that the discussion is = boiling >>>> down to editorial issues, and I am happy to leave that between you, >>>> the shepherd, and the document editor. >>>=20 >>> The current text I have is: >>>=20 >>> Nodes that support Explicit Congestion Notification = [RFC3168] >>> use information in the Traffic Class field from all fragment >>> packets to reconstruct the Traffic Class field in the >>> reassembled packet. See Section 5.3 of RFC3168 for more >>> information. >>>=20 >>>=20 >>> This looks good to me as well. My only concern with the previous = version was that it sounded normative. >>>=20 >>> Regards >>> Suresh >>>=20 >>=20 >=20 From nobody Sat Apr 22 07:31:01 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F23031205F1; Sat, 22 Apr 2017 07:30:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Kathleen Moriarty's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149287145298.25785.13911128954250289426.idtracker@ietfa.amsl.com> Date: Sat, 22 Apr 2017 07:30:52 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 14:30:53 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-6man-rfc2460bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for updating the Security Considerations section. From nobody Sat Apr 22 07:46:04 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F19912426E; Sat, 22 Apr 2017 07:45:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-6man-rfc2460bis@ietf.org, Ole Troan , 6man-chairs@ietf.org, otroan@employees.org, ipv6@ietf.org Subject: Kathleen Moriarty's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149287235711.25885.5896012496912146334.idtracker@ietfa.amsl.com> Date: Sat, 22 Apr 2017 07:45:57 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 14:45:57 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-6man-rfc2460bis-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for updating the Security Considerations section, I was glad to see the references added to the fragmentation work that had already been done. If the TLS and SSH reference remain in the document, references would be good - RFC7525 and RFC4250-4254, but my preference would be to delete the sentence as this document is about IPv6 and developers and implementers of this standard wouldn't need those references, IPsec is enough. From nobody Sat Apr 22 10:31:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37811294B9 for ; Sat, 22 Apr 2017 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x9vZDBH2meC for ; Sat, 22 Apr 2017 10:31:44 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 59DC81294FA for ; Sat, 22 Apr 2017 10:31:42 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id k11so17411963ywb.1 for ; Sat, 22 Apr 2017 10:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MKHSFLveM8/zk4D+J/ytUM0dvRuNeMjAVtS+QbNX53o=; b=2Nvetg9rw3c1jZOcNfHVc3wA4wOrVrQIhgAK0D53YTljh2G8eVsRUOSvqODco40dPb Jq9HSfvD95q5bZqX7qy+4UD2qUfSVbu+lCEp7aEmpgoa8jKBWEvh5g3wX+t+c9T0pXWJ ZGAdxdil17tQPwpOkre4Xexx0eD4gjsxC5G3xCz6zaw4jSEgGHxcQ0qF37tO33UAUFS+ hifqHthVjJ0J+akVGoK9aqkQ1YAouNbfBjxkarsT4ATbOr04S5VnPjNAhdGJq5Wmx/oa aHPMA3bF0KdLu3mRnRDd4PqlMXzxFOfO0enq/h6/5QCy4cuo+kZGrlR093m51gwcR2uE oktg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MKHSFLveM8/zk4D+J/ytUM0dvRuNeMjAVtS+QbNX53o=; b=Kv+xOodBjQQD18FaPiet1FJd8yGbnNZcXbDIOAeyeCn04i+ZbYQx2k6cvEd1m9tqKO 4dY4wnlrf70jzkca68YDi60IiveQcjHEuuLWXS4r4Lp1qRU3dqZpe7ZjGE6mgGJ5J0zs TEM9FAWmyPBWSpsvXJ592dPgCaut6g51cSugQ5sQrBu+5IcunM2T1E2+NgEzbsQFRVdD S18NEUbG9jSn8Fy+hHweWowttkyqDMshUduOkyrrsq/yg99BQwFZwUnk4bPQTaxI/VpA ivAQV1aEGkylE97Hlo9elQs2VN/0NrkhLBbeyQUq+W9CrVxxUOcLCZj8UIrUmmVf+9io R4tA== X-Gm-Message-State: AN3rC/5l4qIcVs0KrVIZ23O8NKcM8mZAygjtVXMYmqmeZ0kHKN3jMv/N 1IiUplSqDlX/Cn9CJjDC1zJ1ahc71g== X-Received: by 10.129.125.193 with SMTP id y184mr1771300ywc.120.1492882301572; Sat, 22 Apr 2017 10:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Sat, 22 Apr 2017 10:31:01 -0700 (PDT) In-Reply-To: <149287235711.25885.5896012496912146334.idtracker@ietfa.amsl.com> References: <149287235711.25885.5896012496912146334.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sat, 22 Apr 2017 13:31:01 -0400 Message-ID: Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT) To: Kathleen Moriarty Cc: The IESG , draft-ietf-6man-rfc2460bis@ietf.org, =?UTF-8?Q?Ole_Tr=C3=B8an?= , IPv6 List , 6man-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a11492bfc46ef30054dc4bf2e Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 17:31:46 -0000 --001a11492bfc46ef30054dc4bf2e Content-Type: text/plain; charset=UTF-8 Hmm... I think it would be good to point out that there are places to secure things other than IPsec (especially given that these, not IPsec, are the dominant methods for protecting traffic that goes over IPsec). However, if people feel strongly for some reason that naming the protocols causes problems, I can live without that. -Ekr On Sat, Apr 22, 2017 at 10:45 AM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-6man-rfc2460bis-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for updating the Security Considerations section, I was glad to > see the references added to the fragmentation work that had already been > done. If the TLS and SSH reference remain in the document, references > would be good - RFC7525 and RFC4250-4254, but my preference would be to > delete the sentence as this document is about IPv6 and developers and > implementers of this standard wouldn't need those references, IPsec is > enough. > > > --001a11492bfc46ef30054dc4bf2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm... I think it would be good to point out that there ar= e places to secure
things other than IPsec (especially given that these= , not IPsec, are the
dominant methods for protecting traffic that= goes over IPsec). However,
if people feel strongly for some reas= on that naming the protocols causes
problems, I can live without = that.

-Ekr


On Sat, Apr 22, 2017 at 10:45 A= M, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com&= gt; wrote:
Kathle= en Moriarty has entered the following ballot position for
draft-ietf-6man-rfc2460bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dr= aft-ietf-6man-rfc2460bis/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Thanks for updating the Security Considerations section, I was glad = to
see the references added to the fragmentation work that had already been done.=C2=A0 If the TLS and SSH reference remain in the document, references=
would be good - RFC7525 and RFC4250-4254, but my preference would be to
delete the sentence as this document is about IPv6 and developers and
implementers of this standard wouldn't need those references, IPsec is<= br> enough.



--001a11492bfc46ef30054dc4bf2e-- From nobody Sat Apr 22 13:47:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD88126CD8; Sat, 22 Apr 2017 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 IMCa_NydTo8T; Sat, 22 Apr 2017 13:47:39 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 3B87E1205D3; Sat, 22 Apr 2017 13:47:39 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id 193so6413570itm.1; Sat, 22 Apr 2017 13:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TgWml1kdnaMrraA1dPB3Udu/GApfWxLdLlrjtBv+3EU=; b=mOY1SrAMOIRQvxbncqvAh1XW1/w08m0q6MG3ZHmJLcYPKueb49fG9Q1yXznnZz4zgc MlAbu7u2hclWur5yRUbSTL1pY0UEVpekqKhowti++2LlfjpOEBd+J4Cnh+lDNvwPywww LwUuZLC9aNyJ5TwIG60V3snH0fFeTnvtcyPwWoNUf8YfUWG/v0F8NmeHRcNcu+jwKzc6 TRy2EH9Wyou0HyxiUt5pQScO6wqn1VbFUgw3qo5Wokko52dFfDktMS/yc1Bdfxtcngsj Nx7TFcm8r1XFfD4qq+43Dp5OB19uY6XTi9nFDfXsQq/kFVvuDip9C6xkDTCwhZYDIn4N Kvvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=TgWml1kdnaMrraA1dPB3Udu/GApfWxLdLlrjtBv+3EU=; b=CflauNjgEW/XCA5GVlw+i+X/Lsu6QL197U+tCE/+iSTm4gUCAIcnzkxpOK7KO6J8k8 DZ6+OCTGgbaQ62yq0+TL0LHBcDJavvqh6G2JbPNjwyF9G58bkR14c0JC9sCWt0eQG0IX H9yW0APcLALN+9KVUOyJ+xm57hM2KAee0kf+vE7jdmiplr8W5bfIGfRbcrYZuzj3f+kg BWUTUF6K0+hxfUFQqvvZ607xX8eZC3CpoCq6oqiOatLqtVs4A8oAzbIQOcOyAepoPa8+ WnOpcVxIRgJRuECEg16bWDOpxSDX/zX+fUtMOnkj+BW3QShYLvGSFSr08atvCVfPL1D6 dC4w== X-Gm-Message-State: AN3rC/64gzwPITi8pr2jI6aihr8VlfuaQ05BDCL3ZnBPIogvp/tmpueZ 4nU0BFrY5gY8kw== X-Received: by 10.99.2.84 with SMTP id 81mr8349003pgc.17.1492894058573; Sat, 22 Apr 2017 13:47:38 -0700 (PDT) Received: from ?IPv6:2406:e001:3e30:1:28cc:dc4c:9703:6781? ([2406:e001:3e30:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b8sm22953894pgn.51.2017.04.22.13.47.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Apr 2017 13:47:37 -0700 (PDT) Subject: =?UTF-8?Q?Across_the_Internet_[was_Mirja_K=c3=bchlewind's_Discuss_o?= =?UTF-8?Q?n_draft-ietf-6man-rfc2460bis-09:_=28with_DISCUSS_and_COMMENT=29]?= To: Robert Raszuk References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <60bf60a7-269b-03c2-21c2-a00d85a2c3c4@gmail.com> Cc: otroan@employees.org, draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , Fernando Gont , 6man-chairs@ietf.org, stefano previdi From: Brian E Carpenter Organization: University of Auckland Message-ID: <255625e9-fdc4-03e4-8d33-bd072d3246a5@gmail.com> Date: Sun, 23 Apr 2017 08:47:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 20:47:41 -0000 Robert, I think we're well off the main topic by now... On 22/04/2017 19:28, Robert Raszuk wrote: > Hi Brian, >=20 > In every other email I see a concern about "Internet" or "Internet-wide= " > behavior. >=20 > To me Internet is a collection of *independent* chain of Autonomous > Systems. As name indicates those domains are **autonomous** and can do > whatever they like to do with packets they carry. If they do not choose= to > do right things customers will avoid them, there will be no revenue and= > they will disappear from Internet map. Pure and simple. The trouble is, that doesn't work for second-order effects like dropping unknown IPv6 extension headers, IPv4 options or ICMP packets. The network= learns to avoid those features, rather than avoiding certain paths. > I find it very bizarre that IETF is trying to be a judge or policer to > dictate on what each AS can or can not do in their own network. We're not. We're simply saying PIPO (packet in =3D packet out), except fo= r any fields that are *explicitly* designed to change. > Moreover it > also apparently is putting least common denominator rule which states t= hat > all 50000 ASes should do MUST only be limited to what the weakest AS ca= n do > with either old or incapable vendors to support innovation. Yes, transmitting IP datagrams from source to destination is indeed the l= owest common denominator that the Internet requires. And that sets a limit on t= he external behaviour of every AS. > I was apparently very wrong assuming for all those years that IETF focu= s is > to make sure that protocol extensions we define are as best as we are > collectively able to do .. rather then community to worry what hardware= > vendors will manage to support or not support in what we define. I'm not sure I take your point. There's always been a tension between ide= al notions of protocol design and the capability of actual hardware. For example, your comment recently about how many bytes of the packet header are within reach of the hardware protocol engine. Are you saying we shoul= d design much larger headers regardless of that limitation? > So what will happen ... we will either have waves of proprietary featur= es > which will be hard to interoperate even within single AS or that defini= tion > of such things will take a spin outside of IETF via various forums, > consortium, foundations etc ... Do we really all here endorse such > direction ? No. The third way: set a base line for the lowest common denominator and then extend from there. That is what we're trying to do here. Regards Brian >=20 > Have a great weekend, > Robert. >=20 >=20 >=20 > On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 22/04/2017 08:09, Robert Raszuk wrote: >>> =E2=80=8BHi Ole,=E2=80=8B >>> >>> >>>> That does in no way stop anyone from proposing _new_ work. Of any so= rt. >>>> >>>> Best regards, >>>> Ole >>>> >>> >>> =E2=80=8BVery true ! Anyone can propose anything in IETF. >>> >>> But with the text additions which I have seen here recently the bar t= o >> move >>> from individual's draft proposal to WG doc then via all LCs to Standa= rds >>> Track RFC just went up significantly higher especially for SRH and EH= >>> elements. =E2=80=8B >>> >>> And that's my point. >> >> But *our* point, for some definition of 'our', is that by making the >> Internet-wide situation clear, we are in fact clearing the way for car= eful >> definition of local-use mechanisms. At the moment, as we've clearly se= en >> from discussion of the SRH, we simply can't have that discussion becau= se >> of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicke= r >> we get that settled and approved by the IESG, the quicker we can look >> seriously at draft-voyer-6man-extension-header-insertion. >> >> You might ask yourself why no IPv4 options have been defined since 200= 7 >> (Quick Start) and before that, 1997 (Router Alert). The same reason: t= hey >> don't survive a trip across the Internet. >> >> Brian >> >> >=20 From nobody Sat Apr 22 14:18:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3D126C7A; Sat, 22 Apr 2017 14:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Qm-hTW4rkCxQ; Sat, 22 Apr 2017 14:18:54 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 4169B1205D3; Sat, 22 Apr 2017 14:18:54 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id g66so20701441ite.1; Sat, 22 Apr 2017 14:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Eo0g9ULgoKKNesh8nretG7oCmmv91KH3gXLdB4f33Uc=; b=AKP9y3OB4gym1rwgW9dP2Xn5uJHtSEThJm/NNuWtYWXHVLpCrBzB+bc9mAHqJnkwhg u2saMlUVJdyGHzeKqkHROVEy9NXkLUUlKMRdknGlPclsFAU6jiXigmBoKmWhbUU1VLcM irW/BzSzkRvna6dO0U7czl3C8CfWXp7+nrYeGw+N8Vs7Uey7qiHWm8IS9flKIs5HYQf+ xUbUKY+P2mNzQR1uGq41EBPVPg7pL5bazAzIMcyiOicU16iCNPEx2ZhrjsK1/W6kvpUd fXbAxH2+P3Km/4SWLxPD6Bvh9f1bmhiVPdD94P1T+TI8R/coWqEgvhwqr2sWRg+hapMO CU+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Eo0g9ULgoKKNesh8nretG7oCmmv91KH3gXLdB4f33Uc=; b=mZbZCztrCzYfSAD21mIbtrTz8leWBQFq5h7P/F0nN0yHQ7pX2Fgu5fDJu2V693bDuP mmbzX/Tx2J1aTpdlklaJbR9r+OjnAtVehoAFp7fk6CZU0O8ovH8BR88kZtOGSLgjolry M83F4bZplIaxef+QomZ4+jWO6Fg2WG92fv/CpfmCzoMe0zQsdw9I2fnFEsVYuHxHyuVL uPj6WOjfyVrsRTo2DSaH+F9EjBWIBx3JHtpHMERKuee0pPWQwR7gYtJk2QbHAtwDC8i5 JTK+z12JBNxmGKwAQDTzC0vq8USzb07H/jL04EEXCaOCUI0r+KAPe6aNNEmE6qweYZDC B+JA== X-Gm-Message-State: AN3rC/52nBEJSeLd20gov09OTWo3Q3M2/KG9DW7tIavFCiA99TqetpVe blWn5TC3lWs/yNZ+MQrMzxxLXT6W7Q== X-Received: by 10.36.115.12 with SMTP id y12mr5803633itb.24.1492895933589; Sat, 22 Apr 2017 14:18:53 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.79.166.14 with HTTP; Sat, 22 Apr 2017 14:18:52 -0700 (PDT) In-Reply-To: <255625e9-fdc4-03e4-8d33-bd072d3246a5@gmail.com> References: <149201127005.15808.3277140025315157500.idtracker@ietfa.amsl.com> <90DFC565-B4E7-45E2-BE6A-0B67895E87F8@gmail.com> <5E28EF66-7BE1-4F11-88F3-6D928870A9FE@kuehlewind.net> <616cb74d-cc15-6c26-cb1d-612dfcddd353@gmail.com> <99E119A3-4BEA-4EE4-9DC1-7B434CAAE016@kuehlewind.net> <8EF4BCDA-ADB9-4EF4-A873-95CA67C6D7F3@employees.org> <8d127de1-a1b6-8406-c234-192fcbf01ad4@si6networks.com> <65C701D2-A0FF-40E5-B88D-E2E9C7260E02@gmail.com> <60bf60a7-269b-03c2-21c2-a00d85a2c3c4@gmail.com> <255625e9-fdc4-03e4-8d33-bd072d3246a5@gmail.com> From: Robert Raszuk Date: Sat, 22 Apr 2017 23:18:52 +0200 X-Google-Sender-Auth: 5eRKfwWo9YpzNzf0L3TUPGazWQg Message-ID: Subject: =?UTF-8?Q?Re=3A_Across_the_Internet_=5Bwas_Mirja_K=C3=BChlewind=27s_Disc?= =?UTF-8?Q?uss_on_draft=2Dietf=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUSS_and_COMM?= =?UTF-8?Q?ENT=29=5D?= To: Brian E Carpenter Cc: otroan@employees.org, draft-ietf-6man-rfc2460bis@ietf.org, 6man WG , Bob Hinden , Suresh Krishnan , "Mirja Kuehlewind (IETF)" , IESG , Fernando Gont , 6man-chairs@ietf.org, stefano previdi Content-Type: multipart/alternative; boundary=001a11444dcacef21b054dc7eb5e Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 21:18:57 -0000 --001a11444dcacef21b054dc7eb5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian, > For example, your comment recently about how many bytes of the packet > header are within reach of the hardware protocol engine. Are you saying > we should design much larger headers regardless of that limitation? We should be realistic. It is wise to enforce progressing the protocol extension only where there is implementation proving it. And that should be sufficient criteria of course assuming that the proposal is wise. So while I am not advocating XXL headers ... but even if someone comes with brilliant idea to have XXL header, but also in the same time documents and proves that any transit node in the end to end path needs to only read first N bytes of such header to claim full support of it I see no problem to standardize it. Just look at proposals which dynamically grow test packets at every node and do require very flexible data planes to add a lot of forwarding and control information on the fly at line rate during packet's forwarding depending on operator's or such packet src included set of required fields. Example: https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-00 Would that be included in the base line you are referring to ? Clearly very useful for my end to end Internet wide v6 transit ! Even more attractive if those probes would be SRv6 enabled Internet wide. //R. On Sat, Apr 22, 2017 at 10:47 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Robert, > > I think we're well off the main topic by now... > On 22/04/2017 19:28, Robert Raszuk wrote: > > Hi Brian, > > > > In every other email I see a concern about "Internet" or "Internet-wide= " > > behavior. > > > > To me Internet is a collection of *independent* chain of Autonomous > > Systems. As name indicates those domains are **autonomous** and can do > > whatever they like to do with packets they carry. If they do not choose > to > > do right things customers will avoid them, there will be no revenue and > > they will disappear from Internet map. Pure and simple. > > The trouble is, that doesn't work for second-order effects like dropping > unknown IPv6 extension headers, IPv4 options or ICMP packets. The network > learns to avoid those features, rather than avoiding certain paths. > > > I find it very bizarre that IETF is trying to be a judge or policer to > > dictate on what each AS can or can not do in their own network. > > We're not. We're simply saying PIPO (packet in =3D packet out), except fo= r > any fields that are *explicitly* designed to change. > > > Moreover it > > also apparently is putting least common denominator rule which states > that > > all 50000 ASes should do MUST only be limited to what the weakest AS ca= n > do > > with either old or incapable vendors to support innovation. > > Yes, transmitting IP datagrams from source to destination is indeed the > lowest > common denominator that the Internet requires. And that sets a limit on t= he > external behaviour of every AS. > > > I was apparently very wrong assuming for all those years that IETF focu= s > is > > to make sure that protocol extensions we define are as best as we are > > collectively able to do .. rather then community to worry what hardware > > vendors will manage to support or not support in what we define. > > I'm not sure I take your point. There's always been a tension between ide= al > notions of protocol design and the capability of actual hardware. For > example, your comment recently about how many bytes of the packet header > are within reach of the hardware protocol engine. Are you saying we shoul= d > design much larger headers regardless of that limitation? > > > So what will happen ... we will either have waves of proprietary featur= es > > which will be hard to interoperate even within single AS or that > definition > > of such things will take a spin outside of IETF via various forums, > > consortium, foundations etc ... Do we really all here endorse such > > direction ? > > No. The third way: set a base line for the lowest common denominator and > then extend from there. That is what we're trying to do here. > > Regards > Brian > > > > > Have a great weekend, > > Robert. > > > > > > > > On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 22/04/2017 08:09, Robert Raszuk wrote: > >>> =E2=80=8BHi Ole,=E2=80=8B > >>> > >>> > >>>> That does in no way stop anyone from proposing _new_ work. Of any > sort. > >>>> > >>>> Best regards, > >>>> Ole > >>>> > >>> > >>> =E2=80=8BVery true ! Anyone can propose anything in IETF. > >>> > >>> But with the text additions which I have seen here recently the bar t= o > >> move > >>> from individual's draft proposal to WG doc then via all LCs to > Standards > >>> Track RFC just went up significantly higher especially for SRH and EH > >>> elements. =E2=80=8B > >>> > >>> And that's my point. > >> > >> But *our* point, for some definition of 'our', is that by making the > >> Internet-wide situation clear, we are in fact clearing the way for > careful > >> definition of local-use mechanisms. At the moment, as we've clearly se= en > >> from discussion of the SRH, we simply can't have that discussion becau= se > >> of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicke= r > >> we get that settled and approved by the IESG, the quicker we can look > >> seriously at draft-voyer-6man-extension-header-insertion. > >> > >> You might ask yourself why no IPv4 options have been defined since 200= 7 > >> (Quick Start) and before that, 1997 (Router Alert). The same reason: > they > >> don't survive a trip across the Internet. > >> > >> Brian > >> > >> > > > > --001a11444dcacef21b054dc7eb5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

&= gt; For=C2=A0example, your comment recently about how many bytes of the packet=C2= =A0
> header=C2=A0are within reach of the hardware protocol = engine. Are you saying=C2=A0
> we should=C2=A0<= span style=3D"font-family:arial,sans-serif;font-size:12.8px">design much la= rger headers regardless of that limitation?

We should be realistic. It is wise to enforce progressing the= protocol extension=C2=A0
only where there is implementat= ion proving it. And that should be sufficient criteria=C2=A0
of course assuming that the proposal is wise.

So while I am not advocating XXL headers ... but even if so= meone comes with brilliant
idea to have XXL header, but= also in the same time documents and proves that any=C2=A0
transit node in the end to end=C2=A0path needs to only read first N bytes of su= ch header=C2=A0
to claim full support of it I see no=C2= =A0pro= blem to standardize it.=C2=A0

Just look at proposals which dynamically grow test packets at ever= y node and do =C2=A0
require very flexible data pla= nes to add a lot of forwarding and control information=C2=A0
on the fly at line rate during packet's forwarding depending = on operator's or such=C2=A0
packet src included= set of required fields.

Example:=C2=A0https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-= 00

Would that be i= ncluded in the base line you are referring to ?=C2=A0 Clearly very useful
for my end to end Internet wide v6 transit ! Even mo= re attractive if those probes=C2=A0
would be SRv6 e= nabled Internet wide.

= //R.


<= div class=3D"gmail_quote">On Sat, Apr 22, 2017 at 10:47 PM, Brian E Carpent= er <brian.e.carpenter@gmail.com> wrote:
Robert,

I think we're well off the main topic by now...
On 22/04/2017 19:28, Robert Raszuk wrote:
> Hi Brian,
>
> In every other email I see a concern about "Internet" or &qu= ot;Internet-wide"
> behavior.
>
> To me Internet is a collection of *independent* chain of Autonomous > Systems. As name indicates those domains are **autonomous** and can do=
> whatever they like to do with packets they carry. If they do not choos= e to
> do right things customers will avoid them, there will be no revenue an= d
> they will disappear from Internet map. Pure and simple.

The trouble is, that doesn't work for second-order effects like droppin= g
unknown IPv6 extension headers, IPv4 options or ICMP packets. The network learns to avoid those features, rather than avoiding certain paths.

> I find it very bizarre that IETF is trying to be a judge or policer to=
> dictate on what each AS can or can not do in their own network.

We're not. We're simply saying PIPO (packet in =3D packet out), exc= ept for
any fields that are *explicitly* designed to change.

> Moreover it
> also apparently is putting least common denominator rule which states = that
> all 50000 ASes should do MUST only be limited to what the weakest AS c= an do
> with either old or incapable vendors to support innovation.

Yes, transmitting IP datagrams from source to destination is indeed the low= est
common denominator that the Internet requires. And that sets a limit on the=
external behaviour of every AS.

> I was apparently very wrong assuming for all those years that IETF foc= us is
> to make sure that protocol extensions we define are as best as we are<= br> > collectively able to do .. rather then community to worry what hardwar= e
> vendors will manage to support or not support in what we define.

I'm not sure I take your point. There's always been a tension betwe= en ideal
notions of protocol design and the capability of actual hardware. For
example, your comment recently about how many bytes of the packet header are within reach of the hardware protocol engine. Are you saying we should<= br> design much larger headers regardless of that limitation?

> So what will happen ... we will either have waves of proprietary featu= res
> which will be hard to interoperate even within single AS or that defin= ition
> of such things will take a spin outside of IETF via various forums, > consortium, foundations etc ... Do we really all here endorse such
> direction ?

No. The third way: set a base line for the lowest common denominator and then extend from there. That is what we're trying to do here.

Regards
=C2=A0 =C2=A0 Brian

>
> Have a great weekend,
> Robert.
>
>
>
> On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> On 22/04/2017 08:09, Robert Raszuk wrote:
>>> =E2=80=8BHi Ole,=E2=80=8B
>>>
>>>
>>>> That does in no way stop anyone from proposing _new_ work.= Of any sort.
>>>>
>>>> Best regards,
>>>> Ole
>>>>
>>>
>>> =E2=80=8BVery true ! Anyone can propose anything in IETF.
>>>
>>> But with the text additions which I have seen here recently th= e bar to
>> move
>>> from individual's draft proposal to WG doc then via all LC= s to Standards
>>> Track RFC just went up significantly higher especially for SRH= and EH
>>> elements. =E2=80=8B
>>>
>>> And that's my point.
>>
>> But *our* point, for some definition of 'our', is that by = making the
>> Internet-wide situation clear, we are in fact clearing the way for= careful
>> definition of local-use mechanisms. At the moment, as we've cl= early seen
>> from discussion of the SRH, we simply can't have that discussi= on because
>> of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the qu= icker
>> we get that settled and approved by the IESG, the quicker we can l= ook
>> seriously at draft-voyer-6man-extension-header-insertion.
>>
>> You might ask yourself why no IPv4 options have been defined since= 2007
>> (Quick Start) and before that, 1997 (Router Alert). The same reaso= n: they
>> don't survive a trip across the Internet.
>>
>>=C2=A0 =C2=A0 =C2=A0Brian
>>
>>
>


--001a11444dcacef21b054dc7eb5e-- From nobody Sun Apr 23 20:19:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89373127A91; Sun, 23 Apr 2017 20:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 MJL4an4zYzHk; Sun, 23 Apr 2017 20:19:06 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 D8CF6126557; Sun, 23 Apr 2017 20:19:05 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id c45so103846353qtb.1; Sun, 23 Apr 2017 20:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PcnYF+gj6ozTARpAr060SiWxhTAXxrRvHNR9J5ZXjwE=; b=Se9shPAUhWWzO5xQ4Hztxr7IUWwnazBeM31frM+1bZpmC9UHY4S/CGGzZQu7a2yW8h evEDU+pzK0/25xpupxuSAFMdY4Q1m8638G4umffSvGufHFdjsgVNKvOngTxGvApaDS3s sAF5iaaVad9xLN4eTLRSudse1pO8jBCl0A1xy2k5h1TlGDX0OiLwUrUFbs4SOpdHelhq MlOlXoggSJi/ugxEHQxBh7HYQaCxzx8jqrpEkedxVVorPXg2/bEE/RcPLG0iW1S/Os2Y tC8iyeJFebZFWE7bIcxf3ci3g/ON7/JAd2VgWeLJSpoeHQ2HnTstp7C5xuiR3vA80HtL 9TeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PcnYF+gj6ozTARpAr060SiWxhTAXxrRvHNR9J5ZXjwE=; b=KEoCDIeXpsttaqKhP/doQwjVFsjpTUWts/59wdhMKjRsv5XYX7X0ZT2WHoxodP9dXI FyiPBZ2YngNCf2zPAjv6VZkr+NpTacDmD5NvPUJrUGiqKACrF8mzA8WKkywDO1uTx+95 ZV+LBNMjg8bgcB3fQrTeHYjGTkA25f7fdY+r+K5ahQV5fuVd530T7dOYAdgwKtbBsgVG RPBAqXwtVpwnTwHr322Ex5c1nKs9HYI/Pk27x64o6JeYuLGWcHiLGawkYHMLcrmjCrn+ YtpJZ1KCADxTa+0p0FD5KEowF8I7hqzdIEKqjGfT6knJi/kMLG2O9u/L9gEjl0uk5/A2 0BRA== X-Gm-Message-State: AN3rC/5rBRGfcH2vFd8ehGJS9bkqm9Bv9SBPQpxOr0APfucYTeqcFh2c CWxhdip2g9WWVIOEc1FvSR35v18SOg== X-Received: by 10.200.35.27 with SMTP id a27mr23280096qta.2.1493003944794; Sun, 23 Apr 2017 20:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.166.130 with HTTP; Sun, 23 Apr 2017 20:19:04 -0700 (PDT) In-Reply-To: <149287235711.25885.5896012496912146334.idtracker@ietfa.amsl.com> References: <149287235711.25885.5896012496912146334.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Sun, 23 Apr 2017 23:19:04 -0400 Message-ID: Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-6man-rfc2460bis-10: (with COMMENT) To: Kathleen Moriarty Cc: The IESG , draft-ietf-6man-rfc2460bis@ietf.org, =?UTF-8?Q?Ole_Tr=C3=B8an?= , IPv6 List , 6man-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 03:19:08 -0000 On Sat, Apr 22, 2017 at 10:45 AM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-6man-rfc2460bis-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for updating the Security Considerations section, I was glad to > see the references added to the fragmentation work that had already been > done. If the TLS and SSH reference remain in the document, references > would be good - RFC7525 and RFC4250-4254, but my preference would be to > delete the sentence as this document is about IPv6 and developers and > implementers of this standard wouldn't need those references, IPsec is > enough. Thanks for clearing Kathleen. I personally think that adding Informative references to RFC7525 and RFC4251 should be fine. Regards Suresh From nobody Sun Apr 23 20:31:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B98D126557; Sun, 23 Apr 2017 20:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 EEay_E0tOj_O; Sun, 23 Apr 2017 20:30:57 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 E70EB126DD9; Sun, 23 Apr 2017 20:30:56 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id c45so103954130qtb.1; Sun, 23 Apr 2017 20:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NMZ0R8BiOLkgJFIA2GeWAnAxmRbXZ4slGvzf04j3ZIs=; b=bT+E/s19CPyuRtAoS2KAfGc8VaebMGn/xy/H23H062Fky2jBLINpcWGStq+ANHUF9p mhIJ0nrdgRfBsH7urstmb+i3G10Gi75fd8oNV8VvNEF25MVKGth3WiywWGCGsSb+/g/L SQrSoGCjxkqYscOME8XwAXLyGBiT/G332wJ29Seu5Hxq5WA8ciM/DO0yktB1AICBoJrx FQpO5DyCGsy0vC4+ZwyyxvxKk56KhYrox6r2gmt8g56Spxn8GPAnjAN+O1rp7L7Zc7VX 7TlLhvQuzXG2sAx4cWRZryEnD/PxNF+3rAp4oexSeurFQ4B6Lv6OJJUKBLD7wzYo7YKB 3hug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NMZ0R8BiOLkgJFIA2GeWAnAxmRbXZ4slGvzf04j3ZIs=; b=sfnyiPpnVydRdfPsDiIo5c2G9kGyag9VyxtBMgaGmGIVMJveDfb5m0+k90IQ0MyJ8D /02AzpVaYD9yTZ5cWY1VS6/+AJZ5poHbOrV/XoT/sK60ZMMWafI7up1qtUwJHvDEUG/D ixA+N1WhgInh0m6DxRGAunJ3gOBGeNCp4y45TpiTuNnzLWrLJ+PwFNTFiJVLunfQvxw4 F/IjsDo2XXS0DYlUB8Mg9ELGasorV1Z+t1eHnZBtRuNvpx2/dm349m00/VYZXq/TSjii H9XPpV3cKkjaVhwmKrTPriAeoSL23TqHYCmyWHlYM5rlNtpC/K27pyNNYSItOKmiScLP ZaLw== X-Gm-Message-State: AN3rC/7YlkmmSEl3dtaONMgZ7jDzW50y8zgMajiM0NBIWkh1kR50Mbjm IEDIDW4b4IcbCUfogTi65KmZeCo7Hw== X-Received: by 10.200.37.16 with SMTP id 16mr25654315qtm.293.1493004655904; Sun, 23 Apr 2017 20:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.166.130 with HTTP; Sun, 23 Apr 2017 20:30:55 -0700 (PDT) In-Reply-To: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> References: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> From: Suresh Krishnan Date: Sun, 23 Apr 2017 23:30:55 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_ECN_and_fragments_=28was_Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlew?= =?UTF-8?Q?ind=27s_Discuss_on_draft=2Dietf=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUS?= =?UTF-8?Q?S_and_COMMENT=29=29?= To: "Mirja Kuehlewind (IETF)" Cc: "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , Bob Hinden , IESG , 6man-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 03:30:58 -0000 On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF) wrote: > Hi Suresh, > > thanks this text is fine for me. > > I=E2=80=99d like propose three tiny editorial only changes/nits: > s/Other/Further,/ > s/this basic/the basic/ > s/sufficient. e.g./sufficient, e.g./ Thanks Mirja. These edits all seem fine. > > Only those headers in the Offset zero fragment packet are retained i= n > the reassembled packet. Further, fields in the IPv6 header may also > vary across the fragments being reassembled. Specifications that > use these fields may provide alternate instructions if the basic > mechanism of using the values from the Offset zero fragment is not > sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine > the ECN bits from the different fragments to derive the ECN bits of > the reassembled packet. > > And I would be even more happier if we could add a few more words to the = last sentence: > > ... e.g. Section 5.3 of [RFC3168] describes how to combine > the ECN bits from the different fragments to derive the ECN bits of > the reassembled packet such that no congestion indications are lost. This is not strictly true. If any of the fragments carries the not-ECT codepoint, congestion indications will be lost (according to RFC3168), but my earlier proposed text still works. So if you don't care strongly about it, I would prefer keeping the old text. Regards Suresh From nobody Mon Apr 24 10:12:11 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2468B13189E; Mon, 24 Apr 2017 10:12:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org Subject: Genart telechat review of draft-ietf-6man-rfc1981bis-06 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149305392811.25808.15115824976388262628@ietfa.amsl.com> Date: Mon, 24 Apr 2017 10:12:08 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 17:12:08 -0000 Reviewer: Stewart Bryant Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-6man-rfc1981bis-?? Reviewer: Stewart Bryant Review Date: 2017-04-24 IETF LC End Date: 2017-03-01 IESG Telechat date: 2017-05-11 Summary: This is can be published as is, but I think could be improved. I thank the authors you for dealing with most of my comments in the previous round. There are two unaddressed points that the IETF Chair may wish to consider, and one that I missed. Major issues: The text has a lot of RFC2119 language, but no RFC2119 declaration. and the document seems inconsistent about when it uses RFC2119 language and when it does not. This sends a mixed messages to authors if we are not consistent on this point throughout the RFC Series. ======= 5.3. Purging stale PMTU information Internetwork topology is dynamic; routes change over time. While the local representation of a path may remain constant, the actual path(s) in use may change. Thus, PMTU information cached by a node can become stale. If the stale PMTU value is too large, this will be discovered almost immediately once a large enough packet is sent on the path. No such mechanism exists for realizing that a stale PMTU value is too small, so an implementation should "age" cached values. When a PMTU value has not been decreased for a while (on the order of 10 minutes), the PMTU estimate should be set to the MTU of the first-hop link, and the packetization layers should be notified of the change. This will cause the complete Path MTU Discovery process to take place again. SB> I still worry that the impact of this advice is going to be a disruption to what might SB> be a critical service every 10 mins, and wonder if there should be some advice along the SB> lines of noting the importance of service delivery as part of deciding whether to SB> test for bigger PMTU vs improving efficiency? Minor issues: A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. SB> I missed this last time. SB> SB> Presumably you mean "A node MUST NOT reduce its estimate of the SB> Path MTU below the IPv6 minimum link MTU in response to such SB> a message." SB> SB> Otherwise I would have thought that this was entirely a matter SB> for the host whether it wanted to use a Path MTU below the IPv6 SB> link minimum. Nothing breaks if the host takes a more conservative SB> decision. SB> Nits/editorial comments: None. From nobody Mon Apr 24 15:52:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BC4131443 for ; Mon, 24 Apr 2017 15:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 7vZ0sN5fRk9l for ; Mon, 24 Apr 2017 15:52:53 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 C0B5712706D for ; Mon, 24 Apr 2017 15:52:52 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id y33so126884089qta.2 for ; Mon, 24 Apr 2017 15:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=tLiimiduXqsd8p9aCF2kayOJHhsVaMSsr0WXFHLYKoQ=; b=Ywcf0N7exZRZ69+PMBSt279l7Nwwu9eixEFD9L+1Ff01Gz0hIVy1Xs1uDriGDnkv4q v9iEsXfrFg2tZHmVMpdNi1r6vGHcUZgHmbp5Kfapn08gLrmtvtyiAxRxuunL2dLWTld0 Qv1K9Sz+UXjNr6tCPDfUwIS28jZ/bXy7IRE7AO77MspFWZtmzr2DJW8Tb3A4HTLKRwhW f/mhBe1b2Wx+JSD0WJu6QE1k5Dc7YanFdVZS//OwHiJA5Tt6n3SdkBXP1lTIxvGpvYF9 /pfGBn4U1/hV1gOASK1wEff5SnhM0NFnTJyfyxG58g4WGwf/xBfh9VHVc+o4j66agoiS YEkA== 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:date:cc:to; bh=tLiimiduXqsd8p9aCF2kayOJHhsVaMSsr0WXFHLYKoQ=; b=GgLmgPtF5rCCU6K7gGI59N5A46D6twDLzoPb7OCc/H36YsOXRvyt/UeXVWu6EL84WP ytv3Y+dvyHv3CRZ1nwrg6mK+yAy+/88l5tigplKuOxcccta4BAXnnkFSYWlOc5lSReqW 3yy8/00iLaI8GGz1A/ON1F74+I0Zi/LC1WH9gfd1piXT3mRSiMoxxAC08m1yAtbOhWeh 7FIMPSW3fhvujq8/6eA/e/qWxI5XhaXxB5/Qmg8cIk5bfTA6AMd/RgifyyPXmDTQbrE6 bAXeJEXYJXnFhsRzFXD/E9OV6QHQU8PRJpj8C51DyN8jSg1qCPXyrrHTdJm+jFuyHqn6 qJgw== X-Gm-Message-State: AN3rC/6ZO5s/wAdHJXOjuJEBb0hBMZ86LPGWCDbAHUIqtQ6ZH4oTW1HD nm4BtLEdU414B0oFXUs= X-Received: by 10.237.37.106 with SMTP id w39mr30663345qtc.14.1493074371636; Mon, 24 Apr 2017 15:52:51 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id o41sm13940357qto.3.2017.04.24.15.52.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 15:52:49 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_274C8DA2-BD43-4E4E-9DC0-B61A1562C39C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Proposed revised Extension Header text for rfc2460bis Message-Id: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> Date: Mon, 24 Apr 2017 15:52:47 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:52:55 -0000 --Apple-Mail=_274C8DA2-BD43-4E4E-9DC0-B61A1562C39C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, After reading through the discussion about this text in Section 4, I = have some new text to propose. I think this is significantly improved = and should resolve many of the issued raised. Changes include separate description of behaviors extension headers and = the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from the = first paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am = convinced it=E2=80=99s not sustainable to say a node can=E2=80=99t = examine extension given how widespread this behavior is. I also removed = the reference to RFC7045 because examine is removed. RFC7045 is = referenced in the recently updated Security Considerations section. I removed the =E2=80=9Cincluding the source and destination nodes=E2=80=9D= text from the paragraph on the hop-by-hop options header because I = don=E2=80=99t think we need to mention the source, and there is a whole = paragraph describe what happens at the destination node. I also added = the text about from the first paragraph about reaching the destination = to the hop-by-hop header paragraph. I also moved (without change) the =E2=80=9CAt the Destination node...=E2=80= =9D text from the first paragraph to a new third paragraph. It applies = to all extension headers. CURRENT and NEW text below. Please review and comment. Bob CURRENT With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of [RFC7045]. At the Destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NEW Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header is not inserted or deleted, but may be examined and processed by every node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. At the Destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. END NEW --Apple-Mail=_274C8DA2-BD43-4E4E-9DC0-B61A1562C39C 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY/oG/AAoJEK7rdBF357uoDEYH/0lkbOTCn15WbL93WCZZASKN 6lCB2PZZLNNyDKbemdiSxdV5XsrILmIWfCrbHXGFNkPmmhzsOFIDaGFrckehJKGm UoSnbElZAIQR7dgOxjdvzPbYToaQ2uLpcMGU8krMLhFjBG7c/5+4PLu6aOBoo8ts FrXq+VoqkKMqduLYR6mSFDzFl22PGczOWTU4wKG5L0PVS8rds//tK65KjClAznxA 6g4nOPsRssmneLpZCTqNtcS5rYM2yHmaQVQNIn2L36YrKxPY7aIeivHJes0ODOtb SAoo/HPcUb5gctQGSAfPgSWkergxgiTkD9VZ5/iGjtSMFIeQbNHHCKutFKiPYpc= =cLhv -----END PGP SIGNATURE----- --Apple-Mail=_274C8DA2-BD43-4E4E-9DC0-B61A1562C39C-- From nobody Mon Apr 24 16:16:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5639E131961 for ; Mon, 24 Apr 2017 16:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2CIb9QcfrTq for ; Mon, 24 Apr 2017 16:16:02 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 4208313195F for ; Mon, 24 Apr 2017 16:16:02 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id h123so45893176qke.0 for ; Mon, 24 Apr 2017 16:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wst80a1ty5IPMQzebIZWmLlGHChytVr9bix6sUo5YiU=; b=iKSzxfPyNj4np8DLSiiRvLxjpR/S8t+oMZq+d7fANThfyzxbDCTdYMm7T4B/et+V8P 2T28r4S1/TJ0NSd88bDjD68Djf2hd4X8e1AKlFGrDN3MdEqmT0yIYX2yQGKpnnPJksoY 7k3vtGVEI+PdbfihPACZicmWIVIi6APIls1KLBTIGcB6tsa7V8a76I8z4QOpbR4SGhOb IQ0nI9r8EswOsYPQvBwe1XQWZoDZeJmPH2tVEwoGpXUzhJUGPzD5w/MfXTNhSXqRpMEN k7mbW6nAUx1YrRKFe5uFXkz/ZOw+WujfrP1nK+fCTOY7Sx7OOndTD++4Krj/B6bT3SiX hYtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wst80a1ty5IPMQzebIZWmLlGHChytVr9bix6sUo5YiU=; b=e0y2Tp6/kpZso6JxMiCcMA58VzsHaGmO6yLgZsp720rbxVkaJACC24sNqI5Sm04MCE ESLDGLv5eNA04dil9gqk2630UqNJQ5hhTbgt08eumxVJF/udgm8TCA0qrhRqO/LQW6lv qmog0tmzcOtCUMLiHHuNdpYz7J1f2NOFjlCjhotK30J7RRlGAtqrDKXqdD8shH7lXR14 Cj8j9igPTTZvk8IiMouwUK8tFAIqkPLsL+cOj6p1syVZu6BLjBjCiCPWhQDQyKgONtXD AtU5jUpedCpJSeXiWkIYYiuHnUCx8H6qQ1JOApoWdXSByPRqvL+qOwTNbgew3rsTaClU lsnQ== X-Gm-Message-State: AN3rC/49obevJWYLfGmndJ3+ABLBQnGFE64quJ99qfxTdwfFEt8IZSEf vHx8avNq7tg4odldgdJpdDJwf6/HwA== X-Received: by 10.55.197.92 with SMTP id p89mr25763195qki.34.1493075761330; Mon, 24 Apr 2017 16:16:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Mon, 24 Apr 2017 16:16:00 -0700 (PDT) In-Reply-To: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> From: Tom Herbert Date: Mon, 24 Apr 2017 16:16:00 -0700 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Bob Hinden Cc: IPv6 List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:16:04 -0000 On Mon, Apr 24, 2017 at 3:52 PM, Bob Hinden wrote: > Hi, > > After reading through the discussion about this text in Section 4, I have= some new text to propose. I think this is significantly improved and shou= ld resolve many of the issued raised. > > Changes include separate description of behaviors extension headers and t= he hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from the firs= t paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am convinced it= =E2=80=99s not sustainable to say a node can=E2=80=99t examine extension gi= ven how widespread this behavior is. I also removed the reference to RFC70= 45 because examine is removed. RFC7045 is referenced in the recently updat= ed Security Considerations section. > > I removed the =E2=80=9Cincluding the source and destination nodes=E2=80= =9D text from the paragraph on the hop-by-hop options header because I don= =E2=80=99t think we need to mention the source, and there is a whole paragr= aph describe what happens at the destination node. I also added the text a= bout from the first paragraph about reaching the destination to the hop-by-= hop header paragraph. > > I also moved (without change) the =E2=80=9CAt the Destination node...=E2= =80=9D text from the first paragraph to a new third paragraph. It applies = to all extension headers. > > CURRENT and NEW text below. Please review and comment. > > Bob > > > CURRENT > > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. Note: If an intermediate forwarding node examines > an extension header for any reason, it must do so in accordance with > the provisions of [RFC7045]. At the Destination node, normal > demultiplexing on the Next Header field of the IPv6 header invokes > the module to process the first extension header, or the upper-layer > header if no extension header is present. The contents and semantics > of each extension header determine whether or not to proceed to the > next header. Therefore, extension headers must be processed strictly > in the order they appear in the packet; a receiver must not, for > example, scan through a packet looking for a particular kind of > extension header and process that header prior to processing all > preceding ones. > > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by every node along a packet's delivery path, including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. > > NEW > > Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header. > > The Hop-by-Hop Options header is not inserted or deleted, but may be > examined and processed by every node along a packet's delivery path, Hi Bob, I would suggest this to substitute "any" for "every" and "and" for "or" to= get: "The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path," Tom > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. The Hop-by-Hop Options header, when present, must > immediately follow the IPv6 header. Its presence is indicated by the > value zero in the Next Header field of the IPv6 header. > > At the Destination node, normal demultiplexing on the Next Header > field of the IPv6 header invokes the module to process the first > extension header, or the upper-layer header if no extension header is > present. The contents and semantics of each extension header > determine whether or not to proceed to the next header. Therefore, > extension headers must be processed strictly in the order they appear > in the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and process > that header prior to processing all preceding ones. > > END NEW > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Apr 24 16:19:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E23131963 for ; Mon, 24 Apr 2017 16:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 AOZKo0PDZldo for ; Mon, 24 Apr 2017 16:19:26 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 91EDF13195F for ; Mon, 24 Apr 2017 16:19:26 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id h123so45940548qke.0 for ; Mon, 24 Apr 2017 16:19:26 -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=7Uw3SpA+xErVFGotsDyb7aoGgEWRvTz7JCx5xgzR7jo=; b=cDQNk8s/tEaTKci0uWxN1w3+ijnAgVkgIZieR/MJUk7D6sZUIpLPhzqXsVwalfYWKo Sh3/M9x3BHxSLdQpPpUltTbp7RRVuU4AYaEg2GGdbSnO6inctpd9eP5uM3yIY+msDIzA E22sw7LXTr62fohCAdnEJYpaQhq4KxBg8qdL3vC9dONijYzsMknVWt4E5zB7kKU+4chq jnk9kSMk1Ls2+v2L8kJpBhKFDAIfDckU5QJYKUSy1Z7wM2/3SGNCPesUbWaGyjtE0r3r j0GjzHbmhZlfwPbRTKccp3cHSn/IVvxz4nWwLb9ADOeesy/YGFVRa8iYfGGayBjzGGYH /+pw== 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=7Uw3SpA+xErVFGotsDyb7aoGgEWRvTz7JCx5xgzR7jo=; b=DnnTBtyPqJ10QEwJbSCPO6WD2LkJ6zDukfP2kDZkZN5ifqKsJpsL1FJtxjpSAL7E7o UjBPY3rSSB4KmwBtfL4tZYFpzCelq4boLO1XUXMG4cYQU1nfwepL4qvF85iPP7SyOVU5 vpUt6XZgy1CMgg34VcIx4mBerdgLJLE0w0t+VnCVff6E+wAkGFgcLubB6tIG/h64S2Ac oNix8bMa3k6GuzkqBEOO7fos89tVadhOWSltucuxakxCrVTxYlUHgJLQftkqwthLZDVx m7xjoVKYsGBKEc8S4OsI0U7ynNH8RzHZcHRnE1GOGsayrhbWMaltBuZgKTWQpJg7bQM4 rnAQ== X-Gm-Message-State: AN3rC/4xi+OWxUNE+3osXCJZyHB01Dr3NzL/eVxlwc6n/fIrq6lEs2HU KKM9Ay1IFeZDtw== X-Received: by 10.55.68.80 with SMTP id r77mr29760494qka.201.1493075965670; Mon, 24 Apr 2017 16:19:25 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d9sm13900787qte.0.2017.04.24.16.19.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 16:19:24 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_22E4BC13-3F09-48BA-884C-1C70E9D22C01"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Proposed revised Extension Header text for rfc2460bis Date: Mon, 24 Apr 2017 16:19:22 -0700 In-Reply-To: Cc: Bob Hinden , IPv6 List To: Tom Herbert References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:19:28 -0000 --Apple-Mail=_22E4BC13-3F09-48BA-884C-1C70E9D22C01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, > On Apr 24, 2017, at 4:16 PM, Tom Herbert wrote: >=20 > On Mon, Apr 24, 2017 at 3:52 PM, Bob Hinden = wrote: >> Hi, >>=20 >> After reading through the discussion about this text in Section 4, I = have some new text to propose. I think this is significantly improved = and should resolve many of the issued raised. >>=20 >> Changes include separate description of behaviors extension headers = and the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from = the first paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am = convinced it=E2=80=99s not sustainable to say a node can=E2=80=99t = examine extension given how widespread this behavior is. I also removed = the reference to RFC7045 because examine is removed. RFC7045 is = referenced in the recently updated Security Considerations section. >>=20 >> I removed the =E2=80=9Cincluding the source and destination nodes=E2=80= =9D text from the paragraph on the hop-by-hop options header because I = don=E2=80=99t think we need to mention the source, and there is a whole = paragraph describe what happens at the destination node. I also added = the text about from the first paragraph about reaching the destination = to the hop-by-hop header paragraph. >>=20 >> I also moved (without change) the =E2=80=9CAt the Destination = node...=E2=80=9D text from the first paragraph to a new third paragraph. = It applies to all extension headers. >>=20 >> CURRENT and NEW text below. Please review and comment. >>=20 >> Bob >>=20 >>=20 >> CURRENT >>=20 >> With one exception, extension headers are not examined, processed, >> inserted, or deleted by any node along a packet's delivery path, >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field = of >> the IPv6 header. Note: If an intermediate forwarding node examines >> an extension header for any reason, it must do so in accordance = with >> the provisions of [RFC7045]. At the Destination node, normal >> demultiplexing on the Next Header field of the IPv6 header invokes >> the module to process the first extension header, or the = upper-layer >> header if no extension header is present. The contents and = semantics >> of each extension header determine whether or not to proceed to the >> next header. Therefore, extension headers must be processed = strictly >> in the order they appear in the packet; a receiver must not, for >> example, scan through a packet looking for a particular kind of >> extension header and process that header prior to processing all >> preceding ones. >>=20 >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by every node along a packet's delivery path, = including >> the source and destination nodes. The Hop-by-Hop Options header, >> when present, must immediately follow the IPv6 header. Its = presence >> is indicated by the value zero in the Next Header field of the IPv6 >> header. >>=20 >> NEW >>=20 >> Extension headers (except for the Hop-by-Hop Options header) are = not >> processed, inserted, or deleted by any node along a packet's = delivery >> path, until the packet reaches the node (or each of the set of = nodes, >> in the case of multicast) identified in the Destination Address = field >> of the IPv6 header. >>=20 >> The Hop-by-Hop Options header is not inserted or deleted, but may = be >> examined and processed by every node along a packet's delivery = path, >=20 > Hi Bob, >=20 > I would suggest this to substitute "any" for "every" and "and" for = "or" to get: >=20 > "The Hop-by-Hop Options header is not inserted or deleted, but may be > examined or processed by any node along a packet's delivery path,=E2=80=9D= I agree, that is better. Thanks, Bob >=20 > Tom >=20 >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field = of >> the IPv6 header. The Hop-by-Hop Options header, when present, must >> immediately follow the IPv6 header. Its presence is indicated by = the >> value zero in the Next Header field of the IPv6 header. >>=20 >> At the Destination node, normal demultiplexing on the Next Header >> field of the IPv6 header invokes the module to process the first >> extension header, or the upper-layer header if no extension header = is >> present. The contents and semantics of each extension header >> determine whether or not to proceed to the next header. Therefore, >> extension headers must be processed strictly in the order they = appear >> in the packet; a receiver must not, for example, scan through a >> packet looking for a particular kind of extension header and = process >> that header prior to processing all preceding ones. >>=20 >> END NEW >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 --Apple-Mail=_22E4BC13-3F09-48BA-884C-1C70E9D22C01 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY/of7AAoJEK7rdBF357uo+aEIAIVHpVjYclMIPOg8ZYzW5k6y +vfCKw2OsMkBeVv4GJyl44+eLUj3nruiZdPgADaPvDADrf/HiGQ3dZe7Hz4R77Yn 17HZH7UmMDhMCIA0QfmTfUiVAHaxqYsbM27gsMwEMoPijzehMfHsV7RQy1pLGGOM 8Jxtf7SX7ziM3uPvsLU+TMZbd1PikGY2ttqOkeB3gmITepoJbZG+Aw3SoevUCe5M oQkux8wHraY0qadBsaHuAizI7uhaZy3z2uEPVWsrM2d7IO30FUc4ThXzmbAUoGP4 QFFwpjY3L8CZ7yg0Hj9auzROXKso9rh5mmVDokCf/E0+KUiW3sV6kJnSKh4sPEI= =sD8m -----END PGP SIGNATURE----- --Apple-Mail=_22E4BC13-3F09-48BA-884C-1C70E9D22C01-- From nobody Mon Apr 24 16:22:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623DE13195A for ; Mon, 24 Apr 2017 16:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 jhn3C32cjx-x for ; Mon, 24 Apr 2017 16:22:37 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 4F3E313192A for ; Mon, 24 Apr 2017 16:22:37 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id c198so18407658pfc.1 for ; Mon, 24 Apr 2017 16:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=EqFW2sJzId6H6tsiUl1VDKcUgmrhERJl+8V432A91CE=; b=LoTjelwitZhnldBdePk85/AuM5vZ6BU0L+Sgpbn+3J5ITaa96lx+qoNYFl1z+XsLS3 KzdpEI6rguta+HJx1tMCisl4alMzD9SwOz38IA+2FaIjM6CMQ7zvl5bLkFUvxxlaV1wk jp+Qhy1P/M6zRWvH1AI5tlqWlsXqquBv8H2M6rmd0Og71FNp9DXInCr2AhI+jNu9Ft0g ochDsYl79XtkfWjtDSR6sWUX249+MktD9zDx+wn9lUBZew0blUNOU9PfCKit2HkIOLxT JE+9+HB9IglkuZ9jao4NDzA/urlrfcNqyeWyKgEZeu+Elpb1i0hLcw6mnSME5sgA7ndY KXIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=EqFW2sJzId6H6tsiUl1VDKcUgmrhERJl+8V432A91CE=; b=I2QdrMvcpPAFtSn62vrU/ax2mo9ecOo1nmXW2vD30pNgkjRw2bKubsIE7pinzNNRcO RJ5MWzAmedQ1bocS9BUDPCO8yfHdkNPiNl0+Dp8VGxkzXFdTRl/B//b6uLUWUqaQMrZq kBgw5yGQBN+BguMGsmgo0sTjNiCtvfYjbvmvE9tOQakuytkuGaqJShPdOFwhhqd3JMSh P2bMYtJToYJsx6tvL0hsqkBtbffNql5FzVV/dzzgIKp8Qj4NafCWCC5q0kSZvoOBU1e/ dSXdrZ+8Tis9DgMxsIfRGVvsj2LkMKzRmjk7ZDXSqZ41bNLXRxRt8XOLOh/8UrwebSIo lyzQ== X-Gm-Message-State: AN3rC/7rCO0Q2okp6avoy5DvVGZkpqnEaNZRW4vTfWYdMFSD0JWqTVL6 ZIkWj3N438Q/qUXG X-Received: by 10.84.142.133 with SMTP id 5mr35676831plx.129.1493076156709; Mon, 24 Apr 2017 16:22:36 -0700 (PDT) Received: from [192.168.178.21] ([118.149.108.178]) by smtp.gmail.com with ESMTPSA id d187sm32492210pfd.47.2017.04.24.16.22.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 16:22:35 -0700 (PDT) Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Bob Hinden , IPv6 List References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <514cc626-03bc-bff3-1bb4-c128214a0882@gmail.com> Date: Tue, 25 Apr 2017 11:22:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:22:39 -0000 This works for me and seems to combine the WG rough consensus with the IE= SG comments. Regards Brian Carpenter On 25/04/2017 10:52, Bob Hinden wrote: > Hi, >=20 > After reading through the discussion about this text in Section 4, I ha= ve some new text to propose. I think this is significantly improved and = should resolve many of the issued raised. >=20 > Changes include separate description of behaviors extension headers and= the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from the = first paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am convin= ced it=E2=80=99s not sustainable to say a node can=E2=80=99t examine exte= nsion given how widespread this behavior is. I also removed the referenc= e to RFC7045 because examine is removed. RFC7045 is referenced in the re= cently updated Security Considerations section. >=20 > I removed the =E2=80=9Cincluding the source and destination nodes=E2=80= =9D text from the paragraph on the hop-by-hop options header because I do= n=E2=80=99t think we need to mention the source, and there is a whole par= agraph describe what happens at the destination node. I also added the t= ext about from the first paragraph about reaching the destination to the = hop-by-hop header paragraph. >=20 > I also moved (without change) the =E2=80=9CAt the Destination node...=E2= =80=9D text from the first paragraph to a new third paragraph. It applie= s to all extension headers. >=20 > CURRENT and NEW text below. Please review and comment. >=20 > Bob >=20 >=20 > CURRENT >=20 > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field o= f > the IPv6 header. Note: If an intermediate forwarding node examines > an extension header for any reason, it must do so in accordance with= > the provisions of [RFC7045]. At the Destination node, normal > demultiplexing on the Next Header field of the IPv6 header invokes > the module to process the first extension header, or the upper-layer= > header if no extension header is present. The contents and semantic= s > of each extension header determine whether or not to proceed to the > next header. Therefore, extension headers must be processed strictl= y > in the order they appear in the packet; a receiver must not, for > example, scan through a packet looking for a particular kind of > extension header and process that header prior to processing all > preceding ones. >=20 > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by every node along a packet's delivery path, includin= g > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence= > is indicated by the value zero in the Next Header field of the IPv6 > header. >=20 > NEW >=20 > Extension headers (except for the Hop-by-Hop Options header) are not= > processed, inserted, or deleted by any node along a packet's deliver= y > path, until the packet reaches the node (or each of the set of nodes= , > in the case of multicast) identified in the Destination Address fiel= d > of the IPv6 header. >=20 > The Hop-by-Hop Options header is not inserted or deleted, but may be= > examined and processed by every node along a packet's delivery path,= > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field o= f > the IPv6 header. The Hop-by-Hop Options header, when present, must > immediately follow the IPv6 header. Its presence is indicated by th= e > value zero in the Next Header field of the IPv6 header. >=20 > At the Destination node, normal demultiplexing on the Next Header > field of the IPv6 header invokes the module to process the first > extension header, or the upper-layer header if no extension header i= s > present. The contents and semantics of each extension header > determine whether or not to proceed to the next header. Therefore, > extension headers must be processed strictly in the order they appea= r > in the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and process= > that header prior to processing all preceding ones. >=20 > END NEW >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Apr 25 03:19:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DFA12EB0A for ; Tue, 25 Apr 2017 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ISPgmuXbzlQL for ; Tue, 25 Apr 2017 03:19:14 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 B656712EB05 for ; Tue, 25 Apr 2017 03:19:13 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id h2so128785228uaa.1 for ; Tue, 25 Apr 2017 03:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2BMxylftVtB3u/+S12Cq3utMrqFEcDGIU+3UyGO1EEo=; b=VVzNq/JvKd2+0o8+Qjr27q9rJzNurJco1nLMLxwsdycHOOvJJENonPYmyadqV0hUX9 bP9GjMKim+JlBduRjgZoDtkfLkccOK4jQKeYTrJTsh9o2wvjEL9WY8sEXJb8h+OyMZS5 FFxtiR8SLHYeeLiUSvjmpXmdBaAnTwJlJ/0tdUd5ZE0TVdopVLOg3HDr96LKC2BN1AGU P3tMTyTojnk5SVsu5Ip8FwsYIfTv+uYQ6fiZ23afi4jFpEZLOUBtum9H2wPmSz2uhP92 CULEqcAsrmqgHInZpD5v6P+jpZPR8w3QJzAzFCP37bzhYPvit6KhZzNeJsz4GGkP/0cp 9YMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2BMxylftVtB3u/+S12Cq3utMrqFEcDGIU+3UyGO1EEo=; b=dUQUJNcvNicQIYLad6ixYhECfPUOK780+d8XcSbK1VhOaebonZ3Zm49jrBJCKj36jM JOXIuAOA9tKdlghmvN01CENRa5Vl2ACfHpEmXIjs9fPVX+qhMfpyKfAxYl65TB9uUBDR HzAPBouutKA4gUEKT6eR/8XhHPc0PDsEY5dDYAh0W5IP8DjpwxY7AkP91ddrY6CSagwL gQ3cDjg8fbDEDJrAHxDxHLj7h3sYJO2rcbM7spU8pn9fM+VOtBxkMzQgPqludG6Q94F1 mZiKjT+ikjZqj0q3oKmwQHtbTrLSFqyLphUh8JIq1AuWakVMs1KVnsQbGSqCAJ7AEayk t2Vw== X-Gm-Message-State: AN3rC/4XEG8luF1FFzPMXhndB8sdmpZEe1+SQiFSBp5nQNRV3hJFacLO FAb1tzGnke08OVZiXGR5fGaLi/ffaw== X-Received: by 10.176.93.207 with SMTP id l15mr14759621uag.19.1493115552588; Tue, 25 Apr 2017 03:19:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.55.130 with HTTP; Tue, 25 Apr 2017 03:19:11 -0700 (PDT) Received: by 10.159.55.130 with HTTP; Tue, 25 Apr 2017 03:19:11 -0700 (PDT) In-Reply-To: <514cc626-03bc-bff3-1bb4-c128214a0882@gmail.com> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <514cc626-03bc-bff3-1bb4-c128214a0882@gmail.com> From: Mark Smith Date: Tue, 25 Apr 2017 20:19:11 +1000 Message-ID: Subject: Re: Proposed revised Extension Header text for rfc2460bis To: Brian E Carpenter Cc: 6man WG , Bob Hinden Content-Type: multipart/alternative; boundary=f403043ee3bc1ee80a054dfb0e8a Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 10:19:16 -0000 --f403043ee3bc1ee80a054dfb0e8a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm happy with it too, and agree that Tom's suggested changes make it better. Regards, Mark. On 25 Apr. 2017 09:22, "Brian E Carpenter" wrote: This works for me and seems to combine the WG rough consensus with the IESG comments. Regards Brian Carpenter On 25/04/2017 10:52, Bob Hinden wrote: > Hi, > > After reading through the discussion about this text in Section 4, I have some new text to propose. I think this is significantly improved and should resolve many of the issued raised. > > Changes include separate description of behaviors extension headers and the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from the fir= st paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am convinced it=E2=80=99s not s= ustainable to say a node can=E2=80=99t examine extension given how widespread this behavior is. I a= lso removed the reference to RFC7045 because examine is removed. RFC7045 is referenced in the recently updated Security Considerations section. > > I removed the =E2=80=9Cincluding the source and destination nodes=E2=80= =9D text from the paragraph on the hop-by-hop options header because I don=E2=80=99t think we= need to mention the source, and there is a whole paragraph describe what happens at the destination node. I also added the text about from the first paragraph about reaching the destination to the hop-by-hop header paragraph. > > I also moved (without change) the =E2=80=9CAt the Destination node...=E2= =80=9D text from the first paragraph to a new third paragraph. It applies to all extension headers. > > CURRENT and NEW text below. Please review and comment. > > Bob > > > CURRENT > > With one exception, extension headers are not examined, processed, > inserted, or deleted by any node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. Note: If an intermediate forwarding node examines > an extension header for any reason, it must do so in accordance with > the provisions of [RFC7045]. At the Destination node, normal > demultiplexing on the Next Header field of the IPv6 header invokes > the module to process the first extension header, or the upper-layer > header if no extension header is present. The contents and semantics > of each extension header determine whether or not to proceed to the > next header. Therefore, extension headers must be processed strictly > in the order they appear in the packet; a receiver must not, for > example, scan through a packet looking for a particular kind of > extension header and process that header prior to processing all > preceding ones. > > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that may be examined > and processed by every node along a packet's delivery path, including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. > > NEW > > Extension headers (except for the Hop-by-Hop Options header) are not > processed, inserted, or deleted by any node along a packet's delivery > path, until the packet reaches the node (or each of the set of nodes, > in the case of multicast) identified in the Destination Address field > of the IPv6 header. > > The Hop-by-Hop Options header is not inserted or deleted, but may be > examined and processed by every node along a packet's delivery path, > until the packet reaches the node (or each of the set of nodes, in > the case of multicast) identified in the Destination Address field of > the IPv6 header. The Hop-by-Hop Options header, when present, must > immediately follow the IPv6 header. Its presence is indicated by the > value zero in the Next Header field of the IPv6 header. > > At the Destination node, normal demultiplexing on the Next Header > field of the IPv6 header invokes the module to process the first > extension header, or the upper-layer header if no extension header is > present. The contents and semantics of each extension header > determine whether or not to proceed to the next header. Therefore, > extension headers must be processed strictly in the order they appear > in the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and process > that header prior to processing all preceding ones. > > END NEW > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f403043ee3bc1ee80a054dfb0e8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm happy with it too, and agree that Tom's = suggested changes make it better.

Regards,
Mark.

On 25 Apr. 2017 09:22, "= ;Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
This works for me and seems to combine the WG rough conse= nsus with the IESG comments.

Regards
=C2=A0 =C2=A0Brian Carpenter

On 25/04/2017 10:52, Bob Hinden wrote:
> Hi,
>
> After reading through the discussion about this text in Section 4, I h= ave some new text to propose.=C2=A0 I think this is significantly improved = and should resolve many of the issued raised.
>
> Changes include separate description of behaviors extension headers an= d the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from the f= irst paragraph.=C2=A0 I removed =E2=80=9Cexamine=E2=80=9D because I am conv= inced it=E2=80=99s not sustainable to say a node can=E2=80=99t examine exte= nsion given how widespread this behavior is.=C2=A0 I also removed the refer= ence to RFC7045 because examine is removed.=C2=A0 RFC7045 is referenced in = the recently updated Security Considerations section.
>
> I removed the =E2=80=9Cincluding the source and destination nodes=E2= =80=9D text from the paragraph on the hop-by-hop options header because I d= on=E2=80=99t think we need to mention the source, and there is a whole para= graph describe what happens at the destination node.=C2=A0 I also added the= text about from the first paragraph about reaching the destination to the = hop-by-hop header paragraph.
>
> I also moved (without change) the =E2=80=9CAt the Destination node...= =E2=80=9D text from the first paragraph to a new third paragraph.=C2=A0 It = applies to all extension headers.
>
> CURRENT and NEW text below.=C2=A0 Please review and comment.
>
> Bob
>
>
>=C2=A0 =C2=A0 CURRENT
>
>=C2=A0 =C2=A0 With one exception, extension headers are not examined, p= rocessed,
>=C2=A0 =C2=A0 inserted, or deleted by any node along a packet's del= ivery path,
>=C2=A0 =C2=A0 until the packet reaches the node (or each of the set of = nodes, in
>=C2=A0 =C2=A0 the case of multicast) identified in the Destination Addr= ess field of
>=C2=A0 =C2=A0 the IPv6 header.=C2=A0 Note: If an intermediate forwardin= g node examines
>=C2=A0 =C2=A0 an extension header for any reason, it must do so in acco= rdance with
>=C2=A0 =C2=A0 the provisions of [RFC7045].=C2=A0 At the Destination nod= e, normal
>=C2=A0 =C2=A0 demultiplexing on the Next Header field of the IPv6 heade= r invokes
>=C2=A0 =C2=A0 the module to process the first extension header, or the = upper-layer
>=C2=A0 =C2=A0 header if no extension header is present.=C2=A0 The conte= nts and semantics
>=C2=A0 =C2=A0 of each extension header determine whether or not to proc= eed to the
>=C2=A0 =C2=A0 next header.=C2=A0 Therefore, extension headers must be p= rocessed strictly
>=C2=A0 =C2=A0 in the order they appear in the packet; a receiver must n= ot, for
>=C2=A0 =C2=A0 example, scan through a packet looking for a particular k= ind of
>=C2=A0 =C2=A0 extension header and process that header prior to process= ing all
>=C2=A0 =C2=A0 preceding ones.
>
>=C2=A0 =C2=A0 The exception referred to in the preceding paragraph is t= he Hop-by-
>=C2=A0 =C2=A0 Hop Options header, which carries information that may be= examined
>=C2=A0 =C2=A0 and processed by every node along a packet's delivery= path, including
>=C2=A0 =C2=A0 the source and destination nodes.=C2=A0 The Hop-by-Hop Op= tions header,
>=C2=A0 =C2=A0 when present, must immediately follow the IPv6 header.=C2= =A0 Its presence
>=C2=A0 =C2=A0 is indicated by the value zero in the Next Header field o= f the IPv6
>=C2=A0 =C2=A0 header.
>
>=C2=A0 =C2=A0 NEW
>
>=C2=A0 =C2=A0 Extension headers (except for the Hop-by-Hop Options head= er) are not
>=C2=A0 =C2=A0 processed, inserted, or deleted by any node along a packe= t's delivery
>=C2=A0 =C2=A0 path, until the packet reaches the node (or each of the s= et of nodes,
>=C2=A0 =C2=A0 in the case of multicast) identified in the Destination A= ddress field
>=C2=A0 =C2=A0 of the IPv6 header.
>
>=C2=A0 =C2=A0 The Hop-by-Hop Options header is not inserted or deleted,= but may be
>=C2=A0 =C2=A0 examined and processed by every node along a packet's= delivery path,
>=C2=A0 =C2=A0 until the packet reaches the node (or each of the set of = nodes, in
>=C2=A0 =C2=A0 the case of multicast) identified in the Destination Addr= ess field of
>=C2=A0 =C2=A0 the IPv6 header.=C2=A0 The Hop-by-Hop Options header, whe= n present, must
>=C2=A0 =C2=A0 immediately follow the IPv6 header.=C2=A0 Its presence is= indicated by the
>=C2=A0 =C2=A0 value zero in the Next Header field of the IPv6 header. >
>=C2=A0 =C2=A0 At the Destination node, normal demultiplexing on the Nex= t Header
>=C2=A0 =C2=A0 field of the IPv6 header invokes the module to process th= e first
>=C2=A0 =C2=A0 extension header, or the upper-layer header if no extensi= on header is
>=C2=A0 =C2=A0 present.=C2=A0 The contents and semantics of each extensi= on header
>=C2=A0 =C2=A0 determine whether or not to proceed to the next header.= =C2=A0 Therefore,
>=C2=A0 =C2=A0 extension headers must be processed strictly in the order= they appear
>=C2=A0 =C2=A0 in the packet; a receiver must not, for example, scan thr= ough a
>=C2=A0 =C2=A0 packet looking for a particular kind of extension header = and process
>=C2=A0 =C2=A0 that header prior to processing all preceding ones.
>
>=C2=A0 =C2=A0 END NEW
>
>
>
> --------------------------------= ------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------
>

-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

--f403043ee3bc1ee80a054dfb0e8a-- From nobody Tue Apr 25 08:12:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F613158F; Tue, 25 Apr 2017 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 x1FS24w9SmLv; Tue, 25 Apr 2017 08:12:49 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 187FA13147B; Tue, 25 Apr 2017 08:12:05 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id g12so7406401wrg.2; Tue, 25 Apr 2017 08:12:05 -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=WiRGkg1A6frDxFLGnVJIyDiYX8+UqDxRyfaRf6ZzZEA=; b=mHEH7bBO4JCqKNElea8Hjs0Aq5BpY6LYru0bmWZYsA4dXFXMO3ITUOtCKgdq6IMZoS cc2KC/FjbHiPsoObWvu22BX0l/K7kRaomzbCTWkRe4xXSFUqdYJbIrZM7P8KoUMOR8gD RsNCfLgHnLUYKh/T9IBEA+wxM08QMKnnjByiyRO01+HV5HgPkDU2KgKfnrtCHNEq4nwg SFjoIG6iuZJWcFoSZ1kJFgG+DsbzE61Bzygv8xejGqNYFJ4i82PYaIHJbyiGhhk46J3x cpC+rN+xYRBFZRKL4Tcn+xo0y61W3Si1kuI+Yif1mLZNZI9m9MgR5Ljdsevznla0sCaH vpCQ== 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=WiRGkg1A6frDxFLGnVJIyDiYX8+UqDxRyfaRf6ZzZEA=; b=EWUnQN9royMUr67FrpljsdklIz5iQFWo6XHnkUgW4fIBUBFUN4o7PI6SVQ6k9WdNFT 0xEFNug3DEufF3bg85uQOTP+1uMpI0b8CYi2MTUN5EYjl73/quWY8h9xBISv8p1DvEeg HvLmZsYOdOjKGkVa9FHXeoXd7jMrTSnKJpZ+p0sZCo+afHmk1iYTofjk9pBGwrYxxB5F VfRI2sIGJyulQEylC1PPiRYTm+dbPse1ypbSWxeEE0IptcE/zre6S+64DId9EXXhmhZu sf8l+hMgkRW7my75HTyy4zj6nKmy+LFAfZw8FdvQue+ftwmqGzdvTUOgOtHHywMuehqf yNxg== X-Gm-Message-State: AN3rC/78iID/2+cExT3/D1g6Jle6gzGbR2mcdLbhVAMK75jEVOC9xw1V Woiihuyt+aCCDw== X-Received: by 10.223.164.148 with SMTP id g20mr10386879wrb.89.1493133123536; Tue, 25 Apr 2017 08:12:03 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:151d:eb0d:55d9:8e8b? ([2601:647:4d01:db10:151d:eb0d:55d9:8e8b]) by smtp.gmail.com with ESMTPSA id 31sm26561173wrt.35.2017.04.25.08.12.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 08:12:02 -0700 (PDT) From: Bob Hinden Message-Id: <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: =?utf-8?Q?Re=3A_ECN_and_fragments_=28was_Re=3A_=5Btsvwg=5D_Mirja_?= =?utf-8?Q?K=C3=BChlewind=27s_Discuss_on_draft-ietf-6man-rfc2460bis-09=3A_?= =?utf-8?Q?=28with_DISCUSS_and_COMMENT=29=29?= Date: Tue, 25 Apr 2017 08:11:57 -0700 In-Reply-To: Cc: Bob Hinden , "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , "C. M. Heard" , IESG , 6man-chairs@ietf.org To: Suresh Krishnan References: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 15:12:51 -0000 --Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Suresh, > On Apr 23, 2017, at 8:30 PM, Suresh Krishnan = wrote: >=20 > On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF) > wrote: >> Hi Suresh, >>=20 >> thanks this text is fine for me. >>=20 >> I=E2=80=99d like propose three tiny editorial only changes/nits: >> s/Other/Further,/ >> s/this basic/the basic/ >> s/sufficient. e.g./sufficient, e.g./ >=20 > Thanks Mirja. These edits all seem fine. >=20 >>=20 >> Only those headers in the Offset zero fragment packet are = retained in >> the reassembled packet. Further, fields in the IPv6 header may = also >> vary across the fragments being reassembled. Specifications that >> use these fields may provide alternate instructions if the basic >> mechanism of using the values from the Offset zero fragment is = not >> sufficient, e.g. Section 5.3 of [RFC3168] describes how to = combine >> the ECN bits from the different fragments to derive the ECN bits = of >> the reassembled packet. >>=20 >> And I would be even more happier if we could add a few more words to = the last sentence: >>=20 >> ... e.g. Section 5.3 of [RFC3168] describes how to combine >> the ECN bits from the different fragments to derive the ECN bits = of >> the reassembled packet such that no congestion indications are = lost. >=20 > This is not strictly true. If any of the fragments carries the not-ECT > codepoint, congestion indications will be lost (according to RFC3168), > but my earlier proposed text still works. So if you don't care > strongly about it, I would prefer keeping the old text. >=20 I looked at the proposed text and came up with the following (including = the text before and after): The following conditions are not expected to occur frequently, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. The Next Header values in the Fragment headers of different fragments of the same original packet may differ. Only the value from the Offset zero fragment packet is used for reassembly. Other fields in the IPv6 header may also vary across the fragments being reassembled. Specifications that use these fields may provide additional instructions if the basic mechanism of using the values from the Offset zero fragment is not sufficient. For example, Section 5.3 of [RFC3168] describes how to combine the Explicit Congestion Notification (ECN) bits from different fragments to derive the ECN bits of the reassembled packet. The biggest change was to split it into two paragraphs and put the new = text after the paragraph about Next Header values. Otherwise it = doesn=E2=80=99t read well. I also did a few editorial changes including spelling out ECN as it was = the first time in the document that was used. The text about Traffic = Class comes later in document. Changed =E2=80=9Calternate=E2=80=9D to = =E2=80=9Cadditional=E2=80=9D because the ECN spec does not respecify the = whole reassembly algorithm, just the ENC parts. Comments? Bob --Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJY/2c+AAoJEK7rdBF357uo+TkH/2HHLSvmDr6OcNebed5vSiXG miQoX5wqoJ8gUzPmNFHbUveM6XFpDiNWLny9GmiF9FON/ftah6hyQzbEmeUqjCGD x373Flr4g4kiBJRW/ysl9BJm48xnu1TugDMcGqvzmJjfyIiu0WxyTDO80kmRk8MO WqOad3EwzF6b0j/auAqKep9S2gEWOcOdMApD+lkBMTYmeipfmhbpS1V6+ZfEaMWk VftgGt3J3phpwdwVUxF8SBpobW0xA5WbrB7H7XBdK0Pv/9iS5fF4wFIFoTDsmBmf QAsr5MGs60b2ecFsnHyIIvP+cQtgfTjSx2Wp8VXhclgmFPEeGRjqHSitpJjz8rQ= =z1bx -----END PGP SIGNATURE----- --Apple-Mail=_50B16128-4744-4F1A-8106-E560C4FEB551-- From nobody Tue Apr 25 08:40:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227A131623; Tue, 25 Apr 2017 08:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 xPswMMn2X12u; Tue, 25 Apr 2017 08:39:59 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF1B131622; Tue, 25 Apr 2017 08:39:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id D8F486BB48; Tue, 25 Apr 2017 11:39:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=as9Lu7eoIVm6UccjSbvyfcY8k/A=; b=eJig// 3i3EtH3Njsaz3N3j9pHlTmhD/augFfZnR/+bOEACZkfEygbeEvHrhMyjBBaU5hIM 5Fa/iBEeHecvCgzGAPrAiVsyGrqJqAAPjqf6NxtfkSGeHD84YIBxjnOuIu2GcEpL 5eV4nN91l+TehZmJ6q55z2sKcQj5umgZuj0dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=J7CY/+3II1Jmwuo06DH2FIjXkkR1gr9p NSuws9GWZJRqFqAfOGgwfX8adCv3qCRqzmPKy24fhU17OisW21qE12l12x85pL1I HJWbln38o8dUv6h1DTbK2KIx8Cn8SlABJ6GkSThI1WRZABuW8z9jqNsDOlmO9YKE 7XQvsG8Rho0= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CECED6BB47; Tue, 25 Apr 2017 11:39:57 -0400 (EDT) Received: from mail-qk0-f180.google.com (unknown [209.85.220.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 582496BB45; Tue, 25 Apr 2017 11:39:57 -0400 (EDT) Received: by mail-qk0-f180.google.com with SMTP id y63so118545951qkd.1; Tue, 25 Apr 2017 08:39:57 -0700 (PDT) X-Gm-Message-State: AN3rC/4NvxHyBpYOkP7sqCuOH69aMCxPNihBdFdT5mfU6EV6DlsTzUkR Bx9mDBtkPAa0djBkVWdRQn6CMDrGRQ== X-Received: by 10.55.20.2 with SMTP id e2mr26752001qkh.15.1493134796926; Tue, 25 Apr 2017 08:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Tue, 25 Apr 2017 08:39:36 -0700 (PDT) In-Reply-To: <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com> References: <4DA7A0B2-AA3C-4E98-95FC-45A3CA5FC1F2@kuehlewind.net> <7F6C9FD6-BB14-4348-A870-93CD5E3CABBA@gmail.com> From: "C. M. Heard" Date: Tue, 25 Apr 2017 08:39:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: =?UTF-8?Q?Re=3A_ECN_and_fragments_=28was_Re=3A_=5Btsvwg=5D_Mirja_K=C3=BChlew?= =?UTF-8?Q?ind=27s_Discuss_on_draft=2Dietf=2D6man=2Drfc2460bis=2D09=3A_=28with_DISCUS?= =?UTF-8?Q?S_and_COMMENT=29=29?= To: Bob Hinden Cc: Suresh Krishnan , "Mirja Kuehlewind (IETF)" , "draft-ietf-6man-rfc2460bis@ietf.org" , 6MAN <6man@ietf.org>, tsvwg , IESG , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary=001a1144d6bc2c5208054dff894b X-Pobox-Relay-ID: 6F7FBEAE-29CD-11E7-B043-E680B56B9B0B-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 15:40:01 -0000 --001a1144d6bc2c5208054dff894b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that this text does the job very well. It reads well, does not levy any requirements on the reassembly process that were not in RFC 2460, clearly states that that other specs such as ECN may levy additional requirements, and points the reader to the relevant section of RFC 3168 for more information. Thanks for putting this together. //cmh On Tue, Apr 25, 2017 at 8:11 AM, Bob Hinden wrote: > Suresh, > > > On Apr 23, 2017, at 8:30 PM, Suresh Krishnan > wrote: > > > > On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF) > > wrote: > >> Hi Suresh, > >> > >> thanks this text is fine for me. > >> > >> I=E2=80=99d like propose three tiny editorial only changes/nits: > >> s/Other/Further,/ > >> s/this basic/the basic/ > >> s/sufficient. e.g./sufficient, e.g./ > > > > Thanks Mirja. These edits all seem fine. > > > >> > >> Only those headers in the Offset zero fragment packet are retained > in > >> the reassembled packet. Further, fields in the IPv6 header may als= o > >> vary across the fragments being reassembled. Specifications that > >> use these fields may provide alternate instructions if the basic > >> mechanism of using the values from the Offset zero fragment is not > >> sufficient, e.g. Section 5.3 of [RFC3168] describes how to combine > >> the ECN bits from the different fragments to derive the ECN bits o= f > >> the reassembled packet. > >> > >> And I would be even more happier if we could add a few more words to > the last sentence: > >> > >> ... e.g. Section 5.3 of [RFC3168] describes how to combine > >> the ECN bits from the different fragments to derive the ECN bits o= f > >> the reassembled packet such that no congestion indications are los= t. > > > > This is not strictly true. If any of the fragments carries the not-ECT > > codepoint, congestion indications will be lost (according to RFC3168), > > but my earlier proposed text still works. So if you don't care > > strongly about it, I would prefer keeping the old text. > > > > I looked at the proposed text and came up with the following (including > the text before and after): > > The following conditions are not expected to occur frequently, but > are not considered errors if they do: > > The number and content of the headers preceding the Fragment > header of different fragments of the same original packet may > differ. Whatever headers are present, preceding the Fragment > header in each fragment packet, are processed when the packets > arrive, prior to queueing the fragments for reassembly. Only > those headers in the Offset zero fragment packet are retained in > the reassembled packet. > > The Next Header values in the Fragment headers of different > fragments of the same original packet may differ. Only the value > from the Offset zero fragment packet is used for reassembly. > > Other fields in the IPv6 header may also vary across the fragments > being reassembled. Specifications that use these fields may > provide additional instructions if the basic mechanism of using > the values from the Offset zero fragment is not sufficient. For > example, Section 5.3 of [RFC3168] describes how to combine the > Explicit Congestion Notification (ECN) bits from different > fragments to derive the ECN bits of the reassembled packet. > > The biggest change was to split it into two paragraphs and put the new > text after the paragraph about Next Header values. Otherwise it doesn=E2= =80=99t > read well. > > I also did a few editorial changes including spelling out ECN as it was > the first time in the document that was used. The text about Traffic Cla= ss > comes later in document. Changed =E2=80=9Calternate=E2=80=9D to =E2=80= =9Cadditional=E2=80=9D because the > ECN spec does not respecify the whole reassembly algorithm, just the ENC > parts. > > Comments? > > Bob > > > --001a1144d6bc2c5208054dff894b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that this text does the job very well. It reads we= ll, does not levy any requirements on the reassembly process that were not = in RFC 2460, clearly states that that other specs such as ECN may levy addi= tional requirements, and points the reader to the relevant section of RFC 3= 168 for more information. Thanks for putting this together.

<= div>//cmh

On Tue, Apr 25, 2017 at 8:11 AM, Bob Hinden <bob.hinden@gmail.com= > wrote:
Suresh,

> On Apr 23, 2017, at 8:30 PM, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
>
> On Sat, Apr 22, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
> <ietf@kuehlewind.net>= wrote:
>> Hi Suresh,
>>
>> thanks this text is fine for me.
>>
>> I=E2=80=99d like propose three tiny editorial only changes/nits: >> s/Other/Further,/
>> s/this basic/the basic/
>> s/sufficient. e.g./sufficient, e.g./
>
> Thanks Mirja. These edits all seem fine.
>
>>
>>=C2=A0 =C2=A0 =C2=A0Only those headers in the Offset zero fragment = packet are retained in
>>=C2=A0 =C2=A0 =C2=A0the reassembled packet. Further, fields in the = IPv6 header may also
>>=C2=A0 =C2=A0 =C2=A0vary across the fragments being reassembled. Sp= ecifications that
>>=C2=A0 =C2=A0 =C2=A0use these fields may provide alternate instruct= ions if the basic
>>=C2=A0 =C2=A0 =C2=A0mechanism of using the values from the Offset z= ero fragment is not
>>=C2=A0 =C2=A0 =C2=A0sufficient, e.g. Section 5.3 of [RFC3168] descr= ibes how to combine
>>=C2=A0 =C2=A0 =C2=A0the ECN bits from the different fragments to de= rive the ECN bits of
>>=C2=A0 =C2=A0 =C2=A0the reassembled packet.
>>
>> And I would be even more happier if we could add a few more words = to the last sentence:
>>
>>=C2=A0 =C2=A0 =C2=A0... e.g. Section 5.3 of [RFC3168] describes how= to combine
>>=C2=A0 =C2=A0 =C2=A0the ECN bits from the different fragments to de= rive the ECN bits of
>>=C2=A0 =C2=A0 =C2=A0the reassembled packet such that no congestion = indications are lost.
>
> This is not strictly true. If any of the fragments carries the not-ECT=
> codepoint, congestion indications will be lost (according to RFC3168),=
> but my earlier proposed text still works. So if you don't care
> strongly about it, I would prefer keeping the old text.
>

I looked at the proposed text and came up with the following (i= ncluding the text before and after):

=C2=A0 =C2=A0The following conditions are not expected to occur frequently,= but
=C2=A0 =C2=A0are not considered errors if they do:

=C2=A0 =C2=A0 =C2=A0 The number and content of the headers preceding the Fr= agment
=C2=A0 =C2=A0 =C2=A0 header of different fragments of the same original pac= ket may
=C2=A0 =C2=A0 =C2=A0 differ.=C2=A0 Whatever headers are present, preceding = the Fragment
=C2=A0 =C2=A0 =C2=A0 header in each fragment packet, are processed when the= packets
=C2=A0 =C2=A0 =C2=A0 arrive, prior to queueing the fragments for reassembly= .=C2=A0 Only
=C2=A0 =C2=A0 =C2=A0 those headers in the Offset zero frag= ment packet are retained in
=C2=A0 =C2=A0 =C2=A0 the reassembled packet.

=C2=A0 =C2=A0 =C2=A0 The Next Header values in the Fragment headers = of different
=C2=A0 =C2=A0 =C2=A0 fragments of the same original packet may differ.=C2= =A0 Only the value
=C2=A0 =C2=A0 =C2=A0 from the Offset zero fragment packet is used for reass= embly.

=C2=A0 =C2=A0 =C2=A0 Other fields in the IPv6 header may also vary across t= he fragments
=C2=A0 =C2=A0 =C2=A0 being reassembled.=C2=A0 Specificatio= ns that use these fields may
=C2=A0 =C2=A0 =C2=A0 provide additional instructions if the basic me= chanism of using
=C2=A0 =C2=A0 =C2=A0 the values from the Offset zero fragment is not suffic= ient.=C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, Section 5.3 of [RFC3168] describes how to com= bine the
=C2=A0 =C2=A0 =C2=A0 Explicit Congestion Notification (ECN) bits from diffe= rent
=C2=A0 =C2=A0 =C2=A0 fragments to derive the ECN bits of t= he reassembled packet.

The biggest change was to split it into two paragraphs and put the n= ew text after the paragraph about Next Header values.=C2=A0 Otherwise it do= esn=E2=80=99t read well.

I also did a few editorial changes including spelling out ECN as it was the= first time in the document that was used.=C2=A0 The text about Traffic Cla= ss comes later in document.=C2=A0 Changed =E2=80=9Calternate=E2=80=9D to = =E2=80=9Cadditional=E2=80=9D because the ECN spec does not respecify the wh= ole reassembly algorithm, just the ENC parts.

Comments?

Bob



--001a1144d6bc2c5208054dff894b-- From nobody Tue Apr 25 11:27:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73967128616; Tue, 25 Apr 2017 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 V060TpduJo6C; Tue, 25 Apr 2017 11:26:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 DCBD212946A; Tue, 25 Apr 2017 11:26:54 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PIQ1sq026365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 11:26:03 -0700 (PDT) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 To: Stewart Bryant , gen-art@ietf.org Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> From: Joe Touch Message-ID: <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> Date: Tue, 25 Apr 2017 11:26:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <149305392811.25808.15115824976388262628@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:26:57 -0000 Hi, Stewart, On 4/24/2017 10:12 AM, Stewart Bryant wrote: > Minor issues: > > A node MUST NOT reduce its estimate of the Path MTU below the IPv6 > minimum link MTU. > > SB> I missed this last time. > SB> > SB> Presumably you mean "A node MUST NOT reduce its estimate of the > SB> Path MTU below the IPv6 minimum link MTU in response to such > SB> a message." This seems fine to me, FWIW - i.e., limiting the advice in this doc to the mechanism in this doc. > SB> > SB> Otherwise I would have thought that this was entirely a matter > SB> for the host whether it wanted to use a Path MTU below the IPv6 > SB> link minimum. Nothing breaks if the host takes a more conservative > SB> decision. I don't agree; the host at that point is violating RFC2460. It should never think that an IPv6 link or path with an MTU below what RFC2460 requires is valid. Joe From nobody Tue Apr 25 19:56:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B521273E2 for ; Tue, 25 Apr 2017 19:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZRiEZgoNVgE for ; Tue, 25 Apr 2017 19:56:21 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 771AD1204DA for ; Tue, 25 Apr 2017 19:56:21 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id c45so155921094qtb.1 for ; Tue, 25 Apr 2017 19:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=5LpOn/TpD2FYmsHHdQz5EvPOS1h+VaCA0wDhGmyErWk=; b=qyCYfAL/AuTMqUmZK3V/l/DSx04mOkrm9krSGVncDi8cf/uzmi2UNE4kTMO3M32mNu u6qkdpcah4j/ko/rd6ey96zQqzK2JcO50COvXkS3mDonnI35nq1si8xqT5SRYfOwE33l TGg2XJOzyqGqN0tPxJSd1H6+NwDyedgFC9tYQ8WjUcLtYB0aRbUBSgF/o3j1MLFMjIA+ fHQDzQ1bXhkFRIUVAXQeVlDda+eGHAvSZyCbeOZ4aD7KqGF+OYXbHpBTp78QIiJRK1gU PqM8tsKE/+pRsvKwIYMvp1mFFGjb7EWB/lmJbF9Rx+K9NTy7dX7bmMH/Wbt4fl3L9oOR ULdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5LpOn/TpD2FYmsHHdQz5EvPOS1h+VaCA0wDhGmyErWk=; b=RivpUzzMpEyMugYDajyqDVbLRa8a9thTMRNFUTwv5yWn1Tp6JwegUniz7KsXSVW3Pt joWZEO+xpnCUWoJks9WO334OJsWp47E/ByYnYf2HN21DyD0WfYVTejgQi1XVNn/kAWDc mSHndiihOEKYnJeuDui5taaPPwSJ1sXHWyW+m+RJRa8D6VRBUPPj+Vwk1CZmdNOoKVxr VIj+0/ycxJ9WW9gW7etpdZJfwJsv1lqr95vX1CthnAjR0tTAQJfnwOMrpvnm3kKVSobL 6IMkn25rceVovbgnaowvO4HRVOooBqo2OrV6b5jWmISM63bxfsLdwehOGzXgg0qD8l5P OW8g== X-Gm-Message-State: AN3rC/4pl52Q5LaX7lSlKBjN+f/7Gi1em76GLM81KRdkZVEJSk3nMGuj gVk+Kmtkg9iGdwqBzoq5KnV8rMvk8wxd X-Received: by 10.200.45.122 with SMTP id o55mr34492099qta.203.1493175380506; Tue, 25 Apr 2017 19:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 25 Apr 2017 19:56:20 -0700 (PDT) From: Tom Herbert Date: Tue, 25 Apr 2017 19:56:20 -0700 Message-ID: Subject: Destination options and denial of service attack To: "ipv6@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:56:24 -0000 The topic of limits of unbounded lists of TLVs that can be ignored came up on tsvwg. By my estimate, it is possible the create an Ethernet MTU size packet that holds 1282 TLVs in destination options (a combination of PAD1s and two bytes option with a type value that is known to be undefined) or at least 724 two byte options that would be ignored. Processing such packets on a host would be quite expensive and could likely be used as a DOS attack. HBH options have similar characteristics , but there are known workarounds such as devices ignoring them completely per the new allowance. Also, it's pretty well known that a router can throw packets with EH into a slow path that provides a from of rate limiting (albeit possibly at the possible expense of hampering legitimate use cases of EH)-- there's no obvious equivalent mechanism for a host. I am specifically concerned with destination options and processing them on hosts. The Linux stack for instance currently has no limits on destination options and will process all that are in a packet AFAICT. My question is what mitigations do we have to handle a DOS attack like this that would be in compliance with the spec? AFAICT from reading 2640bis a host must process all extension headers and must process all destination options in a packet. There is no limit to number of options or space used other than they need to fit into an MTU IIRC. Appendix A of 2460bis mentions "It may be assumed that, when either of the option-bearing headers are present, they carry a very small number of options, usually only one.", but that does not establish an enforceable limit. Thanks, Tom From nobody Wed Apr 26 01:49:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE3131A10; Wed, 26 Apr 2017 01:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 9wWFl6aZayu3; Wed, 26 Apr 2017 01:48:52 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 19730131A12; Wed, 26 Apr 2017 01:48:52 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l9so19315062wre.1; Wed, 26 Apr 2017 01:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OPpzDn4dLZdj73y5j1tvgCeWiWSxiLQI1WqVx/K5boc=; b=q94HxZQRuMSPwczQZB9fM30LBtX35/tdscfe6z6QHtCAh0C/nZkzyDz0e4nxWJUuYm pRs6xyZa0q/GR0YOcx16NaIO7J+2vxpvptduZxWKn67hmPJZ10KET+4rLkpZlCAFVDyf 3NOSYiLkLkiZGeg67rszTHH/ZIp1tBv9oeQO7zfqs7knHRVLyNfJ1t4OTX1npC9/8ajP broo/Q81BmyVnH1FoMyqIOMLVPthto7GLNVHuwOBJd/YQ5I2Frzvc4bgqQFruh3yCaTG d3drm0OC16Vv9MzPieFKKEX72uFsu8QAY8z7YaBZp7PpkJ7x28tbx+0YwgIBU6MxtI14 0UfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OPpzDn4dLZdj73y5j1tvgCeWiWSxiLQI1WqVx/K5boc=; b=qP8/wkLxZa35sgnrPv8us9JI3RwoD/cyufwbaTBX7grioj6Rerl52EFBkb8udWZ73b VEYm0FG2qOI9TQ5t/Lbtv1r4gB7JYU7QRrHoUI3Bz9QYoow6RZvInciPnmRUmsA0IA+V ovvq/v7UJW05iqWiMcaMbObdNEIa5Uo6zNKzFx8RVdvM3xwRYCAPsI1OMeX+6jakf6TW 5OlPr1lDv7S/EaWWcEmCMhjWMiyx3t0o/C/OkB9Ra71GruS/zMGWoT0EwwtQ2aLjnzKh v7SeWLYTjdp51psafr9RQc03YbAUeaFa3tLi95TgtLQbKkl0KIeQxumFA6Ew2WA+ILq7 7GjA== X-Gm-Message-State: AN3rC/50tcG2b6HxoG+cTrlreiGJjeAfZrc+wLRtnUAC/UyyDGxUd/xj 8kTM0WoZ7iLo5odjfms= X-Received: by 10.223.165.138 with SMTP id g10mr14232293wrc.19.1493196530389; Wed, 26 Apr 2017 01:48:50 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m83sm7988509wmc.7.2017.04.26.01.48.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 01:48:49 -0700 (PDT) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 To: Joe Touch , gen-art@ietf.org References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org From: Stewart Bryant Message-ID: Date: Wed, 26 Apr 2017 09:48:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 08:48:54 -0000 On 25/04/2017 19:26, Joe Touch wrote: > Hi, Stewart, > > > On 4/24/2017 10:12 AM, Stewart Bryant wrote: >> Minor issues: >> >> A node MUST NOT reduce its estimate of the Path MTU below the IPv6 >> minimum link MTU. >> >> SB> I missed this last time. >> SB> >> SB> Presumably you mean "A node MUST NOT reduce its estimate of the >> SB> Path MTU below the IPv6 minimum link MTU in response to such >> SB> a message." > This seems fine to me, FWIW - i.e., limiting the advice in this doc to > the mechanism in this doc. > >> SB> >> SB> Otherwise I would have thought that this was entirely a matter >> SB> for the host whether it wanted to use a Path MTU below the IPv6 >> SB> link minimum. Nothing breaks if the host takes a more conservative >> SB> decision. > I don't agree; the host at that point is violating RFC2460. It should > never think that an IPv6 link or path with an MTU below what RFC2460 > requires is valid. > > Joe > That is as maybe, but a host can do more or less what it wants, so this is surely an unenforceable constraint, or are you telling me that the receiving host MUST drop a fragment that is shorter than this? In which case the question whether in practice they do, and whether such a constraint is reasonable. - Stewart From nobody Wed Apr 26 01:53:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0C13180D for ; Wed, 26 Apr 2017 01:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] 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 kOu4DvqdysmC for ; Wed, 26 Apr 2017 01:53:13 -0700 (PDT) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:470:1f0b:8b2::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFD9131A1D for ; Wed, 26 Apr 2017 01:53:13 -0700 (PDT) Received: from gir.theapt.org (unknown [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/0 bits)) (Client did not present a certificate) (Authenticated sender: phessler) by gir.theapt.org (Postfix) with ESMTPSA id BCA7D788E9 for ; Wed, 26 Apr 2017 10:53:11 +0200 (CEST) Date: Wed, 26 Apr 2017 10:52:58 +0200 From: Peter Hessler To: ipv6@ietf.org Subject: Re: Destination options and denial of service attack Message-ID: <20170426085258.GA30896@gir.theapt.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 08:53:14 -0000 On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote: :AFAICT from reading :2640bis a host must process all extension headers and must process all :destination options in a packet. There are many firewalls deployed in the wild that by default drop all IPv6 packets with extension headers. That avoids the DoS condition. -- Did you know ... That no-one ever reads these things? From nobody Wed Apr 26 06:38:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46D129BAD for ; Wed, 26 Apr 2017 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 3X0b_oH6P3rx for ; Wed, 26 Apr 2017 06:38:05 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C280129BA4 for ; Wed, 26 Apr 2017 06:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493213883; bh=tFmejJOHTpQ+wRggBXhc04UUifdy8z9cVH4GRiAFagY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OUMq9TiqEYGp5T54ob+APi5lLdsNgLFlyrt12L4jiSBmWHgGKZGB28TEbNWQS/rAyGow5NKTfFND7eEr757Zszre7M+oL91FEuuKVSuwLteVElJcPiVhKcMuq3lOmgIyQvj5ajfRevui5EFNoqcSu8bFb6LBdaLDrK/imG06xEY= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-C5d0YszkO7q6TuGhDEpCaQ-1; Wed, 26 Apr 2017 14:37:58 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Wed, 26 Apr 2017 13:37:57 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1061.011; Wed, 26 Apr 2017 13:37:57 +0000 From: Tim Chown To: Bob Hinden CC: IPv6 List Subject: Re: Proposed revised Extension Header text for rfc2460bis Thread-Topic: Proposed revised Extension Header text for rfc2460bis Thread-Index: AQHSvU2RtftRrX/0x02YX67sCFIJ2qHXqgQA Date: Wed, 26 Apr 2017 13:37:56 +0000 Message-ID: <83FF75F2-AB2A-4DC4-B3E1-07D98E299797@jisc.ac.uk> References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> In-Reply-To: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:N59BsZctsOR3WXD8nYNvhRlMk3J+SUK0MTVHowGhcmxrTeVeDRvnlaB8TEcX3eH9OFjKwjBlsVHOvlCOt8bauJFr5FGzPvEZIpESx0hcnv4oNx3CsJPkYbWWO082UDDIM3WndDb+xwFta46QBs9nEgjEbosME5v0Of/uJxlf1PTEJ6FzwQOJon5OS+nrqMZCJcUN+0mx1XNlIRmoYSxmBUCj7nq9GxfmuQ/XjUM9PUggjOO1ruxqmPhdjd3eYXQF0uo0bRVFA6y+3Omzo13q5qiC58+uS6JeD+Q2LAB5oghxD8BrJ8uaK0yWlkb8NL2zXRyJ6GvIHyY4MQTvxcjM8Q==; 20:R4CTLzozfuIjx/U460TJnPf0sFb/DcVIeK3YD49cUeCsA/OFxyskDAUeB6ts2e3Nw4M8GE3Stk6JIbDfb3SsEMdBlPUUK0KJNbqFmCCyeCa3rxivOHPfwbVjL9W/h407K0pTKRdGzo89rx7ps5Nevh6cDAW3M1KhiUbW5eXE35w= x-ms-office365-filtering-correlation-id: 2962bb89-1765-49cf-dcc4-08d48ca972e6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201703061421075)(201703161042150)(20161123558100)(6072148)(6042181); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(52314003)(24454002)(36756003)(81166006)(6512007)(6506006)(6436002)(99286003)(6486002)(6306002)(50226002)(8936002)(38730400002)(8676002)(6246003)(3846002)(102836003)(74482002)(57306001)(6116002)(25786009)(5660300001)(66066001)(53546009)(5250100002)(33656002)(110136004)(53936002)(86362001)(4326008)(82746002)(3660700001)(3280700002)(2900100001)(83716003)(42882006)(2950100002)(6916009)(76176999)(189998001)(50986999)(305945005)(2906002)(7736002)(39060400002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 13:37:56.8794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: C5d0YszkO7q6TuGhDEpCaQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 13:38:08 -0000 SGksDQoNCkkgYWdyZWUgdGhpcyB0ZXh0IGlzIG11Y2ggYmV0dGVyLiBKdXN0IGEgY291cGxlIG9m IG1pbm9yIGNvbW1lbnRzIGJlbG93Lg0KDQo+IE9uIDI0IEFwciAyMDE3LCBhdCAyMzo1MiwgQm9i IEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBB ZnRlciByZWFkaW5nIHRocm91Z2ggdGhlIGRpc2N1c3Npb24gYWJvdXQgdGhpcyB0ZXh0IGluIFNl Y3Rpb24gNCwgSSBoYXZlIHNvbWUgbmV3IHRleHQgdG8gcHJvcG9zZS4gIEkgdGhpbmsgdGhpcyBp cyBzaWduaWZpY2FudGx5IGltcHJvdmVkIGFuZCBzaG91bGQgcmVzb2x2ZSBtYW55IG9mIHRoZSBp c3N1ZWQgcmFpc2VkLg0KPiANCj4gQ2hhbmdlcyBpbmNsdWRlIHNlcGFyYXRlIGRlc2NyaXB0aW9u IG9mIGJlaGF2aW9ycyBleHRlbnNpb24gaGVhZGVycyBhbmQgdGhlIGhvcC1ieS1ob3Agb3B0aW9u IGhlYWRlciwgcmVtb3ZlIOKAnGV4YW1pbmXigJ0gZnJvbSB0aGUgZmlyc3QgcGFyYWdyYXBoLiAg SSByZW1vdmVkIOKAnGV4YW1pbmXigJ0gYmVjYXVzZSBJIGFtIGNvbnZpbmNlZCBpdOKAmXMgbm90 IHN1c3RhaW5hYmxlIHRvIHNheSBhIG5vZGUgY2Fu4oCZdCBleGFtaW5lIGV4dGVuc2lvbiBnaXZl biBob3cgd2lkZXNwcmVhZCB0aGlzIGJlaGF2aW9yIGlzLiAgSSBhbHNvIHJlbW92ZWQgdGhlIHJl ZmVyZW5jZSB0byBSRkM3MDQ1IGJlY2F1c2UgZXhhbWluZSBpcyByZW1vdmVkLiAgUkZDNzA0NSBp cyByZWZlcmVuY2VkIGluIHRoZSByZWNlbnRseSB1cGRhdGVkIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24uDQo+IA0KPiBJIHJlbW92ZWQgdGhlIOKAnGluY2x1ZGluZyB0aGUgc291cmNl IGFuZCBkZXN0aW5hdGlvbiBub2Rlc+KAnSB0ZXh0IGZyb20gdGhlIHBhcmFncmFwaCBvbiB0aGUg aG9wLWJ5LWhvcCBvcHRpb25zIGhlYWRlciBiZWNhdXNlIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVk IHRvIG1lbnRpb24gdGhlIHNvdXJjZSwgYW5kIHRoZXJlIGlzIGEgd2hvbGUgcGFyYWdyYXBoIGRl c2NyaWJlIHdoYXQgaGFwcGVucyBhdCB0aGUgZGVzdGluYXRpb24gbm9kZS4gIEkgYWxzbyBhZGRl ZCB0aGUgdGV4dCBhYm91dCBmcm9tIHRoZSBmaXJzdCBwYXJhZ3JhcGggYWJvdXQgcmVhY2hpbmcg dGhlIGRlc3RpbmF0aW9uIHRvIHRoZSBob3AtYnktaG9wIGhlYWRlciBwYXJhZ3JhcGguDQo+IA0K PiBJIGFsc28gbW92ZWQgKHdpdGhvdXQgY2hhbmdlKSB0aGUg4oCcQXQgdGhlIERlc3RpbmF0aW9u IG5vZGUuLi7igJ0gdGV4dCBmcm9tIHRoZSBmaXJzdCBwYXJhZ3JhcGggdG8gYSBuZXcgdGhpcmQg cGFyYWdyYXBoLiAgSXQgYXBwbGllcyB0byBhbGwgZXh0ZW5zaW9uIGhlYWRlcnMuDQo+IA0KPiBD VVJSRU5UIGFuZCBORVcgdGV4dCBiZWxvdy4gIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQo+ IA0KPiBCb2INCj4gDQo+IA0KPiAgIENVUlJFTlQNCj4gDQo+ICAgV2l0aCBvbmUgZXhjZXB0aW9u LCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQo+ICAgaW5z ZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBw YXRoLA0KPiAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0 aGUgc2V0IG9mIG5vZGVzLCBpbg0KPiAgIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmll ZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KPiAgIHRoZSBJUHY2IGhlYWRl ci4gIE5vdGU6IElmIGFuIGludGVybWVkaWF0ZSBmb3J3YXJkaW5nIG5vZGUgZXhhbWluZXMNCj4g ICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVhc29uLCBpdCBtdXN0IGRvIHNvIGluIGFj Y29yZGFuY2Ugd2l0aA0KPiAgIHRoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4gIEF0IHRoZSBE ZXN0aW5hdGlvbiBub2RlLCBub3JtYWwNCj4gICBkZW11bHRpcGxleGluZyBvbiB0aGUgTmV4dCBI ZWFkZXIgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMNCj4gICB0aGUgbW9kdWxlIHRv IHByb2Nlc3MgdGhlIGZpcnN0IGV4dGVuc2lvbiBoZWFkZXIsIG9yIHRoZSB1cHBlci1sYXllcg0K PiAgIGhlYWRlciBpZiBubyBleHRlbnNpb24gaGVhZGVyIGlzIHByZXNlbnQuICBUaGUgY29udGVu dHMgYW5kIHNlbWFudGljcw0KPiAgIG9mIGVhY2ggZXh0ZW5zaW9uIGhlYWRlciBkZXRlcm1pbmUg d2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUNCj4gICBuZXh0IGhlYWRlci4gIFRoZXJl Zm9yZSwgZXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQgc3RyaWN0bHkNCj4gICBp biB0aGUgb3JkZXIgdGhleSBhcHBlYXIgaW4gdGhlIHBhY2tldDsgYSByZWNlaXZlciBtdXN0IG5v dCwgZm9yDQo+ICAgZXhhbXBsZSwgc2NhbiB0aHJvdWdoIGEgcGFja2V0IGxvb2tpbmcgZm9yIGEg cGFydGljdWxhciBraW5kIG9mDQo+ICAgZXh0ZW5zaW9uIGhlYWRlciBhbmQgcHJvY2VzcyB0aGF0 IGhlYWRlciBwcmlvciB0byBwcm9jZXNzaW5nIGFsbA0KPiAgIHByZWNlZGluZyBvbmVzLg0KPiAN Cj4gICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRvIGluIHRoZSBwcmVjZWRpbmcgcGFyYWdyYXBo IGlzIHRoZSBIb3AtYnktDQo+ICAgSG9wIE9wdGlvbnMgaGVhZGVyLCB3aGljaCBjYXJyaWVzIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1pbmVkDQo+ICAgYW5kIHByb2Nlc3NlZCBieSBldmVy eSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgaW5jbHVkaW5nDQo+ICAgdGhl IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbm9kZXMuICBUaGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhl YWRlciwNCj4gICB3aGVuIHByZXNlbnQsIG11c3QgaW1tZWRpYXRlbHkgZm9sbG93IHRoZSBJUHY2 IGhlYWRlci4gIEl0cyBwcmVzZW5jZQ0KPiAgIGlzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgemVy byBpbiB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYNCj4gICBoZWFkZXIuDQo+IA0K PiAgIE5FVw0KPiANCj4gICBFeHRlbnNpb24gaGVhZGVycyAoZXhjZXB0IGZvciB0aGUgSG9wLWJ5 LUhvcCBPcHRpb25zIGhlYWRlcikgYXJlIG5vdA0KPiAgIHByb2Nlc3NlZCwgaW5zZXJ0ZWQsIG9y IGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeQ0KPiAgIHBhdGgs IHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9m IG5vZGVzLA0KPiAgIGluIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUg RGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZA0KPiAgIG9mIHRoZSBJUHY2IGhlYWRlci4NCg0KQWN0 dWFsbHksIGlmIHdlIGFyZSByZXdyaXRpbmcgdGhpcyBhbnl3YXksIHRoZSBtdWx0aWNhc3Qgd29y ZGluZyBzaG91bGQgcHJvYmFibHkgc2F5IOKAnChvciwgaW4gdGhlIGNhc2Ugb2YgbXVsdGljYXN0 LCBhbnkgbm9kZSBpbiB0aGUgbXVsdGljYXN0IGdyb3VwKeKAnSwgZWxzZSB3ZeKAmXJlIHN1Z2dl c3RpbmcgYWN0aW9ucyBjYW5ub3QgYmUgdGFrZW4gdW50aWwgZWFjaCByZWNlaXZlciBoYXMgcmVj ZWl2ZWQgaXRzIGNvcHkuICANCg0KPiAgIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIGlz IG5vdCBpbnNlcnRlZCBvciBkZWxldGVkLCBidXQgbWF5IGJlDQo+ICAgZXhhbWluZWQgYW5kIHBy b2Nlc3NlZCBieSBldmVyeSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aA0KDQo+ ICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQg b2Ygbm9kZXMsIGluDQo+ICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRo ZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mDQoNClRoZSBzYW1lIGNvbW1lbnQgYWdhaW4g Zm9yIG11bHRpY2FzdC4NCg0KPiAgIHRoZSBJUHY2IGhlYWRlci4gIFRoZSBIb3AtYnktSG9wIE9w dGlvbnMgaGVhZGVyLCB3aGVuIHByZXNlbnQsIG11c3QNCj4gICBpbW1lZGlhdGVseSBmb2xsb3cg dGhlIElQdjYgaGVhZGVyLiAgSXRzIHByZXNlbmNlIGlzIGluZGljYXRlZCBieSB0aGUNCj4gICB2 YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIuDQo+ IA0KPiAgIEF0IHRoZSBEZXN0aW5hdGlvbiBub2RlLCBub3JtYWwgZGVtdWx0aXBsZXhpbmcgb24g dGhlIE5leHQgSGVhZGVyDQo+ICAgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMgdGhl IG1vZHVsZSB0byBwcm9jZXNzIHRoZSBmaXJzdA0KPiAgIGV4dGVuc2lvbiBoZWFkZXIsIG9yIHRo ZSB1cHBlci1sYXllciBoZWFkZXIgaWYgbm8gZXh0ZW5zaW9uIGhlYWRlciBpcw0KPiAgIHByZXNl bnQuICBUaGUgY29udGVudHMgYW5kIHNlbWFudGljcyBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXIN Cj4gICBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUgbmV4dCBoZWFk ZXIuICBUaGVyZWZvcmUsDQo+ICAgZXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQg c3RyaWN0bHkgaW4gdGhlIG9yZGVyIHRoZXkgYXBwZWFyDQo+ICAgaW4gdGhlIHBhY2tldDsgYSBy ZWNlaXZlciBtdXN0IG5vdCwgZm9yIGV4YW1wbGUsIHNjYW4gdGhyb3VnaCBhDQo+ICAgcGFja2V0 IGxvb2tpbmcgZm9yIGEgcGFydGljdWxhciBraW5kIG9mIGV4dGVuc2lvbiBoZWFkZXIgYW5kIHBy b2Nlc3MNCj4gICB0aGF0IGhlYWRlciBwcmlvciB0byBwcm9jZXNzaW5nIGFsbCBwcmVjZWRpbmcg b25lcy4NCg0KVGhlcmUgaXMgYWxzbyB0aGUgTk9URTogdGV4dCB0byBwbGFjZToNCg0KICAgTk9U RTogV2hpbGUgW1JGQzI0NjBdIHJlcXVpcmVkIHRoYXQgYWxsIG5vZGVzIG11c3QgZXhhbWluZSBh bmQNCiAgIHByb2Nlc3MgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsIGl0IGlzIG5vdyBl eHBlY3RlZCB0aGF0IG5vZGVzDQogICBhbG9uZyBhIHBhY2tldCdzIGRlbGl2ZXJ5IHBhdGggb25s eSBleGFtaW5lIGFuZCBwcm9jZXNzIHRoZSBIb3AtYnktDQogICBIb3AgT3B0aW9ucyBoZWFkZXIg aWYgZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNvLg0KDQpUaGlzIG1pZ2h0IGZpdCBiZXR0 ZXIgYWZ0ZXIgdGhlIEhiSCBwYXJhZ3JhcGggYWJvdmUsIHJhdGhlciB0aGFuIChhcyBpdCB3b3Vs ZCBiZSBub3cpIGFmdGVyIHRoZSBEZXN0aW5hdGlvbiBub2RlIHBhcmFncmFwaD8NCg0KVGltDQoN Cj4gDQo+ICAgRU5EIE5FVw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQo= From nobody Wed Apr 26 07:36:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E984112EB12 for ; Wed, 26 Apr 2017 07:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 6FxJlAnT8h9q for ; Wed, 26 Apr 2017 07:35:58 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D8D12EB3E for ; Wed, 26 Apr 2017 07:32:27 -0700 (PDT) Received: from [192.168.0.49] (cpc104726-belf11-2-0-cust405.2-1.cable.virginm.net [81.103.197.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B1BB280CBE; Wed, 26 Apr 2017 16:32:24 +0200 (CEST) Subject: Re: Destination options and denial of service attack To: Tom Herbert , "ipv6@ietf.org" References: From: Fernando Gont Message-ID: Date: Wed, 26 Apr 2017 15:22:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:36:01 -0000 On 04/26/2017 03:56 AM, Tom Herbert wrote: > The topic of limits of unbounded lists of TLVs that can be ignored > came up on tsvwg. By my estimate, it is possible the create an > Ethernet MTU size packet that holds 1282 TLVs in destination options > (a combination of PAD1s and two bytes option with a type value that is > known to be undefined) or at least 724 two byte options that would be > ignored. Processing such packets on a host would be quite expensive > and could likely be used as a DOS attack. HBH options have similar > characteristics , but there are known workarounds such as devices > ignoring them completely per the new allowance. Also, it's pretty well > known that a router can throw packets with EH into a slow path that > provides a from of rate limiting (albeit possibly at the possible > expense of hampering legitimate use cases of EH)-- there's no obvious > equivalent mechanism for a host. I am specifically concerned with > destination options and processing them on hosts. The Linux stack for > instance currently has no limits on destination options and will > process all that are in a packet AFAICT. > > My question is what mitigations do we have to handle a DOS attack like > this that would be in compliance with the spec? AFAICT from reading > 2640bis a host must process all extension headers and must process all > destination options in a packet. There is no limit to number of > options or space used other than they need to fit into an MTU IIRC. > Appendix A of 2460bis mentions "It may be assumed that, when either of > the option-bearing headers are present, they carry a very small number > of options, usually only one.", but that does not establish an > enforceable limit. That's part of what I mentioned regarding providing pointers regarding the security implications of IPv6 EHs. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Apr 26 07:52:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2C129C5F for ; Wed, 26 Apr 2017 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 jwiQJ8r2cEmP for ; Wed, 26 Apr 2017 07:51:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6076127BA3 for ; Wed, 26 Apr 2017 07:51:51 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4EA857E1D5 for ; Wed, 26 Apr 2017 10:51:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=AGwmom UR6D4c+xxQZCSdWRHCvA4=; b=LkRRQ9JAoUMIY9V6131DqAlp+M7EMEYpwLehjS GHGjLVgCu5Vt6dGWVlafrLOzcenlkBE1ZHQOLP+vUv8Mw7ufcVSbNu16UOZ63d4m EC362zoW0ZDi7zj/k5o5vRrq9YrBb2SEzKLb4W69etYWySJDiX6KVm1GEHAG594c O28qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= KLigc0IUgAD+SotnLRVymZ/QoPBYFI2DFGZvPPr6MYnvvkULGu24HUge6YeAyR2x TF4ytflt9cIu4AdNWjA0SR8TwyRfQbWVaF0BwzljnilFh+3vvFH5g6s4jPSP87ID FdEpTmbg1049cXGKAxVQ/YjWmB756+lcO7JcbSrJfXs= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 47E527E1D4 for ; Wed, 26 Apr 2017 10:51:50 -0400 (EDT) Received: from mail-qt0-f179.google.com (unknown [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id CAA9E7E1D0 for ; Wed, 26 Apr 2017 10:51:49 -0400 (EDT) Received: by mail-qt0-f179.google.com with SMTP id c45so2609380qtb.1 for ; Wed, 26 Apr 2017 07:51:49 -0700 (PDT) X-Gm-Message-State: AN3rC/4ztTNO3MkcgL6FYmILxT7VABbTH0T26+abdfQok1GB18XjTmIO TRMJoXEwoSoziJkglLMVOOrAz68TGQ== X-Received: by 10.200.3.103 with SMTP id w39mr201803qtg.6.1493218309433; Wed, 26 Apr 2017 07:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.40.180 with HTTP; Wed, 26 Apr 2017 07:51:29 -0700 (PDT) From: "C. M. Heard" Date: Wed, 26 Apr 2017 07:51:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Destination options and denial of service attack To: 6man WG Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: E0CE9BE4-2A8F-11E7-B4B3-C260AE2156B6-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 14:52:00 -0000 On Wed, 26 Apr 2017 10:52:58 +0200 Peter Hessler wrote: > On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote: > :AFAICT from reading > :2640bis a host must process all extension headers and must process all > :destination options in a packet. A host must also process all hop-by-hop options as well, as is made clear by the new proposed extension header text for 2460bis: https://www.ietf.org/mail-archive/web/ipv6/current/msg27144.html > There are many firewalls deployed in the wild that by default drop all > IPv6 packets with extension headers. > > That avoids the DoS condition. That is not a terribly satisfactory answer. RFC 7045 was published by this WG precisely to discourage such behavior. Per Section 2.1 of that RFC, the filtering behavior MUST be configurable, and the default SHOULD be to accept all standard extension headers, including the Hop-by-Hop Options header and the Destination Options header. Mike Heard From nobody Wed Apr 26 08:09:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15212EC4B for ; Wed, 26 Apr 2017 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 yaS7hEVSrNez for ; Wed, 26 Apr 2017 08:09:43 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776EA12EC4A for ; Wed, 26 Apr 2017 08:09:43 -0700 (PDT) Received: from dooku.sandelman.ca (cl-27.chi-03.us.sixxs.net [IPv6:2604:8800:100:1a::2]) by relay.sandelman.ca (Postfix) with ESMTPS id 400081F8EE; Wed, 26 Apr 2017 15:09:42 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 17CEC58D; Wed, 26 Apr 2017 11:09:40 -0400 (EDT) From: Michael Richardson To: Bob Hinden cc: IPv6 List , Eric Rescorla Subject: Re: Revised and expanded rfc2460bis Security Considerations In-reply-to: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> Comments: In-reply-to Bob Hinden message dated "Wed, 19 Apr 2017 13:55:07 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 26 Apr 2017 11:09:40 -0400 Message-ID: <1520.1493219380@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:09:46 -0000 --=-=-= Content-Type: text/plain Bob Hinden wrote: > IPv6 packets can be protected from eavesdropping, packet > modification, replay, and man in the middle attacks by use of the > "Security Architecture for the Internet Protocol" [RFC4301]. In > addition, upper-layer protocols such as TLS or SSH can be used to > protect the application layer traffic running on top of IPv6. I agree with the AD's suggestion that TLS and SSH become informative references. I think that it is appropriate to include this reference here, even if it comes across as "Not my problem" :-) I think that a reference to BCP146, RFC5406 should be included along with RFC4301. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZALgzAAoJEJVM4Vb9/EKQqJcH/2pBsDnv2Xv9nHeBRc5/D5Ey xEzTCu95JfLpogTN+ZHx4Qu50MVkIdcpjmUPaQouUm3QsWoteh7gZZolRI5+7XrE M3w5jXdJyX3vmcE1AFT5/xM9F5n/+s1kVYA/cZwgovn7Bt8aTpv6yVIJA/i7dNNK vTh0O08OqNOo2wIfGb+irLYEJ+nZnM9EFvoRJ3Hkg5HeFe4KFutsG+rLQe9ZWRll 13Bqzowp7y5V3lBZhC/rA7xflwy7+Q9rRWu4LGW1ucZL1v0bBMCi1Df6OLAY914w FUAPH3um6k/Hxd7lL7DJdBTC7mSASDOP4bhr1DmsGyCmvboBUvP2F4iiZo1HGbQ= =z8XW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 26 08:14:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8A12EC69 for ; Wed, 26 Apr 2017 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Swzecf3wJcBO for ; Wed, 26 Apr 2017 08:14:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAC512EC3F for ; Wed, 26 Apr 2017 08:14:18 -0700 (PDT) Received: from dooku.sandelman.ca (otwaon0812w-lp140-01-64-229-175-123.dsl.bell.ca [64.229.175.123]) by relay.sandelman.ca (Postfix) with ESMTPS id 0F1841F8EE; Wed, 26 Apr 2017 15:14:17 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2044058D; Wed, 26 Apr 2017 11:14:16 -0400 (EDT) From: Michael Richardson To: Fernando Gont cc: Eric Rescorla , IPv6 List , Bob Hinden Subject: Re: Revised and expanded rfc2460bis Security Considerations In-reply-to: <6cc8ec3f-f978-838e-5caa-37510e929220@si6networks.com> References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <6cc8ec3f-f978-838e-5caa-37510e929220@si6networks.com> Comments: In-reply-to Fernando Gont message dated "Thu, 20 Apr 2017 14:20:57 +0100." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 26 Apr 2017 11:14:16 -0400 Message-ID: <1875.1493219656@dooku.sandelman.ca> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:14:24 -0000 --=-=-= Content-Type: text/plain Fernando Gont wrote: >> Yes, but there are mechanisms for protecting the content which do not >> protect the metadata, so it's useful to call them both out. > Fully agreed. Just meant that the statement above seemed to suggest > that an eavesdropper can only see the metadata. -- I know that's not > what the authors meant. Just that it might be read as such. I think that there are situations where only the metadata is passed to the eavesdropper. The simplest is running an old version tcpdump with a default snaplen :-). Since tcpdump 4.x ish the default is entire packet. {A legitimate police request for a "pen registry" tap ought to show IP header only. Those kinds of requests have historically not required court orders} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZALlHAAoJEJVM4Vb9/EKQUV0IAIu0cmb63zDb8NOIYqrqkUd5 cQWX+b+VS1OL6mChmRsYwLqCATmW9L8XIKlswbGTot6QiIKJRl1HCH7coDYml4b1 /g2egP7uerHi1hPh+0QmiVscS2serQ1uxnWsvHspCQTg9+V81QKg/ZjbX0aQjstx SHb/uTdFRRiJijaF9u+6rZIS2LzEUKMy2S0oFC5Ms6DWxBGcuey6gUu3PgEOjckx +mXrOyu2oOuDHzbXw/7kOJHKLi9t9JF3KA/4eghkSG6YrVKNtmPZ1fzUTT0CuiWj OeyHd9gfrtey+R+6DjPO7QOUJz6yDS7JueiE0uPsnOpopiGMasNS4Y91e9Ob9X8= =UN/c -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 26 08:40:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D861300F0 for ; Wed, 26 Apr 2017 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 fXE5h6m_pDOZ for ; Wed, 26 Apr 2017 08:40:18 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 1D83B12EC83 for ; Wed, 26 Apr 2017 08:40:18 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l50so2382201wrc.3 for ; Wed, 26 Apr 2017 08:40:18 -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=x19E8TvtCJConBHMc63nfzkh53Y5SYNGkXbOmbcAiFg=; b=k6DYgRHnJraPYGrt74ps51b+Hu5LpsHGyQMSlwkjQfXLn2ObmmEP0GoFmcEFbAcrpJ WCABVCllHnewCHMFqRfVMMpRkvZLrV0zEYYRwXD19WagOKrOp7o3aRWYMWAklkIKlMO7 aBeccnU+Y4vWZ9oAfxwsUoQZNZ1tsBL1SaFEZDr4+sYWy03W+ycBByvXkdr9yLIf8sfX 5Ax8RruiN685YuptA73LbTkEyd1uGzBGxlRySePZAlYLPC+Cz1qp6wQ+E2CiYmQYSBDm JQs2yh8siB+Y1xVPIyrcAk2u/W7T5Kacio3ukN9TDPNgGOVMw6G6WkuqhkwDW2Mvr2nq 6MQg== 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=x19E8TvtCJConBHMc63nfzkh53Y5SYNGkXbOmbcAiFg=; b=XnE4d2lSP6aQrGQz68/hQd4Ve/EJQh6PkVdVOSpefFASu0a/apEaNio8p6Asd+WlMf yP5VRf2hiyHU/0vJtVZwQZAN2+t8LPOFzLiBFY0BEC7ieoWjSoGWc9W5wB3MBgqtsBEz wYHRkZX34B4cCWft7lN6EXAITZvnqUZF4ktQtBslJuk0karb9Kom0bwETW3uGWeEv2FH sFP07oi7lSI5cqzQPQzU1XB+VvhmiyBAymR2ot1XVjFi871KynUbXFJOO/Gf+E+ttPz2 +GNAgVWDCw6usjIFdmhD2zPFldIHN6gQPlfiuXIQzqPSSFK/DqTGIUR8b7TwilguhLS+ 7UWQ== X-Gm-Message-State: AN3rC/4GF19t7xeZNN8mc0y2tsNz81jSqerGjIvAmSRT6ysm7EvYbLoL pkosw+YSv/rY6A== X-Received: by 10.223.153.116 with SMTP id x107mr285390wrb.55.1493221216431; Wed, 26 Apr 2017 08:40:16 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:5425:6c0a:d453:709? ([2601:647:4d01:db10:5425:6c0a:d453:709]) by smtp.gmail.com with ESMTPSA id y63sm9803631wme.31.2017.04.26.08.40.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 08:40:09 -0700 (PDT) From: Bob Hinden Message-Id: <67F595A2-532C-465A-82CC-53E573452238@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CB6DB174-A03B-460B-B6F0-3B0B6A77BACF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Proposed revised Extension Header text for rfc2460bis Date: Wed, 26 Apr 2017 08:40:03 -0700 In-Reply-To: <83FF75F2-AB2A-4DC4-B3E1-07D98E299797@jisc.ac.uk> Cc: Bob Hinden , IPv6 List To: Tim Chown References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <83FF75F2-AB2A-4DC4-B3E1-07D98E299797@jisc.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:40:21 -0000 --Apple-Mail=_CB6DB174-A03B-460B-B6F0-3B0B6A77BACF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tim, > On Apr 26, 2017, at 6:37 AM, Tim Chown wrote: >=20 > Hi, >=20 > I agree this text is much better. Just a couple of minor comments = below. Thanks >=20 >> On 24 Apr 2017, at 23:52, Bob Hinden wrote: >>=20 >> Hi, >>=20 >> After reading through the discussion about this text in Section 4, I = have some new text to propose. I think this is significantly improved = and should resolve many of the issued raised. >>=20 >> Changes include separate description of behaviors extension headers = and the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from = the first paragraph. I removed =E2=80=9Cexamine=E2=80=9D because I am = convinced it=E2=80=99s not sustainable to say a node can=E2=80=99t = examine extension given how widespread this behavior is. I also removed = the reference to RFC7045 because examine is removed. RFC7045 is = referenced in the recently updated Security Considerations section. >>=20 >> I removed the =E2=80=9Cincluding the source and destination nodes=E2=80= =9D text from the paragraph on the hop-by-hop options header because I = don=E2=80=99t think we need to mention the source, and there is a whole = paragraph describe what happens at the destination node. I also added = the text about from the first paragraph about reaching the destination = to the hop-by-hop header paragraph. >>=20 >> I also moved (without change) the =E2=80=9CAt the Destination = node...=E2=80=9D text from the first paragraph to a new third paragraph. = It applies to all extension headers. >>=20 >> CURRENT and NEW text below. Please review and comment. >>=20 >> Bob >>=20 >>=20 >> CURRENT >>=20 >> With one exception, extension headers are not examined, processed, >> inserted, or deleted by any node along a packet's delivery path, >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field = of >> the IPv6 header. Note: If an intermediate forwarding node examines >> an extension header for any reason, it must do so in accordance with >> the provisions of [RFC7045]. At the Destination node, normal >> demultiplexing on the Next Header field of the IPv6 header invokes >> the module to process the first extension header, or the upper-layer >> header if no extension header is present. The contents and = semantics >> of each extension header determine whether or not to proceed to the >> next header. Therefore, extension headers must be processed = strictly >> in the order they appear in the packet; a receiver must not, for >> example, scan through a packet looking for a particular kind of >> extension header and process that header prior to processing all >> preceding ones. >>=20 >> The exception referred to in the preceding paragraph is the Hop-by- >> Hop Options header, which carries information that may be examined >> and processed by every node along a packet's delivery path, = including >> the source and destination nodes. The Hop-by-Hop Options header, >> when present, must immediately follow the IPv6 header. Its presence >> is indicated by the value zero in the Next Header field of the IPv6 >> header. >>=20 >> NEW >>=20 >> Extension headers (except for the Hop-by-Hop Options header) are not >> processed, inserted, or deleted by any node along a packet's = delivery >> path, until the packet reaches the node (or each of the set of = nodes, >> in the case of multicast) identified in the Destination Address = field >> of the IPv6 header. >=20 > Actually, if we are rewriting this anyway, the multicast wording = should probably say =E2=80=9C(or, in the case of multicast, any node in = the multicast group)=E2=80=9D, else we=E2=80=99re suggesting actions = cannot be taken until each receiver has received its copy. I went back and looked at the previous RFCs. In both RFC2460 and = RFC1883, say: (or each of the set of nodes, in the case of multicast) So this text has been there a while and I don=E2=80=99t think it has = caused confusion. I understand you point, but think saying =E2=80=9Ceach=E2= =80=9D makes it clear. For example it doesn=E2=80=99t say =E2=80=9Call = nodes in the case of multicast=E2=80=9D. It would also be close to = impossible to implement =E2=80=9Cuntil each receiver has received its = copy=E2=80=9D. My preference is to not change it. >=20 >> The Hop-by-Hop Options header is not inserted or deleted, but may be >> examined and processed by every node along a packet's delivery path >=20 >> until the packet reaches the node (or each of the set of nodes, in >> the case of multicast) identified in the Destination Address field = of >=20 > The same comment again for multicast. >=20 >> the IPv6 header. The Hop-by-Hop Options header, when present, must >> immediately follow the IPv6 header. Its presence is indicated by = the >> value zero in the Next Header field of the IPv6 header. >>=20 >> At the Destination node, normal demultiplexing on the Next Header >> field of the IPv6 header invokes the module to process the first >> extension header, or the upper-layer header if no extension header = is >> present. The contents and semantics of each extension header >> determine whether or not to proceed to the next header. Therefore, >> extension headers must be processed strictly in the order they = appear >> in the packet; a receiver must not, for example, scan through a >> packet looking for a particular kind of extension header and process >> that header prior to processing all preceding ones. >=20 > There is also the NOTE: text to place: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. >=20 > This might fit better after the HbH paragraph above, rather than (as = it would be now) after the Destination node paragraph? I had planned to leave it following, but I agree it would be better = after the HbH paragraph. Thanks, Bob >=20 > Tim >=20 >>=20 >> END NEW >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 --Apple-Mail=_CB6DB174-A03B-460B-B6F0-3B0B6A77BACF 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZAL9UAAoJEK7rdBF357uo4tYH/3b6JyWB/vJj+gROnwx7JSs8 WYKe0t+uNij/a6FTIvyjbjFNTmtT9QxBtuh1fLcCylKEve6354m/cAZ58O1ckGlj sby9moNwNt3toM3tNSIigMi/WTuzfwK8k8OxuKoz3OYEQCxbQXnE8+3Cnl0RJSci MRgkoXWZf63Lsd4q+Pd8Fxo1MYT2EmJ9i+MyCdy/6N9FVqTYyZE8s407BidUnQur 7vdF3TXQ85TXqd4XzUkVJPYjxd4fX1vC+40m4Wi38wpryCoqmdfygLDBHLSo20xk A5FGyk2jN8QMQ9T7WDvxqFJnZqFO3TQwgqgkq1MdzjpYcaJ3ba+L9Hf9EA6GBO8= =hx8D -----END PGP SIGNATURE----- --Apple-Mail=_CB6DB174-A03B-460B-B6F0-3B0B6A77BACF-- From nobody Wed Apr 26 09:20:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00D51314B5 for ; Wed, 26 Apr 2017 09:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 P6KFdKbsqDbk for ; Wed, 26 Apr 2017 09:20:47 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 DE2131314B7 for ; Wed, 26 Apr 2017 09:20:46 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id l50so3030735wrc.3 for ; Wed, 26 Apr 2017 09:20:46 -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=xJpKMvYaMy429SRA7iPYZSHd0skGsp1LdDNAfvzvZW4=; b=BYuzIuE5QpC4ZCUfpdHyFCstgFj8oN+ZA5+VPW2cPRYeS9pFSRmyA7DuKHJ+PmczZi qusO2WHoxtCRFbiH8q2Yz25PiN61WlxX23IjahpFFL5pYZTZSmGASldo6shNSxG1PoIb q05FcQgPNBala/vi162PQm76Or6xZmQc9wcz17VneiLs1istNK0MimJQsBmbULQV22+n usjMwhi3l3m6GoCmWvUdSnWaGqbmAM9TAw5UjwWTmq4x+ehe6KNFmyNZyI0LSeOQtaOa /TAgaN5b98/kidDUFDRvW5mgYKgCVkUeUFupPTxbiVnhIPsNwW3MKbJITrvJlP4ertsh s6dA== 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=xJpKMvYaMy429SRA7iPYZSHd0skGsp1LdDNAfvzvZW4=; b=WStLxMF1K3jPBiNuGXo9ClmhIkghJIek/QZngMr2VLUnNx3E7a4DPyajKvw8mtizJG e3bIGiUS9bh9EeiaAp0rFNDGfElGcv7JfEVHcvVTQtNkdW3uSLG1KEWK+v0BM2NvXOXf yhdhBo309y23Bw5uSzOSn6FylTpZ6kL8QVe/JVYHSd1l5d2ZtySbwyixM72yxSILbsGG h9CjR3RTadfyg28MB+1BKmXTh8EcwbTCD/BKc4F+yyhAtieRPn07ApnS1jxvNJVL6Sup tiC2Xnw380zRHJLYwy775iE+w7gHMh0j00x7QaR2dZcWzyDugSCO6gTAEdVwkvaTzwqh lQ8w== X-Gm-Message-State: AN3rC/6ZSBofuhrVr9wxwSv7zKG2wK4lCf7WoFy8uljV7z5KB7BoiJgX FhTuHuQs0ysGpAYGYms= X-Received: by 10.223.136.75 with SMTP id e11mr478880wre.14.1493223645437; Wed, 26 Apr 2017 09:20:45 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:5425:6c0a:d453:709? ([2601:647:4d01:db10:5425:6c0a:d453:709]) by smtp.gmail.com with ESMTPSA id l68sm792586wrc.52.2017.04.26.09.20.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 09:20:43 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9F0DA90A-6314-4747-AFF2-1D3DF8C1C71D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Revised and expanded rfc2460bis Security Considerations Date: Wed, 26 Apr 2017 09:20:38 -0700 In-Reply-To: <1520.1493219380@dooku.sandelman.ca> Cc: Bob Hinden , IPv6 List , Eric Rescorla To: Michael Richardson References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <1520.1493219380@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:20:49 -0000 --Apple-Mail=_9F0DA90A-6314-4747-AFF2-1D3DF8C1C71D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Michael, > On Apr 26, 2017, at 8:09 AM, Michael Richardson = wrote: >=20 >=20 > Bob Hinden wrote: >> IPv6 packets can be protected from eavesdropping, packet >> modification, replay, and man in the middle attacks by use of the >> "Security Architecture for the Internet Protocol" [RFC4301]. In >> addition, upper-layer protocols such as TLS or SSH can be used to >> protect the application layer traffic running on top of IPv6. >=20 > I agree with the AD's suggestion that TLS and SSH become informative > references. I think that it is appropriate to include this reference = here, > even if it comes across as "Not my problem" :-) >=20 > I think that a reference to BCP146, RFC5406 should be included along = with > RFC4301. While adding a few more references isn=E2=80=99t a big deal, I don=E2=80=99= t see very much value having a reference to TLS and SSH in the IPv6 = specification. TLS and SSH are very well known, and are even listed in = the RFC Editor Abbreviations List. Is there anyone implementing IPv6 = who doesn=E2=80=99t know what these are? Also, this text is just citing two ways to protect application data. Bob --Apple-Mail=_9F0DA90A-6314-4747-AFF2-1D3DF8C1C71D 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZAMjWAAoJEK7rdBF357uo2pQIAIBf4LSe0CbD/6BJcu97B1wn De945jyjEmFBpZF8JAQerOpN3cQMTn4ird/aSocHhNL9L6J9RAmtloy9j+tn0+Pe 3VTLcR231pBtnd+4Ca2KSlElUgKjV5BLL/LYnrW4VsWcmrhshhZQnwem0TZF6rKd B/0mWuE6729jnPn6d2/CMDA9jGAuxGTFlU8kaRVeRatOm7SKYxWRJYyyEPnfaacW xLnjQOYybGJcDgXE07Bql597sn6wJ4x/HteXIn4eQMFzSAlKunllgTIh0tGmV1OJ 69k0gQvzXMaT66FCTtqu3oR8azM2MY7Ver1fq5z0IQUYwbjWJcCT57tpCdrRi+0= =2AHE -----END PGP SIGNATURE----- --Apple-Mail=_9F0DA90A-6314-4747-AFF2-1D3DF8C1C71D-- From nobody Wed Apr 26 09:30:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C4E1314CC for ; Wed, 26 Apr 2017 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgLVlyRVrVND for ; Wed, 26 Apr 2017 09:30:28 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 22E7C1314C9 for ; Wed, 26 Apr 2017 09:30:28 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c45so5244470qtb.1 for ; Wed, 26 Apr 2017 09:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VdHAFgpaooC3l2CmwX2M5i8GFQMxtd8Sxy9WXUZXdNA=; b=wW4Yf6enB5uQoptFhtxzUb6CnVyzYLeYLmnUT0NwmgGSVG0v/ikzjddTbfcTrq5JPo Bov/v60jDMiBmSGf2MjnYbgFm+9b7obcuafSCYfIKDsw6pKa+WcZ8x0fNYnmKPL9lRGU S6GydrKzTsx9xZbsjOa6JYzGr00D0rcfU/D1pduFz7WFKBP7r6x/TWlAmtUWviX4I0K4 VbfTRl5Xzi+EMrsVOEen0gkRWAfS+hUpJ/mRV+BPzQufR3v0WejBZc2G6BG0NeoDRsyc T3JmENJ9lSzmdnBkTjjiLvifpOtr+mWbAaH5FlIFvHWrW/Hx2yLryf9pbtOUv2McrzOc bQpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VdHAFgpaooC3l2CmwX2M5i8GFQMxtd8Sxy9WXUZXdNA=; b=fZujxFN77FxwrKmbUhdAZpVdbCgFCgtMfJt3Xv5szS0NlGpl1C/d/V09JJpAyucy74 Zbi3NPdtql2T/hDEBrES3A75nXYTdE6c9a6d+E6S4vdaJKhx5TZW2VwX8VVoHeegdsQH 3Y8zR2FrgncpMRx9Li5LoUBzKpiPHdZrDzCDUA5PMx2XunwOIr4RcyAVkR7hAMrzh3ko c5lFmG879WXM03P0vqNWWB3lPUshkb/hlpMFpfNC9mYTjBKHoUKvhQeYZgPRc8ScvS0q 6v5T6HOkM0nv8iFWqecL0vm4grw66B59SRGyQQ91fCLsy2ABbZRv+ljGCne+Qb2IEjnR XKYg== X-Gm-Message-State: AN3rC/5G6jEhcrHpflvgV9U8Kw82KrTOYuIIVjm/0zMLIHZWnDKxU8hT 25zav7fRWr+joyIKtf0xl6y0e4fXZg== X-Received: by 10.237.62.150 with SMTP id n22mr699427qtf.70.1493224227093; Wed, 26 Apr 2017 09:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 26 Apr 2017 09:30:26 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Wed, 26 Apr 2017 09:30:26 -0700 Message-ID: Subject: Re: Destination options and denial of service attack To: "C. M. Heard" Cc: 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:30:30 -0000 On Wed, Apr 26, 2017 at 7:51 AM, C. M. Heard wrote: > On Wed, 26 Apr 2017 10:52:58 +0200 Peter Hessler wrote: >> On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote: >> :AFAICT from reading >> :2640bis a host must process all extension headers and must process all >> :destination options in a packet. > > A host must also process all hop-by-hop options as well, as is made > clear by the new proposed extension header text for 2460bis: > > https://www.ietf.org/mail-archive/web/ipv6/current/msg27144.html > >> There are many firewalls deployed in the wild that by default drop all >> IPv6 packets with extension headers. >> >> That avoids the DoS condition. > > That is not a terribly satisfactory answer. RFC 7045 was published by > this WG precisely to discourage such behavior. Per Section 2.1 of that > RFC, the filtering behavior MUST be configurable, and the default SHOULD > be to accept all standard extension headers, including the Hop-by-Hop > Options header and the Destination Options header. > RFC 7045 refers only to behavior of intermediate nodes processing extension headers not end hosts. There is no requirement that hosts live behind a firewall, so even if firewalls do drop packets with EH that doesn't solve the host-side problem. It may be true that firewall blocking EH may be enough (so far) to make a wide scale DOS attack ineffective. Dropping all packets with EH at the host (or intermediate node for that matter) is not the right solution. We need a way to differentiate a legitimate use of options from one that is likely illegitimate-- a packet with 1282 TLVs is clearly an illegitimate use case! This seems to imply that we need to place some limits on the options, for instance how many destination options a host is willing to process. Unfortunately, I don't see any way to do this without violating the spec. Tom > Mike Heard > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Apr 26 09:30:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BA01314D7 for ; Wed, 26 Apr 2017 09:30:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UGTWyan0cpm for ; Wed, 26 Apr 2017 09:30:35 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 8C0B61314CE for ; Wed, 26 Apr 2017 09:30:35 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 8so1567585ybw.1 for ; Wed, 26 Apr 2017 09:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mY4Vi5MgBDtLAPkaVZy6/cmCH4yyLZaNvs1dtS1uRL0=; b=twg9prIOZqUD6raIC0dNY5AhvOeqXsaYLPRunrIzRxkT8Xm4FztgY5nzCw+QHfarZV IRN5eklmO0SQRSMZ9gVaU1HNsjhthiXH4fsi+Q0ikrK/nMin0CqtfGyipOY6zz/gqZyr kPSO/pkmhhvmWu1OD9/lFxVzjNAzFkwQLtdDYQSDgrj8EzUqei3eX/BGbC42Co/Mwkr0 DUy/Cy6azhUbMYxi3cn0pHEAEGppmdV+vANrXGyylsJONFx/8Txe8MFXggxID8b5psPf K8Fq7WYfdkedBS+Bo3V5aPdgEDEcHKiape7ZvSTrfdsLa2fhJcTRyvtjbFdzN2U/LZvq GeKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mY4Vi5MgBDtLAPkaVZy6/cmCH4yyLZaNvs1dtS1uRL0=; b=Yxf+ecYsXkFFiR/KJQDqQw2xs9BdewsidRdT+knmsWRRXH4Hmq2GTHsNvqEfmvyZig /sd68wvWfdV8mDqW9zWEWClgVH69/VVAwXCExVD70Umn33uB8yOMg4fQBUiFUTKnFOuB 5Hg7BjmgFDQRv4xbNdU79dy05UagkgR+1NpJs7KF6u/oiA3NHc7HN+f88WKanDyva55d xF6iBcw1uc6dqXtezgt0ewqWfNZjhrpHqrx/C3TzVh8dpX/+leglRoVC6hA07I0P4G0Z 6sHbaA/nuUsLb2RjYmd0Pfpa0z8HgTUxicQHXM9lkfmfCNxqJSVb9Ue8NWJ9sCrmyguL k6mQ== X-Gm-Message-State: AN3rC/5YSFD/tW+xjyoGmX28D8S08izXAM3bolqRT2KNDHLGg1Z/Hy1y mdV+RqmEZQ/XOrHOcdGhqiLJCK5Jqg== X-Received: by 10.37.161.196 with SMTP id a62mr596162ybi.9.1493224234692; Wed, 26 Apr 2017 09:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 26 Apr 2017 09:29:54 -0700 (PDT) In-Reply-To: References: <39446C20-CD22-4903-9514-3F9A4788609B@gmail.com> <1520.1493219380@dooku.sandelman.ca> From: Eric Rescorla Date: Wed, 26 Apr 2017 09:29:54 -0700 Message-ID: Subject: Re: Revised and expanded rfc2460bis Security Considerations To: Bob Hinden Cc: Michael Richardson , IPv6 List Content-Type: multipart/alternative; boundary=f403045c563214481d054e145cbd Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:30:37 -0000 --f403045c563214481d054e145cbd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am fine with or without a reference. On Wed, Apr 26, 2017 at 9:20 AM, Bob Hinden wrote: > Michael, > > > On Apr 26, 2017, at 8:09 AM, Michael Richardson > wrote: > > > > > > Bob Hinden wrote: > >> IPv6 packets can be protected from eavesdropping, packet > >> modification, replay, and man in the middle attacks by use of the > >> "Security Architecture for the Internet Protocol" [RFC4301]. In > >> addition, upper-layer protocols such as TLS or SSH can be used to > >> protect the application layer traffic running on top of IPv6. > > > > I agree with the AD's suggestion that TLS and SSH become informative > > references. I think that it is appropriate to include this reference > here, > > even if it comes across as "Not my problem" :-) > > > > I think that a reference to BCP146, RFC5406 should be included along wi= th > > RFC4301. > > While adding a few more references isn=E2=80=99t a big deal, I don=E2=80= =99t see very much > value having a reference to TLS and SSH in the IPv6 specification. TLS a= nd > SSH are very well known, and are even listed in the RFC Editor > Abbreviations List. Is there anyone implementing IPv6 who doesn=E2=80=99= t know > what these are? > > Also, this text is just citing two ways to protect application data. > > Bob > > > --f403045c563214481d054e145cbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with or without a reference.


On Wed, Apr 26, = 2017 at 9:20 AM, Bob Hinden <bob.hinden@gmail.com> wrote:=
Michael,

> On Apr 26, 2017, at 8:09 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Bob Hinden <bob.hinden@gmai= l.com> wrote:
>>=C2=A0 =C2=A0IPv6 packets can be protected from eavesdropping, pack= et
>> modification, replay, and man in the middle attacks by use of the<= br> >> "Security Architecture for the Internet Protocol" [RFC43= 01].=C2=A0 In
>> addition, upper-layer protocols such as TLS or SSH can be used to<= br> >> protect the application layer traffic running on top of IPv6.
>
> I agree with the AD's suggestion that TLS and SSH become informati= ve
> references.=C2=A0 I think that it is appropriate to include this refer= ence here,
> even if it comes across as "Not my problem" :-)
>
> I think that a reference to BCP146, RFC5406 should be included along w= ith
> RFC4301.

While adding a few more references isn=E2=80=99t a big deal, I don= =E2=80=99t see very much value having a reference to TLS and SSH in the IPv= 6 specification.=C2=A0 TLS and SSH are very well known, and are even listed= in the RFC Editor Abbreviations List.=C2=A0 Is there anyone implementing I= Pv6 who doesn=E2=80=99t know what these are?

Also, this text is just citing two ways to protect application data.

Bob



--f403045c563214481d054e145cbd-- From nobody Wed Apr 26 09:57:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0980129557 for ; Wed, 26 Apr 2017 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 lXADGv7TY1_R for ; Wed, 26 Apr 2017 09:57:16 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 82ABC1270A3 for ; Wed, 26 Apr 2017 09:57:16 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id z52so3595853wrc.2 for ; Wed, 26 Apr 2017 09:57:16 -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=5MFmPxZIIhtwzQLvrnRQ/BE8iWuQYdZVOWQD3INFxI8=; b=oLYDSFI4hdcfNjohjR2xBUvDX4msPhZrPJqs8OF31WdmrysIGhlBgcq3R/ZU7qG4s9 Mxf2/8sm32chPdJg0/i7V79pTAPsdibDvgkOIh5RvHJsIX9Jj4LINChY/mzL8mnqrv2e dQnuegL0zgvwoVWNXE1MENOMRcA0uec2iGVBz+CiIVvGJCq/bMSh47PirAhAfsR4zNJ/ h2Nx9LdKyLQH2/ipTf4wmJ0YYHYXXEjYN83B9PQGKhX593r0UWzWj+ddAVyus7AW2LOX DGi6YniG0gcCr6k9dzR8kXa870WnuBxzDmgUFsDbUVfbimhH5b0GVHCOHmGMEg85FTFS Ga5g== 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=5MFmPxZIIhtwzQLvrnRQ/BE8iWuQYdZVOWQD3INFxI8=; b=YxXYElBqe93M/5VWUCKYpLd0+zzEt16l6N/N83Kx9m6LbZEmH+abuuwYFIyrzPWGYV VXo92/kOWUEkrfVCjX1DasI1wcNr8Zebz8EJYN5/C+3RnPTS/JGcV+kDQNr9+Iy2UDMn 6h2G9vUD3ezPkvDd4lIC1dzVnlDC2RGL/kdOON/USs15DlbNdY9QRcPiQYm8EAppzxYQ od1jVaXuL1nDcJ3+n7ZIWuwEB6kL3vbeT69Uih8fXtY76mp9tDZtqiXBXKh4duj4bW4h cSCtftjy6qQ7/Hhk/pOWb6acNc5YdhAJrE8m0Ne4kBv90Oj/ZgN8bxNdrfB6beGvySP+ D0Kg== X-Gm-Message-State: AN3rC/4lvaBkFS1k0DJR0xfnjbQ5G+d/IpT2J4VhJCeRmtMxr0oXXOut mgkLpyxo0QZmbBBoohg= X-Received: by 10.223.179.93 with SMTP id k29mr522829wrd.23.1493225835043; Wed, 26 Apr 2017 09:57:15 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:5425:6c0a:d453:709? ([2601:647:4d01:db10:5425:6c0a:d453:709]) by smtp.gmail.com with ESMTPSA id t2sm155867wme.16.2017.04.26.09.57.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 09:57:13 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F8405BB7-A06B-45EE-869D-C0E550C48F68"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Destination options and denial of service attack Date: Wed, 26 Apr 2017 09:57:07 -0700 In-Reply-To: Cc: Bob Hinden , "C. M. Heard" , IPv6 List To: Tom Herbert References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:57:19 -0000 --Apple-Mail=_F8405BB7-A06B-45EE-869D-C0E550C48F68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, > On Apr 26, 2017, at 9:30 AM, Tom Herbert wrote: >=20 > On Wed, Apr 26, 2017 at 7:51 AM, C. M. Heard wrote: >> On Wed, 26 Apr 2017 10:52:58 +0200 Peter Hessler wrote: >>> On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote: >>> :AFAICT from reading >>> :2640bis a host must process all extension headers and must process = all >>> :destination options in a packet. >>=20 >> A host must also process all hop-by-hop options as well, as is made >> clear by the new proposed extension header text for 2460bis: >>=20 >> https://www.ietf.org/mail-archive/web/ipv6/current/msg27144.html >>=20 >>> There are many firewalls deployed in the wild that by default drop = all >>> IPv6 packets with extension headers. >>>=20 >>> That avoids the DoS condition. >>=20 >> That is not a terribly satisfactory answer. RFC 7045 was published by >> this WG precisely to discourage such behavior. Per Section 2.1 of = that >> RFC, the filtering behavior MUST be configurable, and the default = SHOULD >> be to accept all standard extension headers, including the Hop-by-Hop >> Options header and the Destination Options header. >>=20 > RFC 7045 refers only to behavior of intermediate nodes processing > extension headers not end hosts. There is no requirement that hosts > live behind a firewall, so even if firewalls do drop packets with EH > that doesn't solve the host-side problem. It may be true that firewall > blocking EH may be enough (so far) to make a wide scale DOS attack > ineffective. >=20 > Dropping all packets with EH at the host (or intermediate node for > that matter) is not the right solution. We need a way to differentiate > a legitimate use of options from one that is likely illegitimate-- a > packet with 1282 TLVs is clearly an illegitimate use case! This seems > to imply that we need to place some limits on the options, for > instance how many destination options a host is willing to process. > Unfortunately, I don't see any way to do this without violating the > spec. >=20 Most DDOS attacks I am aware of all send legitimate traffic. They = attempt to overwhelm the target. So while I agree that at some level protecting against these kinds of = attacks are technical violations of some specifications, for example = IPv6, TCP, DNS, TLS, etc., in practice they aren=E2=80=99t. A single = packet doesn=E2=80=99t make for an attack, it many packets from many = sources. Protecting against DDOS attacks requires looking at the = overall attack patter. Further, at least any DDOS attacks using 1282 TLVs is pretty easy to = detect and block since it=E2=80=99s such an outlier, as compared to = simple attacks that use very generic packets that can=E2=80=99t be = differentiated from non-attack traffic. Bob --Apple-Mail=_F8405BB7-A06B-45EE-869D-C0E550C48F68 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZANFkAAoJEK7rdBF357uoSp8H/0LpfW3ICCP17Ei5ThFn1NKe PSqQRvF/84wWagPrbjktQIihNcCI2JOOM9Md0/p7rdxLd/Ev/CJkbcK96rIXm4mK BJFqFGv1TI+OcrUJLQmlF90ECawKz17cTB5Oepm/lq1ICeJw23p8A1NQLKWg8L+q sJouGu4KGMRSUFtrlhZPOQH3FXUfo8I3Lk55PYGT58IgMy2nmfHdI48rCHUDLmMs rPGQY1XuErx1/HHT3V9vARbUoDMaeJI1LhqAF6pyLoIsr8zyVGJmN2YNXeMXXEz6 DHbrdKC51xEs5Rl2EPWUquDOYXgBjeEu70M3PV3tHtUNH5QG2LNF8sm0fC6eduQ= =XgBx -----END PGP SIGNATURE----- --Apple-Mail=_F8405BB7-A06B-45EE-869D-C0E550C48F68-- From nobody Wed Apr 26 11:22:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1550131565 for ; Wed, 26 Apr 2017 11:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgC_yLAZf2nf for ; Wed, 26 Apr 2017 11:22:00 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9AAEC131576 for ; Wed, 26 Apr 2017 11:21:49 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c45so7922526qtb.1 for ; Wed, 26 Apr 2017 11:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mljWfihvlAIDdprIA9qkEATsNBFaD9jFmU0UCiknt/g=; b=JKIF0nJnsIErpj9kkZ5nRLC7/NYsw0RRJbAQcAbgJOsS/gZcTLGEpKotdklHEzbVuA zP7UbIkW2SM2VgTEKu3O1/mJFjt/+ECtJLWE+rqCUB1/n5fv5xeoG5x/On+CwA6m/bub yyhc4LnVKP9k5bOElztMZhAbgztFz3SfYABPu7CCjlsDbXtY/sDvRuYcOxmCZwutleU9 yZyuj77CKZzWgIy90BH7B6Jx9Z5+IwpsrxBKKHga3ljrihH7I2yQtgrnUiC9nO2HJI9o Sdvro1Ir8hjK2bvdYUHLeiIcu8lLkoOgIdrsso/cPpSRFbspDAv6oV1J63hGazzQJWtq Fz5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mljWfihvlAIDdprIA9qkEATsNBFaD9jFmU0UCiknt/g=; b=W057lSoTSfHFN0345uJFmSxhyHcFYOOH8LWkdVZMjXkGGUpcHcKzCOM1ANQ1vdU2o+ tBW/fqtzPZWWg7s/qnwL9nRT2vhZJVt8rGXNZDY/IMw7/GK2ygHVJaNEBPZzvTyDEwji 5gJgACIqcnsbEAwPVzSSn3DYJaHlFWCmLJrmdrnNB3VopiEuwYVq6rXqVqGXsTMqtIb2 MVtcP6I4CXDBbq6modMq0yg/iHzsb5YhJYHikt8WI5GrwbBF4ZwuP5JynSDp1J1wYiIe XAoa2ZdMvzazVkXIpw8FGz4IrdVjw84gY0+dTTCr/xxuVaQ/t0xXrx8gXMGcJNIB6Z5c Q61g== X-Gm-Message-State: AN3rC/6a7RlEn86em0HlE+qi6uf/i8PjS4keDswiHCiOFu8y3xHgs70N tX6FEr30mYo7E6KJ/Ff3Evd2mDbycA== X-Received: by 10.200.55.15 with SMTP id o15mr1116753qtb.279.1493230908691; Wed, 26 Apr 2017 11:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 26 Apr 2017 11:21:48 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Wed, 26 Apr 2017 11:21:48 -0700 Message-ID: Subject: Re: Destination options and denial of service attack To: Bob Hinden Cc: "C. M. Heard" , IPv6 List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:22:02 -0000 On Wed, Apr 26, 2017 at 9:57 AM, Bob Hinden wrote: > Tom, > >> On Apr 26, 2017, at 9:30 AM, Tom Herbert wrote: >> >> On Wed, Apr 26, 2017 at 7:51 AM, C. M. Heard wrote: >>> On Wed, 26 Apr 2017 10:52:58 +0200 Peter Hessler wrote: >>>> On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote: >>>> :AFAICT from reading >>>> :2640bis a host must process all extension headers and must process al= l >>>> :destination options in a packet. >>> >>> A host must also process all hop-by-hop options as well, as is made >>> clear by the new proposed extension header text for 2460bis: >>> >>> https://www.ietf.org/mail-archive/web/ipv6/current/msg27144.html >>> >>>> There are many firewalls deployed in the wild that by default drop all >>>> IPv6 packets with extension headers. >>>> >>>> That avoids the DoS condition. >>> >>> That is not a terribly satisfactory answer. RFC 7045 was published by >>> this WG precisely to discourage such behavior. Per Section 2.1 of that >>> RFC, the filtering behavior MUST be configurable, and the default SHOUL= D >>> be to accept all standard extension headers, including the Hop-by-Hop >>> Options header and the Destination Options header. >>> >> RFC 7045 refers only to behavior of intermediate nodes processing >> extension headers not end hosts. There is no requirement that hosts >> live behind a firewall, so even if firewalls do drop packets with EH >> that doesn't solve the host-side problem. It may be true that firewall >> blocking EH may be enough (so far) to make a wide scale DOS attack >> ineffective. >> >> Dropping all packets with EH at the host (or intermediate node for >> that matter) is not the right solution. We need a way to differentiate >> a legitimate use of options from one that is likely illegitimate-- a >> packet with 1282 TLVs is clearly an illegitimate use case! This seems >> to imply that we need to place some limits on the options, for >> instance how many destination options a host is willing to process. >> Unfortunately, I don't see any way to do this without violating the >> spec. >> > > Most DDOS attacks I am aware of all send legitimate traffic. They attemp= t to overwhelm the target. > > So while I agree that at some level protecting against these kinds of att= acks are technical violations of some specifications, for example IPv6, TCP= , DNS, TLS, etc., in practice they aren=E2=80=99t. A single packet doesn= =E2=80=99t make for an attack, it many packets from many sources. Protecti= ng against DDOS attacks requires looking at the overall attack patter. > Right, but IPv6 is stateless so that analyzing an attack may require new state and resource monitoring that may be prohibitive to implement on low end devices (IoT devices for instance). I think the simplest approach is to create an OS configurable limit for number of non-pad TLVs with a reasonable default, maybe something like five or ten of them. This is at least better then unilaterally blocking all packets with extension headers. Tom From nobody Wed Apr 26 11:31:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4358F1201FA for ; Wed, 26 Apr 2017 11:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 jTSJ8AE3meuH for ; Wed, 26 Apr 2017 11:31:10 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 802CD13013D for ; Wed, 26 Apr 2017 11:31:10 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id g66so44785465ite.1 for ; Wed, 26 Apr 2017 11:31:10 -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=qQJT+kJdAHHM0SRRrQQBDrLO4wbU2sRO7fU42PoL/9U=; b=fnKMOscaPoihvvUe4jynuVjuOfgt6Gg41TmWPN8M8iDn+oujmIKhQQkYoX5YdGdgRL q7QnrwCleAe2JOD/FbRxF8ZerNDE33SfTh93IojgJa5O/+SmW5XFXXsq/FhYS5DUDwrK uobYxlzZLrdaVsdpbVtd1CbEY9H9PTeoYOCAKkIBABPv+SOqUafV0aMXHA6QDaeDiVuM 7s1yYc4sS/rShhkxZh2bYrk7NGkRaJ9WSild4eg1H7CFgYvM6hcrMQlUBgN+9uuAQs3D FsZtzPWyjN2/QPvKTbW3fghRww3EUVEjKvTyl8PPD3pmJOaJr03xjRUNPCH831tz8UYF OLhA== 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=qQJT+kJdAHHM0SRRrQQBDrLO4wbU2sRO7fU42PoL/9U=; b=f0BlzMHl1FGqWlJlDlhcvjjYekjOBazwrgsc08INTSkcCITK24sYqqWoV4sSnWbjdy sHjkXY/JxhHeYDRb50p2fnJX0Hshei7Anb56colURwFnr4vzAHUSKLwyRb2tB1PpuqL3 fliqU2SOLstEF5dI4R82HdpoBtLFt5qC6J/BdyV8C/8+VV8aI7bUbLx1kxNyGMY4v777 YAxrbqw69YnqQmQ77UT0lo9Arwy3S7zhMod4SkSrPaTly3jtOpt4B9bvFdw1Ql+Qqxhc UDwX3148vSJkG9dJJX4s2xMZfzWmt+yJfWQvO0dJA2kDuIIt5hh4XVHwFh0wqun8F7Zb 9xEA== X-Gm-Message-State: AN3rC/70jfTGd+hDst+6AMjRGNVuQZ7pb95qzZdVuJ99OvM5xpsDUkWw l0jJ/gyUtf6Lq2RsYzo= X-Received: by 10.36.228.14 with SMTP id o14mr12654823ith.15.1493231469797; Wed, 26 Apr 2017 11:31:09 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g69sm173525itg.17.2017.04.26.11.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 11:31:08 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4CFB92C4-0A9F-4240-AEFF-FF26601F6580"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Destination options and denial of service attack Date: Wed, 26 Apr 2017 11:31:04 -0700 In-Reply-To: Cc: Bob Hinden , "C. M. Heard" , IPv6 List To: Tom Herbert References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:31:12 -0000 --Apple-Mail=_4CFB92C4-0A9F-4240-AEFF-FF26601F6580 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, > On Apr 26, 2017, at 11:21 AM, Tom Herbert wrote: >=20 >>=20 >>=20 > Right, but IPv6 is stateless so that analyzing an attack may require > new state and resource monitoring that may be prohibitive to implement > on low end devices (IoT devices for instance). I think the simplest > approach is to create an OS configurable limit for number of non-pad > TLVs with a reasonable default, maybe something like five or ten of > them. This is at least better then unilaterally blocking all packets > with extension headers. Something to consider for the node requirement update. Picking some = default values will be a challenging. I also think that for IoT devices, there are so many potential DDOS = attack vectors (and most much worse than this one), there there is = little an individual device can do. Maybe better to limit who can talk = to them instead of trying to protect against stuff like this. Bob p.s. IoT devices seem to be used more for the source of DDOS attacks = these days :-) --Apple-Mail=_4CFB92C4-0A9F-4240-AEFF-FF26601F6580 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZAOdqAAoJEK7rdBF357uoC2cH+wftlgKu7eDGiE9QzPL8IhvN z6p3cJNbybH6OsKNtOiSg26cxyAtCpFB0tYtFczGTphfs2uxOQWKN8OqyhLTzTz/ 6jxsBO0IHROEqy1xufWaPmH3795bjJsOyEYRHIU8xr+dvSzki0FQZ/tRtJYsarpZ FrTUZ5fOKeU3/s6y9oaaBUECX5yGUg6YPE5MWdEUntjJC1NPVMl5UHheoicbu8OX Q3LvPEetjTfY1PSm1oxcie5JmaDRd7k56CxGbLY/Z9fycg03qPVfx5pZoecfWSfr 4omz/fKylmCG18/vKwaICxEBdiFTWZsHeTIQ6u+VbLkbwclxubY2T+LTxCxETOw= =E8XN -----END PGP SIGNATURE----- --Apple-Mail=_4CFB92C4-0A9F-4240-AEFF-FF26601F6580-- From nobody Wed Apr 26 11:35:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF4131586; Wed, 26 Apr 2017 11:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 XcqK_u85ov-y; Wed, 26 Apr 2017 11:35:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 B1782131582; Wed, 26 Apr 2017 11:35:40 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3QIZDKk005153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 11:35:13 -0700 (PDT) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 To: Stewart Bryant , gen-art@ietf.org Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> From: Joe Touch Message-ID: Date: Wed, 26 Apr 2017 11:35:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:35:43 -0000 Hi, Stewart, On 4/26/2017 1:48 AM, Stewart Bryant wrote: > > > On 25/04/2017 19:26, Joe Touch wrote: >> Hi, Stewart, >> >> ... >> >>> SB> >>> SB> Otherwise I would have thought that this was entirely a matter >>> SB> for the host whether it wanted to use a Path MTU below the IPv6 >>> SB> link minimum. Nothing breaks if the host takes a more conservative >>> SB> decision. >> I don't agree; the host at that point is violating RFC2460. It should >> never think that an IPv6 link or path with an MTU below what RFC2460 >> requires is valid. >> >> Joe >> > > That is as maybe, but a host can do more or less what it wants, so > this is surely an > unenforceable constraint, or are you telling me that the receiving > host MUST drop a > fragment that is shorter than this? In which case the question whether > in practice > they do, and whether such a constraint is reasonable. A "path MTU" is a value calculated from information from various sources (attached links, ICMP messages, and perhaps other information), but IMO it's never appropriate to set a "path MTU" smaller than the limit established by IPv6 for a single link. Individual packets and fragments can be smaller than the MTU, of course. Nothing forces fragments to push up against any MTU limit at all. But I would not describe that has a host changing its path MTU; it's just sending packets. Joe From nobody Wed Apr 26 11:38:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D159C131595 for ; Wed, 26 Apr 2017 11:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 zFyTZuxibFEr for ; Wed, 26 Apr 2017 11:38:05 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 3C853131594 for ; Wed, 26 Apr 2017 11:38:05 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id a103so8574803ioj.1 for ; Wed, 26 Apr 2017 11:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=qHSuUjWvOfET0KHCQw70fVYtW3vQKTLfATeaMobvg7U=; b=RL47qs/w2RgJsg8b1C92o+EYde++ZQ2L30owm7cmg6I0HVFVihnEeBwXx4XNKHIaDI q6JQONk4/9FbgXlIKRWybKxvWrLPGLyxkFt+MEAZC2UT96fDjDev0EWWShCx6mYcicQ3 TWEJLPDWdf9PaLr9rQsG+Zvyu648miMKPYduRHyRUlugiJiG9hBBKmVOvcZUJ2/ZveeO ZTLymtDkBnCOSpXsdnN4PK6Xbb2xiLrRe6uM5EmB0QHAyKN4I1BqGRmfoCr4k+0GzTgJ aC3AR38u67p+bWHGvToB7LWwiNWzrsSW85tHRHSK7ds63F2/yk70tviXDNno7Vm5C/as Ckig== 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:date:cc:to; bh=qHSuUjWvOfET0KHCQw70fVYtW3vQKTLfATeaMobvg7U=; b=KHnnS1IGsGqQJVsALBm5UPuKELoVfaCE9Zc7jKR10VNZNb+8NptR4fWBhFx57NZVlS 5e2iwK8OH+zHx/8xaTE8L8S0Yj6kYoBnHns1P/3szum+qHsxutv8fagB0AOxWXVE8MGi TryNovRGjgkh8QTwMmjHy/QftSraCttjvdAA95bje0CjAR93DkMsYwYZPX6Pn3eYL/rW I7dYJljfXJlDytstx3Nz2Hyhh9ost4h6lBDpcNq0SUllpclPYojY/weohHto58MxGL3a ar76CgOFySA8T5T1Oq9ZwQ48aSPB2hhcdTB1NyRKHpyyE+b263KHJRpZlUVh949cdWFC jX8A== X-Gm-Message-State: AN3rC/6LvXdfqBwHhjxHBs8tfwOCfmU5WHrcu0iXBdaXX1+/Ofz/6F9I FgvqPFIuuhoZkA== X-Received: by 10.107.8.226 with SMTP id h95mr1152358ioi.163.1493231884605; Wed, 26 Apr 2017 11:38:04 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id x94sm3380795ita.2.2017.04.26.11.38.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 11:38:03 -0700 (PDT) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_6C8C1188-90F2-4C9D-8623-619486988E97"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Proposed text in Section 4.8. "Defining New Extension Headers and Options" Message-Id: Date: Wed, 26 Apr 2017 11:38:01 -0700 Cc: Bob Hinden To: IPv6 List X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:38:07 -0000 --Apple-Mail=_6C8C1188-90F2-4C9D-8623-619486988E97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Based on the comments and IESG discusses, I clarified the text in = Section 4.8 about defining new IPv6 extension headers. The proposed = text is much closer what was in RFC6564 that updated RFC2460. CURRENT and NEW text is below. Comments? Bob CURRENT Defining new IPv6 extension headers is not recommended. There has to be a very clear justification why any new extension header is needed before it is standardized. Instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility. NEW Defining new IPv6 extension headers is not recommended, unless no existing IPv6 extension header can be used by specifying a new option for that existing IPv6 extension header. Any proposal to create or specify a new IPv6 extension header must include a detailed technical explanation of why no existing IPv6 extension header can be used in the document proposing the new IPv6 extension header. Instead of defining new Extension Headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility. END NEW If new Extension Headers are defined, they need to use the following format: . . . . . . --Apple-Mail=_6C8C1188-90F2-4C9D-8623-619486988E97 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----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZAOkKAAoJEK7rdBF357uo8JsIAJaDSCeuOBH2Gi3Ffg0cBT5w X9NdiiI1u7vkFWTbNrzXe/QzCO1L2uKpLXEo+RlsDDEDi/6aPJzu/Xu8DHgp1AOA jPBltq3RdyFsfCgiVdjcQFRm3GYm2qwur9MWkGd2smh5b6aReWhhzP89z1+Z4Iys qXyUcPXHakAnB7ad8IRVAbk3hxDMFdjnRAYHRClF/FPYdB6H25z5oVLo2kmUTyUh abv0HvLfpqf4lPqZ3fDXi/+9azCuClHl01hVoXVeG2lNZ4mEMcvMlM/5f4tsSJfJ IueSvUxzoftguhKq/0H8SUtYaHGKLMbVvKQ19hNNJZD9WueV1fgPMNkpbVKm2Bo= =7Vw7 -----END PGP SIGNATURE----- --Apple-Mail=_6C8C1188-90F2-4C9D-8623-619486988E97-- From nobody Wed Apr 26 13:08:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABA12EB55; Wed, 26 Apr 2017 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 Wxfv12-ExCL2; Wed, 26 Apr 2017 13:08:37 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 925CB1294A9; Wed, 26 Apr 2017 13:08:31 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id g12so1450040wrg.2; Wed, 26 Apr 2017 13:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zjkl0qMkyaeqzgOEKMUFJke58SC/VxzeNgHcnRnjEp0=; b=Ai/urVsadKiIfFc6DOvBt563jFnPvN0xV4kTW14eAA5w2aoUYKHsG6UysZW6RCNdjl it9eBmgWpfqdumyzKJU0JnsdO8KVHkG/Fvx2KfLlF/mswmu4wU49XhznVKZOxrxwomKZ BfuT7/wcMR6G/0Gh2afvMzfyxhHbG3kDX1bWPSMc0WOn/85Tke6DCMqJxl4nxPe9wNHL VfTRcsr34/6g4fGKimDMCmunu13xs7SgTc5FVgbXyDQhT4FeR4x+pIDBRsWIP3kDrKT7 D7hOKIqRNqFts6NZReAKFujY8JuoPwaEq4z7sU1jYfA0krr391veCHWS3v4sArR2+KeZ RP7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zjkl0qMkyaeqzgOEKMUFJke58SC/VxzeNgHcnRnjEp0=; b=Bju76Gica9+F0AH9R1ABK11P9S3Obf8C8krFHIUf+OZ1N16ZRjrKxA6t9vISWcBwdG s6voANOYt3ud3aUA/GqwQ5o/laI79Cawc9+6mDNtpkTi6vUZAxmK03ot01JRTRZ63uDv aj8deDH+dv7d7kHvvK65VLVJ5YMkUsWaCltSD2EqQ0OIAMn4OBr7JeM2aodc2PvQ+Eze wya0CbIadG5V0yvCX4KUos8t/8U77/NPz33O9q0+nptxs3bZgo2Zbsf/Bl/ycx/lqNR4 kAls4T8JpDfwi9sQkkdk4wrrGjC+rmt9eGiXcnQ4h7RahgTgFsRPPjy/112SkfNn9TeT TbnA== X-Gm-Message-State: AN3rC/4usKrtpzWbHh1OPG4u9RO73sBHOmpCrVVux7TOqExoMs9FwICn AqOVQS3Yaw83CVoOSAM= X-Received: by 10.223.154.240 with SMTP id a103mr1018926wrc.5.1493237310104; Wed, 26 Apr 2017 13:08:30 -0700 (PDT) Received: from 202.66.20.149.in-addr.arpa (202.66.20.149.in-addr.arpa. [149.20.66.202]) by smtp.gmail.com with ESMTPSA id 39sm280734wru.50.2017.04.26.13.08.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 13:08:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 From: Fred Baker In-Reply-To: Date: Wed, 26 Apr 2017 13:08:25 -0700 Cc: Stewart Bryant , gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:08:39 -0000 > On Apr 26, 2017, at 11:35 AM, Joe Touch wrote: >=20 > Hi, Stewart, >=20 >=20 > On 4/26/2017 1:48 AM, Stewart Bryant wrote: >>=20 >>=20 >> On 25/04/2017 19:26, Joe Touch wrote: >>> Hi, Stewart, >>>=20 >>> ... >>>=20 >>>> SB> >>>> SB> Otherwise I would have thought that this was entirely a matter >>>> SB> for the host whether it wanted to use a Path MTU below the IPv6 >>>> SB> link minimum. Nothing breaks if the host takes a more = conservative >>>> SB> decision. >>> I don't agree; the host at that point is violating RFC2460. It = should >>> never think that an IPv6 link or path with an MTU below what RFC2460 >>> requires is valid. >>>=20 >>> Joe >>>=20 >>=20 >> That is as maybe, but a host can do more or less what it wants, so >> this is surely an >> unenforceable constraint, or are you telling me that the receiving >> host MUST drop a >> fragment that is shorter than this? In which case the question = whether >> in practice >> they do, and whether such a constraint is reasonable. >=20 > A "path MTU" is a value calculated from information from various = sources > (attached links, ICMP messages, and perhaps other information), but = IMO > it's never appropriate to set a "path MTU" smaller than the limit > established by IPv6 for a single link. You are, of course, quoting RFC 1981: A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. > Individual packets and fragments can be smaller than the MTU, of = course. > Nothing forces fragments to push up against any MTU limit at all. But = I > would not describe that has a host changing its path MTU; it's just > sending packets. I disagree, both on the definition and the action. You are correct in = "how the Path MTU is calculated". But the Path MTU, by definition, is = the largest packet that can be sent end to end under current routing = conditions. It is not, actually, an IP concept: it's a TCP concept if = anything, or a transport layer concept (if UDP ever decides to have = one). I can imagine TCP probing the Path MTU by trying packets that are = larger than its current estimate to see if the estimate is still = accurate (1981 section 4), but I can't imagine any reason that TCP would = send packets larger than the "largest packet that can be sent end to end = under current routing conditions" in the normal case, as those packets = will by definition either be fragmented or not arrive. From nobody Wed Apr 26 13:18:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48EE13144C; Wed, 26 Apr 2017 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 FtEpxc8LSQFm; Wed, 26 Apr 2017 13:18:39 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 440E21314D6; Wed, 26 Apr 2017 13:18:25 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3QKIBwB000870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 13:18:11 -0700 (PDT) Subject: Re: Genart telechat review of draft-ietf-6man-rfc1981bis-06 To: Fred Baker Cc: Stewart Bryant , gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> From: Joe Touch Message-ID: Date: Wed, 26 Apr 2017 13:18:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> Content-Type: multipart/alternative; boundary="------------9304196B38F0127139E7B07B" Content-Language: en-US X-MailScanner-ID: v3QKIBwB000870 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:18:42 -0000 This is a multi-part message in MIME format. --------------9304196B38F0127139E7B07B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Fred, On 4/26/2017 1:08 PM, Fred Baker wrote: >> Individual packets and fragments can be smaller than the MTU, of course. >> Nothing forces fragments to push up against any MTU limit at all. But I >> would not describe that has a host changing its path MTU; it's just >> sending packets. > I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). While it might apply differently based on port-based routing, path MTU is an IP concept. It sets IP limits (MTU is an IP-ism, including all its variants, such as EMTU_S, EMTUR, etc. - from RFC1122), which then cascades into TCP limits (MSS and MMS_*, again per RFC1122). And it's not the largest packet - it's strictly the largest IP fragment. Transport uses that as the limit on IP messages to avoid fragmentation. Technically, though, PMTU could also be used by the IP layer to guide source fragmentation if the transport layer presents messages that are too large to fit in a single datagram. > I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive. TCP probably wouldn't, but UDP can, would, and does. Joe --------------9304196B38F0127139E7B07B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, Fred,


On 4/26/2017 1:08 PM, Fred Baker wrote:
Individual packets and fragments can be smaller than the MTU, of course.
Nothing forces fragments to push up against any MTU limit at all. But I
would not describe that has a host changing its path MTU; it's just
sending packets.

I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one).
While it might apply differently based on port-based routing, path MTU is an IP concept. It sets IP limits (MTU is an IP-ism, including all its variants, such as EMTU_S, EMTUR, etc. - from RFC1122), which then cascades into TCP limits (MSS and MMS_*, again per RFC1122).

And it's not the largest packet - it's strictly the largest IP fragment. Transport uses that as the limit on IP messages to avoid fragmentation. Technically, though, PMTU could also be used by the IP layer to guide source fragmentation if the transport layer presents messages that are too large to fit in a single datagram.

I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
TCP probably wouldn't, but UDP can, would, and does.

Joe

    

  


--------------9304196B38F0127139E7B07B--


From nobody Wed Apr 26 13:30:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606FF12778D; Wed, 26 Apr 2017 13:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 yVwXCARIihF3; Wed, 26 Apr 2017 13:30:13 -0700 (PDT)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 98562127342; Wed, 26 Apr 2017 13:30:13 -0700 (PDT)
Received: by mail-pf0-x243.google.com with SMTP id c198so2441387pfc.0; Wed, 26 Apr 2017 13:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ymWQklo4o9ij64ii/b86yWzGhaOzaFyAGJZ/J4JYBLE=; b=sQeaVh2FsTQDRk20qfOBW1igbOt+ANsnOafDOcPDBPvsTXc8+0dKeXdiaViPn+SmYo 3X5D62xxbKresEHJpzsCAQer6bx8vQeVHut0OHBMytple68v0kt8m6B05uBisj8RzKEB 770QN5f1FeCepeoKCRUF8ZoJu2di0FZ9rqEkQe1LWc+3bot5r+9ln0gnRfViYgJe60VD L8yR329zH0wGELlfD7nYLIvHMiBu4juR9DxZipIBhwX8KP17TIdTv+X/4Gt3IrIlBQIt 9P4L4dzeCCqN1q1/s4hCfL+bVqkeHeDEYyBDjMYNwC5/LNMPrzfFrGcwXMGWLn7/+0Ne fWYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ymWQklo4o9ij64ii/b86yWzGhaOzaFyAGJZ/J4JYBLE=; b=DBWpTLnsL9qR0N4Vtf9pMGyt+oPo410S54a3dbGaUDDpNsamK28XE7pChlR8tEUxfB 5xTt6bfgPBYbkEWOKTvZh6sw8Ps2s2sWnZkbwCt4agpAHJdeoMtgFfgtMMQeTOVInthb uS0msE6V9DLd3kvbapSXFb3tTDEByB7wYuomO8vo4uAEaQ0gWnTI9Lolg2JszGX3cVDT XmzlSVE3tEhfGfOkOiXxPXMw+52rxTzKGEWuhaM4Onm6t2slLee0P7ca8scCHqJrej7W iYVFPOaNpPkeecL9OF0I11IpzRLkRusf0tFJnBp3Ohk26mJyyyHpe7+8JTCdaTYGm7Y7 8SOA==
X-Gm-Message-State: AN3rC/540o9QkrrRT6bTmNvL0DbVW5IwVAf3Kxrg+IP2biZSs/QvtVOU dDlfKTqz6xnQ3A==
X-Received: by 10.84.217.215 with SMTP id d23mr2189439plj.59.1493238613087; Wed, 26 Apr 2017 13:30:13 -0700 (PDT)
Received: from [192.168.178.21] ([118.149.100.28]) by smtp.gmail.com with ESMTPSA id 17sm259899pgg.48.2017.04.26.13.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 13:30:12 -0700 (PDT)
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06
To: Fred Baker , Joe Touch 
References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu>   <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com>
Cc: gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 27 Apr 2017 08:30:12 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 20:30:16 -0000

On 27/04/2017 08:08, Fred Baker wrote:
> 
>> On Apr 26, 2017, at 11:35 AM, Joe Touch  wrote:
>>
>> Hi, Stewart,
>>
>>
>> On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>>>
>>>
>>> On 25/04/2017 19:26, Joe Touch wrote:
>>>> Hi, Stewart,
>>>>
>>>> ...
>>>>
>>>>> SB>
>>>>> SB> Otherwise I would have thought that this was entirely a matter
>>>>> SB> for the host whether it wanted to use a Path MTU below the IPv6
>>>>> SB> link minimum. Nothing breaks if the host takes a more conservative
>>>>> SB> decision.
>>>> I don't agree; the host at that point is violating RFC2460. It should
>>>> never think that an IPv6 link or path with an MTU below what RFC2460
>>>> requires is valid.
>>>>
>>>> Joe
>>>>
>>>
>>> That is as maybe, but a host can do more or less what it wants, so
>>> this is surely an
>>> unenforceable constraint, or are you telling me that the receiving
>>> host MUST drop a
>>> fragment that is shorter than this? In which case the question whether
>>> in practice
>>> they do, and whether such a constraint is reasonable.
>>
>> A "path MTU" is a value calculated from information from various sources
>> (attached links, ICMP messages, and perhaps other information), but IMO
>> it's never appropriate to set a "path MTU" smaller than the limit
>> established by IPv6 for a single link.
> 
> You are, of course, quoting RFC 1981:
>    A node MUST NOT reduce its estimate of the Path MTU below the IPv6
>    minimum link MTU.
> 
>> Individual packets and fragments can be smaller than the MTU, of course.
>> Nothing forces fragments to push up against any MTU limit at all. But I
>> would not describe that has a host changing its path MTU; it's just
>> sending packets.
> 
> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.

istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?

    Brian


From nobody Wed Apr 26 13:34:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CFE1294AB; Wed, 26 Apr 2017 13:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 ulEldP2NKcW2; Wed, 26 Apr 2017 13:34:06 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 1BAE9129464; Wed, 26 Apr 2017 13:34:06 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3QKXrTa006565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 13:33:53 -0700 (PDT)
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06
To: Brian E Carpenter , Fred Baker 
Cc: gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org
References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu>   <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> 
From: Joe Touch 
Message-ID: 
Date: Wed, 26 Apr 2017 13:33:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7459DC2F1AB0CBA15FBD1564"
Content-Language: en-US
X-MailScanner-ID: v3QKXrTa006565
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 20:34:08 -0000

This is a multi-part message in MIME format.
--------------7459DC2F1AB0CBA15FBD1564
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit



On 4/26/2017 1:30 PM, Brian E Carpenter wrote:
>>> Individual packets and fragments can be smaller than the MTU, of course.
>>> Nothing forces fragments to push up against any MTU limit at all. But I
>>> would not describe that has a host changing its path MTU; it's just
>>> sending packets.
>> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
> istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?
IMO, the best thing is to loudly flag the path as no longer valid.

Either we have required minimums or not. If not, then we have a LOT of
new work to do.

Joe


--------------7459DC2F1AB0CBA15FBD1564
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    


    

    

    
On 4/26/2017 1:30 PM, Brian E Carpenter
      wrote:

    

    

      

        

          
Individual packets and fragments can be smaller than the MTU, of course.
Nothing forces fragments to push up against any MTU limit at all. But I
would not describe that has a host changing its path MTU; it's just
sending packets.


        

        
I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.


      

      
istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?

    

    IMO, the best thing is to loudly flag the path as no longer valid.

    

    Either we have required minimums or not. If not, then we have a LOT
    of new work to do.

    

    Joe

    

  


--------------7459DC2F1AB0CBA15FBD1564--


From nobody Wed Apr 26 13:48:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0ED1279EB for ; Wed, 26 Apr 2017 13:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 4MLTUqT60-Dt for ; Wed, 26 Apr 2017 13:48:07 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FFD128D19 for ; Wed, 26 Apr 2017 13:48:06 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25  iface 141.3.10.81 id 1d3Tr2-0006Ww-V9; Wed, 26 Apr 2017 22:48:05 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 9BCD1B00484; Wed, 26 Apr 2017 22:48:04 +0200 (CEST)
Subject: Re: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
To: Bob Hinden , IPv6 List 
References: 
From: Roland Bless 
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
Message-ID: 
Date: Wed, 26 Apr 2017 22:48:04 +0200
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1493239685.036001475
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 20:48:11 -0000

Hi Bob,

On 26.04.2017 at 20:38 Bob Hinden wrote:
> Based on the comments and IESG discusses, I clarified the text in Section 4.8 about defining new IPv6 extension headers.  The proposed text is much closer what was in RFC6564 that updated RFC2460.
> 
> CURRENT and NEW text is below.
> 
> Comments?

Sound good to me!

Roland

>    CURRENT
> 
>    Defining new IPv6 extension headers is not recommended.  There has to
>    be a very clear justification why any new extension header is needed
>    before it is standardized.  Instead of defining new Extension
>    Headers, it is recommended that the Destination Options header is
>    used to carry optional information that must be examined only by a
>    packet's destination node(s), because they provide better handling
>    and backward compatibility.
> 
>    NEW
> 
>    Defining new IPv6 extension headers is not recommended, unless no
>    existing IPv6 extension header can be used by specifying a new option
>    for that existing IPv6 extension header.  Any proposal to create or
>    specify a new IPv6 extension header must include a detailed technical
>    explanation of why no existing IPv6 extension header can be used in
>    the document proposing the new IPv6 extension header.
> 
>    Instead of defining new Extension Headers, it is recommended that the
>    Destination Options header is used to carry optional information that
>    must be examined only by a packet's destination node(s), because they
>    provide better handling and backward compatibility.
> 
>    END NEW
> 
>    If new Extension Headers are defined, they need to use the following
>    format:
> 
>    . . . . . .
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Apr 26 13:58:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D691279EB for ; Wed, 26 Apr 2017 13:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 I09BDjwJR-M1 for ; Wed, 26 Apr 2017 13:58:02 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 0F6CA127342 for ; Wed, 26 Apr 2017 13:58:02 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id a188so5854670pfa.0 for ; Wed, 26 Apr 2017 13:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9nd3G/R9dd+sIM/W8luObst+60vrfP7pt+IEwmAR00c=; b=RmHqpZfVrDu4yxHyRZXrdu7Q5/fsrcoRanysTdWqzvyHDOio0Q/sAVeHuOexmDgink mFv/bgz7IHBl0omdyMK2S5tbsDvcfmeHVP6dKkIOT8aqZpLfqO14sMk0fxRQv1Qg67V+ GoovabgtDzfR0SUedem353k0Kh7zITOyLXB8pte/JMi3ndv6yhDDe7ZBxo2DyjbfTIwg 2Sr18Xzrq9l/dbW/ajBbwYgo5wy07XqrQToCBTNzrc0ehNUP5Y9DPdjGuCbpBQ5WP/ut ZCvTek0bvPwTeWHzpybKvV4cET1M+T1bpjojepgvkufC9kDCva9Kvy1uqHKmzSgwiqcT /DOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9nd3G/R9dd+sIM/W8luObst+60vrfP7pt+IEwmAR00c=; b=UdqZlTBh5HG+XdNwVL63hxE41EA2Yh8F6HwoBD6zxtjJrGSWwKsw9W/PXTvf+HdYnu hxBrahQHZ+76igDphP9mAbr6v8EGxQJMXu6bKhyib29UERfJK3KGocTai3+vl2xvNMKM nqBqYMvB/nSi/YkkuhEWMp29EZDjJY+C2bRw9oW94zgIqT2UA/qivbHbRcBW6aP7qqa+ XhNIBhgz6yQ/hB4VZkCtwHnEaH04usJUAXLA/3/Aw/y4myB7fY1eofd1/NpMX+3ico8Y 364tURXcgccGd0R0WfymDDE5nsvAWeYwugVug6oGoBDRmmnCmEM8oSLzmA0FmcQpQixb rKtA==
X-Gm-Message-State: AN3rC/7DLzBvIDIKsiA0iwI6hq71VeMUua8k6RJTvDL51Kn+8m7d8slT cDUcHJ39BUv3zQ==
X-Received: by 10.98.211.18 with SMTP id q18mr1879108pfg.97.1493240281657; Wed, 26 Apr 2017 13:58:01 -0700 (PDT)
Received: from [192.168.178.21] ([118.149.100.28]) by smtp.gmail.com with ESMTPSA id q64sm340317pfi.69.2017.04.26.13.57.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 13:58:01 -0700 (PDT)
Subject: Re: Destination options and denial of service attack
To: Tom Herbert , Bob Hinden 
References:    
Cc: "C. M. Heard" , IPv6 List 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 27 Apr 2017 08:58:03 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 20:58:03 -0000

On 27/04/2017 06:21, Tom Herbert wrote:
...
> Right, but IPv6 is stateless so that analyzing an attack may require
> new state and resource monitoring that may be prohibitive to implement
> on low end devices (IoT devices for instance). I think the simplest
> approach is to create an OS configurable limit for number of non-pad
> TLVs with a reasonable default, maybe something like five or ten of
> them. This is at least better then unilaterally blocking all packets
> with extension headers.

Even ignoring a few hundred pads could be an issue, surely?

It might be simpler to set a configurable limit on the acceptable Hdr_Ext_Len
for any Options header.

    Brian


From nobody Wed Apr 26 14:06:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7B1128B91 for ; Wed, 26 Apr 2017 14:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 c-eQRv9052cq for ; Wed, 26 Apr 2017 14:06:09 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB97127342 for ; Wed, 26 Apr 2017 14:06:09 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B59BF349475; Wed, 26 Apr 2017 21:06:06 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A5D8D16004A; Wed, 26 Apr 2017 21:06:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8268D16009B; Wed, 26 Apr 2017 21:06:06 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p4Wx9WcejchC; Wed, 26 Apr 2017 21:06:06 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F321516004A; Wed, 26 Apr 2017 21:06:05 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B9A906D04F09; Thu, 27 Apr 2017 07:06:04 +1000 (AEST)
To: Bob Hinden 
Cc: Tom Herbert , "C. M. Heard" , IPv6 List 
From: Mark Andrews 
References:     
Subject: Re: Destination options and denial of service attack
In-reply-to: Your message of "Wed, 26 Apr 2017 11:31:04 -0700." 
Date: Thu, 27 Apr 2017 07:06:04 +1000
Message-Id: <20170426210604.B9A906D04F09@rock.dv.isc.org>
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 21:06:10 -0000

In message , Bob Hinden writes:
> Tom,
>
> > On Apr 26, 2017, at 11:21 AM, Tom Herbert  wrote:
> >
> >>
> >>
> > Right, but IPv6 is stateless so that analyzing an attack may require
> > new state and resource monitoring that may be prohibitive to implement
> > on low end devices (IoT devices for instance). I think the simplest
> > approach is to create an OS configurable limit for number of non-pad
> > TLVs with a reasonable default, maybe something like five or ten of
> > them. This is at least better then unilaterally blocking all packets
> > with extension headers.
>
> Something to consider for the node requirement update.  Picking some
> default values will be a challenging.
>
> I also think that for IoT devices, there are so many potential DDOS
> attack vectors (and most much worse than this one), there there is little
> an individual device can do.  Maybe better to limit who can talk to them
> instead of trying to protect against stuff like this.
>
> Bob
>
> p.s. IoT devices seem to be used more for the source of DDOS attacks
> these days :-)

And what is the real different between processing a series of IPv6
options and a 1500 byte DNS packet which is essentially a series
of TLV fields?  None.

It also in the worst case devolves to the equivalent of a byte by
byte copy of the packet which while not great is also not the end
of the world.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Apr 26 14:59:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFD01252BA for ; Wed, 26 Apr 2017 14:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rRAXSZrJ4iO for ; Wed, 26 Apr 2017 14:59:38 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 77BA112422F for ; Wed, 26 Apr 2017 14:59:38 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id u75so13114580qka.3 for ; Wed, 26 Apr 2017 14:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sn837clcd77frj+hyvo/pPWPOdg1KGK8CVC7kbEf0XA=; b=htu2egC6DJVByikS2c7CktnbEVNtwsIIRvirO6TLilWrOuQlH7/3HINQwRgHkCGtBx NEhbv1D0wcm+wkjsdJ4vJpdrFQvT1YTAIu4co8fQLk4EG3tBYKlUgljEHjTCueG36ijc URPUmH7UYNcl73um/QWtBRAWArIcm4E/yGcJFZbCorM0ToqBHeYeLgsKTB+Uv78ddiFF BoHrXZQdTVLRgm0N4We0E8Yp4sbIRkkMwQsUuSS9ANQ5C34K8g5q5azxOOIBhkAovADW b5dtKDJthwFSX6fVihd5Vt9ZO+x0zP8shtl/1QCxaG0wlu8T9wPKbjMPv+9nIgHVBpEj EPcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sn837clcd77frj+hyvo/pPWPOdg1KGK8CVC7kbEf0XA=; b=C+yAH33U5/50XE9/0K057CkGQbvn57r6x/O86eJvWET8WHtg3IBD+lFGpUWhKgzdE4 0RTYV739wsroo4kqxPB9S5ZEnaIqt68vhagpM8nKTf0AGYGKcuhAPZoRLzTqQS6wNAuE 6AsAXMjzFGvOkLn3wzuWRTpxXlaDxNBfyL+Rjom+/EYpIfFbuLLS1Nr7zK2NP8l+WNoU JU68G5Zfk0Qt67f59ZWFy8tdLB3XjXCOXqDXcm5AiFKokQd56xHNx8NSplbE8JF/j4Xh quqUolS5vjsYfO94fbnb+26t3vr6B8I8nLxdLApTigIx2x7L10+Y3qT/jqmvbuPVIo5n RBuA==
X-Gm-Message-State: AN3rC/4sCUntbQkkdGDXKrgGMMAiqXIWWtoikMrEZlQBIqc3xbhvB3by rkys5JyYjsCqDEZQSjIpb25Mu46aQg==
X-Received: by 10.55.140.65 with SMTP id o62mr2115681qkd.270.1493243977544; Wed, 26 Apr 2017 14:59:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Wed, 26 Apr 2017 14:59:36 -0700 (PDT)
In-Reply-To: 
References:     
From: Tom Herbert 
Date: Wed, 26 Apr 2017 14:59:36 -0700
Message-ID: 
Subject: Re: Destination options and denial of service attack
To: Brian E Carpenter 
Cc: Bob Hinden , "C. M. Heard" , IPv6 List 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 21:59:39 -0000

On Wed, Apr 26, 2017 at 1:58 PM, Brian E Carpenter
 wrote:
> On 27/04/2017 06:21, Tom Herbert wrote:
> ...
>> Right, but IPv6 is stateless so that analyzing an attack may require
>> new state and resource monitoring that may be prohibitive to implement
>> on low end devices (IoT devices for instance). I think the simplest
>> approach is to create an OS configurable limit for number of non-pad
>> TLVs with a reasonable default, maybe something like five or ten of
>> them. This is at least better then unilaterally blocking all packets
>> with extension headers.
>
> Even ignoring a few hundred pads could be an issue, surely?
>
There's a nice trick in Linux, I don't know if it's standard, that at
most seven consecutive pad bytes are allowed.

> It might be simpler to set a configurable limit on the acceptable Hdr_Ext_Len
> for any Options header.
>
That might be useful also. Even a single 1200 byte destination option
can cause problems with current implementations (pulling up checksum
in checksum complete for instance).

Another thing I'll probably add is configuration to drop any packets
with unknown options. In a closed system, like a datacenter, things
are typically controlled so there shouldn't be "ignored" data in the
network. I wouldn't set this as a default.

Tom


From nobody Wed Apr 26 15:26:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6314E128B8D for ; Wed, 26 Apr 2017 15:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 tIg1AfuQtxSH for ; Wed, 26 Apr 2017 15:26:13 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23DF1272E1 for ; Wed, 26 Apr 2017 15:26:13 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 131C034930F; Wed, 26 Apr 2017 22:26:11 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id F048E16009A; Wed, 26 Apr 2017 22:26:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DBA5A16009B; Wed, 26 Apr 2017 22:26:10 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wTee0YTxz0ZT; Wed, 26 Apr 2017 22:26:10 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9087916009A; Wed, 26 Apr 2017 22:26:10 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 08D986D066BA; Thu, 27 Apr 2017 08:26:08 +1000 (AEST)
To: Tom Herbert 
Cc: Brian E Carpenter , "C. M. Heard" , IPv6 List , Bob Hinden 
From: Mark Andrews 
References:      
Subject: Re: Destination options and denial of service attack
In-reply-to: Your message of "Wed, 26 Apr 2017 14:59:36 -0700." 
Date: Thu, 27 Apr 2017 08:26:08 +1000
Message-Id: <20170426222608.08D986D066BA@rock.dv.isc.org>
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 22:26:15 -0000

In message , Tom Herbert writes:
> On Wed, Apr 26, 2017 at 1:58 PM, Brian E Carpenter
>  wrote:
> > On 27/04/2017 06:21, Tom Herbert wrote:
> > ...
> >> Right, but IPv6 is stateless so that analyzing an attack may require
> >> new state and resource monitoring that may be prohibitive to implement
> >> on low end devices (IoT devices for instance). I think the simplest
> >> approach is to create an OS configurable limit for number of non-pad
> >> TLVs with a reasonable default, maybe something like five or ten of
> >> them. This is at least better then unilaterally blocking all packets
> >> with extension headers.
> >
> > Even ignoring a few hundred pads could be an issue, surely?
> >
> There's a nice trick in Linux, I don't know if it's standard, that at
> most seven consecutive pad bytes are allowed.

Which assumes the only use of pad is to force alignment.

> > It might be simpler to set a configurable limit on the acceptable Hdr_Ext_Len
> > for any Options header.
> 
> That might be useful also. Even a single 1200 byte destination option
> can cause problems with current implementations (pulling up checksum
> in checksum complete for instance).
> 
> Another thing I'll probably add is configuration to drop any packets
> with unknown options. In a closed system, like a datacenter, things
> are typically controlled so there shouldn't be "ignored" data in the
> network. I wouldn't set this as a default.

Even data centers upgrade equipement incrementally, have equipement
from different vendors with different capabilities, etc.  Setting
such a option is like laying landmines, they explode on you later.

Mark

> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org


From nobody Wed Apr 26 15:57:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0409E129464 for ; Wed, 26 Apr 2017 15:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level: 
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 fyllsNtOwRr9 for ; Wed, 26 Apr 2017 15:57:29 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FF6129446 for ; Wed, 26 Apr 2017 15:57:28 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7FC6583CE0 for ; Wed, 26 Apr 2017 18:57:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=Prb827O14VEk4FzNgihdFLBIKHY=; b=vF4vwm 7hH1dEr2ArJx0JmJZ8+KUuV5IhUEIAEvQ2WFHEkA2N7roExbFVmPoNzJ8Znk864F AN8cvSS0k7QsXRacngtR0AiU8gK0BspbQiOG8lNmt2vrd7h/9BReuLs97x4LmQCz WQpOBFNr0vzHtsEUtwCqcppYoJFzk7AYEUDRM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=uP3LDqm+QjS1kT9Uidywv1x+Jn+hZe23 l+UniBcMZwFS/51cjRT+ewJHC5oKdGwsY8Emv2mLulB7hJU6gD+PXeWLWJJok8xe Ggk1IssWXBau3cEoMSJ4zAAgL1/HMtTlf/BkzvA2/KuKNLB9Kvfy8+Glo1mAm8Jc SAXJCsprq04=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 78B3583CDF for ; Wed, 26 Apr 2017 18:57:26 -0400 (EDT)
Received: from mail-qt0-f178.google.com (unknown [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 01CD483CDD for ; Wed, 26 Apr 2017 18:57:26 -0400 (EDT)
Received: by mail-qt0-f178.google.com with SMTP id y33so13398386qta.2 for ; Wed, 26 Apr 2017 15:57:26 -0700 (PDT)
X-Gm-Message-State: AN3rC/5e2ssML6WfWFhIwTufBnZiQZy4OErp/O1Vf32nD4r18ozLwrgO jb8ERzYdxSe2XbAC4FVMZrwYKOrf/Q==
X-Received: by 10.237.37.142 with SMTP id x14mr2299474qtc.160.1493247445695; Wed, 26 Apr 2017 15:57:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.40.180 with HTTP; Wed, 26 Apr 2017 15:57:05 -0700 (PDT)
In-Reply-To: 
References:      
From: "C. M. Heard" 
Date: Wed, 26 Apr 2017 15:57:05 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Destination options and denial of service attack
To: Tom Herbert 
Cc: Brian E Carpenter , Bob Hinden , IPv6 List 
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: B75338EE-2AD3-11E7-8902-C260AE2156B6-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 22:57:30 -0000

On Wed, Apr 26, 2017 at 2:59 PM, Tom Herbert wrote:
> Another thing I'll probably add is configuration to drop any packets
> with unknown options. In a closed system, like a datacenter, things
> are typically controlled so there shouldn't be "ignored" data in the
> network. I wouldn't set this as a default.

Thank you for not making this behaviour the default. I presume that
the default will be to look at the top two bits, per the standard.

//cmh


From nobody Wed Apr 26 16:08:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB081294BF for ; Wed, 26 Apr 2017 16:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 8flQ3EX3pWOq for ; Wed, 26 Apr 2017 16:08:10 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 E4A5B120727 for ; Wed, 26 Apr 2017 16:08:09 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id u75so14203038qka.3 for ; Wed, 26 Apr 2017 16:08:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1iHEsI0t5UOoU574HAP/3F5bqzO+qwAZIDG9hyKPh6c=; b=fI0zRSu5VcBx6weeTxptEZ9JsLeH+6FXlHFWJrFDViR18FkCiejDBWAhPPZr7BBcYb mCrEyxp5i6JrNTEC9qyLMtRKmFNyo0dx1FCKe9Ct/svykfYzyNrcjZvOWa5cBT2fqOFn SoaoKsNppQVFfb6KP4S+VXYQ6s2Y4z1U7keY9my9J6VoHP3pv5JWfy6fAsjjN/LucKY2 QTA2IoTriGElaas7WhpO8+gLl9dQJ5pOyNajspwKSNji3iv05KuSwClAVw80C9LgYw5O vCLuPtY6MBDgYcEB9hjJBo4OsstvfS3i1YXNyWndY+qL5ah8C81MuiZjXvd02R69sr6m ACCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1iHEsI0t5UOoU574HAP/3F5bqzO+qwAZIDG9hyKPh6c=; b=KbuAdV9yYQRh+saAr/JxLDNskKbKpi5j5tfJVlzcoZwpU/9w8YgQr2nqIggNVNJFln IlR0OB7z8SJq0ff3vIy10yZtzSv4ZFuD1nuOlcvOPPFIwVqXSpJp3ISzsLsjs77fFosF gW5b1vC6NJPDv4ENU5xA5H2SpcmMounLRtJgx8/YnXp0Oh68Gt5c7GKeVU9eJNjmv1WR WW4+FCOAL0JeAuX2qJh/yuar+sebia4h9HlQZ0igWwZeZ3+aK3ZQZYU0NuQmv/C+JgTB qqo/vPOvSD00lvvtzpCUKAATxrf9Bxf5YijZvTk6iBo/iUkfytsMcZovDDWNfyCrnqgZ S2uw==
X-Gm-Message-State: AN3rC/7DyElkg/9sRW5Fx6PQaCRRVGvqLhE5QbzhmOXoxWFvnu2B4HWN TzzVPN7ef//QTgibBxISwVmaXub+wP2Q7Nw=
X-Received: by 10.55.27.18 with SMTP id b18mr2247004qkb.142.1493248088878; Wed, 26 Apr 2017 16:08:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.166.130 with HTTP; Wed, 26 Apr 2017 16:08:08 -0700 (PDT)
In-Reply-To: 
References: 
From: Suresh Krishnan 
Date: Wed, 26 Apr 2017 19:08:08 -0400
Message-ID: 
Subject: Re: Destination options and denial of service attack
To: Tom Herbert 
Cc: "ipv6@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 23:08:12 -0000

Hi Tom,

On Tue, Apr 25, 2017 at 10:56 PM, Tom Herbert  wrote:
> The topic of limits of unbounded lists of TLVs that can be ignored
> came up on tsvwg. By my estimate, it is possible the create an
> Ethernet MTU size packet that holds 1282 TLVs in destination options
> (a combination of PAD1s and two bytes option with a type value that is
> known to be undefined) or at least 724 two byte options that would be
> ignored. Processing such packets on a host would be quite expensive
> and could likely be used as a DOS attack. HBH options have similar
> characteristics , but there are known workarounds such as devices
> ignoring them completely per the new allowance. Also, it's pretty well
> known that a router can throw packets with EH into a slow path that
> provides a from of rate limiting (albeit possibly at the possible
> expense of hampering legitimate use cases of EH)-- there's no obvious
> equivalent mechanism for a host. I am specifically concerned with
> destination options and processing them on hosts. The Linux stack for
> instance currently has no limits on destination options and will
> process all that are in a packet AFAICT.

Yes. I agree with you that this is an issue (at least implementation
wise). I encountered this the first time I dealt with a NPU based fast
path implementation of IPv6 in 2003. I wrote it up in

https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-00 (circa 2004)

but it did not go anywhere. Basically, the WG did not feel it was
something worth working on.

>
> My question is what mitigations do we have to handle a DOS attack like
> this that would be in compliance with the spec? AFAICT from reading
> 2640bis a host must process all extension headers and must process all
> destination options in a packet. There is no limit to number of
> options or space used other than they need to fit into an MTU IIRC.
> Appendix A of 2460bis mentions "It may be assumed that, when either of
> the option-bearing headers are present, they carry a very small number
> of options, usually only one.", but that does not establish an
> enforceable limit.

There are a lot of possibilities to fix these and as someone said
downthread, it is a fine balance between the desire for extensibility
and one to prevent attacks.

Cheers
Suresh


From nobody Wed Apr 26 23:07:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABE127071 for ; Wed, 26 Apr 2017 23:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Ve-izvzVeN6c for ; Wed, 26 Apr 2017 23:07:35 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 09EB6126C89 for ; Wed, 26 Apr 2017 23:07:34 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 08F87E6065; Thu, 27 Apr 2017 08:07:33 +0200 (CEST)
Date: Thu, 27 Apr 2017 08:07:32 +0200 (CEST)
Message-Id: <20170427.080732.74710660.sthaug@nethelp.no>
To: marka@isc.org
Cc: bob.hinden@gmail.com, heard@pobox.com, ipv6@ietf.org
Subject: Re: Destination options and denial of service attack
From: sthaug@nethelp.no
In-Reply-To: <20170426210604.B9A906D04F09@rock.dv.isc.org>
References:   <20170426210604.B9A906D04F09@rock.dv.isc.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 06:07:37 -0000

> And what is the real different between processing a series of IPv6
> options and a 1500 byte DNS packet which is essentially a series
> of TLV fields?  None.

One significant difference is that the IPv6 options would normally
be processed entirely by the operating system TCP/IP stack, while a
1500 byte DNS packet would be processed by an application running in
user space. The former means a greater potential for DoS of the whole
operating system.

Steinar Haug, AS2116


From nobody Thu Apr 27 02:02:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72FD1279E5 for ; Thu, 27 Apr 2017 02:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=jisc.ac.uk
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 G3YxLnAVLnfj for ; Thu, 27 Apr 2017 02:02:46 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92511273E2 for ; Thu, 27 Apr 2017 02:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493283764; bh=I9qKctbZrGDtvkwFqb3CZAoZrTmqhOKiu/4mee7zDzU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VOBRdmLNEuiMZEEN3vm8vsvbqditl3hhcIPLay2jTY6kFtFy7bkKemFYWJ5hP0DwxHk/FoGJP4r7BR2/olLeV9vioYinihz5rL4LFNEK1tO2lkLAI16pAkb+h92TYJwC+Ff/QR/wCbEv78NnaeKzVEr3UTdVUIqElcY6bZ1tlgg=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0180.outbound.protection.outlook.com [213.199.154.180]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-112-yyAfBExDPTu-Nx1hjyugIw-1; Thu, 27 Apr 2017 10:02:38 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Thu, 27 Apr 2017 09:02:36 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.001; Thu, 27 Apr 2017 09:02:36 +0000
From: Tim Chown 
To: Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Thread-Topic: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Thread-Index: AQHSvrxLCZVhi/Nuo0S9GuOuCgqjBKHY7I2A
Date: Thu, 27 Apr 2017 09:02:36 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-originating-ip: [193.60.231.51]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:ALsPhJ8O5q/4vn0GXG3PCjdDzQkTyZJUjdVv1venC+ghqWbAEfsueVLBSEKYBW/3fmB51+VgQ0f/CCsWZimwInEpcDyvDQYCnOFbi6MrNhoVuJJs1AiIiewKBnG4HHFb3GabczT2s9Chs7X6kq56u7U41deMnqFCL1VQfP5xwiBu9J+JeNfuENmXyVw59kVOJEsdVaJjb9TF8jwjhML3dYAuDAFWX7WnmyEawL7SDGvR3QDG3IIyFJEIGBaj/swb1Su9BzQDlPrt1Fd6CpIr6NeK9SqaCiWmMGnLUjwEuhIXlEFg1Trlnb+t0hGUo9O3e5y0K6vQVGzpYGYJ0lzJRQ==; 20:+xVToRmtvdxK67eLLzZbOTU2adPdO1WSwqty+25nANtXS26YAgNYUtB5w7mtZ+7rcOFsoaXQGDdWtOerfy7dn2MOhCu/GDiJF8DrKEBgVXPQ+c0LwtfstrOkSTgfBtsnLOtbtFuB0Li0nFMxaGno4ffdpL0ts410be0r+DeuFjQ=
x-ms-office365-filtering-correlation-id: d1bcfb64-e46d-4807-db20-08d48d4c264f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; 
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(24454002)(33656002)(189998001)(561944003)(86362001)(3660700001)(229853002)(3280700002)(66066001)(6916009)(2950100002)(42882006)(57306001)(4326008)(2906002)(8936002)(53546009)(102836003)(36756003)(3846002)(74482002)(38730400002)(39060400002)(6116002)(25786009)(2900100001)(305945005)(6436002)(6246003)(110136004)(7736002)(6306002)(99286003)(82746002)(6512007)(5660300001)(83716003)(6486002)(8676002)(76176999)(53936002)(50986999)(50226002)(81166006)(6506006)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <28C06C5CFE2DF54B8613D8D0C109FC8D@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 09:02:36.4162 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: yyAfBExDPTu-Nx1hjyugIw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 09:02:50 -0000

SGkgQm9iLA0KDQo+IE9uIDI2IEFwciAyMDE3LCBhdCAxOTozOCwgQm9iIEhpbmRlbiA8Ym9iLmhp
bmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPiBCYXNlZCBvbiB0aGUgY29t
bWVudHMgYW5kIElFU0cgZGlzY3Vzc2VzLCBJIGNsYXJpZmllZCB0aGUgdGV4dCBpbiBTZWN0aW9u
IDQuOCBhYm91dCBkZWZpbmluZyBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVycy4gIFRoZSBwcm9w
b3NlZCB0ZXh0IGlzIG11Y2ggY2xvc2VyIHdoYXQgd2FzIGluIFJGQzY1NjQgdGhhdCB1cGRhdGVk
IFJGQzI0NjAuDQo+IA0KPiBDVVJSRU5UIGFuZCBORVcgdGV4dCBpcyBiZWxvdy4NCj4gDQo+IENv
bW1lbnRzPw0KPiANCj4gQm9iDQo+IA0KPiAgIENVUlJFTlQNCj4gDQo+ICAgRGVmaW5pbmcgbmV3
IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgaXMgbm90IHJlY29tbWVuZGVkLiAgVGhlcmUgaGFzIHRv
DQo+ICAgYmUgYSB2ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gd2h5IGFueSBuZXcgZXh0ZW5zaW9u
IGhlYWRlciBpcyBuZWVkZWQNCj4gICBiZWZvcmUgaXQgaXMgc3RhbmRhcmRpemVkLiAgSW5zdGVh
ZCBvZiBkZWZpbmluZyBuZXcgRXh0ZW5zaW9uDQo+ICAgSGVhZGVycywgaXQgaXMgcmVjb21tZW5k
ZWQgdGhhdCB0aGUgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgaXMNCj4gICB1c2VkIHRvIGNh
cnJ5IG9wdGlvbmFsIGluZm9ybWF0aW9uIHRoYXQgbXVzdCBiZSBleGFtaW5lZCBvbmx5IGJ5IGEN
Cj4gICBwYWNrZXQncyBkZXN0aW5hdGlvbiBub2RlKHMpLCBiZWNhdXNlIHRoZXkgcHJvdmlkZSBi
ZXR0ZXIgaGFuZGxpbmcNCj4gICBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCj4gDQo+ICAg
TkVXDQo+IA0KPiAgIERlZmluaW5nIG5ldyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGlzIG5vdCBy
ZWNvbW1lbmRlZCwgdW5sZXNzIG5vDQo+ICAgZXhpc3RpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVy
IGNhbiBiZSB1c2VkIGJ5IHNwZWNpZnlpbmcgYSBuZXcgb3B0aW9uDQo+ICAgZm9yIHRoYXQgZXhp
c3RpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVyLiAgQW55IHByb3Bvc2FsIHRvIGNyZWF0ZSBvcg0K
PiAgIHNwZWNpZnkgYSBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVyIG11c3QgaW5jbHVkZSBhIGRl
dGFpbGVkIHRlY2huaWNhbA0KPiAgIGV4cGxhbmF0aW9uIG9mIHdoeSBubyBleGlzdGluZyBJUHY2
IGV4dGVuc2lvbiBoZWFkZXIgY2FuIGJlIHVzZWQgaW4NCj4gICB0aGUgZG9jdW1lbnQgcHJvcG9z
aW5nIHRoZSBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVyLg0KDQoNClRoYXQgdGV4dCBpcyB2ZXJ5
IGNsb3NlIHRvIHNlY3Rpb24gMyBvZiBSRkM2NTY0LCB3aGljaCBpcyBmaW5lLg0KDQo+ICAgSW5z
dGVhZCBvZiBkZWZpbmluZyBuZXcgRXh0ZW5zaW9uIEhlYWRlcnMsIGl0IGlzIHJlY29tbWVuZGVk
IHRoYXQgdGhlDQo+ICAgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgaXMgdXNlZCB0byBjYXJy
eSBvcHRpb25hbCBpbmZvcm1hdGlvbiB0aGF0DQo+ICAgbXVzdCBiZSBleGFtaW5lZCBvbmx5IGJ5
IGEgcGFja2V0J3MgZGVzdGluYXRpb24gbm9kZShzKSwgYmVjYXVzZSB0aGV5DQo+ICAgcHJvdmlk
ZSBiZXR0ZXIgaGFuZGxpbmcgYW5kIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuDQoNClRoYXTigJlz
IGZpbmUgZm9yIERlc3RpbmF0aW9uIG9wdGlvbnMuIA0KDQpCdXQgSSB0aGluayB0aGUgb3JkZXJp
bmcgb2YgdGhlIHRleHQgaW4gNC44IHdvdWxkIGJlIGEgbGl0dGxlIG9kZCB0aG91Z2gsIHNvIEni
gJlkIHN1Z2dlc3QgdGFraW5nIHdoYXQgeW91IHByb3Bvc2UgKE5FVyB0ZXh0KSBhbmQgcmVvcmRl
cmluZyBzZWN0aW9uIDQuOCBhcyBmb2xsb3dzIChORVcgTkVXKSBzbyB0aGF0IHRoZSB0ZXh0IHRh
bGtzIGF0IGEgaGlnaCBsZXZlbCwgdGhlbiBhYm91dCBIYkgsIHRoZW4gYWJvdXQgZGVzdGluYXRp
b24gb3B0aW9ucywgYWRkaW5nIOKAnEluIHBhcnRpY3VsYXIs4oCdIGFuZCDigJxGdXJ0aGVyLOKA
nSB0byBoZWxwIHRoZSBmbG93Og0KDQrigJQNCg0KTkVXOg0KDQo0LjguICBEZWZpbmluZyBOZXcg
RXh0ZW5zaW9uIEhlYWRlcnMgYW5kIE9wdGlvbnMNCg0KICAgTmV3IGV4dGVuc2lvbiBoZWFkZXJz
IHRoYXQgcmVxdWlyZSBob3AtYnktaG9wIGJlaGF2aW9yIG11c3Qgbm90IGJlDQogICBkZWZpbmVk
IGJlY2F1c2UsIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDQgb2YgdGhpcyBkb2N1bWVudCwgdGhl
IG9ubHkNCiAgIEV4dGVuc2lvbiBIZWFkZXIgdGhhdCBoYXMgaG9wLWJ5LWhvcCBiZWhhdmlvciBp
cyB0aGUgSG9wLWJ5LUhvcA0KICAgT3B0aW9ucyBoZWFkZXIuDQoNCiAgIE5ldyBob3AtYnktaG9w
IG9wdGlvbnMgYXJlIG5vdCByZWNvbW1lbmRlZCBiZWNhdXNlIG5vZGVzIG1heSBiZQ0KICAgY29u
ZmlndXJlZCB0byBpZ25vcmUgdGhlIEhvcC1ieS1Ib3AgT3B0aW9uIGhlYWRlciwgZHJvcCBwYWNr
ZXRzDQogICBjb250YWluaW5nIGEgaG9wLWJ5LWhvcCBoZWFkZXIsIG9yIGFzc2lnbiBwYWNrZXRz
IGNvbnRhaW5pbmcgYSBob3AtDQogICBieS1ob3AgaGVhZGVyIHRvIGEgc2xvdyBwcm9jZXNzaW5n
IHBhdGguICBEZXNpZ25lcnMgY29uc2lkZXJpbmcNCiAgIGRlZmluaW5nIG5ldyBob3AtYnktaG9w
IG9wdGlvbnMgbmVlZCB0byBiZSBhd2FyZSBvZiB0aGlzIGxpa2VseQ0KICAgYmVoYXZpb3VyLiAg
VGhlcmUgaGFzIHRvIGJlIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIHdoeSBhbnkgbmV3DQog
ICBob3AtYnktaG9wIG9wdGlvbiBpcyBuZWVkZWQgYmVmb3JlIGl0IGlzIHN0YW5kYXJkaXplZC4N
Cg0KICBEZWZpbmluZyBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVycyBpcyBub3QgcmVjb21tZW5k
ZWQsIHVubGVzcyBubw0KICBleGlzdGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgY2FuIGJlIHVz
ZWQgYnkgc3BlY2lmeWluZyBhIG5ldyBvcHRpb24NCiAgZm9yIHRoYXQgZXhpc3RpbmcgSVB2NiBl
eHRlbnNpb24gaGVhZGVyLiAgQW55IHByb3Bvc2FsIHRvIGNyZWF0ZSBvcg0KICBzcGVjaWZ5IGEg
bmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBtdXN0IGluY2x1ZGUgYSBkZXRhaWxlZCB0ZWNobmlj
YWwNCiAgZXhwbGFuYXRpb24gb2Ygd2h5IG5vIGV4aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRl
ciBjYW4gYmUgdXNlZCBpbg0KICB0aGUgZG9jdW1lbnQgcHJvcG9zaW5nIHRoZSBuZXcgSVB2NiBl
eHRlbnNpb24gaGVhZGVyLg0KDQogIEluc3RlYWQgb2YgZGVmaW5pbmcgbmV3IEV4dGVuc2lvbiBI
ZWFkZXJzLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZQ0KICBEZXN0aW5hdGlvbiBPcHRpb25z
IGhlYWRlciBpcyB1c2VkIHRvIGNhcnJ5IG9wdGlvbmFsIGluZm9ybWF0aW9uIHRoYXQNCiAgbXVz
dCBiZSBleGFtaW5lZCBvbmx5IGJ5IGEgcGFja2V0J3MgZGVzdGluYXRpb24gbm9kZShzKSwgYmVj
YXVzZSB0aGV5DQogIHByb3ZpZGUgYmV0dGVyIGhhbmRsaW5nIGFuZCBiYWNrd2FyZCBjb21wYXRp
YmlsaXR5Lg0KDQogICBJZiBuZXcgRXh0ZW5zaW9uIEhlYWRlcnMgYXJlIGRlZmluZWQsIHRoZXkg
bmVlZCB0byDigKYuDQoNCuKAlA0KDQpORVcgTkVXOg0KDQo0LjguICBEZWZpbmluZyBOZXcgRXh0
ZW5zaW9uIEhlYWRlcnMgYW5kIE9wdGlvbnMNCg0KICBEZWZpbmluZyBuZXcgSVB2NiBleHRlbnNp
b24gaGVhZGVycyBpcyBub3QgcmVjb21tZW5kZWQsIHVubGVzcyBubw0KICBleGlzdGluZyBJUHY2
IGV4dGVuc2lvbiBoZWFkZXIgY2FuIGJlIHVzZWQgYnkgc3BlY2lmeWluZyBhIG5ldyBvcHRpb24N
CiAgZm9yIHRoYXQgZXhpc3RpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVyLiAgQW55IHByb3Bvc2Fs
IHRvIGNyZWF0ZSBvcg0KICBzcGVjaWZ5IGEgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBtdXN0
IGluY2x1ZGUgYSBkZXRhaWxlZCB0ZWNobmljYWwNCiAgZXhwbGFuYXRpb24gb2Ygd2h5IG5vIGV4
aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlciBjYW4gYmUgdXNlZCBpbg0KICB0aGUgZG9jdW1l
bnQgcHJvcG9zaW5nIHRoZSBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVyLg0KDQogICBJbiBwYXJ0
aWN1bGFyLCBuZXcgZXh0ZW5zaW9uIGhlYWRlcnMgdGhhdCByZXF1aXJlIGhvcC1ieS1ob3AgYmVo
YXZpb3IgbXVzdCBub3QgYmUNCiAgIGRlZmluZWQgYmVjYXVzZSwgYXMgc3BlY2lmaWVkIGluIFNl
Y3Rpb24gNCBvZiB0aGlzIGRvY3VtZW50LCB0aGUgb25seQ0KICAgRXh0ZW5zaW9uIEhlYWRlciB0
aGF0IGhhcyBob3AtYnktaG9wIGJlaGF2aW9yIGlzIHRoZSBIb3AtYnktSG9wDQogICBPcHRpb25z
IGhlYWRlci4NCg0KICAgRnVydGhlciwgbmV3IGhvcC1ieS1ob3Agb3B0aW9ucyBhcmUgbm90IHJl
Y29tbWVuZGVkIGJlY2F1c2Ugbm9kZXMgbWF5IGJlDQogICBjb25maWd1cmVkIHRvIGlnbm9yZSB0
aGUgSG9wLWJ5LUhvcCBPcHRpb24gaGVhZGVyLCBkcm9wIHBhY2tldHMNCiAgIGNvbnRhaW5pbmcg
YSBob3AtYnktaG9wIGhlYWRlciwgb3IgYXNzaWduIHBhY2tldHMgY29udGFpbmluZyBhIGhvcC0N
CiAgIGJ5LWhvcCBoZWFkZXIgdG8gYSBzbG93IHByb2Nlc3NpbmcgcGF0aC4gIERlc2lnbmVycyBj
b25zaWRlcmluZw0KICAgZGVmaW5pbmcgbmV3IGhvcC1ieS1ob3Agb3B0aW9ucyBuZWVkIHRvIGJl
IGF3YXJlIG9mIHRoaXMgbGlrZWx5DQogICBiZWhhdmlvdXIuICBUaGVyZSBoYXMgdG8gYmUgYSB2
ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gd2h5IGFueSBuZXcNCiAgIGhvcC1ieS1ob3Agb3B0aW9u
IGlzIG5lZWRlZCBiZWZvcmUgaXQgaXMgc3RhbmRhcmRpemVkLg0KDQogIFdoZXJlIGEgbmV3IHJl
cXVpcmVtZW50IGFyaXNlcyB0byBjYXJyeSBvcHRpb25hbCBpbmZvcm1hdGlvbiB0aGF0IA0KICBt
dXN0IGJlIGV4YW1pbmVkIG9ubHkgYnkgYSBwYWNrZXQncyBkZXN0aW5hdGlvbiBub2RlKHMpLCBp
bnN0ZWFkIA0KICBvZiBkZWZpbmluZyBuZXcgRXh0ZW5zaW9uIEhlYWRlcnMsIGl0IGlzIHJlY29t
bWVuZGVkIHRoYXQgdGhlIA0KICBleGlzdGluZyBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRlciBp
cyB1c2VkIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uICANCiAoKiBBZGQgdGhlIHJhdGlvbmFs
ZSB0ZXh0IGJhY2sgaW4gaGVyZSBpZiB0aGF04oCZcyBkZWVtZWQgdXNlZnVsOyBpdCBzZWVtcyB1
bm5lY2Vzc2FyeT8gKikNCg0KICAgSWYgbmV3IEV4dGVuc2lvbiBIZWFkZXJzIGFyZSBkZWZpbmVk
LCB0aGV5IG5lZWQgdG8g4oCmLg0KDQrigJQNCg0KQmVzdCB3aXNoZXMsDQpUaW0NCg0KPiANCj4g
ICBFTkQgTkVXDQo+IA0KPiAgIElmIG5ldyBFeHRlbnNpb24gSGVhZGVycyBhcmUgZGVmaW5lZCwg
dGhleSBuZWVkIHRvIHVzZSB0aGUgZm9sbG93aW5nDQo+ICAgZm9ybWF0Og0KPiANCj4gICAuIC4g
LiAuIC4gLg0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBn
cm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1
ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQoNCg==


From nobody Thu Apr 27 05:04:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D636129437 for ; Thu, 27 Apr 2017 05:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8s4E-BGrUhKh for ; Thu, 27 Apr 2017 05:04:32 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B741293F5 for ; Thu, 27 Apr 2017 05:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6700; q=dns/txt; s=iport; t=1493294672; x=1494504272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DJlAPwQ2dCAUx4JQU4tPWD3OgHu3wIVX0OpnPawCGjA=; b=GlA4gA1zx2sGbQeduObg7yOnji468cgfD5x4Uvg8HjEeym/UWwSKP6Id kkyHRYl/NR0XdLeWfpO9GnIqiPDFqlpMJmCt18kTCyiDbhBScmsLCqiSX UaeR+J9qmUoQ24xFEbqygTro5rA7C6NbuesGgfcDpOpzxosirkQyJ1K3M A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAgCL3QFZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKGJEpIYgijUqCDyELhXgCGoN9PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhETMHCwULAgEIGAICJgICAh8GCxUQAgQOBYoFAw0IDqwag?= =?us-ascii?q?iaHMQ2DXwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFSYIJC4JkglOCDIMGLoI?= =?us-ascii?q?xBYk9k1g7AYpJg3aETIIChTeIaIE9ixmJDQEfOIEKbxVEEgGGXXWHaIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,383,1488844800"; d="scan'208";a="238352801"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 12:04:30 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3RC4Uxp010579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 12:04:30 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 08:04:30 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 08:04:30 -0400
From: "Stefano Previdi (sprevidi)" 
To: Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSv05seutrRlhObUyHRTFvWb8cFA==
Date: Thu, 27 Apr 2017 12:04:29 +0000
Message-ID: <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com>
In-Reply-To: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.66.12]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9FF1B6ED465A884592361F1FA22FB721@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 12:04:34 -0000

DQo+IE9uIEFwciAyNSwgMjAxNywgYXQgMTI6NTIgQU0sIEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5A
Z21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gQWZ0ZXIgcmVhZGluZyB0aHJvdWdo
IHRoZSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgdGV4dCBpbiBTZWN0aW9uIDQsIEkgaGF2ZSBzb21l
IG5ldyB0ZXh0IHRvIHByb3Bvc2UuICBJIHRoaW5rIHRoaXMgaXMgc2lnbmlmaWNhbnRseSBpbXBy
b3ZlZCBhbmQgc2hvdWxkIHJlc29sdmUgbWFueSBvZiB0aGUgaXNzdWVkIHJhaXNlZC4NCj4gDQo+
IENoYW5nZXMgaW5jbHVkZSBzZXBhcmF0ZSBkZXNjcmlwdGlvbiBvZiBiZWhhdmlvcnMgZXh0ZW5z
aW9uIGhlYWRlcnMgYW5kIHRoZSBob3AtYnktaG9wIG9wdGlvbiBoZWFkZXIsIHJlbW92ZSDigJxl
eGFtaW5l4oCdIGZyb20gdGhlIGZpcnN0IHBhcmFncmFwaC4gIEkgcmVtb3ZlZCDigJxleGFtaW5l
4oCdIGJlY2F1c2UgSSBhbSBjb252aW5jZWQgaXTigJlzIG5vdCBzdXN0YWluYWJsZSB0byBzYXkg
YSBub2RlIGNhbuKAmXQgZXhhbWluZSBleHRlbnNpb24gZ2l2ZW4gaG93IHdpZGVzcHJlYWQgdGhp
cyBiZWhhdmlvciBpcy4gIEkgYWxzbyByZW1vdmVkIHRoZSByZWZlcmVuY2UgdG8gUkZDNzA0NSBi
ZWNhdXNlIGV4YW1pbmUgaXMgcmVtb3ZlZC4gIFJGQzcwNDUgaXMgcmVmZXJlbmNlZCBpbiB0aGUg
cmVjZW50bHkgdXBkYXRlZCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KPiANCj4g
SSByZW1vdmVkIHRoZSDigJxpbmNsdWRpbmcgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbm9k
ZXPigJ0gdGV4dCBmcm9tIHRoZSBwYXJhZ3JhcGggb24gdGhlIGhvcC1ieS1ob3Agb3B0aW9ucyBo
ZWFkZXIgYmVjYXVzZSBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCB0byBtZW50aW9uIHRoZSBzb3Vy
Y2UsIGFuZCB0aGVyZSBpcyBhIHdob2xlIHBhcmFncmFwaCBkZXNjcmliZSB3aGF0IGhhcHBlbnMg
YXQgdGhlIGRlc3RpbmF0aW9uIG5vZGUuICBJIGFsc28gYWRkZWQgdGhlIHRleHQgYWJvdXQgZnJv
bSB0aGUgZmlyc3QgcGFyYWdyYXBoIGFib3V0IHJlYWNoaW5nIHRoZSBkZXN0aW5hdGlvbiB0byB0
aGUgaG9wLWJ5LWhvcCBoZWFkZXIgcGFyYWdyYXBoLg0KPiANCj4gSSBhbHNvIG1vdmVkICh3aXRo
b3V0IGNoYW5nZSkgdGhlIOKAnEF0IHRoZSBEZXN0aW5hdGlvbiBub2RlLi4u4oCdIHRleHQgZnJv
bSB0aGUgZmlyc3QgcGFyYWdyYXBoIHRvIGEgbmV3IHRoaXJkIHBhcmFncmFwaC4gIEl0IGFwcGxp
ZXMgdG8gYWxsIGV4dGVuc2lvbiBoZWFkZXJzLg0KPiANCj4gQ1VSUkVOVCBhbmQgTkVXIHRleHQg
YmVsb3cuICBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Lg0KPiANCj4gQm9iDQo+IA0KPiANCj4g
ICBDVVJSRU5UDQo+IA0KPiAgIFdpdGggb25lIGV4Y2VwdGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMg
YXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KPiAgIGluc2VydGVkLCBvciBkZWxldGVkIGJ5
IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwNCj4gICB1bnRpbCB0aGUg
cGFja2V0IHJlYWNoZXMgdGhlIG5vZGUgKG9yIGVhY2ggb2YgdGhlIHNldCBvZiBub2RlcywgaW4N
Cj4gICB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9u
IEFkZHJlc3MgZmllbGQgb2YNCj4gICB0aGUgSVB2NiBoZWFkZXIuICBOb3RlOiBJZiBhbiBpbnRl
cm1lZGlhdGUgZm9yd2FyZGluZyBub2RlIGV4YW1pbmVzDQo+ICAgYW4gZXh0ZW5zaW9uIGhlYWRl
ciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBkbyBzbyBpbiBhY2NvcmRhbmNlIHdpdGgNCj4gICB0
aGUgcHJvdmlzaW9ucyBvZiBbUkZDNzA0NV0uICBBdCB0aGUgRGVzdGluYXRpb24gbm9kZSwgbm9y
bWFsDQo+ICAgZGVtdWx0aXBsZXhpbmcgb24gdGhlIE5leHQgSGVhZGVyIGZpZWxkIG9mIHRoZSBJ
UHY2IGhlYWRlciBpbnZva2VzDQo+ICAgdGhlIG1vZHVsZSB0byBwcm9jZXNzIHRoZSBmaXJzdCBl
eHRlbnNpb24gaGVhZGVyLCBvciB0aGUgdXBwZXItbGF5ZXINCj4gICBoZWFkZXIgaWYgbm8gZXh0
ZW5zaW9uIGhlYWRlciBpcyBwcmVzZW50LiAgVGhlIGNvbnRlbnRzIGFuZCBzZW1hbnRpY3MNCj4g
ICBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXIgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHBy
b2NlZWQgdG8gdGhlDQo+ICAgbmV4dCBoZWFkZXIuICBUaGVyZWZvcmUsIGV4dGVuc2lvbiBoZWFk
ZXJzIG11c3QgYmUgcHJvY2Vzc2VkIHN0cmljdGx5DQo+ICAgaW4gdGhlIG9yZGVyIHRoZXkgYXBw
ZWFyIGluIHRoZSBwYWNrZXQ7IGEgcmVjZWl2ZXIgbXVzdCBub3QsIGZvcg0KPiAgIGV4YW1wbGUs
IHNjYW4gdGhyb3VnaCBhIHBhY2tldCBsb29raW5nIGZvciBhIHBhcnRpY3VsYXIga2luZCBvZg0K
PiAgIGV4dGVuc2lvbiBoZWFkZXIgYW5kIHByb2Nlc3MgdGhhdCBoZWFkZXIgcHJpb3IgdG8gcHJv
Y2Vzc2luZyBhbGwNCj4gICBwcmVjZWRpbmcgb25lcy4NCj4gDQo+ICAgVGhlIGV4Y2VwdGlvbiBy
ZWZlcnJlZCB0byBpbiB0aGUgcHJlY2VkaW5nIHBhcmFncmFwaCBpcyB0aGUgSG9wLWJ5LQ0KPiAg
IEhvcCBPcHRpb25zIGhlYWRlciwgd2hpY2ggY2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IG1heSBi
ZSBleGFtaW5lZA0KPiAgIGFuZCBwcm9jZXNzZWQgYnkgZXZlcnkgbm9kZSBhbG9uZyBhIHBhY2tl
dCdzIGRlbGl2ZXJ5IHBhdGgsIGluY2x1ZGluZw0KPiAgIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0
aW9uIG5vZGVzLiAgVGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIsDQo+ICAgd2hlbiBwcmVz
ZW50LCBtdXN0IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJdHMgcHJlc2Vu
Y2UNCj4gICBpcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIHplcm8gaW4gdGhlIE5leHQgSGVhZGVy
IGZpZWxkIG9mIHRoZSBJUHY2DQo+ICAgaGVhZGVyLg0KPiANCj4gICBORVcNCj4gDQo+ICAgRXh0
ZW5zaW9uIGhlYWRlcnMgKGV4Y2VwdCBmb3IgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIp
IGFyZSBub3QNCg0KDQpteSByZWNvbW1lbmRhdGlvbiBpcyB0byBjaGFuZ2Ug4oCcYXJlIG5vdOKA
nSB3aXRoIOKAnFNIT1VMRCBOT1TigJ0uDQoNClRoaXMgZG9lc27igJl0IGNoYW5nZSB3aGF0IHRo
ZSBjdXJyZW50IHRleHQgYXNzdW1lcyB3aGlsZSBpdCB1c2VzIGEgbW9yZSBmb3JtYWwgbGFuZ3Vh
Z2UuDQoNCnMuDQoNCg0KPiAgIHByb2Nlc3NlZCwgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55
IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeQ0KPiAgIHBhdGgsIHVudGlsIHRoZSBwYWNr
ZXQgcmVhY2hlcyB0aGUgbm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLA0KPiAgIGlu
IHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRk
cmVzcyBmaWVsZA0KPiAgIG9mIHRoZSBJUHY2IGhlYWRlci4NCj4gDQo+ICAgVGhlIEhvcC1ieS1I
b3AgT3B0aW9ucyBoZWFkZXIgaXMgbm90IGluc2VydGVkIG9yIGRlbGV0ZWQsIGJ1dCBtYXkgYmUN
Cj4gICBleGFtaW5lZCBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQn
cyBkZWxpdmVyeSBwYXRoLA0KPiAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAo
b3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KPiAgIHRoZSBjYXNlIG9mIG11bHRpY2Fz
dCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KPiAgIHRo
ZSBJUHY2IGhlYWRlci4gIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLCB3aGVuIHByZXNl
bnQsIG11c3QNCj4gICBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVyLiAgSXRzIHBy
ZXNlbmNlIGlzIGluZGljYXRlZCBieSB0aGUNCj4gICB2YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhl
YWRlciBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIuDQo+IA0KPiAgIEF0IHRoZSBEZXN0aW5hdGlv
biBub2RlLCBub3JtYWwgZGVtdWx0aXBsZXhpbmcgb24gdGhlIE5leHQgSGVhZGVyDQo+ICAgZmll
bGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMgdGhlIG1vZHVsZSB0byBwcm9jZXNzIHRoZSBm
aXJzdA0KPiAgIGV4dGVuc2lvbiBoZWFkZXIsIG9yIHRoZSB1cHBlci1sYXllciBoZWFkZXIgaWYg
bm8gZXh0ZW5zaW9uIGhlYWRlciBpcw0KPiAgIHByZXNlbnQuICBUaGUgY29udGVudHMgYW5kIHNl
bWFudGljcyBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXINCj4gICBkZXRlcm1pbmUgd2hldGhlciBv
ciBub3QgdG8gcHJvY2VlZCB0byB0aGUgbmV4dCBoZWFkZXIuICBUaGVyZWZvcmUsDQo+ICAgZXh0
ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQgc3RyaWN0bHkgaW4gdGhlIG9yZGVyIHRo
ZXkgYXBwZWFyDQo+ICAgaW4gdGhlIHBhY2tldDsgYSByZWNlaXZlciBtdXN0IG5vdCwgZm9yIGV4
YW1wbGUsIHNjYW4gdGhyb3VnaCBhDQo+ICAgcGFja2V0IGxvb2tpbmcgZm9yIGEgcGFydGljdWxh
ciBraW5kIG9mIGV4dGVuc2lvbiBoZWFkZXIgYW5kIHByb2Nlc3MNCj4gICB0aGF0IGhlYWRlciBw
cmlvciB0byBwcm9jZXNzaW5nIGFsbCBwcmVjZWRpbmcgb25lcy4NCj4gDQo+ICAgRU5EIE5FVw0K
PiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0
DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo=


From nobody Thu Apr 27 05:36:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0A127909; Thu, 27 Apr 2017 05:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_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 tidE2CuCJ5qs; Thu, 27 Apr 2017 05:36:34 -0700 (PDT)
Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 8EB0D126B7F; Thu, 27 Apr 2017 05:36:34 -0700 (PDT)
Received: by mail-wr0-x242.google.com with SMTP id v42so3630544wrc.3; Thu, 27 Apr 2017 05:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5VudjgTR5zvQXsq5QUfqINOO5xHr5CN60JUHEd4AQzc=; b=oOo9XLx2hviC5JdIn/usK3Tb55cNEHmC7gztnhPPd611GAMDWWRA4EAWOuLKGxunTj 0qNs8hpFCAPrvRplPJi2hR6gcFq/uHT4tf4DJAUUE48NU8z5fPUp780jnVgssGFwrumE xZ1gc6RUZ/iF3aGODy3ulFAiljtRQ+pC+X8N3L/QZsLpqActVx8Xp/tfeJOvl1kpR1c1 9bGv2VILBv6eQo9zNq02pm7fQCaBDSXM3rEHAN93II82iMRtq1Zy9+jthv9vRiamXoe0 XT8zeuPMFlILbQ44SVLLeMDLN2l+ThLfH/qyLdF7H74IPFUEPlJUia7HOtJQ6tQXdWvQ mAsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5VudjgTR5zvQXsq5QUfqINOO5xHr5CN60JUHEd4AQzc=; b=SjZP/3Umm8t7Qa0oGjCxkbd+RMy6s0UtZPvfFwzSOy2nq8UTE2l6uXJXFq4BEbAxmk 1kNZTVqJBKOwL1yLGdbWb/KNVjM03UKEtC89cMPIgQAJ7SpZ3sQy2lLW0toft+PGiB6y XD13BJ2DJ6Gnyt1F9990cpJeq7+IBh7knqY/FXqly0bCrOSHXnEJKtPx0ld01pDRtbge JAHhicuBW2bJ3I+ScsZL4KlEq0rEzmwc05SDBzqqOANtig8xhs8PeAxh9JQmDaprZSU/ LOs+9fHe8fuQPU2IPA2AmwW/9FsLAoxeeQWd9l1koqjCtXccAJHJHRGa1VBVlUnllOd9 NmpQ==
X-Gm-Message-State: AN3rC/4pgIHaPxfz5VZoBzJbk1w9D6bj6Iy+4DsiVKCjjdsJbqOvQj24 IMlFa7M7yknPvA==
X-Received: by 10.223.162.147 with SMTP id s19mr3355901wra.142.1493296592995;  Thu, 27 Apr 2017 05:36:32 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i199sm3164441wmf.33.2017.04.27.05.36.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 05:36:32 -0700 (PDT)
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06
To: Brian E Carpenter , Fred Baker , Joe Touch 
References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu>   <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> 
Cc: gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org
From: Stewart Bryant 
Message-ID: <8fdddab8-dba8-d151-6552-882d2c9a7918@gmail.com>
Date: Thu, 27 Apr 2017 13:36:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 12:36:37 -0000

On 26/04/2017 21:30, Brian E Carpenter wrote:
> On 27/04/2017 08:08, Fred Baker wrote:
>>> On Apr 26, 2017, at 11:35 AM, Joe Touch  wrote:
>>>
>>> Hi, Stewart,
>>>
>>>
>>> On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>>>>
>>>> On 25/04/2017 19:26, Joe Touch wrote:
>>>>> Hi, Stewart,
>>>>>
>>>>> ...
>>>>>
>>>>>> SB>
>>>>>> SB> Otherwise I would have thought that this was entirely a matter
>>>>>> SB> for the host whether it wanted to use a Path MTU below the IPv6
>>>>>> SB> link minimum. Nothing breaks if the host takes a more conservative
>>>>>> SB> decision.
>>>>> I don't agree; the host at that point is violating RFC2460. It should
>>>>> never think that an IPv6 link or path with an MTU below what RFC2460
>>>>> requires is valid.
>>>>>
>>>>> Joe
>>>>>
>>>> That is as maybe, but a host can do more or less what it wants, so
>>>> this is surely an
>>>> unenforceable constraint, or are you telling me that the receiving
>>>> host MUST drop a
>>>> fragment that is shorter than this? In which case the question whether
>>>> in practice
>>>> they do, and whether such a constraint is reasonable.
>>> A "path MTU" is a value calculated from information from various sources
>>> (attached links, ICMP messages, and perhaps other information), but IMO
>>> it's never appropriate to set a "path MTU" smaller than the limit
>>> established by IPv6 for a single link.
>> You are, of course, quoting RFC 1981:
>>     A node MUST NOT reduce its estimate of the Path MTU below the IPv6
>>     minimum link MTU.
>>
>>> Individual packets and fragments can be smaller than the MTU, of course.
>>> Nothing forces fragments to push up against any MTU limit at all. But I
>>> would not describe that has a host changing its path MTU; it's just
>>> sending packets.
>> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
> istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?
>
>      Brian
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

So this seems to me to be an argument of principle vs pragmatism, and in 
general pragmatism has served the Internet well so far.

I think pragmatism is what Fred and Brian arguing for. It is certainly 
the general approach that I support.

I think we have agreed that nothing actually breaks if the host takes a 
more conservative approach, and that the communications path is less 
likely to be disrupted if that is what the host does. I would have 
thought that we should write the text in such a way to "allow" a 
pragmatic mode of operation.

- Stewart




From nobody Thu Apr 27 10:00:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F2129B37; Thu, 27 Apr 2017 10:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Vy4WfhiOxJxD; Thu, 27 Apr 2017 10:00:15 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 A61B0129B51; Thu, 27 Apr 2017 09:57:59 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3RGvh92009153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Apr 2017 09:57:43 -0700 (PDT)
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06
To: Stewart Bryant , Brian E Carpenter , Fred Baker 
Cc: gen-art@ietf.org, 6man WG , IETF-Discussion Discussion , draft-ietf-6man-rfc1981bis.all@ietf.org
References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu>   <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com>  <8fdddab8-dba8-d151-6552-882d2c9a7918@gmail.com>
From: Joe Touch 
Message-ID: 
Date: Thu, 27 Apr 2017 09:57:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <8fdddab8-dba8-d151-6552-882d2c9a7918@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 17:00:17 -0000

On 4/27/2017 5:36 AM, Stewart Bryant wrote:
> ...
> So this seems to me to be an argument of principle vs pragmatism, and
> in general pragmatism has served the Internet well so far.
>
> I think pragmatism is what Fred and Brian arguing for. It is certainly
> the general approach that I support.

IMO, 1981bis should limit its advice to behavior in response to ICMPs, e.g.:

   In reaction to a received ICMP message, a node MUST NOT reduce its estimate of the Path MTU below the IPv6
   minimum link MTU.

Doing otherwise presents too big an attack surface.

Any other advice on how an end system manages its idea of MTU or
otherwise overrides the 1981bis computation of path MTU should be
limited to host requirements documents, not this one.

Joe


From nobody Thu Apr 27 11:40:58 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8ED129B42; Thu, 27 Apr 2017 11:40:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , <6man-chairs@ietf.org>
Subject: The 6MAN WG has placed draft-clw-rfc6434-bis in state "Adopted by a WG"
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149331845710.2963.3652981885115129375.idtracker@ietfa.amsl.com>
Date: Thu, 27 Apr 2017 11:40:57 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 18:40:57 -0000

The 6MAN WG has placed draft-clw-rfc6434-bis in state 
Adopted by a WG (entered by Ole Troan)

The document is available at
https://datatracker.ietf.org/doc/draft-clw-rfc6434-bis/


From nobody Thu Apr 27 11:43:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8786C128D2E for ; Thu, 27 Apr 2017 11:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 5j4U2gCTJ2E4 for ; Thu, 27 Apr 2017 11:43:10 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5A5129AEB for ; Thu, 27 Apr 2017 11:39:55 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 27 Apr 2017 18:39:54 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id DE425D788B; Thu, 27 Apr 2017 11:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=j8BA0tn49foQp56c9flEfFbyPVc=; b= Hq4DnuP3BZ0x2Br73lcbQ6epXmcoeXUQsp/98enXg2MIxl8KxP/QfTINWsl6AGtt wPEo7xg2v2zpZsFwrOp64/AJkbg69aWBJP5AOu0ppfIbKrdGwj1ZdS3kQFzdPRbW z24ehmU1Gup0zExGeVUVCEL+acsN87UUUT9c33l+bvQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=kfLOAwsrO0QqBvST/1J7Au4 lCNKOT8+uiqZI6f1f+WHx93GyOVNpHZfbVmqasZZRnRB0ruVT2JUiUYQGbIWD9cp UhZBbWcbR2DvRidlipAUe8H4YhDaumNt81RwU8By8cMjz0+XXX+AckXVej+fSZ7I pyPfP+EFdeWjO6jIobeQ=
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A9A63D788A; Thu, 27 Apr 2017 11:39:53 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 80E6EB254525; Thu, 27 Apr 2017 20:39:50 +0200 (CEST)
From: otroan@employees.org
Message-Id: <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_364BD933-4BC8-4B4C-BB6E-8A678E6BE8B4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
Date: Thu, 27 Apr 2017 20:39:49 +0200
In-Reply-To: 
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Bob Hinden 
To: 6man WG , Tim Chown , Timothy Winters 
References: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 18:43:11 -0000

--Apple-Mail=_364BD933-4BC8-4B4C-BB6E-8A678E6BE8B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

As there were no objections this document is now adopted as a working =
group document.
Authors, can you please re-submit the last revision as =
draft-ietf-6man-rfc6434bis-00.

Best regards,
Ole & Bob

> On 7 Apr 2017, at 22:38, Bob Hinden  wrote:
>=20
> At the Chicago IETF 6MAN session there was clear consensus for =
adopting draft-clw-rfc6434-bis as a 6MAN working group document.  This =
message starts a one week call on confirming the consensus from the WG =
meeting.
>=20
>        Title           : IPv6 Node Requirements
>        Authors         : Tim Chown
>                          John Loughney
>                          Tim Winters
> 	Filename        : draft-clw-rfc6434-bis-01.txt
> 	Pages           : 34
> 	Date            : 2017-03-13
>=20
>        https://tools.ietf.org/html/draft-clw-rfc6434-bis-01
>=20
> Please respond only if you think this document should _not_ be =
adopted.
> This adoption call will end on April 14, 2017.
>=20
> Regards,
>=20
> Bob & Ole
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_364BD933-4BC8-4B4C-BB6E-8A678E6BE8B4
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-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJZAjr2AAoJEL7aWKiYQt92s2sP+weugdHPGl6sB4k9xl1CQylP
j4+4ZqNT9qSVNffuKTHcpox65VcAV4rcJvoTcnKjPSfQ31RxHBZ7B/Iw21UAYUSZ
IJEVDzjGAcB6hSA2gnTLcgTjdV9k5mK7uJLJ1pJNBQMboYnC8FQJj27hHObplHJc
oDQl1kd50ynI6xtwcWB4RCI61e7Bk0CqptbUyOVPSJR6yoJVgWF5DQaZym7PXBrs
i+jOcyr5D8mmI41irAhS5rJdGHfOiKfW+jAmVlyoxxwxqCUzgd7IJ7VCwxZam+w9
Br7U0abSOdIucEI/zjBL4BjNC3seOavUaBenKHPQ1EpBLMNlTcaJ/94+4AeNNtAt
X2RDvt64ZQrveOqCc3YwSQqPR7arxzrXmVcXwm3dm4a+ZWbxwIecRzDNTqwbkllI
AGGNE8H+VwIOfO9T+JX8srauObsj3+Ld4QOt6UOvdRSPNZIYD3rUGbg3ddSdmps1
fdAXf8EgMCnRQYbVzdKyhoWGdGkrq0Q4qcJMDb1GXJr0LJpyctyoxVRYSNnmBYyX
QTkzX9ePegi6e195V8q7NuTYYZt6oBy5vbCWlXZ+zEb2OMYk81Ja/lekrQErLeec
unaHkt6aaxfnS8Eu+83Eob7UupY90bfMRYTVXcAy65K1a5M4yiPMxhXN+j0gSRHS
zwi++VFLIvmHSGTYUrZY
=0jq/
-----END PGP SIGNATURE-----

--Apple-Mail=_364BD933-4BC8-4B4C-BB6E-8A678E6BE8B4--


From nobody Thu Apr 27 11:55:38 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1DB129C14; Thu, 27 Apr 2017 11:55:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
Cc: ot@cisco.com, suresh.krishnan@gmail.com, ipv6@ietf.org, 6man-chairs@ietf.org
Subject: 6man - New Meeting Session Request for IETF 99
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149331933646.2983.4989317090798620937.idtracker@ietfa.amsl.com>
Date: Thu, 27 Apr 2017 11:55:36 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 18:55:36 -0000

A new meeting session request has just been submitted by Ole Troan, a Chair of the 6man working group.


---------------------------------------------------------
Working Group Name: IPv6 Maintenance
Area Name: Internet Area
Session Requester: Ole Troan

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 150
Conflicts to Avoid: 
 First Priority: 6lo 6tisch dhc homenet intarea v6ops spring mtgvenue




People who must be present:
  Robert M. Hinden
  Ole Troan
  Suresh Krishnan

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Thu Apr 27 13:02:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36E129517 for ; Thu, 27 Apr 2017 13:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5NgcjeT1I4jZ for ; Thu, 27 Apr 2017 13:02:32 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD32128B4E for ; Thu, 27 Apr 2017 12:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5481; q=dns/txt; s=iport; t=1493323129; x=1494532729; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M+6vra2if3kJHyo/ubrZMl4zyPBfNOiWKfV6TgYlF7g=; b=bvH3PUtVjbhEa8N5RoD1v287BvD3Va8Jerg5A8aUvX5uRq3RBElqVaT2 ZrnFEVZRII+73KEuAT1mAb3eepn1Bv2nOK3TKZhYn5asLf6bUAFg7qJYg tf80kzsvqVMdERvyYWYjz0EpQgr4XgHOTi9qhh37dDcpHl6mdxI0nbvCR 4=;
X-IronPort-AV: E=Sophos;i="5.37,385,1488844800"; d="scan'208";a="236727301"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 19:58:49 +0000
Received: from [10.24.35.235] ([10.24.35.235]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3RJwiF0031893; Thu, 27 Apr 2017 19:58:47 GMT
Message-ID: <59024D70.4030408@cisco.com>
Date: Thu, 27 Apr 2017 12:58:40 -0700
From: "Ahmed Bashandy (bashandy)" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Stefano Previdi (sprevidi)" , Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
In-Reply-To: <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 20:02:34 -0000

Agreed

rfc2119 has clear definition of the normative language that alleviates 
any ambiguity. So it is always good to use them

Ahmed


On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
>> On Apr 25, 2017, at 12:52 AM, Bob Hinden  wrote:
>>
>> Hi,
>>
>> After reading through the discussion about this text in Section 4, I have some new text to propose.  I think this is significantly improved and should resolve many of the issued raised.
>>
>> Changes include separate description of behaviors extension headers and the hop-by-hop option header, remove “examine” from the first paragraph.  I removed “examine” because I am convinced it’s not sustainable to say a node can’t examine extension given how widespread this behavior is.  I also removed the reference to RFC7045 because examine is removed.  RFC7045 is referenced in the recently updated Security Considerations section.
>>
>> I removed the “including the source and destination nodes” text from the paragraph on the hop-by-hop options header because I don’t think we need to mention the source, and there is a whole paragraph describe what happens at the destination node.  I also added the text about from the first paragraph about reaching the destination to the hop-by-hop header paragraph.
>>
>> I also moved (without change) the “At the Destination node...” text from the first paragraph to a new third paragraph.  It applies to all extension headers.
>>
>> CURRENT and NEW text below.  Please review and comment.
>>
>> Bob
>>
>>
>>    CURRENT
>>
>>    With one exception, extension headers are not examined, processed,
>>    inserted, or deleted by any node along a packet's delivery path,
>>    until the packet reaches the node (or each of the set of nodes, in
>>    the case of multicast) identified in the Destination Address field of
>>    the IPv6 header.  Note: If an intermediate forwarding node examines
>>    an extension header for any reason, it must do so in accordance with
>>    the provisions of [RFC7045].  At the Destination node, normal
>>    demultiplexing on the Next Header field of the IPv6 header invokes
>>    the module to process the first extension header, or the upper-layer
>>    header if no extension header is present.  The contents and semantics
>>    of each extension header determine whether or not to proceed to the
>>    next header.  Therefore, extension headers must be processed strictly
>>    in the order they appear in the packet; a receiver must not, for
>>    example, scan through a packet looking for a particular kind of
>>    extension header and process that header prior to processing all
>>    preceding ones.
>>
>>    The exception referred to in the preceding paragraph is the Hop-by-
>>    Hop Options header, which carries information that may be examined
>>    and processed by every node along a packet's delivery path, including
>>    the source and destination nodes.  The Hop-by-Hop Options header,
>>    when present, must immediately follow the IPv6 header.  Its presence
>>    is indicated by the value zero in the Next Header field of the IPv6
>>    header.
>>
>>    NEW
>>
>>    Extension headers (except for the Hop-by-Hop Options header) are not
>
> my recommendation is to change “are not” with “SHOULD NOT”.
>
> This doesn’t change what the current text assumes while it uses a more formal language.
>
> s.
>
>
>>    processed, inserted, or deleted by any node along a packet's delivery
>>    path, until the packet reaches the node (or each of the set of nodes,
>>    in the case of multicast) identified in the Destination Address field
>>    of the IPv6 header.
>>
>>    The Hop-by-Hop Options header is not inserted or deleted, but may be
>>    examined and processed by every node along a packet's delivery path,
>>    until the packet reaches the node (or each of the set of nodes, in
>>    the case of multicast) identified in the Destination Address field of
>>    the IPv6 header.  The Hop-by-Hop Options header, when present, must
>>    immediately follow the IPv6 header.  Its presence is indicated by the
>>    value zero in the Next Header field of the IPv6 header.
>>
>>    At the Destination node, normal demultiplexing on the Next Header
>>    field of the IPv6 header invokes the module to process the first
>>    extension header, or the upper-layer header if no extension header is
>>    present.  The contents and semantics of each extension header
>>    determine whether or not to proceed to the next header.  Therefore,
>>    extension headers must be processed strictly in the order they appear
>>    in the packet; a receiver must not, for example, scan through a
>>    packet looking for a particular kind of extension header and process
>>    that header prior to processing all preceding ones.
>>
>>    END NEW
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Apr 27 13:58:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762971292AE for ; Thu, 27 Apr 2017 13:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_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 fDHcK7fwY6Sf for ; Thu, 27 Apr 2017 13:58:02 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 BBB99129C07 for ; Thu, 27 Apr 2017 13:54:25 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id 194so37602258pfv.3 for ; Thu, 27 Apr 2017 13:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/ee09pmM77WLXRRXDjjpPFhrRH9hF7/JaRzwpsWCujE=; b=A5tD4kw9ado/Dyjna3fEnBeVCLMMKB4fpVZGUmj3lPYl50PTDt8bs8Vdd4v85BhICN 6ZdXfCzGts4tws4s/Bvu2me0VxG5PoemPMbIPfwU4DUe+BIr7RsHaNVQu0bBnSVIFUN1 UFZdeQBCsbJ/V4tI3/kfSoZNtdyYOI2ZVV4/HqNNMJ7qvU/lNJ2dHYYWHp77z3wyHIHi Bdhr5uQfGtSnksnpSXwYaJ1CA+WNWvxtt2WQFMHjoKFk5aPnFfFYCPsfJJD2jv1HfKoa DlHuP8QZU0ANN/SM0SoJfD9Ajk9ztW41ATsfGa7j8gJ/WQgVabF6lHk11V9sbar9AtCO lKHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=/ee09pmM77WLXRRXDjjpPFhrRH9hF7/JaRzwpsWCujE=; b=Y9RPMN5DludcFb/aPDRCsBz+IveUvvmVJxM5rosNptp0F7BDN5vKhPE+EWByUWyw/t 0R0hK1Cq50GYkEAQrU1EqHzj1kdGfnb0s7qacE84iRLZ0tHcmzPjZoM59XOBytfeW027 lb/FY1X/GOURJXGiGq+W5zpwCMwe/ND9Tdb3s4G0oh0anjUtVyc8CGE3xg4oDx9QgbWS htcV8j5U7QdjPCCyxif1Xcn/KdrIEiI2kon8C8mkyE0iRcn/Rju61scMiihvPKiphmdR 6tX9arLPJXSAuycHe61TKr2ivll6NifOBgZUZW0bQFrauxWN0/yrXv5bH7FQbm+iY9ef s6iA==
X-Gm-Message-State: AN3rC/6HRCIj0cve7mmo0o2MEqSxby4U4bCiiMGJnZx6hwAIbyGUjcjS vU5Z8hjURlZhIg==
X-Received: by 10.98.218.68 with SMTP id w4mr8191916pfl.246.1493326465277; Thu, 27 Apr 2017 13:54:25 -0700 (PDT)
Received: from ?IPv6:2406:e007:768a:1:28cc:dc4c:9703:6781? ([2406:e007:768a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t6sm7324336pgt.55.2017.04.27.13.54.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 13:54:24 -0700 (PDT)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: "Ahmed Bashandy (bashandy)" , "Stefano Previdi (sprevidi)" , Bob Hinden 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>
Cc: IPv6 List 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 28 Apr 2017 08:54:27 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <59024D70.4030408@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 20:58:04 -0000

On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
> Agreed
>=20
> rfc2119 has clear definition of the normative language that alleviates =

> any ambiguity. So it is always good to use them

iirc the WG already agreed to the editor's choice to follow RFC2460 by us=
ing
plain English rather than RFC2119. And "are not" does not mean the same t=
hing
as "should not", with or without upper case letters. Personally, I agree =
with
"are not" and disagree with "should not", which changes the meaning.

   Brian

>=20
> Ahmed
>=20
>=20
> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden  wrote=
:
>>>
>>> Hi,
>>>
>>> After reading through the discussion about this text in Section 4, I =
have some new text to propose.  I think this is significantly improved an=
d should resolve many of the issued raised.
>>>
>>> Changes include separate description of behaviors extension headers a=
nd the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D from th=
e first paragraph.  I removed =E2=80=9Cexamine=E2=80=9D because I am conv=
inced it=E2=80=99s not sustainable to say a node can=E2=80=99t examine ex=
tension given how widespread this behavior is.  I also removed the refere=
nce to RFC7045 because examine is removed.  RFC7045 is referenced in the =
recently updated Security Considerations section.
>>>
>>> I removed the =E2=80=9Cincluding the source and destination nodes=E2=80=
=9D text from the paragraph on the hop-by-hop options header because I do=
n=E2=80=99t think we need to mention the source, and there is a whole par=
agraph describe what happens at the destination node.  I also added the t=
ext about from the first paragraph about reaching the destination to the =
hop-by-hop header paragraph.
>>>
>>> I also moved (without change) the =E2=80=9CAt the Destination node...=
=E2=80=9D text from the first paragraph to a new third paragraph.  It app=
lies to all extension headers.
>>>
>>> CURRENT and NEW text below.  Please review and comment.
>>>
>>> Bob
>>>
>>>
>>>    CURRENT
>>>
>>>    With one exception, extension headers are not examined, processed,=

>>>    inserted, or deleted by any node along a packet's delivery path,
>>>    until the packet reaches the node (or each of the set of nodes, in=

>>>    the case of multicast) identified in the Destination Address field=
 of
>>>    the IPv6 header.  Note: If an intermediate forwarding node examine=
s
>>>    an extension header for any reason, it must do so in accordance wi=
th
>>>    the provisions of [RFC7045].  At the Destination node, normal
>>>    demultiplexing on the Next Header field of the IPv6 header invokes=

>>>    the module to process the first extension header, or the upper-lay=
er
>>>    header if no extension header is present.  The contents and semant=
ics
>>>    of each extension header determine whether or not to proceed to th=
e
>>>    next header.  Therefore, extension headers must be processed stric=
tly
>>>    in the order they appear in the packet; a receiver must not, for
>>>    example, scan through a packet looking for a particular kind of
>>>    extension header and process that header prior to processing all
>>>    preceding ones.
>>>
>>>    The exception referred to in the preceding paragraph is the Hop-by=
-
>>>    Hop Options header, which carries information that may be examined=

>>>    and processed by every node along a packet's delivery path, includ=
ing
>>>    the source and destination nodes.  The Hop-by-Hop Options header,
>>>    when present, must immediately follow the IPv6 header.  Its presen=
ce
>>>    is indicated by the value zero in the Next Header field of the IPv=
6
>>>    header.
>>>
>>>    NEW
>>>
>>>    Extension headers (except for the Hop-by-Hop Options header) are n=
ot
>>
>> my recommendation is to change =E2=80=9Care not=E2=80=9D with =E2=80=9C=
SHOULD NOT=E2=80=9D.
>>
>> This doesn=E2=80=99t change what the current text assumes while it use=
s a more formal language.
>>
>> s.
>>
>>
>>>    processed, inserted, or deleted by any node along a packet's deliv=
ery
>>>    path, until the packet reaches the node (or each of the set of nod=
es,
>>>    in the case of multicast) identified in the Destination Address fi=
eld
>>>    of the IPv6 header.
>>>
>>>    The Hop-by-Hop Options header is not inserted or deleted, but may =
be
>>>    examined and processed by every node along a packet's delivery pat=
h,
>>>    until the packet reaches the node (or each of the set of nodes, in=

>>>    the case of multicast) identified in the Destination Address field=
 of
>>>    the IPv6 header.  The Hop-by-Hop Options header, when present, mus=
t
>>>    immediately follow the IPv6 header.  Its presence is indicated by =
the
>>>    value zero in the Next Header field of the IPv6 header.
>>>
>>>    At the Destination node, normal demultiplexing on the Next Header
>>>    field of the IPv6 header invokes the module to process the first
>>>    extension header, or the upper-layer header if no extension header=
 is
>>>    present.  The contents and semantics of each extension header
>>>    determine whether or not to proceed to the next header.  Therefore=
,
>>>    extension headers must be processed strictly in the order they app=
ear
>>>    in the packet; a receiver must not, for example, scan through a
>>>    packet looking for a particular kind of extension header and proce=
ss
>>>    that header prior to processing all preceding ones.
>>>
>>>    END NEW
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Apr 27 14:38:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA4B129BB6 for ; Thu, 27 Apr 2017 14:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 7f3IczJvYVft for ; Thu, 27 Apr 2017 14:38:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87867129BCA for ; Thu, 27 Apr 2017 14:35:10 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 445FD2009E for ; Thu, 27 Apr 2017 18:00:45 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6CD77636BB for ; Thu, 27 Apr 2017 17:35:09 -0400 (EDT)
From: Michael Richardson 
To: 6man WG 
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
In-Reply-To: <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org>
References:  <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 21:38:15 -0000

--=-=-=
Content-Type: text/plain


otroan@employees.org wrote:
    > As there were no objections this document is now adopted as a working
    > group document.  Authors, can you please re-submit the last revision as
    > draft-ietf-6man-rfc6434bis-00.

I agree with adopting it.

I think that, given the pushback we have on rfc2460bis, that I would like to
make some progress on 6434bis before we attempt to finalize 2460bis.

I think that we should not have done these one at a time.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkCZA0ACgkQgItw+93Q
3WWs1ggAih725XjUMsxcRoN0jXsbFeULMkV80FEjeyKuSkk/0xXtkkK+O7cmTZj2
xI3rwi7fVQABCA7suA7DIbNeJ4WBuw9eI805DzyBRxbJvHP8qm1AgdWxlMLHKcQN
XdmUBX7/pLXYG90vGh7l9RP7d1l2DaDw+3zK3t9e5r7b/la6I0ST8Xr3w5Eqph1Y
yfP23/JjWAJecATh/SkFOfVzr3vqYVG8Uur05k7mcVaV21ebl19vIJu5qGkiIKFd
ix1sRew88Z4GVyod8SPkX8Ceb7hG6OR/fyuhGNLbguW4BAC2SIXv0Ac371x00o1R
oYgCkbk0OUI+ydLVI0o3r3gJP8dV6w==
=sYsA
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Apr 27 14:48:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C607212943C for ; Thu, 27 Apr 2017 14:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 Ld_l326xCzCm for ; Thu, 27 Apr 2017 14:48:46 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 C85EB129BB8 for ; Thu, 27 Apr 2017 14:45:22 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id g66so26071926ite.1 for ; Thu, 27 Apr 2017 14:45:22 -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=tUpbOiEklZO2+3nOwXqVbrHZ++YSVaTjm9ewfC5MdKQ=; b=aoAGWXRPIJP5V6RqwVkdC2KFFFY0cEBfcC0JcRrs0RMl30uZe/+4TH0EPRxbZ2g3gT 8g/89henn546CPxzEcYadQEbGEZYY2r/dc4rczExHallj20jFoLXNXSspSt6rPiEhax2 uzTaAq8mL3sZ1fCV5UUm5nu+48HnOJ2ugGWOCCg7Z5XyJpciSUSnWYeyZ1ha688azDxi OXNOLh7UFvi0iWcsMDM1wU+YpeyMfPzpw6qb8jEHULCpLbIKpKmApX6mq5K8VSDviDlN z1Jyo2Bo9O2ESR9q5tHXuEgN6MshFpbE3kVFsi0f5E4wzpHzhAnHey0Hkv4olEXeoHAD utEw==
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=tUpbOiEklZO2+3nOwXqVbrHZ++YSVaTjm9ewfC5MdKQ=; b=LPKIEaAo4cBiuDzdu3mp9iSJPMXG0EnevVMI3a8SaqwDqOsN2zaRc4ANyjH/kbaszx 6ikjMjIa5Vizi49PWivA/oy9yNS1XVdWBqqZ0O4kpWVuBWDLZeoL0sVgWs8qpOp4LGQk CJhLP4ce2CWE4JbIk+TdOegweGDr//tjHYol5blSejb1mUfoIXFV/h/yVmAcC9ygCsTJ mLbZOiYnsCDjcp0tvycRx/t9gH3d6dUagVeMOJYqVYrp7hODpkKtjBxhu3axC/jbSOtx eTqZ8KXYbqIH9JulDHnZsbH4pPm3DEm80n4s5U2sKrGB0sI5e2G1Hha3gffmHVpm/pLO WVHw==
X-Gm-Message-State: AN3rC/5W522lRgW4MVVv8JX49TAHJlim9ZGxFv5zDyCXYV1XraVhozqC 9hwIbfDl9E/MZw==
X-Received: by 10.36.172.45 with SMTP id s45mr5660477ite.11.1493329522082; Thu, 27 Apr 2017 14:45:22 -0700 (PDT)
Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id x94sm312946ita.2.2017.04.27.14.45.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 14:45:21 -0700 (PDT)
From: Bob Hinden 
Message-Id: <75ACCE55-CA38-498C-B9C4-B1EA083CFB76@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3E3F40DD-6CDC-48DA-A258-6B5FDA298A95"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Date: Thu, 27 Apr 2017 14:45:17 -0700
In-Reply-To: 
Cc: Bob Hinden , IPv6 List 
To: Tim Chown 
References:  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 21:48:49 -0000

--Apple-Mail=_3E3F40DD-6CDC-48DA-A258-6B5FDA298A95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Tim,

> On Apr 27, 2017, at 2:02 AM, Tim Chown  wrote:
>=20
> Hi Bob,
>=20
>> On 26 Apr 2017, at 19:38, Bob Hinden  wrote:
>>=20
>> Hi,
>>=20
>> Based on the comments and IESG discusses, I clarified the text in =
Section 4.8 about defining new IPv6 extension headers.  The proposed =
text is much closer what was in RFC6564 that updated RFC2460.
>>=20
>> CURRENT and NEW text is below.
>>=20
>> Comments?
>>=20
>> Bob
>>=20
>>  CURRENT
>>=20
>>  Defining new IPv6 extension headers is not recommended.  There has =
to
>>  be a very clear justification why any new extension header is needed
>>  before it is standardized.  Instead of defining new Extension
>>  Headers, it is recommended that the Destination Options header is
>>  used to carry optional information that must be examined only by a
>>  packet's destination node(s), because they provide better handling
>>  and backward compatibility.
>>=20
>>  NEW
>>=20
>>  Defining new IPv6 extension headers is not recommended, unless no
>>  existing IPv6 extension header can be used by specifying a new =
option
>>  for that existing IPv6 extension header.  Any proposal to create or
>>  specify a new IPv6 extension header must include a detailed =
technical
>>  explanation of why no existing IPv6 extension header can be used in
>>  the document proposing the new IPv6 extension header.
>=20
>=20
> That text is very close to section 3 of RFC6564, which is fine.

Good, thanks.

>=20
>>  Instead of defining new Extension Headers, it is recommended that =
the
>>  Destination Options header is used to carry optional information =
that
>>  must be examined only by a packet's destination node(s), because =
they
>>  provide better handling and backward compatibility.
>=20
> That=E2=80=99s fine for Destination options.
>=20
> But I think the ordering of the text in 4.8 would be a little odd =
though, so I=E2=80=99d suggest taking what you propose (NEW text) and =
reordering section 4.8 as follows (NEW NEW) so that the text talks at a =
high level, then about HbH, then about destination options, adding =E2=80=9C=
In particular,=E2=80=9D and =E2=80=9CFurther,=E2=80=9D to help the flow:

See below.

>=20
> =E2=80=94
>=20
> NEW:
>=20
> 4.8.  Defining New Extension Headers and Options
>=20
>   New extension headers that require hop-by-hop behavior must not be
>   defined because, as specified in Section 4 of this document, the =
only
>   Extension Header that has hop-by-hop behavior is the Hop-by-Hop
>   Options header.
>=20
>   New hop-by-hop options are not recommended because nodes may be
>   configured to ignore the Hop-by-Hop Option header, drop packets
>   containing a hop-by-hop header, or assign packets containing a hop-
>   by-hop header to a slow processing path.  Designers considering
>   defining new hop-by-hop options need to be aware of this likely
>   behaviour.  There has to be a very clear justification why any new
>   hop-by-hop option is needed before it is standardized.
>=20
>  Defining new IPv6 extension headers is not recommended, unless no
>  existing IPv6 extension header can be used by specifying a new option
>  for that existing IPv6 extension header.  Any proposal to create or
>  specify a new IPv6 extension header must include a detailed technical
>  explanation of why no existing IPv6 extension header can be used in
>  the document proposing the new IPv6 extension header.
>=20
>  Instead of defining new Extension Headers, it is recommended that the
>  Destination Options header is used to carry optional information that
>  must be examined only by a packet's destination node(s), because they
>  provide better handling and backward compatibility.
>=20
>   If new Extension Headers are defined, they need to =E2=80=A6.
>=20
> =E2=80=94
>=20
> NEW NEW:
>=20
> 4.8.  Defining New Extension Headers and Options
>=20
>  Defining new IPv6 extension headers is not recommended, unless no
>  existing IPv6 extension header can be used by specifying a new option
>  for that existing IPv6 extension header.  Any proposal to create or
>  specify a new IPv6 extension header must include a detailed technical
>  explanation of why no existing IPv6 extension header can be used in
>  the document proposing the new IPv6 extension header.
>=20
>   In particular, new extension headers that require hop-by-hop =
behavior must not be
>   defined because, as specified in Section 4 of this document, the =
only
>   Extension Header that has hop-by-hop behavior is the Hop-by-Hop
>   Options header.
>=20
>   Further, new hop-by-hop options are not recommended because nodes =
may be
>   configured to ignore the Hop-by-Hop Option header, drop packets
>   containing a hop-by-hop header, or assign packets containing a hop-
>   by-hop header to a slow processing path.  Designers considering
>   defining new hop-by-hop options need to be aware of this likely
>   behaviour.  There has to be a very clear justification why any new
>   hop-by-hop option is needed before it is standardized.
>=20
>  Where a new requirement arises to carry optional information that
>  must be examined only by a packet's destination node(s), instead
>  of defining new Extension Headers, it is recommended that the
>  existing Destination Options header is used to carry such =
information.
> (* Add the rationale text back in here if that=E2=80=99s deemed =
useful; it seems unnecessary? *)
>=20
>   If new Extension Headers are defined, they need to =E2=80=A6.
>=20

I agree that it makes sense to move the general statement first in this =
section.  How about the following?

Bob

  NEW NEW

   Defining new IPv6 extension headers is not recommended, unless no
   existing IPv6 extension header can be used by specifying a new option
   for that existing IPv6 extension header.  Any proposal to create or
   specify a new IPv6 extension header must include a detailed technical
   explanation of why no existing IPv6 extension header can be used in
   the document proposing the new IPv6 extension header.

   Note: New extension headers that require hop-by-hop behavior must not
   be defined because, as specified in Section 4 of this document, the
   only Extension Header that has hop-by-hop behavior is the Hop-by-Hop
   Options header.

   New hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path.  Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.  There has to be a very clear justification why any new
   hop-by-hop option is needed before it is standardized.

   Instead of defining new Extension Headers, it is recommended that the
   Destination Options header is used to carry optional information that
   must be processed only by a packet's destination node(s), because =
they
   provide better handling and backward compatibility.

   END NEW NEW




> =E2=80=94
>=20
> Best wishes,
> Tim
>=20
>>=20
>>  END NEW
>>=20
>>  If new Extension Headers are defined, they need to use the following
>>  format:
>>=20
>>  . . . . . .
>>=20
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20


--Apple-Mail=_3E3F40DD-6CDC-48DA-A258-6B5FDA298A95
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-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJZAmZuAAoJEK7rdBF357uocAUIAK+tOt/UrBkaQKvLckoGDtUM
t6aq5ESeiFNa+OCAg+ufXfa2SKCaPI/eGqyidNyhkD9fUy5xhtDMcT+NjEVV/iIY
hLsm/OqkTaubRbLXuLSaLnJOgXDAmX8Rm5IbnCSBPU0ZaoSaAbc91Ez78QwB3TTf
aLfd1WQEk/Sug6mr5oqnLYIgxwRmJhvV9kO6MSzMcqcLOIaAYuFSPjc+KkK4XcpB
Kjd0EahcNhmxNP86YALyXnmNoWIW9yb7hnOmbglREMMfIj17byKajJnwOFhXyXuw
R0/mnNoROzrXWeA1ya53G+/eSDX/jek5iBeSjT4agRZhhHslhDO3GLDf4+5DzRw=
=UsX7
-----END PGP SIGNATURE-----

--Apple-Mail=_3E3F40DD-6CDC-48DA-A258-6B5FDA298A95--


From nobody Thu Apr 27 18:08:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02CB129BCC for ; Thu, 27 Apr 2017 18:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 zCtAefTJ1Hma for ; Thu, 27 Apr 2017 18:08:49 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 3B2AC129BDB for ; Thu, 27 Apr 2017 18:05:57 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id v1so6501250pgv.1 for ; Thu, 27 Apr 2017 18:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IARMrQ/nqhzIO+VAqoSrj073eH4JZptu4EMT9qDxsvc=; b=Uz4PwlFOA5UV7jQx5NeA6B2fPpRNzhF4+7o0APwc7/pnLX7bf97Am4kOHCEWuU9uPY em+tpC8QVaDlycusyHaoA6MwTa3ExUME/ozjL3oHgiCB+NAZ1VprzF/bgTv6D2QYWfs8 lQxBHamqvwqS13MPzfMRAbBCUxgfPn7ERLuP2ejFZRJ0X3vKAIzfsSWZXjKO3ICbFFT0 fELfKxCKXWDadsBfHJSOQ40fQkDG2f8euoRUtHSlZtwFbdb7bN9QENtGwLTYaDp1Heck Q0x44zenlrUl9+o4rzgm/Azm5k0Qw786lS0DuMxN1l9ENcv/FDkq40bfhwYOB41VZoq5 rP7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IARMrQ/nqhzIO+VAqoSrj073eH4JZptu4EMT9qDxsvc=; b=aeoJ9Eeok80+bDDH5t4xwCcNC3aW7w2ZB13ucpq3fMYN1v+2BWs4L+EgwiWctBBLYb rvPwQ7D5EYLSXk84KsyEsw8WknqEqfPfBKjG3sEXF/eBPEefDMhyrjNH9D9LVN20PPzX O/I1AAhzvh+cLh0jr3h9GJ7/n5JfJ9MHQAS+ogsA3t+C8T4kLWCEXnpE647IDnV3Umnf QTn5xQADx+/Wsoj8MqD8w8UCBjwOhNRqi8LVIV3ovWQ4Vnl+h1tQrx++vYodvdS1ObM9 J9ap6YNlX8UIJO5RQsbH0sSJh/uiK+zDvLvb4UMnqUuIuDUxE6VUQnnP3pDH4RYmgLx6 vUbw==
X-Gm-Message-State: AN3rC/5Dof61LdL0rVys5zBm7SVZCh597RIEJupwOpw8K2dwvyZ6O8+D P0b6bj6dWgTtt1JO
X-Received: by 10.84.128.47 with SMTP id 44mr11207480pla.35.1493341556661; Thu, 27 Apr 2017 18:05:56 -0700 (PDT)
Received: from ?IPv6:2406:e007:768a:1:28cc:dc4c:9703:6781? ([2406:e007:768a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i15sm7808616pfj.51.2017.04.27.18.05.55 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 18:05:56 -0700 (PDT)
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
To: ipv6@ietf.org
References:  <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org> <7144.1493328909@obiwan.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com>
Date: Fri, 28 Apr 2017 13:06:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <7144.1493328909@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 01:08:52 -0000

Hi Michael,
On 28/04/2017 09:35, Michael Richardson wrote:
...
> I think that, given the pushback we have on rfc2460bis, that I would like to
> make some progress on 6434bis before we attempt to finalize 2460bis.

I disagree quite strongly. On the contrary, we should IMHO get 2460bis
frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be built on
shifting sands and we'll never get out of the loop.

(I really wish we had a better mechanism than a rarely revised RFC for formally
defining the latest IPv6 node requirements, but that's not really an option.
IMHO, Node Requirements should up for revision every time a relevant RFC is
published, not once in a while when somebody thinks of it.)

   Brian


From nobody Fri Apr 28 03:04:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E691270B4 for ; Fri, 28 Apr 2017 03:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 nG1aUcnoub7P for ; Fri, 28 Apr 2017 03:04:34 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A55112E957 for ; Fri, 28 Apr 2017 03:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493373691; bh=n2JDMdY5C75KOtIQ1MNXUedexOlHBki9OEzHvL9i8Dk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=g+NJgl9tHYxve4UH3oushQWIqTY6+dvTXlc0DLbEPJEPZvac20eG/B0ZYfAyA6Y1lhiaCgzflUMgDJXolrzSwDQ98tem869SlwHirLWWk0oYV+cyxRFQBuFl9WkaSKDyfAnhkA0KV8bwkFOWaE4wkVcXlwA6Ih/MfAQL3PCMf5g=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0183.outbound.protection.outlook.com [213.199.180.183]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-55-3FWjH-b9PoKzwvpfMJkbvw-1; Fri, 28 Apr 2017 11:01:22 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Fri, 28 Apr 2017 10:01:21 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.001; Fri, 28 Apr 2017 10:01:21 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: "ipv6@ietf.org" 
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
Thread-Topic: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
Thread-Index: AQHSv4WvrV5VAUNDyUqIr7iNQR44QKHZvT6AgAA66oCAAJWQgA==
Date: Fri, 28 Apr 2017 10:01:21 +0000
Message-ID: <51327F3A-BFF2-42A9-A709-256A84585FB9@jisc.ac.uk>
References:  <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org> <7144.1493328909@obiwan.sandelman.ca> <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com>
In-Reply-To: <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-originating-ip: [193.62.83.229]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:NMYyDbpchWv9n9Um9WpPLTFORtkv6bdz98GmU5sQIBlBLHjuejtuKJ3ZY/HkqT1fiT2IQbOY1nrSRJAJqhSYw6FTiG27oG7iqoL1MOa0wTx7s5+yoxtYiks3obEOAN79mUZJcEOE5sCVypjgx35AyFIXsdPBCQa+VwkaisNOEQlJxdbWyPT4JjJ3yTkAqM8pN7jnwqyCi7SrQe13hqU/tZ2mDDjZgZrOuIpCu609KpjTxqaQjHOkpooZsn/LqIT4ZkvUJdWYL8aE+QSM78qe1620CG0Xmf+jcN30Y562Xn3ElaNrBUDpAiJEI+c/eYSagB/thZpCGNMW6oFTkRwK2w==; 20:9ggyy9mAF7L4sAqnqXy8VIJktgoWIYTr/nj3hjzg3wBkWh8cOch9k/W9kz198NJf5lrDsV2Gllzenb/myZh7nrPJa6bMaafFCE0Srm1wBC4eII3n08mJKY/wYQMXuLhxztYXw+V2ygsLs/JdEjYndpeq9n/bITXq24VLbnMvcdA=
x-ms-office365-filtering-correlation-id: 927862a5-745d-472c-cc06-08d48e1d8580
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1140; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; 
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39840400002)(51444003)(24454002)(230783001)(33656002)(93886004)(3660700001)(229853002)(3280700002)(189998001)(86362001)(2950100002)(42882006)(6916009)(66066001)(4326008)(2906002)(57306001)(3846002)(102836003)(38730400002)(74482002)(36756003)(25786009)(39060400002)(6116002)(6436002)(7736002)(305945005)(6246003)(110136004)(6512007)(81166006)(50226002)(2900100001)(6306002)(8676002)(6486002)(5660300001)(50986999)(53936002)(83716003)(99286003)(6506006)(76176999)(5250100002)(82746002)(53546009)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <8F4642FAAB7F1C4AB00A009C68230217@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 10:01:21.0307 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140
X-MC-Unique: 3FWjH-b9PoKzwvpfMJkbvw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 10:04:37 -0000

PiBPbiAyOCBBcHIgMjAxNywgYXQgMDI6MDYsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh
cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgTWljaGFlbCwNCj4gT24gMjgvMDQv
MjAxNyAwOTozNSwgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPiAuLi4NCj4+IEkgdGhpbmsg
dGhhdCwgZ2l2ZW4gdGhlIHB1c2hiYWNrIHdlIGhhdmUgb24gcmZjMjQ2MGJpcywgdGhhdCBJIHdv
dWxkIGxpa2UgdG8NCj4+IG1ha2Ugc29tZSBwcm9ncmVzcyBvbiA2NDM0YmlzIGJlZm9yZSB3ZSBh
dHRlbXB0IHRvIGZpbmFsaXplIDI0NjBiaXMuDQo+IA0KPiBJIGRpc2FncmVlIHF1aXRlIHN0cm9u
Z2x5LiBPbiB0aGUgY29udHJhcnksIHdlIHNob3VsZCBJTUhPIGdldCAyNDYwYmlzDQo+IGZyb3pl
biBhbmQgaW4gdGhlIFJGQyBFZGl0b3IgcXVldWUgQVNBUC4gT3RoZXJ3aXNlLCA2NDM0YmlzIHdp
bGwgYmUgYnVpbHQgb24NCj4gc2hpZnRpbmcgc2FuZHMgYW5kIHdlJ2xsIG5ldmVyIGdldCBvdXQg
b2YgdGhlIGxvb3AuDQoNCkkgYWdyZWUgd2l0aCBCcmlhbi4gIEFuZCA2NDM0YmlzIHdpbGwgb25s
eSByZWZsZWN0IHdoYXTigJlzIGluIDI0NjBiaXM7IHdlIG5lZWQgdG8gZ2V0IDI0NjBiaXMgZnJv
emVuIHNvIHdlIGtub3cgd2hhdCB0byBwdXQgaW4gNjQzNGJpcy4NCg0KPiAoSSByZWFsbHkgd2lz
aCB3ZSBoYWQgYSBiZXR0ZXIgbWVjaGFuaXNtIHRoYW4gYSByYXJlbHkgcmV2aXNlZCBSRkMgZm9y
IGZvcm1hbGx5DQo+IGRlZmluaW5nIHRoZSBsYXRlc3QgSVB2NiBub2RlIHJlcXVpcmVtZW50cywg
YnV0IHRoYXQncyBub3QgcmVhbGx5IGFuIG9wdGlvbi4NCj4gSU1ITywgTm9kZSBSZXF1aXJlbWVu
dHMgc2hvdWxkIHVwIGZvciByZXZpc2lvbiBldmVyeSB0aW1lIGEgcmVsZXZhbnQgUkZDIGlzDQo+
IHB1Ymxpc2hlZCwgbm90IG9uY2UgaW4gYSB3aGlsZSB3aGVuIHNvbWVib2R5IHRoaW5rcyBvZiBp
dC4pDQoNCkFuIGludGVyZXN0aW5nIHBvaW50LiBZb3UgY291bGQgZm9yIGV4YW1wbGUga2VlcCBh
IFZlcnNpb25OLWJpcyBkcmFmdCB1cGRhdGVkIGFzIHNvb24gYXMgVmVyc2lvbk4gaXMgcHVibGlz
aGVkLCBhbmQgcHVibGlzaCBWZXJzaW9uTisxIGFzIGFuIFJGQyBhdCBzb21lIGFncmVlZCBpbnRl
cnZhbC4gT24gb3VyIGN1cnJlbnQgdHJhY2sgcmVjb3JkLCB0aGF0IGludGVydmFsIGlzIGV2ZXJ5
IDYgeWVhcnMuIFN1Y2ggYW4gYXBwcm9hY2ggd291bGQgbWVhbiB0aGUgbW9zdCB1cC10by1kYXRl
IGd1aWRhbmNlIGlzIG5vdCBpbiB0aGUgbW9zdCByZWNlbnRseSBwdWJsaXNoZWQgUkZDLCBidXQg
aW4gdGhlIOKAnGxpdmluZ+KAnSBJLUQuIA0KDQpUaW0NCg0KPiANCj4gICBCcmlhbg0KPiANCj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlw
djZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCg0K


From nobody Fri Apr 28 07:52:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3281292F4 for ; Fri, 28 Apr 2017 07:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 REANxQwOVIkM for ; Fri, 28 Apr 2017 07:51:59 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1F312951E for ; Fri, 28 Apr 2017 07:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6553; q=dns/txt; s=iport; t=1493390866; x=1494600466; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dYTm0x1/jTTxnjf60QwLQ3r8V52qI2acxRXx3/ZPcwU=; b=BgGyqPS9qepbl+x5O8YXfXV5SaELt3EYPmu3np90D/MwxlQbEr9WUMGT d3dQfFo7n8H0vW3SxOrCTkAEuPxEvhXJau7G3z1wS8vDb9dPXZ7OoJ3V5 vy2/3M6NNwjA0n/kjQJQL8DRSmleK+qv/q6UazQ+N3ZYFZvpunYx37Dgg Q=;
X-IronPort-AV: E=Sophos;i="5.37,388,1488844800"; d="scan'208";a="238956749"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2017 14:47:45 +0000
Received: from [10.24.35.235] ([10.24.35.235]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3SElgTs016423; Fri, 28 Apr 2017 14:47:43 GMT
Message-ID: <5903560D.50803@cisco.com>
Date: Fri, 28 Apr 2017 07:47:41 -0700
From: "Ahmed Bashandy (bashandy)" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Brian E Carpenter , "Stefano Previdi (sprevidi)" , Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 14:52:01 -0000

If I were to implement this RFC, what is the meaning of "are not"? where 
is unambiguously defined?

Ahmed

On 4/27/2017 1:54 PM, Brian E Carpenter wrote:
> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
>> Agreed
>>
>> rfc2119 has clear definition of the normative language that alleviates
>> any ambiguity. So it is always good to use them
> iirc the WG already agreed to the editor's choice to follow RFC2460 by using
> plain English rather than RFC2119. And "are not" does not mean the same thing
> as "should not", with or without upper case letters. Personally, I agree with
> "are not" and disagree with "should not", which changes the meaning.
>
>     Brian
>
>> Ahmed
>>
>>
>> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
>>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden  wrote:
>>>>
>>>> Hi,
>>>>
>>>> After reading through the discussion about this text in Section 4, I have some new text to propose.  I think this is significantly improved and should resolve many of the issued raised.
>>>>
>>>> Changes include separate description of behaviors extension headers and the hop-by-hop option header, remove “examine” from the first paragraph.  I removed “examine” because I am convinced it’s not sustainable to say a node can’t examine extension given how widespread this behavior is.  I also removed the reference to RFC7045 because examine is removed.  RFC7045 is referenced in the recently updated Security Considerations section.
>>>>
>>>> I removed the “including the source and destination nodes” text from the paragraph on the hop-by-hop options header because I don’t think we need to mention the source, and there is a whole paragraph describe what happens at the destination node.  I also added the text about from the first paragraph about reaching the destination to the hop-by-hop header paragraph.
>>>>
>>>> I also moved (without change) the “At the Destination node...” text from the first paragraph to a new third paragraph.  It applies to all extension headers.
>>>>
>>>> CURRENT and NEW text below.  Please review and comment.
>>>>
>>>> Bob
>>>>
>>>>
>>>>     CURRENT
>>>>
>>>>     With one exception, extension headers are not examined, processed,
>>>>     inserted, or deleted by any node along a packet's delivery path,
>>>>     until the packet reaches the node (or each of the set of nodes, in
>>>>     the case of multicast) identified in the Destination Address field of
>>>>     the IPv6 header.  Note: If an intermediate forwarding node examines
>>>>     an extension header for any reason, it must do so in accordance with
>>>>     the provisions of [RFC7045].  At the Destination node, normal
>>>>     demultiplexing on the Next Header field of the IPv6 header invokes
>>>>     the module to process the first extension header, or the upper-layer
>>>>     header if no extension header is present.  The contents and semantics
>>>>     of each extension header determine whether or not to proceed to the
>>>>     next header.  Therefore, extension headers must be processed strictly
>>>>     in the order they appear in the packet; a receiver must not, for
>>>>     example, scan through a packet looking for a particular kind of
>>>>     extension header and process that header prior to processing all
>>>>     preceding ones.
>>>>
>>>>     The exception referred to in the preceding paragraph is the Hop-by-
>>>>     Hop Options header, which carries information that may be examined
>>>>     and processed by every node along a packet's delivery path, including
>>>>     the source and destination nodes.  The Hop-by-Hop Options header,
>>>>     when present, must immediately follow the IPv6 header.  Its presence
>>>>     is indicated by the value zero in the Next Header field of the IPv6
>>>>     header.
>>>>
>>>>     NEW
>>>>
>>>>     Extension headers (except for the Hop-by-Hop Options header) are not
>>> my recommendation is to change “are not” with “SHOULD NOT”.
>>>
>>> This doesn’t change what the current text assumes while it uses a more formal language.
>>>
>>> s.
>>>
>>>
>>>>     processed, inserted, or deleted by any node along a packet's delivery
>>>>     path, until the packet reaches the node (or each of the set of nodes,
>>>>     in the case of multicast) identified in the Destination Address field
>>>>     of the IPv6 header.
>>>>
>>>>     The Hop-by-Hop Options header is not inserted or deleted, but may be
>>>>     examined and processed by every node along a packet's delivery path,
>>>>     until the packet reaches the node (or each of the set of nodes, in
>>>>     the case of multicast) identified in the Destination Address field of
>>>>     the IPv6 header.  The Hop-by-Hop Options header, when present, must
>>>>     immediately follow the IPv6 header.  Its presence is indicated by the
>>>>     value zero in the Next Header field of the IPv6 header.
>>>>
>>>>     At the Destination node, normal demultiplexing on the Next Header
>>>>     field of the IPv6 header invokes the module to process the first
>>>>     extension header, or the upper-layer header if no extension header is
>>>>     present.  The contents and semantics of each extension header
>>>>     determine whether or not to proceed to the next header.  Therefore,
>>>>     extension headers must be processed strictly in the order they appear
>>>>     in the packet; a receiver must not, for example, scan through a
>>>>     packet looking for a particular kind of extension header and process
>>>>     that header prior to processing all preceding ones.
>>>>
>>>>     END NEW
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>


From nobody Fri Apr 28 09:10:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE27A129C5E for ; Fri, 28 Apr 2017 09:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 YDGIiprR-VXq for ; Fri, 28 Apr 2017 09:10:44 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061B9129C66 for ; Fri, 28 Apr 2017 09:07:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1493395622; bh=0xfEL1wwzKRWI69Q+7jYFBWUD/4+seeeT3auP8T88Io=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:Content-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ac3OFvxLX+N1Ay2PbPtDHRdRtz12IEJmlaYTL+YjfyeCYYM8E0s9j0uaRVNDeCw6iynBcUL7SJGDizp9cD2FzNq3kaZDLmx+XvUlYt6CQe7RB4IUunQOodyv2E749Rm8VtNDu7EyIVvGjKVPBNSuy5coI1zTT26BSoFt0m4VlrY=
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0055.outbound.protection.outlook.com [213.199.154.55]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-117-PELLgzfnMKqJlDMtYV-m3A-1; Fri, 28 Apr 2017 17:06:59 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Fri, 28 Apr 2017 16:06:57 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::cc2e:e06e:e272:6d7a%15]) with mapi id 15.01.1075.001; Fri, 28 Apr 2017 16:06:57 +0000
From: Tim Chown 
To: Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Thread-Topic: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Thread-Index: AQHSvrxLCZVhi/Nuo0S9GuOuCgqjBKHY7I2AgADVGICAATPMAA==
Date: Fri, 28 Apr 2017 16:06:57 +0000
Message-ID: 
References:   <75ACCE55-CA38-498C-B9C4-B1EA083CFB76@gmail.com>
In-Reply-To: <75ACCE55-CA38-498C-B9C4-B1EA083CFB76@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3273)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:tLsG4rlL65E98dE+Kq9klK+ek346kmGomm5uEXa4kyF2km3Ql2AvIQ0GUs9+XPnu+AEIsROmS5s5lEe5rSkWTvgd0WZhsV9wbbMc2Bx3GOjvQKF4HNGur83HF/p3g0onV9cWp6KtmkWr4Vg+hC+tCpO2g/FC+ZBUodgUlGJbkvTt6ighBpnQ8WV0NLWdElavpgbq68epYJRj6DxPaXV6FNZz3bENTvqAIKeTclhHkusO714t9T8H4AChm7KyCOXUDoPUZvt0ZaY3DF250LkAM3ELcz99npzNC36yUp6az1QaW3dVNXfUjUiunrZS7AOiLAbb6DTlwyy5d+408x3wlQ==; 20:E5ESHODNwn18GiWtEINSt52UxCOqQR+vV2BVJnL/MsrrA0E2kqqcSj9cszZxJNqQEMs0PtTnhcj23cyAI3/VS6iIJy4wttdks0hP0yf8dOhTx6vMjDEdGZll8Je0LqlHNFFov6uJd4UXLNjWIwjpyyH7QeeIOVVWHB3qlhcsfXU=
x-ms-office365-filtering-correlation-id: 0aba43ee-1de5-4993-f11a-08d48e509880
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB1137; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(274715658323672);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; 
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39410400002)(39400400002)(39850400002)(377454003)(24454002)(229853002)(2950100002)(39060400002)(6916009)(6512007)(42882006)(99286003)(53936002)(66066001)(6306002)(6486002)(6506006)(2906002)(5660300001)(76176999)(6436002)(25786009)(36756003)(83716003)(86362001)(561944003)(38730400002)(57306001)(4326008)(110136004)(6246003)(50986999)(305945005)(7736002)(82746002)(81166006)(53546009)(2900100001)(3660700001)(74482002)(8936002)(102836003)(5250100002)(3846002)(6116002)(3280700002)(50226002)(8676002)(33656002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <2489D8F91699C042B5B945155264689E@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 16:06:57.1322 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: PELLgzfnMKqJlDMtYV-m3A-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:10:47 -0000

SGkgQm9iLA0KDQpQZXJmZWN0bHkgaGFwcHkgd2l0aCB3aGF0IHlvdSBwcm9wb3NlIGJlbG93Lg0K
DQpCZXN0IHdpc2hlcywNCg0KVGltIA0KDQo+IE9uIDI3IEFwciAyMDE3LCBhdCAyMjo0NSwgQm9i
IEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gVGltLA0KPiANCj4+
IE9uIEFwciAyNywgMjAxNywgYXQgMjowMiBBTSwgVGltIENob3duIDxUaW0uQ2hvd25AamlzYy5h
Yy51az4gd3JvdGU6DQo+PiANCj4+IEhpIEJvYiwNCj4+IA0KPj4+IE9uIDI2IEFwciAyMDE3LCBh
dCAxOTozOCwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0K
Pj4+IEhpLA0KPj4+IA0KPj4+IEJhc2VkIG9uIHRoZSBjb21tZW50cyBhbmQgSUVTRyBkaXNjdXNz
ZXMsIEkgY2xhcmlmaWVkIHRoZSB0ZXh0IGluIFNlY3Rpb24gNC44IGFib3V0IGRlZmluaW5nIG5l
dyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzLiAgVGhlIHByb3Bvc2VkIHRleHQgaXMgbXVjaCBjbG9z
ZXIgd2hhdCB3YXMgaW4gUkZDNjU2NCB0aGF0IHVwZGF0ZWQgUkZDMjQ2MC4NCj4+PiANCj4+PiBD
VVJSRU5UIGFuZCBORVcgdGV4dCBpcyBiZWxvdy4NCj4+PiANCj4+PiBDb21tZW50cz8NCj4+PiAN
Cj4+PiBCb2INCj4+PiANCj4+PiBDVVJSRU5UDQo+Pj4gDQo+Pj4gRGVmaW5pbmcgbmV3IElQdjYg
ZXh0ZW5zaW9uIGhlYWRlcnMgaXMgbm90IHJlY29tbWVuZGVkLiAgVGhlcmUgaGFzIHRvDQo+Pj4g
YmUgYSB2ZXJ5IGNsZWFyIGp1c3RpZmljYXRpb24gd2h5IGFueSBuZXcgZXh0ZW5zaW9uIGhlYWRl
ciBpcyBuZWVkZWQNCj4+PiBiZWZvcmUgaXQgaXMgc3RhbmRhcmRpemVkLiAgSW5zdGVhZCBvZiBk
ZWZpbmluZyBuZXcgRXh0ZW5zaW9uDQo+Pj4gSGVhZGVycywgaXQgaXMgcmVjb21tZW5kZWQgdGhh
dCB0aGUgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXIgaXMNCj4+PiB1c2VkIHRvIGNhcnJ5IG9w
dGlvbmFsIGluZm9ybWF0aW9uIHRoYXQgbXVzdCBiZSBleGFtaW5lZCBvbmx5IGJ5IGENCj4+PiBw
YWNrZXQncyBkZXN0aW5hdGlvbiBub2RlKHMpLCBiZWNhdXNlIHRoZXkgcHJvdmlkZSBiZXR0ZXIg
aGFuZGxpbmcNCj4+PiBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCj4+PiANCj4+PiBORVcN
Cj4+PiANCj4+PiBEZWZpbmluZyBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVycyBpcyBub3QgcmVj
b21tZW5kZWQsIHVubGVzcyBubw0KPj4+IGV4aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlciBj
YW4gYmUgdXNlZCBieSBzcGVjaWZ5aW5nIGEgbmV3IG9wdGlvbg0KPj4+IGZvciB0aGF0IGV4aXN0
aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlci4gIEFueSBwcm9wb3NhbCB0byBjcmVhdGUgb3INCj4+
PiBzcGVjaWZ5IGEgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBtdXN0IGluY2x1ZGUgYSBkZXRh
aWxlZCB0ZWNobmljYWwNCj4+PiBleHBsYW5hdGlvbiBvZiB3aHkgbm8gZXhpc3RpbmcgSVB2NiBl
eHRlbnNpb24gaGVhZGVyIGNhbiBiZSB1c2VkIGluDQo+Pj4gdGhlIGRvY3VtZW50IHByb3Bvc2lu
ZyB0aGUgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlci4NCj4+IA0KPj4gDQo+PiBUaGF0IHRleHQg
aXMgdmVyeSBjbG9zZSB0byBzZWN0aW9uIDMgb2YgUkZDNjU2NCwgd2hpY2ggaXMgZmluZS4NCj4g
DQo+IEdvb2QsIHRoYW5rcy4NCj4gDQo+PiANCj4+PiBJbnN0ZWFkIG9mIGRlZmluaW5nIG5ldyBF
eHRlbnNpb24gSGVhZGVycywgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUNCj4+PiBEZXN0aW5h
dGlvbiBPcHRpb25zIGhlYWRlciBpcyB1c2VkIHRvIGNhcnJ5IG9wdGlvbmFsIGluZm9ybWF0aW9u
IHRoYXQNCj4+PiBtdXN0IGJlIGV4YW1pbmVkIG9ubHkgYnkgYSBwYWNrZXQncyBkZXN0aW5hdGlv
biBub2RlKHMpLCBiZWNhdXNlIHRoZXkNCj4+PiBwcm92aWRlIGJldHRlciBoYW5kbGluZyBhbmQg
YmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCj4+IA0KPj4gVGhhdOKAmXMgZmluZSBmb3IgRGVzdGlu
YXRpb24gb3B0aW9ucy4NCj4+IA0KPj4gQnV0IEkgdGhpbmsgdGhlIG9yZGVyaW5nIG9mIHRoZSB0
ZXh0IGluIDQuOCB3b3VsZCBiZSBhIGxpdHRsZSBvZGQgdGhvdWdoLCBzbyBJ4oCZZCBzdWdnZXN0
IHRha2luZyB3aGF0IHlvdSBwcm9wb3NlIChORVcgdGV4dCkgYW5kIHJlb3JkZXJpbmcgc2VjdGlv
biA0LjggYXMgZm9sbG93cyAoTkVXIE5FVykgc28gdGhhdCB0aGUgdGV4dCB0YWxrcyBhdCBhIGhp
Z2ggbGV2ZWwsIHRoZW4gYWJvdXQgSGJILCB0aGVuIGFib3V0IGRlc3RpbmF0aW9uIG9wdGlvbnMs
IGFkZGluZyDigJxJbiBwYXJ0aWN1bGFyLOKAnSBhbmQg4oCcRnVydGhlcizigJ0gdG8gaGVscCB0
aGUgZmxvdzoNCj4gDQo+IFNlZSBiZWxvdy4NCj4gDQo+PiANCj4+IOKAlA0KPj4gDQo+PiBORVc6
DQo+PiANCj4+IDQuOC4gIERlZmluaW5nIE5ldyBFeHRlbnNpb24gSGVhZGVycyBhbmQgT3B0aW9u
cw0KPj4gDQo+PiAgTmV3IGV4dGVuc2lvbiBoZWFkZXJzIHRoYXQgcmVxdWlyZSBob3AtYnktaG9w
IGJlaGF2aW9yIG11c3Qgbm90IGJlDQo+PiAgZGVmaW5lZCBiZWNhdXNlLCBhcyBzcGVjaWZpZWQg
aW4gU2VjdGlvbiA0IG9mIHRoaXMgZG9jdW1lbnQsIHRoZSBvbmx5DQo+PiAgRXh0ZW5zaW9uIEhl
YWRlciB0aGF0IGhhcyBob3AtYnktaG9wIGJlaGF2aW9yIGlzIHRoZSBIb3AtYnktSG9wDQo+PiAg
T3B0aW9ucyBoZWFkZXIuDQo+PiANCj4+ICBOZXcgaG9wLWJ5LWhvcCBvcHRpb25zIGFyZSBub3Qg
cmVjb21tZW5kZWQgYmVjYXVzZSBub2RlcyBtYXkgYmUNCj4+ICBjb25maWd1cmVkIHRvIGlnbm9y
ZSB0aGUgSG9wLWJ5LUhvcCBPcHRpb24gaGVhZGVyLCBkcm9wIHBhY2tldHMNCj4+ICBjb250YWlu
aW5nIGEgaG9wLWJ5LWhvcCBoZWFkZXIsIG9yIGFzc2lnbiBwYWNrZXRzIGNvbnRhaW5pbmcgYSBo
b3AtDQo+PiAgYnktaG9wIGhlYWRlciB0byBhIHNsb3cgcHJvY2Vzc2luZyBwYXRoLiAgRGVzaWdu
ZXJzIGNvbnNpZGVyaW5nDQo+PiAgZGVmaW5pbmcgbmV3IGhvcC1ieS1ob3Agb3B0aW9ucyBuZWVk
IHRvIGJlIGF3YXJlIG9mIHRoaXMgbGlrZWx5DQo+PiAgYmVoYXZpb3VyLiAgVGhlcmUgaGFzIHRv
IGJlIGEgdmVyeSBjbGVhciBqdXN0aWZpY2F0aW9uIHdoeSBhbnkgbmV3DQo+PiAgaG9wLWJ5LWhv
cCBvcHRpb24gaXMgbmVlZGVkIGJlZm9yZSBpdCBpcyBzdGFuZGFyZGl6ZWQuDQo+PiANCj4+IERl
ZmluaW5nIG5ldyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGlzIG5vdCByZWNvbW1lbmRlZCwgdW5s
ZXNzIG5vDQo+PiBleGlzdGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgY2FuIGJlIHVzZWQgYnkg
c3BlY2lmeWluZyBhIG5ldyBvcHRpb24NCj4+IGZvciB0aGF0IGV4aXN0aW5nIElQdjYgZXh0ZW5z
aW9uIGhlYWRlci4gIEFueSBwcm9wb3NhbCB0byBjcmVhdGUgb3INCj4+IHNwZWNpZnkgYSBuZXcg
SVB2NiBleHRlbnNpb24gaGVhZGVyIG11c3QgaW5jbHVkZSBhIGRldGFpbGVkIHRlY2huaWNhbA0K
Pj4gZXhwbGFuYXRpb24gb2Ygd2h5IG5vIGV4aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlciBj
YW4gYmUgdXNlZCBpbg0KPj4gdGhlIGRvY3VtZW50IHByb3Bvc2luZyB0aGUgbmV3IElQdjYgZXh0
ZW5zaW9uIGhlYWRlci4NCj4+IA0KPj4gSW5zdGVhZCBvZiBkZWZpbmluZyBuZXcgRXh0ZW5zaW9u
IEhlYWRlcnMsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlDQo+PiBEZXN0aW5hdGlvbiBPcHRp
b25zIGhlYWRlciBpcyB1c2VkIHRvIGNhcnJ5IG9wdGlvbmFsIGluZm9ybWF0aW9uIHRoYXQNCj4+
IG11c3QgYmUgZXhhbWluZWQgb25seSBieSBhIHBhY2tldCdzIGRlc3RpbmF0aW9uIG5vZGUocyks
IGJlY2F1c2UgdGhleQ0KPj4gcHJvdmlkZSBiZXR0ZXIgaGFuZGxpbmcgYW5kIGJhY2t3YXJkIGNv
bXBhdGliaWxpdHkuDQo+PiANCj4+ICBJZiBuZXcgRXh0ZW5zaW9uIEhlYWRlcnMgYXJlIGRlZmlu
ZWQsIHRoZXkgbmVlZCB0byDigKYuDQo+PiANCj4+IOKAlA0KPj4gDQo+PiBORVcgTkVXOg0KPj4g
DQo+PiA0LjguICBEZWZpbmluZyBOZXcgRXh0ZW5zaW9uIEhlYWRlcnMgYW5kIE9wdGlvbnMNCj4+
IA0KPj4gRGVmaW5pbmcgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgaXMgbm90IHJlY29tbWVu
ZGVkLCB1bmxlc3Mgbm8NCj4+IGV4aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlciBjYW4gYmUg
dXNlZCBieSBzcGVjaWZ5aW5nIGEgbmV3IG9wdGlvbg0KPj4gZm9yIHRoYXQgZXhpc3RpbmcgSVB2
NiBleHRlbnNpb24gaGVhZGVyLiAgQW55IHByb3Bvc2FsIHRvIGNyZWF0ZSBvcg0KPj4gc3BlY2lm
eSBhIG5ldyBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgbXVzdCBpbmNsdWRlIGEgZGV0YWlsZWQgdGVj
aG5pY2FsDQo+PiBleHBsYW5hdGlvbiBvZiB3aHkgbm8gZXhpc3RpbmcgSVB2NiBleHRlbnNpb24g
aGVhZGVyIGNhbiBiZSB1c2VkIGluDQo+PiB0aGUgZG9jdW1lbnQgcHJvcG9zaW5nIHRoZSBuZXcg
SVB2NiBleHRlbnNpb24gaGVhZGVyLg0KPj4gDQo+PiAgSW4gcGFydGljdWxhciwgbmV3IGV4dGVu
c2lvbiBoZWFkZXJzIHRoYXQgcmVxdWlyZSBob3AtYnktaG9wIGJlaGF2aW9yIG11c3Qgbm90IGJl
DQo+PiAgZGVmaW5lZCBiZWNhdXNlLCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA0IG9mIHRoaXMg
ZG9jdW1lbnQsIHRoZSBvbmx5DQo+PiAgRXh0ZW5zaW9uIEhlYWRlciB0aGF0IGhhcyBob3AtYnkt
aG9wIGJlaGF2aW9yIGlzIHRoZSBIb3AtYnktSG9wDQo+PiAgT3B0aW9ucyBoZWFkZXIuDQo+PiAN
Cj4+ICBGdXJ0aGVyLCBuZXcgaG9wLWJ5LWhvcCBvcHRpb25zIGFyZSBub3QgcmVjb21tZW5kZWQg
YmVjYXVzZSBub2RlcyBtYXkgYmUNCj4+ICBjb25maWd1cmVkIHRvIGlnbm9yZSB0aGUgSG9wLWJ5
LUhvcCBPcHRpb24gaGVhZGVyLCBkcm9wIHBhY2tldHMNCj4+ICBjb250YWluaW5nIGEgaG9wLWJ5
LWhvcCBoZWFkZXIsIG9yIGFzc2lnbiBwYWNrZXRzIGNvbnRhaW5pbmcgYSBob3AtDQo+PiAgYnkt
aG9wIGhlYWRlciB0byBhIHNsb3cgcHJvY2Vzc2luZyBwYXRoLiAgRGVzaWduZXJzIGNvbnNpZGVy
aW5nDQo+PiAgZGVmaW5pbmcgbmV3IGhvcC1ieS1ob3Agb3B0aW9ucyBuZWVkIHRvIGJlIGF3YXJl
IG9mIHRoaXMgbGlrZWx5DQo+PiAgYmVoYXZpb3VyLiAgVGhlcmUgaGFzIHRvIGJlIGEgdmVyeSBj
bGVhciBqdXN0aWZpY2F0aW9uIHdoeSBhbnkgbmV3DQo+PiAgaG9wLWJ5LWhvcCBvcHRpb24gaXMg
bmVlZGVkIGJlZm9yZSBpdCBpcyBzdGFuZGFyZGl6ZWQuDQo+PiANCj4+IFdoZXJlIGEgbmV3IHJl
cXVpcmVtZW50IGFyaXNlcyB0byBjYXJyeSBvcHRpb25hbCBpbmZvcm1hdGlvbiB0aGF0DQo+PiBt
dXN0IGJlIGV4YW1pbmVkIG9ubHkgYnkgYSBwYWNrZXQncyBkZXN0aW5hdGlvbiBub2RlKHMpLCBp
bnN0ZWFkDQo+PiBvZiBkZWZpbmluZyBuZXcgRXh0ZW5zaW9uIEhlYWRlcnMsIGl0IGlzIHJlY29t
bWVuZGVkIHRoYXQgdGhlDQo+PiBleGlzdGluZyBEZXN0aW5hdGlvbiBPcHRpb25zIGhlYWRlciBp
cyB1c2VkIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uDQo+PiAoKiBBZGQgdGhlIHJhdGlvbmFs
ZSB0ZXh0IGJhY2sgaW4gaGVyZSBpZiB0aGF04oCZcyBkZWVtZWQgdXNlZnVsOyBpdCBzZWVtcyB1
bm5lY2Vzc2FyeT8gKikNCj4+IA0KPj4gIElmIG5ldyBFeHRlbnNpb24gSGVhZGVycyBhcmUgZGVm
aW5lZCwgdGhleSBuZWVkIHRvIOKApi4NCj4+IA0KPiANCj4gSSBhZ3JlZSB0aGF0IGl0IG1ha2Vz
IHNlbnNlIHRvIG1vdmUgdGhlIGdlbmVyYWwgc3RhdGVtZW50IGZpcnN0IGluIHRoaXMgc2VjdGlv
bi4gIEhvdyBhYm91dCB0aGUgZm9sbG93aW5nPw0KPiANCj4gQm9iDQo+IA0KPiAgTkVXIE5FVw0K
PiANCj4gICBEZWZpbmluZyBuZXcgSVB2NiBleHRlbnNpb24gaGVhZGVycyBpcyBub3QgcmVjb21t
ZW5kZWQsIHVubGVzcyBubw0KPiAgIGV4aXN0aW5nIElQdjYgZXh0ZW5zaW9uIGhlYWRlciBjYW4g
YmUgdXNlZCBieSBzcGVjaWZ5aW5nIGEgbmV3IG9wdGlvbg0KPiAgIGZvciB0aGF0IGV4aXN0aW5n
IElQdjYgZXh0ZW5zaW9uIGhlYWRlci4gIEFueSBwcm9wb3NhbCB0byBjcmVhdGUgb3INCj4gICBz
cGVjaWZ5IGEgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBtdXN0IGluY2x1ZGUgYSBkZXRhaWxl
ZCB0ZWNobmljYWwNCj4gICBleHBsYW5hdGlvbiBvZiB3aHkgbm8gZXhpc3RpbmcgSVB2NiBleHRl
bnNpb24gaGVhZGVyIGNhbiBiZSB1c2VkIGluDQo+ICAgdGhlIGRvY3VtZW50IHByb3Bvc2luZyB0
aGUgbmV3IElQdjYgZXh0ZW5zaW9uIGhlYWRlci4NCj4gDQo+ICAgTm90ZTogTmV3IGV4dGVuc2lv
biBoZWFkZXJzIHRoYXQgcmVxdWlyZSBob3AtYnktaG9wIGJlaGF2aW9yIG11c3Qgbm90DQo+ICAg
YmUgZGVmaW5lZCBiZWNhdXNlLCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA0IG9mIHRoaXMgZG9j
dW1lbnQsIHRoZQ0KPiAgIG9ubHkgRXh0ZW5zaW9uIEhlYWRlciB0aGF0IGhhcyBob3AtYnktaG9w
IGJlaGF2aW9yIGlzIHRoZSBIb3AtYnktSG9wDQo+ICAgT3B0aW9ucyBoZWFkZXIuDQo+IA0KPiAg
IE5ldyBob3AtYnktaG9wIG9wdGlvbnMgYXJlIG5vdCByZWNvbW1lbmRlZCBiZWNhdXNlIG5vZGVz
IG1heSBiZQ0KPiAgIGNvbmZpZ3VyZWQgdG8gaWdub3JlIHRoZSBIb3AtYnktSG9wIE9wdGlvbiBo
ZWFkZXIsIGRyb3AgcGFja2V0cw0KPiAgIGNvbnRhaW5pbmcgYSBob3AtYnktaG9wIGhlYWRlciwg
b3IgYXNzaWduIHBhY2tldHMgY29udGFpbmluZyBhIGhvcC0NCj4gICBieS1ob3AgaGVhZGVyIHRv
IGEgc2xvdyBwcm9jZXNzaW5nIHBhdGguICBEZXNpZ25lcnMgY29uc2lkZXJpbmcNCj4gICBkZWZp
bmluZyBuZXcgaG9wLWJ5LWhvcCBvcHRpb25zIG5lZWQgdG8gYmUgYXdhcmUgb2YgdGhpcyBsaWtl
bHkNCj4gICBiZWhhdmlvdXIuICBUaGVyZSBoYXMgdG8gYmUgYSB2ZXJ5IGNsZWFyIGp1c3RpZmlj
YXRpb24gd2h5IGFueSBuZXcNCj4gICBob3AtYnktaG9wIG9wdGlvbiBpcyBuZWVkZWQgYmVmb3Jl
IGl0IGlzIHN0YW5kYXJkaXplZC4NCj4gDQo+ICAgSW5zdGVhZCBvZiBkZWZpbmluZyBuZXcgRXh0
ZW5zaW9uIEhlYWRlcnMsIGl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlDQo+ICAgRGVzdGluYXRp
b24gT3B0aW9ucyBoZWFkZXIgaXMgdXNlZCB0byBjYXJyeSBvcHRpb25hbCBpbmZvcm1hdGlvbiB0
aGF0DQo+ICAgbXVzdCBiZSBwcm9jZXNzZWQgb25seSBieSBhIHBhY2tldCdzIGRlc3RpbmF0aW9u
IG5vZGUocyksIGJlY2F1c2UgdGhleQ0KPiAgIHByb3ZpZGUgYmV0dGVyIGhhbmRsaW5nIGFuZCBi
YWNrd2FyZCBjb21wYXRpYmlsaXR5Lg0KPiANCj4gICBFTkQgTkVXIE5FVw0KPiANCj4gDQo+IA0K
PiANCj4+IOKAlA0KPj4gDQo+PiBCZXN0IHdpc2hlcywNCj4+IFRpbQ0KPj4gDQo+Pj4gDQo+Pj4g
RU5EIE5FVw0KPj4+IA0KPj4+IElmIG5ldyBFeHRlbnNpb24gSGVhZGVycyBhcmUgZGVmaW5lZCwg
dGhleSBuZWVkIHRvIHVzZSB0aGUgZm9sbG93aW5nDQo+Pj4gZm9ybWF0Og0KPj4+IA0KPj4+IC4g
LiAuIC4gLiAuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBJRVRGIElQ
djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+PiBpcHY2QGlldGYub3JnDQo+Pj4gQWRt
aW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaXB2Ng0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg==


From nobody Fri Apr 28 09:11:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3C12EAC1 for ; Fri, 28 Apr 2017 09:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ctNDEWMl3Bqt for ; Fri, 28 Apr 2017 09:11:29 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7935E12EABE for ; Fri, 28 Apr 2017 09:07:46 -0700 (PDT)
Received: from [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416] (unknown [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1B7D780984; Fri, 28 Apr 2017 18:08:02 +0200 (CEST)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: "Stefano Previdi (sprevidi)" , Bob Hinden 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
Cc: IPv6 List 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <9d71de8f-d17b-e747-80ba-933e746d75c4@si6networks.com>
Date: Fri, 28 Apr 2017 17:04:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:11:31 -0000

On 04/27/2017 01:04 PM, Stefano Previdi (sprevidi) wrote:
> 
>> On Apr 25, 2017, at 12:52 AM, Bob Hinden 
>> wrote:
[....]
>> 
>> NEW
>> 
>> Extension headers (except for the Hop-by-Hop Options header) are
>> not
> 
> 
> my recommendation is to change “are not” with “SHOULD NOT”.
> 
> This doesn’t change what the current text assumes while it uses a
> more formal language.

This would be incorrect. "are not" is similar to "must not", whereas
"should not" is not. And what the wg meant is "MUST NOT". If there s any
change to be made, it is to replace "are not" with "must not".

And we should probably do, so that we can avoid the next 100+ message
debate on "what 'are not' means".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Apr 28 09:11:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBC912EAE2 for ; Fri, 28 Apr 2017 09:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 oUDfEgQJR_ZP for ; Fri, 28 Apr 2017 09:11:33 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE02128CD5 for ; Fri, 28 Apr 2017 09:07:48 -0700 (PDT)
Received: from [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416] (unknown [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8C544809B2; Fri, 28 Apr 2017 18:08:04 +0200 (CEST)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Brian E Carpenter , "Ahmed Bashandy (bashandy)" , "Stefano Previdi (sprevidi)" , Bob Hinden 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com> 
Cc: IPv6 List 
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
Date: Fri, 28 Apr 2017 17:06:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:11:35 -0000

On 04/27/2017 09:54 PM, Brian E Carpenter wrote:
> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
>> Agreed
>>
>> rfc2119 has clear definition of the normative language that alleviates 
>> any ambiguity. So it is always good to use them
> 
> iirc the WG already agreed to the editor's choice to follow RFC2460 by using
> plain English rather than RFC2119. And "are not" does not mean the same thing
> as "should not", with or without upper case letters. Personally, I agree with
> "are not" and disagree with "should not", which changes the meaning.

FWIW, I agree 100% with you.

That said, given the past (unfortunate) history with this topic, we
should probably change the "are not" to "must not", so that we can avoid
future debates on what "are not" means (clearly, it means "must not").

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Apr 28 09:11:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71F12EAC8 for ; Fri, 28 Apr 2017 09:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 KBwBTAgqmNv6 for ; Fri, 28 Apr 2017 09:11:35 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F979129409 for ; Fri, 28 Apr 2017 09:07:50 -0700 (PDT)
Received: from [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416] (unknown [IPv6:2a02:8084:c83:5900:a112:d05b:c61a:1416]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 86600809C0; Fri, 28 Apr 2017 18:08:07 +0200 (CEST)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: "Ahmed Bashandy (bashandy)" , Brian E Carpenter , "Stefano Previdi (sprevidi)" , Bob Hinden 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com>
Cc: IPv6 List 
From: Fernando Gont 
Message-ID: <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>
Date: Fri, 28 Apr 2017 17:07:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5903560D.50803@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:11:37 -0000

Abmed,

What I was thought when learning English as a second language is that
"are not" has the same meaning as "must not".

Thanks,
Fernando




On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:
> If I were to implement this RFC, what is the meaning of "are not"? where
> is unambiguously defined?
> 
> Ahmed
> 
> On 4/27/2017 1:54 PM, Brian E Carpenter wrote:
>> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
>>> Agreed
>>>
>>> rfc2119 has clear definition of the normative language that alleviates
>>> any ambiguity. So it is always good to use them
>> iirc the WG already agreed to the editor's choice to follow RFC2460 by
>> using
>> plain English rather than RFC2119. And "are not" does not mean the
>> same thing
>> as "should not", with or without upper case letters. Personally, I
>> agree with
>> "are not" and disagree with "should not", which changes the meaning.
>>
>>     Brian
>>
>>> Ahmed
>>>
>>>
>>> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
>>>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> After reading through the discussion about this text in Section 4,
>>>>> I have some new text to propose.  I think this is significantly
>>>>> improved and should resolve many of the issued raised.
>>>>>
>>>>> Changes include separate description of behaviors extension headers
>>>>> and the hop-by-hop option header, remove “examine” from the first
>>>>> paragraph.  I removed “examine” because I am convinced it’s not
>>>>> sustainable to say a node can’t examine extension given how
>>>>> widespread this behavior is.  I also removed the reference to
>>>>> RFC7045 because examine is removed.  RFC7045 is referenced in the
>>>>> recently updated Security Considerations section.
>>>>>
>>>>> I removed the “including the source and destination nodes” text
>>>>> from the paragraph on the hop-by-hop options header because I don’t
>>>>> think we need to mention the source, and there is a whole paragraph
>>>>> describe what happens at the destination node.  I also added the
>>>>> text about from the first paragraph about reaching the destination
>>>>> to the hop-by-hop header paragraph.
>>>>>
>>>>> I also moved (without change) the “At the Destination node...” text
>>>>> from the first paragraph to a new third paragraph.  It applies to
>>>>> all extension headers.
>>>>>
>>>>> CURRENT and NEW text below.  Please review and comment.
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>>     CURRENT
>>>>>
>>>>>     With one exception, extension headers are not examined, processed,
>>>>>     inserted, or deleted by any node along a packet's delivery path,
>>>>>     until the packet reaches the node (or each of the set of nodes, in
>>>>>     the case of multicast) identified in the Destination Address
>>>>> field of
>>>>>     the IPv6 header.  Note: If an intermediate forwarding node
>>>>> examines
>>>>>     an extension header for any reason, it must do so in accordance
>>>>> with
>>>>>     the provisions of [RFC7045].  At the Destination node, normal
>>>>>     demultiplexing on the Next Header field of the IPv6 header invokes
>>>>>     the module to process the first extension header, or the
>>>>> upper-layer
>>>>>     header if no extension header is present.  The contents and
>>>>> semantics
>>>>>     of each extension header determine whether or not to proceed to
>>>>> the
>>>>>     next header.  Therefore, extension headers must be processed
>>>>> strictly
>>>>>     in the order they appear in the packet; a receiver must not, for
>>>>>     example, scan through a packet looking for a particular kind of
>>>>>     extension header and process that header prior to processing all
>>>>>     preceding ones.
>>>>>
>>>>>     The exception referred to in the preceding paragraph is the
>>>>> Hop-by-
>>>>>     Hop Options header, which carries information that may be examined
>>>>>     and processed by every node along a packet's delivery path,
>>>>> including
>>>>>     the source and destination nodes.  The Hop-by-Hop Options header,
>>>>>     when present, must immediately follow the IPv6 header.  Its
>>>>> presence
>>>>>     is indicated by the value zero in the Next Header field of the
>>>>> IPv6
>>>>>     header.
>>>>>
>>>>>     NEW
>>>>>
>>>>>     Extension headers (except for the Hop-by-Hop Options header)
>>>>> are not
>>>> my recommendation is to change “are not” with “SHOULD NOT”.
>>>>
>>>> This doesn’t change what the current text assumes while it uses a
>>>> more formal language.
>>>>
>>>> s.
>>>>
>>>>
>>>>>     processed, inserted, or deleted by any node along a packet's
>>>>> delivery
>>>>>     path, until the packet reaches the node (or each of the set of
>>>>> nodes,
>>>>>     in the case of multicast) identified in the Destination Address
>>>>> field
>>>>>     of the IPv6 header.
>>>>>
>>>>>     The Hop-by-Hop Options header is not inserted or deleted, but
>>>>> may be
>>>>>     examined and processed by every node along a packet's delivery
>>>>> path,
>>>>>     until the packet reaches the node (or each of the set of nodes, in
>>>>>     the case of multicast) identified in the Destination Address
>>>>> field of
>>>>>     the IPv6 header.  The Hop-by-Hop Options header, when present,
>>>>> must
>>>>>     immediately follow the IPv6 header.  Its presence is indicated
>>>>> by the
>>>>>     value zero in the Next Header field of the IPv6 header.
>>>>>
>>>>>     At the Destination node, normal demultiplexing on the Next Header
>>>>>     field of the IPv6 header invokes the module to process the first
>>>>>     extension header, or the upper-layer header if no extension
>>>>> header is
>>>>>     present.  The contents and semantics of each extension header
>>>>>     determine whether or not to proceed to the next header. 
>>>>> Therefore,
>>>>>     extension headers must be processed strictly in the order they
>>>>> appear
>>>>>     in the packet; a receiver must not, for example, scan through a
>>>>>     packet looking for a particular kind of extension header and
>>>>> process
>>>>>     that header prior to processing all preceding ones.
>>>>>
>>>>>     END NEW
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Apr 28 09:17:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C57129423 for ; Fri, 28 Apr 2017 09:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4J-FLxPyfOcx for ; Fri, 28 Apr 2017 09:16:57 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CC912EB0D for ; Fri, 28 Apr 2017 09:12:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10946; q=dns/txt; s=iport; t=1493395948; x=1494605548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2l/KeFGjRZnxg1Q9c8UvuY15yP3ZlrxrdKFB/W6RlXU=; b=HpWHbpI/BcI5aeZ0R85L3CDFz3538anj08BtZr6GdDwZCoMrb6k3LzJq Jl6Ey0dFFHjy2iPdWtSDZfflLp/FHBIxbHtlU0kfi06q0nerXQTHfAR7l 9WfZHyXvHA8cQQyUTM6PtbH6bW49s1V0fTVO9wJw2Ysl17gGTimW2guc7 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAABCaQNZ/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKGJFNiCKNS4IPIQuFeAIahBw/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBIREzBgELDAQCAQgOAwQBAQECAiMDAgICHwYLFAEICAIEAQ0FC?= =?us-ascii?q?Il/AxUOrxyCJoc2DYNHAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4pMglOCI4J?= =?us-ascii?q?vgl8FiT2TWTsBikuDdoRDgguFN4hogT2LG4kNAR84gQpvFUSGcHWGX4ENAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,388,1488844800"; d="scan'208";a="419298298"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2017 16:12:26 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3SGCQH0030494 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2017 16:12:26 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Apr 2017 12:12:25 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 28 Apr 2017 12:12:25 -0400
From: "Ahmed Bashandy (bashandy)" 
To: Fernando Gont , Brian E Carpenter , "Stefano Previdi (sprevidi)" , Bob Hinden 
CC: IPv6 List 
Subject: RE: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSvU2LFfwrV27JpUS6O7vyILpv0KHZZUuAgAAPIwCAAITvgIABK9yAgAAWV4D//70pQA==
Date: Fri, 28 Apr 2017 16:12:25 +0000
Message-ID: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>
In-Reply-To: <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.35.235]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:16:59 -0000

U28gd2h5IG5vdCB1c2UgdGhlIHN0YW5kYXJkaXplZCAibXVzdCBub3QiPw0KDQpBaG1lZA0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGZXJuYW5kbyBHb250IFttYWlsdG86
ZmdvbnRAc2k2bmV0d29ya3MuY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMjgsIDIwMTcgOTow
OCBBTQ0KVG86IEFobWVkIEJhc2hhbmR5IChiYXNoYW5keSk7IEJyaWFuIEUgQ2FycGVudGVyOyBT
dGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTsgQm9iIEhpbmRlbg0KQ2M6IElQdjYgTGlzdA0KU3Vi
amVjdDogUmU6IFByb3Bvc2VkIHJldmlzZWQgRXh0ZW5zaW9uIEhlYWRlciB0ZXh0IGZvciByZmMy
NDYwYmlzDQoNCkFibWVkLA0KDQpXaGF0IEkgd2FzIHRob3VnaHQgd2hlbiBsZWFybmluZyBFbmds
aXNoIGFzIGEgc2Vjb25kIGxhbmd1YWdlIGlzIHRoYXQgImFyZSBub3QiIGhhcyB0aGUgc2FtZSBt
ZWFuaW5nIGFzICJtdXN0IG5vdCIuDQoNClRoYW5rcywNCkZlcm5hbmRvDQoNCg0KDQoNCk9uIDA0
LzI4LzIwMTcgMDM6NDcgUE0sIEFobWVkIEJhc2hhbmR5IChiYXNoYW5keSkgd3JvdGU6DQo+IElm
IEkgd2VyZSB0byBpbXBsZW1lbnQgdGhpcyBSRkMsIHdoYXQgaXMgdGhlIG1lYW5pbmcgb2YgImFy
ZSBub3QiPyANCj4gd2hlcmUgaXMgdW5hbWJpZ3VvdXNseSBkZWZpbmVkPw0KPiANCj4gQWhtZWQN
Cj4gDQo+IE9uIDQvMjcvMjAxNyAxOjU0IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4+
IE9uIDI4LzA0LzIwMTcgMDc6NTgsIEFobWVkIEJhc2hhbmR5IChiYXNoYW5keSkgd3JvdGU6DQo+
Pj4gQWdyZWVkDQo+Pj4NCj4+PiByZmMyMTE5IGhhcyBjbGVhciBkZWZpbml0aW9uIG9mIHRoZSBu
b3JtYXRpdmUgbGFuZ3VhZ2UgdGhhdCANCj4+PiBhbGxldmlhdGVzIGFueSBhbWJpZ3VpdHkuIFNv
IGl0IGlzIGFsd2F5cyBnb29kIHRvIHVzZSB0aGVtDQo+PiBpaXJjIHRoZSBXRyBhbHJlYWR5IGFn
cmVlZCB0byB0aGUgZWRpdG9yJ3MgY2hvaWNlIHRvIGZvbGxvdyBSRkMyNDYwIA0KPj4gYnkgdXNp
bmcgcGxhaW4gRW5nbGlzaCByYXRoZXIgdGhhbiBSRkMyMTE5LiBBbmQgImFyZSBub3QiIGRvZXMg
bm90IA0KPj4gbWVhbiB0aGUgc2FtZSB0aGluZyBhcyAic2hvdWxkIG5vdCIsIHdpdGggb3Igd2l0
aG91dCB1cHBlciBjYXNlIA0KPj4gbGV0dGVycy4gUGVyc29uYWxseSwgSSBhZ3JlZSB3aXRoICJh
cmUgbm90IiBhbmQgZGlzYWdyZWUgd2l0aCAic2hvdWxkIA0KPj4gbm90Iiwgd2hpY2ggY2hhbmdl
cyB0aGUgbWVhbmluZy4NCj4+DQo+PiAgICAgQnJpYW4NCj4+DQo+Pj4gQWhtZWQNCj4+Pg0KPj4+
DQo+Pj4gT24gNC8yNy8yMDE3IDU6MDQgQU0sIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIHdy
b3RlOg0KPj4+Pj4gT24gQXByIDI1LCAyMDE3LCBhdCAxMjo1MiBBTSwgQm9iIEhpbmRlbiA8Ym9i
LmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IEhpLA0KPj4+Pj4NCj4+Pj4+
IEFmdGVyIHJlYWRpbmcgdGhyb3VnaCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHRleHQgaW4g
U2VjdGlvbiA0LCANCj4+Pj4+IEkgaGF2ZSBzb21lIG5ldyB0ZXh0IHRvIHByb3Bvc2UuICBJIHRo
aW5rIHRoaXMgaXMgc2lnbmlmaWNhbnRseSANCj4+Pj4+IGltcHJvdmVkIGFuZCBzaG91bGQgcmVz
b2x2ZSBtYW55IG9mIHRoZSBpc3N1ZWQgcmFpc2VkLg0KPj4+Pj4NCj4+Pj4+IENoYW5nZXMgaW5j
bHVkZSBzZXBhcmF0ZSBkZXNjcmlwdGlvbiBvZiBiZWhhdmlvcnMgZXh0ZW5zaW9uIA0KPj4+Pj4g
aGVhZGVycyBhbmQgdGhlIGhvcC1ieS1ob3Agb3B0aW9uIGhlYWRlciwgcmVtb3ZlIOKAnGV4YW1p
bmXigJ0gZnJvbSANCj4+Pj4+IHRoZSBmaXJzdCBwYXJhZ3JhcGguICBJIHJlbW92ZWQg4oCcZXhh
bWluZeKAnSBiZWNhdXNlIEkgYW0gY29udmluY2VkIA0KPj4+Pj4gaXTigJlzIG5vdCBzdXN0YWlu
YWJsZSB0byBzYXkgYSBub2RlIGNhbuKAmXQgZXhhbWluZSBleHRlbnNpb24gZ2l2ZW4gDQo+Pj4+
PiBob3cgd2lkZXNwcmVhZCB0aGlzIGJlaGF2aW9yIGlzLiAgSSBhbHNvIHJlbW92ZWQgdGhlIHJl
ZmVyZW5jZSB0bw0KPj4+Pj4gUkZDNzA0NSBiZWNhdXNlIGV4YW1pbmUgaXMgcmVtb3ZlZC4gIFJG
QzcwNDUgaXMgcmVmZXJlbmNlZCBpbiB0aGUgDQo+Pj4+PiByZWNlbnRseSB1cGRhdGVkIFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQo+Pj4+Pg0KPj4+Pj4gSSByZW1vdmVkIHRoZSDi
gJxpbmNsdWRpbmcgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbm9kZXPigJ0gdGV4dCANCj4+
Pj4+IGZyb20gdGhlIHBhcmFncmFwaCBvbiB0aGUgaG9wLWJ5LWhvcCBvcHRpb25zIGhlYWRlciBi
ZWNhdXNlIEkgDQo+Pj4+PiBkb27igJl0IHRoaW5rIHdlIG5lZWQgdG8gbWVudGlvbiB0aGUgc291
cmNlLCBhbmQgdGhlcmUgaXMgYSB3aG9sZSANCj4+Pj4+IHBhcmFncmFwaCBkZXNjcmliZSB3aGF0
IGhhcHBlbnMgYXQgdGhlIGRlc3RpbmF0aW9uIG5vZGUuICBJIGFsc28gDQo+Pj4+PiBhZGRlZCB0
aGUgdGV4dCBhYm91dCBmcm9tIHRoZSBmaXJzdCBwYXJhZ3JhcGggYWJvdXQgcmVhY2hpbmcgdGhl
IA0KPj4+Pj4gZGVzdGluYXRpb24gdG8gdGhlIGhvcC1ieS1ob3AgaGVhZGVyIHBhcmFncmFwaC4N
Cj4+Pj4+DQo+Pj4+PiBJIGFsc28gbW92ZWQgKHdpdGhvdXQgY2hhbmdlKSB0aGUg4oCcQXQgdGhl
IERlc3RpbmF0aW9uIG5vZGUuLi7igJ0gDQo+Pj4+PiB0ZXh0IGZyb20gdGhlIGZpcnN0IHBhcmFn
cmFwaCB0byBhIG5ldyB0aGlyZCBwYXJhZ3JhcGguICBJdCANCj4+Pj4+IGFwcGxpZXMgdG8gYWxs
IGV4dGVuc2lvbiBoZWFkZXJzLg0KPj4+Pj4NCj4+Pj4+IENVUlJFTlQgYW5kIE5FVyB0ZXh0IGJl
bG93LiAgUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4NCj4+Pj4+DQo+Pj4+PiBCb2INCj4+Pj4+
DQo+Pj4+Pg0KPj4+Pj4gICAgIENVUlJFTlQNCj4+Pj4+DQo+Pj4+PiAgICAgV2l0aCBvbmUgZXhj
ZXB0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgbm90IGV4YW1pbmVkLCBwcm9jZXNzZWQsDQo+
Pj4+PiAgICAgaW5zZXJ0ZWQsIG9yIGRlbGV0ZWQgYnkgYW55IG5vZGUgYWxvbmcgYSBwYWNrZXQn
cyBkZWxpdmVyeSBwYXRoLA0KPj4+Pj4gICAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUg
bm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KPj4+Pj4gICAgIHRoZSBjYXNl
IG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyANCj4+
Pj4+IGZpZWxkIG9mDQo+Pj4+PiAgICAgdGhlIElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50
ZXJtZWRpYXRlIGZvcndhcmRpbmcgbm9kZSANCj4+Pj4+IGV4YW1pbmVzDQo+Pj4+PiAgICAgYW4g
ZXh0ZW5zaW9uIGhlYWRlciBmb3IgYW55IHJlYXNvbiwgaXQgbXVzdCBkbyBzbyBpbiANCj4+Pj4+
IGFjY29yZGFuY2Ugd2l0aA0KPj4+Pj4gICAgIHRoZSBwcm92aXNpb25zIG9mIFtSRkM3MDQ1XS4g
IEF0IHRoZSBEZXN0aW5hdGlvbiBub2RlLCBub3JtYWwNCj4+Pj4+ICAgICBkZW11bHRpcGxleGlu
ZyBvbiB0aGUgTmV4dCBIZWFkZXIgZmllbGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMNCj4+
Pj4+ICAgICB0aGUgbW9kdWxlIHRvIHByb2Nlc3MgdGhlIGZpcnN0IGV4dGVuc2lvbiBoZWFkZXIs
IG9yIHRoZSANCj4+Pj4+IHVwcGVyLWxheWVyDQo+Pj4+PiAgICAgaGVhZGVyIGlmIG5vIGV4dGVu
c2lvbiBoZWFkZXIgaXMgcHJlc2VudC4gIFRoZSBjb250ZW50cyBhbmQgDQo+Pj4+PiBzZW1hbnRp
Y3MNCj4+Pj4+ICAgICBvZiBlYWNoIGV4dGVuc2lvbiBoZWFkZXIgZGV0ZXJtaW5lIHdoZXRoZXIg
b3Igbm90IHRvIHByb2NlZWQgDQo+Pj4+PiB0byB0aGUNCj4+Pj4+ICAgICBuZXh0IGhlYWRlci4g
IFRoZXJlZm9yZSwgZXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQgDQo+Pj4+PiBz
dHJpY3RseQ0KPj4+Pj4gICAgIGluIHRoZSBvcmRlciB0aGV5IGFwcGVhciBpbiB0aGUgcGFja2V0
OyBhIHJlY2VpdmVyIG11c3Qgbm90LCBmb3INCj4+Pj4+ICAgICBleGFtcGxlLCBzY2FuIHRocm91
Z2ggYSBwYWNrZXQgbG9va2luZyBmb3IgYSBwYXJ0aWN1bGFyIGtpbmQgb2YNCj4+Pj4+ICAgICBl
eHRlbnNpb24gaGVhZGVyIGFuZCBwcm9jZXNzIHRoYXQgaGVhZGVyIHByaW9yIHRvIHByb2Nlc3Np
bmcgYWxsDQo+Pj4+PiAgICAgcHJlY2VkaW5nIG9uZXMuDQo+Pj4+Pg0KPj4+Pj4gICAgIFRoZSBl
eGNlcHRpb24gcmVmZXJyZWQgdG8gaW4gdGhlIHByZWNlZGluZyBwYXJhZ3JhcGggaXMgdGhlDQo+
Pj4+PiBIb3AtYnktDQo+Pj4+PiAgICAgSG9wIE9wdGlvbnMgaGVhZGVyLCB3aGljaCBjYXJyaWVz
IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIGV4YW1pbmVkDQo+Pj4+PiAgICAgYW5kIHByb2Nlc3Nl
ZCBieSBldmVyeSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwgDQo+Pj4+PiBp
bmNsdWRpbmcNCj4+Pj4+ICAgICB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBub2Rlcy4gIFRo
ZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyLA0KPj4+Pj4gICAgIHdoZW4gcHJlc2VudCwgbXVz
dCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIElQdjYgaGVhZGVyLiAgSXRzIA0KPj4+Pj4gcHJlc2Vu
Y2UNCj4+Pj4+ICAgICBpcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIHplcm8gaW4gdGhlIE5leHQg
SGVhZGVyIGZpZWxkIG9mIHRoZQ0KPj4+Pj4gSVB2Ng0KPj4+Pj4gICAgIGhlYWRlci4NCj4+Pj4+
DQo+Pj4+PiAgICAgTkVXDQo+Pj4+Pg0KPj4+Pj4gICAgIEV4dGVuc2lvbiBoZWFkZXJzIChleGNl
cHQgZm9yIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyKSANCj4+Pj4+IGFyZSBub3QNCj4+
Pj4gbXkgcmVjb21tZW5kYXRpb24gaXMgdG8gY2hhbmdlIOKAnGFyZSBub3TigJ0gd2l0aCDigJxT
SE9VTEQgTk9U4oCdLg0KPj4+Pg0KPj4+PiBUaGlzIGRvZXNu4oCZdCBjaGFuZ2Ugd2hhdCB0aGUg
Y3VycmVudCB0ZXh0IGFzc3VtZXMgd2hpbGUgaXQgdXNlcyBhIA0KPj4+PiBtb3JlIGZvcm1hbCBs
YW5ndWFnZS4NCj4+Pj4NCj4+Pj4gcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4+ICAgICBwcm9jZXNzZWQs
IGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFueSBub2RlIGFsb25nIGEgcGFja2V0J3MgDQo+Pj4+
PiBkZWxpdmVyeQ0KPj4+Pj4gICAgIHBhdGgsIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUg
bm9kZSAob3IgZWFjaCBvZiB0aGUgc2V0IG9mIA0KPj4+Pj4gbm9kZXMsDQo+Pj4+PiAgICAgaW4g
dGhlIGNhc2Ugb2YgbXVsdGljYXN0KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiANCj4+
Pj4+IEFkZHJlc3MgZmllbGQNCj4+Pj4+ICAgICBvZiB0aGUgSVB2NiBoZWFkZXIuDQo+Pj4+Pg0K
Pj4+Pj4gICAgIFRoZSBIb3AtYnktSG9wIE9wdGlvbnMgaGVhZGVyIGlzIG5vdCBpbnNlcnRlZCBv
ciBkZWxldGVkLCBidXQgDQo+Pj4+PiBtYXkgYmUNCj4+Pj4+ICAgICBleGFtaW5lZCBhbmQgcHJv
Y2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSANCj4+Pj4+IHBh
dGgsDQo+Pj4+PiAgICAgdW50aWwgdGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNo
IG9mIHRoZSBzZXQgb2Ygbm9kZXMsIGluDQo+Pj4+PiAgICAgdGhlIGNhc2Ugb2YgbXVsdGljYXN0
KSBpZGVudGlmaWVkIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIA0KPj4+Pj4gZmllbGQgb2YN
Cj4+Pj4+ICAgICB0aGUgSVB2NiBoZWFkZXIuICBUaGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRl
ciwgd2hlbiBwcmVzZW50LCANCj4+Pj4+IG11c3QNCj4+Pj4+ICAgICBpbW1lZGlhdGVseSBmb2xs
b3cgdGhlIElQdjYgaGVhZGVyLiAgSXRzIHByZXNlbmNlIGlzIGluZGljYXRlZCANCj4+Pj4+IGJ5
IHRoZQ0KPj4+Pj4gICAgIHZhbHVlIHplcm8gaW4gdGhlIE5leHQgSGVhZGVyIGZpZWxkIG9mIHRo
ZSBJUHY2IGhlYWRlci4NCj4+Pj4+DQo+Pj4+PiAgICAgQXQgdGhlIERlc3RpbmF0aW9uIG5vZGUs
IG5vcm1hbCBkZW11bHRpcGxleGluZyBvbiB0aGUgTmV4dCBIZWFkZXINCj4+Pj4+ICAgICBmaWVs
ZCBvZiB0aGUgSVB2NiBoZWFkZXIgaW52b2tlcyB0aGUgbW9kdWxlIHRvIHByb2Nlc3MgdGhlIGZp
cnN0DQo+Pj4+PiAgICAgZXh0ZW5zaW9uIGhlYWRlciwgb3IgdGhlIHVwcGVyLWxheWVyIGhlYWRl
ciBpZiBubyBleHRlbnNpb24gDQo+Pj4+PiBoZWFkZXIgaXMNCj4+Pj4+ICAgICBwcmVzZW50LiAg
VGhlIGNvbnRlbnRzIGFuZCBzZW1hbnRpY3Mgb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyDQo+Pj4+
PiAgICAgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgdG8gdGhlIG5leHQgaGVh
ZGVyLiANCj4+Pj4+IFRoZXJlZm9yZSwNCj4+Pj4+ICAgICBleHRlbnNpb24gaGVhZGVycyBtdXN0
IGJlIHByb2Nlc3NlZCBzdHJpY3RseSBpbiB0aGUgb3JkZXIgdGhleSANCj4+Pj4+IGFwcGVhcg0K
Pj4+Pj4gICAgIGluIHRoZSBwYWNrZXQ7IGEgcmVjZWl2ZXIgbXVzdCBub3QsIGZvciBleGFtcGxl
LCBzY2FuIHRocm91Z2ggYQ0KPj4+Pj4gICAgIHBhY2tldCBsb29raW5nIGZvciBhIHBhcnRpY3Vs
YXIga2luZCBvZiBleHRlbnNpb24gaGVhZGVyIGFuZCANCj4+Pj4+IHByb2Nlc3MNCj4+Pj4+ICAg
ICB0aGF0IGhlYWRlciBwcmlvciB0byBwcm9jZXNzaW5nIGFsbCBwcmVjZWRpbmcgb25lcy4NCj4+
Pj4+DQo+Pj4+PiAgICAgRU5EIE5FVw0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gLS0g
SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcgDQo+Pj4+
PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gLS0NCj4+Pj4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KPj4+PiAtIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2
QGlldGYub3JnIEFkbWluaXN0cmF0aXZlIA0KPj4+PiBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gLQ0KPj4+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlw
djZAaWV0Zi5vcmcgQWRtaW5pc3RyYXRpdmUgDQo+Pj4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4gDQo+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBp
cHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQotLSANCkZlcm5h
bmRvIEdvbnQNClNJNiBOZXR3b3Jrcw0KZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NClBH
UCBGaW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFE
NEUgNzQ5Mg0KDQoNCg0KDQo=


From nobody Fri Apr 28 09:20:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424CD127241 for ; Fri, 28 Apr 2017 09:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Ef4Am8VEqL3A for ; Fri, 28 Apr 2017 09:20:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2253B129C5A for ; Fri, 28 Apr 2017 09:15:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0910720183; Fri, 28 Apr 2017 12:40:38 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64F4C636BB; Fri, 28 Apr 2017 12:14:59 -0400 (EDT)
From: Michael Richardson 
To: Brian E Carpenter 
cc: ipv6@ietf.org
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
In-Reply-To: <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com>
References:  <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org> <7144.1493328909@obiwan.sandelman.ca> <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:20:12 -0000

--=-=-=
Content-Type: text/plain


Brian E Carpenter  wrote:
    > Hi Michael, On 28/04/2017 09:35, Michael Richardson wrote: ...
    >> I think that, given the pushback we have on rfc2460bis, that I would
    >> like to make some progress on 6434bis before we attempt to finalize
    >> 2460bis.

    > I disagree quite strongly. On the contrary, we should IMHO get 2460bis
    > frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be
    > built on shifting sands and we'll never get out of the loop.

I don't it's useful to discuss header insertion or not or HbH option being
examined or not, etc. unless we know what the end host will do with the
result.

    > (I really wish we had a better mechanism than a rarely revised RFC for
    > formally defining the latest IPv6 node requirements, but that's not
    > really an option.  IMHO, Node Requirements should up for revision every
    > time a relevant RFC is published, not once in a while when somebody
    > thinks of it.)

I would agree... I think newtrk had a mechanism for this that you designed :-)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlkDaoMACgkQgItw+93Q
3WXR/Qf+NNswP6dRCHKTXtMhDyDebEGQG0XPDefo/VDWsL75dwARsbvUPynyGQkJ
3h/hA4pUSB+gMC8Kn0DylIsVotBIzd6CHyDV1Bar9cOhrdNert/JKPot4xQ1cFiD
bKjzoksbU1zzzgzImTncPy3gQ4T3o+TqE4GH1g5aeETJaY+gBW/8KYiaoXHm3MTJ
t2agKPAAKzL75+W/ouJgyGyhJlRap/FIOu3wEZAs9IoGb2+AsDLigXxGbWhVols6
8RZj7/rFQcshzvfuTFdLqvmRpXx1yiz2xwO0jaZbXu8jve6AFO9EASLigoug+cfL
4bTTGalgpjGymoLoM/41j6O2DVUl9g==
=vY7G
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Apr 28 09:24:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9EF129564 for ; Fri, 28 Apr 2017 09:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ChqxPYMmZmQv for ; Fri, 28 Apr 2017 09:24:03 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58B212EAC3 for ; Fri, 28 Apr 2017 09:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1094; q=dns/txt; s=iport; t=1493396327; x=1494605927; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OO2G9vRqZmuIqnIUiz3NQWC+foqwW1c6e5YsG+tOTn0=; b=LTipOMlHFAl5lvG8B+jee/HqG2LpE5JQThEdaf9gp8IkN/jZIUQmftJ+ H5HNZvPjEJdc2daMvJhr3p0N+wazbq3/42m0DZCqcD9MtHN6RN9A/xFuE DUbXx2rrNgYJ6RMNLKm/LYHbxrZyqAo5dzScHeoObhX+0VooW8nmDc+s2 k=;
X-IronPort-AV: E=Sophos;i="5.37,388,1488844800"; d="scan'208";a="237164422"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2017 16:18:46 +0000
Received: from [10.24.35.235] ([10.24.35.235]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3SGIi0X018346; Fri, 28 Apr 2017 16:18:45 GMT
Message-ID: <59036B64.4010008@cisco.com>
Date: Fri, 28 Apr 2017 09:18:44 -0700
From: "Ahmed Bashandy (bashandy)" 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Fernando Gont , Brian E Carpenter , "Stefano Previdi (sprevidi)" , Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
In-Reply-To: <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:24:04 -0000

I also agree
Using the standardized keywords avoids any *language-dependent* 
misunderstandings

Going back to the original discussion, I agree with Stefano's "should 
not" in this place


Ahmed

On 4/28/2017 9:06 AM, Fernando Gont wrote:
> On 04/27/2017 09:54 PM, Brian E Carpenter wrote:
>> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
>>> Agreed
>>>
>>> rfc2119 has clear definition of the normative language that alleviates
>>> any ambiguity. So it is always good to use them
>> iirc the WG already agreed to the editor's choice to follow RFC2460 by using
>> plain English rather than RFC2119. And "are not" does not mean the same thing
>> as "should not", with or without upper case letters. Personally, I agree with
>> "are not" and disagree with "should not", which changes the meaning.
> FWIW, I agree 100% with you.
>
> That said, given the past (unfortunate) history with this topic, we
> should probably change the "are not" to "must not", so that we can avoid
> future debates on what "are not" means (clearly, it means "must not").
>
> Thanks,


From nobody Fri Apr 28 09:24:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1934312951C for ; Fri, 28 Apr 2017 09:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ssrgc3zU98QP for ; Fri, 28 Apr 2017 09:24:11 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7080812953B for ; Fri, 28 Apr 2017 09:19:00 -0700 (PDT)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v3SGImlG035699 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Apr 2017 17:18:49 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <59036B68.4090501@foobar.org>
Date: Fri, 28 Apr 2017 17:18:48 +0100
From: Nick Hilliard 
User-Agent: Postbox 5.0.12 (Macintosh/20170323)
MIME-Version: 1.0
To: Fernando Gont 
CC: Brian E Carpenter , "Ahmed Bashandy (bashandy)" , "Stefano Previdi (sprevidi)" , Bob Hinden , IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
In-Reply-To: <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:24:18 -0000

Fernando Gont wrote:
> That said, given the past (unfortunate) history with this topic, we
> should probably change the "are not" to "must not", so that we can avoid
> future debates on what "are not" means (clearly, it means "must not").

Perhaps change to rfc6919-style "MUST NOT(BUT WE KNOW YOU WILL)"

Nick


From nobody Fri Apr 28 09:24:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A4712EB36 for ; Fri, 28 Apr 2017 09:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_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 zva2Z67OxODE for ; Fri, 28 Apr 2017 09:24:40 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 1EAFD12EB76 for ; Fri, 28 Apr 2017 09:19:19 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id y33so54024102qta.2 for ; Fri, 28 Apr 2017 09:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qfYetZoHwjSl8h1U2Me5QH1hfJShSKNaigVMr+LIX8c=; b=lfiltvfv9JT5KpA3znRXZI05CdBNMuaJSmMNCcWQ63X+1dFMZTDGztKfR1A4B3d2D2 BlnELBkY4inezcL68WJ+5MiC9bdiNNrkwB3tdnGjP0HRQ+gMIlvQZWKPD0/zFgi4gd2x 5K/AGarmA9CGNe1biWjGM8ODMx4bEztey5QhC7LR08mx5bZbYVKy+VMN7lB63vvj4RCe SLV8G9AXJsXjk5M3hROEeKAfGSdVc8t18ioa8KcEXgcb6lBM8FH4dFiBUIVAkBerKJ9u N8Jimu2egR60Ch5YxlduZTdAPiUfHWmO3oDQK4NxJSkh7iWowwFJYXA3AyylCE7cTDCV dPfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qfYetZoHwjSl8h1U2Me5QH1hfJShSKNaigVMr+LIX8c=; b=tQ4dZfZMWmFqskXk5Nc+a6mA3kr8tn9mTQHwebnXjg2sgerQJm+k3Eiaftza65Uxwq PO0/V8YBB+puIzBd2hiwQBhXa7IL1DItOHgMlI5PicSVHSKhBqf5saAuPBP5VvW401lJ Kingu7B9hUEKv8kPtm6ZppGwbeQdwawErQc20lyn4AUF+jf3THzga4fBiu3Wu2iYtCKj Bk+6n8Y1j0RtQEE1KAh5tKMJAPafYKL+priXBYpZiqLxkgCio99Ek0M0gwxEULfP+n8O wFwiR9rkNxA8LesVx9QFxamEFzk6YLw8K6gzs2KnYPl5QSZ4gqoQRu3rJAgiVxEsbdKK wbEw==
X-Gm-Message-State: AN3rC/73Qj/Nc/5K4u1llVTf3T8RBZRfY8ptfwNz+7XevQlXKu5IMJJi cO2sliMiT6RRQ/iOnt1Rb25oZ1mFcw==
X-Received: by 10.200.47.147 with SMTP id l19mr10261062qta.286.1493396358042;  Fri, 28 Apr 2017 09:19:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.166.130 with HTTP; Fri, 28 Apr 2017 09:19:17 -0700 (PDT)
Received: by 10.55.166.130 with HTTP; Fri, 28 Apr 2017 09:19:17 -0700 (PDT)
In-Reply-To: <51327F3A-BFF2-42A9-A709-256A84585FB9@jisc.ac.uk>
References:  <4AC521EA-AA08-4A1C-9C5C-886D0E78FA2A@employees.org> <7144.1493328909@obiwan.sandelman.ca> <7b88b653-5a66-91e3-5ebb-b42150176f4a@gmail.com> <51327F3A-BFF2-42A9-A709-256A84585FB9@jisc.ac.uk>
From: Suresh Krishnan 
Date: Fri, 28 Apr 2017 12:19:17 -0400
Message-ID: 
Subject: Re: Confirmation of consensus to adopt: draft-clw-rfc6434-bis-01
To: Tim Chown 
Cc: Brian E Carpenter , IPv6 List 
Content-Type: multipart/alternative; boundary=001a113d3f486e1aa6054e3c6f93
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:24:44 -0000

--001a113d3f486e1aa6054e3c6f93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Tim,



On Apr 28, 2017 6:04 AM, "Tim Chown"  wrote:

> On 28 Apr 2017, at 02:06, Brian E Carpenter 
wrote:
>
> Hi Michael,
> On 28/04/2017 09:35, Michael Richardson wrote:
> ...
>> I think that, given the pushback we have on rfc2460bis, that I would
like to
>> make some progress on 6434bis before we attempt to finalize 2460bis.
>
> I disagree quite strongly. On the contrary, we should IMHO get 2460bis
> frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be built
on
> shifting sands and we'll never get out of the loop.

I agree with Brian.  And 6434bis will only reflect what=E2=80=99s in 2460bi=
s; we
need to get 2460bis frozen so we know what to put in 6434bis.

> (I really wish we had a better mechanism than a rarely revised RFC for
formally
> defining the latest IPv6 node requirements, but that's not really an
option.
> IMHO, Node Requirements should up for revision every time a relevant RFC
is
> published, not once in a while when somebody thinks of it.)

An interesting point. You could for example keep a VersionN-bis draft
updated as soon as VersionN is published, and publish VersionN+1 as an RFC
at some agreed interval. On our current track record, that interval is
every 6 years. Such an approach would mean the most up-to-date guidance is
not in the most recently published RFC, but in the =E2=80=9Cliving=E2=80=9D=
 I-D.


That sounds reasonable to me. I was also thinking if a wiki could work but
keeping it updated as a draft gives us more options. E.g. We could publish
an RFC every x years with the current content if needed.

Regards
Suresh

--001a113d3f486e1aa6054e3c6f93
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Tim,=C2=A0



On Apr 28, 2017 6:04 AM,=
 "Tim Chown" <Tim.Chow=
n@jisc.ac.uk> wrote:
> On 28 Apr 2017, at 02:06, Brian E Carpent=
er <brian.e.carpenter@gma=
il.com> wrote:

>

> Hi Michael,

> On 28/04/2017 09:35, Michael Richardson wrote:

> ...

>> I think that, given the pushback we have on rfc2460bis, that I wou=
ld like to

>> make some progress on 6434bis before we attempt to finalize 2460bi=
s.

>

> I disagree quite strongly. On the contrary, we should IMHO get 2460bis=


> frozen and in the RFC Editor queue ASAP. Otherwise, 6434bis will be bu=
ilt on

> shifting sands and we'll never get out of the loop.




I agree with Brian.=C2=A0 And 6434bis will only reflect what=E2=80=99=
s in 2460bis; we need to get 2460bis frozen so we know what to put in 6434b=
is.




> (I really wish we had a better mechanism than a rarely revised RFC for=
 formally

> defining the latest IPv6 node requirements, but that's not really =
an option.

> IMHO, Node Requirements should up for revision every time a relevant R=
FC is

> published, not once in a while when somebody thinks of it.)




An interesting point. You could for example keep a VersionN-bis draft=
 updated as soon as VersionN is published, and publish VersionN+1 as an RFC=
 at some agreed interval. On our current track record, that interval is eve=
ry 6 years. Such an approach would mean the most up-to-date guidance is not=
 in the most recently published RFC, but in the =E2=80=9Cliving=E2=80=9D I-=
D.

That sounds reasonable to me. I was also thinking if a wiki could work =
but keeping it updated as a draft gives us more options. E.g. We could publ=
ish an RFC every x years with the current content if needed.=C2=A0

Regards=C2=A0
Suresh


--001a113d3f486e1aa6054e3c6f93--


From nobody Fri Apr 28 09:49:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F5E1289B0 for ; Fri, 28 Apr 2017 09:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 RdnZoMrjFows for ; Fri, 28 Apr 2017 09:49:01 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 979F1129571 for ; Fri, 28 Apr 2017 09:45:58 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id z52so36801877wrc.2 for ; Fri, 28 Apr 2017 09:45:58 -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=4xoz/hYgTp9b1I2pdQXma1rcYPawqWEDW5j9wAEdB0E=; b=hGiErzEr75IfQYhdudhm6wLeJEqxDimq0951W3F8f+9zXOsh4VLDmriib7jngqV+lr HK+CgPJvQcrmuG/OdtvDvWdK7ljaVgohJ9iThoXXtcMLTxmoJWlHgU/RbBurnFkOaLdI yuIu5y6F92RkL80zCSjdetJXdjMUGoB5o+dQQwoEvHyyK5QYPRg4iJpPi10wqykKBhtG eROcZxIQuYrCNOdIrwcf3lB0dSd56fM9HOuNNsXmSIeEzZRfekFu6V5cLl7tyJ+yKhpg SFP0R1g+agWBtqooZgE3HD4cTS9u21TC+1VdvkQshvAHDGmHW8r4Ftuf9Z52AyTzw+te jV6g==
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=4xoz/hYgTp9b1I2pdQXma1rcYPawqWEDW5j9wAEdB0E=; b=UMX17ZrZ+bBImuN4XEBz1sO3RyGaS6+XX/oFhLVpmJqRrZSYL0ZcYb+7kdiezUphez U2vGOx9FSL89iKN6jb59U6kgUd20YlorpaliGKo2MWZUDnuWMSHLJGq77MrebMnjdjw8 hALaWaVMS1x3Eo4GpABm8fIHvpCicdOkWSSUxdil8JARaTcRXZtyvZ+yLOFeFV1E53zQ 1m4WAvecanWNna7GvJqjUiZeBYlZQNdojD7SZ1CWaqN1CJ7a5DIk2sLZaQrgEPEcqef2 I0JTx/PgWOLygcfsae9ljBkXEAj+lHB8PaZbV7mpG07x4uH15PbkLGWtDy5eaoPEZrPQ dkOg==
X-Gm-Message-State: AN3rC/6W6udn8OspYcg7S8Zc/q8Pabj9YfO/CWGsUTgTWWCWARWAYNPD iYRq0mXqzUko1Q==
X-Received: by 10.223.183.12 with SMTP id l12mr7983873wre.191.1493397956957; Fri, 28 Apr 2017 09:45:56 -0700 (PDT)
Received: from [172.16.103.251] ([156.39.127.199]) by smtp.gmail.com with ESMTPSA id c37sm8273498wra.16.2017.04.28.09.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 09:45:55 -0700 (PDT)
From: Bob Hinden 
Message-Id: <5C81CF80-F950-4D44-A41B-F0256DB9B286@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7711EE0D-8888-49A1-9A33-084647ED0803"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Proposed text in Section 4.8. "Defining New Extension Headers and Options"
Date: Fri, 28 Apr 2017 09:45:49 -0700
In-Reply-To: 
Cc: Bob Hinden , IPv6 List 
To: Tim Chown 
References:   <75ACCE55-CA38-498C-B9C4-B1EA083CFB76@gmail.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:49:03 -0000

--Apple-Mail=_7711EE0D-8888-49A1-9A33-084647ED0803
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 28, 2017, at 9:06 AM, Tim Chown  wrote:
>=20
> Hi Bob,
>=20
> Perfectly happy with what you propose below.

Thanks,
Bob


>=20
> Best wishes,
>=20
> Tim
>=20
>> On 27 Apr 2017, at 22:45, Bob Hinden  wrote:
>>=20
>> Tim,
>>=20
>>> On Apr 27, 2017, at 2:02 AM, Tim Chown  wrote:
>>>=20
>>> Hi Bob,
>>>=20
>>>> On 26 Apr 2017, at 19:38, Bob Hinden  wrote:
>>>>=20
>>>> Hi,
>>>>=20
>>>> Based on the comments and IESG discusses, I clarified the text in =
Section 4.8 about defining new IPv6 extension headers.  The proposed =
text is much closer what was in RFC6564 that updated RFC2460.
>>>>=20
>>>> CURRENT and NEW text is below.
>>>>=20
>>>> Comments?
>>>>=20
>>>> Bob
>>>>=20
>>>> CURRENT
>>>>=20
>>>> Defining new IPv6 extension headers is not recommended.  There has =
to
>>>> be a very clear justification why any new extension header is =
needed
>>>> before it is standardized.  Instead of defining new Extension
>>>> Headers, it is recommended that the Destination Options header is
>>>> used to carry optional information that must be examined only by a
>>>> packet's destination node(s), because they provide better handling
>>>> and backward compatibility.
>>>>=20
>>>> NEW
>>>>=20
>>>> Defining new IPv6 extension headers is not recommended, unless no
>>>> existing IPv6 extension header can be used by specifying a new =
option
>>>> for that existing IPv6 extension header.  Any proposal to create or
>>>> specify a new IPv6 extension header must include a detailed =
technical
>>>> explanation of why no existing IPv6 extension header can be used in
>>>> the document proposing the new IPv6 extension header.
>>>=20
>>>=20
>>> That text is very close to section 3 of RFC6564, which is fine.
>>=20
>> Good, thanks.
>>=20
>>>=20
>>>> Instead of defining new Extension Headers, it is recommended that =
the
>>>> Destination Options header is used to carry optional information =
that
>>>> must be examined only by a packet's destination node(s), because =
they
>>>> provide better handling and backward compatibility.
>>>=20
>>> That=E2=80=99s fine for Destination options.
>>>=20
>>> But I think the ordering of the text in 4.8 would be a little odd =
though, so I=E2=80=99d suggest taking what you propose (NEW text) and =
reordering section 4.8 as follows (NEW NEW) so that the text talks at a =
high level, then about HbH, then about destination options, adding =E2=80=9C=
In particular,=E2=80=9D and =E2=80=9CFurther,=E2=80=9D to help the flow:
>>=20
>> See below.
>>=20
>>>=20
>>> =E2=80=94
>>>=20
>>> NEW:
>>>=20
>>> 4.8.  Defining New Extension Headers and Options
>>>=20
>>> New extension headers that require hop-by-hop behavior must not be
>>> defined because, as specified in Section 4 of this document, the =
only
>>> Extension Header that has hop-by-hop behavior is the Hop-by-Hop
>>> Options header.
>>>=20
>>> New hop-by-hop options are not recommended because nodes may be
>>> configured to ignore the Hop-by-Hop Option header, drop packets
>>> containing a hop-by-hop header, or assign packets containing a hop-
>>> by-hop header to a slow processing path.  Designers considering
>>> defining new hop-by-hop options need to be aware of this likely
>>> behaviour.  There has to be a very clear justification why any new
>>> hop-by-hop option is needed before it is standardized.
>>>=20
>>> Defining new IPv6 extension headers is not recommended, unless no
>>> existing IPv6 extension header can be used by specifying a new =
option
>>> for that existing IPv6 extension header.  Any proposal to create or
>>> specify a new IPv6 extension header must include a detailed =
technical
>>> explanation of why no existing IPv6 extension header can be used in
>>> the document proposing the new IPv6 extension header.
>>>=20
>>> Instead of defining new Extension Headers, it is recommended that =
the
>>> Destination Options header is used to carry optional information =
that
>>> must be examined only by a packet's destination node(s), because =
they
>>> provide better handling and backward compatibility.
>>>=20
>>> If new Extension Headers are defined, they need to =E2=80=A6.
>>>=20
>>> =E2=80=94
>>>=20
>>> NEW NEW:
>>>=20
>>> 4.8.  Defining New Extension Headers and Options
>>>=20
>>> Defining new IPv6 extension headers is not recommended, unless no
>>> existing IPv6 extension header can be used by specifying a new =
option
>>> for that existing IPv6 extension header.  Any proposal to create or
>>> specify a new IPv6 extension header must include a detailed =
technical
>>> explanation of why no existing IPv6 extension header can be used in
>>> the document proposing the new IPv6 extension header.
>>>=20
>>> In particular, new extension headers that require hop-by-hop =
behavior must not be
>>> defined because, as specified in Section 4 of this document, the =
only
>>> Extension Header that has hop-by-hop behavior is the Hop-by-Hop
>>> Options header.
>>>=20
>>> Further, new hop-by-hop options are not recommended because nodes =
may be
>>> configured to ignore the Hop-by-Hop Option header, drop packets
>>> containing a hop-by-hop header, or assign packets containing a hop-
>>> by-hop header to a slow processing path.  Designers considering
>>> defining new hop-by-hop options need to be aware of this likely
>>> behaviour.  There has to be a very clear justification why any new
>>> hop-by-hop option is needed before it is standardized.
>>>=20
>>> Where a new requirement arises to carry optional information that
>>> must be examined only by a packet's destination node(s), instead
>>> of defining new Extension Headers, it is recommended that the
>>> existing Destination Options header is used to carry such =
information.
>>> (* Add the rationale text back in here if that=E2=80=99s deemed =
useful; it seems unnecessary? *)
>>>=20
>>> If new Extension Headers are defined, they need to =E2=80=A6.
>>>=20
>>=20
>> I agree that it makes sense to move the general statement first in =
this section.  How about the following?
>>=20
>> Bob
>>=20
>> NEW NEW
>>=20
>>  Defining new IPv6 extension headers is not recommended, unless no
>>  existing IPv6 extension header can be used by specifying a new =
option
>>  for that existing IPv6 extension header.  Any proposal to create or
>>  specify a new IPv6 extension header must include a detailed =
technical
>>  explanation of why no existing IPv6 extension header can be used in
>>  the document proposing the new IPv6 extension header.
>>=20
>>  Note: New extension headers that require hop-by-hop behavior must =
not
>>  be defined because, as specified in Section 4 of this document, the
>>  only Extension Header that has hop-by-hop behavior is the Hop-by-Hop
>>  Options header.
>>=20
>>  New hop-by-hop options are not recommended because nodes may be
>>  configured to ignore the Hop-by-Hop Option header, drop packets
>>  containing a hop-by-hop header, or assign packets containing a hop-
>>  by-hop header to a slow processing path.  Designers considering
>>  defining new hop-by-hop options need to be aware of this likely
>>  behaviour.  There has to be a very clear justification why any new
>>  hop-by-hop option is needed before it is standardized.
>>=20
>>  Instead of defining new Extension Headers, it is recommended that =
the
>>  Destination Options header is used to carry optional information =
that
>>  must be processed only by a packet's destination node(s), because =
they
>>  provide better handling and backward compatibility.
>>=20
>>  END NEW NEW
>>=20
>>=20
>>=20
>>=20
>>> =E2=80=94
>>>=20
>>> Best wishes,
>>> Tim
>>>=20
>>>>=20
>>>> END NEW
>>>>=20
>>>> If new Extension Headers are defined, they need to use the =
following
>>>> format:
>>>>=20
>>>> . . . . . .
>>>>=20
>>>>=20
>>>>=20
>>>> =
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> =
--------------------------------------------------------------------
>=20


--Apple-Mail=_7711EE0D-8888-49A1-9A33-084647ED0803
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-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJZA3G+AAoJEK7rdBF357uo7LAIALe5RJlyyte2BbDBFluM+zAj
YCOuS3mDuDh1i0azm8K4E1pWjoHdlLiY96yuUmqHwOZ1oURekAWAr+5FCFxcgcQS
bzxkcLrNZXVnMfuEGvVsedd6p/OeMCUXpG1RpSXGUt+qyF7hhXdvOtLNSsnALvJG
KEioYM2l+vAxL+WSbkXRqgjwhb1Ac3Z+hktWNqb91VOEwQ3OmROajfF1Oc6B+wPW
aoakKmyFYIjb1JOdHPycD95aL3+2E2gE5ZYwuAIButhpOzn5FWhO/4iyAKjZ1YBa
QAr4C3d9EgkkzImM0KVGfJFfonRJ5G2KIYMHq3bk3h65nH9nmvEcR8SOl/2QblA=
=wG+X
-----END PGP SIGNATURE-----

--Apple-Mail=_7711EE0D-8888-49A1-9A33-084647ED0803--


From nobody Fri Apr 28 10:25:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47369128DE5 for ; Fri, 28 Apr 2017 10:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 jhBMQ2P9I_-L for ; Fri, 28 Apr 2017 10:25:37 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 52699129AA3 for ; Fri, 28 Apr 2017 10:22:03 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id y33so55381611qta.2 for ; Fri, 28 Apr 2017 10:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZboW8HxDZdyMeviAp5HPyS/C0Z1YUdYwUnYlx55MJtw=; b=lYbjfv9fqiGyIVGwntSPe4gKsawZXTfJwDOPmnij9PPlQSdAIXSJyU41lUgR8JhYIn AFkdpXrR2da50x0X+n+F2ktkeBwvE6IYQlCtnLvfPNoqacAs2I3T7TKcp6+llw9KQsZu yIIJJNFePFu3Mvf6GMZjjMTP/bPhfPtBFV/tFe7oLM47zlttihMiSBdc86U4J3daIh8h gQOsI5KRqQ91F2QuKiXHtogwLQ+VfISeng1WkJmmdFd5+Jcl+DgIfRcCDjULkfmIXu8/ Y1h2ajTvbUEYwRn5mL9qam8iSgPUqskNd1gg0/2gGLrMdfGrKLs/dO/EGr7vpYGlHPUc eQgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZboW8HxDZdyMeviAp5HPyS/C0Z1YUdYwUnYlx55MJtw=; b=B5A34Z53XUAcK0n0T2sPd5mP3iLM6bkwoiVerVvP9sZbtIyinbn7TxiBIBYiLJeGKu 92hPiPhRXxFioGPg70egI6O5+XAxcUtDnD2DdMG+z3yNbRqku70B+84Xp6qF7XT6Ga+6 SOkYuhdma3EJ2SJi0COZHSRb6VEgR+2+Bzu7qvm7sNVA0pjYy7LNzHq4KgP5xtwhhj45 yRbbiGupWuOT9co1he5GWc1GyLr/oFvHDAQsEvqMDIaZohrj9MdXerA3/7dSJ7RrBeZX qrdcAZvdrEPbjFmpzvHffVIAZg1oBb8pumIWwWn1/x9uCOiZegcljPMnOP/reJ6fJMde nNrg==
X-Gm-Message-State: AN3rC/5/nEkNL9X64Thpt/LL3w+qVdnmvhghz7oHq8UryT56CegwA0D5 BO66zJ4gnIuxr0dR7MdIFforDZL67Q==
X-Received: by 10.200.51.132 with SMTP id c4mr10974784qtb.13.1493400122317; Fri, 28 Apr 2017 10:22:02 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.208 with HTTP; Fri, 28 Apr 2017 10:22:01 -0700 (PDT)
In-Reply-To: <59036B64.4010008@cisco.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
Date: Fri, 28 Apr 2017 10:22:01 -0700
X-Google-Sender-Auth: d-AXAW49IeConw8iDt_rUQExlxo
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: "Ahmed Bashandy (bashandy)" 
Cc: Fernando Gont , Brian E Carpenter ,  "Stefano Previdi (sprevidi)" , Bob Hinden , IPv6 List 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 17:25:38 -0000

At Fri, 28 Apr 2017 09:18:44 -0700,
"Ahmed Bashandy (bashandy)"  wrote:

> I also agree
> Using the standardized keywords avoids any *language-dependent*
> misunderstandings

I also wish this document (both the latest bis and its predecessors)
had been using RFC2119 keywords, but the fact is that it hasn't, and
my recollection matches Brian's comment: we explicitly discussed it
before and the decision was not to use RFC2119 keywords for
rfc2460bis.  I don't think it productive to rehash the discussion at
this point.

> Going back to the original discussion, I agree with Stefano's "should
> not" in this place

I don't agree "should not" is an appropriate replacement of "are not",
just like Brian and Fernando.  I also agree with Fernando in that it's
actually much closer to "must not", if anything.  So if our goal is to
make it clearer, the logical conclusion should be a "must not".  But,
I personally would like to suggest stopping wording nitpicking like
this one.  I understand some people are not happy about the sense of
the wording.  In fact, I suspect we have this discussion not because
it's unclear or informal but because the meaning is closer to "must
not" and not all people like it.  But IMO at this stage it's much more
productive if we focus on shipping rfc2460bis and discussing other
updates to it sooner.

So I support the word "are not" and finishing the task.

--
JINMEI, Tatuya


From nobody Fri Apr 28 13:18:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55312951C for ; Fri, 28 Apr 2017 13:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 hJBDjCxPrDK2 for ; Fri, 28 Apr 2017 13:18:34 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 444C31294E9 for ; Fri, 28 Apr 2017 13:16:26 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id i4so16521942pfc.0 for ; Fri, 28 Apr 2017 13:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aagpkzhgrkx6RxBC3zFmoNblHz1lPcE3L9hNkV55jxw=; b=vE6y4YLFlCH6bFBAuBBLp2aftpMZHEJ6XItBzg9/ndWT3uF8k5D3XsQR8whHVm52AP rHwHHKcOFrxLYISDzt9gm0FIPyVx7itPpifdFZXiOR1harSGkYIfCfVKjZNm0pkEMFBR IvUFYGYfZTYVQEg8gz1GGI6JS1nXC4LFVT87TN0pcuct2+izPRWZFDd+cB/4q5aawYeL 9BnSvHbYenuObOUADRqlvTkAvx1Tlcz5alkIp6bPq3kYISpNqAegoQx+37/hc83kMxtY qGB6nyy01z0L2dvPIKb+U1uHPJftT6wxBZCVWtqsN4lxjm5e1KJkwDKA9L+1caHdNPdH EywA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=aagpkzhgrkx6RxBC3zFmoNblHz1lPcE3L9hNkV55jxw=; b=DR9dsIZh7TzwhYW1us2SnwWuNTXdTZPwNXVh7EMUNo8c5R6aD6x/sS1IXAeCjAFgYK spTwyTX8T1sXPCxAw0NpU60jOraD/u3DgwsK1JuMhufoOE9VDriovnIsGplkvACuJ27T iSl84Y7mVXFhY5ca+spawBRPly3UHki/aivhMNnybgQ4qrN6NWrDNr9h04PdMfACfq9m 2/2WRSW4MDl28JfbL1xV/Cfy9GEtM4BM9hWDLvc8XNZzeDLEAKZ1PdzKZ0jt+NEEK0lw JpHW9kLFZsYQ6sKa4zD7vPi9odXBjWIgQdzX7ZtetV9pX2z12HW4Q+ZxjxVreS9F2zUy 2ZtQ==
X-Gm-Message-State: AN3rC/4UQoh0a5pXF9OIZHNT23lXHKO9RBwbIDjyzHYTep1/0VIjq0sT BTuwqfZmM4dzgQ==
X-Received: by 10.98.209.24 with SMTP id z24mr14402862pfg.200.1493410585912; Fri, 28 Apr 2017 13:16:25 -0700 (PDT)
Received: from [192.168.178.21] ([118.149.105.110]) by smtp.gmail.com with ESMTPSA id 2sm11377299pfs.85.2017.04.28.13.16.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 13:16:25 -0700 (PDT)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Fernando Gont , "Ahmed Bashandy (bashandy)" , "Stefano Previdi (sprevidi)" , Bob Hinden 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
Cc: IPv6 List 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1e7ede20-5049-2084-b9e6-9314e24fee4d@gmail.com>
Date: Sat, 29 Apr 2017 08:16:31 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 20:18:36 -0000

On 29/04/2017 04:06, Fernando Gont wrote:
> On 04/27/2017 09:54 PM, Brian E Carpenter wrote:
>> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
>>> Agreed
>>>
>>> rfc2119 has clear definition of the normative language that alleviates 
>>> any ambiguity. So it is always good to use them
>>
>> iirc the WG already agreed to the editor's choice to follow RFC2460 by using
>> plain English rather than RFC2119. And "are not" does not mean the same thing
>> as "should not", with or without upper case letters. Personally, I agree with
>> "are not" and disagree with "should not", which changes the meaning.
> 
> FWIW, I agree 100% with you.
> 
> That said, given the past (unfortunate) history with this topic, we
> should probably change the "are not" to "must not", so that we can avoid
> future debates on what "are not" means (clearly, it means "must not").

Exactly. On the other hand, we are an international community so any time
anybody sees ambiguity, it is good to clarify it.

   Brian


From nobody Fri Apr 28 15:31:52 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4408129555; Fri, 28 Apr 2017 15:31:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-rfc2460bis-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149341871062.2854.15461030740811922884@ietfa.amsl.com>
Date: Fri, 28 Apr 2017 15:31:50 -0700
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 22:31:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance of the IETF.

        Title           : Internet Protocol, Version 6 (IPv6) Specification
        Authors         : Stephen E. Deering <>
                          Robert M. Hinden
	Filename        : draft-ietf-6man-rfc2460bis-11.txt
	Pages           : 45
	Date            : 2017-04-28

Abstract:
   This document specifies version 6 of the Internet Protocol (IPv6).
   It obsoletes RFC2460


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Apr 28 16:50:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968FA129520 for ; Fri, 28 Apr 2017 16:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 B6E7MqBotSaZ for ; Fri, 28 Apr 2017 16:50:26 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 2918B129476 for ; Fri, 28 Apr 2017 16:47:50 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id k87so80581921ioi.0 for ; Fri, 28 Apr 2017 16:47:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ASe35oBqEZ7ui+OYAl5ypN78rG3v7GW50xRVDrN8HPo=; b=n0UU7Om/pheeRfm99R+r6PLqER+KTWkK3AyN9hZKEGIkAeM0tl/IEO2ThPy2whaxxn PA8/gpc0TvAOZXjI4gBeV8oQuTNF83zkjcXvuYirOYBT5AKtnKD+rm4GfL/TX1MX8NIL 5gH9UNfjBr+YvlOpQ/L4Sx8yj5UgzeLbJQRnY3vF5kituBVCvLP94CThxy53rX0YQone AmZMnSvjRHG427yRyEGJ/6ZOy+IewGRHwE89j9DGq6pN+CWIZbV+x+5pDjIu2Ya98mhu y39O/RPwX2UYSTRpjPYQkhvPN2RZBJcGH7O169JlM4UtVxnK8Z9jvSvJ/mg00VChrDZs Peqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ASe35oBqEZ7ui+OYAl5ypN78rG3v7GW50xRVDrN8HPo=; b=osAiHHqWJzaaMv6zC4la5ly16u1coyh74CKpt6jAA953Y2rIszS3aatKsajYVwrzHd vhCi85rHgPTSNgIvn+zjrM1lvCuD6AsayjSONs3euSMp02KkViCiv2lJuO0V8yoo/phH e7EdsNxTTbZ/mJjQHXDFVk2T29U8b/8xvPMU3Ty0iMdRiuoPqvZ6mq/1ZeEMMl+SSfoz DqD2o/3AOCCe4RvpOHFu3yVCkbUdcWc0ASOKDXFft8/6mob/Jjmoic2DNZYbKPGmauDw gL+cC6eLG6harOyRubFNPFfZMcapdW0zfhx04IMP9S0Pu0mAsci3/02mMn3B8MvZsNAV L1ZQ==
X-Gm-Message-State: AN3rC/7yqs/k4s+VHTPWX2E/Yye8NkfQtxC8tz8wmTU8WPvvjTy0b41f HRPQNctxTo6V/gIsjKXqWIGVWf+XMg==
X-Received: by 10.107.189.198 with SMTP id n189mr13259312iof.179.1493423269359;  Fri, 28 Apr 2017 16:47:49 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Fri, 28 Apr 2017 16:47:47 -0700 (PDT)
Received: by 10.79.62.24 with HTTP; Fri, 28 Apr 2017 16:47:47 -0700 (PDT)
In-Reply-To: <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>
From: Robert Raszuk 
Date: Fri, 28 Apr 2017 19:47:47 -0400
X-Google-Sender-Auth: h6tz3zMlhRO_IiL25Trzxcd_hQY
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Fernando Gont 
Cc: 6man WG , Bob Hinden ,  "Ahmed Bashandy (bashandy)" , Brian E Carpenter ,  "Stefano Previdi (sprevidi)" 
Content-Type: multipart/alternative; boundary=94eb2c0c85e47840d0054e42b30f
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 23:50:28 -0000

--94eb2c0c85e47840d0054e42b30f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

"Are not" is present tense while "must not" is future tense.

So this entire debate here is like defining the global speed limit in one
law for all care makers to never exceed 100 just to immediately after
promise to start working on new regulation which tries to relax this and
allow to drive 200+ on selected roads.

Except that cars can drive on all roads ...



On Apr 28, 2017 12:12, "Fernando Gont"  wrote:

> Abmed,
>
> What I was thought when learning English as a second language is that
> "are not" has the same meaning as "must not".
>
> Thanks,
> Fernando
>
>
>
>
> On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:
> > If I were to implement this RFC, what is the meaning of "are not"? wher=
e
> > is unambiguously defined?
> >
> > Ahmed
> >
> > On 4/27/2017 1:54 PM, Brian E Carpenter wrote:
> >> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
> >>> Agreed
> >>>
> >>> rfc2119 has clear definition of the normative language that alleviate=
s
> >>> any ambiguity. So it is always good to use them
> >> iirc the WG already agreed to the editor's choice to follow RFC2460 by
> >> using
> >> plain English rather than RFC2119. And "are not" does not mean the
> >> same thing
> >> as "should not", with or without upper case letters. Personally, I
> >> agree with
> >> "are not" and disagree with "should not", which changes the meaning.
> >>
> >>     Brian
> >>
> >>> Ahmed
> >>>
> >>>
> >>> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
> >>>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden 
> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> After reading through the discussion about this text in Section 4,
> >>>>> I have some new text to propose.  I think this is significantly
> >>>>> improved and should resolve many of the issued raised.
> >>>>>
> >>>>> Changes include separate description of behaviors extension headers
> >>>>> and the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D =
from the first
> >>>>> paragraph.  I removed =E2=80=9Cexamine=E2=80=9D because I am convin=
ced it=E2=80=99s not
> >>>>> sustainable to say a node can=E2=80=99t examine extension given how
> >>>>> widespread this behavior is.  I also removed the reference to
> >>>>> RFC7045 because examine is removed.  RFC7045 is referenced in the
> >>>>> recently updated Security Considerations section.
> >>>>>
> >>>>> I removed the =E2=80=9Cincluding the source and destination nodes=
=E2=80=9D text
> >>>>> from the paragraph on the hop-by-hop options header because I don=
=E2=80=99t
> >>>>> think we need to mention the source, and there is a whole paragraph
> >>>>> describe what happens at the destination node.  I also added the
> >>>>> text about from the first paragraph about reaching the destination
> >>>>> to the hop-by-hop header paragraph.
> >>>>>
> >>>>> I also moved (without change) the =E2=80=9CAt the Destination node.=
..=E2=80=9D text
> >>>>> from the first paragraph to a new third paragraph.  It applies to
> >>>>> all extension headers.
> >>>>>
> >>>>> CURRENT and NEW text below.  Please review and comment.
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>>
> >>>>>     CURRENT
> >>>>>
> >>>>>     With one exception, extension headers are not examined,
> processed,
> >>>>>     inserted, or deleted by any node along a packet's delivery path=
,
> >>>>>     until the packet reaches the node (or each of the set of nodes,
> in
> >>>>>     the case of multicast) identified in the Destination Address
> >>>>> field of
> >>>>>     the IPv6 header.  Note: If an intermediate forwarding node
> >>>>> examines
> >>>>>     an extension header for any reason, it must do so in accordance
> >>>>> with
> >>>>>     the provisions of [RFC7045].  At the Destination node, normal
> >>>>>     demultiplexing on the Next Header field of the IPv6 header
> invokes
> >>>>>     the module to process the first extension header, or the
> >>>>> upper-layer
> >>>>>     header if no extension header is present.  The contents and
> >>>>> semantics
> >>>>>     of each extension header determine whether or not to proceed to
> >>>>> the
> >>>>>     next header.  Therefore, extension headers must be processed
> >>>>> strictly
> >>>>>     in the order they appear in the packet; a receiver must not, fo=
r
> >>>>>     example, scan through a packet looking for a particular kind of
> >>>>>     extension header and process that header prior to processing al=
l
> >>>>>     preceding ones.
> >>>>>
> >>>>>     The exception referred to in the preceding paragraph is the
> >>>>> Hop-by-
> >>>>>     Hop Options header, which carries information that may be
> examined
> >>>>>     and processed by every node along a packet's delivery path,
> >>>>> including
> >>>>>     the source and destination nodes.  The Hop-by-Hop Options heade=
r,
> >>>>>     when present, must immediately follow the IPv6 header.  Its
> >>>>> presence
> >>>>>     is indicated by the value zero in the Next Header field of the
> >>>>> IPv6
> >>>>>     header.
> >>>>>
> >>>>>     NEW
> >>>>>
> >>>>>     Extension headers (except for the Hop-by-Hop Options header)
> >>>>> are not
> >>>> my recommendation is to change =E2=80=9Care not=E2=80=9D with =E2=80=
=9CSHOULD NOT=E2=80=9D.
> >>>>
> >>>> This doesn=E2=80=99t change what the current text assumes while it u=
ses a
> >>>> more formal language.
> >>>>
> >>>> s.
> >>>>
> >>>>
> >>>>>     processed, inserted, or deleted by any node along a packet's
> >>>>> delivery
> >>>>>     path, until the packet reaches the node (or each of the set of
> >>>>> nodes,
> >>>>>     in the case of multicast) identified in the Destination Address
> >>>>> field
> >>>>>     of the IPv6 header.
> >>>>>
> >>>>>     The Hop-by-Hop Options header is not inserted or deleted, but
> >>>>> may be
> >>>>>     examined and processed by every node along a packet's delivery
> >>>>> path,
> >>>>>     until the packet reaches the node (or each of the set of nodes,
> in
> >>>>>     the case of multicast) identified in the Destination Address
> >>>>> field of
> >>>>>     the IPv6 header.  The Hop-by-Hop Options header, when present,
> >>>>> must
> >>>>>     immediately follow the IPv6 header.  Its presence is indicated
> >>>>> by the
> >>>>>     value zero in the Next Header field of the IPv6 header.
> >>>>>
> >>>>>     At the Destination node, normal demultiplexing on the Next Head=
er
> >>>>>     field of the IPv6 header invokes the module to process the firs=
t
> >>>>>     extension header, or the upper-layer header if no extension
> >>>>> header is
> >>>>>     present.  The contents and semantics of each extension header
> >>>>>     determine whether or not to proceed to the next header.
> >>>>> Therefore,
> >>>>>     extension headers must be processed strictly in the order they
> >>>>> appear
> >>>>>     in the packet; a receiver must not, for example, scan through a
> >>>>>     packet looking for a particular kind of extension header and
> >>>>> process
> >>>>>     that header prior to processing all preceding ones.
> >>>>>
> >>>>>     END NEW
> >>>>>
> >>>>> -------------------------------------------------------------------=
-
> >>>>> IETF IPv6 working group mailing list
> >>>>> ipv6@ietf.org
> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> -------------------------------------------------------------------=
-
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> ipv6@ietf.org
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--94eb2c0c85e47840d0054e42b30f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


"Are not" is present tense while "must not=
" is future tense.

So thi=
s entire debate here is like defining the global speed limit in one law for=
 all care makers to never exceed 100 just to immediately after promise to s=
tart working on new regulation which tries to relax this and allow to drive=
 200+ on selected roads.=C2=A0

Except that cars can drive on all roads ...
<=
br>


<=
div class=3D"gmail_quote">On Apr 28, 2017 12:12, "Fernando Gont" =
<fgont@si6net=
works.com> wrote:
Abmed,



What I was thought when learning English as a second language is that

"are not" has the same meaning as "must not".



Thanks,

Fernando









On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:

> If I were to implement this RFC, what is the meaning of "are not&=
quot;? where

> is unambiguously defined?

>

> Ahmed

>

> On 4/27/2017 1:54 PM, Brian E Carpenter wrote:

>> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:

>>> Agreed

>>>

>>> rfc2119 has clear definition of the normative language that al=
leviates

>>> any ambiguity. So it is always good to use them

>> iirc the WG already agreed to the editor's choice to follow RF=
C2460 by

>> using

>> plain English rather than RFC2119. And "are not" does no=
t mean the

>> same thing

>> as "should not", with or without upper case letters. Per=
sonally, I

>> agree with

>> "are not" and disagree with "should not", whic=
h changes the meaning.

>>

>>=C2=A0 =C2=A0 =C2=A0Brian

>>

>>> Ahmed

>>>

>>>

>>> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:

>>>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden <bob.hinden@gmail.com> wrote:

>>>>>

>>>>> Hi,

>>>>>

>>>>> After reading through the discussion about this text i=
n Section 4,

>>>>> I have some new text to propose.=C2=A0 I think this is=
 significantly

>>>>> improved and should resolve many of the issued raised.=


>>>>>

>>>>> Changes include separate description of behaviors exte=
nsion headers

>>>>> and the hop-by-hop option header, remove =E2=80=9Cexam=
ine=E2=80=9D from the first

>>>>> paragraph.=C2=A0 I removed =E2=80=9Cexamine=E2=80=9D b=
ecause I am convinced it=E2=80=99s not

>>>>> sustainable to say a node can=E2=80=99t examine extens=
ion given how

>>>>> widespread this behavior is.=C2=A0 I also removed the =
reference to

>>>>> RFC7045 because examine is removed.=C2=A0 RFC7045 is r=
eferenced in the

>>>>> recently updated Security Considerations section.

>>>>>

>>>>> I removed the =E2=80=9Cincluding the source and destin=
ation nodes=E2=80=9D text

>>>>> from the paragraph on the hop-by-hop options header be=
cause I don=E2=80=99t

>>>>> think we need to mention the source, and there is a wh=
ole paragraph

>>>>> describe what happens at the destination node.=C2=A0 I=
 also added the

>>>>> text about from the first paragraph about reaching the=
 destination

>>>>> to the hop-by-hop header paragraph.

>>>>>

>>>>> I also moved (without change) the =E2=80=9CAt the Dest=
ination node...=E2=80=9D text

>>>>> from the first paragraph to a new third paragraph.=C2=
=A0 It applies to

>>>>> all extension headers.

>>>>>

>>>>> CURRENT and NEW text below.=C2=A0 Please review and co=
mment.

>>>>>

>>>>> Bob

>>>>>

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0CURRENT

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0With one exception, extension heade=
rs are not examined, processed,

>>>>>=C2=A0 =C2=A0 =C2=A0inserted, or deleted by any node al=
ong a packet's delivery path,

>>>>>=C2=A0 =C2=A0 =C2=A0until the packet reaches the node (=
or each of the set of nodes, in

>>>>>=C2=A0 =C2=A0 =C2=A0the case of multicast) identified i=
n the Destination Address

>>>>> field of

>>>>>=C2=A0 =C2=A0 =C2=A0the IPv6 header.=C2=A0 Note: If an =
intermediate forwarding node

>>>>> examines

>>>>>=C2=A0 =C2=A0 =C2=A0an extension header for any reason,=
 it must do so in accordance

>>>>> with

>>>>>=C2=A0 =C2=A0 =C2=A0the provisions of [RFC7045].=C2=A0 =
At the Destination node, normal

>>>>>=C2=A0 =C2=A0 =C2=A0demultiplexing on the Next Header f=
ield of the IPv6 header invokes

>>>>>=C2=A0 =C2=A0 =C2=A0the module to process the first ext=
ension header, or the

>>>>> upper-layer

>>>>>=C2=A0 =C2=A0 =C2=A0header if no extension header is pr=
esent.=C2=A0 The contents and

>>>>> semantics

>>>>>=C2=A0 =C2=A0 =C2=A0of each extension header determine =
whether or not to proceed to

>>>>> the

>>>>>=C2=A0 =C2=A0 =C2=A0next header.=C2=A0 Therefore, exten=
sion headers must be processed

>>>>> strictly

>>>>>=C2=A0 =C2=A0 =C2=A0in the order they appear in the pac=
ket; a receiver must not, for

>>>>>=C2=A0 =C2=A0 =C2=A0example, scan through a packet look=
ing for a particular kind of

>>>>>=C2=A0 =C2=A0 =C2=A0extension header and process that h=
eader prior to processing all

>>>>>=C2=A0 =C2=A0 =C2=A0preceding ones.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0The exception referred to in the pr=
eceding paragraph is the

>>>>> Hop-by-

>>>>>=C2=A0 =C2=A0 =C2=A0Hop Options header, which carries i=
nformation that may be examined

>>>>>=C2=A0 =C2=A0 =C2=A0and processed by every node along a=
 packet's delivery path,

>>>>> including

>>>>>=C2=A0 =C2=A0 =C2=A0the source and destination nodes.=
=C2=A0 The Hop-by-Hop Options header,

>>>>>=C2=A0 =C2=A0 =C2=A0when present, must immediately foll=
ow the IPv6 header.=C2=A0 Its

>>>>> presence

>>>>>=C2=A0 =C2=A0 =C2=A0is indicated by the value zero in t=
he Next Header field of the

>>>>> IPv6

>>>>>=C2=A0 =C2=A0 =C2=A0header.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0NEW

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Extension headers (except for the H=
op-by-Hop Options header)

>>>>> are not

>>>> my recommendation is to change =E2=80=9Care not=E2=80=9D w=
ith =E2=80=9CSHOULD NOT=E2=80=9D.

>>>>

>>>> This doesn=E2=80=99t change what the current text assumes =
while it uses a

>>>> more formal language.

>>>>

>>>> s.

>>>>

>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0processed, inserted, or deleted by =
any node along a packet's

>>>>> delivery

>>>>>=C2=A0 =C2=A0 =C2=A0path, until the packet reaches the =
node (or each of the set of

>>>>> nodes,

>>>>>=C2=A0 =C2=A0 =C2=A0in the case of multicast) identifie=
d in the Destination Address

>>>>> field

>>>>>=C2=A0 =C2=A0 =C2=A0of the IPv6 header.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0The Hop-by-Hop Options header is no=
t inserted or deleted, but

>>>>> may be

>>>>>=C2=A0 =C2=A0 =C2=A0examined and processed by every nod=
e along a packet's delivery

>>>>> path,

>>>>>=C2=A0 =C2=A0 =C2=A0until the packet reaches the node (=
or each of the set of nodes, in

>>>>>=C2=A0 =C2=A0 =C2=A0the case of multicast) identified i=
n the Destination Address

>>>>> field of

>>>>>=C2=A0 =C2=A0 =C2=A0the IPv6 header.=C2=A0 The Hop-by-H=
op Options header, when present,

>>>>> must

>>>>>=C2=A0 =C2=A0 =C2=A0immediately follow the IPv6 header.=
=C2=A0 Its presence is indicated

>>>>> by the

>>>>>=C2=A0 =C2=A0 =C2=A0value zero in the Next Header field=
 of the IPv6 header.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0At the Destination node, normal dem=
ultiplexing on the Next Header

>>>>>=C2=A0 =C2=A0 =C2=A0field of the IPv6 header invokes th=
e module to process the first

>>>>>=C2=A0 =C2=A0 =C2=A0extension header, or the upper-laye=
r header if no extension

>>>>> header is

>>>>>=C2=A0 =C2=A0 =C2=A0present.=C2=A0 The contents and sem=
antics of each extension header

>>>>>=C2=A0 =C2=A0 =C2=A0determine whether or not to proceed=
 to the next header.

>>>>> Therefore,

>>>>>=C2=A0 =C2=A0 =C2=A0extension headers must be processed=
 strictly in the order they

>>>>> appear

>>>>>=C2=A0 =C2=A0 =C2=A0in the packet; a receiver must not,=
 for example, scan through a

>>>>>=C2=A0 =C2=A0 =C2=A0packet looking for a particular kin=
d of extension header and

>>>>> process

>>>>>=C2=A0 =C2=A0 =C2=A0that header prior to processing all=
 preceding ones.

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0END NEW

>>>>>

>>>>> -------------------------------------------------=
-------------------

>>>>> IETF IPv6 working group mailing list

>>>>> ipv6@ietf.org

>>>>> Administrative Requests: https://www.=
ietf.org/mailman/listinfo/ipv6

>>>>> -------------------------------------------------=
-------------------

>>>> -----------------------------------------------------=
---------------

>>>> IETF IPv6 working group mailing list

>>>> ipv6@ietf.org

>>>> Administrative Requests: https://www.ietf=
.org/mailman/listinfo/ipv6

>>>> -----------------------------------------------------=
---------------

>>> ---------------------------------------------------------=
-----------

>>> IETF IPv6 working group mailing list

>>> ipv6@ietf.org

>>> Administrative Requests: https://www.ietf.org=
/mailman/listinfo/ipv6

>>> ---------------------------------------------------------=
-----------

>>>

>

> ------------------------------------------------------------=
--------

> IETF IPv6 working group mailing list

> ipv6@ietf.org

> Administrative Requests: https://www.ietf.org/mailman=
/listinfo/ipv6

> ------------------------------------------------------------=
--------





--

Fernando Gont

SI6 Networks

e-mail: fgont@si6networks.com<=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492









-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---




--94eb2c0c85e47840d0054e42b30f--


From nobody Fri Apr 28 16:52:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7612955A for ; Fri, 28 Apr 2017 16:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 mVi5AEjAqDIs for ; Fri, 28 Apr 2017 16:52:29 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3CE71129A8B for ; Fri, 28 Apr 2017 16:49:29 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id r190so59531337wme.1 for ; Fri, 28 Apr 2017 16:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=ZiWU799Q/woLsmZmd555dgktKxkU0K3J1VjTW8t6h8Q=; b=VODjPFd0NkVNuqtjJmAz5zqzip9pCVdmvR2Mlv08GomzamlyiApEZ6gzw3shxzgIua XlRBZjWD0prMqAgQUU5+iNVFeTroAxPyXTAacJb5shrp8ByPtlWewVo5hsJ3zF9olXXE DJeACq+MJhsTntN0sq5vVEYAWl/CX1TglvfQnkL0ditQrnxZRU9Ivi/u7fByfxoVT6br HnjZFqdalCT2wAF7dxu6iz2xzzYaa9j/6NGKWzKa2BVtfjDkH1hoQn2tfpGORrrfsjVc cfqSnvftCwna7UXLIFDTNIar5SLCwgaOZwLNbKZycuR+7K/TKRv8FhqzgCtphFQ4beeb lZSw==
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:date:cc:to; bh=ZiWU799Q/woLsmZmd555dgktKxkU0K3J1VjTW8t6h8Q=; b=GEM93qKyzaKCkGMWcGkZn3kUXlYDNDMSqyA1LWIfKwr97HkaDjNvrLuZGGglQVWqGC OnxIl6+5u92TfebYKaIIvQz7RDlQBtFGl7DPIcG0iWIZvf/3lkEJPA+D10+m/StmpT1L i0vYUrqsTrW+wK81dfdj0zjCSqZo9zrxcJ4BLSUUukMrrVZuqtv1jzXf6j5JJLCGUQkv k1HUcXX5YpB8nxBDDzNJkOC7H5XjsI19eE46BDLAceDqYBS9h680h/bleguRAYkVuDlF GfyCSRkCB9yEGVCwoU24aOEbQrtmKZbF7Bj1FsUfcNwr+Ax1ECb4WsRqax34wi03BJXC Ny8Q==
X-Gm-Message-State: AN3rC/5uaBUQ8v6nzp7xHY7+EhFocd56ymDY9adQ/gT3jjn7+XXZXanT o0Rg8A/Moqo3fl/OusU=
X-Received: by 10.28.6.199 with SMTP id 190mr335704wmg.10.1493423367470; Fri, 28 Apr 2017 16:49:27 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:59d9:d243:297c:fb03? ([2601:647:4d01:db10:59d9:d243:297c:fb03]) by smtp.gmail.com with ESMTPSA id h199sm873899wme.4.2017.04.28.16.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 16:49:26 -0700 (PDT)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_117EFAF4-F4BF-416D-921A-FB8B921EE0DA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: 
Message-Id: <3C36596A-2F6E-4747-8863-D950253C1715@gmail.com>
Date: Fri, 28 Apr 2017 16:49:21 -0700
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 23:52:31 -0000

--Apple-Mail=_117EFAF4-F4BF-416D-921A-FB8B921EE0DA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I published the -11 version of 6man working group draft of rfc2460bis.  =
Links below.

The changes in this draft are:

      In Section 4.5 added clarification noting that some fields in
      the IPv6 header may also vary across the fragments being
      reassembled and that other specifications may provide
      additional instructions for how they should be reassembled.
      For example, Section 5.3 of [RFC3168].

      In Section 4 restructured text including separated behaviors
      of extension headers and the hop-by-hop option header,
      removed "examine" from first paragraph about extension
      headers, and removed reference to RFC7045 because "examine"
      was removed (RFC7045 is referenced in Security
      Considerations).  Also removed "including the source and
      destination nodes" from paragraph about the hop-by-hop
      options header.

      Revised Section 4.8 to make it closer to the update done by
      RFC6554 that updated it and reordered the paragraphs.

      Reordered items in Appendix B "Changes Since RFC2460=E2=80=9D to =
match
      the order of the document.

      Editorial changes.

A diff from the -10 version can be found at:

 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-11

Please review the changes.

This is part of the project to move the core IPv6 specifications to =
Internet Standard.

Thanks,
Bob

p.s. After submitting this version, I noticed I inadvertently left an =
old paragraph in the start of Section 4.8.  I will fix this in the next =
version.  Please ignore it.




> A new version of I-D, draft-ietf-6man-rfc2460bis-11.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>=20
> Name:		draft-ietf-6man-rfc2460bis
> Revision:	11
> Title:		Internet Protocol, Version 6 (IPv6) =
Specification
> Document date:	2017-04-28
> Group:		6man
> Pages:		45
> URL:            =
https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc2460bis-11.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> Htmlized:       =
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-11
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-11
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-11
>=20
> Abstract:
>   This document specifies version 6 of the Internet Protocol (IPv6).
>   It obsoletes RFC2460
>=20

--Apple-Mail=_117EFAF4-F4BF-416D-921A-FB8B921EE0DA
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-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJZA9UCAAoJEK7rdBF357uojmgH/jp7pHZRXH18TVy75ivI9aoJ
KinpMw6SMNhkNjwkmpT5yuxVxZvBUqY27B6kjYqxp+h0Z07OYGv3eB9et8muqHj+
JXIb504ggS6n3mK6KfSem+Xntpy0/DCTmxOnMFxnmM5rd2cf3KSVQmISRx3Hwak5
k8HDAeQ6YPzOl1yOGFPyuISi6ZwX6yY376qmMntmOwDXRWQ9+DGQhnkZ/J5LzhBQ
AWdJf8vqIUYwIFbecduJlhcB5J4VHWLycLUfOaRO98W3l3lMWhH5h+XJCaayzJf5
uDvsy53hQD6aNo/tDRo+I1AWg9gx3hxwVAQ5B4dDc7ssZiA7LdKOwe+xMN0BQW4=
=9FHW
-----END PGP SIGNATURE-----

--Apple-Mail=_117EFAF4-F4BF-416D-921A-FB8B921EE0DA--


From nobody Fri Apr 28 17:00:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401A7129AA1 for ; Fri, 28 Apr 2017 17:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 RmIVMEqjs2bJ for ; Fri, 28 Apr 2017 17:00:10 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 04304129ABE for ; Fri, 28 Apr 2017 16:57:46 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id o3so16404877pgn.2 for ; Fri, 28 Apr 2017 16:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wNZ/iBmBgI6uXiUxwYbsvk9BYP6Y71E3o1z46EQ0yVY=; b=HKIpslRI85VtyGGBAb34pL/1enkHm1mzsOXKyQB+PDqpFq2/zflXxWjvIRosIKvvXE Ykk494taRyAa1yOzL0JogOzxsEXelNJjGLTJZv1+W9U8mpHJnR/q9VEPpJI5Jq5uaYG+ 0wknwd/+rZ1y2HXbMRR36OE7/XRydrnm/KDsalW8up6Dlue1QOlkrRxcvBrhJ7VYGblK k5oL9sZ6/02DkuaMq3qzWz1+LPbJraxeron8FjjnrOcFG33s2WJcpVjCQLG0yMJOOJcY GXCYfxGMN6KA6WIxNefgv5mIb0VnYNZy6R03k36mfq6ZrJ9Ty7sXXr0C5s6iQMQJJGgr yDBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wNZ/iBmBgI6uXiUxwYbsvk9BYP6Y71E3o1z46EQ0yVY=; b=uQmA2PgsX2svg6RWWW7n68BZYQG/G3etVAFV8wdBwugBbGPu9IBI+Bkq75R3u2txNW 4sH2guuJscGyyC7zbWKyWFFVaeeOcPjoSD1axdA2fOJnqU/rpU3Hjlc9V5xTwZ8qvbMB eld07WXJtrSTxFwVokhfbMll3EbIYIPeYx57IDETXf1XiAXgTuzDipX+fQiHalSBHvSM LXYogMoyPoVBWFRrvafViXRDZVFdffydGDOPSTuKz9jpgxd+9LN82a+nEqtkudyIzAa1 eD2qOrnI7bamwSFgM5HSiau9ZnjQrw6OGh/9uVDb7XzZAQhzZZGJr3WYihh5wijKCvMk a8sQ==
X-Gm-Message-State: AN3rC/6nTKcq785jAtcNeX6/XgUREzCrSZ/dsNtMVoQ/cq/5nSo8uM++ VYlFKmtvPpKR7Q==
X-Received: by 10.99.122.66 with SMTP id j2mr14148342pgn.129.1493423865306; Fri, 28 Apr 2017 16:57:45 -0700 (PDT)
Received: from [192.168.1.22] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id s3sm10100841pgn.29.2017.04.28.16.57.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 16:57:44 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Proposed revised Extension Header text for rfc2460bis
From: Fred Baker 
In-Reply-To: 
Date: Fri, 28 Apr 2017 16:57:42 -0700
Cc: Fernando Gont , Bob Hinden ,  6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BB15813-7F8C-44FF-8C4E-1BCE811CC1CD@gmail.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 00:00:15 -0000

> On Apr 28, 2017, at 4:47 PM, Robert Raszuk  wrote:
>=20
> "Are not" is present tense while "must not" is future tense.

You might be interested in the comment in =
https://www.usingenglish.com/forum/threads/136704-Past-and-future-tense-of=
-must. "Must" has no past, and no future, tense, per this conversation.=20=


> So this entire debate here is like defining the global speed limit in =
one law for all care makers to never exceed 100 just to immediately =
after promise to start working on new regulation which tries to relax =
this and allow to drive 200+ on selected roads.=20
>=20
> Except that cars can drive on all roads ...
>=20
>=20
>=20
> On Apr 28, 2017 12:12, "Fernando Gont"  wrote:
> Abmed,
>=20
> What I was thought when learning English as a second language is that
> "are not" has the same meaning as "must not".
>=20
> Thanks,
> Fernando
>=20
>=20
>=20
>=20
> On 04/28/2017 03:47 PM, Ahmed Bashandy (bashandy) wrote:
> > If I were to implement this RFC, what is the meaning of "are not"? =
where
> > is unambiguously defined?
> >
> > Ahmed
> >
> > On 4/27/2017 1:54 PM, Brian E Carpenter wrote:
> >> On 28/04/2017 07:58, Ahmed Bashandy (bashandy) wrote:
> >>> Agreed
> >>>
> >>> rfc2119 has clear definition of the normative language that =
alleviates
> >>> any ambiguity. So it is always good to use them
> >> iirc the WG already agreed to the editor's choice to follow RFC2460 =
by
> >> using
> >> plain English rather than RFC2119. And "are not" does not mean the
> >> same thing
> >> as "should not", with or without upper case letters. Personally, I
> >> agree with
> >> "are not" and disagree with "should not", which changes the =
meaning.
> >>
> >>     Brian
> >>
> >>> Ahmed
> >>>
> >>>
> >>> On 4/27/2017 5:04 AM, Stefano Previdi (sprevidi) wrote:
> >>>>> On Apr 25, 2017, at 12:52 AM, Bob Hinden  =
wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> After reading through the discussion about this text in Section =
4,
> >>>>> I have some new text to propose.  I think this is significantly
> >>>>> improved and should resolve many of the issued raised.
> >>>>>
> >>>>> Changes include separate description of behaviors extension =
headers
> >>>>> and the hop-by-hop option header, remove =E2=80=9Cexamine=E2=80=9D=
 from the first
> >>>>> paragraph.  I removed =E2=80=9Cexamine=E2=80=9D because I am =
convinced it=E2=80=99s not
> >>>>> sustainable to say a node can=E2=80=99t examine extension given =
how
> >>>>> widespread this behavior is.  I also removed the reference to
> >>>>> RFC7045 because examine is removed.  RFC7045 is referenced in =
the
> >>>>> recently updated Security Considerations section.
> >>>>>
> >>>>> I removed the =E2=80=9Cincluding the source and destination =
nodes=E2=80=9D text
> >>>>> from the paragraph on the hop-by-hop options header because I =
don=E2=80=99t
> >>>>> think we need to mention the source, and there is a whole =
paragraph
> >>>>> describe what happens at the destination node.  I also added the
> >>>>> text about from the first paragraph about reaching the =
destination
> >>>>> to the hop-by-hop header paragraph.
> >>>>>
> >>>>> I also moved (without change) the =E2=80=9CAt the Destination =
node...=E2=80=9D text
> >>>>> from the first paragraph to a new third paragraph.  It applies =
to
> >>>>> all extension headers.
> >>>>>
> >>>>> CURRENT and NEW text below.  Please review and comment.
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>>
> >>>>>     CURRENT
> >>>>>
> >>>>>     With one exception, extension headers are not examined, =
processed,
> >>>>>     inserted, or deleted by any node along a packet's delivery =
path,
> >>>>>     until the packet reaches the node (or each of the set of =
nodes, in
> >>>>>     the case of multicast) identified in the Destination Address
> >>>>> field of
> >>>>>     the IPv6 header.  Note: If an intermediate forwarding node
> >>>>> examines
> >>>>>     an extension header for any reason, it must do so in =
accordance
> >>>>> with
> >>>>>     the provisions of [RFC7045].  At the Destination node, =
normal
> >>>>>     demultiplexing on the Next Header field of the IPv6 header =
invokes
> >>>>>     the module to process the first extension header, or the
> >>>>> upper-layer
> >>>>>     header if no extension header is present.  The contents and
> >>>>> semantics
> >>>>>     of each extension header determine whether or not to proceed =
to
> >>>>> the
> >>>>>     next header.  Therefore, extension headers must be processed
> >>>>> strictly
> >>>>>     in the order they appear in the packet; a receiver must not, =
for
> >>>>>     example, scan through a packet looking for a particular kind =
of
> >>>>>     extension header and process that header prior to processing =
all
> >>>>>     preceding ones.
> >>>>>
> >>>>>     The exception referred to in the preceding paragraph is the
> >>>>> Hop-by-
> >>>>>     Hop Options header, which carries information that may be =
examined
> >>>>>     and processed by every node along a packet's delivery path,
> >>>>> including
> >>>>>     the source and destination nodes.  The Hop-by-Hop Options =
header,
> >>>>>     when present, must immediately follow the IPv6 header.  Its
> >>>>> presence
> >>>>>     is indicated by the value zero in the Next Header field of =
the
> >>>>> IPv6
> >>>>>     header.
> >>>>>
> >>>>>     NEW
> >>>>>
> >>>>>     Extension headers (except for the Hop-by-Hop Options header)
> >>>>> are not
> >>>> my recommendation is to change =E2=80=9Care not=E2=80=9D with =
=E2=80=9CSHOULD NOT=E2=80=9D.
> >>>>
> >>>> This doesn=E2=80=99t change what the current text assumes while =
it uses a
> >>>> more formal language.
> >>>>
> >>>> s.
> >>>>
> >>>>
> >>>>>     processed, inserted, or deleted by any node along a packet's
> >>>>> delivery
> >>>>>     path, until the packet reaches the node (or each of the set =
of
> >>>>> nodes,
> >>>>>     in the case of multicast) identified in the Destination =
Address
> >>>>> field
> >>>>>     of the IPv6 header.
> >>>>>
> >>>>>     The Hop-by-Hop Options header is not inserted or deleted, =
but
> >>>>> may be
> >>>>>     examined and processed by every node along a packet's =
delivery
> >>>>> path,
> >>>>>     until the packet reaches the node (or each of the set of =
nodes, in
> >>>>>     the case of multicast) identified in the Destination Address
> >>>>> field of
> >>>>>     the IPv6 header.  The Hop-by-Hop Options header, when =
present,
> >>>>> must
> >>>>>     immediately follow the IPv6 header.  Its presence is =
indicated
> >>>>> by the
> >>>>>     value zero in the Next Header field of the IPv6 header.
> >>>>>
> >>>>>     At the Destination node, normal demultiplexing on the Next =
Header
> >>>>>     field of the IPv6 header invokes the module to process the =
first
> >>>>>     extension header, or the upper-layer header if no extension
> >>>>> header is
> >>>>>     present.  The contents and semantics of each extension =
header
> >>>>>     determine whether or not to proceed to the next header.
> >>>>> Therefore,
> >>>>>     extension headers must be processed strictly in the order =
they
> >>>>> appear
> >>>>>     in the packet; a receiver must not, for example, scan =
through a
> >>>>>     packet looking for a particular kind of extension header and
> >>>>> process
> >>>>>     that header prior to processing all preceding ones.
> >>>>>
> >>>>>     END NEW
> >>>>>
> >>>>> =
--------------------------------------------------------------------
> >>>>> IETF IPv6 working group mailing list
> >>>>> ipv6@ietf.org
> >>>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> =
--------------------------------------------------------------------
> >>>> =
--------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> ipv6@ietf.org
> >>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
> >>>> =
--------------------------------------------------------------------
> >>> =
--------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
> >>> =
--------------------------------------------------------------------
> >>>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>=20
>=20
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>=20
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Fri Apr 28 18:17:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C72129490 for ; Fri, 28 Apr 2017 18:17:34 -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_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 2sHJSM0b2_af for ; Fri, 28 Apr 2017 18:17:32 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 C3FEB129576 for ; Fri, 28 Apr 2017 18:15:21 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id y33so62530673qta.2 for ; Fri, 28 Apr 2017 18:15:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QVRYUtja2qdM4vp1e0GwXdhZHK4Dgl4V1asc0fmzkE8=; b=P/5Y/C3ySEjEJmivgib18sZ5mXsjjMN3uYCIy4JSFML3wJBptBaJDo3YpnPGejc5k3 wO7sF+hqEmGGLe0SyHcLYfrEtpu49zSjxPeK4/vkxQxmMGkVG7/71rRDbxkzKVl8EflI 2/wlRJ5qUGIsQIWZXiuMydviXMCqMRbUFTynIpA6b4ljjIoXzkPW1NQ1Lr/+SYukFDpS YMG1BvM124iNQ6VZW+EMqE7N97Iu06olcmL3hw0TKSaD5Zm1Ib6E/NcXTwei3hyviBZo 4mBx+Bm6Y6YUzqBOUutyRGRP4b86Xzpjo4BOdNdxedCGrus6pdu+5svIxBuEcTDqhpbT JOtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QVRYUtja2qdM4vp1e0GwXdhZHK4Dgl4V1asc0fmzkE8=; b=GyFRT9wo31JjKkwC8tUzCYS2Jt/sAx3oPXoKsS0MyX5cW1cUjmla3cg82gG93IJXH3 GB8UJTui/YyGa+qX6Rr8lTuRioRHrzFUzrOqCT028nePX0XqUIxdYrNqGWg/1aNORju0 Lj0x9qBEvMSMhZmXkeAoR5SaPurlKVgPoZYqRg/nvG8ggrSAXaAEp14ZNHYFUTDD4HyV h9v8JuFOAf5wloVHSh6yAOtapMbHERPGZ+GWeh30IsycbWgd3BM0s9ai+ehP/RHuOyAJ 2KqCr/oE/0M5gUjNSV/mdrk2OdJXRWvQa/o6Al6R7gAMFMSUDHwSNJozSPvtEACXrTi0 BJaA==
X-Gm-Message-State: AN3rC/4eWEOezvOwII9nsjweIV4jEtTZ3I8L73/j/0FgxPJAqCNU4hXK ljDIqvNdAsWrEyAhVns5IyeS6wYOHQ==
X-Received: by 10.200.47.147 with SMTP id l19mr12030892qta.286.1493428520781;  Fri, 28 Apr 2017 18:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.166.130 with HTTP; Fri, 28 Apr 2017 18:15:20 -0700 (PDT)
Received: by 10.55.166.130 with HTTP; Fri, 28 Apr 2017 18:15:20 -0700 (PDT)
In-Reply-To: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com> 
From: Suresh Krishnan 
Date: Fri, 28 Apr 2017 21:15:20 -0400
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Robert Raszuk 
Cc: Bob Hinden , IPv6 List ,  Fernando Gont 
Content-Type: multipart/alternative; boundary=001a113d3f487a8e00054e43ecb7
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 01:17:34 -0000

--001a113d3f487a8e00054e43ecb7
Content-Type: text/plain; charset=UTF-8

Hi Robert,



On Apr 28, 2017 7:50 PM, "Robert Raszuk"  wrote:

"Are not" is present tense while "must not" is future tense.


Personally, I am perfectly fine with the text staying as "are not". "must
not" was a suggestion upthread from Ahmed, Fernando, and Jinmei.


So this entire debate here is like defining the global speed limit in one
law for all care makers to never exceed 100 just to immediately after
promise to start working on new regulation which tries to relax this and
allow to drive 200+ on selected roads.


I think this analogy is not fitting. We are not talking about speeds or
magnitude here. This case is more like: There are billion cars on the roads
today that have drivers. You can drive a car on these roads without a
driver when you can prove your autonomous car is safe.

Thanks
Suresh

--001a113d3f487a8e00054e43ecb7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Robert,=C2=A0



On Apr 28, 2017 7:50 =
PM, "Robert Raszuk" <robert@raszuk.net> wrote:
"Are not&qu=
ot; is present tense while "must not" is future tense.

Per=
sonally, I am perfectly fine with the text staying as "are not". =
"must not" was a suggestion upthread from Ahmed, Fernando, and Ji=
nmei.=C2=A0


So this entire debate here is like defining the global speed limit in on=
e law for all care makers to never exceed 100 just to immediately after pro=
mise to start working on new regulation which tries to relax this and allow=
 to drive 200+ on selected roads.=C2=A0
=


I think this analogy is not fitting. We are not talking about speeds or m=
agnitude here. This case is more like: There are billion cars on the roads =
today that have drivers. You can drive a car on these roads without a drive=
r when you can prove your autonomous car is safe.=C2=A0

Thanks=C2=A0
Suresh<=
/div>


--001a113d3f487a8e00054e43ecb7--


From nobody Fri Apr 28 18:38:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5126F129A8D for ; Fri, 28 Apr 2017 18:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 W0vLvWprNdQV for ; Fri, 28 Apr 2017 18:38:24 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 07F56129A9A for ; Fri, 28 Apr 2017 18:36:00 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id r16so80790880ioi.2 for ; Fri, 28 Apr 2017 18:35:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7j0YPQOyRHEgDWqjdR4n6XprERy448wsJ81dDAdQWT8=; b=Gwg3vhB6k7njMLmqz1IhroB7iOajWv81vMi6dzB2ZFhR01YYRse+z3pAfb8tSpp472 J83p/IeNk6eRnhqIECwfitKZ6LHpIpdWJzKcy3urVoCpkEq9nLG83lEJR7KgRiHsoiRo Fh+FeLQj1pFhPd56zCBX3W23ZlggeQe19/Ut8jpiRlZbANIYlzjw5XjripGE1+5NstcK mixCDF76LqufAHWvPzLFwT2jvyNFhPnjWuWakSPeu2pXPyaHuU80G013ao8BdBbXGSVo fvWYtf6kzQqB/lCpDAJssCb9RZqvAXR0p+U5uPfPpe13MEylMVfynD1rx7TOyW5bnqaM Y3FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7j0YPQOyRHEgDWqjdR4n6XprERy448wsJ81dDAdQWT8=; b=fXmRkIzJt99z+pQkyuI1d9yDKDH4TPU5D7BMP+BVDNoVndkmnE1LSd7O5v+ZeM9y1z I5K0gT/qPPd5ubCYkbqIVR+bi1LEWFUJDqpr58nJ+Yn/0pYUGDAYo4Rxy4Di+lO4cgH2 jggwWrdrPuareWXclP3t52G0UDTrNYCKMzy/zxiLuLeXilcWMlSIXIWgeTsJ5Zot6HoN HgRXo5euDgiN2Z78GcNvMXdXEXjFeGrUqvnLmvMdpEg83LO6okUEtDui7uByAi7z2eNm j4W0o6C8XnhJ9qAIGbNQ+mmldHs1L6Z//WkVG+By2sQJy4gMbw/n9nC/l9Fe/EVDCliP ybXg==
X-Gm-Message-State: AN3rC/42NsnfSYSbyPKxCh/JQLFDYvQx94IkgQ9idkbTMRHvx+Sh9EIX pMIrTJABsYaNFxiJL5Y0ZZ3N7K2BBA==
X-Received: by 10.107.189.198 with SMTP id n189mr13522050iof.179.1493429759357;  Fri, 28 Apr 2017 18:35:59 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Fri, 28 Apr 2017 18:35:58 -0700 (PDT)
Received: by 10.79.62.24 with HTTP; Fri, 28 Apr 2017 18:35:58 -0700 (PDT)
In-Reply-To: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>  
From: Robert Raszuk 
Date: Fri, 28 Apr 2017 21:35:58 -0400
X-Google-Sender-Auth: 9wRmgNwIO2WXNbKyRqvmoOQ4njs
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Suresh Krishnan 
Cc: 6man WG , Bob Hinden ,  Fernando Gont 
Content-Type: multipart/alternative; boundary=94eb2c0c85e44dc0ba054e443614
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 01:38:27 -0000

--94eb2c0c85e44dc0ba054e443614
Content-Type: text/plain; charset=UTF-8

Hi Suresh,

I am not quite seeing your comparison as well I admit maybe my analogy wad
not that perfect too in describing the situation.

Let me try again ...

Yes there are billions of cars on the roads today. However this debate is
not about putting them into any risk of collisions with those new ones.

Instead we are talking about adding a gps to selected drivers which can
influence directing cars left or right and what is even more significant
only at selected and upgraded intersections (read dst address in ipv6 top
header only) .

I truly do not understand this entire resistance from innovation. Perhaps
the crux of it is that it is misunderstood by number of folks or that most
folks just did not have time to understand last few years of segment
routing work.

Adding overpass or underpass at specific intersections to subset of cars is
in no way to cause any danger to existing traffic.

No one here will or even can to ask for special handling of cars on non
upgraded yet intersections to support it.

Cheers,
R.


On Apr 28, 2017 21:15, "Suresh Krishnan"  wrote:

Hi Robert,



On Apr 28, 2017 7:50 PM, "Robert Raszuk"  wrote:

"Are not" is present tense while "must not" is future tense.


Personally, I am perfectly fine with the text staying as "are not". "must
not" was a suggestion upthread from Ahmed, Fernando, and Jinmei.


So this entire debate here is like defining the global speed limit in one
law for all care makers to never exceed 100 just to immediately after
promise to start working on new regulation which tries to relax this and
allow to drive 200+ on selected roads.


I think this analogy is not fitting. We are not talking about speeds or
magnitude here. This case is more like: There are billion cars on the roads
today that have drivers. You can drive a car on these roads without a
driver when you can prove your autonomous car is safe.

Thanks
Suresh

--94eb2c0c85e44dc0ba054e443614
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Suresh,

I=
 am not quite seeing your comparison as well I admit maybe my analogy wad n=
ot that perfect too in describing the situation.
Let me try again ...

Yes there are billions of cars on the roads today. Ho=
wever this debate is not about putting them into any risk of collisions wit=
h those new ones.

Instea=
d we are talking about adding a gps to selected drivers which can influence=
 directing cars left or right and what is even more significant only at sel=
ected and upgraded intersections (read dst address in ipv6 top header only)=
 .

I truly do not unders=
tand this entire resistance from innovation. Perhaps the crux of it is that=
 it is misunderstood by number of folks or that most folks just did not hav=
e time to understand last few years of segment routing work.

Adding overpass or underpass at speci=
fic intersections to subset of cars is in no way to cause any danger to exi=
sting traffic.

No one he=
re will or even can to ask for special handling of cars on non upgraded yet=
 intersections to support it.

Cheers,
R.


On Apr 28, 2017 21:15, "S=
uresh Krishnan" <sures=
h.krishnan@gmail.com> wrote:
Hi Robert,=C2=A0



On Apr 28, 2017 7:50 PM, "Robert Raszuk" <robert@raszuk.net&g=
t; wrote:
"Are not" is present t=
ense while "must not" is future tense.

Personally, I=
 am perfectly fine with the text staying as "are not". "must=
 not" was a suggestion upthread from Ahmed, Fernando, and Jinmei.=C2=
=A0


So this entire debate here is like=
 defining the global speed limit in one law for all care makers to never ex=
ceed 100 just to immediately after promise to start working on new regulati=
on which tries to relax this and allow to drive 200+ on selected roads.=C2=
=A0

I think this analogy is not =
fitting. We are not talking about speeds or magnitude here. This case is mo=
re like: There are billion cars on the roads today that have drivers. You c=
an drive a car on these roads without a driver when you can prove your auto=
nomous car is safe.=C2=A0

Thanks=C2=A0
Suresh
<=
/font>






--94eb2c0c85e44dc0ba054e443614--


From nobody Fri Apr 28 20:00:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862F8129572 for ; Fri, 28 Apr 2017 20:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 dwvHCL49Q24s for ; Fri, 28 Apr 2017 20:00:11 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 98471129B9D for ; Fri, 28 Apr 2017 19:57:50 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id t7so22862713pgt.3 for ; Fri, 28 Apr 2017 19:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wmDAWAexUzHCYj5HJ5WlWcnRzDeOezJ0L8ChnznSpz4=; b=n/GSoDGMgYqACoMIt+X4Yp1t2Q3K88jQqk5UVgmDo7hOPNiLhodlcyVkFs0sjkAF1B ZLfqU3auN5IYpJDE8LBZuCkjYWHr2FdRLkaddWEjSjLXQR1p73xH+O8EWBHX3RhGOFQ8 T2gkps8lwC3jLLlddROAFxPCZ0K737i5vRwnKhgyisHm9h9VDATG/Lz+2LUY8293kQEE Dhu1I04zAHHWL+uNNH8fA/isAL9byXbUGcAaWnX2oOfMg8szx3XPGXRKa0zIHyaRrixt /B4rpXnf49W42gOJlhIkP9QQmgQqQCK/RhbJwJwDmzyhhh9/9f7dHDoIlt2VSxPUB2B+ Dk9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wmDAWAexUzHCYj5HJ5WlWcnRzDeOezJ0L8ChnznSpz4=; b=Z54CcNvJY5KYOZG0MngGUL4GM6yYx97oOlK2D7guijsMo4B/lpP4WBlEZRx0OCZKh/ xFt8G/ApYh/2/2te4ilrg4VwOy2BfDdMy9nJfXn1cl/CHaiZjQaFrAKezMnmgTDAeUk3 Uzk3M9/6X5BDijqirUeiwbfvHHckPnK54AwXLwddDxSnEMfWi6Z2QqzdalUyjXRaGZ4B F4GbDN2Hk1hqyNkdw+vY9L9QK2KScBy9Z7/F/uVUe/DsLocl426Tagv+/UIJ6OAztMB2 q1EFyO/yIr83/a2HaMMPAFt2ZHV4VsHJo273NPqgGMEDiZRGTdmzJSez7SaQpNCBzuA9 mvJA==
X-Gm-Message-State: AN3rC/6LpstLt6iz74rrx4c0nTV92FyU7oui1RZbZAoTvRunf2xKfyzu pCYXWIpYEtmaAGjU
X-Received: by 10.84.129.67 with SMTP id 61mr19455130plb.150.1493434670112; Fri, 28 Apr 2017 19:57:50 -0700 (PDT)
Received: from [192.168.178.21] ([118.149.105.110]) by smtp.gmail.com with ESMTPSA id k198sm10551024pga.54.2017.04.28.19.57.47 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 19:57:49 -0700 (PDT)
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: ipv6@ietf.org
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>
Date: Sat, 29 Apr 2017 14:57:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 03:00:12 -0000

Robert,

...
> I truly do not understand this entire resistance from innovation.

There isn't. Once again: when we have 2460bis approved for full Internet
Standard, thus defining Internet-wide interoperability, we can start a serious
discussion of next steps for domain-local extensibility. I'll be happy to
help improve draft-voyer-6man-extension-header-insertion, or whatever else
seems like the best way forward.

It isn't as if we have no domain-local features already; diffserv is
defined as domain-local and so of course are ULAs.

     Brian


From nobody Sat Apr 29 03:28:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EE6126DFF for ; Sat, 29 Apr 2017 03:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level: 
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RczJl76aWh0I for ; Sat, 29 Apr 2017 03:28:18 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 3396C126C22 for ; Sat, 29 Apr 2017 03:28:06 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id 70so54836097ita.0 for ; Sat, 29 Apr 2017 03:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XTsjqlYRW6QZvIu6ocWfRG0wQsYD0lxyoV3g0Jyjegg=; b=QSHg4q/6FREnzrqT1WtQn1+GV5/RwCV0wHEq79gOBSpxiDTKliCpwwebHwEbKFraxT AUx0FuJZ6S22kePmDMqnmt7scNjlKp3nbt9GDSi3Qe0RZ14IqsdZLHVjVhwk9Fmz7/Jz WmodTX1etXg/u9uTRWiiAMwMmMpA4+s1XesDV3pgqHTSIeKTae2AbB4FicvYvxYDCE0l EwtXwPApp0+6BYPZ0jVJq5OCDb/CqSlh+lHgPdNkhapBcXgecJXGUovnsydGbUhgstwL BPjJRVKgXR8dHbzi4fccMLzQT9ZiaOk9KzAUJ39/2eh2qSWyd/9J/uGchr7gSXAuGfgj mTzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XTsjqlYRW6QZvIu6ocWfRG0wQsYD0lxyoV3g0Jyjegg=; b=iLWgmvVmWSyeVqZzQFEp73JB80SGDayuGJt0jh0B80Zo98mYhUP8xpwrXB5Rpn25Jr CPtBZp99zjUfo9S+6EnqtaJv4WH0te9du8e8Jj36ur8X/eDj5oSHP7FZQoN+usrKqU06 ZvHA4emNr9W5RMVUjZA7/BGesqmWqJi18wo6YymH2g54dii405pT/Trcc6UZGBYBKN1V IxxkAhitNzSz3+AmQH95E+BzHEjlDc54Xu6mT/F3dZIKrYqHiFdw6HFJYEl3UDttDcG3 38vZ7OZdPiiFz9tItM9yGUonNl0eZaGJMu6QbCFo7YTEwJuGjVvbpVM0k5DPi6tSiSsv hlsQ==
X-Gm-Message-State: AN3rC/5wmljLk/4LVCWaIS+ozXO4hS4gItOeLI9sbtPqbnE6e+0mm7zY U7NkPSnL4cYcBpQrk/AUwj3R3t/qCA==
X-Received: by 10.36.28.74 with SMTP id c71mr858808itc.18.1493461685540; Sat, 29 Apr 2017 03:28:05 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Sat, 29 Apr 2017 03:28:03 -0700 (PDT)
Received: by 10.79.62.24 with HTTP; Sat, 29 Apr 2017 03:28:03 -0700 (PDT)
In-Reply-To: <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>
From: Robert Raszuk 
Date: Sat, 29 Apr 2017 06:28:03 -0400
X-Google-Sender-Auth: Qn_vgWCwT78bm73P3faMaFNHba4
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: Brian E Carpenter 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary=001a1140574e40c472054e4ba561
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 10:28:20 -0000

--001a1140574e40c472054e4ba561
Content-Type: text/plain; charset=UTF-8

The point is that SRv6 with SRH actions to me should be full internet-wide
standard and not domain-local one.

//R.

PS. Just look at current proprietary SD-WANs or interoperable IETF LISP.
They are all - by design - Internet wide. So it is in general possible to
innovate at Internet scale. Why revised in 2017 rfc2460 just does not
accomodate the current needs and latest developments i IPv6 space ?


On Apr 28, 2017 23:00, "Brian E Carpenter" 
wrote:

Robert,

...
> I truly do not understand this entire resistance from innovation.

There isn't. Once again: when we have 2460bis approved for full Internet
Standard, thus defining Internet-wide interoperability, we can start a
serious
discussion of next steps for domain-local extensibility. I'll be happy to
help improve draft-voyer-6man-extension-header-insertion, or whatever else
seems like the best way forward.

It isn't as if we have no domain-local features already; diffserv is
defined as domain-local and so of course are ULAs.

     Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--001a1140574e40c472054e4ba561
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The point is that SRv6 with SRH actions to me should=
 be full internet-wide standard and not domain-local one.
=

//R.

PS. Just =
look at current proprietary SD-WANs or interoperable IETF LISP. They are al=
l - by design - Internet wide. So it is in general possible to innovate at =
Internet scale. Why revised in 2017 rfc2460 just does not accomodate the cu=
rrent needs and latest developments i IPv6 space ?
<=
br>

O=
n Apr 28, 2017 23:00, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
Robert,



...


> I truly do not understand this entire resis=
tance from innovation.




There isn't. Once again: when we have 2460bis approved for full I=
nternet

Standard, thus defining Internet-wide interoperability, we can start a seri=
ous

discussion of next steps for domain-local extensibility. I'll be happy =
to

help improve draft-voyer-6man-extension-header-insertion, or whatever =
else

seems like the best way forward.



It isn't as if we have no domain-local features already; diffserv is
defined as domain-local and so of course are ULAs.



=C2=A0 =C2=A0 =C2=A0Brian




-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--001a1140574e40c472054e4ba561--


From nobody Sat Apr 29 13:47:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7AB1267BB for ; Sat, 29 Apr 2017 13:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.622
X-Spam-Level: 
X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Vl19JokVNlYg for ; Sat, 29 Apr 2017 13:47:46 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F5B129A9F for ; Sat, 29 Apr 2017 13:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=460; q=dns/txt; s=iport; t=1493498737; x=1494708337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3OAPPBOc13Y+eNNDK8yw4tcWbg7eBQ5939qQS53oG/c=; b=cs4YNLNHL7A51oQ1+BLzWCWnDLw8P28p4GbCfoDnqGGEl888INUfNhr0 j2THgJCm9P4EEJdHyW+HtVBHwd8zn5i/56R7pMQHe1JCpA0w0/NGXLs80 UHoKFOaQKk7k2egvSyLYdTu+CVQtTh2z9rdZQyfjuFg1PdM7pzQxUgZcP c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAB/+gRZ/4kNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbQeNeZFLlW2CD4YkAoQ3PxgBAgEBAQEBAQFrKIUVAQEBAQI?= =?us-ascii?q?BeQULAgEIGC4yJQIEDgWKFwixY4sMAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZfg?= =?us-ascii?q?gmCcIgUgjEBBJ1TAZMQgWoBj3OULAEfOIEKbxVWAYReHIFjdYcagQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.37,393,1488844800"; d="scan'208";a="419749542"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2017 20:45:36 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3TKjaPJ013664 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 29 Apr 2017 20:45:36 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 29 Apr 2017 16:45:35 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Sat, 29 Apr 2017 16:45:35 -0400
From: "Stefano Previdi (sprevidi)" 
To: Nick Hilliard 
CC: Fernando Gont , Brian E Carpenter , "Ahmed Bashandy (bashandy)" , Bob Hinden , IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSv5CqvG2qal8sOEusPVCxbYji0aHZ9NeAgAFB4oCAAANvAIAB3OWA
Date: Sat, 29 Apr 2017 20:45:35 +0000
Message-ID: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B68.4090501@foobar.org>
In-Reply-To: <59036B68.4090501@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.82.33]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 20:47:47 -0000

> On Apr 28, 2017, at 6:18 PM, Nick Hilliard  wrote:
>=20
> Fernando Gont wrote:
>> That said, given the past (unfortunate) history with this topic, we
>> should probably change the "are not" to "must not", so that we can avoid
>> future debates on what "are not" means (clearly, it means "must not").
>=20
> Perhaps change to rfc6919-style "MUST NOT(BUT WE KNOW YOU WILL)=94


I=92d support that text ;-)

s.


>=20
> Nick


From nobody Sat Apr 29 13:52:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEF61294A2 for ; Sat, 29 Apr 2017 13:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.622
X-Spam-Level: 
X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vwAyT5XWypMm for ; Sat, 29 Apr 2017 13:52:12 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E688129512 for ; Sat, 29 Apr 2017 13:49:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2608; q=dns/txt; s=iport; t=1493498998; x=1494708598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JCoITX2P+OuHgxRm+fTD9eYR4DAppS75+LII5e1c2ko=; b=Nnb7OUz2HCYLuzlTKaDUkVISSoQ1DgqekgrAVmtwwGRiSjiEG6RZTxdi b8sV5qzfPgdvAiGKlQgVhnbLEgG21XpjYDunUGl9XXQwpI5pa6+eaVdM2 rt3yTGB+J0iw+RqndokukqHXu85x3x2osdCEO8ihPVeOAzr0+weq+eQCe I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQAX/ARZ/4UNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbQeDYYoYkSohgyGSTIIPhiQCGoQdPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBIxFABQULAgEGAhgCAiYCAgIwFRACBA4FihcIkUadYYImiwwBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQuFVIIJC4JlhGAXgm8ugjEBBJ1TAZMQkV6ULAE?= =?us-ascii?q?fOIEKbxVWAYZddYcagQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.37,393,1488844800"; d="scan'208";a="419758547"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2017 20:49:57 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3TKnvTm003416 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 29 Apr 2017 20:49:57 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 29 Apr 2017 16:49:56 -0400
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Sat, 29 Apr 2017 16:49:56 -0400
From: "Stefano Previdi (sprevidi)" 
To: =?utf-8?B?56We5piO6YGU5ZOJ?= 
CC: "Ahmed Bashandy (bashandy)" , Fernando Gont , Brian E Carpenter , "Bob Hinden" , IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSv5CqvG2qal8sOEusPVCxbYji0aHZ9NeAgAFB4oCAAANqAIAAEa6AgAHMdAA=
Date: Sat, 29 Apr 2017 20:49:56 +0000
Message-ID: <1CA0E022-B54D-455C-8063-0AE34DD2CCC2@cisco.com>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <26f5f9c5-2e5e-6f4b-ba47-2818ca4e16bb@si6networks.com> <59036B64.4010008@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.82.33]
Content-Type: text/plain; charset="utf-8"
Content-ID: <463480FD77D8CF4A8D333BFFC3999D94@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 20:52:14 -0000

DQo+IE9uIEFwciAyOCwgMjAxNywgYXQgNzoyMiBQTSwg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lk
ZS5hZC5qcD4gd3JvdGU6DQo+IA0KPiBBdCBGcmksIDI4IEFwciAyMDE3IDA5OjE4OjQ0IC0wNzAw
LA0KPiAiQWhtZWQgQmFzaGFuZHkgKGJhc2hhbmR5KSIgPGJhc2hhbmR5QGNpc2NvLmNvbT4gd3Jv
dGU6DQo+IA0KPj4gSSBhbHNvIGFncmVlDQo+PiBVc2luZyB0aGUgc3RhbmRhcmRpemVkIGtleXdv
cmRzIGF2b2lkcyBhbnkgKmxhbmd1YWdlLWRlcGVuZGVudCoNCj4+IG1pc3VuZGVyc3RhbmRpbmdz
DQo+IA0KPiBJIGFsc28gd2lzaCB0aGlzIGRvY3VtZW50IChib3RoIHRoZSBsYXRlc3QgYmlzIGFu
ZCBpdHMgcHJlZGVjZXNzb3JzKQ0KPiBoYWQgYmVlbiB1c2luZyBSRkMyMTE5IGtleXdvcmRzLCBi
dXQgdGhlIGZhY3QgaXMgdGhhdCBpdCBoYXNuJ3QsIGFuZA0KPiBteSByZWNvbGxlY3Rpb24gbWF0
Y2hlcyBCcmlhbidzIGNvbW1lbnQ6IHdlIGV4cGxpY2l0bHkgZGlzY3Vzc2VkIGl0DQo+IGJlZm9y
ZSBhbmQgdGhlIGRlY2lzaW9uIHdhcyBub3QgdG8gdXNlIFJGQzIxMTkga2V5d29yZHMgZm9yDQo+
IHJmYzI0NjBiaXMuICBJIGRvbid0IHRoaW5rIGl0IHByb2R1Y3RpdmUgdG8gcmVoYXNoIHRoZSBk
aXNjdXNzaW9uIGF0DQo+IHRoaXMgcG9pbnQuDQoNCg0Kd2h5IG5vdCA/IA0KDQppc27igJl0IHRo
ZSBwb2ludCBvZiBhIG5vcm1hdGl2ZSBkb2N1bWVudCB0byB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdl
ID8gDQoNCg0KDQoNCj4gDQo+PiBHb2luZyBiYWNrIHRvIHRoZSBvcmlnaW5hbCBkaXNjdXNzaW9u
LCBJIGFncmVlIHdpdGggU3RlZmFubydzICJzaG91bGQNCj4+IG5vdCIgaW4gdGhpcyBwbGFjZQ0K
PiANCj4gSSBkb24ndCBhZ3JlZSAic2hvdWxkIG5vdCIgaXMgYW4gYXBwcm9wcmlhdGUgcmVwbGFj
ZW1lbnQgb2YgImFyZSBub3TigJ0sDQoNCg0KYnV0IGl04oCZcyBhbiBhcHByb3ByaWF0ZSByZXBs
YWNlbWVudCB0ZXh0LCBsb29raW5nIGF0IHRoZSByZWFsaXR5IG9mIDIwMTcgYW5kIG5vdCB0aGUg
b25lIGluIDE5OTguDQoNCg0KPiBqdXN0IGxpa2UgQnJpYW4gYW5kIEZlcm5hbmRvLiAgSSBhbHNv
IGFncmVlIHdpdGggRmVybmFuZG8gaW4gdGhhdCBpdCdzDQo+IGFjdHVhbGx5IG11Y2ggY2xvc2Vy
IHRvICJtdXN0IG5vdCIsIGlmIGFueXRoaW5nLg0KDQoNCmRlc3BpdGUgdGhlIHZhcmlvdXMgZXBp
c29kZXMsIEkgc3RpbGwgZG8gbm90IGFncmVlIG9uIHRoZSBjdXJyZW50IHRleHQuDQoNCnMuDQoN
Cg0KPiAgU28gaWYgb3VyIGdvYWwgaXMgdG8NCj4gbWFrZSBpdCBjbGVhcmVyLCB0aGUgbG9naWNh
bCBjb25jbHVzaW9uIHNob3VsZCBiZSBhICJtdXN0IG5vdCIuICBCdXQsDQo+IEkgcGVyc29uYWxs
eSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgc3RvcHBpbmcgd29yZGluZyBuaXRwaWNraW5nIGxpa2UN
Cj4gdGhpcyBvbmUuICBJIHVuZGVyc3RhbmQgc29tZSBwZW9wbGUgYXJlIG5vdCBoYXBweSBhYm91
dCB0aGUgc2Vuc2Ugb2YNCj4gdGhlIHdvcmRpbmcuICBJbiBmYWN0LCBJIHN1c3BlY3Qgd2UgaGF2
ZSB0aGlzIGRpc2N1c3Npb24gbm90IGJlY2F1c2UNCj4gaXQncyB1bmNsZWFyIG9yIGluZm9ybWFs
IGJ1dCBiZWNhdXNlIHRoZSBtZWFuaW5nIGlzIGNsb3NlciB0byAibXVzdA0KPiBub3QiIGFuZCBu
b3QgYWxsIHBlb3BsZSBsaWtlIGl0LiAgQnV0IElNTyBhdCB0aGlzIHN0YWdlIGl0J3MgbXVjaCBt
b3JlDQo+IHByb2R1Y3RpdmUgaWYgd2UgZm9jdXMgb24gc2hpcHBpbmcgcmZjMjQ2MGJpcyBhbmQg
ZGlzY3Vzc2luZyBvdGhlcg0KPiB1cGRhdGVzIHRvIGl0IHNvb25lci4NCj4gDQo+IFNvIEkgc3Vw
cG9ydCB0aGUgd29yZCAiYXJlIG5vdCIgYW5kIGZpbmlzaGluZyB0aGUgdGFzay4NCj4gDQo+IC0t
DQo+IEpJTk1FSSwgVGF0dXlhDQoNCg==


From nobody Sat Apr 29 15:57:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41426127B57 for ; Sat, 29 Apr 2017 15:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.521
X-Spam-Level: 
X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 w49tiz9WQoqB for ; Sat, 29 Apr 2017 15:57:40 -0700 (PDT)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7045129454 for ; Sat, 29 Apr 2017 15:55:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3TMtqsP020708; Sat, 29 Apr 2017 15:55:52 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3TMtoxD020692 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sat, 29 Apr 2017 15:55:50 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 29 Apr 2017 15:55:49 -0700
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Sat, 29 Apr 2017 15:55:49 -0700
From: "Manfredi, Albert E" 
To: Robert Raszuk 
CC: 6man WG 
Subject: RE: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSwC8GxB+nJe82b0+NhPWGWSFnqKHbaBiAgACAj4CAABh2AIAABcQAgAAW5wCAAH3DgIAAWaCw
Date: Sat, 29 Apr 2017 22:55:49 +0000
Message-ID: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 22:57:41 -0000

RnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJv
YmVydCBSYXN6dWsNCg0KPiBQUy4gSnVzdCBsb29rIGF0IGN1cnJlbnQgcHJvcHJpZXRhcnkgU0Qt
V0FOcyBvciBpbnRlcm9wZXJhYmxlIElFVEYNCj4gTElTUC4gVGhleSBhcmUgYWxsIC0gYnkgZGVz
aWduIC0gSW50ZXJuZXQgd2lkZS4gU28gaXQgaXMgaW4gZ2VuZXJhbA0KPiBwb3NzaWJsZSB0byBp
bm5vdmF0ZSBhdCBJbnRlcm5ldCBzY2FsZS4gV2h5IHJldmlzZWQgaW4gMjAxNyByZmMyNDYwDQo+
IGp1c3QgZG9lcyBub3QgYWNjb21vZGF0ZSB0aGUgY3VycmVudCBuZWVkcyBhbmQgbGF0ZXN0IGRl
dmVsb3BtZW50cw0KPiBpIElQdjYgc3BhY2UgPw0KDQpUaGUgZ2VuZXJhbCBmZWVsaW5nIGhhcyBi
ZWVuIGV4cHJlc3NlZCBtYW55IHRpbWVzLiBHbyBhaGVhZCBhbmQgaW5ub3ZhdGUsIGJ1dCBub3Qg
YnkgdmlvbGF0aW5nIGNlcnRhaW4gZnVuZGFtZW50YWwgcnVsZXMsIGVzdGFibGlzaGVkIHdheSBi
YWNrIHdoZW4uIFBlb3BsZSBjb3VudCBvbiB0aG9zZSBydWxlcyByZW1haW5pbmcgaW4gcGxhY2Uu
IEJ5IHZpb2xhdGluZyB0aGVtLCB5b3Ugd2lsbCBicmVhayB0aGluZ3MgdGhhdCB3b3JrIGp1c3Qg
ZmluZSBub3cuDQoNClNvIGlubm92YXRlIHdpdGhvdXQgdmlvbGF0aW5nIGJhc2ljIHJ1bGVzLCBv
biB0aGUgb3BlbiBJbnRlcm5ldC4gT3IgdmlvbGF0ZSB0aGUgcnVsZXMgYWxsIHlvdSBsaWtlLCBi
dXQgbWFrZSBzdXJlIGl0IGlzIG9ubHkgYW1vbmcgImNvbnNlbnRpbmcgYWR1bHRzLCIgd2hpY2gg
bWVhbnMsIGluIGEgbG9jYWwgZG9tYWluLiBJdCdzIGFsd2F5cyBiZWVuIHRoaXMgd2F5LCBzbyB0
aGlzIHNob3VsZCBub3QgY29tZSBhcyBhIHN1cnByaXNlPw0KDQpCZXJ0DQoNCg==


From nobody Sat Apr 29 18:47:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22171128959 for ; Sat, 29 Apr 2017 18:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BFd-JV8ZYAzu for ; Sat, 29 Apr 2017 18:47:55 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 96B101293D6 for ; Sat, 29 Apr 2017 18:45:47 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id r185so13263562itd.1 for ; Sat, 29 Apr 2017 18:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tEWsS2roCZWeVcuo9bMdeFA3+apoH/sO5sBPmQLDM1E=; b=amxrHJvVyc+VaDp2jHcmIDWh06vvegqpFBIXml4kUs7m2KO97yiGU/AsUTsoZ7JS1W Cc2axcaKejHmIY1uOc0PkbTvPGVB/XyX3L0cc8yCXqstOnBEGrb1vp7NzBV20/Qv43hO kBfcJnWtuFIDkHW+gAfPQtPhW0vf80vJiOjgQRFts5VQiIfR93YIqGfGwnjWRe+qUkl5 +sDFzoxrU7J+Yd65ffIQaNFrERKHBsB1gpogOKsDVzMCVxnmga/0GUUR+YE7Ao8prDDO ZYow7zrW6PHI9EuJQawM9fjRI47N06hoFC+sBp1pVZsWqZblcZZsPP1lyUPs1mKQ11kR f+Zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tEWsS2roCZWeVcuo9bMdeFA3+apoH/sO5sBPmQLDM1E=; b=uiaucC3ACZEnFXZj9/qYCONAol3QSp3Z1PRe28b3G2Y+4EeGpDtl0rq7UG9fko2uMw S/EZ3YaxTNeoduOPDb/zLN3uyriz6ysMtgynbSNw3de99ewiOmRQl0P0H9QBSDZAyhlq fL4f035JqR/bQfynENfUFt3UxckjSHNr/U6lozGwEZa643F/5mQG/DrE/zE27fpVuIWA JhYzS1Pp+82d3VGg/Z8Jo8JOaY97zW0Ppm6T6RrxWnZf6NnqGhHw3tgA0Ez9QytwA3e7 1YsVBYiDOkjS67oKsWvCVX+m3iqjy63RU2/GF8FQmXQiF7fb8S4mPG6WIoo5c2cZ+VZi rybw==
X-Gm-Message-State: AN3rC/4XQuFCqXggw7KmvSPH9BpYVwkjSbHl1YFZIBeAaLOCNrJNnj2K PShVD/FENzukin2V7ZzOfucAJIDNAA==
X-Received: by 10.36.28.74 with SMTP id c71mr3153154itc.18.1493516746733; Sat, 29 Apr 2017 18:45:46 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.62.24 with HTTP; Sat, 29 Apr 2017 18:45:45 -0700 (PDT)
Received: by 10.79.62.24 with HTTP; Sat, 29 Apr 2017 18:45:45 -0700 (PDT)
In-Reply-To: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>      
From: Robert Raszuk 
Date: Sat, 29 Apr 2017 21:45:45 -0400
X-Google-Sender-Auth: TA0ur5R8DT9iwQNY7wjgYZmW_RI
Message-ID: 
Subject: RE: Proposed revised Extension Header text for rfc2460bis
To: "Manfredi, Albert E" 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary=001a1140574e27e09a054e587782
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 01:47:57 -0000

--001a1140574e27e09a054e587782
Content-Type: text/plain; charset=UTF-8

So innovate without violating basic rules, on the open Internet. Or violate
the rules all you like, but make sure it is only among "consenting adults,"
which means, in a local domain. It's always been this way, so this should
not come as a surprise?

Bert


Dear Bert,

To your quote "It's always been this way" I completely and respectfully
disagree.

If the IETF would be stuck in not violating on what you call "basic rules"
we would still be classfull and never use CIDR, we will still be using
RIPv1 for routing and for good or for bad we will never have MP-BGP ...
just to quote 1% of breaking the "always" rules.

I am not getting why IPv6 ministers are like monks in deepest Bhutan's
Monasteries. The banner is: "What has been defined years back is the only
truth forever."

Maybe it is time to open the windows and ask yourself why IPv6 deployment
for end consumers is really not happeing (except very local markets like
Japan). Maybe IPv6 did not come with suficient reason to be deployed ???

Maybe it came with way too much baggage not to be deployed .. example hosts
force to pick which PA address to use as src .... this is so broken !

IMHO if we can not give PI to everyone we are doing something very wrong.

And no further then last IETF I had one vendor person coming to me after
comment at RTGWG that PI for IPv6 is not so great idea that I immediately
understood why IPv6 is in such poor state. He insisted everyone should use
PA space. Is this what you all recommend ???

Bottom line if IPv6 gurus think today that what has been defined years back
it is to stay as "basic rule" for v6 in the years to come I can only wish
you all the best.

Cheers,
Robert.

PS. Folks like Stefano and myself do know very well traveling the world to
educate folks to deploy new technologies that it only get's good traction
where there is good reason for it. Clearly depletion of v4 space as real
life shows was not the reason for v6 to gain global momentum. Even folks at
various conferencs admit it these days.

--001a1140574e27e09a054e587782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


So innovate without violati=
ng basic rules, on the open Internet. Or violate the rules all you like, bu=
t make sure it is only among "consenting adults," which means, in=
 a local domain. It's always been this way, so this should not come as =
a surprise?



Bert





Dear B=
ert,

To your quote "It's always been this way&=
quot; I completely and respectfully disagree.=C2=A0

If =
the IETF would be stuck in not violating on what you call "basic rules=
" we would still be classfull and never use CIDR, we will still be usi=
ng RIPv1 for routing and for good or for bad we will never have MP-BGP ... =
just to quote 1% of breaking the "always" rules.

I am not getting why IPv6 ministers are like monks in deepest Bhutan&#=
39;s Monasteries. The banner is: "What has been defined years back is =
the only truth forever."
=

Maybe it is time to open =
the windows and ask yourself why IPv6 deployment for end consumers is reall=
y not happeing (except very local markets like Japan). Maybe IPv6 did not c=
ome with suficient reason to be deployed ???

Maybe it c=
ame with way too much baggage not to be deployed .. example hosts force to =
pick which PA address to use as src .... this is so broken !

IMHO if we can not give PI to everyone we are doing something very wr=
ong.=C2=A0

And no further then last IETF I had one vend=
or person coming to me after comment at RTGWG that PI for IPv6 is not so gr=
eat idea that I immediately understood why IPv6 is in such poor state. He i=
nsisted everyone should use PA space. Is this what you all recommend ???

Bottom line if IPv6 gurus think today that what has been =
defined years back it is to stay as "basic rule" for v6 in the ye=
ars to come I can only wish you all the best.

Cheers,
Robert.

PS.=
 Folks like Stefano and myself do know very well traveling the world to edu=
cate folks to deploy new technologies that it only get's good traction =
where there is good reason for it. Clearly depletion of v4 space as real li=
fe shows was not the reason for v6 to gain global momentum. Even folks at v=
arious conferencs admit it these days.






--001a1140574e27e09a054e587782--


From nobody Sat Apr 29 20:09:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823311275C5 for ; Sat, 29 Apr 2017 20:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Hx3NX7bih9j4 for ; Sat, 29 Apr 2017 20:09:07 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 7E46C129400 for ; Sat, 29 Apr 2017 20:07:08 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id j59so54898591uad.0 for ; Sat, 29 Apr 2017 20:07:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x5b5mD+uNPu/STKdosQq6XAg3y7ZhHVI1+L06j4HCjk=; b=AHLI+DyINVYnCOG5Sau4f5KzW8ZG6HPBbKoC5ddn3cdqoLniMpp0EFUPWzvMh6H5cX i+7Qdx3KeG3wF8fNFxjrMrLDTpsMBJ2OTQeWhZm+OsEln6Axcsq13eFbmowiNUdD9moB QzUUoGY7y/QdkTxI2NQJbXKZ5SMHHFT5ZbTu8LndOaSOzNtb4qjsg9TzjEGcX5uJG3iz cWHjV/T4uRA2xYjUmGmj2BUzzkchzvsZ0zcMz1UPzFW5vT+L+4HTDOV9Y2hujOHD9qQO EPVhiO/icnss6WtNrgtLiH0xD6JolmwFL1azZ9YCIgtNXk09dH61l7vnTZaD6ciVmWq7 g5ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x5b5mD+uNPu/STKdosQq6XAg3y7ZhHVI1+L06j4HCjk=; b=gxFUhZgc4eA5tFy8GWKkYlpnHjbQx59RUc+TiqsWy16Mw1Y4WoG8oL2ck2vYOTDP1t JDHv079lN4QLy0n0AnBJuV2iLh2FRi/uNW5QwFAeICDgDYRb1IcGk+noIWwnhDAMdeLb mCHAWr4rufpnP0q/NCrdv5/5YLOL5QoIQQRIEmIGFluspVbqTpUNWaB9D331Nvw9zcdZ CG8hgnnh2EV2Ls5Bsg0B0SjN2NlTNV4SxNqK5+D12hPeHiCIKafigGgpy0w0+l2uMiWz vUCqvT56BJ9Df+11mSU3hX5aS8MVM0DxKJ6i6cNW/e1Uldy8ux3F5Y1JiwVKWbvTnC17 SwBw==
X-Gm-Message-State: AN3rC/6jm3Fgtm0oPLUfLgJdCeSZ/PPTTPKxZM4A2xWtR7ZvzTXytNpo 69S1bJ9fT5qh4QzXeSOrcz6gi7187A==
X-Received: by 10.176.80.16 with SMTP id b16mr10029002uaa.103.1493521626293; Sat, 29 Apr 2017 20:07:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.55.130 with HTTP; Sat, 29 Apr 2017 20:07:05 -0700 (PDT)
Received: by 10.159.55.130 with HTTP; Sat, 29 Apr 2017 20:07:05 -0700 (PDT)
In-Reply-To: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>       
From: Mark Smith 
Date: Sun, 30 Apr 2017 13:07:05 +1000
Message-ID: 
Subject: RE: Proposed revised Extension Header text for rfc2460bis
To: Robert Raszuk 
Cc: 6man WG , "Manfredi, Albert E" 
Content-Type: multipart/alternative; boundary=94eb2c1913f8ffeb86054e599960
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 03:09:09 -0000

--94eb2c1913f8ffeb86054e599960
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 30 Apr. 2017 11:48, "Robert Raszuk"  wrote:

So innovate without violating basic rules, on the open Internet. Or violate
the rules all you like, but make sure it is only among "consenting adults,"
which means, in a local domain. It's always been this way, so this should
not come as a surprise?

Bert


Dear Bert,

To your quote "It's always been this way" I completely and respectfully
disagree.

If the IETF would be stuck in not violating on what you call "basic rules"
we would still be classfull and never use CIDR, we will still be using
RIPv1 for routing and for good or for bad we will never have MP-BGP ...
just to quote 1% of breaking the "always" rules.



None of those made structural or size changes to IPv4 packets while
in-flight. They were control plane protocol changes or forwarding
processing changes that left the format of the packet and the semantics of
its field values alone.

(And no, MPLS or any other link layer encapsulation is not changing the
IPv4 packet - the range of octets starting at the IPv4 header extending
through to the end of the IPv4 payload. Same with an IPv6 packet.)

Your proposed change is unprecedented. No other network layer protocol as
far as I'm aware, including IPv4, IPX and Appletalk (I'm pretty confident
if DECnet and CLNS too) have made structural changes to their network layer
PDUs while in-flight.

An unprecedented change may not be trivial, and certainly shouldn't be
classified as such during a document maintenance=E2=80=8B update to a 18+ y=
ear old
protocol like IPv6.



I am not getting why IPv6 ministers are like monks in deepest Bhutan's
Monasteries. The banner is: "What has been defined years back is the only
truth forever."

Maybe it is time to open the windows and ask yourself why IPv6 deployment
for end consumers is really not happeing (except very local markets like
Japan). Maybe IPv6 did not come with suficient reason to be deployed ???


You're out of touch with IPv6 deployment status.

https://www.google.com/intl/en/ipv6/statistics.html

https://stats.labs.apnic.net/ipv6/



Maybe it came with way too much baggage not to be deployed .. example hosts
force to pick which PA address to use as src .... this is so broken !

IMHO if we can not give PI to everyone we are doing something very wrong.

And no further then last IETF I had one vendor person coming to me after
comment at RTGWG that PI for IPv6 is not so great idea that I immediately
understood why IPv6 is in such poor state. He insisted everyone should use
PA space. Is this what you all recommend ???


Bottom line if IPv6 gurus think today that what has been defined years back
it is to stay as "basic rule" for v6 in the years to come I can only wish
you all the best.


We have an installed base of billions of IPv6 capable devices that expect
RFC2460 behaviour to look after.

Your SPRING=E2=80=8B group is operating in currently a very small green fie=
ld (are
there any production deployments of SR yet?), ours is a very large brown
one. "Trivial" changes for you are trivial, for us we need to make sure
they don't break things in unexpected ways, because real and existing
end-users and production network operators may suffer a significant and
potentially financially costly consequence.

Regards,
Mark.


Cheers,
Robert.

PS. Folks like Stefano and myself do know very well traveling the world to
educate folks to deploy new technologies that it only get's good traction
where there is good reason for it. Clearly depletion of v4 space as real
life shows was not the reason for v6 to gain global momentum. Even folks at
various conferencs admit it these days.


CGN capacity/throughput costs and the opex of running two protocols will
get them in the end.






--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--94eb2c1913f8ffeb86054e599960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 30 Apr. 2017 11:48, "Robert Raszuk" <robert@raszuk.net> wrote:
So innovate without vi=
olating basic rules, on the open Internet. Or violate the rules all you lik=
e, but make sure it is only among "consenting adults," which mean=
s, in a local domain. It's always been this way, so this should not com=
e as a surprise?



Bert





=
Dear Bert,

To your quote "It's always been thi=
s way" I completely and respectfully disagree.=C2=A0

If the IETF would be stuck in not violating on what you call "bas=
ic rules" we would still be classfull and never use CIDR, we will stil=
l be using RIPv1 for routing and for good or for bad we will never have MP-=
BGP ... just to quote 1% of breaking the "always" rules.


None of those made structural or size chan=
ges to IPv4 packets while in-flight. They were control plane protocol chang=
es or forwarding processing changes that left the format of the packet and =
the semantics of its field values alone.

<=
div dir=3D"auto">(And no, MPLS or any other link layer encapsulation is not=
 changing the IPv4 packet - the range of octets starting at the IPv4 header=
 extending through to the end of the IPv4 payload. Same with an IPv6 packet=
.)

Your proposed change =
is unprecedented. No other network layer protocol as far as I'm aware, =
including IPv4, IPX and Appletalk (I'm pretty confident if DECnet and C=
LNS too) have made structural changes to their network layer PDUs while in-=
flight.

An unprecedented=
 change may not be trivial, and certainly shouldn't be classified as su=
ch during a document maintenance=E2=80=8B update to a 18+ year old protocol=
 like IPv6.



I am not getting why I=
Pv6 ministers are like monks in deepest Bhutan's Monasteries. The banne=
r is: "What has been defined years back is the only truth forever.&quo=
t;

Maybe it is time to open the windows and ask yoursel=
f why IPv6 deployment for end consumers is really not happeing (except very=
 local markets like Japan). Maybe IPv6 did not come with suficient reason t=
o be deployed ???

You're out of touch with IPv6 deployment=
 status.





Maybe it =
came with way too much baggage not to be deployed .. example hosts force to=
 pick which PA address to use as src .... this is so broken !

IMHO if we can not give PI to everyone we are doing something very w=
rong.=C2=A0

And no further then last IETF I had one ven=
dor person coming to me after comment at RTGWG that PI for IPv6 is not so g=
reat idea that I immediately understood why IPv6 is in such poor state. He =
insisted everyone should use PA space. Is this what you all recommend ???

Bottom line if IPv6 gurus think today that what has be=
en defined years back it is to stay as "basic rule" for v6 in the=
 years to come I can only wish you all the best.

We have an in=
stalled base of billions of IPv6 capable devices that expect RFC2460 behavi=
our to look after.

Your =
SPRING=E2=80=8B group is operating in currently a very small green field (a=
re there any production deployments of SR yet?), ours is a very large brown=
 one. "Trivial" changes for you are trivial, for us we need to ma=
ke sure they don't break things in unexpected ways, because real and ex=
isting end-users and production network operators may suffer a significant =
and potentially financially costly consequence.

=

Regards,
Mark.


=
Cheers,
Robert.

PS. Folks like Stefano and myself do know very well traveling the wor=
ld to educate folks to deploy new technologies that it only get's good =
traction where there is good reason for it. Clearly depletion of v4 space a=
s real life shows was not the reason for v6 to gain global momentum. Even f=
olks at various conferencs admit it these days.

CGN capacity/t=
hroughput costs and the opex of running two protocols will get them in the =
end.=C2=A0



=




-------------------------------------------------------------=
-------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--94eb2c1913f8ffeb86054e599960--


From nobody Sat Apr 29 23:42:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360D1243F6 for ; Sat, 29 Apr 2017 23:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_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 8yOwUt2snZl0 for ; Sat, 29 Apr 2017 23:42:03 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 70DC6126FDC for ; Sat, 29 Apr 2017 23:40:24 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id e64so27162266pfd.1 for ; Sat, 29 Apr 2017 23:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d/rTTNG09ZDKoC0BFYhXT2MKLLr/qPozytPbuhz3d0A=; b=OP5zceL9HWBg+q8cfZHH5yD3tvVidolV8o67HHamG+MN7rKaEoNi3I9FKB1KTzr/Ct o8Q+wmbdawBfuNL25U7PTHXghQzzS7zi7tJLuK9tUTX3tFwZenA4uLJu+PGQga1Hv7mz VJl/TMeNKH7h6nSORmsxvkxFoRKC7Rvb4o1q7m7m5qc6AGYb1BVWeph5t1T3jVQDUKXW TH0+6xQWCrUk3bdlUEkI81zWv2lpCFpddvpO1PmMnE8e+tZ4fpElb4vPke1UDmjjpoCW s1TEysTw+bWgEaLEfHqAlTDN44JDYvyQqrO1nhJuctEmo1igFI2NuuhdQ4LS6hjlkw3a ubrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d/rTTNG09ZDKoC0BFYhXT2MKLLr/qPozytPbuhz3d0A=; b=DQgkiRWAZkPmbFIcA3PjmOiPT7DBUyQ2WEvl13jkFN1KuTNweC07xPVBI3rNzgTdSE J1nQIy3X0zrvLI30HVQSZuf/a2mwq0fccC4GS5P0mGsoJEcanmxyLjVJqD29hgK2iBzh CqkEz4G6+jN42L8dGaWSmvlBo6N9bUZ4+5TR1jBQPIiRy85oYLNta8d6oggVSNu5M/GR bTbct9cfURjUruwcIRDxmXotXVZP5qSNBiPx06BA2AerdYdQIKPVlyfPbKa02YNN2tU3 MGBtBH1k7AvEW5OFj/TS9GloGo3YBhdoZXzV0je/q+3/vdGGFOVg0krpoGhX+K6voLwm oWjA==
X-Gm-Message-State: AN3rC/7KMO2vqdKGYNPliVphqGlt3TTunPodfaXX1wW7G58WGR9U+Z2Z RKKaMrDYqEEKTA==
X-Received: by 10.84.238.198 with SMTP id l6mr26226350pln.95.1493534423857; Sat, 29 Apr 2017 23:40:23 -0700 (PDT)
Received: from [192.168.1.12] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id g22sm18789532pfd.22.2017.04.29.23.40.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 23:40:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Proposed revised Extension Header text for rfc2460bis
From: Fred Baker 
In-Reply-To: 
Date: Sat, 29 Apr 2017 23:40:20 -0700
Cc: 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>        
To: Mark Smith , Robert Raszuk 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 06:42:06 -0000

On Apr 29, 2017, at 8:07 PM, Mark Smith  wrote:
> On Apr 29, 2017, at 6:45 PM, Robert Raszuk  wrote:
>> Maybe it is time to open the windows and ask yourself why IPv6 =
deployment for end consumers is really not happening (except very local =
markets like Japan). Maybe IPv6 did not come with suficient reason to be =
deployed ???
>=20
> You're out of touch with IPv6 deployment status.

Robert, you might be interested to poke around on the current status of =
IPv6 deployment. Here are 36 countries, of which Google says that 5% or =
more of the traffic from them uses IPv6. Consider the implications of =
that, if you would; it means that someone had a computer that was =
attached to a network attached to an ISP attached to another ISP that =
went to Google to a computer, and every step along the way IPv6 was =
deployed and working, end to end.=20

=
https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dbe,us=
,gr,de,ch,lu,in,br,ee,ca,ec,jp,gb,pt,my,fr,tt,no,fi,pe,au,cz,nz,nl,ie,ro,h=
u,si,zw,gt,pr,kr,vn,sa,at,ax,pl

That includes countries on every continent, including Zimbabwe in =
Africa, six Latin American countries, Saudi Arabia, Malaysia, and India. =
And, oh yes, Japan. And the US.

Heck, look at Trinidad and Tobago, a Small Island State in the =
Caribbean, someone that the UN considers to be seriously back woods. =
Google says that 15% of the sessions they have in T&T use IPv6, and =
Akamai says that 20% of the traffic they deliver there uses IPv6. This =
isn't just the big countries, or the well-connected ones.

https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dtt
https://www.vyncke.org/ipv6status/project.php?metric=3Dk&country=3Dtt

At F Root, about 11% of our DNS accesses come in IPv6 packets.

http://rssac-stats.isc.org/rssac002/2017

Several companies are taking serious steps toward turning IPv4 off, or =
have already done so. Where is IPv6 dominant? The Mobile networks are =
among the biggest there.

https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft
https://blog.apnic.net/2017/02/02/addressing-in-2016
=
https://blog.apnic.net/2017/02/07/reliance-jio-boosts-india-past-20-ipv6-c=
apability
=
https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-onl=
y-infra
https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf=20=

=
https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_13462152832-2.p=
df

Performance issues that were there historically, largely due to =
substandard routing, are a bad memory.
https://blog.apnic.net/2016/08/22/ipv6-performance-revisited

You might be interested in Uber's viewpoint.

https://eng.uber.com/ipv6

"Having deployment problems" isn't a very accurate statement.

It is fair to say that the deployment started slowly. It started in =
2006, with ICANN ratifying a policy for the allocation of IPv6 prefixes, =
and the limited-IPv6-capability Windows Vista release in the same year =
(other platforms all had it, Windows was the laggard, and killing off =
Windows XP has been an quest worthy of Arthur). By 2009, 4000 prefixes =
had been allocated world-wide. IPv4 exhaustion at IANA was predicted, =
although there was a lot of discussion between Geoff and Tony, and =
finally happened in January 2011. April 2011, APNIC entered their final =
phase of IPv4 allocation (by policy, they now only allocate a /22 to a =
new member, and none at all to existing members), and at this point all =
five RIRs are in their final phase of IPv4 allocation. The IPv4 Market =
Group says that they expect the price of an IPv4 address, which right =
now varies between about $6 and $15 per address depending on the block =
size, to start to decline in 2019, because at that point more than half =
of the users in the world will have functional IPv6 capabilities and it =
will be in corporate interest to look forward rather than back. Swisscom =
says that by 2024 they expect they won't have enough IPv4 traffic to =
justify continuing to route it.

https://www.icann.org/news/announcement-2006-09-11-en
https://www.oecd.org/sti/ieconomy/44961688.pdf slide 16
https://ipv4.potaroo.net/
http://ipv4marketgroup.com/ipv4-pricing-in-a-post-arin-runout-world
http://ipv4marketgroup.com/q42016-update
=
http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Statu=
s_Roadmap_and_Outlook_IPv6.pdf

In other words, it didn't start until the IPv4 address space became =
exhausted at IANA and the relevant RIRs, which was 100% predictable. At =
this point, smart companies are starting to use the speculative asset of =
IPv4 address space to finance their IPv6 deployment, and some companies =
are starting to charge for IPv4 address space while leaving IPv6 free.

https://gist.github.com/simonster/e22e50cd52b7dffcf5a4db2b8ea4cce0
=
http://www.networkworld.com/article/3191503/internet/mit-selling-8-million=
-coveted-ipv4-addresses-amazon-a-buyer.html
https://www.mythic-beasts.com/order/vps

If you are on a major broadband service in the US and don't have IPv6 in =
your home (go to http://www.kame.net, and see if the turtle dances), ask =
your provider about it. There's a good chance the issue is at your =
residential router.

You're welcome to your opinions of IPv6; if it were mine to do over =
there are some things I might change. But it is what it is, and it's out =
there. Get used to it. Resistance, as they say, is futile.=


From nobody Sun Apr 30 16:58:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229DD127601 for ; Sun, 30 Apr 2017 16:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-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 GSIpQuDUfDex for ; Sun, 30 Apr 2017 16:58:36 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF69129442 for ; Sun, 30 Apr 2017 16:56:59 -0700 (PDT)
Received: from [85.158.139.3] by server-9.bemta-5.messagelabs.com id 6D/11-01999-AC976095; Sun, 30 Apr 2017 23:56:58 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOJsWRWlGSWpSXmKPExsXi7PqsVfdkJVu kwfkOXouXZ98zWew8cpTdomlhE7MDs8fOWXfZPZYs+cnksXvjAqYA5ijWzLyk/IoE1oyFF2ez FczewFjxdUttA+PztYxdjJwcEgJ+Er2XrrGB2EICexkl1tz3gbBvMErcnwdkcwHZpxkl3l9Zw t7FyMHBJqAjMeeFPEiNiICXxPz278wgNrOAtMStJc+ZQGxhASeJ2z8WskDUOEvc6d3PBjJHRK CLUeLKxMNgRSwCqhKvDz0As3kFrCQO9C1hhFh2gEPi+tL9jCDLOAUCJRbergepYRQQk/h+ag0 TxDJxiVtP5jNBPCAgsWTPeWYIW1Ti5eN/rCC2qICexLUPK1kg4joSZ68/gXrYQGLr0n1QcQWJ udM3s0DMjJX48aKbGeIeQYmTM59A1UhKHFxxgwUSKIoS8269ZYG4cx6jxMStbewQRfYS/y/9Y JzAKDMLyX2zkMydhWTuLKDXmAU0Jdbv0ocoUZSY0v2QHcLWkGidMxfKtpf4uv4KC7KaBYwcqx g1ilOLylKLdA1N9JKKMtMzSnITM3N0DQ1M9XJTi4sT01NzEpOK9ZLzczcxAhMMAxDsYDx72vM QoyQHk5Io7/pytkghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKEryxFUA5waLU9NSKtMwcYKqDSUtw 8CiJ8JaDpHmLCxJzizPTIVKnGBWlxHkngyQEQBIZpXlwbbD0eolRVkqYlxHoECGegtSi3MwSV PlXjOIcjErCvDUgU3gy80rgpr8CWswEtLhejQVkcUkiQkqqgXHV3DsHcpe01B/8WKB2wvOvuA bnq5TTHxeyyD4N+nLfvn6F9Oufu1dfCas78HlJTrpvt0/Y/oSmEL/n0Y6rnXwOXy7SeNzq6NI lE10uXLRHb3p/x9lPTw0OxbpWn93K7bSM/dC/tq0eBR4HVy1k4Ok1dJm89q3dyjmK7fsiuKZt uzfhTUB2vrISS3FGoqEWc1FxIgBosQUOqgMAAA==
X-Env-Sender: daniel.voyer@bell.ca
X-Msg-Ref: server-6.tower-90.messagelabs.com!1493596615!14614533!2
X-Originating-IP: [67.69.230.133]
X-StarScan-Received: 
X-StarScan-Version: 9.4.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15394 invoked from network); 30 Apr 2017 23:56:57 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-6.tower-90.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 30 Apr 2017 23:56:57 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca
Received: from DG2MBX04-WYN.bell.corp.bce.ca (198.235.102.32) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1210.3; Sun, 30 Apr 2017 19:56:53 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX04-WYN.bell.corp.bce.ca (2002:8eb6:1216::8eb6:1216) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Apr 2017 19:56:54 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39%23]) with mapi id 15.00.1210.000; Sun, 30 Apr 2017 19:56:54 -0400
From: "Voyer, Daniel" 
To: Mark Smith , Robert Raszuk 
CC: 6man WG 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSvU2GLj2bkcaFakK4L3vH7EBFBaHZZUuAgACEfACAAA+WgIABK9yAgAAWV4CAAICQgIAAGHYAgAAFxACAABbmAIAAfcOAgADQ7YD//+0US4AAWSCAgAEaIIA=
Date: Sun, 30 Apr 2017 23:56:54 +0000
Message-ID: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.26]
Content-Type: multipart/alternative; boundary="_000_0DF549512A954BB08F7CB6AB6BEDE40Fbellca_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.102.32 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 23:58:39 -0000

--_000_0DF549512A954BB08F7CB6AB6BEDE40Fbellca_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkZyb206IGlwdjYgPGlwdjYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1hcmsg
U21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+DQpEYXRlOiBTYXR1cmRheSwgQXByaWwgMjks
IDIwMTcgYXQgMTE6MDcgUE0NClRvOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4N
CkNjOiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUkU6IFByb3Bvc2VkIHJldmlz
ZWQgRXh0ZW5zaW9uIEhlYWRlciB0ZXh0IGZvciByZmMyNDYwYmlzDQoNCg0KDQpPbiAzMCBBcHIu
IDIwMTcgMTE6NDgsICJSb2JlcnQgUmFzenVrIiA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJv
YmVydEByYXN6dWsubmV0Pj4gd3JvdGU6DQpTbyBpbm5vdmF0ZSB3aXRob3V0IHZpb2xhdGluZyBi
YXNpYyBydWxlcywgb24gdGhlIG9wZW4gSW50ZXJuZXQuIE9yIHZpb2xhdGUgdGhlIHJ1bGVzIGFs
bCB5b3UgbGlrZSwgYnV0IG1ha2Ugc3VyZSBpdCBpcyBvbmx5IGFtb25nICJjb25zZW50aW5nIGFk
dWx0cywiIHdoaWNoIG1lYW5zLCBpbiBhIGxvY2FsIGRvbWFpbi4gSXQncyBhbHdheXMgYmVlbiB0
aGlzIHdheSwgc28gdGhpcyBzaG91bGQgbm90IGNvbWUgYXMgYSBzdXJwcmlzZT8NCg0KQmVydA0K
DQpEZWFyIEJlcnQsDQoNClRvIHlvdXIgcXVvdGUgIkl0J3MgYWx3YXlzIGJlZW4gdGhpcyB3YXki
IEkgY29tcGxldGVseSBhbmQgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLg0KDQpJZiB0aGUgSUVURiB3
b3VsZCBiZSBzdHVjayBpbiBub3QgdmlvbGF0aW5nIG9uIHdoYXQgeW91IGNhbGwgImJhc2ljIHJ1
bGVzIiB3ZSB3b3VsZCBzdGlsbCBiZSBjbGFzc2Z1bGwgYW5kIG5ldmVyIHVzZSBDSURSLCB3ZSB3
aWxsIHN0aWxsIGJlIHVzaW5nIFJJUHYxIGZvciByb3V0aW5nIGFuZCBmb3IgZ29vZCBvciBmb3Ig
YmFkIHdlIHdpbGwgbmV2ZXIgaGF2ZSBNUC1CR1AgLi4uIGp1c3QgdG8gcXVvdGUgMSUgb2YgYnJl
YWtpbmcgdGhlICJhbHdheXMiIHJ1bGVzLg0KDQoNCk5vbmUgb2YgdGhvc2UgbWFkZSBzdHJ1Y3R1
cmFsIG9yIHNpemUgY2hhbmdlcyB0byBJUHY0IHBhY2tldHMgd2hpbGUgaW4tZmxpZ2h0LiBUaGV5
IHdlcmUgY29udHJvbCBwbGFuZSBwcm90b2NvbCBjaGFuZ2VzIG9yIGZvcndhcmRpbmcgcHJvY2Vz
c2luZyBjaGFuZ2VzIHRoYXQgbGVmdCB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgYW5kIHRoZSBz
ZW1hbnRpY3Mgb2YgaXRzIGZpZWxkIHZhbHVlcyBhbG9uZS4NCg0KKEFuZCBubywgTVBMUyBvciBh
bnkgb3RoZXIgbGluayBsYXllciBlbmNhcHN1bGF0aW9uIGlzIG5vdCBjaGFuZ2luZyB0aGUgSVB2
NCBwYWNrZXQgLSB0aGUgcmFuZ2Ugb2Ygb2N0ZXRzIHN0YXJ0aW5nIGF0IHRoZSBJUHY0IGhlYWRl
ciBleHRlbmRpbmcgdGhyb3VnaCB0byB0aGUgZW5kIG9mIHRoZSBJUHY0IHBheWxvYWQuIFNhbWUg
d2l0aCBhbiBJUHY2IHBhY2tldC4pDQoNCllvdXIgcHJvcG9zZWQgY2hhbmdlIGlzIHVucHJlY2Vk
ZW50ZWQuIE5vIG90aGVyIG5ldHdvcmsgbGF5ZXIgcHJvdG9jb2wgYXMgZmFyIGFzIEknbSBhd2Fy
ZSwgaW5jbHVkaW5nIElQdjQsIElQWCBhbmQgQXBwbGV0YWxrIChJJ20gcHJldHR5IGNvbmZpZGVu
dCBpZiBERUNuZXQgYW5kIENMTlMgdG9vKSBoYXZlIG1hZGUgc3RydWN0dXJhbCBjaGFuZ2VzIHRv
IHRoZWlyIG5ldHdvcmsgbGF5ZXIgUERVcyB3aGlsZSBpbi1mbGlnaHQuDQoNCkFuIHVucHJlY2Vk
ZW50ZWQgY2hhbmdlIG1heSBub3QgYmUgdHJpdmlhbCwgYW5kIGNlcnRhaW5seSBzaG91bGRuJ3Qg
YmUgY2xhc3NpZmllZCBhcyBzdWNoIGR1cmluZyBhIGRvY3VtZW50IG1haW50ZW5hbmNl4oCLIHVw
ZGF0ZSB0byBhIDE4KyB5ZWFyIG9sZCBwcm90b2NvbCBsaWtlIElQdjYuDQoNCg0KDQpJIGFtIG5v
dCBnZXR0aW5nIHdoeSBJUHY2IG1pbmlzdGVycyBhcmUgbGlrZSBtb25rcyBpbiBkZWVwZXN0IEJo
dXRhbidzIE1vbmFzdGVyaWVzLiBUaGUgYmFubmVyIGlzOiAiV2hhdCBoYXMgYmVlbiBkZWZpbmVk
IHllYXJzIGJhY2sgaXMgdGhlIG9ubHkgdHJ1dGggZm9yZXZlci4iDQoNCk1heWJlIGl0IGlzIHRp
bWUgdG8gb3BlbiB0aGUgd2luZG93cyBhbmQgYXNrIHlvdXJzZWxmIHdoeSBJUHY2IGRlcGxveW1l
bnQgZm9yIGVuZCBjb25zdW1lcnMgaXMgcmVhbGx5IG5vdCBoYXBwZWluZyAoZXhjZXB0IHZlcnkg
bG9jYWwgbWFya2V0cyBsaWtlIEphcGFuKS4gTWF5YmUgSVB2NiBkaWQgbm90IGNvbWUgd2l0aCBz
dWZpY2llbnQgcmVhc29uIHRvIGJlIGRlcGxveWVkID8/Pw0KDQpZb3UncmUgb3V0IG9mIHRvdWNo
IHdpdGggSVB2NiBkZXBsb3ltZW50IHN0YXR1cy4NCg0KaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9p
bnRsL2VuL2lwdjYvc3RhdGlzdGljcy5odG1sDQoNCmh0dHBzOi8vc3RhdHMubGFicy5hcG5pYy5u
ZXQvaXB2Ni8NCg0KDQoNCk1heWJlIGl0IGNhbWUgd2l0aCB3YXkgdG9vIG11Y2ggYmFnZ2FnZSBu
b3QgdG8gYmUgZGVwbG95ZWQgLi4gZXhhbXBsZSBob3N0cyBmb3JjZSB0byBwaWNrIHdoaWNoIFBB
IGFkZHJlc3MgdG8gdXNlIGFzIHNyYyAuLi4uIHRoaXMgaXMgc28gYnJva2VuICENCg0KSU1ITyBp
ZiB3ZSBjYW4gbm90IGdpdmUgUEkgdG8gZXZlcnlvbmUgd2UgYXJlIGRvaW5nIHNvbWV0aGluZyB2
ZXJ5IHdyb25nLg0KDQpBbmQgbm8gZnVydGhlciB0aGVuIGxhc3QgSUVURiBJIGhhZCBvbmUgdmVu
ZG9yIHBlcnNvbiBjb21pbmcgdG8gbWUgYWZ0ZXIgY29tbWVudCBhdCBSVEdXRyB0aGF0IFBJIGZv
ciBJUHY2IGlzIG5vdCBzbyBncmVhdCBpZGVhIHRoYXQgSSBpbW1lZGlhdGVseSB1bmRlcnN0b29k
IHdoeSBJUHY2IGlzIGluIHN1Y2ggcG9vciBzdGF0ZS4gSGUgaW5zaXN0ZWQgZXZlcnlvbmUgc2hv
dWxkIHVzZSBQQSBzcGFjZS4gSXMgdGhpcyB3aGF0IHlvdSBhbGwgcmVjb21tZW5kID8/Pw0KDQpC
b3R0b20gbGluZSBpZiBJUHY2IGd1cnVzIHRoaW5rIHRvZGF5IHRoYXQgd2hhdCBoYXMgYmVlbiBk
ZWZpbmVkIHllYXJzIGJhY2sgaXQgaXMgdG8gc3RheSBhcyAiYmFzaWMgcnVsZSIgZm9yIHY2IGlu
IHRoZSB5ZWFycyB0byBjb21lIEkgY2FuIG9ubHkgd2lzaCB5b3UgYWxsIHRoZSBiZXN0Lg0KDQpX
ZSBoYXZlIGFuIGluc3RhbGxlZCBiYXNlIG9mIGJpbGxpb25zIG9mIElQdjYgY2FwYWJsZSBkZXZp
Y2VzIHRoYXQgZXhwZWN0IFJGQzI0NjAgYmVoYXZpb3VyIHRvIGxvb2sgYWZ0ZXIuDQoNCllvdXIg
U1BSSU5H4oCLIGdyb3VwIGlzIG9wZXJhdGluZyBpbiBjdXJyZW50bHkgYSB2ZXJ5IHNtYWxsIGdy
ZWVuIGZpZWxkIChhcmUgdGhlcmUgYW55IHByb2R1Y3Rpb24gZGVwbG95bWVudHMgb2YgU1IgeWV0
PyksIG91cnMgaXMgYSB2ZXJ5IGxhcmdlIGJyb3duIG9uZS4gIlRyaXZpYWwiIGNoYW5nZXMgZm9y
IHlvdSBhcmUgdHJpdmlhbCwgZm9yIHVzIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoZXkgZG9uJ3Qg
YnJlYWsgdGhpbmdzIGluIHVuZXhwZWN0ZWQgd2F5cywgYmVjYXVzZSByZWFsIGFuZCBleGlzdGlu
ZyBlbmQtdXNlcnMgYW5kIHByb2R1Y3Rpb24gbmV0d29yayBvcGVyYXRvcnMgbWF5IHN1ZmZlciBh
IHNpZ25pZmljYW50IGFuZCBwb3RlbnRpYWxseSBmaW5hbmNpYWxseSBjb3N0bHkgY29uc2VxdWVu
Y2UuDQoNClNlZ21lbnQgUm91dGluZyBpcyBpbiBwcm9kdWN0aW9uIGluIEJlbGwgbmV0d29yayAo
YXMgZXhwbGFpbiBhdCBNUExTIFBhcmlzIDIwMTcpIGFzIHdlbGwgYXMgZm9yIG90aGVycyBvcGVy
YXRvcnMgZm9yIG9idmlvdXMgcmVhc29uczsgc2ltcGxpY2l0eSBhbmQg4oCcbXVjaCBuZWVkZWQg
aW5ub3ZhdGlvbuKAnS4NCg0KUmVnYXJkcywNCk1hcmsuDQoNCg0KQ2hlZXJzLA0KUm9iZXJ0Lg0K
DQpQUy4gRm9sa3MgbGlrZSBTdGVmYW5vIGFuZCBteXNlbGYgZG8ga25vdyB2ZXJ5IHdlbGwgdHJh
dmVsaW5nIHRoZSB3b3JsZCB0byBlZHVjYXRlIGZvbGtzIHRvIGRlcGxveSBuZXcgdGVjaG5vbG9n
aWVzIHRoYXQgaXQgb25seSBnZXQncyBnb29kIHRyYWN0aW9uIHdoZXJlIHRoZXJlIGlzIGdvb2Qg
cmVhc29uIGZvciBpdC4gQ2xlYXJseSBkZXBsZXRpb24gb2YgdjQgc3BhY2UgYXMgcmVhbCBsaWZl
IHNob3dzIHdhcyBub3QgdGhlIHJlYXNvbiBmb3IgdjYgdG8gZ2FpbiBnbG9iYWwgbW9tZW50dW0u
IEV2ZW4gZm9sa3MgYXQgdmFyaW91cyBjb25mZXJlbmNzIGFkbWl0IGl0IHRoZXNlIGRheXMuDQoN
CkNHTiBjYXBhY2l0eS90aHJvdWdocHV0IGNvc3RzIGFuZCB0aGUgb3BleCBvZiBydW5uaW5nIHR3
byBwcm90b2NvbHMgd2lsbCBnZXQgdGhlbSBpbiB0aGUgZW5kLg0KDQoNCg0KDQoNCg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9y
ZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg==

--_000_0DF549512A954BB08F7CB6AB6BEDE40Fbellca_
Content-Type: text/html; charset="utf-8"
Content-ID: <415AE7B6328F4440AB145C234F477F3A@exchange.bell.ca>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0
IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5pcHY2ICZsdDtpcHY2LWJvdW5jZXNAaWV0Zi5vcmcm
Z3Q7IG9uIGJlaGFsZiBvZiBNYXJrIFNtaXRoICZsdDttYXJrenp6c21pdGhAZ21haWwuY29tJmd0
Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgQXByaWwgMjksIDIwMTcgYXQgMTE6MDcgUE08
YnI+DQo8Yj5UbzogPC9iPlJvYmVydCBSYXN6dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0Ozxi
cj4NCjxiPkNjOiA8L2I+Nm1hbiBXRyAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq
ZWN0OiA8L2I+UkU6IFByb3Bvc2VkIHJldmlzZWQgRXh0ZW5zaW9uIEhlYWRlciB0ZXh0IGZvciBy
ZmMyNDYwYmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gMzAgQXByLiAyMDE3IDExOjQ4LCAmcXVvdDtSb2JlcnQgUmFzenVrJnF1b3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiPnJvYmVydEByYXN6dWsubmV0
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPlNvIGlubm92YXRlIHdpdGhvdXQgdmlvbGF0aW5nIGJhc2lj
IHJ1bGVzLCBvbiB0aGUgb3BlbiBJbnRlcm5ldC4gT3IgdmlvbGF0ZSB0aGUgcnVsZXMgYWxsIHlv
dSBsaWtlLCBidXQgbWFrZSBzdXJlIGl0IGlzIG9ubHkgYW1vbmcgJnF1b3Q7Y29uc2VudGluZyBh
ZHVsdHMsJnF1b3Q7IHdoaWNoIG1lYW5zLCBpbiBhIGxvY2FsIGRvbWFpbi4gSXQncyBhbHdheXMg
YmVlbiB0aGlzIHdheSwNCiBzbyB0aGlzIHNob3VsZCBub3QgY29tZSBhcyBhIHN1cnByaXNlPzxi
cj4NCjxicj4NCkJlcnQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQmVydCw8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8geW91ciBxdW90ZSAmcXVvdDtJ
dCdzIGFsd2F5cyBiZWVuIHRoaXMgd2F5JnF1b3Q7IEkgY29tcGxldGVseSBhbmQgcmVzcGVjdGZ1
bGx5IGRpc2FncmVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgSUVURiB3b3VsZCBiZSBzdHVjayBpbiBub3QgdmlvbGF0
aW5nIG9uIHdoYXQgeW91IGNhbGwgJnF1b3Q7YmFzaWMgcnVsZXMmcXVvdDsgd2Ugd291bGQgc3Rp
bGwgYmUgY2xhc3NmdWxsIGFuZCBuZXZlciB1c2UgQ0lEUiwgd2Ugd2lsbCBzdGlsbCBiZSB1c2lu
ZyBSSVB2MSBmb3Igcm91dGluZyBhbmQgZm9yIGdvb2Qgb3IgZm9yIGJhZCB3ZSB3aWxsIG5ldmVy
IGhhdmUgTVAtQkdQIC4uLiBqdXN0IHRvIHF1b3RlIDElIG9mDQogYnJlYWtpbmcgdGhlICZxdW90
O2Fsd2F5cyZxdW90OyBydWxlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk5vbmUgb2YgdGhvc2UgbWFkZSBzdHJ1Y3R1cmFsIG9yIHNpemUgY2hhbmdlcyB0
byBJUHY0IHBhY2tldHMgd2hpbGUgaW4tZmxpZ2h0LiBUaGV5IHdlcmUgY29udHJvbCBwbGFuZSBw
cm90b2NvbCBjaGFuZ2VzIG9yIGZvcndhcmRpbmcgcHJvY2Vzc2luZyBjaGFuZ2VzIHRoYXQgbGVm
dCB0aGUgZm9ybWF0IG9mIHRoZSBwYWNrZXQgYW5kIHRoZSBzZW1hbnRpY3Mgb2YgaXRzIGZpZWxk
IHZhbHVlcyBhbG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+KEFuZCBubywgTVBMUyBvciBhbnkgb3RoZXIgbGluayBsYXllciBlbmNhcHN1
bGF0aW9uIGlzIG5vdCBjaGFuZ2luZyB0aGUgSVB2NCBwYWNrZXQgLSB0aGUgcmFuZ2Ugb2Ygb2N0
ZXRzIHN0YXJ0aW5nIGF0IHRoZSBJUHY0IGhlYWRlciBleHRlbmRpbmcgdGhyb3VnaCB0byB0aGUg
ZW5kIG9mIHRoZSBJUHY0IHBheWxvYWQuIFNhbWUgd2l0aCBhbiBJUHY2IHBhY2tldC4pPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXIgcHJv
cG9zZWQgY2hhbmdlIGlzIHVucHJlY2VkZW50ZWQuIE5vIG90aGVyIG5ldHdvcmsgbGF5ZXIgcHJv
dG9jb2wgYXMgZmFyIGFzIEknbSBhd2FyZSwgaW5jbHVkaW5nIElQdjQsIElQWCBhbmQgQXBwbGV0
YWxrIChJJ20gcHJldHR5IGNvbmZpZGVudCBpZiBERUNuZXQgYW5kIENMTlMgdG9vKSBoYXZlIG1h
ZGUgc3RydWN0dXJhbCBjaGFuZ2VzIHRvIHRoZWlyIG5ldHdvcmsgbGF5ZXIgUERVcyB3aGlsZSBp
bi1mbGlnaHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkFuIHVucHJlY2VkZW50ZWQgY2hhbmdlIG1heSBub3QgYmUgdHJpdmlhbCwgYW5kIGNl
cnRhaW5seSBzaG91bGRuJ3QgYmUgY2xhc3NpZmllZCBhcyBzdWNoIGR1cmluZyBhIGRvY3VtZW50
IG1haW50ZW5hbmNl4oCLIHVwZGF0ZSB0byBhIDE4JiM0MzsgeWVhciBvbGQgcHJvdG9jb2wgbGlr
ZSBJUHY2LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5v
dCBnZXR0aW5nIHdoeSBJUHY2IG1pbmlzdGVycyBhcmUgbGlrZSBtb25rcyBpbiBkZWVwZXN0IEJo
dXRhbidzIE1vbmFzdGVyaWVzLiBUaGUgYmFubmVyIGlzOiAmcXVvdDtXaGF0IGhhcyBiZWVuIGRl
ZmluZWQgeWVhcnMgYmFjayBpcyB0aGUgb25seSB0cnV0aCBmb3JldmVyLiZxdW90OzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBpdCBp
cyB0aW1lIHRvIG9wZW4gdGhlIHdpbmRvd3MgYW5kIGFzayB5b3Vyc2VsZiB3aHkgSVB2NiBkZXBs
b3ltZW50IGZvciBlbmQgY29uc3VtZXJzIGlzIHJlYWxseSBub3QgaGFwcGVpbmcgKGV4Y2VwdCB2
ZXJ5IGxvY2FsIG1hcmtldHMgbGlrZSBKYXBhbikuIE1heWJlIElQdjYgZGlkIG5vdCBjb21lIHdp
dGggc3VmaWNpZW50IHJlYXNvbiB0byBiZSBkZXBsb3llZCA/Pz88bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UncmUgb3V0IG9mIHRvdWNoIHdpdGggSVB2NiBk
ZXBsb3ltZW50IHN0YXR1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9pbnRsL2VuL2lw
djYvc3RhdGlzdGljcy5odG1sIj5odHRwczovL3d3dy5nb29nbGUuY29tL2ludGwvZW4vaXB2Ni9z
dGF0aXN0aWNzLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vc3RhdHMubGFicy5hcG5pYy5uZXQvaXB2
Ni8iPmh0dHBzOi8vc3RhdHMubGFicy5hcG5pYy5uZXQvaXB2Ni88L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g
MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIGl0IGNhbWUgd2l0aCB3YXkgdG9vIG11
Y2ggYmFnZ2FnZSBub3QgdG8gYmUgZGVwbG95ZWQgLi4gZXhhbXBsZSBob3N0cyBmb3JjZSB0byBw
aWNrIHdoaWNoIFBBIGFkZHJlc3MgdG8gdXNlIGFzIHNyYyAuLi4uIHRoaXMgaXMgc28gYnJva2Vu
ICE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SU1ITyBpZiB3ZSBjYW4gbm90IGdpdmUgUEkgdG8gZXZlcnlvbmUgd2UgYXJlIGRvaW5nIHNvbWV0
aGluZyB2ZXJ5IHdyb25nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgbm8gZnVydGhlciB0aGVuIGxhc3QgSUVURiBJIGhhZCBv
bmUgdmVuZG9yIHBlcnNvbiBjb21pbmcgdG8gbWUgYWZ0ZXIgY29tbWVudCBhdCBSVEdXRyB0aGF0
IFBJIGZvciBJUHY2IGlzIG5vdCBzbyBncmVhdCBpZGVhIHRoYXQgSSBpbW1lZGlhdGVseSB1bmRl
cnN0b29kIHdoeSBJUHY2IGlzIGluIHN1Y2ggcG9vciBzdGF0ZS4gSGUgaW5zaXN0ZWQgZXZlcnlv
bmUgc2hvdWxkIHVzZSBQQSBzcGFjZS4gSXMgdGhpcw0KIHdoYXQgeW91IGFsbCByZWNvbW1lbmQg
Pz8/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g
MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb3R0b20gbGluZSBpZiBJUHY2IGd1cnVz
IHRoaW5rIHRvZGF5IHRoYXQgd2hhdCBoYXMgYmVlbiBkZWZpbmVkIHllYXJzIGJhY2sgaXQgaXMg
dG8gc3RheSBhcyAmcXVvdDtiYXNpYyBydWxlJnF1b3Q7IGZvciB2NiBpbiB0aGUgeWVhcnMgdG8g
Y29tZSBJIGNhbiBvbmx5IHdpc2ggeW91IGFsbCB0aGUgYmVzdC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGFuIGluc3RhbGxlZCBiYXNlIG9mIGJp
bGxpb25zIG9mIElQdjYgY2FwYWJsZSBkZXZpY2VzIHRoYXQgZXhwZWN0IFJGQzI0NjAgYmVoYXZp
b3VyIHRvIGxvb2sgYWZ0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPllvdXIgU1BSSU5H4oCLIGdyb3VwIGlzIG9wZXJhdGluZyBpbiBjdXJy
ZW50bHkgYSB2ZXJ5IHNtYWxsIGdyZWVuIGZpZWxkIChhcmUgdGhlcmUgYW55IHByb2R1Y3Rpb24g
ZGVwbG95bWVudHMgb2YgU1IgeWV0PyksIG91cnMgaXMgYSB2ZXJ5IGxhcmdlIGJyb3duIG9uZS4g
JnF1b3Q7VHJpdmlhbCZxdW90OyBjaGFuZ2VzIGZvciB5b3UgYXJlIHRyaXZpYWwsIGZvciB1cyB3
ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGV5IGRvbid0IGJyZWFrDQogdGhpbmdzIGluIHVuZXhwZWN0
ZWQgd2F5cywgYmVjYXVzZSByZWFsIGFuZCBleGlzdGluZyBlbmQtdXNlcnMgYW5kIHByb2R1Y3Rp
b24gbmV0d29yayBvcGVyYXRvcnMgbWF5IHN1ZmZlciBhIHNpZ25pZmljYW50IGFuZCBwb3RlbnRp
YWxseSBmaW5hbmNpYWxseSBjb3N0bHkgY29uc2VxdWVuY2UuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNlZ21lbnQgUm91dGluZyBpcyBpbiBwcm9kdWN0aW9uIGluIEJlbGwgbmV0d29yayAoYXMg
ZXhwbGFpbiBhdCBNUExTIFBhcmlzIDIwMTcpIGFzIHdlbGwgYXMgZm9yIG90aGVycyBvcGVyYXRv
cnMgZm9yIG9idmlvdXMgcmVhc29uczsgc2ltcGxpY2l0eSBhbmQg4oCcbXVjaCBuZWVkZWQgaW5u
b3ZhdGlvbuKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk1hcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Sb2JlcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlBTLiBGb2xrcyBsaWtlIFN0ZWZhbm8gYW5kIG15c2VsZiBkbyBrbm93IHZlcnkg
d2VsbCB0cmF2ZWxpbmcgdGhlIHdvcmxkIHRvIGVkdWNhdGUgZm9sa3MgdG8gZGVwbG95IG5ldyB0
ZWNobm9sb2dpZXMgdGhhdCBpdCBvbmx5IGdldCdzIGdvb2QgdHJhY3Rpb24gd2hlcmUgdGhlcmUg
aXMgZ29vZCByZWFzb24gZm9yIGl0LiBDbGVhcmx5IGRlcGxldGlvbiBvZiB2NCBzcGFjZSBhcyBy
ZWFsIGxpZmUgc2hvd3Mgd2FzDQogbm90IHRoZSByZWFzb24gZm9yIHY2IHRvIGdhaW4gZ2xvYmFs
IG1vbWVudHVtLiBFdmVuIGZvbGtzIGF0IHZhcmlvdXMgY29uZmVyZW5jcyBhZG1pdCBpdCB0aGVz
ZSBkYXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNHTiBj
YXBhY2l0eS90aHJvdWdocHV0IGNvc3RzIGFuZCB0aGUgb3BleCBvZiBydW5uaW5nIHR3byBwcm90
b2NvbHMgd2lsbCBnZXQgdGhlbSBpbiB0aGUgZW5kLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48
YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_0DF549512A954BB08F7CB6AB6BEDE40Fbellca_--


From nobody Sun Apr 30 17:13:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BEC126CF6 for ; Sun, 30 Apr 2017 17:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-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 u_gl8RuG3Sfz for ; Sun, 30 Apr 2017 17:13:10 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8328C124C27 for ; Sun, 30 Apr 2017 17:11:31 -0700 (PDT)
Received: from [85.158.136.35] by server-7.bemta-5.messagelabs.com id 06/04-02181-13D76095; Mon, 01 May 2017 00:11:29 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgk+JIrShJLcpLzFFi42I5t4YxWVevli3 SYMsHFYut7/exWbw8+57JYv3uR0wOzB5Tfm9k9dg56y67x5IlP5kCmKNYM/OS8isSWDN+Lf/A XjDXpmJp3z/GBsYd1l2MnBwSAn4Sf1c9Y+ti5OIQEtjPKDH31Ul2COcGo8TbtYuZIZzTjBJNr 5cBlXFwsAnoSMx5IQ/SLSIQKXHmaSMrSJhZQFbi2qRIkLCwgJPE7R8LWSBKnCXu9O5ng7CtJP at7GcCsVkEVCR+fVjOCGLzAsUPrJ3HDmILCeRJXHmwGCzOKWArsa+lC2wOo4CYxPdTa8B6mQX EJW49mc8E8YCAxJI955khbFGJl4//sYLYogJ6Etc+rGSBiOtInL3+hBHCNpDYunQfVFxBYu70 zSwQ52tKrN+lDzHeXuJ2y35GCFtRYkr3Q3aIMwUlTs58AtUqKXFwxQ0WiJMVJebdessCCan5j BLbJp9ihyiyl3h4+SvTBEa5WUjOnoWwbhaSdbOQrJuFZN0CRtZVjOrFqUVlqUW6lnpJRZnpGS W5iZk5uoYGpnq5qcXFiempOYlJxXrJ+bmbGIEphAEIdjCubXU+xCjJwaQkyru+nC1SiC8pP6U yI7E4I76oNCe1+BCjDAeHkgTvomqgnGBRanpqRVpmDjCZwaQlOHiURHgPgqR5iwsSc4sz0yFS pxgVpcR5i0ESAiCJjNI8uDZYAr3EKCslzMsIdIgQT0FqUW5mCar8K0ZxDkYlYd5jIFN4MvNK4 Ka/AlrMBLS4Xo0FZHFJIkJKqoHRe/YxriNTfTXkFD7v/tLvZfji7vLrP/e/2yhktDQvMW31qp sXXY/IbIvvWVVuc8SzSXnHhJS6+5qTROP+9K+cOOH108zIN8tEZKInb9t3aleq77kFx3rzmyf +d1ErfiTnWnNEoNw94NiXRf41byR2ZG/Onp/7/daM3NM8VTlf9v14/+mj04HrOUosxRmJhlrM RcWJAPNrydCbAwAA
X-Env-Sender: daniel.voyer@bell.ca
X-Msg-Ref: server-10.tower-125.messagelabs.com!1493597485!72454839!1
X-Originating-IP: [206.172.1.99]
X-StarScan-Received: 
X-StarScan-Version: 9.4.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7350 invoked from network); 1 May 2017 00:11:26 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.99) by server-10.tower-125.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 May 2017 00:11:26 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-DOR.bell.corp.bce.ca
Received: from DG2MBX01-WYN.bell.corp.bce.ca (198.235.121.232) by EX13EDGE02-DOR.bell.corp.bce.ca (198.235.121.55) with Microsoft SMTP Server id 15.0.1210.3; Sun, 30 Apr 2017 20:11:21 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX01-WYN.bell.corp.bce.ca (2002:8eb6:1213::8eb6:1213) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Apr 2017 20:11:23 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39%23]) with mapi id 15.00.1210.000; Sun, 30 Apr 2017 20:11:23 -0400
From: "Voyer, Daniel" 
To: "Stefano Previdi (sprevidi)" , Bob Hinden 
CC: IPv6 List 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSvU2GLj2bkcaFakK4L3vH7EBFBaHZZUuAgAU/BoA=
Date: Mon, 1 May 2017 00:11:23 +0000
Message-ID: <2F6B2177-A0CE-4607-9786-A32C4356E734@bell.ca>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
In-Reply-To: <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.26]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5A348F5549A62948A0C16E877918CA37@exchange.bell.ca>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-DOR.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.121.232 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-DOR.bell.corp.bce.ca
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 May 2017 00:13:13 -0000

SSBhZ3JlZSBhbmQgc3VwcG9ydC4NCg0KZGFuDQoNCk9uIDIwMTctMDQtMjcsIDg6MDQgQU0sICJp
cHY2IG9uIGJlaGFsZiBvZiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSIgPGlwdjYtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCg0KICAg
IA0KICAgID4gT24gQXByIDI1LCAyMDE3LCBhdCAxMjo1MiBBTSwgQm9iIEhpbmRlbiA8Ym9iLmhp
bmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBIaSwNCiAgICA+IA0KICAgID4g
QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgdGV4dCBpbiBT
ZWN0aW9uIDQsIEkgaGF2ZSBzb21lIG5ldyB0ZXh0IHRvIHByb3Bvc2UuICBJIHRoaW5rIHRoaXMg
aXMgc2lnbmlmaWNhbnRseSBpbXByb3ZlZCBhbmQgc2hvdWxkIHJlc29sdmUgbWFueSBvZiB0aGUg
aXNzdWVkIHJhaXNlZC4NCiAgICA+IA0KICAgID4gQ2hhbmdlcyBpbmNsdWRlIHNlcGFyYXRlIGRl
c2NyaXB0aW9uIG9mIGJlaGF2aW9ycyBleHRlbnNpb24gaGVhZGVycyBhbmQgdGhlIGhvcC1ieS1o
b3Agb3B0aW9uIGhlYWRlciwgcmVtb3ZlIOKAnGV4YW1pbmXigJ0gZnJvbSB0aGUgZmlyc3QgcGFy
YWdyYXBoLiAgSSByZW1vdmVkIOKAnGV4YW1pbmXigJ0gYmVjYXVzZSBJIGFtIGNvbnZpbmNlZCBp
dOKAmXMgbm90IHN1c3RhaW5hYmxlIHRvIHNheSBhIG5vZGUgY2Fu4oCZdCBleGFtaW5lIGV4dGVu
c2lvbiBnaXZlbiBob3cgd2lkZXNwcmVhZCB0aGlzIGJlaGF2aW9yIGlzLiAgSSBhbHNvIHJlbW92
ZWQgdGhlIHJlZmVyZW5jZSB0byBSRkM3MDQ1IGJlY2F1c2UgZXhhbWluZSBpcyByZW1vdmVkLiAg
UkZDNzA0NSBpcyByZWZlcmVuY2VkIGluIHRoZSByZWNlbnRseSB1cGRhdGVkIFNlY3VyaXR5IENv
bnNpZGVyYXRpb25zIHNlY3Rpb24uDQogICAgPiANCiAgICA+IEkgcmVtb3ZlZCB0aGUg4oCcaW5j
bHVkaW5nIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG5vZGVz4oCdIHRleHQgZnJvbSB0aGUg
cGFyYWdyYXBoIG9uIHRoZSBob3AtYnktaG9wIG9wdGlvbnMgaGVhZGVyIGJlY2F1c2UgSSBkb27i
gJl0IHRoaW5rIHdlIG5lZWQgdG8gbWVudGlvbiB0aGUgc291cmNlLCBhbmQgdGhlcmUgaXMgYSB3
aG9sZSBwYXJhZ3JhcGggZGVzY3JpYmUgd2hhdCBoYXBwZW5zIGF0IHRoZSBkZXN0aW5hdGlvbiBu
b2RlLiAgSSBhbHNvIGFkZGVkIHRoZSB0ZXh0IGFib3V0IGZyb20gdGhlIGZpcnN0IHBhcmFncmFw
aCBhYm91dCByZWFjaGluZyB0aGUgZGVzdGluYXRpb24gdG8gdGhlIGhvcC1ieS1ob3AgaGVhZGVy
IHBhcmFncmFwaC4NCiAgICA+IA0KICAgID4gSSBhbHNvIG1vdmVkICh3aXRob3V0IGNoYW5nZSkg
dGhlIOKAnEF0IHRoZSBEZXN0aW5hdGlvbiBub2RlLi4u4oCdIHRleHQgZnJvbSB0aGUgZmlyc3Qg
cGFyYWdyYXBoIHRvIGEgbmV3IHRoaXJkIHBhcmFncmFwaC4gIEl0IGFwcGxpZXMgdG8gYWxsIGV4
dGVuc2lvbiBoZWFkZXJzLg0KICAgID4gDQogICAgPiBDVVJSRU5UIGFuZCBORVcgdGV4dCBiZWxv
dy4gIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQogICAgPiANCiAgICA+IEJvYg0KICAgID4g
DQogICAgPiANCiAgICA+ICAgQ1VSUkVOVA0KICAgID4gDQogICAgPiAgIFdpdGggb25lIGV4Y2Vw
dGlvbiwgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIG5vdCBleGFtaW5lZCwgcHJvY2Vzc2VkLA0KICAg
ID4gICBpbnNlcnRlZCwgb3IgZGVsZXRlZCBieSBhbnkgbm9kZSBhbG9uZyBhIHBhY2tldCdzIGRl
bGl2ZXJ5IHBhdGgsDQogICAgPiAgIHVudGlsIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgbm9kZSAo
b3IgZWFjaCBvZiB0aGUgc2V0IG9mIG5vZGVzLCBpbg0KICAgID4gICB0aGUgY2FzZSBvZiBtdWx0
aWNhc3QpIGlkZW50aWZpZWQgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YNCiAg
ICA+ICAgdGhlIElQdjYgaGVhZGVyLiAgTm90ZTogSWYgYW4gaW50ZXJtZWRpYXRlIGZvcndhcmRp
bmcgbm9kZSBleGFtaW5lcw0KICAgID4gICBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBhbnkgcmVh
c29uLCBpdCBtdXN0IGRvIHNvIGluIGFjY29yZGFuY2Ugd2l0aA0KICAgID4gICB0aGUgcHJvdmlz
aW9ucyBvZiBbUkZDNzA0NV0uICBBdCB0aGUgRGVzdGluYXRpb24gbm9kZSwgbm9ybWFsDQogICAg
PiAgIGRlbXVsdGlwbGV4aW5nIG9uIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBvZiB0aGUgSVB2NiBo
ZWFkZXIgaW52b2tlcw0KICAgID4gICB0aGUgbW9kdWxlIHRvIHByb2Nlc3MgdGhlIGZpcnN0IGV4
dGVuc2lvbiBoZWFkZXIsIG9yIHRoZSB1cHBlci1sYXllcg0KICAgID4gICBoZWFkZXIgaWYgbm8g
ZXh0ZW5zaW9uIGhlYWRlciBpcyBwcmVzZW50LiAgVGhlIGNvbnRlbnRzIGFuZCBzZW1hbnRpY3MN
CiAgICA+ICAgb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyIGRldGVybWluZSB3aGV0aGVyIG9yIG5v
dCB0byBwcm9jZWVkIHRvIHRoZQ0KICAgID4gICBuZXh0IGhlYWRlci4gIFRoZXJlZm9yZSwgZXh0
ZW5zaW9uIGhlYWRlcnMgbXVzdCBiZSBwcm9jZXNzZWQgc3RyaWN0bHkNCiAgICA+ICAgaW4gdGhl
IG9yZGVyIHRoZXkgYXBwZWFyIGluIHRoZSBwYWNrZXQ7IGEgcmVjZWl2ZXIgbXVzdCBub3QsIGZv
cg0KICAgID4gICBleGFtcGxlLCBzY2FuIHRocm91Z2ggYSBwYWNrZXQgbG9va2luZyBmb3IgYSBw
YXJ0aWN1bGFyIGtpbmQgb2YNCiAgICA+ICAgZXh0ZW5zaW9uIGhlYWRlciBhbmQgcHJvY2VzcyB0
aGF0IGhlYWRlciBwcmlvciB0byBwcm9jZXNzaW5nIGFsbA0KICAgID4gICBwcmVjZWRpbmcgb25l
cy4NCiAgICA+IA0KICAgID4gICBUaGUgZXhjZXB0aW9uIHJlZmVycmVkIHRvIGluIHRoZSBwcmVj
ZWRpbmcgcGFyYWdyYXBoIGlzIHRoZSBIb3AtYnktDQogICAgPiAgIEhvcCBPcHRpb25zIGhlYWRl
ciwgd2hpY2ggY2FycmllcyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBleGFtaW5lZA0KICAgID4g
ICBhbmQgcHJvY2Vzc2VkIGJ5IGV2ZXJ5IG5vZGUgYWxvbmcgYSBwYWNrZXQncyBkZWxpdmVyeSBw
YXRoLCBpbmNsdWRpbmcNCiAgICA+ICAgdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gbm9kZXMu
ICBUaGUgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwNCiAgICA+ICAgd2hlbiBwcmVzZW50LCBt
dXN0IGltbWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJdHMgcHJlc2VuY2UNCiAg
ICA+ICAgaXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhlYWRlciBm
aWVsZCBvZiB0aGUgSVB2Ng0KICAgID4gICBoZWFkZXIuDQogICAgPiANCiAgICA+ICAgTkVXDQog
ICAgPiANCiAgICA+ICAgRXh0ZW5zaW9uIGhlYWRlcnMgKGV4Y2VwdCBmb3IgdGhlIEhvcC1ieS1I
b3AgT3B0aW9ucyBoZWFkZXIpIGFyZSBub3QNCiAgICANCiAgICANCiAgICBteSByZWNvbW1lbmRh
dGlvbiBpcyB0byBjaGFuZ2Ug4oCcYXJlIG5vdOKAnSB3aXRoIOKAnFNIT1VMRCBOT1TigJ0uDQog
ICAgDQogICAgVGhpcyBkb2VzbuKAmXQgY2hhbmdlIHdoYXQgdGhlIGN1cnJlbnQgdGV4dCBhc3N1
bWVzIHdoaWxlIGl0IHVzZXMgYSBtb3JlIGZvcm1hbCBsYW5ndWFnZS4NCiAgICANCiAgICBzLg0K
ICAgIA0KICAgIA0KICAgID4gICBwcm9jZXNzZWQsIGluc2VydGVkLCBvciBkZWxldGVkIGJ5IGFu
eSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkNCiAgICA+ICAgcGF0aCwgdW50aWwgdGhl
IHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMsDQog
ICAgPiAgIGluIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVzdGlu
YXRpb24gQWRkcmVzcyBmaWVsZA0KICAgID4gICBvZiB0aGUgSVB2NiBoZWFkZXIuDQogICAgPiAN
CiAgICA+ICAgVGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBoZWFkZXIgaXMgbm90IGluc2VydGVkIG9y
IGRlbGV0ZWQsIGJ1dCBtYXkgYmUNCiAgICA+ICAgZXhhbWluZWQgYW5kIHByb2Nlc3NlZCBieSBl
dmVyeSBub2RlIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCwNCiAgICA+ICAgdW50aWwg
dGhlIHBhY2tldCByZWFjaGVzIHRoZSBub2RlIChvciBlYWNoIG9mIHRoZSBzZXQgb2Ygbm9kZXMs
IGluDQogICAgPiAgIHRoZSBjYXNlIG9mIG11bHRpY2FzdCkgaWRlbnRpZmllZCBpbiB0aGUgRGVz
dGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZg0KICAgID4gICB0aGUgSVB2NiBoZWFkZXIuICBUaGUg
SG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciwgd2hlbiBwcmVzZW50LCBtdXN0DQogICAgPiAgIGlt
bWVkaWF0ZWx5IGZvbGxvdyB0aGUgSVB2NiBoZWFkZXIuICBJdHMgcHJlc2VuY2UgaXMgaW5kaWNh
dGVkIGJ5IHRoZQ0KICAgID4gICB2YWx1ZSB6ZXJvIGluIHRoZSBOZXh0IEhlYWRlciBmaWVsZCBv
ZiB0aGUgSVB2NiBoZWFkZXIuDQogICAgPiANCiAgICA+ICAgQXQgdGhlIERlc3RpbmF0aW9uIG5v
ZGUsIG5vcm1hbCBkZW11bHRpcGxleGluZyBvbiB0aGUgTmV4dCBIZWFkZXINCiAgICA+ICAgZmll
bGQgb2YgdGhlIElQdjYgaGVhZGVyIGludm9rZXMgdGhlIG1vZHVsZSB0byBwcm9jZXNzIHRoZSBm
aXJzdA0KICAgID4gICBleHRlbnNpb24gaGVhZGVyLCBvciB0aGUgdXBwZXItbGF5ZXIgaGVhZGVy
IGlmIG5vIGV4dGVuc2lvbiBoZWFkZXIgaXMNCiAgICA+ICAgcHJlc2VudC4gIFRoZSBjb250ZW50
cyBhbmQgc2VtYW50aWNzIG9mIGVhY2ggZXh0ZW5zaW9uIGhlYWRlcg0KICAgID4gICBkZXRlcm1p
bmUgd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB0byB0aGUgbmV4dCBoZWFkZXIuICBUaGVyZWZv
cmUsDQogICAgPiAgIGV4dGVuc2lvbiBoZWFkZXJzIG11c3QgYmUgcHJvY2Vzc2VkIHN0cmljdGx5
IGluIHRoZSBvcmRlciB0aGV5IGFwcGVhcg0KICAgID4gICBpbiB0aGUgcGFja2V0OyBhIHJlY2Vp
dmVyIG11c3Qgbm90LCBmb3IgZXhhbXBsZSwgc2NhbiB0aHJvdWdoIGENCiAgICA+ICAgcGFja2V0
IGxvb2tpbmcgZm9yIGEgcGFydGljdWxhciBraW5kIG9mIGV4dGVuc2lvbiBoZWFkZXIgYW5kIHBy
b2Nlc3MNCiAgICA+ICAgdGhhdCBoZWFkZXIgcHJpb3IgdG8gcHJvY2Vzc2luZyBhbGwgcHJlY2Vk
aW5nIG9uZXMuDQogICAgPiANCiAgICA+ICAgRU5EIE5FVw0KICAgID4gDQogICAgPiAtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KICAgID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQogICAgPiBp
cHY2QGlldGYub3JnDQogICAgPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0K
ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQogICAgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0
DQogICAgaXB2NkBpZXRmLm9yZw0KICAgIEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCiAgICAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAg
IA0KDQo=


From nobody Sun Apr 30 17:14:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E71128B8D for ; Sun, 30 Apr 2017 17:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 WBJvq8KDFIT8 for ; Sun, 30 Apr 2017 17:14:48 -0700 (PDT)
Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A91B129441 for ; Sun, 30 Apr 2017 17:13:01 -0700 (PDT)
Received: from [194.106.220.35] by server-4.bemta-6.messagelabs.com id 66/08-02956-81C76095; Mon, 01 May 2017 00:06:48 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjk+JIrShJLcpLzFFi42Jxdn3WqitewxZ pcLnB2KJ3zQY2i5dn3zNZNC1sYnZg9vh98A2zx5IlP5k8dm9cwBTAHMWamZeUX5HAmrF830n2 gpXCFTeXlzcwdgh3MXJySAj4SfReusbWxcjFISSwl1Hi9vqNLBDODUaJlqcXWSGc04wSa/s3M ncxcnCwCehIzHkhD2KKCERLzPjiAjKIWUBa4taS50wgtrCAk8TtHwtZQGwRAWeJO7372SDsOo mL33eCxVkEVCR+7J7ABjKGV8BK4vktc5CwkMAcVokt15JAbE4BX4nLkw+DlTMKiEl8P7WGCWK VuMStJ/OZIO4XkFiy5zwzhC0q8fLxP1YQW1RAT+Lah5UsEHEdibPXnzBC2AYSW5fuYwFZKyGg IHHtRiSIySygKbF+lz7EdHuJSXMes0PYihJTuh+C2bwCghInZz6BmigpcXDFDRaIixUl5t16C w20eYwS1xc/giqyl/h/6QfjBEa5WUiunoWwbhaSdbOQrJuFZN0CRtZVjBrFqUVlqUW6xgZ6SU WZ6RkluYmZObqGBmZ6uanFxYnpqTmJScV6yfm5mxiB6YMBCHYw/l0beIhRkoNJSZR3fTlbpBB fUn5KZUZicUZ8UWlOavEhRhkODiUJ3vVVQDnBotT01Iq0zBxgIoNJS3DwKInwXgBJ8xYXJOYW Z6ZDpE4xKkqJ8z4GSQiAJDJK8+DaYMnzEqOslDAvI9AhQjwFqUW5mSWo8q8YxTkYlYR5r4FM4 cnMK4Gb/gpoMRPQ4no1FpDFJYkIKakGxpSFyRdY/+5fEZ0n7P1BcLNZdfa/5Cmn9pt8jvRewZ npsVv6ydpnmUubVZNMb2feX8p9/c8PwwSB6eFtnA1bs+w1/nedWXHujP7ZGQnN9QmmDJv/86h /2v/4vNNf6Zn1f1s+sG7MqpjXPDNp3uypN/3NlG+vCmnWq0godmEUL7Z+qO305IbBLiWW4oxE Qy3mouJEAHYI70aZAwAA
X-Env-Sender: daniel.voyer@bell.ca
X-Msg-Ref: server-12.tower-91.messagelabs.com!1493597206!24082011!1
X-Originating-IP: [67.69.230.133]
X-StarScan-Received: 
X-StarScan-Version: 9.4.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26891 invoked from network); 1 May 2017 00:06:47 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-12.tower-91.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 1 May 2017 00:06:47 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca
Received: from DG2MBX01-WYN.bell.corp.bce.ca (198.235.102.33) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1210.3; Sun, 30 Apr 2017 20:06:44 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca (2002:8eb6:1215::8eb6:1215) by DG2MBX01-WYN.bell.corp.bce.ca (2002:8eb6:1213::8eb6:1213) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 30 Apr 2017 20:06:45 -0400
Received: from DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39]) by DG2MBX03-WYN.bell.corp.bce.ca ([fe80::6475:3594:7cbe:fc39%23]) with mapi id 15.00.1210.000; Sun, 30 Apr 2017 20:06:45 -0400
From: "Voyer, Daniel" 
To: "Manfredi, Albert E" , Robert Raszuk 
CC: 6man WG 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
Thread-Topic: Proposed revised Extension Header text for rfc2460bis
Thread-Index: AQHSvU2GLj2bkcaFakK4L3vH7EBFBaHZZUuAgACEfACAAA+WgIABK9yAgAAWV4CAAICQgIAAGHYAgAAFxACAABbmAIAAfcOAgADQ7YCAAWMVgA==
Date: Mon, 1 May 2017 00:06:45 +0000
Message-ID: 
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.28]
Content-Type: text/plain; charset="utf-8"
Content-ID: <58E9933DFAE0A64FA0AEDB367803497F@exchange.bell.ca>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning daniel.voyer@bell.ca discourages use of 198.235.102.33 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 May 2017 00:14:50 -0000

DQoNCk9uIDIwMTctMDQtMjksIDY6NTUgUE0sICJpcHY2IG9uIGJlaGFsZiBvZiBNYW5mcmVkaSwg
QWxiZXJ0IEUiIDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFsYmVydC5lLm1h
bmZyZWRpQGJvZWluZy5jb20+IHdyb3RlOg0KDQogICAgRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYt
Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNCiAgICANCiAgICA+
IFBTLiBKdXN0IGxvb2sgYXQgY3VycmVudCBwcm9wcmlldGFyeSBTRC1XQU5zIG9yIGludGVyb3Bl
cmFibGUgSUVURg0KICAgID4gTElTUC4gVGhleSBhcmUgYWxsIC0gYnkgZGVzaWduIC0gSW50ZXJu
ZXQgd2lkZS4gU28gaXQgaXMgaW4gZ2VuZXJhbA0KICAgID4gcG9zc2libGUgdG8gaW5ub3ZhdGUg
YXQgSW50ZXJuZXQgc2NhbGUuIFdoeSByZXZpc2VkIGluIDIwMTcgcmZjMjQ2MA0KICAgID4ganVz
dCBkb2VzIG5vdCBhY2NvbW9kYXRlIHRoZSBjdXJyZW50IG5lZWRzIGFuZCBsYXRlc3QgZGV2ZWxv
cG1lbnRzDQogICAgPiBpIElQdjYgc3BhY2UgPw0KICAgIA0KICAgIFRoZSBnZW5lcmFsIGZlZWxp
bmcgaGFzIGJlZW4gZXhwcmVzc2VkIG1hbnkgdGltZXMuIEdvIGFoZWFkIGFuZCBpbm5vdmF0ZSwg
YnV0IG5vdCBieSB2aW9sYXRpbmcgY2VydGFpbiBmdW5kYW1lbnRhbCBydWxlcywgZXN0YWJsaXNo
ZWQgd2F5IGJhY2sgd2hlbi4gUGVvcGxlIGNvdW50IG9uIHRob3NlIHJ1bGVzIHJlbWFpbmluZyBp
biBwbGFjZS4gQnkgdmlvbGF0aW5nIHRoZW0sIHlvdSB3aWxsIGJyZWFrIHRoaW5ncyB0aGF0IHdv
cmsganVzdCBmaW5lIG5vdy4NCiAgICANCiAgICBTbyBpbm5vdmF0ZSB3aXRob3V0IHZpb2xhdGlu
ZyBiYXNpYyBydWxlcywgb24gdGhlIG9wZW4gSW50ZXJuZXQuIE9yIHZpb2xhdGUgdGhlIHJ1bGVz
IGFsbCB5b3UgbGlrZSwgYnV0IG1ha2Ugc3VyZSBpdCBpcyBvbmx5IGFtb25nICJjb25zZW50aW5n
IGFkdWx0cywiIHdoaWNoIG1lYW5zLCBpbiBhIGxvY2FsIGRvbWFpbi4gSXQncyBhbHdheXMgYmVl
biB0aGlzIHdheSwgc28gdGhpcyBzaG91bGQgbm90IGNvbWUgYXMgYSBzdXJwcmlzZT8NCiAgICAN
Ckkgc3VwcG9ydCBSb2JlcnQgUi4gaGVyZSwgb3BlcmF0b3JzIG5lZWQgaW5ub3ZhdGlvbnMgd2hp
Y2ggbWF5IHJlcXVpcmVzIHRvIHJlLXZpc2l0IHNvbWUgcnVsZXMuIFRoZSBJRVRGIOKAnE1VU1Qg
Tk9U4oCdIGJlY29tZSBhIGJvdHRsZW5lY2sgZm9yIGNoYW5nZSwgaXQgcmVxdWlyZXMgYW4gb3Bl
biBtaW5kLg0KDQpXaXRoIHRoYXQgc2FpZDsgYXJlIHdlIHNheWluZyB0aGUgZm9sbG93aW5nIOKA
nGJ1dCBub3QgYnkgdmlvbGF0aW5nIGNlcnRhaW4gZnVuZGFtZW50YWwgcnVsZXPigJ0gd2l0aCBp
biBtaW5kIHRoYXQgYWxsb3cgYSDigJxoZWFkZXIgaW5zZXJ0aW9uIGlzIOKAnHZpb2xhdGluZyBh
IOKAnGZ1bmRhbWVudGFsIHJ1bGVz4oCdID8gSSBkb27igJl0IHVuZGVyc3RhbmQgd2h5IGluIHRo
aXMgbGlzdCB3ZSBhcmUgbm93IGF0IHRoYXQgZXh0cmVtZSA/DQoNCiAgICBCZXJ0DQogICAgDQog
ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiAgICBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QN
CiAgICBpcHY2QGlldGYub3JnDQogICAgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAgIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg
DQoNCg==


From nobody Sun Apr 30 17:32:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0CD1294F4 for ; Sun, 30 Apr 2017 17:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DA0QX_jUHWO0 for ; Sun, 30 Apr 2017 17:32:13 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 E3CB81294CF for ; Sun, 30 Apr 2017 17:30:16 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id g49so599000uaa.1 for ; Sun, 30 Apr 2017 17:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DivwKn9kAr2w4ocwHcFuhRFXLoSwG0VmMzaml1PxuBs=; b=ICtG51nrzE/kXo1yxwwKNvyaFoabyIqiEWOGDkJzZvH4NiaBSbGglNUn+zhdx6ZehM Vj5U/pR8EkodVOU6CWrGA7hnDFme5mUDrRnHjA4SGfQIuMGmkLmvyW6hWCfrwQsMjgCC zSPZr8C087z4TR+lmz5z/IeDXSM55QkFjOXI/IzdhXwo0LSanldo9XviTmQnWTlSSPmN cV5yGaFPz1JcCKnofm/TYDm3Yziw7H+OjQUB71tcpNKoJglruDqb3vN+GLDkqbotwXy8 MGhg3pk5BUtryqLj3M2PEHp7L03H2dC1mJ3sw2BdH28R1RTIucQrAzWowpFogUEhTRQc GJTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DivwKn9kAr2w4ocwHcFuhRFXLoSwG0VmMzaml1PxuBs=; b=sNTuwn1g7Na8PB3qfxnPh5yTIDExT+U/P2YyLtsOTBAXOVFACiIx17PaFIPsJzqVGW PE3hOQm/E67x8jQcJ3f+ducNfeG4f0ahElX5kS/lOtmK0ThRHf+vjGj/jTpWVkmy9vu1 jAtb5+Rlf9K3kpvIYTIjZiTf8nGkDSMPa1taXqYTTnOyQDtjMhbu/yG9riKomuFVZJ+V 43Kc3dffSOgNgmZFdNmP3/5bxvB8gn/KxfQ5H3JRdezmDoxxeZ1lYPB5RZ/5alByMmoG 5eV7rz+a38GH1vnKVynTQq0T9RsFqx8hZOrJNmoAmQjdIkRlU/F69mDiPBc/6L/5HY+Q Pr5Q==
X-Gm-Message-State: AN3rC/7E40wax2p2MIsf+Oy8srCi6w0WqHK2HEvwK1d6njjuxbxSYnXf rLTU/gKyfZPnunyYUuWaw8LapiMeaA==
X-Received: by 10.176.24.85 with SMTP id j21mr12170294uag.125.1493598615915; Sun, 30 Apr 2017 17:30:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.55.130 with HTTP; Sun, 30 Apr 2017 17:29:44 -0700 (PDT)
In-Reply-To: <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca>
References: <9A6886D9-20BD-438F-B2FD-F497958F5D12@gmail.com> <8CFD4E13-2118-4119-90EF-51A2350E079D@cisco.com> <59024D70.4030408@cisco.com>  <5903560D.50803@cisco.com> <7210ad13-7953-e1ba-ae18-6e20db89f358@si6networks.com>    <7493f1f4-50d3-aa6a-781a-ba2f23075ff7@gmail.com>         <0DF54951-2A95-4BB0-8F7C-B6AB6BEDE40F@bell.ca>
From: Mark Smith 
Date: Mon, 1 May 2017 10:29:44 +1000
Message-ID: 
Subject: Re: Proposed revised Extension Header text for rfc2460bis
To: "Voyer, Daniel" 
Cc: Robert Raszuk , 6man WG 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 May 2017 00:32:15 -0000

On 1 May 2017 at 09:56, Voyer, Daniel  wrote:
>
>
>
>

>
>
> Your SPRING group is operating in currently a very small green field (are
> there any production deployments of SR yet?), ours is a very large brown
> one. "Trivial" changes for you are trivial, for us we need to make sure t=
hey
> don't break things in unexpected ways, because real and existing end-user=
s
> and production network operators may suffer a significant and potentially
> financially costly consequence.
>
>
>
> Segment Routing is in production in Bell network (as explain at MPLS Pari=
s
> 2017) as well as for others operators for obvious reasons; simplicity and
> =E2=80=9Cmuch needed innovation=E2=80=9D.
>

Presumably MPLS based given the name of the conference?

Are the slides anywhere?

Were any changes required to the MPLS header or MPLS forwarding
operations to support SR?

Another difference between IPv6 and MPLS is that MPLS is not an
end-to-end protocol, so it naturally creates and enforces local
domains. To have MPLS frames successfully leak between two networks
requires active enabling of MPLS on both ends of the links between
them, which won't happen unless the MPLS networks explicitly agree to
trade MPLS traffic, for explicit MPLS reasons, purposes and functions.

IPv6 is an end-to-end protocol between hosts, that may transit
multiple networks in between those hosts. IPv6 is brought up between
two networks to provide services for any IPv6 applications. So SR
wouldn't likely be the initial reason to enable IPv6 between two
networks. Consequently, the likelihood of "internal" IPv6 SR packets
going further than they should is naturally much higher. RFC1918 and
similar have demonstrated that on the Internet, local or private "IP"
domains aren't.

Regards,
Mark.