From nobody Fri Apr 1 13:30:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AE012D156 for ; Fri, 1 Apr 2016 13:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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, RCVD_IN_SORBS_WEB=0.77, 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 4EIe00T7KaCF for ; Fri, 1 Apr 2016 13:30:53 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 7642612D12D for ; Fri, 1 Apr 2016 13:30:53 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id ui10so2952155igc.1 for ; Fri, 01 Apr 2016 13:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=eryihdL/GibKrV/hhWFJ0XYWhRRgcHPTQUZLMm47rWk=; b=zZHxyvRttxMDEsQ9kH/FlrabeGYYP98IIPeVcV6i6umUXzWYySPmA8pj4K/dTr+2tJ P3TnEzRNE5uS3/NY+XtsfyFCswvSW2SOFOiIX5cCGq8aiP6Kws1Oc5uGkTIOtYU/9h7L MQB3HkMLJO2k9GN6VLVpkhzh3USte/N0Z+IiED0r6xjlL/K0KW9B7YpkGv52NbwACaj3 Y8KxcjQYQOpLu8Nay49Em7n+AtrGJrR0aL7R38NEgLbvQ7uT8IdYCJTjCSZPtdJwgAa7 sp8X+3KlTGisulST3E7QM/QgbvqzjLV9r5ZUoAw0ljBx2260r71a1JQgIHL2MFFAH87K 4eIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=eryihdL/GibKrV/hhWFJ0XYWhRRgcHPTQUZLMm47rWk=; b=GDIRqce3jRE9bPNdC8delbrVRnUpknT1nqsXWSa4x4ZoD++4U8kHdsXS0ZZ9rRrqXY NeiB9X663JpaXLE7FJUopBurbqjVuBdcG9uOStkXG6vpYY+wkb7DbcMtvbpXSYUHngOi nHcpjAzugFB7usqGwsGsJQvhOUIWjkUvXTEn5xRH1QiMdEh32MoAmnZEJ2KdIm89H7C/ JqS+jtKgqkYkPEUrvXBwgJM7xbnv4Pg0s0jYq3g14Rkv2EsslvB8OlgkIFVh0U9+ujwD 4h/qIw7Uf2oUBCIDTpwxrirF7VAcCOEHp2qdHK3NhiAABiWOMbVQ9XTijnBV6ab6eaci R5bg== X-Gm-Message-State: AD7BkJK2T0SyvFI1/2Ii6jBVqEzxag6z2uQvdOQcvaJhVqiceQJ02YPFOkCVeTqnwm+jTw== X-Received: by 10.50.65.8 with SMTP id t8mr805989igs.60.1459542652899; Fri, 01 Apr 2016 13:30:52 -0700 (PDT) Received: from [10.10.104.105] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id k2sm286685igx.5.2016.04.01.13.30.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Apr 2016 13:30:52 -0700 (PDT) Subject: Re: 6MAN Draft agenda for IETF95 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_95F7C173-C9F1-488B-B757-F618E5D8E1E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <5A2019ED-DDA6-424D-8A53-2A5374466CEC@gmail.com> Date: Fri, 1 Apr 2016 17:30:48 -0300 Message-Id: <14B53753-F0CB-4A0E-94C3-C805A4D750F2@gmail.com> References: <5A2019ED-DDA6-424D-8A53-2A5374466CEC@gmail.com> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 20:30:55 -0000 --Apple-Mail=_95F7C173-C9F1-488B-B757-F618E5D8E1E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We still need a volunteers for the jabber scribe and minute taker for = the 6MAN session. Thanks, Bob > On Mar 21, 2016, at 6:42 PM, Bob Hinden wrote: >=20 > Hi, >=20 > The 6MAN draft agenda for IETF95 can be found at: >=20 > https://www.ietf.org/proceedings/95/agenda/agenda-95-6man >=20 > We believe we were able accommodate all of the agenda requests we = received. Please let us know if we missed anyone. >=20 > The agenda is organized in three sections, Working Group drafts, = Active Individual drafts, and New Individual drafts. We gave priority = to the requests in that order. >=20 > The Working group drafts section includes the project to move the base = IPv6 specifications to Internet Standard. >=20 > Active individual drafts are drafts that have seen active discussion = on the IPv6 list. >=20 > While we didn=E2=80=99t receive any requests this time for new = individual drafts, these are usually new and/or have not seen a lot of = discussion. We will schedule the last category five minutes each to = allow the authors to do a introduction to the work and then start a = discussion on the mailing list if time allows in the session. >=20 > We also need a minute taker and a jabber scribe. Please volunteer. >=20 > Thanks, > Bob & Ole >=20 >=20 --Apple-Mail=_95F7C173-C9F1-488B-B757-F618E5D8E1E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW/tp4AAoJEK7rdBF357uo3yoIALYd8ocN8JcHoKUZ1Ea6r9fO JUbf7JYTDHIwEKlzoH8K4IvTPcMa+rB1j4QAISxcsEVGLcSD838C6uMQVclMSn4x 7uxJtKAI7FL8pbCHbVTfvMF1cld/nnKlrMXa08yyA0OOGEbdZPC7bgxUKoEO0o8+ zqqMaSLq3E76tZTu9yDy++RRNO9ahFjKJ8AUTgcb2qcHtlpM61r35kfZDLwQF+A9 rx6UMcsXcPQ/MEcP4VnWCO/hpVD1u1S7ZuV7J8o4OqnhogFwXxqR1pXR9C/ZAOoI k4MlJObRze84M2sXEdquvcUtK1QWMdjeHUxtNfRJ6KB5vOcoyUjfocKQynQ7DhA= =5+p1 -----END PGP SIGNATURE----- --Apple-Mail=_95F7C173-C9F1-488B-B757-F618E5D8E1E7-- From nobody Sun Apr 3 06:30:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68612D52A for ; Sun, 3 Apr 2016 06:30:04 -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 Vc61oRcVECc1 for ; Sun, 3 Apr 2016 06:30:01 -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 25BC912D1EA for ; Sun, 3 Apr 2016 06:30:01 -0700 (PDT) Received: from [IPv6:2001:67c:370:168:d02a:4d80:f2b0:31b7] (unknown [IPv6:2001:67c:370:168:d02a:4d80:f2b0:31b7]) (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 0F8FD800B4; Sun, 3 Apr 2016 15:29:51 +0200 (CEST) Subject: Re: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt) To: Alissa Cooper , Christian Huitema References: <20160217110334.12586.6254.idtracker@ietfa.amsl.com> <56EBFF21.3010202@si6networks.com> <56EC0ABB.4050608@si6networks.com> <56EC29BE.7020802@si6networks.com> <56EFF988.4040703@si6networks.com> <56F07C82.2020400@si6networks.com> <56F12754.4020209@innovationslab.net> <56F3046D.4040700@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57011AC5.1050905@si6networks.com> Date: Sun, 3 Apr 2016 10:29:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Brian Haberman , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 13:30:04 -0000 Hi, Alissa, On 03/25/2016 04:32 PM, Alissa Cooper wrote: >> Note that this is unrelated to whether IT admins allow randomized >> addresses, or whether a specific hardware supports it. If >> randomization is forbidden or unavailable, of course it will not be >> used and the address will not change. And the users will be easy to >> track. > > > Thinking this through, I think part of the difficulty with this kind > of document is the gap between what is standardized and what is > implemented. What we have today, from a standards perspective is: > > (1) a bunch of specs that normatively specify embedding in an IID a > MAC address as presently specified by IEEE 802 > > (2) RFC 4941 which specifies a method for temporary address > generation but indicates that such addresses can/should be generated > alongside a MAC-based address > > (3) RFC 7217 which specifies a method for generating a random address > that stays stable per-subnet > > Aside from what has been standardized, it sounds like what we also > have are MAC addresses getting randomized more commonly, use of the > method in 7217 to generate addresses that do not necessarily remain > stable per subnet, and perhaps use of 4941 temporary addresses in > isolation, without a stable address also configured. > > If we want to replace (1) with something better from a > security/privacy perspective, we have limited choices if we want to > point to an existing standard. This was the whole point of this I-D. > If we do not care about pointing to an > existing standard, we could just list what the requirements are, and > have all the specs that fall under (1) be updated to use some > (unspecified) mechanisms that meet those requirements. Or we could > first standardize mechanisms to cover all the cases that the > requirements would cover, and then point to those mechanisms. What we're doing there is replacing the default mechanism for generating stable addresses. ANything else is orthogonal. e..g, if you want to use RFC4941-only, that has, IMO, nothing to do with replacing the MAC-based stable addresses with RFC7217. > Personally I think requirements 2-4 in Sec. 3 of default-iids > represent the minimum change that is worth updating all the specs > that fall under (1). Adding a requirement or changing requirement 2 > to speak to an address change per network connection/disconnection > rather than per subnet would be reasonable if we decide to ditch > requirement 1. From this discussion it sounds like adding a > requirement against direct embedding of a link layer address in an > IID may also be a good addition. Isn't it there, already? 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 Sun Apr 3 08:04:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274CE12D564 for ; Sun, 3 Apr 2016 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 1Xio4YsMu5Kq for ; Sun, 3 Apr 2016 08:04:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D3312D198 for ; Sun, 3 Apr 2016 08:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WijqhzErTx2U4oAUViME0CQv/oeb/d6Oq9PGX4f+UyE=; b=BCEeiU/NPQ9Jm1h4YIDBuvTNWwn2NJi+L8lgqzKV3Q6xYvMartb3bT6+yK5sgCkFYIY+2f1UJTFdPyDPYwITDrI1/xd9KQxKW1plyLGCOstWs1osqCE0TO39p+/zGe/Ea/g0TBqGkWgrVQ6AsusLl/ybp15Hq4cTQhQCIrASuCU= Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1988.namprd05.prod.outlook.com (10.162.224.30) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 3 Apr 2016 15:04:28 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0447.027; Sun, 3 Apr 2016 15:04:28 +0000 From: Ronald Bonica To: "otroan@employees.org" , Brian Haberman Subject: RE: Review of draft-ietf-6man-hbh-header-handling-01 Thread-Topic: Review of draft-ietf-6man-hbh-header-handling-01 Thread-Index: AQHRde+vpur3jempfUO2BKkuKIZdl59OFwVAgAEZMYCAA3Kj8IABlYGAgAIu8jCADjAyAIAAARjggAAKJ4CAABYqYIAADlkAgAAK2ACAABWWEIAAYJIAgACSYYCABpoQgIAK9/Ig Date: Sun, 3 Apr 2016 15:04:28 +0000 Message-ID: References: <88F34B62-6DB7-496F-8E7F-9E5249348B92@employees.org> <56F0A7DE.40507@gmail.com> <20160322.100604.74718563.sthaug@nethelp.no> <56F185C7.1090507@innovationslab.net> <5D8258EE-97C2-4E96-AA6C-31B8E5978EA1@employees.org> In-Reply-To: <5D8258EE-97C2-4E96-AA6C-31B8E5978EA1@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: employees.org; dkim=none (message not signed) header.d=none;employees.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: d026bab7-4427-4c48-bc94-08d35bd1412f x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:Beq3YRSOLduEWyBJKjdFyX61CYbIFNl6b4QCIQGcf9J6Jv7S1kOEJ5lsYxY4yO3XKAJ+y6qWsqcAj1Q7wbD8EIFVfheQD2gwjq1jrF/ZVV1YYi/44+PqITQr3srzRLeVHEEMnJi30NUNiYRB5pV6vg==; 24:SfQUxKP9/PT5RX9wpu0WEZrxayeus3SD7V14aNezVOETD6dKP/NwgpiQTCZMcCXgUkf3HUgES4uvWn56ojDdtLfJ07jayqsm4LY0jrgRRd4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR05MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1988; x-forefront-prvs: 09011458FC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(13464003)(377454003)(2906002)(3280700002)(3660700001)(4326007)(93886004)(2501003)(11100500001)(50986999)(76176999)(54356999)(74316001)(5003600100002)(33656002)(189998001)(1220700001)(81166005)(92566002)(586003)(6116002)(102836003)(3846002)(87936001)(5001770100001)(1096002)(5004730100002)(230783001)(10400500002)(19580405001)(19580395003)(76576001)(99286002)(86362001)(77096005)(106116001)(122556002)(2950100001)(5008740100001)(2900100001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1988; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2016 15:04:28.8530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1988 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 15:04:32 -0000 Folks, Does anyone know of an IPv6 RSVP implementation that relies on the HBH Opti= ons Extension Header? AFAIK, no such implementation exist for RSVP-TE (i.e., MPLS signaling). How= ever, such an implementation might exist for RSVP's original use-case (band= width reservation). If anybody know of other implementations, please chime in. = Ron > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of > otroan@employees.org > Sent: Saturday, March 26, 2016 6:39 PM > To: Brian Haberman > Cc: 6man WG > Subject: Re: Review of draft-ietf-6man-hbh-header-handling-01 >=20 > [SNIP} >=20 > MLD, RSVP. IOS depends on the HBH (as I would expect many others). >=20 From nobody Sun Apr 3 08:04:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813D312D564 for ; Sun, 3 Apr 2016 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 RD200cwB1066 for ; Sun, 3 Apr 2016 08:04:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F69512D530 for ; Sun, 3 Apr 2016 08:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XESJDo0oN4+KjKsh6WpuRcsvfPO9Jz1Wf2WADo21e/s=; b=k2qX82eJ+y7Gu2S1y9fiWjL+XSHib4Gh3yRqOt37ERaOzKftIBDOiuUp2+qMy2ZHKSffvVoakGZtywkxu8xgO9LmTVg1B7otB5OY/SqL0ZtAeUTAAnKOQo++FWXNvOV1jQeUSvRXgEiGitGAZhyc/ur5809cXLbZqRMs7P77XXk= Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1988.namprd05.prod.outlook.com (10.162.224.30) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 3 Apr 2016 15:04:30 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0447.027; Sun, 3 Apr 2016 15:04:30 +0000 From: Ronald Bonica To: 6man WG , Fernando Gont Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01) Thread-Topic: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01) Thread-Index: AdGNLY1ESPfeTf4OQziq6GNEc8vUog== Date: Sun, 3 Apr 2016 15:04:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 52def476-5484-44f5-0426-08d35bd141f8 x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:3/8DsoRDIjSRZTx+rkYBi8PuIvzhDUwa26LuTFNirz8tjX0C+utOuXZC0rT9N+m2u5uChAcEfnyRX/MZKClqOOIc7p6DZ+D9D0Eo3I+IUTcHIcqrWpslZfzpy0gyBPxbHSTy8fE4+mNuBIB30cdEdA==; 24:ZDGDuZAHtF2Ns8RVhtLSYh+mSY+OjM++SsL4RsBNTTK201C1zuIg7XSPeFScQJDS6saTFLvqC4Kz++sWxLHOh7xqNmsul86nh81pq5e5wpI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR05MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1988; x-forefront-prvs: 09011458FC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2906002)(3280700002)(3660700001)(11100500001)(50986999)(54356999)(74316001)(5003600100002)(33656002)(189998001)(1220700001)(81166005)(92566002)(586003)(6116002)(102836003)(3846002)(87936001)(5001770100001)(1096002)(5004730100002)(230783001)(10400500002)(76576001)(99286002)(86362001)(77096005)(122556002)(5008740100001)(2900100001)(5002640100001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1988; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2016 15:04:30.1499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1988 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 15:04:33 -0000 Folks, Having read through this email thread, the following are a few observations= . Again, we have three options: 1) Tighten up HBH handling (as currently proposed in draft-ietf-6man-hbh-he= ader-handling) 2) Follow the path of RFC 7045. Repurpose draft-ietf-6man-hbh-header-handli= ng to document the implications of that decision 3) Deprecate the HBH Options Extension Header Nobody (including me) is crazy about Option 1. We have heard support for Op= tions 2 and 3. So, let's consider those. When the HBH Options Extension Header was conceived, the founding fathers c= ouldn't foresee what kind of options would be defined in the future. Given = twenty years of hindsight, we now can categorize HBH Option into the follow= ing categories: - Forwarding plane options - Control plane options A forwarding plane option contains information required to forward the pack= et. That information can be discarded as soon as the packet has been forwar= ded. The Jumbogram HBH Option is an example of a forwarding plane option.=20 A control plane option contains information that is used to create or destr= oy more persistent state on an intermediate node. The router alert option i= s an example of a forwarding plane option. If we pursue Option 2, forwarding plane options will work, but applicabilit= y will be limited to the following scenarios: - the information carried by the forwarding option is not critical. The pac= ket can be forwarded even if the intermediate node ignores the option - the information carried by the forwarding plane is critical. The packet c= annot be forwarded if the intermediate node ignores the option. However, th= e sender is certain that every intermediate node that the packet traverses = will process the option. Control plane options may not have been a very good idea in the first place= . As Fernando is fond of pointing out, they expose the control plane to unt= rusted parties, increasing the attack surface of the intermediate node. The= re are better ways to establish state in intermediate nodes If we were to adopt Option 2, control plane options would work, but would b= e limited to the following scenarios: - A protocol uses HBH to establish state on intermediate nodes, but that st= ate isn't so critical that the protocol will not work unless that state is = not established - A protocol uses HBH to establish state on intermediate nodes. That state = is critical and the protocol will not work unless that state is not establi= shed. However, the sending station is certain that every node along the pat= h will process the option The following is my personal opinion and possibly the end of rational disco= urse: We should follow both options 2 and 3. For the time being, we should follow= the path of RFC 7045 and repurpose draft-ietf-6man-hbh-header-handling to = document the implications of that decision. We should also revisit protocol= s that rely on HBH, determining whether 7045 breaks any of them. Regarding Option 3 draft-ietf-6man-hbh-header-handling should also say: - that the IETF will never standardize another HBH Option - that the IETF will never standardize another protocol that relies on HBH In my mind, this is what it means to deprecate HBH. Comments? Ron Bonica From nobody Sun Apr 3 08:04:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDA512D5AC for ; Sun, 3 Apr 2016 08:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Q4lyQDNr1v7B for ; Sun, 3 Apr 2016 08:04:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF02012D198 for ; Sun, 3 Apr 2016 08:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LvHErpAvHA5U2sYquNT2cfzR3rqHMuMWjkSA7tyGzyk=; b=iHf72EHiCLTerwYcTnJaL+txvtAZ6mmbdhfi1EavDU7noGQc6hTxmkVORUWFfqSGGe5yO6ekSufPQZPRBSemgLPi+nbIcH+tP4VwR5HTYNpo2JRAC5ZwaJVuPpygkwacLbYkHcRthVeL4b6+1tEIYH9bWUonaYdHTLl4BQmLvBc= Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1988.namprd05.prod.outlook.com (10.162.224.30) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 3 Apr 2016 15:04:31 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0447.027; Sun, 3 Apr 2016 15:04:31 +0000 From: Ronald Bonica To: Brian E Carpenter , Michael Richardson , ipv6 Subject: RE: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01) Thread-Topic: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01) Thread-Index: AQHRhlKi1sM6pnB/7E+m9N9ZbSJijp9qfaiAgACOaYCADFFu8A== Date: Sun, 3 Apr 2016 15:04:31 +0000 Message-ID: References: <20999.1458930949@obiwan.sandelman.ca> <56F5FC7B.7010601@gmail.com> In-Reply-To: <56F5FC7B.7010601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: e5e39b85-eb81-4d15-ae0f-08d35bd142c2 x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:rFdY15KIZM+5uKhLc85i/nDJ11Dh68j84d+vXkQUOqjuH77iSsgKz3sBPOU3bx5qkUauCZK/xFyBFm5j/BiW+q6ikTVfJrUPrSfyWayCK4QwZfzuQTTAQy+Ja5N4tgfa7+T2YL4wMfCOTert4DkwMQ==; 24:6ShH+zMYvfCrK3OBCwODbuokEpAr+fAjyaYAmk8XtgjIJdbtKylkFBOYKA+AFhVLoBYnRgul9h/cs1QziqCOcmYn5OHszUIFZWtsGY6GYtk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR05MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1988; x-forefront-prvs: 09011458FC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(377454003)(24454002)(66066001)(2906002)(3280700002)(3660700001)(4326007)(93886004)(11100500001)(50986999)(76176999)(54356999)(5890100001)(74316001)(5003600100002)(33656002)(189998001)(1220700001)(81166005)(92566002)(586003)(6116002)(102836003)(3846002)(87936001)(5001770100001)(1096002)(5004730100002)(230783001)(10400500002)(19580405001)(19580395003)(76576001)(99286002)(15975445007)(86362001)(77096005)(106116001)(122556002)(2950100001)(5008740100001)(2900100001)(5002640100001)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1988; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2016 15:04:31.4781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1988 Archived-At: Cc: "C. M. Heard" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 15:04:35 -0000 Brian, Even of somebody saw a Jumbogram at an IXP, it wouldn't be so bad. The IPv6= header would have: - a packet length of 0 - a next header of HBH If the receiving node didn't recognize Jumbograms, wouldn't it discard the = packet and send an ICMP Parameter Problem to the source? = Ron > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Friday, March 25, 2016 11:06 PM > To: Michael Richardson ; ipv6 > Cc: C. M. Heard > Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header- > handling-01) >=20 > On 26/03/2016 07:35, Michael Richardson wrote: > > > > C. M. Heard wrote: > > > Indeed, the question arises whether allowing a router to ignore t= hese > > > options beaks them, or not. Clearly so for Jumbo Payload, >=20 > I dispute that, as far as the real world goes. Nobody ever expected the > jumbo payload to be used outside a "consenting adults" scenario; the > requirement to send back ICMP on discard is really icing on the jumbo cak= e. > As some words in > RFC3765 tells you, the path has to be pretty much hand-crafted: >=20 > " On links with configurable MTUs, the MTU must not be configured to a > value greater than 65,575 octets if there are nodes attached to that > link that do not support the Jumbo Payload option and it can not be > guaranteed that the Jumbo Payload option will not be sent to those > nodes." >=20 > So in practice, it really doesn't matter what the non-supporting router d= oes. > Did anybody ever see one of these things at a peering link or an IXP? I v= ery > much doubt it. >=20 > Brian >=20 >=20 > > > but it's > > > unclear to me why RPL, MPL, and DFF need to be specified as other > than > > > ignore if unrecognized. > > > > I agree that it's unclear if there is real benefit. > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > > > > > -------------------------------------------------------------------- > > 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 Sun Apr 3 13:33:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A21B12D5A4 for ; Sun, 3 Apr 2016 13:33:04 -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 I_Dw0wQOr5MK for ; Sun, 3 Apr 2016 13:33:02 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 61A0612D551 for ; Sun, 3 Apr 2016 13:33:02 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id zm5so129336126pac.0 for ; Sun, 03 Apr 2016 13:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=inlpn/O/DnP48JzMdEVJqRm8UQi5Fyg7AR/KULOwS1s=; b=OT+xacyD1TZr1r+EI6X90lBw2rFM2ADgpaY3VYRZLPWT/qdRsEPSlnLKiG69vF7QAN BEKBJZnFmrZCiXsjdJLdrh2Rg9L45lIBkuL/bKNpHUwjKHhtMQP3Osde24fmCvnC6A+c qE4yI0W5RrUsrWE0kR0e+UADALHvQhk5asFneQWgKQ77aMyNspC9DUqsPc5HaWUufHJ9 6EuIQj+xT5ZmzchhTypkRFfp9a1c7xCUGNEYjX+k9gACmb4ajBGZ+czYB079HIlwIH58 ut2yDP51jBki/idIUMkOx4bpUR2ozAg196QL3wMvcVvE/xi5yVuhvANkVAMwfakPJevY VqbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=inlpn/O/DnP48JzMdEVJqRm8UQi5Fyg7AR/KULOwS1s=; b=JNJzlFukIo0JgNmjCF20H+T8VNOkNdO8VaO5vaWrpgqEkrKRD2IHfx0jQletXqjswU E58JOmyixm+wBUiGyySVhmjzUrMw9q27raspQ5uUcVCg7LgXpFXlzioedtapNxaO8m7H Mp7qaLUInU1WS5W+PxXeJ9BFB64UzYiZ76ShFIQxUvq5WTa8oS/sH7y6lM6msXAkZpdU i66zyc1LDSEJKaRPjlDUjb32z8lL1y5VLDiZSJPi57CyLI0ID1AFzH/XM9sOKJ2x7UZs K7+lmqmTU5YmvMgz0cY0KHr5ntNn4y6unE54HmFPwtV6JlPc7x3FYzH3g2UWVne5rzmO +sAQ== X-Gm-Message-State: AD7BkJL+ajjIabauHSozpunoXzJ4MIkN/V3M++TfROPpniffaBPId7GBY/2dFDceF4GQew== X-Received: by 10.66.55.6 with SMTP id n6mr48470087pap.35.1459715581992; Sun, 03 Apr 2016 13:33:01 -0700 (PDT) Received: from ?IPv6:2406:e007:483d:1:28cc:dc4c:9703:6781? ([2406:e007:483d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 8sm34193979pfk.69.2016.04.03.13.32.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2016 13:33:00 -0700 (PDT) Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01) To: Ronald Bonica , Michael Richardson , ipv6 References: <20999.1458930949@obiwan.sandelman.ca> <56F5FC7B.7010601@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57017DF8.2090601@gmail.com> Date: Mon, 4 Apr 2016 08:32:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "C. M. Heard" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 20:33:04 -0000 On 04/04/2016 03:04, Ronald Bonica wrote: > Brian, > > Even of somebody saw a Jumbogram at an IXP, it wouldn't be so bad. The IPv6 header would have: > > - a packet length of 0 > - a next header of HBH > > If the receiving node didn't recognize Jumbograms, wouldn't it discard the packet and send an ICMP Parameter Problem to the source? Most likely. But my point really was: who cares? Anyone who sends Jumbograms without knowing that the path supports them will lose anyway. Brian Ron > > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Friday, March 25, 2016 11:06 PM >> To: Michael Richardson ; ipv6 >> Cc: C. M. Heard >> Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header- >> handling-01) >> >> On 26/03/2016 07:35, Michael Richardson wrote: >>> >>> C. M. Heard wrote: >>> > Indeed, the question arises whether allowing a router to ignore these >>> > options beaks them, or not. Clearly so for Jumbo Payload, >> >> I dispute that, as far as the real world goes. Nobody ever expected the >> jumbo payload to be used outside a "consenting adults" scenario; the >> requirement to send back ICMP on discard is really icing on the jumbo cake. >> As some words in >> RFC3765 tells you, the path has to be pretty much hand-crafted: >> >> " On links with configurable MTUs, the MTU must not be configured to a >> value greater than 65,575 octets if there are nodes attached to that >> link that do not support the Jumbo Payload option and it can not be >> guaranteed that the Jumbo Payload option will not be sent to those >> nodes." >> >> So in practice, it really doesn't matter what the non-supporting router does. >> Did anybody ever see one of these things at a peering link or an IXP? I very >> much doubt it. >> >> Brian >> >> >>> > but it's >>> > unclear to me why RPL, MPL, and DFF need to be specified as other >> than >>> > ignore if unrecognized. >>> >>> I agree that it's unclear if there is real benefit. >>> >>> -- >>> 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 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > . > From nobody Mon Apr 4 07:58:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114D612D743 for ; Mon, 4 Apr 2016 07:58: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, 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 Ni68GZLonaMN for ; Mon, 4 Apr 2016 07:57:57 -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 3C7A812D175 for ; Mon, 4 Apr 2016 07:56:50 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:f823:aeaf:52:cc65] (unknown [IPv6:2001:67c:370:160:f823:aeaf:52:cc65]) (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 EB78A800B0; Mon, 4 Apr 2016 16:56:46 +0200 (CEST) Subject: Re: rfc2460bis question To: Brian E Carpenter , 6man References: <56F9CCA5.9040101@gmail.com> From: Fernando Gont Message-ID: <57026A25.6060309@si6networks.com> Date: Mon, 4 Apr 2016 10:20:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F9CCA5.9040101@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:58:00 -0000 On 03/28/2016 09:30 PM, Brian E Carpenter wrote: > Hi, > > rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 that > seems to come up repeatedly. > > Are intermediate systems allowed to insert, change or delete Extension Headers, > apart from specified cases (routing headers, and HbH options that may change > en route)? And in the cases where changes are allowed, are intermediate systems > allowed to change the *length* of headers or option data? > > For option data, the answer is clear but slightly hidden: since the Option Data > but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data Len is > clearly not allowed to change and therefore options cannot be inserted or > deleted either (which breaks RFC 4782). But it isn't stated anywhere that > I can see that intermeiate systems must not insert, change or delete EHs, > although they are all supposed to be e2e except for HbH options. > > Maybe that needs to be an erratum on 2460? +1 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 4 09:30:25 2016 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 D131112D54D; Mon, 4 Apr 2016 09:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404163023.15654.96360.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 09:30:23 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:30:24 -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 : Generation of IPv6 Atomic Fragments Considered Harmful Authors : Fernando Gont Will(Shucheng) Liu Tore Anderson Filename : draft-ietf-6man-deprecate-atomfrag-generation-06.txt Pages : 10 Date : 2016-04-04 Abstract: This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments, and concludes that the aforementioned functionality is undesirable, thus documenting the motivation for removing this functionality in the revision of the core IPv6 protocol specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-deprecate-atomfrag-generation-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 Mon Apr 4 12:07:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F63F12D10B; Mon, 4 Apr 2016 12:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FEzc5DWlTvwf; Mon, 4 Apr 2016 12:07:46 -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 CB2BA12D75D; Mon, 4 Apr 2016 12:07:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 96D3A200A3; Mon, 4 Apr 2016 15:11:10 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C35936375A; Mon, 4 Apr 2016 15:07:44 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks , 6man@ietf.org Subject: changing the RPL RPI Option Type --- new version of useofrplinfo X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:07:48 -0000 --=-=-= Content-Type: text/plain I've been through an editorial pass of useofrplinfo. The result is the -03 version of the document, which you can see diffs at: https://www.ietf.org/rfcdiff?url1=draft-ietf-roll-useofrplinfo-02&url2=draft-ietf-roll-useofrplinfo-03 I think that I want to change all of the "not-RPL-aware" to "non-RPL-aware". I shortened some of the column names in the tables so they would fit better, and I split up the storing/non-storing table so that it would be easier to read. Now I wonder why I wrote "Raf" rather than "Ral". Please see the summary in new section 7. The thing I wanted to bring out is how much work the storing mode of RPL has to do in order to deal with the Option Type being 0x63 rather than 0x43. Here is the table. "Raf" == RPL Aware Router. "!Raf" == non-RPL Aware Router. +---------------+--------------+--------------+----------+----------+ | Use Case | RPI (RFC | RH3 (RFC | IP-in-IP | IPIP dst | | | 6553) | 6554) | | | +---------------+--------------+--------------+----------+----------+ | Raf to root | Yes | No | No | -- | | root to Raf | Yes | No | No | -- | | root to ~Raf | Yes | No | Yes | hop * | | ~Raf to root | Yes | No | Yes | root | | Raf to Int | Yes | No | Yes | root | | Int to Raf | Yes | No | Yes | raf *1 | | ~Raf to Int | Yes | No | Yes | root | | Int to ~Raf | Yes | No | Yes | hop *1 | | Raf to Raf | Yes | No | No | -- *2 | | Raf to ~Raf | Yes | No | Yes | hop *2 | | ~Raf to Raf | Yes | No | Yes | dst *2 | | ~Raf to ~Raf | Yes | No | Yes | hop *2 | +---------------+--------------+--------------+----------+----------+ If an RPL LLN can be sure that there are no 6lowpan-only nodes, then it can regularly avoid IPIP headers except for traffic entering or leaving the LLN. Traffic entering the LLN is obvious to the 6LBR, so that part is easy. Traffic leaving the LLN can usually be determine by comparing the destination address to that of the prefix found in the DIO's PIO. Traffic not matching is going out the Internet and requires an IPIP header towards the 6LBR, which will remove the RPI header on the way out. If the RPL LLN is *not* certain that there are no 6lowpan-only nodes (%), then nodes have no way of knowing if they are in the two situations marked *1, or *2. As such, they essentially have to send *ALL* traffic in the LLN with *hop-by-hop* IPIP headers, as the RPI might have to be removed at any point in the forwarding. These hop-by-hop IPIP headers do *NOTHING* to help steer ICMP messages back to the correct originating node unless each router keeps state about each encapsulation/decapsulation it has done. Note that the "always do hop-by-hop IPIP" solution does *not* work in the non-storing case. Section 7.2 mentions this. If we make the RPI Option Type 0x43, then all the cases marked "to ~Raf" devolve into the cases marked "to Raf", and we can use RPI everywhere. A change to the 6lowpan specification to say that Option Type 0x63 MUST be recognized (and discarded by end hosts) would also work if there was still value elsewhere. We are about to have a flag day for 6lowpan hosts when it comes to compressing these artifacts anyway. I could redo useofrpl with the assumption that the Option Type was 0x43 and show the resulting difference. (%) - in RPL non-storing mode we actually get a signal to the 6LBR root that there are non-RPL nodes in the LLN. We could create such a signal for storing mode. In the storing mode case, this signal would have to be rebroadcast from the root to tell all nodes to go into hop-by-hop mode. As such the nodes would now have two code paths and all the problems of both. Seems like a stupid thing to do. Note that we do not have the same problems in non-storing mode because all traffic goes through the root, and the root knows the entire topology, and can figure out how to address the IPIP headers so that they the RPI is removed before the leaf. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwK7fYCLcPvd0N1lAQIILwgAjCoa3vhoucASYwZ3fZoKydv4I7Z4VCgB B/kCdR5qzGTMhYMVKwQMWqWSUOABLZu/WYrzHW77CqkfntbjHmdWi/4DDc5zmiJi 5FEl++TSK8e9XbUzgFKbcFurA9DW+tu9XvoowkpeGlG5oJr2UNCazkJ9pBwaiVLh /L0RgMZEC+VBC8I5mcYQ9veRXMcObtI9sn8CuNt1xaem666KYCjny1cuuxWsQ/jb hvASOIBtRqt/UogGVxh9bpcY9GUEu/GQHAMx7c0RHf5BKRk/+cpTNDLeBkR/B+DS w9PkmS6+UQnU9Cp2ppVA7YSsJ+4TCDmNSVYScSqF7LID9NfgTTFueg== =oh7i -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 4 12:46:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9003612D1CD for ; Mon, 4 Apr 2016 12:46:14 -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 xKlSFdFTMmx0 for ; Mon, 4 Apr 2016 12:46:12 -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 923B812D821 for ; Mon, 4 Apr 2016 12:46:12 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id t10so77950114ywa.0 for ; Mon, 04 Apr 2016 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=5hHSwGgXuz++bkfn7C0C0CnKFBna8ZzfAc5wd8fafJI=; b=NptdpLefTC3zGCJeyY9XpVGBP2OnHVmLnc/XcMccNlTvyIeBZ0Xl03bYK0ezN70ey6 +Mit2ppL32cnfkUPDT1KNzPT9fz+KFkBjKnAa4AGYP1JrvtYm3aRYl1FiVvZTfxwLA/U BJPO4vwI5eakj/O3If4xvjoWmRf27X3UuXJcm9HwuTPwmh0vQk77CIRDTFtDq23P1HxK T8Pxrf+wEeOkjFBfcIfIuugD/UykKhZfzxbh3YN50qk+qT4mIozxoQyWNgSL8voRgjql nJm5uOqeqVCReOrdy5Mpafaze1SRT1qm7BPeEMhHl9npeXtecy/UzT1MLIxNTfygIN9d teEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=5hHSwGgXuz++bkfn7C0C0CnKFBna8ZzfAc5wd8fafJI=; b=CY4fuX/HQDMhaGSS1wm2E+n/iepDrhdph9tVH//ZkbBzczeMXEi13G8F4gt8Gg4p8R 8BJZqYQ3PEGlAJ6o3AUCiLfuS6jdch7ZDn8zRosuN74YlqlAoUFpMwgCNdVe43Ed7MuK 57Al07h2ktK8NgNjTSMPARZP3e0lva9IkCedV6p3DoAmQ9JeJpa+BcvGt96Z8Iz3XW3z Z+SW0/gZ3zYI02GKTo4KKqSq0kie7AmMgKj7H+rjWAOI88/t2YlqdJjLqrlMn+LcEX7o RPDj4dJlzw/yJ3agQXDfQOB1UwG4aa2K/r1uMtrE+k9szNgLjFzeb1bDw59lC8gzOuje zlow== X-Gm-Message-State: AD7BkJKlhRMCSmbD6hx+mBZR2IpbH5XjP0cWvrSreg9A+WrNaHCbHohtfZXCXP4ocvWIew== X-Received: by 10.129.111.10 with SMTP id k10mr18823223ywc.79.1459799171885; Mon, 04 Apr 2016 12:46:11 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:d194:cade:a04c:c16b? ([2001:67c:370:176:d194:cade:a04c:c16b]) by smtp.gmail.com with ESMTPSA id i81sm18341031ywg.33.2016.04.04.12.46.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Apr 2016 12:46:11 -0700 (PDT) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4448A2D1-E59D-4A70-9570-18DF80E3E11C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <56F9CCA5.9040101@gmail.com> Date: Mon, 4 Apr 2016 16:46:09 -0300 Message-Id: <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> References: <56F9CCA5.9040101@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:46:14 -0000 --Apple-Mail=_4448A2D1-E59D-4A70-9570-18DF80E3E11C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Mar 28, 2016, at 9:30 PM, Brian E Carpenter = wrote: >=20 > Hi, >=20 > rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 that > seems to come up repeatedly. >=20 > Are intermediate systems allowed to insert, change or delete Extension = Headers, > apart from specified cases (routing headers, and HbH options that may = change > en route)? And in the cases where changes are allowed, are = intermediate systems > allowed to change the *length* of headers or option data? Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header": Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]. I think covers the inserting issue. I don=E2=80=99t see any text that prohibits changing or deleting = Extension Headers. I think it was the intent to not delete or change = the length of Extension Headers, so we could add that as a = clarification. Changing the content is more complex, as you note, we do = allow changing the content of some extension headers. I think that = needs to be part of the definition of each extension header. We could add text cover deleting and changing the length. > For option data, the answer is clear but slightly hidden: since the = Option Data > but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data = Len is > clearly not allowed to change and therefore options cannot be inserted = or > deleted either (which breaks RFC 4782). But it isn't stated anywhere = that > I can see that intermeiate systems must not insert, change or delete = EHs, > although they are all supposed to be e2e except for HbH options. I think that confirms the intent. I could work on some text for = rfc2460bis. Bob >=20 > Maybe that needs to be an erratum on 2460? >=20 > Regards > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_4448A2D1-E59D-4A70-9570-18DF80E3E11C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXAsSBAAoJEK7rdBF357uoNUUH/0JCOYZtrH1yeZdZuuduo8nU wvzmGNideW9rLOMZRfKce768/wOZl8ZEwHaFLbOQvsnJmS7wWKCzMWntaMMOvdFf T+S5Aom1uVGmrNOfmDrCcTZAehfv8qTtQeenVuEfS2VutyO19I3EInzu6wWmGpTj hX5dluYNV97Ss7sfzuH+ldaoyWAR9R5Jm1SayrQ6KiOAV+Nz9RQ6KvCNPO0MHBMG 2p5oJ8xIXSDK7uyqHzBo05JNGZ5NWrCLQsqWvOW0eOG5FJifzZosL89JVT+P7T9A aZgXUU5dbuHekQIV7/t6QiqztsXEqal9sCjJB1Y1sxFEp2fT6DtY7SB7WqoqVPQ= =rhoH -----END PGP SIGNATURE----- --Apple-Mail=_4448A2D1-E59D-4A70-9570-18DF80E3E11C-- From nobody Mon Apr 4 13:05:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D209412D84B for ; Mon, 4 Apr 2016 13:05:43 -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 yzN88owjDsbV for ; Mon, 4 Apr 2016 13:05:41 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 CB85312D804 for ; Mon, 4 Apr 2016 13:05:41 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id tt10so150624023pab.3 for ; Mon, 04 Apr 2016 13:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bmxBnOcKbTEy4WFkgbYp3Kr3JS8wgyGcADToK9sNOgw=; b=O9g2I/Xq0SKtBvLHAZ57SZpisofA7I6UQLHB6a8tWzO9dVvJZo8v3rkzrShf8sw/Ez IXbyK38TmlSMlCbD33GmxlLN7peW/ZjIryGVOyMxzccNZEujb/xR/EfXa8t+cpee5dO2 hMrgjIWKw+4BkrYB6kO3jX0U2wTHwAkR5U5Alo7r7aZhcwf6rCKmUJ4D0dXz98zhW6FQ NigIPOo8pZPpih/Ca8Js7+H173NLcUWvTUBPw3K8hipzmGU0WZNCK09+t5fMn0jPaE6P IYZj4GfMCp3TGksgmdn/VmDENQlxMDjlHidPyGicp6TH0f1lJAUIbabr/ztCE+0RiBn1 pdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=bmxBnOcKbTEy4WFkgbYp3Kr3JS8wgyGcADToK9sNOgw=; b=Is+2m2d4D2KqEU7/OJo6PfpnhYE1cN+cQXiFPQcHnrOA/jyfRIgLGnEhSmX5uaqP2B DKEBVuuh9ZtclM+o+aEuu1fXKLzSi2BDvyt0696gfcaLaPIlCheFFzTGxilXqh3rlYRn 2+xeT1tB0xzYOn/VNKiee9VK5ESNzpuR/rSC93jOak36JSG6V+QvpuBQImYBz/jWg6DX wl4bYnzo9BxFLMn4yBBlG3BVPKABcy+hbx7JPQaWHH6izb3Ws5UcqYMUbDzIsv1SskPT JtVmn8l7xn4p6OlIdBZP4mwcmDQ+ItuTP1OQXNba2VRmmTPw+detfD5ctPrfyqbl29is cozw== X-Gm-Message-State: AD7BkJI2e8WnwKCeTfnhI286kWlxSD0DMp9a3rCYxhu06Zxru/6eJQuYj/783/9wcvSFHQ== X-Received: by 10.66.243.35 with SMTP id wv3mr55848891pac.93.1459800341294; Mon, 04 Apr 2016 13:05:41 -0700 (PDT) Received: from ?IPv6:2406:e007:6365:1:28cc:dc4c:9703:6781? ([2406:e007:6365:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id kl14sm2252720pab.23.2016.04.04.13.05.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 13:05:40 -0700 (PDT) Subject: Re: rfc2460bis question To: Bob Hinden References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5702C912.6040506@gmail.com> Date: Tue, 5 Apr 2016 08:05:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:05:44 -0000 Thanks Bob, that all works for me. RFC 4782 seems to be problematic. Brian On 05/04/2016 07:46, Bob Hinden wrote: > Brian, >=20 >> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter wrote: >> >> Hi, >> >> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 that= >> seems to come up repeatedly. >> >> Are intermediate systems allowed to insert, change or delete Extension= Headers, >> apart from specified cases (routing headers, and HbH options that may = change >> en route)? And in the cases where changes are allowed, are intermediat= e systems >> allowed to change the *length* of headers or option data? >=20 > Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header":= >=20 > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. >=20 > I think covers the inserting issue. >=20 > I don=E2=80=99t see any text that prohibits changing or deleting Extens= ion Headers. I think it was the intent to not delete or change the lengt= h of Extension Headers, so we could add that as a clarification. Changin= g the content is more complex, as you note, we do allow changing the cont= ent of some extension headers. I think that needs to be part of the defi= nition of each extension header. >=20 > We could add text cover deleting and changing the length. >=20 >=20 >> For option data, the answer is clear but slightly hidden: since the Op= tion Data >> but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data Le= n is >> clearly not allowed to change and therefore options cannot be inserted= or >> deleted either (which breaks RFC 4782). But it isn't stated anywhere t= hat >> I can see that intermeiate systems must not insert, change or delete E= Hs, >> although they are all supposed to be e2e except for HbH options. >=20 > I think that confirms the intent. I could work on some text for rfc246= 0bis. >=20 > Bob >=20 >> >> Maybe that needs to be an erratum on 2460? >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Mon Apr 4 19:32:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2329712D1CA for ; Mon, 4 Apr 2016 19:32:43 -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 r2ADTmhFvn2S for ; Mon, 4 Apr 2016 19:32:40 -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 9C6D512D0C3 for ; Mon, 4 Apr 2016 19:32:40 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 2so3357561ioy.1 for ; Mon, 04 Apr 2016 19:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=R7RIlHqLwNQOo9xMSBxJSJRy0P2tHsURAG4VsWwBmKU=; b=H9oDBLHSI7cd+booDZqOjTXZU4j5pwgEBiOyMmaAPRDbkNFCuajhx38I9Fu/w0vAOD hNr4saefHgabLxhQwXUCGW0cQ/Y/dB7oHcxYaKEoKf1yVBZ2hc05jkbZ6TUyD0l6oCoq X4Nhaan2Th1r/L409SS0p9kLjLztcFCjr8jNvndqUpolbUCNlEuXWypJRz0eQu+/iEYo B16c/lUx3GFRs03NY9FeqyF7I/XK4QRSO0UYkPD5c8GF6abTp/iAw9Qwy15y7Fe+UPUJ p1dhjn/coPOySGnJFVOSHLcYJT8N3C98s8/TVZrX7RLbj8GScIU8/HyOvWlOya5Ij33X Xsjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=R7RIlHqLwNQOo9xMSBxJSJRy0P2tHsURAG4VsWwBmKU=; b=ayVM/zR2kJ2YcmQWT/pwXa28m/nOJuS+AYS1RFprg83OW1uJiq45ApTELoY3wtKcXE 6U+G6q/p/1wQoHEhi0Onn2uT9m/OPPWjyMcmWud2I8WtJBh+EOIilo072zPJ7Pp6Jv9A CEIKHYQSVpcwAh/aIenKeWoLaMknz0nTkCutOVc90azt/DTgPbkloiIBVdU/tO10ueQv 8yxRpcypCsCM+TZEXCJEqHgZR6/WxBwp+9xOoCwnkqUqX7I2Iw1Vzw49d58ioyzIZCQI prmP3oBjpe60ratlvu817j9o67SV43QyE9IN5eH5ibL33ozm8As3GKf449WYJmYUV+Lq d/Bg== X-Gm-Message-State: AD7BkJLWfff3YsVDUlafn61Bj2BZOEC7MSf+oHlRydHf0O6Emnll/vC3dps5hUh6/RtaGw== X-Received: by 10.107.137.201 with SMTP id t70mr19344305ioi.164.1459823559915; Mon, 04 Apr 2016 19:32:39 -0700 (PDT) Received: from dhcp-93f1.meeting.ietf.org (dhcp-93f1.meeting.ietf.org. [31.133.147.241]) by smtp.gmail.com with ESMTPSA id c193sm12878089ioe.18.2016.04.04.19.32.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Apr 2016 19:32:39 -0700 (PDT) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_95A7B9F0-9071-4AB1-B937-7D257FE6361B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <5702C912.6040506@gmail.com> Date: Mon, 4 Apr 2016 23:32:34 -0300 Message-Id: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:32:43 -0000 --Apple-Mail=_95A7B9F0-9071-4AB1-B937-7D257FE6361B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here is my proposed text: Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]. Extension headers must never be deleted or changed in size by any node on the path the packet takes. The contents of an Extension header or Option in an Extension header may be modified if this is permitted by the definition of the Extension header or option. The first paragraph is unchanged. I will probably combine all of this = into one paragraph, but kept separate for now for easier review. Comments? Thanks, Bob > On Apr 4, 2016, at 5:05 PM, Brian E Carpenter = wrote: >=20 > Thanks Bob, that all works for me. >=20 > RFC 4782 seems to be problematic. >=20 > Brian >=20 > On 05/04/2016 07:46, Bob Hinden wrote: >> Brian, >>=20 >>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter = wrote: >>>=20 >>> Hi, >>>=20 >>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 = that >>> seems to come up repeatedly. >>>=20 >>> Are intermediate systems allowed to insert, change or delete = Extension Headers, >>> apart from specified cases (routing headers, and HbH options that = may change >>> en route)? And in the cases where changes are allowed, are = intermediate systems >>> allowed to change the *length* of headers or option data? >>=20 >> Some relevant words from rfc2460bis Section 4. "IPv6 Extension = Header": >>=20 >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >>=20 >> I think covers the inserting issue. >>=20 >> I don=E2=80=99t see any text that prohibits changing or deleting = Extension Headers. I think it was the intent to not delete or change = the length of Extension Headers, so we could add that as a = clarification. Changing the content is more complex, as you note, we do = allow changing the content of some extension headers. I think that = needs to be part of the definition of each extension header. >>=20 >> We could add text cover deleting and changing the length. >>=20 >>=20 >>> For option data, the answer is clear but slightly hidden: since the = Option Data >>> but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data = Len is >>> clearly not allowed to change and therefore options cannot be = inserted or >>> deleted either (which breaks RFC 4782). But it isn't stated anywhere = that >>> I can see that intermeiate systems must not insert, change or delete = EHs, >>> although they are all supposed to be e2e except for HbH options. >>=20 >> I think that confirms the intent. I could work on some text for = rfc2460bis. >>=20 >> Bob >>=20 >>>=20 >>> Maybe that needs to be an erratum on 2460? >>>=20 >>> Regards >>> Brian >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 --Apple-Mail=_95A7B9F0-9071-4AB1-B937-7D257FE6361B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXAyPDAAoJEK7rdBF357uo8LEH/14Nq6Q4xphU2v8N8YNWMjhN S0xqOq4++hSUfrBUtUPZsAjqvx7HYBezTpbO+EsC+dYyoGX/i94wCfQoRCwVYY2l R2GG3B5QAngadmHrm809O+Q4D6C4zDhWjPgirjRi3iFqEwdqSeOtiY6TBblHi1n4 cq8uyXsH+C6g5iS6QWONZrA/bbdZyNpv/LTxZ4miD9cFK+81NbQA0yRVCeg7QpMB 1SfW9yNOqt9s+q8OTIz856ILAy+cLDbCoAld4xQV5c2GGXmxst6SKZmLoiyPShpA hBtfmX/vW8s3KP9Q3MOd6GSW9A8iJEidGtUR9pOgAjpmSNWRpa7kZTyFCKImyPU= =ZY0M -----END PGP SIGNATURE----- --Apple-Mail=_95A7B9F0-9071-4AB1-B937-7D257FE6361B-- From nobody Mon Apr 4 19:48:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE3C12D1E3 for ; Mon, 4 Apr 2016 19:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.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=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 iCINsH564JLz for ; Mon, 4 Apr 2016 19:48:48 -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 A957812D176 for ; Mon, 4 Apr 2016 19:48:48 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c4so809434vkb.3 for ; Mon, 04 Apr 2016 19:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HvpqO59AHzcam/BWk450S3c08UGJl0JTXTNtlSEVmJ8=; b=kVRy4ruZ/IHffEgf+krRS1DvmZWvEJQ14yarakWESeExipgnzzZ8Cw1LqwnBoRn71D VxWRTahvjuBxch/MOYNQXc4crQ1g0xUwM4wrqVVhbj8Lh/2JaXXdyScFAGOCY68xfqYC 1s9HeMQH+sekJT09pUxlareX41o3BiNmg2she4WZZGa3eGC0OTZ1GjXAM7Vyou8Qd3I3 byoXwl3sFbvmRkjxy5XWrxWaemuS8tfGLVa1vMWj+JJ4YXMSElw/IKbdVtxP6eA8d9jJ QN7neG4CL6n6/99bqNZUSaP1pI/BbgySslNteQ/mcSxSudjyy8aKeLCabbnqH1aiVCfL Ibqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HvpqO59AHzcam/BWk450S3c08UGJl0JTXTNtlSEVmJ8=; b=YNb3mvG6YVq+Apv0ckBe56DM2S0n+ElP1iuDL/TMceNA6VBQyGHXtT8e2Ef4ht4E6K EmsOZidj+mAv57vy1uKnamctusQuibDJS1Va3cSZ7oYYtmST6tMbh0iaiyYKt/BFq01v IQUT6X37ya0S1bLagLnZWuQlEx3EkdHO7RhGOpubFuhTC8PlXBov81Cr1LCrD4oylCfE 5hSDEmb1nYlYsTveU/QBhKQeuFuJcGRxB5f9kCl/FYB0+1ldY1Ax49B3wI9YvbW0IM27 SkmxIEwTpQRpAAspXkSyFA3h2uM39fbXzb2p3J3IKRUtnvbgUn0SxYr1xq6ekSujuoc1 +OVQ== X-Gm-Message-State: AD7BkJIWqv/BXci0oJRtmQs1MXk9eUjFxo9AJj0iMnf85gUBoWJ9W6ZB4PVxKZcneRDh/wiBY7JRmYt8nuxJJA== MIME-Version: 1.0 X-Received: by 10.31.128.82 with SMTP id b79mr10625672vkd.47.1459824527774; Mon, 04 Apr 2016 19:48:47 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Mon, 4 Apr 2016 19:48:47 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Mon, 4 Apr 2016 19:48:47 -0700 (PDT) In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> Date: Tue, 5 Apr 2016 12:48:47 +1000 Message-ID: Subject: Re: rfc2460bis question From: Mark Smith To: Bob Hinden Content-Type: multipart/alternative; boundary=001a11429ce4699901052fb3e277 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:48:51 -0000 --001a11429ce4699901052fb3e277 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 Apr 2016 12:32 PM, "Bob Hinden" wrote: > > Here is my proposed text: > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > Extension headers must never be deleted or changed in size by any > node on the path the packet takes. > > The contents of an Extension header or Option in an Extension header > may be modified if this is permitted by the definition of the > Extension header or option. > > The first paragraph is unchanged. I will probably combine all of this into one paragraph, but kept separate for now for easier review. > > Comments? > I like it. Regards, Mark. > Thanks, > Bob > > > On Apr 4, 2016, at 5:05 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > > Thanks Bob, that all works for me. > > > > RFC 4782 seems to be problematic. > > > > Brian > > > > On 05/04/2016 07:46, Bob Hinden wrote: > >> Brian, > >> > >>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 tha= t > >>> seems to come up repeatedly. > >>> > >>> Are intermediate systems allowed to insert, change or delete Extension Headers, > >>> apart from specified cases (routing headers, and HbH options that may change > >>> en route)? And in the cases where changes are allowed, are intermediate systems > >>> allowed to change the *length* of headers or option data? > >> > >> Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header"= : > >> > >> Extension headers must never be inserted by any node other than the > >> source of the packet. IP Encapsulation must be used to meet any > >> requirement for inserting headers, for example, as defined in > >> [RFC2473]. > >> > >> I think covers the inserting issue. > >> > >> I don=E2=80=99t see any text that prohibits changing or deleting Exten= sion Headers. I think it was the intent to not delete or change the length of Extension Headers, so we could add that as a clarification. Changing the content is more complex, as you note, we do allow changing the content of some extension headers. I think that needs to be part of the definition of each extension header. > >> > >> We could add text cover deleting and changing the length. > >> > >> > >>> For option data, the answer is clear but slightly hidden: since the Option Data > >>> but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data Len is > >>> clearly not allowed to change and therefore options cannot be inserted or > >>> deleted either (which breaks RFC 4782). But it isn't stated anywhere that > >>> I can see that intermeiate systems must not insert, change or delete EHs, > >>> although they are all supposed to be e2e except for HbH options. > >> > >> I think that confirms the intent. I could work on some text for rfc2460bis. > >> > >> Bob > >> > >>> > >>> Maybe that needs to be an erratum on 2460? > >>> > >>> Regards > >>> Brian > >>> > >>> -------------------------------------------------------------------- > >>> 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 > -------------------------------------------------------------------- > --001a11429ce4699901052fb3e277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Apr 2016 12:32 PM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
> Here is my proposed text:
>
> =C2=A0 =C2=A0Extension headers must never be inserted by any node othe= r than the
> =C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must be used= to meet any
> =C2=A0 =C2=A0requirement for inserting headers, for example, as define= d in
> =C2=A0 =C2=A0[RFC2473].
>
> =C2=A0 =C2=A0Extension headers must never be deleted or changed in siz= e by any
> =C2=A0 =C2=A0node on the path the packet takes.
>
> =C2=A0 =C2=A0The contents of an Extension header or Option in an Exten= sion header
> =C2=A0 =C2=A0may be modified if this is permitted by the definition of= the
> =C2=A0 =C2=A0Extension header or option.
>
> The first paragraph is unchanged.=C2=A0 I will probably combine all of= this into one paragraph, but kept separate for now for easier review.
>
> Comments?
>

I like it.

Regards,
Mark.

> Thanks,
> Bob
>
> > On Apr 4, 2016, at 5:05 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:<= br> > >
> > Thanks Bob, that all works for me.
> >
> > RFC 4782 seems to be problematic.
> >
> >=C2=A0 =C2=A0 Brian
> >
> > On 05/04/2016 07:46, Bob Hinden wrote:
> >> Brian,
> >>
> >>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
> >>>
> >>> Hi,
> >>>
> >>> rfc2460bis doesn't fix an ambiguity in interpretation= of RFC 2460 that
> >>> seems to come up repeatedly.
> >>>
> >>> Are intermediate systems allowed to insert, change or del= ete Extension Headers,
> >>> apart from specified cases (routing headers, and HbH opti= ons that may change
> >>> en route)? And in the cases where changes are allowed, ar= e intermediate systems
> >>> allowed to change the *length* of headers or option data?=
> >>
> >> Some relevant words from rfc2460bis Section 4. "IPv6 Ext= ension Header":
> >>
> >>=C2=A0 =C2=A0Extension headers must never be inserted by any n= ode other than the
> >>=C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must= be used to meet any
> >>=C2=A0 =C2=A0requirement for inserting headers, for example, a= s defined in
> >>=C2=A0 =C2=A0[RFC2473].
> >>
> >> I think covers the inserting issue.
> >>
> >> I don=E2=80=99t see any text that prohibits changing or delet= ing Extension Headers.=C2=A0 I think it was the intent to not delete or cha= nge the length of Extension Headers, so we could add that as a clarificatio= n.=C2=A0 Changing the content is more complex, as you note, we do allow cha= nging the content of some extension headers.=C2=A0 I think that needs to be= part of the definition of each extension header.
> >>
> >> We could add text cover deleting and changing the length.
> >>
> >>
> >>> For option data, the answer is clear but slightly hidden:= since the Option Data
> >>> but *not* the Opt Data Len may be omitted from IPSec AUTH= , Opt Data Len is
> >>> clearly not allowed to change and therefore options canno= t be inserted or
> >>> deleted either (which breaks RFC 4782). But it isn't = stated anywhere that
> >>> I can see that intermeiate systems must not insert, chang= e or delete EHs,
> >>> although they are all supposed to be e2e except for HbH o= ptions.
> >>
> >> I think that confirms the intent.=C2=A0 I could work on some = text for rfc2460bis.
> >>
> >> Bob
> >>
> >>>
> >>> Maybe that needs to be an erratum on 2460?
> >>>
> >>> Regards
> >>>=C2=A0 Brian
> >>>
> >>> ---------------------------------------------------------= -----------
> >>> 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
> -------------------------------------------------------------------- >

--001a11429ce4699901052fb3e277-- From nobody Tue Apr 5 09:56:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E257912D7CC for ; Tue, 5 Apr 2016 09:56:44 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 0u-MudtSp1T3 for ; Tue, 5 Apr 2016 09:56:43 -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 3030B12D798 for ; Tue, 5 Apr 2016 09:56:43 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id o126so3813360iod.0 for ; Tue, 05 Apr 2016 09:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=4VDm7qKlYABwNP4iRkPyEI0nv0QHRn5cu79+sOh+MDc=; b=0naEoFZ4RMTHT3sj1Rn/Rqds7YlF1yNR02HvMhtjophxg4r5KEA/JIPw3k0aTZ5/EB JpdSNfalG/XU25qKMI/MDDbYigaP/Ln6qNcV40Sv+Pig5JjezSB0sv10Zwj3kugqNjjU Cx6xMUwMonNY0LrlyyHmB/VsZ8ku1CMP8GilOBZ0U9eqTuul2rjgQiyJZV7unnPIAucZ clopYUgc47aJaQsQ+rjpZjcXzYMjwsGbYtpl6e/T7NaG1wU3dYfvhRMSPR+AA49cwiym joFn+F/801KvdokQ4iuv+/jqOSvrqRJ25Jdj3QVIJIE2O5JD/jCg08Ac913/bM4x2pgk gF1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4VDm7qKlYABwNP4iRkPyEI0nv0QHRn5cu79+sOh+MDc=; b=GIIGPIq93wkabS5FWrK3A91s7nVXUQKBhYSELYXuXm5VI4qJMaUEqdg91df1MeKfTW 3bD5HecJl4xhB3AhDi5ZHz8HGqEnGSu8wqzeYFfQRTXEAQmHIukC1M5p3hjP4grPRtlp 1o0tSM+EfDVsTz0JyKP8xXVqnffPQ4EzzFnBNDusUYRbhFr5uPJpklWFQqdr95j0GUwd Qy/Q5P7DCRRhz0dYwz3I3uGES0KlhUkJNwT3DoKDMkHgzxPl83OK4G47Roda4/GOAYZB O5XtQSjer03KFkwAUflEtmqSbS/ga3YYG/UAqgYcsB6YEBcKoa6q1pEUBY2Cy0Hvzxwy yCZQ== X-Gm-Message-State: AD7BkJJRTBnQyQ/xewBgjqq7n0f5qMBNQPGo0nOEAIZUl0V5PQ20bRXlmz/tr+oNGY8QuoUHYsBn/3E6E/G1Ag== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr31270652iop.172.1459875402523; Tue, 05 Apr 2016 09:56:42 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.198.133 with HTTP; Tue, 5 Apr 2016 09:56:42 -0700 (PDT) In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> Date: Tue, 5 Apr 2016 09:56:42 -0700 X-Google-Sender-Auth: BNg1jbqZRdMkqcfpkvXmvdm5XWY Message-ID: Subject: Re: rfc2460bis question From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:56:46 -0000 At Mon, 4 Apr 2016 23:32:34 -0300, Bob Hinden wrote: > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > Extension headers must never be deleted or changed in size by any > node on the path the packet takes. > > The contents of an Extension header or Option in an Extension header > may be modified if this is permitted by the definition of the > Extension header or option. > > The first paragraph is unchanged. I will probably combine all of this into one paragraph, but kept separate for now for easier review. The text looks good to me, but should we also do something explicitly for cases like RFC4782 (or any other existing spec that would violate this clarification)? For example, should we explicitly refer to such RFC(s) and explain, e.g., those spec exist due to less clear wording of RFC2460 but should have been considered invalid all the time? Should we add "Update RFC4782" tag to rfc2460bis? -- JINMEI, Tatuya From nobody Tue Apr 5 10:23:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F42312D8E8 for ; Tue, 5 Apr 2016 10:23:13 -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 Fck0yV901shw for ; Tue, 5 Apr 2016 10:23:10 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 848E712D8A9 for ; Tue, 5 Apr 2016 10:23:10 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id y89so15844470qge.2 for ; Tue, 05 Apr 2016 10:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ZzoRkaf6bUH3qSf1Ht7nES6zaQdxt1ESyybzVkLorrw=; b=uFDb6uCCT1U3Z225MBGRxxX/yBORyXYtfrKqBJB/zFJzyAy9crCzSv9wGTlH2eF33f nLHLCgYqL0TBvMCTZXloEe4Hga6agl9LcTfblZm1tpGnWj6s3YddZHXrN5GGtOBnnmHw kv0MfcqzeSUlRDBHA4ash1QznMjC1ndnuJAnN73gVrmf7jWLkFSszH7G5/g8zujII4MK xQt/KGND+HEKtKy1XS89WyRJj7yUVvLJ8b95iOKqHLG/QCBnl+Z2cFjdlXTD4usYRzOm rb/w9o5QihnPkPqGjpaaJZ82+wqdiw/QW3B1sioiwzCl/8a5vGw15QzrPU2XE+sTffL9 fGLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ZzoRkaf6bUH3qSf1Ht7nES6zaQdxt1ESyybzVkLorrw=; b=NQqpn1KA2+e4CeCyimUPgkaDZvJKIXXR+MQ3NObBHcmyTclMnoAxS+G/6OZxACljFG iQvNkUlC/yhJ6jqlf3NA4jcNAFdwyqxu6iX/6Lw7Yp5zuiYAAKZF0ImF2FYqcJG7Xxp/ ThlydvYFOfyGUUmu2KJqtrbTH1qDMP/OK0kbjY2PY4hLs7pxcVyf0oh1Q97/C2FOLAW2 Zdhw2w1kBWVpduNHqbLK7AgtlqICmCUjsAoKYeYNOj/0PuKInzGnCU5idnRsXOrawrZe 4qAfDE7BAu9ATJ3rUKM6fSxLLOrFJHVj9KxbrH5HdsOjE2rbLbcP8xciw8MZhYzL6hUx nF9w== X-Gm-Message-State: AD7BkJLoOYcATyoB2nCbrZkmigoDTbjaayiDep4tpXNAsodc8ByugpveMs+QdM1wOCBjEw== X-Received: by 10.140.86.101 with SMTP id o92mr18982452qgd.49.1459876989640; Tue, 05 Apr 2016 10:23:09 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:8546:d0a7:b378:4441? ([2001:67c:370:176:8546:d0a7:b378:4441]) by smtp.gmail.com with ESMTPSA id a90sm15071515qka.4.2016.04.05.10.23.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 10:23:08 -0700 (PDT) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2BD09EAC-6929-4370-B432-80D83AA69CE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Tue, 5 Apr 2016 14:23:04 -0300 Message-Id: <01FFA86E-14AF-4AEB-9349-30E576C786D7@gmail.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:23:13 -0000 --Apple-Mail=_2BD09EAC-6929-4370-B432-80D83AA69CE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei, > On Apr 5, 2016, at 1:56 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 ... >=20 > The text looks good to me, but should we also do something explicitly > for cases like RFC4782 (or any other existing spec that would violate > this clarification)? For example, should we explicitly refer to such > RFC(s) and explain, e.g., those spec exist due to less clear wording > of RFC2460 but should have been considered invalid all the time? > Should we add "Update RFC4782" tag to rfc2460bis? I am not sure it's appropriate to include updating text in rfc2460bis = since RFC4782 is experimental, how about if we submit an errata on = RFC4782 when rfc2460bis is published describing the issue. Bob >=20 > -- > JINMEI, Tatuya --Apple-Mail=_2BD09EAC-6929-4370-B432-80D83AA69CE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXA/R5AAoJEK7rdBF357uoW+IIALMJzjjoHzRQD4YY7BLZ3Tes DQT/kSG/t/K1oMoSoixlFHS33/j0XdOOs44YrTYY5lvH8mHFtgBuyBBKRCGyz36C 4WAIe0M97cESeHj9GrIN12Bsgz4S8yDtnXMprztP1QgFAKDUkdZpo9yRm/zQwIBm +OsQxlxcueySBr5iJwarO+GHM+LX4sZZCxzdwxPTywg4sFTS6f+8ISomSPp40+fU f0UalLoEYLpvz+7EygDV9QrzW+zKL/xrJA9ERtYyG4mjN0Y8E+WOORWoWYhhAGWF Ce4aZ2plGoQikOOQt4XQZ2uksI2j5nyUsCkcWWvFK2SOb2BzQc7bKTnF1nLFrjY= =G5fY -----END PGP SIGNATURE----- --Apple-Mail=_2BD09EAC-6929-4370-B432-80D83AA69CE1-- From nobody Tue Apr 5 10:45:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FA412D1D2 for ; Tue, 5 Apr 2016 10:45:33 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 00AcWLwv8QkY for ; Tue, 5 Apr 2016 10:45:32 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 53CFB12D7B7 for ; Tue, 5 Apr 2016 10:45:32 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id f1so112096601igr.1 for ; Tue, 05 Apr 2016 10:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=PSHSA6sokdYcuctQUkC32Dse1a0DO6KrnVsqxiqwkxA=; b=qNkFd9in2P4jsJduRIi0ulAtZnkAmniJakJGySorYoi3p2QXhfzVUI2gaGqQlJfbHP lrTemQm+ZvpJ+aPeVAS9qq7HmjDgpBSQNdFLGA2KhTR79SNxfRxA77yqpVH1hPhXQ4XF 4xcRV7es9VJ1/fAX21xPGszIZQ6D/FmTd6hUtuJYu4p5Vs4fErdczrtbQKpGFOvkrfzn w0KpVQx+xsvM8uXq8aljzB1Roys6YQ90TTjIq9+1iG4loDo2FufAEU6i/qGwLeLrAnHR tnwCf7XjVrqYsdwe8vHtg6P5BhG34DSCu1S4kR1aA42cSSDeYEfIQBQbPS5NOwrM1Q+t Nouw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PSHSA6sokdYcuctQUkC32Dse1a0DO6KrnVsqxiqwkxA=; b=iKjaKJtbsVWSUb4w1ZgAKMqF6k6P02Ejfg9T6pqtzuDzBTlZ5I1H4iwxsQSH+LZp9O RRKMZoBtRCckanOEkZSTX1KN6s5cWC8LhdQIg6d00OBHnz7Xxr6Na4DDKPXKQyp5l3Z1 GOJp3VfNelVMFQdeDH73hdbnFo1dnrvy73EO5OE85n8nISlZ4+S06I9t9xC5yfbfH5nU 7YNKcvWL4X1M8ZC+e6852i87cs43mjxixWMVEfYyousj6oDxIl2cV9tozp+FzzudaBOo rjqlg6QTbJa5FbU7LiXUxEckl2Hjxdz/yXGCjAwbujGp8iCpN4RYeMKo28cFvBbY72xh pr5w== X-Gm-Message-State: AD7BkJKlF/Em5yygnX9PNK5oz+ATSrStrEUqEiu9q7lSxg8b9bvLMBkJ/Acfwb4ayzMFjQ3ng43xb0oLhmJ9zQ== MIME-Version: 1.0 X-Received: by 10.50.160.39 with SMTP id xh7mr16552153igb.64.1459878331583; Tue, 05 Apr 2016 10:45:31 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.198.133 with HTTP; Tue, 5 Apr 2016 10:45:31 -0700 (PDT) In-Reply-To: <01FFA86E-14AF-4AEB-9349-30E576C786D7@gmail.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> <01FFA86E-14AF-4AEB-9349-30E576C786D7@gmail.com> Date: Tue, 5 Apr 2016 10:45:31 -0700 X-Google-Sender-Auth: TkZzWHZeoF99ljpl4Pb626GqOuw Message-ID: Subject: Re: rfc2460bis question From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:45:34 -0000 At Tue, 5 Apr 2016 14:23:04 -0300, Bob Hinden wrote: > > The text looks good to me, but should we also do something explicitly > > for cases like RFC4782 (or any other existing spec that would violate > > this clarification)? For example, should we explicitly refer to such > > RFC(s) and explain, e.g., those spec exist due to less clear wording > > of RFC2460 but should have been considered invalid all the time? > > Should we add "Update RFC4782" tag to rfc2460bis? > > I am not sure it's appropriate to include updating text in > rfc2460bis since RFC4782 is experimental, how about if we submit an > errata on RFC4782 when rfc2460bis is published describing the issue. I don't necessarily think it's inappropriate (unlike a case where an experimental updates a standards track), but I'm fine with the errata approach, too. I just thought we should take some explicit action to resolve this seeming conflict. -- JINMEI, Tatuya From nobody Tue Apr 5 13:33:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263B312D854 for ; Tue, 5 Apr 2016 13:33:37 -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 Mzb1pZKvDf0W for ; Tue, 5 Apr 2016 13:33:34 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 46AAC12D63A for ; Tue, 5 Apr 2016 13:33:28 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id fe3so17490227pab.1 for ; Tue, 05 Apr 2016 13:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YHiFhDxw+3OkwCwF5iBY46vHs1FUJ2H3A3ze5mGSQLY=; b=a+rguVf/8IKQ5RKbjGL0RV5SQiKaYmeAp9XL6FYwsDLYTljMgydIElBtNIXEfFDa1o RJifJkVepxPCBVvOqlLZu3Uy6RH5p+Gpp/lp6/yDh16vfTmJDCtx3CS/o998sWlx949Q 53dGlIWZMXIJaypdbNvZsSPC/6Z/XEeaE52ltoCf6Hk4ZfRXZGLrWVAojCOeXnKS1fhX 4m8LkMHKIguwb0GUD9GDcgfAdfPW507Is1iRsp7bHA8kzF5aOt5s9qFtVSjfIRS54ceb iOQgxQs1fZCEwJG/Sgc2JNKl6ziy6Z5B1z13V2Y0qVLd/KQQg6LyWjSglQUeKZM2B0hP IkpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YHiFhDxw+3OkwCwF5iBY46vHs1FUJ2H3A3ze5mGSQLY=; b=VMSfwv7KRaJ/pzAcOiv6vIpC7ZbXRKg5DElnGGcCUGsZbub5qaqPegcZxpnuvJLn04 18JQ6wKIKasInk/PYfJVFhMhQZzgs7vLiZWSe4hv2xlF+b5v0A4xwMBSMUw6rLMd2T7I Q8ZtOdmBl8DEOpSwtU9Q6CZTJ8N/a8/6yutrmihH+bXZASC8K3JBX8HX5ZgdlZkjLrzZ DMZWbY2LOfRreMqvAGqHZRmgns/SGM0WGmkOsS4e/fwNQ4x09z/WCJM3K6Lbm2LJAKAq oYPj2MWfeVMmhiTaBZkFUGLWyBBVkm1QCAuFnE3Py1Qg7iIKFXMiEW8yGt3gyepaAIrF Wh+A== X-Gm-Message-State: AD7BkJKyFeYYMyYuvzhgzGFUDJKuUtZPgNm+5jKSzbUaTsoq1UH3Men43dMuv9sYDu74MQ== X-Received: by 10.66.54.78 with SMTP id h14mr64970447pap.95.1459888375940; Tue, 05 Apr 2016 13:32:55 -0700 (PDT) Received: from ?IPv6:2406:e007:4ed6:1:28cc:dc4c:9703:6781? ([2406:e007:4ed6:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x64sm48822201pfa.72.2016.04.05.13.32.53 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 13:32:54 -0700 (PDT) Subject: Re: rfc2460bis question To: ipv6@ietf.org References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> <01FFA86E-14AF-4AEB-9349-30E576C786D7@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570420F7.2030408@gmail.com> Date: Wed, 6 Apr 2016 08:32:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:33:37 -0000 On 06/04/2016 05:45, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 5 Apr 2016 14:23:04 -0300, > Bob Hinden wrote: >=20 >>> The text looks good to me, but should we also do something explicitly= >>> for cases like RFC4782 (or any other existing spec that would violate= >>> this clarification)? For example, should we explicitly refer to such= >>> RFC(s) and explain, e.g., those spec exist due to less clear wording >>> of RFC2460 but should have been considered invalid all the time? >>> Should we add "Update RFC4782" tag to rfc2460bis? >> >> I am not sure it's appropriate to include updating text in >> rfc2460bis since RFC4782 is experimental, how about if we submit an >> errata on RFC4782 when rfc2460bis is published describing the issue. >=20 > I don't necessarily think it's inappropriate (unlike a case where an > experimental updates a standards track), but I'm fine with the errata > approach, too. I just thought we should take some explicit action to > resolve this seeming conflict. I think that a patch to RFC4782, suggested by Fred, to overwrite the option with a PAD, would be a valid erratum, and would actually have been a better fix when the document was approved than the changes made after Last Call. Brian From nobody Tue Apr 5 15:52:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE90612D162 for ; Tue, 5 Apr 2016 15:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kHyaK5ETyL_u for ; Tue, 5 Apr 2016 15:52:07 -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 6698812D134 for ; Tue, 5 Apr 2016 15:52:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E6002002A; Tue, 5 Apr 2016 18:55:36 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 82FD66375A; Tue, 5 Apr 2016 18:52:06 -0400 (EDT) From: Michael Richardson To: Bob Hinden Subject: Re: rfc2460bis question In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:52:08 -0000 --=-=-= Content-Type: text/plain Bob Hinden wrote: > Here is my proposed text: > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > Extension headers must never be deleted or changed in size by any > node on the path the packet takes. > The contents of an Extension header or Option in an Extension header > may be modified if this is permitted by the definition of the > Extension header or option. > The first paragraph is unchanged. I will probably combine all of this > into one paragraph, but kept separate for now for easier review. > Comments? I'd rather you left them as seperate sections, and I wouldn't mind if they were easily referred to, as it would make it easier to explain if I could say rfc2460bis#section4_1_1 or something like that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwRBk4CLcPvd0N1lAQLatAf9Epivn+ZhIh4ASj1qaz/ImAxBTJK7lXjs GfdaUbgwGAW+f07KXFJ/Jvbo+snJrcqe42wZN7LzhOvVBxd5RszXuqcCwTSYdnFJ Wh7250cCeifotATmmPEwOudNBCsrgaFsO5PwdvSCCyy0Yhne9wetkxqriHYr65Qw hLqdhxaonjiWXCV3mhTM7A9UEvfO0WHFvMHePrhdJPchjboWaWDa8b84EbUxVisz LwIqy78/oMzJi+HXIl7Po4fhkNXbGm95ccmkhFGhS73TSoMfpF7WjDWniv4aYW+Z WD8nk7Pt2CxLA5hNvY/0SuRm+Ir61CcPL/idWwuJGV8WmAH6bhZvoQ== =8imq -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 5 17:27:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F086512D627 for ; Tue, 5 Apr 2016 17:27:35 -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 WoPFtQEf4J1C for ; Tue, 5 Apr 2016 17:27:33 -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 49E4912D61F for ; Tue, 5 Apr 2016 17:27:33 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id t10so37450965ywa.0 for ; Tue, 05 Apr 2016 17:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=0X6j7t7Fjmf8MlqXujtiJv7PRKky46KoHw2wPuDq6IA=; b=fgW1hQJIiixhFAjovhYN7lnCb/tx4SakdnAlYXaPXeOP2fFRbkiy67pfGLiqvgvba0 YTSZHw+9XA1fgWM43p77Dee4d1ouMQvHa+HmCx8WNiLjsPmFm643rDZ9ky4KJBM87AkP pGC8pMKEg9AvgiTho09CL50051VoA22apbRhfrs4fJVCOFuAvFalHpeyKLqJZz+fMINx zMGee2eruKfOLhERP0yuJWbvDjGLYSIT756RV5bB1LFM82hDKMpCCSSETs33FpB1Oisu 7FwdeB/Abl5Wrnnn1FGuvTcUftN8mxdewe9+23yo8Xxzmw844YyvssseYnFi3dxS5I8T JXCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=0X6j7t7Fjmf8MlqXujtiJv7PRKky46KoHw2wPuDq6IA=; b=bVoyAdOk/+4dJY2iC88bb1Cdeycb7YIEWWsBfNyH+VP+D7hWzTuEa8mBl5ELcVwkX2 pKfhHF9eyD4x3S7CCpFwp0PlT0e5nmTPw+5ZIJ9h2uPQNhRo+G1vzwkN6LkuZdO6endY QZDW+QswlLeQMp7I0+sbihwrTA7cmM5fKAZp+G7vtJNign8qUysbh4cDzPFug2kStwCW AdKeid/3K2ttRfQj4+J2koqZ+ZO0Ww99kBQk+eynR47cmxnuMyIfstaPjSsjs5rVZax6 6s1utuelCsqQzbR3pXXRRKkDnkgRIQi3w0hOGR2Qvz+JbY1Dct9/CzAIHdyqq6f358C+ Dh8w== X-Gm-Message-State: AD7BkJLJq4PZOQ1Ko2/noENMYVNnpQpjr9u9tSDdTY+WkHoNJhLY4WqtzuNfL+TKflyPDw== X-Received: by 10.129.109.195 with SMTP id i186mr13115278ywc.255.1459902452530; Tue, 05 Apr 2016 17:27:32 -0700 (PDT) Received: from dhcp-93f1.meeting.ietf.org (dhcp-93f1.meeting.ietf.org. [31.133.147.241]) by smtp.gmail.com with ESMTPSA id y81sm197899ywc.50.2016.04.05.17.27.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 17:27:31 -0700 (PDT) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E29768A6-E977-485B-87D1-77CDB410A97E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <1435.1459896726@obiwan.sandelman.ca> Date: Tue, 5 Apr 2016 21:27:28 -0300 Message-Id: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> <1435.1459896726@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 00:27:36 -0000 --Apple-Mail=_E29768A6-E977-485B-87D1-77CDB410A97E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, > On Apr 5, 2016, at 7:52 PM, Michael Richardson = wrote: >=20 >=20 > Bob Hinden wrote: >> Here is my proposed text: >=20 >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >=20 >> Extension headers must never be deleted or changed in size by any >> node on the path the packet takes. >=20 >> The contents of an Extension header or Option in an Extension header >> may be modified if this is permitted by the definition of the >> Extension header or option. >=20 >> The first paragraph is unchanged. I will probably combine all of = this >> into one paragraph, but kept separate for now for easier review. >=20 >> Comments? >=20 > I'd rather you left them as seperate sections, and I wouldn't mind if = they > were easily referred to, as it would make it easier to explain if I = could say > rfc2460bis#section4_1_1 or something like that. I am OK keeping it as separate paragraphs, but making each (the last two = are only one sentence) a separate section, would be be sort of odd. You = could refer to them as, for example, the third paragraph of Section 4. Bob >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 --Apple-Mail=_E29768A6-E977-485B-87D1-77CDB410A97E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXBFfwAAoJEK7rdBF357uoHQ4H/jmbWY89Z96WLqnV3JiCmILR OIFYg69kw4Ggx9UlG5xxuiUds83Dc04QKN4gFypc/Ql8SuXYKIwC5ifGVdqpom2y 2eI4VfImza98UE39zz5Hk1kbqVMi25zI7QsjsiHmjYq+HGYpV7HcllZzLYoeKcVo u5bYlADYgcllwMA4tCOg+rdIbo53w8lbVNwezB7IjolCGUakMTq9uaQiFzwOZMLj qoBLejV3AKOGDI+2p5hL91pyc2J5XmoNBi+cfe8HdvI0ZYca5zKAXndFkciBpYjP wofKVu4/xfod0ZJilV3Xd+ipPXtvuN2yuzHjIc1zWo69s+AQmJEqzlto4S0ZNjA= =hVUO -----END PGP SIGNATURE----- --Apple-Mail=_E29768A6-E977-485B-87D1-77CDB410A97E-- From nobody Wed Apr 6 03:46:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4693212D187 for ; Wed, 6 Apr 2016 03:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4I3gSJcu7cfS for ; Wed, 6 Apr 2016 03:46:42 -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 63CA912D0B9 for ; Wed, 6 Apr 2016 03:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4624; q=dns/txt; s=iport; t=1459939602; x=1461149202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0FJROlcB0Xdb+zGagTzOoaj379e4pF5RsQJcQU0LkkI=; b=Iy7624lxScbwBAlzIXk3LuS/6SFkEOV1MKQ3VClxYLlUgrEbH1LNOO/8 L6rjeeDC6EGq7OjcRBKM5a96EsPwdE/7vU2qIfF+KBCv078jH2L16Lje0 2hfyB2ku8HugtIQrAO2tBBSWqV8erRj9NRQMSqD7yvdPAg+2mpps2wFQq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCD6ARX/4ENJK1cgzdTfQaudItXA?= =?us-ascii?q?Q2BchcKhWwCHIElOBQBAQEBAQEBZSeEQQEBAQMBAQEBIBE6CwULAgEGAhgCAiY?= =?us-ascii?q?CAgIfBgsVEAIEDgWIEgMKCA6RTp0XjGENhQoBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERBHyFJYF1glaCQYR+K4IrBYdvj2ExAYwVgXWPDodHh1kBHgEBQoNnbAGHdH4?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="88795720" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 10:46:41 +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 u36AkfNp011227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 10:46:41 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.1104.5; Wed, 6 Apr 2016 06:46:40 -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.1104.009; Wed, 6 Apr 2016 06:46:40 -0400 From: "Stefano Previdi (sprevidi)" To: Bob Hinden Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRj/GZGbjOPkFJykCCV3KDKYtuDg== Date: Wed, 6 Apr 2016 10:46:40 +0000 Message-ID: <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> In-Reply-To: <8A52FAF7-DDB0-4150-B22E-14A7912375D9@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.24.69.136] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:46:44 -0000 DQo+IE9uIEFwciA0LCAyMDE2LCBhdCA5OjQ2IFBNLCBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdt YWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBCcmlhbiwNCj4gDQo+PiBPbiBNYXIgMjgsIDIwMTYsIGF0 IDk6MzAgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ IHdyb3RlOg0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gcmZjMjQ2MGJpcyBkb2Vzbid0IGZpeCBhbiBh bWJpZ3VpdHkgaW4gaW50ZXJwcmV0YXRpb24gb2YgUkZDIDI0NjAgdGhhdA0KPj4gc2VlbXMgdG8g Y29tZSB1cCByZXBlYXRlZGx5Lg0KPj4gDQo+PiBBcmUgaW50ZXJtZWRpYXRlIHN5c3RlbXMgYWxs b3dlZCB0byBpbnNlcnQsIGNoYW5nZSBvciBkZWxldGUgRXh0ZW5zaW9uIEhlYWRlcnMsDQo+PiBh cGFydCBmcm9tIHNwZWNpZmllZCBjYXNlcyAocm91dGluZyBoZWFkZXJzLCBhbmQgSGJIIG9wdGlv bnMgdGhhdCBtYXkgY2hhbmdlDQo+PiBlbiByb3V0ZSk/IEFuZCBpbiB0aGUgY2FzZXMgd2hlcmUg Y2hhbmdlcyBhcmUgYWxsb3dlZCwgYXJlIGludGVybWVkaWF0ZSBzeXN0ZW1zDQo+PiBhbGxvd2Vk IHRvIGNoYW5nZSB0aGUgKmxlbmd0aCogb2YgaGVhZGVycyBvciBvcHRpb24gZGF0YT8NCj4gDQo+ IFNvbWUgcmVsZXZhbnQgd29yZHMgZnJvbSByZmMyNDYwYmlzIFNlY3Rpb24gNC4gIklQdjYgRXh0 ZW5zaW9uIEhlYWRlciI6DQo+IA0KPiAgIEV4dGVuc2lvbiBoZWFkZXJzIG11c3QgbmV2ZXIgYmUg aW5zZXJ0ZWQgYnkgYW55IG5vZGUgb3RoZXIgdGhhbiB0aGUNCj4gICBzb3VyY2Ugb2YgdGhlIHBh Y2tldC4gIElQIEVuY2Fwc3VsYXRpb24gbXVzdCBiZSB1c2VkIHRvIG1lZXQgYW55DQo+ICAgcmVx dWlyZW1lbnQgZm9yIGluc2VydGluZyBoZWFkZXJzLCBmb3IgZXhhbXBsZSwgYXMgZGVmaW5lZCBp bg0KPiAgIFtSRkMyNDczXS4NCg0KDQppbiBhIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQgd2hlcmUg Ym91bmRhcmllcyBhcmUgY2xlYXJseSBpZGVudGlmaWVkIGFuZCB3aXRoIHRoZSBhcHByb3ByaWF0 ZSBzZWN1cml0eSBtZWNoYW5pc21zLCBJIGRvbuKAmXQgc2VlIHdoeSBhbiBleHRlbnNpb24gaGVh ZGVyIGNhbuKAmXQgYmUgaW5zZXJ0ZWQsIGFzIGxvbmcgYXMgd2hhdGV2ZXIgeW91IGluc2VydCBp cyByZW1vdmVkIHdoZW4gZXhpc3RpbmcgdGhlIGNvbnRyb2xsZWQgZG9tYWluLg0KDQpBcyBhIG1h dHRlciBvZiBmYWN0LCBpdCBkb2VzIGhhcHBlbiBhbHJlYWR5IHRoYW5rcyB0byBtdWx0aXBsZSBp bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyAoc2VnbWVudCByb3V0aW5nIGhlYWRlciwgUkg0 KSBhbmQgSSBrbm93IG5ldHdvcmtzIHdoZXJlIHRoaXMgaXMgYmVpbmcgZGVwbG95ZWQuIA0KDQpB Z2FpbiwgdGhpcyBpcyBhIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQuDQoNClN0YXRpbmcgdGhhdCAi RXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBuZXZlciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZeKApuKA nSBsb29rcyBhIGJpdCBleHRyZW1lIHRvIG1lIGFuZCBJ4oCZZCBwcmVmZXIgdG8g4oCccmVjb21t ZW5k4oCdIG5vdCB0byBpbnNlcnQgcmF0aGVyIHRoYW4ganVzdCBpZ25vcmluZyB3aGF0IGhhcHBl bnMgaW4gcmVhbCBuZXR3b3JrcyBhbmQgZm9yIHJlYWwgdXNlIGNhc2VzLg0KDQpUaGFua3MuDQpz Lg0KDQoNCj4gDQo+IEkgdGhpbmsgY292ZXJzIHRoZSBpbnNlcnRpbmcgaXNzdWUuDQo+IA0KPiBJ IGRvbuKAmXQgc2VlIGFueSB0ZXh0IHRoYXQgcHJvaGliaXRzIGNoYW5naW5nIG9yIGRlbGV0aW5n IEV4dGVuc2lvbiBIZWFkZXJzLiAgSSB0aGluayBpdCB3YXMgdGhlIGludGVudCB0byBub3QgZGVs ZXRlIG9yIGNoYW5nZSB0aGUgbGVuZ3RoIG9mIEV4dGVuc2lvbiBIZWFkZXJzLCBzbyB3ZSBjb3Vs ZCBhZGQgdGhhdCBhcyBhIGNsYXJpZmljYXRpb24uICBDaGFuZ2luZyB0aGUgY29udGVudCBpcyBt b3JlIGNvbXBsZXgsIGFzIHlvdSBub3RlLCB3ZSBkbyBhbGxvdyBjaGFuZ2luZyB0aGUgY29udGVu dCBvZiBzb21lIGV4dGVuc2lvbiBoZWFkZXJzLiAgSSB0aGluayB0aGF0IG5lZWRzIHRvIGJlIHBh cnQgb2YgdGhlIGRlZmluaXRpb24gb2YgZWFjaCBleHRlbnNpb24gaGVhZGVyLg0KPiANCj4gV2Ug Y291bGQgYWRkIHRleHQgY292ZXIgZGVsZXRpbmcgYW5kIGNoYW5naW5nIHRoZSBsZW5ndGguDQo+ IA0KPiANCj4+IEZvciBvcHRpb24gZGF0YSwgdGhlIGFuc3dlciBpcyBjbGVhciBidXQgc2xpZ2h0 bHkgaGlkZGVuOiBzaW5jZSB0aGUgT3B0aW9uIERhdGENCj4+IGJ1dCAqbm90KiB0aGUgT3B0IERh dGEgTGVuIG1heSBiZSBvbWl0dGVkIGZyb20gSVBTZWMgQVVUSCwgT3B0IERhdGEgTGVuIGlzDQo+ PiBjbGVhcmx5IG5vdCBhbGxvd2VkIHRvIGNoYW5nZSBhbmQgdGhlcmVmb3JlIG9wdGlvbnMgY2Fu bm90IGJlIGluc2VydGVkIG9yDQo+PiBkZWxldGVkIGVpdGhlciAod2hpY2ggYnJlYWtzIFJGQyA0 NzgyKS4gQnV0IGl0IGlzbid0IHN0YXRlZCBhbnl3aGVyZSB0aGF0DQo+PiBJIGNhbiBzZWUgdGhh dCBpbnRlcm1laWF0ZSBzeXN0ZW1zIG11c3Qgbm90IGluc2VydCwgY2hhbmdlIG9yIGRlbGV0ZSBF SHMsDQo+PiBhbHRob3VnaCB0aGV5IGFyZSBhbGwgc3VwcG9zZWQgdG8gYmUgZTJlIGV4Y2VwdCBm b3IgSGJIIG9wdGlvbnMuDQo+IA0KPiBJIHRoaW5rIHRoYXQgY29uZmlybXMgdGhlIGludGVudC4g IEkgY291bGQgd29yayBvbiBzb21lIHRleHQgZm9yIHJmYzI0NjBiaXMuDQo+IA0KPiBCb2INCj4g DQo+PiANCj4+IE1heWJlIHRoYXQgbmVlZHMgdG8gYmUgYW4gZXJyYXR1bSBvbiAyNDYwPw0KPj4g DQo+PiBSZWdhcmRzDQo+PiAgQnJpYW4NCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0K From nobody Wed Apr 6 03:59:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A39212D727 for ; Wed, 6 Apr 2016 03:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 lsI1UMZ_NUw0 for ; Wed, 6 Apr 2016 03:59:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA25312D197 for ; Wed, 6 Apr 2016 03:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=942; q=dns/txt; s=iport; t=1459940361; x=1461149961; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bjZ0nnEzT2AB6ONRsg1Zv6evvPqTsPRBWUDlG0PxbB8=; b=gP9NooK0hpG5JA7uHmczchrw89/sB0+Ste7knkdY89+QYFTx5EIPh6O+ HCIrfamrZ78IGfX+ZHD5jG38JxiO0pGzNEiy/ukPArcp7GnEz6clZjdiF d3tgmRC9bHWFOlO9ScgwF5eeTAxLxpiGFjuTNA7MKQsRPLW/bSKWPnsyU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCg6gRX/4UNJK1cgzeBUAa6SwENg?= =?us-ascii?q?XKGDQIcgSU4FAEBAQEBAQFlJ4RBAQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEAQ0FCIgfrnqReAEBAQEBAQEBAQEBAQEBAQEBAQEBARV8iXCHP4JWBZgBA?= =?us-ascii?q?Y4DgViNPY8gAR4BAUKDZ2yHdX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="90593527" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 10:59:21 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u36AxK2A029122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 10:59:21 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 06:59:20 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 06:59:19 -0400 From: "Hemant Singh (shemant)" To: "Stefano Previdi (sprevidi)" , Bob Hinden Subject: RE: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRiVI+9XPFzG+wQEibDtD1Ck+sIp96ha6AgAKN7wD//8AkQA== Date: Wed, 6 Apr 2016 10:59:19 +0000 Message-ID: <8957467651ec4b83b89fd99e4a494bae@XCH-RTP-005.cisco.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> In-Reply-To: <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.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.82.178.158] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:59:23 -0000 DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkN Cj5TZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDE2IDY6NDcgQU0NCj5UbzogQm9iIEhpbmRl bg0KPkNjOiBJUHY2IExpc3QNCj5TdWJqZWN0OiBSZTogcmZjMjQ2MGJpcyBxdWVzdGlvbg0KDQo+ aW4gYSBjb250cm9sbGVkIGVudmlyb25tZW50IHdoZXJlIGJvdW5kYXJpZXMgYXJlIGNsZWFybHkg aWRlbnRpZmllZCBhbmQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgc2VjdXJpdHkgbWVjaGFuaXNtcywg SSBkb27igJl0IHNlZSB3aHkgYW4gZXh0ZW5zaW9uIGhlYWRlciBjYW7igJl0IGJlIGluc2VydGVk LCBhcyBsb25nIGFzIHdoYXRldmVyIHlvdSBpbnNlcnQgaXMgcmVtb3ZlZCA+d2hlbiBleGlzdGlu ZyB0aGUgY29udHJvbGxlZCBkb21haW4uDQoNCj5BcyBhIG1hdHRlciBvZiBmYWN0LCBpdCBkb2Vz IGhhcHBlbiBhbHJlYWR5IHRoYW5rcyB0byBtdWx0aXBsZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVu dGF0aW9ucyAoc2VnbWVudCByb3V0aW5nIGhlYWRlciwgUkg0KSBhbmQgSSBrbm93IG5ldHdvcmtz IHdoZXJlIHRoaXMgaXMgYmVpbmcgZGVwbG95ZWQuIA0KDQorMQ0KDQpUaGFua3MsDQoNCkhlbWFu dA0K From nobody Wed Apr 6 04:24:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074E812D098 for ; Wed, 6 Apr 2016 04:24:18 -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 lNx7Nd-o8Ea1 for ; Wed, 6 Apr 2016 04:24:15 -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 81FFC12D0D8 for <6man@ietf.org>; Wed, 6 Apr 2016 04:24:15 -0700 (PDT) Received: from [192.168.3.107] (unknown [181.165.122.68]) (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 0F00F80D90; Wed, 6 Apr 2016 13:24:07 +0200 (CEST) To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont Subject: Discussion of default-iids and MAC address randomization and RFC4941 X-Enigmail-Draft-Status: N1110 Message-ID: <5704F1C8.8010508@gont.com.ar> Date: Wed, 6 Apr 2016 08:23:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-default-iids@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:24:18 -0000 Folks, Hopefully I'll be able to use this during the 6man meeting, but in any case, I've posted some summary slides regarding the default-iids document and MAC address randomization. They are available here: https://www.gont.com.ar/talks/ietf95-draft-ietf-6man-default-iids-additional.pdf FWIW, IMO this whole discussion boils down to: * Stable addresses are currently required * This document replaces the existing scheme for producing stable addresses with one that mitigates the security/privacy implications of the traditional scheme. * The IETF can work on a separate document that e.g., proposes the use of RFC4941-only. Obviously, if such document was pursued/standardized, the recommendations here would not apply, since they simply apply to stable addresses. --- i.e., this document doesn't mandate stable addresses (stable addresses are mandated elsewhere!). We're just replacing the algorithm employed for stable addresses, when you actually generate them (which is "always" nowadays, as RFC4941 calls for that). * It's important that the implications around randomized MAC addresses when used with traditional SLAAC be clearly spelled out (see the posted slideware). Thanks, -- 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 Wed Apr 6 05:02:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17912D1BC for ; Wed, 6 Apr 2016 05:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 z6476ho0Fo0Z for ; Wed, 6 Apr 2016 05:02:38 -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 D89B212D0FF for <6man@ietf.org>; Wed, 6 Apr 2016 05:02:35 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so52880040ywa.0 for <6man@ietf.org>; Wed, 06 Apr 2016 05:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HeumUsh55Dwo1Si2v2/yqJCUqIEOLPis6YUteVQq3IU=; b=pu7Rxv5AwqR1YfvQsSsZ2yXTeTZhfJI7+Ku9WE9R+mDd3I8nbcZshjhqq2vzbEMcqM j5cHDFAdTEtIs/4U76u8PLtjzGHooOlKU2VqKTy4Ki7n39Bm6kJQlkvv1bKZ30ab1TLJ K1wHu/PMHCGzuzkN4RIIsvyHp7YsDGuM7n7ZfRoLh3YRNI0rZa2TseLjadUy/UZWS2TL 5kUlTKPOYqzXNFCWpLFN41O9P2vA5i7XnEU+vYZ/J1025THlW0btissGD4BKae5rMDHw NaoGsxiLgzk8+kLmVg0SRwaXJCNT0Qh52s8ne0VCv021WnkNT3YC5snC+IopoObDzgpW rHIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HeumUsh55Dwo1Si2v2/yqJCUqIEOLPis6YUteVQq3IU=; b=lzbOXJMXat0BKwPbcGZt0jddKs1fgxNnA3tDyEEdeXnbNZ79MYOhl/i67pzxQo7JLc C6Mqei60YAqJeOZAgxvzgx6Mi0InzC6PJjJj+q+7+THnq5A1OQ6cc3o2kAd8/rDxIO8I vaE6JOyQAR00nDcgYF/dAiMFhs3nFtsrYbABMMFeDbMP8Abi35z64zQSYVz+EXY1nsfK PS0AXWyhnx0Mbg1FPZ9bZTkpFATfivuP6EAgeKGb39KgWA/Qka4Sjyo+qG4em8EHJ1TY 8ehBHwKjCWS9jYvCaCLeftodVgMo/uzh/fz8oyr6EdPCpgdYmWYoXyFA77WMtTmBqANC yS/Q== X-Gm-Message-State: AD7BkJL0RbSNR4J/y1yesB3cHR2TxwWdPQi8WP5mVGmwMaEkrxnYFqnaOfixSbInmpeXYzzScVPPuYgZQkA4JYFI X-Received: by 10.37.80.75 with SMTP id e72mr3745171ybb.152.1459944154108; Wed, 06 Apr 2016 05:02:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.209.12 with HTTP; Wed, 6 Apr 2016 05:02:14 -0700 (PDT) In-Reply-To: <5704F1C8.8010508@gont.com.ar> References: <5704F1C8.8010508@gont.com.ar> From: Lorenzo Colitti Date: Wed, 6 Apr 2016 21:02:14 +0900 Message-ID: Subject: Re: Discussion of default-iids and MAC address randomization and RFC4941 To: Fernando Gont Content-Type: multipart/alternative; boundary=001a113ea402b32dec052fcfbca6 Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-default-iids@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:02:43 -0000 --001a113ea402b32dec052fcfbca6 Content-Type: text/plain; charset=UTF-8 Fernando, going on the record now because I won't be in BA. On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont wrote: > * Stable addresses are currently required > As should be clear by now, I disagree. Further, I think that unless that statement is heavily qualified and applied only to specific use cases, there will need to be a substantial privacy debate explaining how, even though "pervasive monitoring is an attack", we are mandating that the IPv6 addresses on a given network be stable for the life of the device. I think other parts of the IETF will need to be involved in that debate as well. > * It's important that the implications around randomized MAC addresses > when used with traditional SLAAC be clearly spelled out (see the posted > slideware). > There's a lot of FUD in that: - We do not control whether MAC addr randomization algorithm is appropriate or if it is actually possible. Not true - or rather, it's mostly not true. The exact level of incorrectness depends on who "we" is. If "we" = "Apple", then that statement is completely false. If "we" = "Windows" or "we" = "Android" then it is only mostly false. If "we" = "Linux" it is almost certainly false unless the host is using binary-only drivers. - Wastes 18 bits of entropy: "wastes" how? What's the downside? - Interoperability problems: depends heavily on the link layer. It's not true that you can't recover from DAD failures using SLAAC, you can just pick another number and try again. Of course, there's nothing new in my position, just like there's nothing new in yours. I'd just like to make sure that nobody can later state that the people who objected to the document are no longer objecting :-) Cheers, Lorenzo --001a113ea402b32dec052fcfbca6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fern= ando,

= going on the record now because I won't be in BA.

On Wed, Apr 6, 2016 at 8:23= PM, Fernando Gont <fernando@gont.com.ar> wrote:
* Stable addresses are currently required
=
As should be clear by now, I disagree.

<= div>Further, I think that unless that statement is heavily qualified and ap= plied only to specific use cases, there will need to be a substantial priva= cy debate explaining how, even though "pervasive monitoring is an atta= ck", we are mandating that the IPv6 addresses on a given network be st= able for the life of the device. I think other parts of the IETF will need = to be involved in that debate as well.
=C2=A0
*=C2=A0 It's important that the implications around randomized MAC a= ddresses
when used with traditional SLAAC be clearly spelled out (see the posted
slideware).

There's a lot of FUD in= that:
  • We do not control whether MAC addr randomization a= lgorithm is appropriate or if it is actually possible. Not true - or rather= , it's mostly not true. The exact level of incorrectness depends on who= "we" is. If "we" =3D "Apple", then that stat= ement is completely false. If "we" =3D "Windows" or &qu= ot;we" =3D "Android" then it is only mostly false. If "= we" =3D "Linux" it is almost certainly false unless the host= is using binary-only drivers.
  • Wastes 18 bits of entropy: "was= tes" how? What's the downside?
  • Interoperability problems: = depends heavily on the link layer. It's not true that you can't rec= over from DAD failures using SLAAC, you can just pick another number and tr= y again.
Of course, there's nothing new in my position, j= ust like there's nothing new in yours. I'd just like to make sure t= hat nobody can later state that the people who objected to the document are= no longer objecting :-)

Cheers,
L= orenzo
--001a113ea402b32dec052fcfbca6-- From nobody Wed Apr 6 05:13:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E106512D82D for ; Wed, 6 Apr 2016 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 mEnU6nZHneKe for ; Wed, 6 Apr 2016 05:13:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6206412D9C1 for <6man@ietf.org>; Wed, 6 Apr 2016 05:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FBPYATsCpii+9rWGJ80qGhyI0ATsOrezwlAOwE8nxEo=; b=DREVjsekH3+xZhPd6reF3X77rNoUO/+dew/9DSl4efnSIyHbWxm0omUMoB+q1sh6XpL7hom4Bwv9S1nTbg6xeBfLfjJxNZ3ApO9G/6hT7vSpYyN/5x3Ij7jyEL+tIWmFwFEm9lJxDPJoi8jNlFvBvLYKsoy9UE3T+qeDzY7F1Lk= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0719.namprd03.prod.outlook.com (10.160.97.14) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 12:13:17 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 12:13:17 +0000 From: Dave Thaler To: Lorenzo Colitti , Fernando Gont Subject: RE: Discussion of default-iids and MAC address randomization and RFC4941 Thread-Topic: Discussion of default-iids and MAC address randomization and RFC4941 Thread-Index: AQHRj/blqO/Uuq7DhUuQMGxZtB9y9Z982GIAgAAC6tA= Date: Wed, 6 Apr 2016 12:13:17 +0000 Message-ID: References: <5704F1C8.8010508@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:136:bd00:7202:774b:5013] x-ms-office365-filtering-correlation-id: 821c26f4-a77e-4628-4668-08d35e14d65a x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0719; 5:xCvwwqzb60Y6olrO0XSMgfAhGYUu4g4U3Gg3ewGdDfZ2a2QXZEGo9LRoCgTtgHRYsenWKUunhiaFcl5HOuBbOYUW3dnmNRQNLW7KmT5vMBWG8J8MKfGjJ0h95X2kd+vsHEhMGQ5g0mKPJAzEkmU9Zg==; 24:z1zmeBRhdxp8SULXvUEel/qoJ3Jy4W5UjRhVLirI28XMuXMPLFYJkYUKQWlgD8eqAmBUyKYehp8RE/xEw56PuS0Kxph97OCCfG0I4dvNXd0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0719; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0719; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0719; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(51444003)(106116001)(3280700002)(19580405001)(6116002)(19625215002)(74316001)(790700001)(86362001)(3660700001)(33656002)(5004730100002)(1096002)(2906002)(16236675004)(5002640100001)(99286002)(19580395003)(1220700001)(102836003)(586003)(4326007)(5008740100001)(76576001)(5003600100002)(19300405004)(10090500001)(5005710100001)(8990500004)(77096005)(86612001)(81166005)(10400500002)(15975445007)(92566002)(11100500001)(189998001)(5001770100001)(2900100001)(87936001)(76176999)(122556002)(54356999)(2950100001)(50986999)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0719; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB07178A5D1F081AAEDBB57727A39F0DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 12:13:17.6406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0719 Archived-At: Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-default-iids@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:13:22 -0000 --_000_DM2PR0301MB07178A5D1F081AAEDBB57727A39F0DM2PR0301MB0717_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIExvcmVuem/igJlzIHBvaW50cyBhbmQgSSBjYW4gdHJ5IHRvIHJlcHJlc2Vu dCB0aGVtIGluIHRoaXMgZGlzY3Vzc2lvbi4NCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDk6 MDIgQU0NClRvOiBGZXJuYW5kbyBHb250IDxmZXJuYW5kb0Bnb250LmNvbS5hcj4NCkNjOiA2bWFu QGlldGYub3JnOyA2bWFuLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi02bWFuLWRl ZmF1bHQtaWlkc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IERpc2N1c3Npb24gb2YgZGVm YXVsdC1paWRzIGFuZCBNQUMgYWRkcmVzcyByYW5kb21pemF0aW9uIGFuZCBSRkM0OTQxDQoNCkZl cm5hbmRvLA0KDQpnb2luZyBvbiB0aGUgcmVjb3JkIG5vdyBiZWNhdXNlIEkgd29uJ3QgYmUgaW4g QkEuDQoNCk9uIFdlZCwgQXByIDYsIDIwMTYgYXQgODoyMyBQTSwgRmVybmFuZG8gR29udCA8ZmVy bmFuZG9AZ29udC5jb20uYXI8bWFpbHRvOmZlcm5hbmRvQGdvbnQuY29tLmFyPj4gd3JvdGU6DQoq IFN0YWJsZSBhZGRyZXNzZXMgYXJlIGN1cnJlbnRseSByZXF1aXJlZA0KDQpBcyBzaG91bGQgYmUg Y2xlYXIgYnkgbm93LCBJIGRpc2FncmVlLg0KDQpGdXJ0aGVyLCBJIHRoaW5rIHRoYXQgdW5sZXNz IHRoYXQgc3RhdGVtZW50IGlzIGhlYXZpbHkgcXVhbGlmaWVkIGFuZCBhcHBsaWVkIG9ubHkgdG8g c3BlY2lmaWMgdXNlIGNhc2VzLCB0aGVyZSB3aWxsIG5lZWQgdG8gYmUgYSBzdWJzdGFudGlhbCBw cml2YWN5IGRlYmF0ZSBleHBsYWluaW5nIGhvdywgZXZlbiB0aG91Z2ggInBlcnZhc2l2ZSBtb25p dG9yaW5nIGlzIGFuIGF0dGFjayIsIHdlIGFyZSBtYW5kYXRpbmcgdGhhdCB0aGUgSVB2NiBhZGRy ZXNzZXMgb24gYSBnaXZlbiBuZXR3b3JrIGJlIHN0YWJsZSBmb3IgdGhlIGxpZmUgb2YgdGhlIGRl dmljZS4gSSB0aGluayBvdGhlciBwYXJ0cyBvZiB0aGUgSUVURiB3aWxsIG5lZWQgdG8gYmUgaW52 b2x2ZWQgaW4gdGhhdCBkZWJhdGUgYXMgd2VsbC4NCg0KKiAgSXQncyBpbXBvcnRhbnQgdGhhdCB0 aGUgaW1wbGljYXRpb25zIGFyb3VuZCByYW5kb21pemVkIE1BQyBhZGRyZXNzZXMNCndoZW4gdXNl ZCB3aXRoIHRyYWRpdGlvbmFsIFNMQUFDIGJlIGNsZWFybHkgc3BlbGxlZCBvdXQgKHNlZSB0aGUg cG9zdGVkDQpzbGlkZXdhcmUpLg0KDQpUaGVyZSdzIGEgbG90IG9mIEZVRCBpbiB0aGF0Og0KDQog ICogICBXZSBkbyBub3QgY29udHJvbCB3aGV0aGVyIE1BQyBhZGRyIHJhbmRvbWl6YXRpb24gYWxn b3JpdGhtIGlzIGFwcHJvcHJpYXRlIG9yIGlmIGl0IGlzIGFjdHVhbGx5IHBvc3NpYmxlLiBOb3Qg dHJ1ZSAtIG9yIHJhdGhlciwgaXQncyBtb3N0bHkgbm90IHRydWUuIFRoZSBleGFjdCBsZXZlbCBv ZiBpbmNvcnJlY3RuZXNzIGRlcGVuZHMgb24gd2hvICJ3ZSIgaXMuIElmICJ3ZSIgPSAiQXBwbGUi LCB0aGVuIHRoYXQgc3RhdGVtZW50IGlzIGNvbXBsZXRlbHkgZmFsc2UuIElmICJ3ZSIgPSAiV2lu ZG93cyIgb3IgIndlIiA9ICJBbmRyb2lkIiB0aGVuIGl0IGlzIG9ubHkgbW9zdGx5IGZhbHNlLiBJ ZiAid2UiID0gIkxpbnV4IiBpdCBpcyBhbG1vc3QgY2VydGFpbmx5IGZhbHNlIHVubGVzcyB0aGUg aG9zdCBpcyB1c2luZyBiaW5hcnktb25seSBkcml2ZXJzLg0KICAqICAgV2FzdGVzIDE4IGJpdHMg b2YgZW50cm9weTogIndhc3RlcyIgaG93PyBXaGF0J3MgdGhlIGRvd25zaWRlPw0KICAqICAgSW50 ZXJvcGVyYWJpbGl0eSBwcm9ibGVtczogZGVwZW5kcyBoZWF2aWx5IG9uIHRoZSBsaW5rIGxheWVy LiBJdCdzIG5vdCB0cnVlIHRoYXQgeW91IGNhbid0IHJlY292ZXIgZnJvbSBEQUQgZmFpbHVyZXMg dXNpbmcgU0xBQUMsIHlvdSBjYW4ganVzdCBwaWNrIGFub3RoZXIgbnVtYmVyIGFuZCB0cnkgYWdh aW4uDQpPZiBjb3Vyc2UsIHRoZXJlJ3Mgbm90aGluZyBuZXcgaW4gbXkgcG9zaXRpb24sIGp1c3Qg bGlrZSB0aGVyZSdzIG5vdGhpbmcgbmV3IGluIHlvdXJzLiBJJ2QganVzdCBsaWtlIHRvIG1ha2Ug c3VyZSB0aGF0IG5vYm9keSBjYW4gbGF0ZXIgc3RhdGUgdGhhdCB0aGUgcGVvcGxlIHdobyBvYmpl Y3RlZCB0byB0aGUgZG9jdW1lbnQgYXJlIG5vIGxvbmdlciBvYmplY3RpbmcgOi0pDQoNCkNoZWVy cywNCkxvcmVuem8NCg== --_000_DM2PR0301MB07178A5D1F081AAEDBB57727A39F0DM2PR0301MB0717_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjU5MjExMzkzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODcxMjE4NDU2O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBM b3Jlbnpv4oCZcyBwb2ludHMgYW5kIEkgY2FuIHRyeSB0byByZXByZXNlbnQgdGhlbSBpbiB0aGlz IGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9y ZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgQXByaWwgNiwgMjAxNiA5OjAyIEFNPGJyPg0KPGI+VG86PC9iPiBGZXJu YW5kbyBHb250ICZsdDtmZXJuYW5kb0Bnb250LmNvbS5hciZndDs8YnI+DQo8Yj5DYzo8L2I+IDZt YW5AaWV0Zi5vcmc7IDZtYW4tY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLTZtYW4t ZGVmYXVsdC1paWRzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBEaXNj dXNzaW9uIG9mIGRlZmF1bHQtaWlkcyBhbmQgTUFDIGFkZHJlc3MgcmFuZG9taXphdGlvbiBhbmQg UkZDNDk0MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZlcm5hbmRvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5nb2luZyBvbiB0aGUgcmVjb3JkIG5vdyBiZWNhdXNl IEkgd29uJ3QgYmUgaW4gQkEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDYsIDIwMTYgYXQgODoyMyBQTSwgRmVybmFuZG8g R29udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZlcm5hbmRvQGdvbnQuY29tLmFyIiB0YXJnZXQ9Il9i bGFuayI+ZmVybmFuZG9AZ29udC5jb20uYXI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFN0YWJsZSBhZGRyZXNzZXMgYXJl IGN1cnJlbnRseSByZXF1aXJlZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgc2hvdWxkIGJlIGNsZWFyIGJ5IG5vdywgSSBkaXNh Z3JlZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RnVydGhlciwgSSB0aGluayB0aGF0IHVubGVzcyB0aGF0IHN0YXRlbWVudCBpcyBoZWF2aWx5 IHF1YWxpZmllZCBhbmQgYXBwbGllZCBvbmx5IHRvIHNwZWNpZmljIHVzZSBjYXNlcywgdGhlcmUg d2lsbCBuZWVkIHRvIGJlIGEgc3Vic3RhbnRpYWwgcHJpdmFjeSBkZWJhdGUgZXhwbGFpbmluZyBo b3csIGV2ZW4gdGhvdWdoICZxdW90O3BlcnZhc2l2ZSBtb25pdG9yaW5nIGlzIGFuIGF0dGFjayZx dW90Oywgd2UgYXJlIG1hbmRhdGluZw0KIHRoYXQgdGhlIElQdjYgYWRkcmVzc2VzIG9uIGEgZ2l2 ZW4gbmV0d29yayBiZSBzdGFibGUgZm9yIHRoZSBsaWZlIG9mIHRoZSBkZXZpY2UuIEkgdGhpbmsg b3RoZXIgcGFydHMgb2YgdGhlIElFVEYgd2lsbCBuZWVkIHRvIGJlIGludm9sdmVkIGluIHRoYXQg ZGViYXRlIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiombmJzcDsgSXQncyBpbXBvcnRhbnQgdGhhdCB0aGUgaW1wbGlj YXRpb25zIGFyb3VuZCByYW5kb21pemVkIE1BQyBhZGRyZXNzZXM8YnI+DQp3aGVuIHVzZWQgd2l0 aCB0cmFkaXRpb25hbCBTTEFBQyBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0IChzZWUgdGhlIHBvc3Rl ZDxicj4NCnNsaWRld2FyZSkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSdzIGEgbG90IG9mIEZVRCBpbiB0aGF0OjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpXZSBkbyBub3QgY29udHJvbCB3 aGV0aGVyIE1BQyBhZGRyIHJhbmRvbWl6YXRpb24gYWxnb3JpdGhtIGlzIGFwcHJvcHJpYXRlIG9y IGlmIGl0IGlzIGFjdHVhbGx5IHBvc3NpYmxlLiBOb3QgdHJ1ZSAtIG9yIHJhdGhlciwgaXQncyBt b3N0bHkgbm90IHRydWUuIFRoZSBleGFjdCBsZXZlbCBvZiBpbmNvcnJlY3RuZXNzIGRlcGVuZHMg b24gd2hvICZxdW90O3dlJnF1b3Q7IGlzLiBJZiAmcXVvdDt3ZSZxdW90OyA9ICZxdW90O0FwcGxl JnF1b3Q7LCB0aGVuIHRoYXQgc3RhdGVtZW50IGlzIGNvbXBsZXRlbHkNCiBmYWxzZS4gSWYgJnF1 b3Q7d2UmcXVvdDsgPSAmcXVvdDtXaW5kb3dzJnF1b3Q7IG9yICZxdW90O3dlJnF1b3Q7ID0gJnF1 b3Q7QW5kcm9pZCZxdW90OyB0aGVuIGl0IGlzIG9ubHkgbW9zdGx5IGZhbHNlLiBJZiAmcXVvdDt3 ZSZxdW90OyA9ICZxdW90O0xpbnV4JnF1b3Q7IGl0IGlzIGFsbW9zdCBjZXJ0YWlubHkgZmFsc2Ug dW5sZXNzIHRoZSBob3N0IGlzIHVzaW5nIGJpbmFyeS1vbmx5IGRyaXZlcnMuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KV2Fz dGVzIDE4IGJpdHMgb2YgZW50cm9weTogJnF1b3Q7d2FzdGVzJnF1b3Q7IGhvdz8gV2hhdCdzIHRo ZSBkb3duc2lkZT88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQpJbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zOiBkZXBlbmRzIGhl YXZpbHkgb24gdGhlIGxpbmsgbGF5ZXIuIEl0J3Mgbm90IHRydWUgdGhhdCB5b3UgY2FuJ3QgcmVj b3ZlciBmcm9tIERBRCBmYWlsdXJlcyB1c2luZyBTTEFBQywgeW91IGNhbiBqdXN0IHBpY2sgYW5v dGhlciBudW1iZXIgYW5kIHRyeSBhZ2Fpbi48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UsIHRoZXJlJ3Mgbm90aGluZyBuZXcgaW4gbXkg cG9zaXRpb24sIGp1c3QgbGlrZSB0aGVyZSdzIG5vdGhpbmcgbmV3IGluIHlvdXJzLiBJJ2QganVz dCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IG5vYm9keSBjYW4gbGF0ZXIgc3RhdGUgdGhhdCB0aGUg cGVvcGxlIHdobyBvYmplY3RlZCB0byB0aGUgZG9jdW1lbnQgYXJlIG5vIGxvbmdlciBvYmplY3Rp bmcgOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TG9yZW56bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM2PR0301MB07178A5D1F081AAEDBB57727A39F0DM2PR0301MB0717_-- From nobody Wed Apr 6 05:14:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C656112D9BA for ; Wed, 6 Apr 2016 05:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 PulpuXJTNq5e for ; Wed, 6 Apr 2016 05:14:04 -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 E941812D5A8 for ; Wed, 6 Apr 2016 05:14:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A4192002A; Wed, 6 Apr 2016 08:17:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 956A46375A; Wed, 6 Apr 2016 08:14:02 -0400 (EDT) From: Michael Richardson To: Bob Hinden Subject: Re: rfc2460bis question In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <5702C912.6040506@gmail.com> <1435.1459896726@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:14:05 -0000 --=-=-= Content-Type: text/plain Bob Hinden wrote: >> Bob Hinden wrote: >>> Here is my proposed text: >> >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >> >>> Extension headers must never be deleted or changed in size by any >>> node on the path the packet takes. >> >>> The contents of an Extension header or Option in an Extension header >>> may be modified if this is permitted by the definition of the >>> Extension header or option. >> >>> The first paragraph is unchanged. I will probably combine all of this >>> into one paragraph, but kept separate for now for easier review. >> >>> Comments? >> >> I'd rather you left them as seperate sections, and I wouldn't mind if they >> were easily referred to, as it would make it easier to explain if I could say >> rfc2460bis#section4_1_1 or something like that. > I am OK keeping it as separate paragraphs, but making each (the last > two are only one sentence) a separate section, would be be sort of odd. > You could refer to them as, for example, the third paragraph of Section > 4. Yes, I'll be doing that :-) (hoping our revised rfc-format will let us turn that into a URL.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwT9h4CLcPvd0N1lAQK/Mgf+NuZzo2Np8ZeGePc7eShEtO0ggqOilM70 Qe4AwS/EPRkD1nlSZw3BXwnv085umkQ1D2pgt3KiiAo+dCk1vb8rPtkqgnqfOUOs VtMTtDpbIKXoxpDTGeeP98BsXNcrpkXFcuYcYHpe269HCnn769YOJb9pNoX0eflB 2786WwNr8LMB+HeuceXnV8HUeGBgqqSg0tkdWCYtzm9XoRg76SWN7OGb26riBbpL 1qvIWaxnGm285gKzw1DC0TRbrObzHKKYMmF5Isjyf5LKVmSNVpXRfo7f+dptcrCr AmzwENIVBdu/tSVQAowgOfpJVZwDgVgeZIFIhJ59WCqWPxeKUHbnDQ== =dMdf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 05:28:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785A712D09D for ; Wed, 6 Apr 2016 05:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 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, RCVD_IN_SORBS_WEB=0.77, 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 PBvAfitAJDCj for ; Wed, 6 Apr 2016 05:28:30 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 6449412D1A8 for ; Wed, 6 Apr 2016 05:28:30 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id f52so34159289qga.3 for ; Wed, 06 Apr 2016 05:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=2ZIa9H1KcjKjx1VQVJe6saee63H8O3oxn9xrnfkJLSg=; b=rK7nof01AWzbEirvK9dMPTdOJ2GanQ/PxWnfKoOCI13CDPavPAYpwFcDnkxcTSzZf8 SyDKp7sBsoObdp+qzrw/r/q7Bnd+n47bNXoALv08/Iz/LgIWnVul/EriMVSk1eJH8q/p BlMmfqiO8AV38vRjfnmKSYfFJkJByRfqyE+ob5wvqO9rkHIy77QNezJTjUxIY66KiX9o 0sawatHFLJ3JkqdwoqmvoJMy/4jnTqfsa5qnomDw3WnvDKLcRrXJ0tJj6wpD19NuzNxt hOwGjk9EPZa3Auw1DTqNEyB3/3wr6ExluddjRpCpHm3TRORsyArCaG7XQqqEx/Mg1uuj +8fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=2ZIa9H1KcjKjx1VQVJe6saee63H8O3oxn9xrnfkJLSg=; b=g0vlNrInttjQCfpo4ZQGJF6uzRImptcU6tsA6uGwbKK24v0uqMNFO/iwT8uYbmCbm7 YE8uxGv2yGEcOWZtD9WtMXfcsk5eM8of/OC1bY/US0ahOKdzqYk7C6PHZw/zGbhuu5gZ lDPFD2ybLtDiMAGOGu7sF2mUryKss3f/zWslD6GHgSiH7wGMnUu4PwEvJ2jcXK0VPyJR /GHsVBfhor3CjvbIZKYqaZbgRnu87q8iuxshE8nzr6A8jQXuPafry+YdYG378nrW9ZBL gW9XS6K5am9utbbqyhHagLyJ8tTCGqxoVj1wohlAsbvNlur+dtH2mQy5iMM85Kjl1c5x ssCw== X-Gm-Message-State: AD7BkJKdzdAPh7ljO4Sl13WltT1DHAxZsOVi5+JADwJFUZeBKlVKRX1RbG/zsSWqe5Xb4w== X-Received: by 10.140.142.144 with SMTP id 138mr1314879qho.84.1459945709555; Wed, 06 Apr 2016 05:28:29 -0700 (PDT) Received: from [10.10.104.31] (200-127-148-163.net.prima.net.ar. [200.127.148.163]) by smtp.gmail.com with ESMTPSA id 7sm1158531qhx.24.2016.04.06.05.28.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 05:28:28 -0700 (PDT) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_31DB8758-8B3C-43C9-BEB9-0FF3F35C73FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Still need Jabber scribe and minute taker for today's 6MAN session Date: Wed, 6 Apr 2016 09:28:24 -0300 Message-Id: <10D5ABB7-9017-45F3-AF86-B201251859FB@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:28:32 -0000 --Apple-Mail=_31DB8758-8B3C-43C9-BEB9-0FF3F35C73FC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, We still need Jabber scribe and minute taker for today's 6MAN session Please volunteer. Thanks Bob & Ole --Apple-Mail=_31DB8758-8B3C-43C9-BEB9-0FF3F35C73FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXBQDpAAoJEK7rdBF357uoGbMH/0n/3grn8jooNrqxfDe+39RS lM/1blryR9/VOP6zumjtTCTn1GpiTeSMrRWjulmP8Itp9fzpd2AzsuT1DOJcpiD7 kwVUZkefVk+Vu0/z0p6C4lcCkkkKBbgw0ttIeijuOYhwk6LMdvkIPo10Ta25cffZ jSSroMLEDzvpVP5AewzFXNj2i7gJGmWDCqE6202LuzmyNGfPR3I1W4RLdJbMjrpL x7CW95L7zNpgG8klE0URBnVcwY2kH6YrRLCjb06zVuerf7AP7TG5feZLub/ycYEN QsEBNENaXailTXe+nrlQzBSCvYdG8SBrsJ/P29Ck77/+xL+oUGU21I0lchbZWZg= =glGq -----END PGP SIGNATURE----- --Apple-Mail=_31DB8758-8B3C-43C9-BEB9-0FF3F35C73FC-- From nobody Wed Apr 6 05:29:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE2712D8EB for ; Wed, 6 Apr 2016 05:29:44 -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 AZFwphXLt5xF for ; Wed, 6 Apr 2016 05:29:37 -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 E416112D0A2 for <6man@ietf.org>; Wed, 6 Apr 2016 05:29:36 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 2so53821025ioy.1 for <6man@ietf.org>; Wed, 06 Apr 2016 05:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=lILftKEQnFWWidIc8SQl0ZWsYSvCs0915TejrdYvaTU=; b=Ksu1FliJyXlfIb8tu7LfnratXRzSk4ulkUUmqeQIinc2xAmX05U+cPZNlNxhbwROaR MltXf4T5nQganbwKFWD+ug6gpuSgdbGGJnAFWLdzwZyBCjLRmMWOPO8YsnaiAPNVuVEy 1ydCWUurtUVbnc/5+FI0KFRboJiG4QWkAkVZlG14Eoik02zFaOyqfk0nhl1SawGHVw8r UuTg6PnZjEMjNdfnQbXVsbt4cU9AkpR1MSlt5DangjwsCiYavwhQWRGNHOgbt2OoM9vh TSvcUUBd8pzYPNEOgUae8FBKsgqc+qpc1AM+A1QPU/+3rTDq8uKvhIn+iUqhEVzhbeqw mhqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lILftKEQnFWWidIc8SQl0ZWsYSvCs0915TejrdYvaTU=; b=mFcoWhQGyfC0B5xMSEn9a9qoaNiyd3FawaJjVrURy3TCIVQ4q8kjWNbyl+GkxMkTem bE9DCd0LXXSI59AWKzL+Rno1/Xfd5F7qkBIGaU1o0XGcZkUUTAB67x4pvv3zC8ubFEcM Axr5tUEjzVi1PBE7+qImTzIjwW8lOn9CExTOdPBA/xx2jJB7Nf0kf8ns06kC9AOXjssF UT02QkVSX2CvqH4/sfESDtwEm9Bbu+JhYcfxjg2tFds6hhWyALycU/XWn5as9ScRMPYA FrwVcFKuUhrKXDCI9Mz/GX09RuHet/h/6ZXXW9VWc7AI7aDoul1bgbKED3MFddl5lWx1 +3TA== X-Gm-Message-State: AD7BkJLRw9qfViSssF6dueZ6rtY3idVwGaO1cXibKHDSKDmOBmzcdrqpXnB+vBFXrTVSYUcKyaOGYsQtCNiGZA== MIME-Version: 1.0 X-Received: by 10.107.43.206 with SMTP id r197mr20469597ior.140.1459945776151; Wed, 06 Apr 2016 05:29:36 -0700 (PDT) Sender: fgont.mobile@gmail.com Received: by 10.36.110.13 with HTTP; Wed, 6 Apr 2016 05:29:36 -0700 (PDT) Received: by 10.36.110.13 with HTTP; Wed, 6 Apr 2016 05:29:36 -0700 (PDT) In-Reply-To: References: <5704F1C8.8010508@gont.com.ar> Date: Wed, 6 Apr 2016 14:29:36 +0200 X-Google-Sender-Auth: boQTh45Cq9fvcDYnEkXu0O_Ghoo Message-ID: Subject: Re: Discussion of default-iids and MAC address randomization and RFC4941 From: Fernando Gont To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a1139b9186105fe052fd01d21 Archived-At: Cc: Chairs 6man <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-default-iids@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:29:44 -0000 --001a1139b9186105fe052fd01d21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 6/4/2016 9:02, "Lorenzo Colitti" escribi=C3=B3: > > Fernando, > > going on the record now because I won't be in BA. > > On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont wrote: >> >> * Stable addresses are currently required > > > As should be clear by now, I disagree. > > Further, I think that unless that statement is heavily qualified and applied only to specific use cases, there will need to be a substantial privacy debate explaining how, even though "pervasive monitoring is an attack", we are mandating that the IPv6 addresses on a given network be stable for the life of the device. I think other parts of the IETF will need to be involved in that debate as well. Please check the slides I've attached. Stable addresses are not a requirement of this document, but a requirement of existing specs. This docunent applies *when* generqting stable addresses which, nowadays, is always. If you don't want that, you keed to update rfc4941, or randomize mac addresses and use the randomized mac address as the net_iface parameter of RFC7217. i.e., I'm not even arguing against your desire of rfc4941. For instance, i understand that there are scenarios in which you may want to do that. But what's interferring with thqt is the existing specs (e.g., rfc4941), and not this document. This document applies only when uou generate stable addresses. Nowadays, tjat happens to be "always" because other documents mandate that. >> * It's important that the implications around randomized MAC addresses >> when used with traditional SLAAC be clearly spelled out (see the posted >> slideware). > > > There's a lot of FUD in that: > We do not control whether MAC addr randomization algorithm is appropriate or if it is actually possible. Not true - or rather, it's mostly not true. The exact level of incorrectness depends on who "we" is. If "we" =3D "Apple= ", then that statement is completely false. If "we" =3D "Windows" or "we" =3D "Android" then it is only mostly false. If "we" =3D "Linux" it is almost certainly false unless the host is using binary-only drivers. We =3D=3D ietf. This is not an android or mac devloping forum. > Wastes 18 bits of entropy: "wastes" how? What's the downside? Local/global bit, unicast/multicast bit, and 0xfffe. Talk to JC Zu=C3=B1iga= . > Interoperability problems: depends heavily on the link layer. It's not true that you can't recover from DAD failures using SLAAC, you can just pick another number and try again. Could you please point me a spec tjat explains how to recover from a DAD collision in a protocol where the premise is giving you a unique identifier= ? > Of course, there's nothing new in my position, just like there's nothing new in yours. I'd just like to make sure that nobody can later state that the people who objected to the document are no longer objecting :-) In the same way that if we were to add this to draft-gont-numeric-ids as an example of doing things wrong after 30 years of experience with that, nobody can say that nobody noted it. --001a1139b9186105fe052fd01d21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 6/4/2016 9:02, "Lorenzo Colitti" <lorenzo@google.com> escribi=C3=B3:
>
> Fernando,
>
> going on the record now because I won't be in BA.
>
> On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont <fernando@gont.com.ar> wrote:
>>
>> * Stable addresses are currently required
>
>
> As should be clear by now, I disagree.
>
> Further, I think that unless that statement is heavily qualified and a= pplied only to specific use cases, there will need to be a substantial priv= acy debate explaining how, even though "pervasive monitoring is an att= ack", we are mandating that the IPv6 addresses on a given network be s= table for the life of the device. I think other parts of the IETF will need= to be involved in that debate as well.

Please check the slides I've attached. Stable addresses = are not a requirement of this document, but a requirement of existing specs= .

This docunent applies *when* generqting stable addresses whi= ch, nowadays, is always. If you don't want that, you keed to update rfc= 4941, or randomize mac addresses and use the randomized mac address as the = net_iface parameter of RFC7217.

i.e., I'm not even arguing against your desire of rfc494= 1. For instance, i understand that there are scenarios in which you may wan= t to do that. But what's interferring with thqt is the existing specs (= e.g., rfc4941), and not this document.

This document applies only when uou generate stable addresse= s. Nowadays, tjat happens to be "always" because other documents = mandate that.

>> *=C2=A0 It's important that the implications ar= ound randomized MAC addresses
>> when used with traditional SLAAC be clearly spelled out (see the p= osted
>> slideware).
>
>
> There's a lot of FUD in that:
> We do not control whether MAC addr randomization algorithm is appropri= ate or if it is actually possible. Not true - or rather, it's mostly no= t true. The exact level of incorrectness depends on who "we" is. = If "we" =3D "Apple", then that statement is completely = false. If "we" =3D "Windows" or "we" =3D &quo= t;Android" then it is only mostly false. If "we" =3D "L= inux" it is almost certainly false unless the host is using binary-onl= y drivers.

We =3D=3D ietf. This is not an android or mac devloping foru= m.

> Wastes 18 bits of entropy: "wastes" how? What= 's the downside?

Local/global bit, unicast/multicast bit, and 0xfffe. Talk to= JC Zu=C3=B1iga.

> Interoperability problems: depends heavily on the link = layer. It's not true that you can't recover from DAD failures using= SLAAC, you can just pick another number and try again.

Could you please point me a spec tjat explains how to recove= r from a DAD collision in a protocol where the premise is giving you a uniq= ue identifier?

> Of course, there's nothing new in my position, just= like there's nothing new in yours. I'd just like to make sure that= nobody can later state that the people who objected to the document are no= longer objecting :-)

In the same way that if we were to add this to draft-gont-nu= meric-ids as an example of doing things wrong after 30 years of experience = with that, nobody can say that nobody noted it.

--001a1139b9186105fe052fd01d21-- From nobody Wed Apr 6 05:36:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3D812D09D for ; Wed, 6 Apr 2016 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 iYg6wMPwxelB for ; Wed, 6 Apr 2016 05:36:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A886D12D55D for <6man@ietf.org>; Wed, 6 Apr 2016 05:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XpJ+YIY9CG1A10Rx2QqUGUsWiKRmbh4h9PDFrtU6sPc=; b=hpqDOt3jiEdNsg1Mm50f9bhj3IPOv9cwhhsMiMsDEZRybI5wmEbNjgeZFzL0CaDaFmCG6+WE+qkldxjD/dlDUGLWLeKHJ4ABeUpYlI2QdHIZu3fweeUqH3W0ykmNm4zmbM1IxZhFSFAr28OmUtWAL+Y9CUvni+y+L7oF4lBotSY= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 12:36:19 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 12:36:19 +0000 From: Dave Thaler To: Fernando Gont , Lorenzo Colitti Subject: RE: Discussion of default-iids and MAC address randomization and RFC4941 Thread-Topic: Discussion of default-iids and MAC address randomization and RFC4941 Thread-Index: AQHRj/blqO/Uuq7DhUuQMGxZtB9y9Z982GIAgAAHpgCAAACFAA== Date: Wed, 6 Apr 2016 12:36:19 +0000 Message-ID: References: <5704F1C8.8010508@gont.com.ar> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: si6networks.com; dkim=none (message not signed) header.d=none;si6networks.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:136:bd00:7202:774b:5013] x-ms-office365-filtering-correlation-id: 4591cb24-52ec-4991-3862-08d35e180dbb x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 5:tG19SaySBCXnqAAniECnBQa3d0l/T/O8QVpeNNstse2D7j06jtmR9tQtEsKm8HyPiuLdwYXto9zP+IeyV7CczqpEOhvEqyD4iysU3f7RQ0gvsiowKb/mEeDkzMnXFdTVmYgxcnWEPB7T9Z7zalNAwQ==; 24:xKFZSu+Q+KHuEFz33QMhXl+6yA3vEF5lzRV2cflsHS/P9nj7v9cQiIJ666XBLfdUIbk2xc1ppIXYr/f+AOUixo3AXmgTNNzdgfbZJ0JPWB0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51444003)(377454003)(13464003)(1096002)(1220700001)(102836003)(54356999)(4326007)(8990500004)(87936001)(5005710100001)(586003)(2900100001)(6116002)(2950100001)(76176999)(5008740100001)(86612001)(189998001)(74316001)(33656002)(50986999)(5001770100001)(5004730100002)(5003600100002)(10290500002)(5002640100001)(10400500002)(106116001)(86362001)(99286002)(76576001)(10090500001)(81166005)(11100500001)(92566002)(5890100001)(2906002)(122556002)(77096005)(19580405001)(3280700002)(19580395003)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 12:36:19.0252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: Cc: Chairs 6man <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-default-iids@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:36:55 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBmZ29udC5tb2JpbGVAZ21haWwu Y29tIFttYWlsdG86ZmdvbnQubW9iaWxlQGdtYWlsLmNvbV0gT24gQmVoYWxmDQo+IE9mIEZlcm5h bmRvIEdvbnQNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDk6MzAgQU0NCj4gVG86 IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KPiBDYzogZHJhZnQtaWV0Zi02 bWFuLWRlZmF1bHQtaWlkc0B0b29scy5pZXRmLm9yZzsgQ2hhaXJzIDZtYW4gPDZtYW4tDQo+IGNo YWlyc0B0b29scy5pZXRmLm9yZz47IDZtYW5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IERpc2N1 c3Npb24gb2YgZGVmYXVsdC1paWRzIGFuZCBNQUMgYWRkcmVzcyByYW5kb21pemF0aW9uIGFuZA0K PiBSRkM0OTQxDQo+IA0KPiBFbCA2LzQvMjAxNiA5OjAyLCAiTG9yZW56byBDb2xpdHRpIiA8bG9y ZW56b0Bnb29nbGUuY29tPiBlc2NyaWJpw7M6DQo+ID4NCj4gPiBGZXJuYW5kbywNCj4gPg0KPiA+ IGdvaW5nIG9uIHRoZSByZWNvcmQgbm93IGJlY2F1c2UgSSB3b24ndCBiZSBpbiBCQS4NCj4gPg0K PiA+IE9uIFdlZCwgQXByIDYsIDIwMTYgYXQgODoyMyBQTSwgRmVybmFuZG8gR29udCA8ZmVybmFu ZG9AZ29udC5jb20uYXI+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+PiAqIFN0YWJsZSBhZGRyZXNzZXMg YXJlIGN1cnJlbnRseSByZXF1aXJlZA0KPiA+DQo+ID4NCj4gPiBBcyBzaG91bGQgYmUgY2xlYXIg Ynkgbm93LCBJIGRpc2FncmVlLg0KPiA+DQo+ID4gRnVydGhlciwgSSB0aGluayB0aGF0IHVubGVz cyB0aGF0IHN0YXRlbWVudCBpcyBoZWF2aWx5IHF1YWxpZmllZCBhbmQNCj4gYXBwbGllZCBvbmx5 IHRvIHNwZWNpZmljIHVzZSBjYXNlcywgdGhlcmUgd2lsbCBuZWVkIHRvIGJlIGEgc3Vic3RhbnRp YWwgcHJpdmFjeQ0KPiBkZWJhdGUgZXhwbGFpbmluZyBob3csIGV2ZW4gdGhvdWdoICJwZXJ2YXNp dmUgbW9uaXRvcmluZyBpcyBhbiBhdHRhY2siLCB3ZQ0KPiBhcmUgbWFuZGF0aW5nIHRoYXQgdGhl IElQdjYgYWRkcmVzc2VzIG9uIGEgZ2l2ZW4gbmV0d29yayBiZSBzdGFibGUgZm9yIHRoZQ0KPiBs aWZlIG9mIHRoZSBkZXZpY2UuIEkgdGhpbmsgb3RoZXIgcGFydHMgb2YgdGhlIElFVEYgd2lsbCBu ZWVkIHRvIGJlIGludm9sdmVkIGluDQo+IHRoYXQgZGViYXRlIGFzIHdlbGwuDQo+IA0KPiBQbGVh c2UgY2hlY2sgdGhlIHNsaWRlcyBJJ3ZlIGF0dGFjaGVkLiBTdGFibGUgYWRkcmVzc2VzIGFyZSBu b3QgYSByZXF1aXJlbWVudA0KPiBvZiB0aGlzIGRvY3VtZW50LCBidXQgYSByZXF1aXJlbWVudCBv ZiBleGlzdGluZyBzcGVjcy4NCj4gDQo+IFRoaXMgZG9jdW5lbnQgYXBwbGllcyAqd2hlbiogZ2Vu ZXJxdGluZyBzdGFibGUgYWRkcmVzc2VzIHdoaWNoLA0KPiBub3dhZGF5cywgaXMgYWx3YXlzLiBJ ZiB5b3UgZG9uJ3Qgd2FudCB0aGF0LCB5b3Uga2VlZCB0byB1cGRhdGUgcmZjNDk0MSwgb3INCj4g cmFuZG9taXplIG1hYyBhZGRyZXNzZXMgYW5kIHVzZSB0aGUgcmFuZG9taXplZCBtYWMgYWRkcmVz cyBhcyB0aGUNCj4gbmV0X2lmYWNlIHBhcmFtZXRlciBvZiBSRkM3MjE3Lg0KDQpEaXNhZ3JlZSB0 aGF0IHlvdSBuZWVkIHRvIHVzZSB0aGUgcmFuZG9tIG1hYyBhZGRyZXNzIGFzIHRoZSBuZXRfaWZh Y2UNCnBhcmFtZXRlciBvZiBSRkMgNzIxNy4gIFRoYXQgaXMgKm9uZSogd2F5IHRvIGRvIGl0LiAg SXQncyBub3QgdGhlIG9ubHkgd2F5IHRvIGRvIGl0Lg0KZHJhZnQtaWV0Zi02bG8tcHJpdmFjeS1j b25zaWRlcmF0aW9ucy0wMCBjb250YWlucyBhIGxvbmdlciBhbmFseXNpcyB0aGF0IEkNCmhhdmVu J3QgaGVhcmQgYW55IHByb2JsZW1zIHdpdGggc28gZmFyLg0KDQo+IA0KPiBpLmUuLCBJJ20gbm90 IGV2ZW4gYXJndWluZyBhZ2FpbnN0IHlvdXIgZGVzaXJlIG9mIHJmYzQ5NDEuIEZvciBpbnN0YW5j ZSwgaQ0KPiB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIHNjZW5hcmlvcyBpbiB3aGljaCB5b3Ug bWF5IHdhbnQgdG8gZG8gdGhhdC4gQnV0DQo+IHdoYXQncyBpbnRlcmZlcnJpbmcgd2l0aCB0aHF0 IGlzIHRoZSBleGlzdGluZyBzcGVjcyAoZS5nLiwgcmZjNDk0MSksIGFuZCBub3QgdGhpcw0KPiBk b2N1bWVudC4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgYXBwbGllcyBvbmx5IHdoZW4gdW91IGdlbmVy YXRlIHN0YWJsZSBhZGRyZXNzZXMuIE5vd2FkYXlzLA0KPiB0amF0IGhhcHBlbnMgdG8gYmUgImFs d2F5cyIgYmVjYXVzZSBvdGhlciBkb2N1bWVudHMgbWFuZGF0ZSB0aGF0Lg0KPiANCj4gPj4gKiAg SXQncyBpbXBvcnRhbnQgdGhhdCB0aGUgaW1wbGljYXRpb25zIGFyb3VuZCByYW5kb21pemVkIE1B Qw0KPiA+PiBhZGRyZXNzZXMgd2hlbiB1c2VkIHdpdGggdHJhZGl0aW9uYWwgU0xBQUMgYmUgY2xl YXJseSBzcGVsbGVkIG91dA0KPiA+PiAoc2VlIHRoZSBwb3N0ZWQgc2xpZGV3YXJlKS4NCj4gPg0K PiA+DQo+ID4gVGhlcmUncyBhIGxvdCBvZiBGVUQgaW4gdGhhdDoNCj4gPiBXZSBkbyBub3QgY29u dHJvbCB3aGV0aGVyIE1BQyBhZGRyIHJhbmRvbWl6YXRpb24gYWxnb3JpdGhtIGlzDQo+ID4gYXBw cm9wcmlhdGUNCj4gb3IgaWYgaXQgaXMgYWN0dWFsbHkgcG9zc2libGUuIE5vdCB0cnVlIC0gb3Ig cmF0aGVyLCBpdCdzIG1vc3RseSBub3QgdHJ1ZS4NCj4gVGhlIGV4YWN0IGxldmVsIG9mIGluY29y cmVjdG5lc3MgZGVwZW5kcyBvbiB3aG8gIndlIiBpcy4gSWYgIndlIiA9ICJBcHBsZSIsDQo+IHRo ZW4gdGhhdCBzdGF0ZW1lbnQgaXMgY29tcGxldGVseSBmYWxzZS4gSWYgIndlIiA9ICJXaW5kb3dz IiBvciAid2UiID0NCj4gIkFuZHJvaWQiIHRoZW4gaXQgaXMgb25seSBtb3N0bHkgZmFsc2UuIElm ICJ3ZSIgPSAiTGludXgiIGl0IGlzIGFsbW9zdCBjZXJ0YWlubHkNCj4gZmFsc2UgdW5sZXNzIHRo ZSBob3N0IGlzIHVzaW5nIGJpbmFyeS1vbmx5IGRyaXZlcnMuDQo+IA0KPiBXZSA9PSBpZXRmLiBU aGlzIGlzIG5vdCBhbiBhbmRyb2lkIG9yIG1hYyBkZXZsb3BpbmcgZm9ydW0uDQoNClRoZSBJRVRG IGRvZXNuJ3QgImNvbnRyb2wnIGFueXRoaW5nLiAgSXQgY3JlYXRlcyBzdGFuZGFyZHMgYW5kIGlt cGxlbWVudGF0aW9ucw0KY2hvb3NlIHRvIGltcGxlbWVudCB0aGVtIG9yIG5vdC4gICBJIHRoaW5r IHRoaXMgaXMgYSByZWQgaGVycmluZyBpbiB0aGlzIGRpc2N1c3Npb24NCnRob3VnaC4NCg0KPiAN Cj4gPiBXYXN0ZXMgMTggYml0cyBvZiBlbnRyb3B5OiAid2FzdGVzIiBob3c/IFdoYXQncyB0aGUg ZG93bnNpZGU/DQo+IA0KPiBMb2NhbC9nbG9iYWwgYml0LCB1bmljYXN0L211bHRpY2FzdCBiaXQs IGFuZCAweGZmZmUuIFRhbGsgdG8gSkMgWnXDsWlnYQ0KDQpOb25lIG9mIHRob3NlIGFuc3dlciB0 aGUgcXVlc3Rpb24uICBUaGUgMTggYml0cyBhcmVuJ3QgdXNlZCBmb3IgZW50cm9weS4NCkEgY2xh aW0gdGhhdCBpdCdzIGEgIndhc3RlIiBpcyBhIHN1YmplY3RpdmUgdmFsdWUganVkZ2VtZW50IHRo YXQNCmFkZGl0aW9uYWwgZW50cm9weSBpcyBtb3JlIHZhbHVhYmxlIHRoYW4gb3RoZXIgdGhpbmdz IHlvdSBtaWdodCBnZXQNCmZyb20gdGhvc2UgYml0cy4gICBUaGF0IHN0YXRlbWVudCBuZWVkcyB0 byBiZSBiYWNrZWQgdXAgd2l0aCBqdXN0aWZpY2F0aW9uLg0KZHJhZnQtaWV0Zi02bG8tcHJpdmFj eS1jb25zaWRlcmF0aW9ucy0wMCBzZWN0aW9uIDIgZm9yIGV4YW1wbGUgaGFzIGFuDQooSSB0aGlu aykgb2JqZWN0aXZlIGRpc2N1c3Npb24gb2YgYW1vdW50IG9mIGVudHJvcHkgbmVlZGVkLiAgIE9u Y2UNCnlvdSBnZXQgb3ZlciBhIGNlcnRhaW4gdGhyZXNob2xkIHJlbGF0aXZlIHRvIGxpbmsgbGlm ZXRpbWUsIGV4dHJhIGVudHJvcHkNCmJlY29tZXMgbXVjaCBsZXNzIHZhbHVhYmxlIGFuZCBvdGhl ciBjb25zaWRlcmF0aW9ucyBtYXkgYmUgZ3JlYXRlci4NCg0KRGF2ZQ0K From nobody Wed Apr 6 06:14:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ADC12D16B for ; Wed, 6 Apr 2016 06:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EjoCBUmkMt2Y for ; Wed, 6 Apr 2016 06:13:58 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 C1C0E12D555 for ; Wed, 6 Apr 2016 06:13:11 -0700 (PDT) Received: from [31.133.180.15] (dhcp-b40f.meeting.ietf.org [31.133.180.15]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u36DD2xF014351 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 06:13:03 -0700 Subject: Re: rfc2460bis question To: "Stefano Previdi (sprevidi)" , Bob Hinden References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> From: Erik Nordmark Message-ID: <57050B5C.1050503@acm.org> Date: Wed, 6 Apr 2016 10:13:00 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVa7PUCVQiz/NJjVp2wQ7Rv7+RW63l1cXfnm3tn/erzv954zvVRsZlQl3G+YCq/0HKeefVNjqpsDZEPXDVO/EiAS X-Sonic-ID: C;4HiESvn75RGFR5FDXdaMvg== M;cKI4S/n75RGFR5FDXdaMvg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:14:00 -0000 On 4/6/16 7:46 AM, Stefano Previdi (sprevidi) wrote: > > > > in a controlled environment where boundaries are clearly identified and with the appropriate security mechanisms, I don’t see why an extension header can’t be inserted, as long as whatever you insert is removed when existing the controlled domain. > > As a matter of fact, it does happen already thanks to multiple interoperable implementations (segment routing header, RH4) and I know networks where this is being deployed. Stefano, In addition to having a strict boundary around the controlled environment to prevent the IPv6 base header to leak with this extension, you also need to ensure that it doesn't leak inside an ICMP error. Do the current implementations ensure that? I assume one would also need to mandate that there are no tunnels that can cause the packets to leak out with the added extension header. Do you have a mechanism to ensure that? > > Again, this is a controlled environment. > > Stating that "Extension headers must never be inserted by any node…†looks a bit extreme to me and I’d prefer to “recommend†not to insert rather than just ignoring what happens in real networks and for real use cases. Similar arguments has been made many times in the IETF for protocols with an intended deployment in a controlled environment. (I recall the ones about not needing security for some protocol because of the intended deployment.) The experience has been that that successful protocol get deployed outside of their initially intended environment or constraints. In the case of segment routing it wouldn't be unreasonable to assume that in the future there could be some gradual deployments into controlled environments resulting in some routers doing segment routing (hence adding/removing the extension header) while other routers at the boundary of the environment remain unmodified. In such a case you do not have a strict boundary to prevent the leakage inside ICMP errors, and perhaps not even in the IPV6 base header depending on how routing is done. Regards, Erik > > Thanks. > s. > > >> I think covers the inserting issue. >> >> I don’t see any text that prohibits changing or deleting Extension Headers. I think it was the intent to not delete or change the length of Extension Headers, so we could add that as a clarification. Changing the content is more complex, as you note, we do allow changing the content of some extension headers. I think that needs to be part of the definition of each extension header. >> >> We could add text cover deleting and changing the length. >> >> >>> For option data, the answer is clear but slightly hidden: since the Option Data >>> but *not* the Opt Data Len may be omitted from IPSec AUTH, Opt Data Len is >>> clearly not allowed to change and therefore options cannot be inserted or >>> deleted either (which breaks RFC 4782). But it isn't stated anywhere that >>> I can see that intermeiate systems must not insert, change or delete EHs, >>> although they are all supposed to be e2e except for HbH options. >> I think that confirms the intent. I could work on some text for rfc2460bis. >> >> Bob >> >>> Maybe that needs to be an erratum on 2460? >>> >>> Regards >>> Brian >>> >>> -------------------------------------------------------------------- >>> 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 Wed Apr 6 07:21:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6403E12D652 for ; Wed, 6 Apr 2016 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 Nsf0CoLtD6et for ; Wed, 6 Apr 2016 07:21:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6174512D62F for <6man@ietf.org>; Wed, 6 Apr 2016 07:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+gVEm1B5QtvCtrlJM5UQ9/jgsJrIHGNa/tZwozpY9fo=; b=fy59Rlc4WWPjQP6qWOc4YHUegSwHwPuxwVAsAkG+2CCCl9IoU0fRRYFEDPM+hPSsKhxkh+9yoD5wipSDBNxLQjRwWThXXdKAzCqGzKnos1/D1fJaGeEXTe8ajPhDvC0IpCUhOAgSMTDuMW8WpysCULijoEgXxIP0MHInoMfwW20= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 14:20:47 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 14:20:47 +0000 From: Dave Thaler To: "6man@ietf.org" <6man@ietf.org> Subject: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfg== Date: Wed, 6 Apr 2016 14:20:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:136:bd00:7202:774b:5013] x-ms-office365-filtering-correlation-id: 471b799b-055c-45f4-8db4-08d35e26a5d8 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 5:mKbOQVDorIv5F1KTFM6NbFUQ30k8ZDsWrwBtVk6Hw8DllXLHkImxdl8f3U6Y9oGpxhV5rap0gSye8xGaumpIvgWp5KZkVOvc2RKdVNVHyW35XEnmLpjyrnXeMvJ58lW/2FklTHSLWo/VlpbfpTF6JA==; 24:JklhDKtpWHbRsDMA9oqZOsq9h6lYeOF2wxByW6aCc+ZywyneXRWK2cc5m40Lwh8TSdiEvCMNQEL1M95reC9/ZO47/XRlVXrwCJMW021BeYU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(81166005)(76576001)(99286002)(10090500001)(92566002)(5630700001)(19300405004)(5640700001)(11100500001)(106356001)(229853001)(86362001)(2351001)(2501003)(3280700002)(19580395003)(3660700001)(2906002)(122556002)(77096005)(86612001)(5008740100001)(5005710100001)(6116002)(586003)(2900100001)(790700001)(102836003)(1096002)(1220700001)(8990500004)(54356999)(87936001)(19625215002)(5003600100002)(15975445007)(16236675004)(10400500002)(10290500002)(5002640100001)(110136002)(107886002)(189998001)(74316001)(5004730100002)(450100001)(33656002)(50986999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB071790EAA30275A1CE643567A39F0DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 14:20:47.1229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:21:12 -0000 --_000_DM2PR0301MB071790EAA30275A1CE643567A39F0DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OLD: If any of the packets sent on that path are too large to be forwarded OLD: by some node along the path, that node will discard them and return OLD: ICMPv6 Packet Too Big messages [ICMPv6]. NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node along the path (regardless of whether it decrements the H= op Limit), that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. That is, just add the phrase "(regardless of whether it decrements the Hop = Limit)" to the existing sentence. Dave --_000_DM2PR0301MB071790EAA30275A1CE643567A39F0DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
OLD: If any of the pack=
ets sent on that path are too large to be forwarded

= OLD: by some node along the path, that node will discard them and return

= OLD: ICMPv6 Packet Too Big messages [ICMPv6]. 

=  

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node along the path (reg=
ardless of whether it decrements the Hop Limit), that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

That is, just add the phrase “(rega= rdless of whether it decrements the Hop Limit)” to the existing sente= nce.

 

Dave

--_000_DM2PR0301MB071790EAA30275A1CE643567A39F0DM2PR0301MB0717_-- From nobody Wed Apr 6 07:43:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D43512D66E for ; Wed, 6 Apr 2016 07:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UnFmduGLO6_k for ; Wed, 6 Apr 2016 07:43:02 -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 7D90812D678 for <6man@ietf.org>; Wed, 6 Apr 2016 07:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6707; q=dns/txt; s=iport; t=1459953755; x=1461163355; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3ys16Era3eerucQ1VNeK7tvUWP//c1BJ/J9r+HuAVmE=; b=bmH99b00as5Teoz8yPhPtNL3irqY95GX+7H7fpARmu0aJhQhsve3LHkJ 41ikpEtmmZjH6KxCGXBtUW7ggor8amsJHENv8Tk8KH/Cf9nbHg26qsYlU H0m/MkDViJ5Qu3p675twwPV6YvOD1wXMB26M6bgAW5FVdDNIPapwZ2AtK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCZHwVX/5pdJa1cgmtMU30GukUBD?= =?us-ascii?q?YFyhg0CgUg4FAEBAQEBAQFlJ4RBAQEBBC1cAgEIDgMEAQEoBzIUCQgBAQQBEgi?= =?us-ascii?q?IH8BsAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuBOIJiW4UgBZgBAY4DjxWPI?= =?us-ascii?q?AEeAQFCgjKBNWyHNz5+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,447,1454976000"; d="scan'208,217"; a="90668627" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2016 14:42:34 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u36EgYZs003209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 14:42:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 09:42:33 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 09:42:33 -0500 From: "Pascal Thubert (pthubert)" To: Dave Thaler , "6man@ietf.org" <6man@ietf.org> Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfgAArF4Q Date: Wed, 6 Apr 2016 14:42:19 +0000 Deferred-Delivery: Wed, 6 Apr 2016 14:41:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.170.136] Content-Type: multipart/alternative; boundary="_000_cf5da1c7066c449ebae204abd2f1f053XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:43:05 -0000 --_000_cf5da1c7066c449ebae204abd2f1f053XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dave, If "It" refers to the node, maybe it would be more readable to place the ch= ange at the end of the sentence? Cheers, Pascal From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: mercredi 6 avril 2016 11:21 To: 6man@ietf.org Subject: Proposed RFC 1981bis clarification regarding Hop Limit decrement b= eing orthogonal OLD: If any of the packets sent on that path are too large to be forwarded OLD: by some node along the path, that node will discard them and return OLD: ICMPv6 Packet Too Big messages [ICMPv6]. NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node along the path (regardless of whether it decrements the H= op Limit), that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. That is, just add the phrase "(regardless of whether it decrements the Hop = Limit)" to the existing sentence. Dave --_000_cf5da1c7066c449ebae204abd2f1f053XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Dave,=

 

If “It” re= fers to the node, maybe it would be more readable to place the change at th= e end of the sentence?

 

Cheers,

 = ;

Pascal

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] = On Behalf Of Dave Thaler
Sent: mercredi 6 avril 2016 11:21
To: 6man@ietf.org
Subject: Proposed RFC 1981bis clarification regarding Hop Limit decr= ement being orthogonal

 

OLD: If any of the pack=
ets sent on that path are too large to be forwarded

= OLD: by some node along the path, that node will discard them and return

= OLD: ICMPv6 Packet Too Big messages [ICMPv6]. 

=  

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node along the path (reg=
ardless of whether it decrements the Hop Limit), that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

That is, just add the phrase “(rega= rdless of whether it decrements the Hop Limit)” to the existing sente= nce.

 

Dave

--_000_cf5da1c7066c449ebae204abd2f1f053XCHRCD001ciscocom_-- From nobody Wed Apr 6 07:45:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A42212D676 for ; Wed, 6 Apr 2016 07:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 klUBahNyl5_I for ; Wed, 6 Apr 2016 07:45:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5267B12D67B for <6man@ietf.org>; Wed, 6 Apr 2016 07:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KNsfQ8yvkXCa8NE3OG05zdLvdyCpn++oqFfAwqA/y1c=; b=Lq44WezBxLSb+d/Zz3COAliPASnN7kOK+5L9FTHSDKKniUDuAaqWc+16P8/LtXfYaB+xB8ESKechS8mjOZj1E96/jKo5gzK+9DXiFpnPi/l0CDznBgNRct7xb46ZhZpkWikDQ0choqLZA/ikgDfDwAiRG/LMy0MCbsi0OkMfOA4= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0720.namprd03.prod.outlook.com (10.160.97.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 14:44:27 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 14:44:27 +0000 From: Dave Thaler To: "Pascal Thubert (pthubert)" , "6man@ietf.org" <6man@ietf.org> Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfgAArF4QAAAd27A= Date: Wed, 6 Apr 2016 14:44:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:370:160:ac5c:56:3492:5c] x-ms-office365-filtering-correlation-id: 58731424-6471-4ba1-21b1-08d35e29f46e x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0720; 5:m4lSqdiJG6nOoh/jRx2m80h5J1Cch+yJHRVRe0o9QKNA4KHZLOfAvR7RfPX/tlUGosMGTVk65dY06dBRfHwlh+/lTtK+iZoOb535INSJl0AETpNayG4FRZXV2ju6g5ECtHhCz5zD2tmbjchWSzveCw==; 24:F7DWmnLQ/zum9LBTYOXskZEEVyD4VybaiNdIAwtKZUsa0Yk06pEZ039E6axr94/L/D6LaYRPC7dBHLaRuspUdlDC2nFKAxRhwmQq/dlalHk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0720; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0720; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0720; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(10090500001)(76176999)(2906002)(5005710100001)(2950100001)(10400500002)(15975445007)(19300405004)(50986999)(10290500002)(5001770100001)(87936001)(107886002)(86612001)(33656002)(19580395003)(586003)(1220700001)(6116002)(8990500004)(19580405001)(92566002)(5003600100002)(2900100001)(5004730100002)(1096002)(790700001)(54356999)(5002640100001)(2501003)(102836003)(5008740100001)(77096005)(99286002)(3660700001)(3280700002)(11100500001)(122556002)(76576001)(86362001)(16236675004)(81166005)(74316001)(19625215002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0720; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB07173FDBB43D993C0CA96969A39F0DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 14:44:27.5494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0720 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:45:11 -0000 --_000_DM2PR0301MB07173FDBB43D993C0CA96969A39F0DM2PR0301MB0717_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, it refers to the node, and good grammatical point. So to take your f= eedback in a different spot: NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node (regardless of whether it decrements the Hop Limit) along= the path, that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. I.e. moved it up to right after the first existing use of "node". From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, April 6, 2016 11:42 AM To: Dave Thaler ; 6man@ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Hello Dave, If "It" refers to the node, maybe it would be more readable to place the ch= ange at the end of the sentence? Cheers, Pascal From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: mercredi 6 avril 2016 11:21 To: 6man@ietf.org Subject: Proposed RFC 1981bis clarification regarding Hop Limit decrement b= eing orthogonal OLD: If any of the packets sent on that path are too large to be forwarded OLD: by some node along the path, that node will discard them and return OLD: ICMPv6 Packet Too Big messages [ICMPv6]. NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node along the path (regardless of whether it decrements the H= op Limit), that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. That is, just add the phrase "(regardless of whether it decrements the Hop = Limit)" to the existing sentence. Dave --_000_DM2PR0301MB07173FDBB43D993C0CA96969A39F0DM2PR0301MB0717_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, it refers to the = node, and good grammatical point.   So to take your feedback in a= different spot:

 

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node (regardless of whet=
her it decrements the Hop Limit) along the path, that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

I.e. moved it up to ri= ght after the first existing use of “node”.

 

From: Pascal Thubert (pthubert) [mailto:pthub= ert@cisco.com]
Sent: Wednesday, April 6, 2016 11:42 AM
To: Dave Thaler <dthaler@microsoft.com>; 6man@ietf.org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Hello Dave,=

 

If “It” re= fers to the node, maybe it would be more readable to place the change at th= e end of the sentence?

 

Cheers,

 = ;

Pascal

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: mercredi 6 avril 2016 11:21
To: 6man@ietf.org
Subject: Proposed RFC 1981bis clarification regarding Hop Limit decr= ement being orthogonal

 

OLD: If any of the pack=
ets sent on that path are too large to be forwarded

= OLD: by some node along the path, that node will discard them and return

= OLD: ICMPv6 Packet Too Big messages [ICMPv6]. 

=  

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node along the path (reg=
ardless of whether it decrements the Hop Limit), that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

That is, just add the phrase “(rega= rdless of whether it decrements the Hop Limit)” to the existing sente= nce.

 

Dave

--_000_DM2PR0301MB07173FDBB43D993C0CA96969A39F0DM2PR0301MB0717_-- From nobody Wed Apr 6 08:14:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5EF12D6A9 for ; Wed, 6 Apr 2016 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 header.b=bF/fUxcp; dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com header.b=POS1VmjS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArSPwlAgxgt for ; Wed, 6 Apr 2016 08:14:03 -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 B329E12D0FA for <6man@ietf.org>; Wed, 6 Apr 2016 08:10:10 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id o126so37380865iod.0 for <6man@ietf.org>; Wed, 06 Apr 2016 08:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=XGdHwQ9+dFyWqQZXhz8wKrQb8G5jy/KqyEHygrD+6To=; b=bF/fUxcpXWFEA5ewKR2Ls+fynhgX0Do/5e959ndH2sgrVQAMp6a0NQ2zp4IRGUZPHn QKnHl35FFFU8pR1GQIUacgOPCCZpIy65Q5UAhcSFszT42GMlmOeX/+APoxwDZz8gQ3N2 n4CnqgClahjld4yykhAs6qYoYeb1Oy7+r3xvNYs4W66s+YMGLlcyHHQyNIXcfYomHxSn Lwmjp3sXInCqkxROdcWVUC2mDehzNP0CtIC9z6bC5rgV9tbokUYVThLZZKiUZVxN85jl EilkHYE1q/FwR9835X4Jt/OY8mVns/HBCqQPsgpY0zAy7kZ7CrOS/7Or9MseoNLfM4mv 3ouA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=XGdHwQ9+dFyWqQZXhz8wKrQb8G5jy/KqyEHygrD+6To=; b=POS1VmjSs4PwXliuRP89JxhL354PE/Hgewo/sCZPHXlEwzRHXrRTIUCXE7NxAiN4Dr MBjqTgTz0lYsRb+VNZMzN/UWWC1MEOHGFBXWfMsi53NznwLu87P9/qC2X/p8E/DQE4OW NIwY1bG8eknr5O/MroTSYjm4xpszWL4yzOXhPWrv0Cu2AiZtIvXxXQVGbzA8SV2h/dKl nlEgPc+8F58X9i6X0aXg74JTFDS68/TNwialj+C3Zlwt82jQ9rnZpE60FZzU1YR+WxFy 1bUX10vkoFRcj/YaOsnmi3t3ngRt3/AGbiXuOOV36Mf0nFHFG712xmBKLNca8El2OLqi xJzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XGdHwQ9+dFyWqQZXhz8wKrQb8G5jy/KqyEHygrD+6To=; b=V16TwfKPwR0JVVReVgcbcM3L6KQPc8SFxri3dVnkD64Dt6eDymjmqwelJ/6Pqnn0qm zTR+E33la0JPRtpkqCSXtDzHKGOuNVEtCK9zeE95mo5r2FQxAH7vrC2x6i1ZbHALfOA9 TJNEz/uZoObe8BXBkukiLLn3LmK0BiMtsMkj4/iyycu8toNV53m25pJb4dW7OKzB8uym L43FhFWfBFbQFymB6ibs2D4btfzls4lvM48dJ9Y/7DmDKsU4+wi1uvtKDa2omlyP2ewn fyKzRnNlLxWBV1hPh0wbRAU8VjePXf6XsHd6BmmJtdeezvaGWKZf8BRr+Q25SyHVeRYU A+Vw== X-Gm-Message-State: AD7BkJLf8a6nnTUFtZrrwo4zbg638Qyj0/UNjbr1r7WUZgm35hncdBmjqNbt2r1cBbazGt4EOTkQdPrgb0l9vA== MIME-Version: 1.0 X-Received: by 10.107.3.193 with SMTP id e62mr20658661ioi.40.1459955410000; Wed, 06 Apr 2016 08:10:10 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.79.67.197 with HTTP; Wed, 6 Apr 2016 08:10:09 -0700 (PDT) In-Reply-To: References: <5704F1C8.8010508@gont.com.ar> Date: Wed, 6 Apr 2016 11:10:09 -0400 X-Google-Sender-Auth: kfLA77Lxaec6EuTYtd7y66h-hTI Message-ID: Subject: Re: Discussion of default-iids and MAC address randomization and RFC4941 From: Kerry Lynn To: Dave Thaler Content-Type: multipart/alternative; boundary=001a113ecaee99e2a4052fd25b3a Archived-At: Cc: Chairs 6man <6man-chairs@tools.ietf.org>, Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-default-iids@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:14:05 -0000 --001a113ecaee99e2a4052fd25b3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 6, 2016 at 8:36 AM, Dave Thaler wrote: > > -----Original Message----- > > From: fgont.mobile@gmail.com [mailto:fgont.mobile@gmail.com] On Behalf > > Of Fernando Gont > > Sent: Wednesday, April 6, 2016 9:30 AM > > To: Lorenzo Colitti > > Cc: draft-ietf-6man-default-iids@tools.ietf.org; Chairs 6man <6man- > > chairs@tools.ietf.org>; 6man@ietf.org > > Subject: Re: Discussion of default-iids and MAC address randomization a= nd > > RFC4941 > > > > El 6/4/2016 9:02, "Lorenzo Colitti" escribi=C3=B3: > > > > > > Fernando, > > > > > > going on the record now because I won't be in BA. > > > > > > On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont > > wrote: > > >> > > >> * Stable addresses are currently required > > > > > > > > > As should be clear by now, I disagree. > > > > > > Further, I think that unless that statement is heavily qualified and > > applied only to specific use cases, there will need to be a substantial > privacy > > debate explaining how, even though "pervasive monitoring is an attack", > we > > are mandating that the IPv6 addresses on a given network be stable for > the > > life of the device. I think other parts of the IETF will need to be > involved in > > that debate as well. > > > > Please check the slides I've attached. Stable addresses are not a > requirement > > of this document, but a requirement of existing specs. > > > > This docunent applies *when* generqting stable addresses which, > > nowadays, is always. If you don't want that, you keed to update rfc4941= , > or > > randomize mac addresses and use the randomized mac address as the > > net_iface parameter of RFC7217. > > Disagree that you need to use the random mac address as the net_iface > parameter of RFC 7217. That is *one* way to do it. It's not the only wa= y > to do it. > draft-ietf-6lo-privacy-considerations-00 contains a longer analysis that = I > haven't heard any problems with so far. > > draft-ietf-6lo-privacy-considerations provides much needed guidance for using privacy addresses in the M2M domain where the desire to provide efficient IPv6 header compression may be overriding, especially for link local traffic. For the record, I have submitted comments to the 6lo mailing list (twice) that raise issues with this draft and I look forward to the discussion being joined in the 6lo WG. Kerry --001a113ecaee99e2a4052fd25b3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 6, 2016 at 8:36 AM, Dave Thaler <dthaler@microsoft.com>= wrote:
> -----Original Mess= age-----
> From: fgont.mobile@gmail.com= [mailto:fgont.mobile@gmail.c= om] On Behalf
> Of Fernando Gont
> Sent: Wednesday, April 6, 2016 9:30 AM
> To: Lorenzo Colitti <lorenzo@= google.com>
> Cc: dra= ft-ietf-6man-default-iids@tools.ietf.org; Chairs 6man <6man-
> chairs@tools.ietf.org>= ; 6man@ietf.org
> Subject: Re: Discussion of default-iids and MAC address randomization = and
> RFC4941
>
> El 6/4/2016 9:02, "Lorenzo Colitti" = <lorenzo@google.com> escrib= i=C3=B3:
> >
> > Fernando,
> >
> > going on the record now because I won't be in BA.
> >
> > On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont <fernando@gont.com.ar>
> wrote:
> >>
> >> * Stable addresses are currently required
> >
> >
> > As should be clear by now, I disagree.
> >
> > Further, I think that unless that statement is heavily qualified = and
> applied only to specific use cases, there will need to be a substantia= l privacy
> debate explaining how, even though "pervasive monitoring is an at= tack", we
> are mandating that the IPv6 addresses on a given network be stable for= the
> life of the device. I think other parts of the IETF will need to be in= volved in
> that debate as well.
>
> Please check the slides I've attached. Stable addresses are not a = requirement
> of this document, but a requirement of existing specs.
>
> This docunent applies *when* generqting stable addresses which,
> nowadays, is always. If you don't want that, you keed to update rf= c4941, or
> randomize mac addresses and use the randomized mac address as the
> net_iface parameter of RFC7217.

Disagree that you need to use the random mac address as the net_ifac= e
parameter of RFC 7217.=C2=A0 That is *one* way to do it.=C2=A0 It's not= the only way to do it.
draft-ietf-6lo-privacy-considerations-00 contains a longer analysis that I<= br> haven't heard any problems with so far.

draft-ietf-6lo-privacy-consid= erations provides much needed guidance for using
privacy addr= esses in the M2M domain where the desire to provide efficient
IPv= 6 header compression may be overriding, especially for link local traffic.<= /div>
For the record, I have submitted comments to the 6lo mailing list= (twice) that
raise issues with this draft and I look forward to = the discussion being joined in
the 6lo WG.

Kerry

--001a113ecaee99e2a4052fd25b3a-- From nobody Wed Apr 6 08:22:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48912D812 for ; Wed, 6 Apr 2016 08:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 ChBIZw2jV0xD for ; Wed, 6 Apr 2016 08:22:19 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 7A35012D8AD for ; Wed, 6 Apr 2016 08:18:35 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1anpDz-003PyK-1I; Wed, 06 Apr 2016 17:18:31 +0200 Date: Wed, 6 Apr 2016 17:18:31 +0200 From: David Lamparter To: Iljitsch van Beijnum Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160406151831.GZ518778@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:22:24 -0000 On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: > I'll be presenting > https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on > Wednesday. There are operational considerations here, so I encourage > people to drop in and/or comment on this draft. Ok... easy comments/opinions first: - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to piggyback on NUD sounds great, though admittedly I haven't thought it through looking for pitfalls. - if possible (not sure on NUD interactions), this should use RFC5082 TTL security, sending HL=255 and discarding packets !=255 - there's probably a lot of 4821 that can be incorporated by reference, shortening the draft by quite a bit - Mark Townsley's comment about extension headers doesn't make sense to me; we're looking at a single subnet here -- do we really want to support a non-fully-transparent layer 2 bridge messing up the packets? - the padding should be specified as "MUST be non-zero" and checksum validation a "MUST"; I've personally seen devices that zero out packets beyond their size limits but still switching them. - ditch IPv4, but +1 to Mark's "MUST NOT interact/break" room comment Now the hard bit; L2 devices messing with L2 addresses. The device class I have in mind here are 802.11 "client to wired" bridges. They connect to wifi as plain clients and have one or more LAN ports supporting multiple devices. 802.11 restricts them to the single MAC address their radio has, so what they do is they "MAC-NAT" everything behind them. (They rewrite ARP & ND and have an address table to undo it on incoming wireless packets.) The -05 draft currently says "Neighbors are identified by combination of a link address and an IP version". (NB: IP version, not IP address...) I believe the better choice here is "Neighbors are identified by their IPv6 link-local address". This removes any possibility for 2 hosts to be conflated into a single neighbor even in the presence of 'broken' L2 devices. It also makes clear that for forwarded packets beyond the subnet, the mechanism operates on the (host, router) pair and in no way interacts with L3 PMTUD or holds state for any global-scope address. The (host, router) pair would establish the maximum possible MTU for packets taking that route, from which PMTUD then works downwards. (Using link-local would introduce other corner cases, particularly if the link layer address changes, probe data isn't implicitly auto-discarded; this should become an explicit action. There's probably more corners I didn't think of.) -David From nobody Wed Apr 6 09:35:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7017D12D52A for ; Wed, 6 Apr 2016 09:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1Bu8wvNibwv8 for ; Wed, 6 Apr 2016 09:35:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B620F12D162 for ; Wed, 6 Apr 2016 09:35:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLQ97496; Wed, 06 Apr 2016 16:35:47 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 17:35:45 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 09:35:33 -0700 From: John Kaippallimalil To: "nordmark@acm.org" , "ipv6@ietf.org" Subject: dmm prefix cost, deprecated Ipv6 address Thread-Topic: dmm prefix cost, deprecated Ipv6 address Thread-Index: AdGQIlmokfq0g1tzTmGanzFKSpiZOg== Date: Wed, 6 Apr 2016 16:35:33 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB71EC6@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.163] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB71EC6dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.57053AE4.02C1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f2c04cadb06683fcd69b4fac7c4b6647 Archived-At: Cc: Peter McCann X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:35:58 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB71EC6dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, We have a section in the draft that describes the need for more than 2 valu= es of prefix cost. Snippet from https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 bel= ow: "..The operator of the network or host's service provider can configure policy that determines how the host should handle the prefix cost values. In a 3GPP network, the subscription provider may configure policies in the host via OMA-DM or S14 (ANDSF). For example, the service provider may configure rules to state that prefix cost values below 500 indicate low cost and ideal access network conditions, values from 501 - 5000 indicate that the host should try to relocate connections, and values above 5000 indicate a risk and impending loss of connectivity. The policies themselves can be (re-)configured as needed by the operator. Prefix cost information with each Router Advertisement allows the host to interpet a simple number and associated policies to (re-)select optimal routes. For networks service providers, when this cost is associated with charging, it can be a valuable tool in dynamically managing the utilization of network resources. " Also - my understanding of deprecating IPv6 addresses is that the behavior = may be different. The timeframes we are talking about here in many cases is= in the order of a few seconds (5 sec ?) - enough for the MN to find a bett= er address and move over gracefully. BR, John --_000_6561EABF52675C45BCDACA1B4D7AA1171DB71EC6dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

We have a section in the draft that describes the ne= ed for more than 2 values of prefix cost.

 

Snippet from https://tools.ietf.org/html/draft-mccann-dmm-prefixcost-02 below:<= /o:p>

“..The operator of the network or host's service provider ca=
n configure

  = policy that determines how the host should handle the prefix cost

  = values.  In a 3GPP network, the subscription provider may configure

  = policies in the host via OMA-DM or S14 (ANDSF).  For example, the

  = service provider may configure rules to state that prefix cost values=

  = below 500 indicate low cost and ideal access network conditions,

  = values from 501 - 5000 indicate that the host should try to relocate<= /o:p>

  = connections, and values above 5000 indicate a risk and impending loss=

  = of connectivity.  The policies themselves can be (re-)configured as

  = needed by the operator.  Prefix cost information with each Router

  = Advertisement allows the host to interpet a simple number and

  = associated policies to (re-)select optimal routes.  For networks=

  = service providers, when this cost is associated with charging, it can=

  = be a valuable tool in dynamically managing the utilization of network=

  = resources.

”

 

Also – my understanding of deprecating IPv6 ad= dresses is that the behavior may be different. The timeframes we are talkin= g about here in many cases is in the order of a few seconds (5 sec ?) ̵= 1; enough for the MN to find a better address and move over gracefully.

 

BR,

John

 

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB71EC6dfweml501mbb_-- From nobody Wed Apr 6 10:12:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349B612D6A5 for ; Wed, 6 Apr 2016 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 sE5eHepLajS3 for ; Wed, 6 Apr 2016 10:12:47 -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 5878412D67D for ; Wed, 6 Apr 2016 10:12:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 130EC2002A; Wed, 6 Apr 2016 13:16:18 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7FEEB6375A; Wed, 6 Apr 2016 13:12:45 -0400 (EDT) From: Michael Richardson To: David Lamparter Subject: Re: draft-van-beijnum-multi-mtu-05.txt In-Reply-To: <20160406151831.GZ518778@eidolon> References: <20160406151831.GZ518778@eidolon> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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: Cc: Iljitsch van Beijnum , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:12:50 -0000 --=-=-= Content-Type: text/plain David Lamparter wrote: > Now the hard bit; L2 devices messing with L2 addresses. The device > class I have in mind here are 802.11 "client to wired" bridges. They > connect to wifi as plain clients and have one or more LAN ports > supporting multiple devices. 802.11 restricts them to the single MAC > address their radio has, so what they do is they "MAC-NAT" everything > behind them. (They rewrite ARP & ND and have an address table to undo > it on incoming wireless packets.) This definitely falls into the category of stupid-layer-2 tricks to get around a lack of a routed (homenet-style) layer-3. sigh. IPv4 legacy. It seems you are saying with can deal with this problem with: > I believe the better choice here is "Neighbors are identified by their IPv6 > link-local address". This removes any possibility for 2 hosts to be > conflated into a single neighbor even in the presence of 'broken' L2 > devices. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwVDioCLcPvd0N1lAQL0nAf7BPP0qWAhZ3B8hP7ANoOdn68kaRLSZG4M D3nDGdZOn5nqZOkianBH1khXYrl663gQ9+bzUatk3HbXAtahVAI+eWJeijh0+XkD 0ydjOEiClI37XBXvXDxFbS0rij1XsSanThNnLjw+LOxVpNptUlZNHy17JUmhPCYQ VhlOToclyATX6pSeRQtuVkGgDc2eZfcV+C4YZ/UAyg1GoUNzl/S7Fk9ucRwyKo4C tKCscyRTh5lTxzXuSntoPLx7okOWlHx6uyazKFxc5pPgvBHavMLJt48zH4StnocU PJ0lOG2PJrXdKF/01uUpTahnXiaH9BIchrVG6+TMNNQCkGK+zEQkfA== =Rn69 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 6 10:43:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E8F12D6F9 for ; Wed, 6 Apr 2016 10:43: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 UlBV2vM9cM9X for ; Wed, 6 Apr 2016 10:43:15 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 BEFE512D6E4 for ; Wed, 6 Apr 2016 10:43:13 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1anrTw-003TUz-FU; Wed, 06 Apr 2016 19:43:08 +0200 Date: Wed, 6 Apr 2016 19:43:08 +0200 From: David Lamparter To: Michael Richardson Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160406174308.GA518778@eidolon> References: <20160406151831.GZ518778@eidolon> <15686.1459962765@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15686.1459962765@obiwan.sandelman.ca> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Iljitsch van Beijnum , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:43:17 -0000 On Wed, Apr 06, 2016 at 01:12:45PM -0400, Michael Richardson wrote: > David Lamparter wrote: > > Now the hard bit; L2 devices messing with L2 addresses. The device > > class I have in mind here are 802.11 "client to wired" bridges. They > > connect to wifi as plain clients and have one or more LAN ports > > supporting multiple devices. 802.11 restricts them to the single MAC > > address their radio has, so what they do is they "MAC-NAT" everything > > behind them. (They rewrite ARP & ND and have an address table to undo > > it on incoming wireless packets.) > > This definitely falls into the category of stupid-layer-2 tricks to get > around a lack of a routed (homenet-style) layer-3. sigh. IPv4 legacy. Indeed, though it's also 802.11 failing to cover bridges as plain clients. 802.11ak (= work in progress) and non-standardised WDS (widely available) solve the same issue, but they need AP implementation (11ak) or even configured cooperation (WDS); thus that class of kludge products will stay around for quite a while... > It seems you are saying with can deal with this problem with: Yes (sorry if I worded this poorly) - I arrived at the suggestion below in the hope that identifying by link-locals is less prone to L2 shenanigans than identifying by link-layer address. > > I believe the better choice here is "Neighbors are identified by their IPv6 > > link-local address". This removes any possibility for 2 hosts to be > > conflated into a single neighbor even in the presence of 'broken' L2 > > devices. From nobody Wed Apr 6 12:40:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7057012D6E7 for ; Wed, 6 Apr 2016 12:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 XwRIxucPpE1d for ; Wed, 6 Apr 2016 12:40:27 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15FC12D6E4 for ; Wed, 6 Apr 2016 12:40:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AKAgDlZQVX/yYyC4dcGgEBAYJvK1N9BrpGAQ2Bcx6FbwKBUDgUAQEBAQEBAWUnhEEBAQEBAxIPASwgCwwGAQgNBAMBAQECAwYCGwIDMwEUCQkBBAENBQgVBAGIBQENkjCSTIpGAZFoAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXmFKYRKhA8RAR6CfS6CKwWHb5ASAYV1iXxOg3+DHIU+jyEeAQFCgjKBNWwBAQGHPDYBfQEBAQ X-IPAS-Result: A2AKAgDlZQVX/yYyC4dcGgEBAYJvK1N9BrpGAQ2Bcx6FbwKBUDgUAQEBAQEBAWUnhEEBAQEBAxIPASwgCwwGAQgNBAMBAQECAwYCGwIDMwEUCQkBBAENBQgVBAGIBQENkjCSTIpGAZFoAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXmFKYRKhA8RAR6CfS6CKwWHb5ASAYV1iXxOg3+DHIU+jyEeAQFCgjKBNWwBAQGHPDYBfQEBAQ X-IronPort-AV: E=Sophos;i="5.24,448,1454994000"; d="scan'208";a="178951465" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Apr 2016 15:40:24 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 06 Apr 2016 15:40:15 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Wed, 6 Apr 2016 15:40:14 -0400 From: "Mudric, Dusan (Dusan)" To: Brian E Carpenter , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Subject: RE: ipv6 Digest, Vol 142, Issue 35 - Routing packets from hosts in a multi-prefix network Thread-Topic: ipv6 Digest, Vol 142, Issue 35 - Routing packets from hosts in a multi-prefix network Thread-Index: AdGQPCFCvbfa/4L9Tc2DcxMd4vzV3A== Date: Wed, 6 Apr 2016 19:40:13 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:40:29 -0000 Hi Brian, "Routing packets from hosts in a multi-prefix network" says: A router that advertises a prefix indicates that it is able to appropriately route packets with source addresses within that prefix, regardless of the setting of the L and A flags in the PIO. a host SHOULD NOT ignore a PIO simply because both L and A flags are cleared; a router SHOULD be able to send such a PIO. A host SHOULD select default routers for each prefix it is assigned an address in. The prefix list is used to find out if the destination address is on-link.= =20 If the router can route the packets from a host with the source address usi= ng L=3D0 prefix, theoretically off-link prefix can be used for SLAAC addres= s. The problem is that L=3D0 prefix might be used on other links and if the= host creates SLAAC address using L=3D0 prefix, the host will not be able t= o detect if the address is in use (DAD does not work between different rout= er links). For that reason looks like L=3D0 prefix should not be used for S= LAAC. If L=3D0 prefix is not use for SLAAC, there will be no source address= with L=3D0 prefix and L=3D0 prefixes will not help host to find the first = hop router. Consequently, hosts can ignore L=3D0 prefixes. Am I missing something about L=3D0 prefixes? Thanks, Dusan. -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of ipv6-request@ietf.or= g Sent: Monday, February 22, 2016 3:00 PM To: ipv6@ietf.org Subject: ipv6 Digest, Vol 142, Issue 35 Send ipv6 mailing list submissions to ipv6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i= CrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&= s=3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D or, via email, send a message with subject or body 'help' to ipv6-request@ietf.org You can reach the person managing the list at ipv6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of ipv6 digest..." Today's Topics: 1. I-D Action: draft-ietf-6man-multi-homed-host-05.txt (internet-drafts@ietf.org) 2. I-D Action: draft-ietf-6man-multi-homed-host-06.txt (internet-drafts@ietf.org) ---------------------------------------------------------------------- Message: 1 Date: Mon, 22 Feb 2016 10:32:52 -0800 From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-multi-homed-host-05.txt Message-ID: <20160222183252.21102.35271.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Routing packets from hosts in a multi-prefix netw= ork Authors : Fred Baker Brian Carpenter Filename : draft-ietf-6man-multi-homed-host-05.txt Pages : 13 Date : 2016-02-22 Abstract: This document describes expected IPv6 host behavior in a network that has more than one prefix, each allocated by an upstream network that implements BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. This host behavior may interact with source address selection in a given implementation, but logically follows it. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBFpWQw8bsuK= pl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U= 0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew5_ZvzDS1STF= tTjDg&e=3D=20 There's also a htmlized version available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQICAg&c=3DBFpWQw8bsuKp= l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0= qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DWqnr6PzhAWzCUOMlH0v2MPK87KyhpIfl1sDF96U= NhP4&e=3D=20 A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff= -3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQICAg&c=3DBF= pWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DvPYONcimyGIvGJFl1Th6RV-kSJv79= qPXaULdoyeOHEo&e=3D=20 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: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoU= WB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DDK= DpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D=20 ------------------------------ Message: 2 Date: Mon, 22 Feb 2016 10:55:30 -0800 From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-multi-homed-host-06.txt Message-ID: <20160222185530.5662.71093.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Routing packets from hosts in a multi-prefix netw= ork Authors : Fred Baker Brian Carpenter Filename : draft-ietf-6man-multi-homed-host-06.txt Pages : 13 Date : 2016-02-22 Abstract: This document describes expected IPv6 host behavior in a network that has more than one prefix, each allocated by an upstream network that implements BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. This host behavior may interact with source address selection in a given implementation, but logically follows it. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861. The IETF datatracker status page for this draft is: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBFpWQw8bsuK= pl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U= 0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew5_ZvzDS1STF= tTjDg&e=3D=20 There's also a htmlized version available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQICAg&c=3DBFpWQw8bsuKp= l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0= qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DlGfMGfWC7GV6V-rewMLkuXhmMv8qCGBHIxhCsFm= kOnY&e=3D=20 A diff from the previous version is available at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff= -3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQICAg&c=3DBF= pWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DUFS97FbjEQDBE-DJBZaJF7J3umdmn= 66PA1Z4yc95xjU&e=3D=20 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: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoU= WB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DDK= DpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D=20 ------------------------------ Subject: Digest Footer _______________________________________________ ipv6 mailing list ipv6@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iC= rhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s= =3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D=20 ------------------------------ End of ipv6 Digest, Vol 142, Issue 35 ************************************* From nobody Wed Apr 6 12:56:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A412D175 for ; Wed, 6 Apr 2016 12:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zQ33HkF0XH_X for ; Wed, 6 Apr 2016 12:55:59 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 C2CB112D12E for ; Wed, 6 Apr 2016 12:55:59 -0700 (PDT) Received: from [31.133.180.15] (dhcp-b40f.meeting.ietf.org [31.133.180.15]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u36JtmhH015514 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 12:55:50 -0700 Subject: Re: draft-van-beijnum-multi-mtu-05.txt To: David Lamparter , Iljitsch van Beijnum References: <20160406151831.GZ518778@eidolon> From: Erik Nordmark Message-ID: <570569C2.4030601@acm.org> Date: Wed, 6 Apr 2016 16:55:46 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160406151831.GZ518778@eidolon> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYKBlr37FhBXkWHPLH8Z0YmP6iiNqvvnG7jMs+Osr9te5p+u0E0npgkcSiZMROhk9ZuSPhbJb+GI0OFzZtt0AnE X-Sonic-ID: C;TIbKjjH85RG/hZFDXdaMvg== M;qn+ujzH85RG/hZFDXdaMvg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:56:01 -0000 On 4/6/16 12:18 PM, David Lamparter wrote: > On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: >> I'll be presenting >> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on >> Wednesday. There are operational considerations here, so I encourage >> people to drop in and/or comment on this draft. > Ok... easy comments/opinions first: > - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to > piggyback on NUD sounds great, though admittedly I haven't thought it > through looking for pitfalls. One issue compared to a dedicate probe is that a NUD (a unicast NS) of size X wouldn't necessarily result in a unicast NA that is also padded; perhaps one can add such behavior so that we can get the bidirectional probe in both directions. Note that just like TCP can suppress the need for NUD (per RFC 4861) a TCP implementation could also indicate to the IP layer than a packet of size X got through, which could be used to suppress the MTU probe. That applies independently of what protocol is used to do the MTU probing. > > - if possible (not sure on NUD interactions), this should use RFC5082 > TTL security, sending HL=255 and discarding packets !=255 Yes, it would make sense to use the TTL security approach for the probe protocol, whether it is UDP or NUD or something else. > > - there's probably a lot of 4821 that can be incorporated by reference, > shortening the draft by quite a bit Are you referring to the choice of sizes to try? I haven't re-read 4861 next to this draft. > > - Mark Townsley's comment about extension headers doesn't make sense to > me; we're looking at a single subnet here -- do we really want to > support a non-fully-transparent layer 2 bridge messing up the packets? My understanding is that the muti-mtu draft is for the local link, and not for end-to-end. An observation is that if/where RFC4821 is implemented, then the dependency on ICMP PTB is removed. Hence addresses Mark's comment. > > - the padding should be specified as "MUST be non-zero" and checksum > validation a "MUST"; I've personally seen devices that zero out > packets beyond their size limits but still switching them. Good point. Regards, Erik > > - ditch IPv4, but +1 to Mark's "MUST NOT interact/break" room comment > > > Now the hard bit; L2 devices messing with L2 addresses. The device > class I have in mind here are 802.11 "client to wired" bridges. They > connect to wifi as plain clients and have one or more LAN ports > supporting multiple devices. 802.11 restricts them to the single MAC > address their radio has, so what they do is they "MAC-NAT" everything > behind them. (They rewrite ARP & ND and have an address table to undo > it on incoming wireless packets.) > > The -05 draft currently says "Neighbors are identified by combination of > a link address and an IP version". (NB: IP version, not IP address...) > > I believe the better choice here is "Neighbors are identified by their > IPv6 link-local address". This removes any possibility for 2 hosts to > be conflated into a single neighbor even in the presence of 'broken' L2 > devices. > It also makes clear that for forwarded packets beyond the subnet, the > mechanism operates on the (host, router) pair and in no way interacts > with L3 PMTUD or holds state for any global-scope address. The (host, > router) pair would establish the maximum possible MTU for packets taking > that route, from which PMTUD then works downwards. > > (Using link-local would introduce other corner cases, particularly if > the link layer address changes, probe data isn't implicitly > auto-discarded; this should become an explicit action. There's probably > more corners I didn't think of.) > > > -David > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Apr 6 13:15:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D154D12D59B for ; Wed, 6 Apr 2016 13:15:40 -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 fKBtTSMEQ8v6 for ; Wed, 6 Apr 2016 13:15:39 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 09E6F12D191 for ; Wed, 6 Apr 2016 13:15:39 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c20so40235776pfc.1 for ; Wed, 06 Apr 2016 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LJb6zYK+g/uU8PQoqYBmfp88ODXoKVzuTep/NEpMzZU=; b=Yhc0lyRcadFfpy7b87yICWQDbJslux+k9bVHZi7pnUrrZpLCoFDElR/k4Zxboybky9 SyAvnA7rAxruWw+vjq07eK290ugClmY1ZXhJ9gRrqmOnFgI08YBxhiH2bMWe9Dbo7Vm9 b3BTDU9Pjm/cMEHkpw4Tifd8n6VsVJDisf7sDeAiPQ+aT8W26iXFJGqIRiezrAH6OlS1 qTP8nw6Q5bcYwpUvHoT/i0VOeJUFwBSiqxs/L4vbiooLkhl+GntwJrYcknOBmqgHKs4X QBrZOqtjiBMBuVfHsCM/FzrihpkI19chZl5iKBQWdUrr28W00AuqnqREJeGK01es7eV1 cnpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=LJb6zYK+g/uU8PQoqYBmfp88ODXoKVzuTep/NEpMzZU=; b=UkR2WyjzuZjLfTua29l5oTizSTCCDJslq8uihyM50ejaxOs2dm02mlegnlcfw2jtqE ozMJrezVZVDITsEBeV5Y6z62V3Ees84S8EFI1JWtzUho3tQOoLSqyvqDdWS2SjjVgNap nKUSdJAjIAwxmtED8NXQY3xDRIJC5BQCB2aAB8wU2CCy2AKzcJ6f94aQtQ1j++PHK+Ii MyOiyqLclQptWA+I+9JodPm3BTxruQLmeWBRO6NDTEiNxbuAh0+rNGtZBxtVF8GEQl5m XuwZ4iqLzbAzilt1OGMeEMtHn/IYqm59A9cRmruY4OQw3j3OUaMzu98EklXud4Zamhb4 Cwgg== X-Gm-Message-State: AD7BkJK2TcUKr4ZGBumPixAdJqQzoTEyNsZjYjjkdjn4XXYjGNCop7JcSgE2lPylwiyJzg== X-Received: by 10.98.1.197 with SMTP id 188mr41258589pfb.8.1459973738420; Wed, 06 Apr 2016 13:15:38 -0700 (PDT) Received: from ?IPv6:2406:e007:481c:1:28cc:dc4c:9703:6781? ([2406:e007:481c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id se8sm6853940pac.44.2016.04.06.13.15.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 13:15:36 -0700 (PDT) Subject: Re: rfc2460bis question To: "Stefano Previdi (sprevidi)" , Bob Hinden References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57056E6C.2090902@gmail.com> Date: Thu, 7 Apr 2016 08:15:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:15:41 -0000 On 06/04/2016 22:46, Stefano Previdi (sprevidi) wrote: >=20 >> On Apr 4, 2016, at 9:46 PM, Bob Hinden wrote: >> >> Brian, >> >>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter wrote: >>> >>> Hi, >>> >>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 tha= t >>> seems to come up repeatedly. >>> >>> Are intermediate systems allowed to insert, change or delete Extensio= n Headers, >>> apart from specified cases (routing headers, and HbH options that may= change >>> en route)? And in the cases where changes are allowed, are intermedia= te systems >>> allowed to change the *length* of headers or option data? >> >> Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header"= : >> >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >=20 >=20 > in a controlled environment where boundaries are clearly identified and= with the appropriate security mechanisms, I don=E2=80=99t see why an ext= ension header can=E2=80=99t be inserted, as long as whatever you insert i= s removed when existing the controlled domain. >=20 > As a matter of fact, it does happen already thanks to multiple interope= rable implementations (segment routing header, RH4) and I know networks w= here this is being deployed.=20 >=20 > Again, this is a controlled environment. >=20 > Stating that "Extension headers must never be inserted by any node=E2=80= =A6=E2=80=9D looks a bit extreme to me and I=E2=80=99d prefer to =E2=80=9C= recommend=E2=80=9D not to insert rather than just ignoring what happens i= n real networks and for real use cases. I disagree. We're fixing some poor writing in 2460, which failed to state= what seemed obvious at the time. Of course, there are no protocol police and p= eople can do what they want in a closed domain, but if we relax the "must not" = we have done nothing to fix the poor writing; we've actually made it worse. I completely agree with Erik that there's a real probability of leakage, = which is another reason for the "must not" approach. Regards Brian From nobody Wed Apr 6 13:20:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7612D70F for ; Wed, 6 Apr 2016 13:20:01 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 3TXOlEh7jwUz for ; Wed, 6 Apr 2016 13:19:59 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 445C612D667 for ; Wed, 6 Apr 2016 13:19:59 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id ui10so52505768igc.1 for ; Wed, 06 Apr 2016 13:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=n9az/UEru5ZP6edOgaHr2LaTbi3newpBBa7Ik2uqCMg=; b=VT8I3E82voPjRMr0wg0acjvvbeFrblv46BJtKW4ZzaF/CJQ+1TS5HzaBXAln3AP/qh 7cioUWsA2ug6h8QvN6+0QxL8yutcA8RJGh5ccPwwAHzpULO8qqCGWtyOiPT/wgnI5vt7 mq7d50Kizq5YWNksVTIDhVkzDjC4NesIVN/MTl/Osvsdx4YBboG3dUglZ9c5psYgIBq3 r51ONcHOogrpCgjVh/YEnhFAQO0IrgPjP6O028urMUg4fbiW5FfsyFpLiW1kibR1ycdo FrdYTpmqQOwpeBg6Ksdx/PwoSIWNjdcK+nIQhDbUPN4a0tzFl/BBxbf+kiDawDbz2bB1 vhww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=n9az/UEru5ZP6edOgaHr2LaTbi3newpBBa7Ik2uqCMg=; b=BBnfyS7u2pxk5VAWxj+PSnkecCKwN5tv7yNqZKkYEJG8EsHD+Oyi0KGtDnH/7BlSQ2 5jdm3FQcq22c2TqLnshpc/EYie8VCpsujDNZ4Vq4mtAqUEN15MwUjd6PVycGxIukS6Ko FlzOcumd9Hv/DIwObSqh1XCOuLpXfNu4n1gRA6vpdguoBtGXC7mlrRs4Z4htG71e2tzp lgjes1ny8zw26GsIzgy/BLNAnC+gRxsS8ccqU1NOsCv9BOc8rkS6rmWc8n9lI+fz45wH GhUsR0xq2RiSNsp8ykA2jkuSIgM0kbbKkkQ/YL9ojo6vZvZtxLKL90JXaVw0Jtd/ZhuH etDQ== X-Gm-Message-State: AD7BkJLuQ/9d+myAo4c++7wbUCT6wDzkK/p3MvkQpSG4RDc4Yut1rHCPRV0jTIYXhJSaUo16xQc8JBIt0WxoOQ== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr26035874igl.78.1459973998554; Wed, 06 Apr 2016 13:19:58 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.198.133 with HTTP; Wed, 6 Apr 2016 13:19:58 -0700 (PDT) In-Reply-To: <57056E6C.2090902@gmail.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> Date: Wed, 6 Apr 2016 13:19:58 -0700 X-Google-Sender-Auth: rIBa6HKPOZO5vZaM5qr3DeFJYpc Message-ID: Subject: Re: rfc2460bis question From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:20:01 -0000 At Thu, 7 Apr 2016 08:15:40 +1200, Brian E Carpenter wrote: > > Stating that "Extension headers must never be inserted by any > > node=E2=80=A6=E2=80=9D looks a bit extreme to me and I=E2=80=99d prefer= to =E2=80=9Crecommend=E2=80=9D not > > to insert rather than just ignoring what happens in real networks > > and for real use cases. > > I disagree. We're fixing some poor writing in 2460, which failed to state= what > seemed obvious at the time. Of course, there are no protocol police and p= eople > can do what they want in a closed domain, but if we relax the "must not" = we have > done nothing to fix the poor writing; we've actually made it worse. > > I completely agree with Erik that there's a real probability of leakage, = which > is another reason for the "must not" approach. +1 (to Brian and Erik). -- JINMEI, Tatuya From nobody Wed Apr 6 13:27:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143F712D65F for ; Wed, 6 Apr 2016 13:27: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 bAt0sAs7Qj9o for ; Wed, 6 Apr 2016 13:27:32 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 E013012D639 for <6man@ietf.org>; Wed, 6 Apr 2016 13:27:31 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id fe3so39704302pab.1 for <6man@ietf.org>; Wed, 06 Apr 2016 13:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Inpac3LfkESOd2HT9g0xRASVU7pMOHyVy6DjPk/gG8k=; b=ta8pPSkgKryjetGd+Rt/CL76T9C0hLWnxzSuwllxDdVri5KjiqbI2TS0yOQVTN15M+ Q7Ebj+IlopRrwPKNAXKvdsLue9dUQM1/dvKOtELfQxJAhYMdw6axQUxWIYlYPWDuuRYY woGv9B5hCvQQR6+9jbz5MU1o4VeK8karQqYjd42AK+ZTFfx6utLqRct1JDaOBCl+EHD4 00c0p6shEkiwUCD42U2ceEUT2M14sjkVhqzetIFEO5Jltjk9lWFzk8sTz3X0wxx83NsF d/AvhJhqDsKJY/aVpSlNgBGBXatxF4MH5+LMTJyjobCFrBQrIZTafakSpWmtHdhaPLxk LUlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=Inpac3LfkESOd2HT9g0xRASVU7pMOHyVy6DjPk/gG8k=; b=ZeH5SLztLSAffpf2y8AAV2LToeksrOSdCggSVq3jlmiaQEwOP16b6IFhFibR0AoYay rkrLNCPK4i8RVnNACMlS6A8aXIagNb/yQOBa/AXuejwvYI1OvvCG37YtnJlpQVRPRZC1 75EqB0RZCwcbnemvNaxpeXYOCvHOzm41m4kprdhAdoX5ppj0S+Zbsry+xGsaoka9E/MF Ey4DqH6uc7b68OwXnDmV74q3gbcEJ0OrzSfUVwsjge0vIUDfGSo3YzTsWOM0cCGIpShO 2lz8yRoIF7Hugoh2Jl2Auf8gmvC5fmhY4TS1dtsvwOTsSbm01r9SyDBx+rBARqtYXd2K XuRQ== X-Gm-Message-State: AD7BkJLsI68SsAWdO8eGnayWXRIIeIO87p4sqQZOj9f28wVDqxJfi/0yAyIJN8qJphtHLA== X-Received: by 10.66.190.40 with SMTP id gn8mr73349761pac.64.1459974451220; Wed, 06 Apr 2016 13:27:31 -0700 (PDT) Received: from ?IPv6:2406:e007:481c:1:28cc:dc4c:9703:6781? ([2406:e007:481c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s66sm6918452pfi.3.2016.04.06.13.27.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 13:27:30 -0700 (PDT) Subject: Re: Discussion of default-iids and MAC address randomization and RFC4941 To: Fernando Gont , Lorenzo Colitti References: <5704F1C8.8010508@gont.com.ar> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57057134.1060003@gmail.com> Date: Thu, 7 Apr 2016 08:27:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Chairs 6man <6man-chairs@tools.ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-default-iids@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:27:34 -0000 Hi Fernando, On 07/04/2016 00:29, Fernando Gont wrote: > El 6/4/2016 9:02, "Lorenzo Colitti" escribi=C3=B3:= >> >> Fernando, >> >> going on the record now because I won't be in BA. >> >> On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont > wrote: >>> >>> * Stable addresses are currently required >> >> >> As should be clear by now, I disagree. >> >> Further, I think that unless that statement is heavily qualified and > applied only to specific use cases, there will need to be a substantial= > privacy debate explaining how, even though "pervasive monitoring is an > attack", we are mandating that the IPv6 addresses on a given network be= > stable for the life of the device. I think other parts of the IETF will= > need to be involved in that debate as well. >=20 > Please check the slides I've attached. Stable addresses are not a > requirement of this document, but a requirement of existing specs. >=20 > This docunent applies *when* generqting stable addresses which, nowaday= s, > is always. If you don't want that, you keed to update rfc4941, or rando= mize > mac addresses and use the randomized mac address as the net_iface param= eter > of RFC7217. As I think I've tried to say several times, you *really* need to add new = text at the beginning of the Introduction to take account of what Lorenzo has = been saying. You just start of with a bang '...which typically results in hosts config= uring one or more "stable" addresses' and you should really start off with the need fo= r privacy, the fact that RFC4941 is the recommended solution for privacy, but that t= here is a long-standing need for stable addresses too. Maybe you also need to = state that RFC4941-only is a valid scenario (which is new, I think). Then state= that when stable addresses are needed, predictable and traceable stable addres= ses are a Bad Thing. Then you can start talking about SLAAC... Regards Brian >=20 > i.e., I'm not even arguing against your desire of rfc4941. For instance= , i > understand that there are scenarios in which you may want to do that. B= ut > what's interferring with thqt is the existing specs (e.g., rfc4941), an= d > not this document. >=20 > This document applies only when uou generate stable addresses. Nowadays= , > tjat happens to be "always" because other documents mandate that. >=20 >>> * It's important that the implications around randomized MAC address= es >>> when used with traditional SLAAC be clearly spelled out (see the post= ed >>> slideware). >> >> >> There's a lot of FUD in that: >> We do not control whether MAC addr randomization algorithm is appropri= ate > or if it is actually possible. Not true - or rather, it's mostly not tr= ue. > The exact level of incorrectness depends on who "we" is. If "we" =3D "A= pple", > then that statement is completely false. If "we" =3D "Windows" or "we" = =3D > "Android" then it is only mostly false. If "we" =3D "Linux" it is almos= t > certainly false unless the host is using binary-only drivers. >=20 > We =3D=3D ietf. This is not an android or mac devloping forum. >=20 >> Wastes 18 bits of entropy: "wastes" how? What's the downside? >=20 > Local/global bit, unicast/multicast bit, and 0xfffe. Talk to JC Zu=C3=B1= iga. >=20 >> Interoperability problems: depends heavily on the link layer. It's not= > true that you can't recover from DAD failures using SLAAC, you can just= > pick another number and try again. >=20 > Could you please point me a spec tjat explains how to recover from a DA= D > collision in a protocol where the premise is giving you a unique identi= fier? >=20 >> Of course, there's nothing new in my position, just like there's nothi= ng > new in yours. I'd just like to make sure that nobody can later state th= at > the people who objected to the document are no longer objecting :-) >=20 > In the same way that if we were to add this to draft-gont-numeric-ids a= s an > example of doing things wrong after 30 years of experience with that, > nobody can say that nobody noted it. >=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 6 13:58:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4312D542 for ; Wed, 6 Apr 2016 13:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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=1, RCVD_IN_DNSWL_LOW=-0.7, 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 0pthX4qlFZhh for ; Wed, 6 Apr 2016 13:58:35 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 4FA3C12D149 for ; Wed, 6 Apr 2016 13:58:35 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e6so74571028vkh.2 for ; Wed, 06 Apr 2016 13:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=67E1NXEtE/XIJBKyF/oshgSg6cmYrnxtojcTw4PXa28=; b=uaRqYbR0ICsGzXqTumHrwsw4Z0aWfdpTwPzFcgSWGFX+H5sWPCA1q0kgVjyWNNsGrl wtyPzfOWPEMhfKPS2Oc9ZCkln5taTA466RYQOxRmPFf2ajfo4ygHhVxSb1ETYqhAWpKc BVENqsXY91Lj3griwQpuNTB2XMZZELwV8U8YD/sPUp819jX0WmZrX43YGd60F29pBwe8 Xyp+o4zrD9EXgloQIgUJeBnWZ5AvilOP/fHxIs01hNdgAqtuvrvA3vVbmHPJzwCvMEVA GpuHMHEoGu4adL6lvSPuQheyso74CEio+7wxTC/zvrc6aV39I2DBqTfVLrTWedehK/ij 8fiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=67E1NXEtE/XIJBKyF/oshgSg6cmYrnxtojcTw4PXa28=; b=S2S78F9wXNBCymyJW4vYsBWslHd1mLmir17bDjGxNXQM/xI/GsB64X5l1WUbSCRa/Q WSeaIHtUZ9OVZRpaEA29avAI9v9/1SwBR22onI830jKz6DN6vXDDWfnj3QDH01KPV1GP AUbrHyzYmMUvXvwHGAlCAofTFDBzKIUaGbv8Y3kUbKML8dwz1ZX3lbvqEz/ijs+tmZcO AlSutBZNe2X9cXFZg1cy/7KDiTtItJ1GTKBDgCOXqpzUmUWVYILt+8p12b98g6tXb55M MMOLrPSk/5D59I5NSpbft2B/hOaCGWf4KgKr26Jclx2Jln5bM9ubVrHHmtAY3qYESI4Q q76g== X-Gm-Message-State: AD7BkJIyc+gMxi+8/wkdLJ7uANDx4khO5uBmL5BW3GOwVySZegDqLlkDDOabkvajZ7lBOXAtqEmXaGH35JYSxg== X-Received: by 10.176.65.33 with SMTP id j30mr14046993uad.142.1459976314304; Wed, 06 Apr 2016 13:58:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.228 with HTTP; Wed, 6 Apr 2016 13:58:04 -0700 (PDT) In-Reply-To: <57056E6C.2090902@gmail.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> From: Mark Smith Date: Thu, 7 Apr 2016 06:58:04 +1000 Message-ID: Subject: Re: rfc2460bis question To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:58:37 -0000 On 7 April 2016 at 06:15, Brian E Carpenter w= rote: > On 06/04/2016 22:46, Stefano Previdi (sprevidi) wrote: >> >>> On Apr 4, 2016, at 9:46 PM, Bob Hinden wrote: >>> >>> Brian, >>> >>>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter wrote: >>>> >>>> Hi, >>>> >>>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 that >>>> seems to come up repeatedly. >>>> >>>> Are intermediate systems allowed to insert, change or delete Extension= Headers, >>>> apart from specified cases (routing headers, and HbH options that may = change >>>> en route)? And in the cases where changes are allowed, are intermediat= e systems >>>> allowed to change the *length* of headers or option data? >>> >>> Some relevant words from rfc2460bis Section 4. "IPv6 Extension Header": >>> >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >> >> >> in a controlled environment where boundaries are clearly identified and = with the appropriate security mechanisms, I don=E2=80=99t see why an extens= ion header can=E2=80=99t be inserted, as long as whatever you insert is rem= oved when existing the controlled domain. >> >> As a matter of fact, it does happen already thanks to multiple interoper= able implementations (segment routing header, RH4) and I know networks wher= e this is being deployed. >> >> Again, this is a controlled environment. >> >> Stating that "Extension headers must never be inserted by any node=E2=80= =A6=E2=80=9D looks a bit extreme to me and I=E2=80=99d prefer to =E2=80=9Cr= ecommend=E2=80=9D not to insert rather than just ignoring what happens in r= eal networks and for real use cases. > > I disagree. We're fixing some poor writing in 2460, which failed to state= what > seemed obvious at the time. Of course, there are no protocol police and p= eople > can do what they want in a closed domain, but if we relax the "must not" = we have > done nothing to fix the poor writing; we've actually made it worse. > > I completely agree with Erik that there's a real probability of leakage, = which > is another reason for the "must not" approach. > And here is an example of how hard troubleshooting silent modification in the network can be: "How both TCP and Ethernet checksums fail" http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html The statement "The answer is that the Ethernet CRC is recalculated by switches. If the switch corrupts the packet and it has the same TCP checksum, the hardware blindly recalculates a new, valid Ethernet CRC when it goes out." Isn't quite right. Switches only recalculate the checksum when they modify the packet, by adding or removing e.g., an 802.1q shim. Occurrence may be rare, but it is hard and time costly to troubleshoot. I understand the 802.1q people did it because they didn't think widely available ethernet hardware could handle fully encapsulating the packet in another - as Cisco did with their proprietary alterantive (whose name doesn't spring to mind right now). Thinking about the above risk was what made me realise that tunnelling is a far better method of adding information or other semantics via indirect methods to a packet than "shimming", because it always left the original packet alone. Regards, Mark. From nobody Wed Apr 6 14:17:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988AD12D174 for ; Wed, 6 Apr 2016 14:17: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, 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 qPg-Pv2ePyus for ; Wed, 6 Apr 2016 14:17:38 -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 D070012D6C8 for ; Wed, 6 Apr 2016 14:17:37 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:8d8f:be82:5f7:ab59] (unknown [IPv6:2001:67c:370:160:8d8f:be82:5f7:ab59]) (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 B2673800C1; Wed, 6 Apr 2016 23:17:31 +0200 (CEST) Subject: Re: rfc2460bis question To: Brian E Carpenter , "Stefano Previdi (sprevidi)" , Bob Hinden References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> From: Fernando Gont Message-ID: <57057CE1.6030001@si6networks.com> Date: Wed, 6 Apr 2016 18:17:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57056E6C.2090902@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:17:39 -0000 On 04/06/2016 05:15 PM, Brian E Carpenter wrote: >> >> >> in a controlled environment where boundaries are clearly identified >> and with the appropriate security mechanisms, I don’t see why an >> extension header can’t be inserted, as long as whatever you insert >> is removed when existing the controlled domain. >> >> As a matter of fact, it does happen already thanks to multiple >> interoperable implementations (segment routing header, RH4) and I >> know networks where this is being deployed. >> >> Again, this is a controlled environment. >> >> Stating that "Extension headers must never be inserted by any >> node…†looks a bit extreme to me and I’d prefer to “recommend†not >> to insert rather than just ignoring what happens in real networks >> and for real use cases. > > I disagree. We're fixing some poor writing in 2460, which failed to > state what seemed obvious at the time. Of course, there are no > protocol police and people can do what they want in a closed domain, > but if we relax the "must not" we have done nothing to fix the poor > writing; we've actually made it worse. > > I completely agree with Erik that there's a real probability of > leakage, which is another reason for the "must not" approach. I concur with Brian and Erik here. 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 6 14:20:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498EB12D6FF for ; Wed, 6 Apr 2016 14:20: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, 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 tQTv1DlCxzJ1 for ; Wed, 6 Apr 2016 14:20:54 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 D9D5F12D174 for ; Wed, 6 Apr 2016 14:20:53 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1anusa-003YOQ-4t; Wed, 06 Apr 2016 23:20:48 +0200 Date: Wed, 6 Apr 2016 23:20:48 +0200 From: David Lamparter To: Erik Nordmark Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160406212048.GB518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570569C2.4030601@acm.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Iljitsch van Beijnum , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:20:56 -0000 On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: > On 4/6/16 12:18 PM, David Lamparter wrote: > > On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: > > Ok... easy comments/opinions first: > > - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to > > piggyback on NUD sounds great, though admittedly I haven't thought it > > through looking for pitfalls. > One issue compared to a dedicate probe is that a NUD (a unicast NS) of > size X wouldn't necessarily result in a unicast NA that is also padded; > perhaps one can add such behavior so that we can get the bidirectional > probe in both directions. That might be (half of) a feature: if the MTU probe is a NS option, and the target host does not support it, we still get a NA reply. That's better than timing out waiting. The downside is that a NA without the "MTU response" option doesn't mean that the host doesn't implement the protocol -- the NA could be in response to something else. That said, I'd expect the probability of a host ignoring a new NS option is much lower than it filtering out unknown new ICMP (sub)types or UDP ports. If that reduces useless probing (or even waiting), I'm all for it. (As I understand it, the draft in no case suggests waiting for the probes to come back, so it's not much of an argument. Might still reduce useless probe traffic?) > > - there's probably a lot of 4821 that can be incorporated by reference, > > shortening the draft by quite a bit > Are you referring to the choice of sizes to try? I haven't re-read 4861 > next to this draft. I was thinking it could be possible to inherit parts of the algorithm and corner case behaviour spec, but the draft makes the argument that its probing can be much more aggressive since there is (almost?) no congestion interference. That seems a fair point, so I guess I spoke too quickly :( > > - if possible (not sure on NUD interactions), this should use RFC5082 > > TTL security, sending HL=255 and discarding packets !=255 > Yes, it would make sense to use the TTL security approach for the probe > protocol, whether it is UDP or NUD or something else. Rereading the draft, it already says "other than 255 [...] discarded". So my comment turns into "add explicit reference to 5082". -David From nobody Wed Apr 6 14:57:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB712D1E0 for ; Wed, 6 Apr 2016 14:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 oqsvf7mTE3Kq for ; Wed, 6 Apr 2016 14:57:39 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BA412D53D for ; Wed, 6 Apr 2016 14:57:38 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 9328ED7884; Wed, 6 Apr 2016 14:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=78isX7HbzWzP4wWuzs81NOOG1ME=; b= idKdZjyQKPO04xWKlO7mJhwjsgGFbBhWJwAbliqgMx2BFZyEGcySiWBReBe/33/j aET8IeuG3+MfNl5p+WjOJ7xI0l7bQOewfkBFzZCMkIEUEX3916PaC90kbZ/piKdf ySGIUe2igkA/7PzUbg771UaT/cmRJX+iWxz4bQjcmx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ptvc8Yp8RGolAK4008v1rqEzKD 9Riu54W9hScPgM5ZsVGb6HQLCzKztKBisoFizT3c/QmLTc2bQtObOAttLxMiQdwe qZnLWnYyIwisdoaybZ59qGc3BQSMtbG4Gohh5NJrOGCKosY98b1YNthkuViNgnls ObRkIc/C5Czht1cr4= Received: from h.hanazo.no (dhcp-b1da.meeting.ietf.org [31.133.177.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 2A066D7883; Wed, 6 Apr 2016 14:57:37 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2547B140F7F2; Wed, 6 Apr 2016 18:57:34 -0300 (ART) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2F5E828C-D383-4310-800D-02A62C39E385"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <57056E6C.2090902@gmail.com> Date: Wed, 6 Apr 2016 18:57:33 -0300 Message-Id: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:57:42 -0000 --Apple-Mail=_2F5E828C-D383-4310-800D-02A62C39E385 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let me add on to the comments that I made during the meeting today: There is a high bar to introduce changes to RFC2460. Changes are limited = to those described in RFC6410 in addition to "Updated by" documents. The proposed change presented today is: (note that is updated from what = is in the draft) "Extension headers must never be deleted or changed in size by any = node on the path the packet takes. The contents of an Extension header or Option in an Extension header = may be modified if this is permitted by the definition of the Extension header or option." There is no errata or updated-by document concerning this issue. It is not an unused feature, since the proposal is to add new text to = RFC2460. As far as I am aware, there is no interoperability issue caused by the = current RFC2460 text. And as far as I can tell the proposed addition is unlikely to create = interoperability issues either. There is RFC4782, that allows for deletion of extension headers. That is = an experimental RFC, and I'm unaware of what the conclusion from the = experiment is. RFC791 allows the introduction of options in certain = cases. Resolving how header insertion or deletion of extension headers / option = is done is outside the scope of the changes we can make to 2460. Those = considerations should be done in the protocol specification for those = proposed extension headers / options. My current view on this, is that it would appear that like to have this = additional text, not to fix an existing problem, but to fend off what = should be allowed in new protocol specifications. As I said at the microphone, my position as chair is that by _default_, = the text in RFC2460 is left unchanged. Ole > On 06 Apr 2016, at 17:15, Brian E Carpenter = wrote: >=20 > On 06/04/2016 22:46, Stefano Previdi (sprevidi) wrote: >>=20 >>> On Apr 4, 2016, at 9:46 PM, Bob Hinden wrote: >>>=20 >>> Brian, >>>=20 >>>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 = that >>>> seems to come up repeatedly. >>>>=20 >>>> Are intermediate systems allowed to insert, change or delete = Extension Headers, >>>> apart from specified cases (routing headers, and HbH options that = may change >>>> en route)? And in the cases where changes are allowed, are = intermediate systems >>>> allowed to change the *length* of headers or option data? >>>=20 >>> Some relevant words from rfc2460bis Section 4. "IPv6 Extension = Header": >>>=20 >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >>=20 >>=20 >> in a controlled environment where boundaries are clearly identified = and with the appropriate security mechanisms, I don=E2=80=99t see why an = extension header can=E2=80=99t be inserted, as long as whatever you = insert is removed when existing the controlled domain. >>=20 >> As a matter of fact, it does happen already thanks to multiple = interoperable implementations (segment routing header, RH4) and I know = networks where this is being deployed. >>=20 >> Again, this is a controlled environment. >>=20 >> Stating that "Extension headers must never be inserted by any = node=E2=80=A6=E2=80=9D looks a bit extreme to me and I=E2=80=99d prefer = to =E2=80=9Crecommend=E2=80=9D not to insert rather than just ignoring = what happens in real networks and for real use cases. >=20 > I disagree. We're fixing some poor writing in 2460, which failed to = state what > seemed obvious at the time. Of course, there are no protocol police = and people > can do what they want in a closed domain, but if we relax the "must = not" we have > done nothing to fix the poor writing; we've actually made it worse. >=20 > I completely agree with Erik that there's a real probability of = leakage, which > is another reason for the "must not" approach. >=20 > Regards > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_2F5E828C-D383-4310-800D-02A62C39E385 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBYZNAAoJEL7aWKiYQt9267AQAKZjPreOPChmVYGnmIDGImy2 +5X1I6lyCRHtkTov+/PPmP/B7uqkdeoWT0oi6bi9MfxzidjbLrI+x4qsVicGgeE5 9mU3yAXZgg6HqjZFkQvf2DCpmOZg9iJ2WFHCW7F+afUeE5kv1BcwNWa1gmM8M1kA CwzFMGnsNvs53+9fDLqHqLhCnIsiW16esYcfgAgvzMDbhMv5Qt8u3Z6qLd91TNxA as84lreL/J/p8Ekm2+T0JC3VaE/FrdRWdedFrUehRNp+H1q+/3S+2qB3s6+zWNk5 TDR6rSsX+Nx+ZWBt5PocCr24oiy0/yJyTFQMa4N5z2WLBaJxnPI90KWeKlhcNT0x 1fgBXZrBxiyIE8wVJ+GTYGrK0w+bksDcRLb4nx1adChJuZuLy7aJgo9GB+L0rGE7 GRdbefED4Vfo084ofvsmadiSG2T1nAg9PbZq1JQs0MSbzVH4QB8XAwXbRxSZKbyG 9zLI4Nbdb6diZOBTuXKGHhhu0Wu7yydHrla6tZAfijTeUJmN5F3axub6/vR+OWXi 33DuiA75m6GNrMspkpg1sBVm0x101IgvOwPB8QZWiAgqFCxYi1RgfnZ0RnD7vd83 qHd99DfQszxH7z4LIpjpNL44HKQCvWlTijP8PLl2C8fJ6mO2BV3Kz/FhQrH4PBtw /ZxBSmOSlVIWZBP3jxe1 =fmNP -----END PGP SIGNATURE----- --Apple-Mail=_2F5E828C-D383-4310-800D-02A62C39E385-- From nobody Wed Apr 6 15:06:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF3512D101 for ; Wed, 6 Apr 2016 15:06:27 -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 kERmMdkog1yF for ; Wed, 6 Apr 2016 15:06:26 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [85.239.127.252]) (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 1343912D0A3 for ; Wed, 6 Apr 2016 15:06:25 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1anvYZ-003ZKM-5d; Thu, 07 Apr 2016 00:04:11 +0200 Date: Thu, 7 Apr 2016 00:04:11 +0200 From: David Lamparter To: David Lamparter Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160406220411.GC518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160406212048.GB518778@eidolon> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:06:27 -0000 On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote: > On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: > > On 4/6/16 12:18 PM, David Lamparter wrote: > > > On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: > > > Ok... easy comments/opinions first: > > > - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to > > > piggyback on NUD sounds great, though admittedly I haven't thought it > > > through looking for pitfalls. > > One issue compared to a dedicate probe is that a NUD (a unicast NS) of > > size X wouldn't necessarily result in a unicast NA that is also padded; > > perhaps one can add such behavior so that we can get the bidirectional > > probe in both directions. > > That might be (half of) a feature: if the MTU probe is a NS option, and > the target host does not support it, we still get a NA reply. That's > better than timing out waiting. The downside is that a NA without the > "MTU response" option doesn't mean that the host doesn't implement the > protocol -- the NA could be in response to something else. Obvious easy way: have the "ND NODEMTU" option described in draft sec. 5 mandatory on all NAs if the host implements the protocol; receipt of any NA without the option can then flag the sender as mtu-probe-incapable. (Not sure if the last paragraph of sec. 9.1 already implies the option MUST be put on all NAs and NSs? Certainly needs better wording.) -David > That said, I'd expect the probability of a host ignoring a new NS option > is much lower than it filtering out unknown new ICMP (sub)types or UDP > ports. If that reduces useless probing (or even waiting), I'm all for > it. > > (As I understand it, the draft in no case suggests waiting for the > probes to come back, so it's not much of an argument. Might still > reduce useless probe traffic?) From nobody Wed Apr 6 18:35:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3553612D801 for ; Wed, 6 Apr 2016 18:35:15 -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 JdlsaYEol0pf for ; Wed, 6 Apr 2016 18:35:10 -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 ED13612D66A for ; Wed, 6 Apr 2016 18:35:09 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id c20so44809484pfc.1 for ; Wed, 06 Apr 2016 18:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=caQAe/Vj7AyHXRYj7byaeF6F2rJoacqWpJ18CTY1+o8=; b=xSYiMLoCW+ISJ1t43tDV79CpzcgHD7Lj9NofC13lWuorSTZVN4Lfkk0IeNkPntYeYo IHI96xktoAFsyzgUj+GkTQ1YgSQ74HfaNtRZ6y+3FbHmRRK4XYCi0KkQr8jzpj9KY2Ks lM2iHXJUwKGH/YYOUKdUCQPoC2RHvDr3cWeRt980iwYAalfFs0hhKCysVmr+/a0h5JcS R039L3YkBVfqB7wYy2wvtHyq8GHii6cOrkN5aD3EDekjwjUxeImHvsvBAxyNzCubfaGl EV17568ZtVH4V5+cR3Jcejfm6Rp3txtevwxTStWNs02KMwvaVI33KVTLbCsQSLUqyCT4 BOVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=caQAe/Vj7AyHXRYj7byaeF6F2rJoacqWpJ18CTY1+o8=; b=HpTFdOIkiktOl4jSp0Vnjsb6b9i6t2TEOPyaWM2Yn6AyH4xSux7ojnV9KUxo0hhJdF aDoK2L1+tQt4ttrfFxGL25/Y2eaatCrK1ix9VYXe9fRJ7JEI5hDHpbeEcOTv2AbgqZQZ mv3QWfVVByBvy+dPGn8JHZjscHUbECsDmiRsZW7Gy4/Y8Re1eZ510XKF31kUZ41HQG9s b4PB3cEerZS21rfeunT4qC72JaAQQSb+ZkOYmCz3mNzTt4d+vOW/DmFjHxfPKTm2ygRD 77cPgBl541UW63Jx3UTbEnoJmSoPy80EhBVV+M55gQe23ZeJ8QI3TXn7Tm8CZIm67MDY uXuw== X-Gm-Message-State: AD7BkJJIa58WqlRyGrwAraADaKZmrUtyCDkVx/aXsDRV59YPCQS7j97wfdkNo2HIuTRc0A== X-Received: by 10.98.32.211 with SMTP id m80mr680399pfj.3.1459992909571; Wed, 06 Apr 2016 18:35:09 -0700 (PDT) Received: from ?IPv6:2406:e007:481c:1:28cc:dc4c:9703:6781? ([2406:e007:481c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 19sm7582070pfp.66.2016.04.06.18.35.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 18:35:07 -0700 (PDT) Subject: Re: rfc2460bis question To: otroan@employees.org, 6man WG References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5705B94E.4030704@gmail.com> Date: Thu, 7 Apr 2016 13:35:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 01:35:15 -0000 Hi Ole, On 07/04/2016 09:57, otroan@employees.org wrote: > Let me add on to the comments that I made during the meeting today: >=20 > There is a high bar to introduce changes to RFC2460. Changes are limite= d to those described in RFC6410 in addition to "Updated by" documents. >=20 > The proposed change presented today is: (note that is updated from what= is in the draft) >=20 > "Extension headers must never be deleted or changed in size by any n= ode on the path the packet takes. > The contents of an Extension header or Option in an Extension heade= r may be modified if this is permitted > by the definition of the Extension header or option." >=20 > There is no errata or updated-by document concerning this issue. Correct. But I was extremely surprised the first time I saw a proposal to= insert headers en route, since I had *always* read RFC2460 (and RFC1883) to imply that headers are only created by the source node. So I maintain that it is a drafting ambiguity (in RFC1883, actually) and therefore fair= game for clarification during the revisions allowed by RFC6410. If you really want to see it as an erratum, that would only take a few minutes. > It is not an unused feature, since the proposal is to add new text to R= FC2460. >=20 > As far as I am aware, there is no interoperability issue caused by the = current RFC2460 text. Yes there is, because it does not forbid insertion of an extension header= by a third party, whereas the interoperability model for extension headers is that b= oth the source and the destination need to understand the extension header (a "co= nsenting adults" model). An unknown inserted header will cause a lost packet: " If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet..." It might also cause PMTUD anomalies, too. > And as far as I can tell the proposed addition is unlikely to create in= teroperability issues either. >=20 > There is RFC4782, that allows for deletion of extension headers. That i= s an experimental RFC, and I'm unaware of what the conclusion from the ex= periment is. RFC791 allows the introduction of options in certain cases. >=20 > Resolving how header insertion or deletion of extension headers / optio= n is done is outside the scope of the changes we can make to 2460.=20 Obviously, I disagree. > Those considerations should be done in the protocol specification for t= hose proposed extension headers / options. >=20 > My current view on this, is that it would appear that like to have this= additional text, not to fix an existing problem, but to fend off what sh= ould be allowed in new protocol specifications. >=20 > As I said at the microphone, my position as chair is that by _default_,= the text in RFC2460 is left unchanged. Agreed, but when that text is actually interpreted differently by differe= nt people, which is clearly the case here, we are IMHO obliged to clarify it. Brian >> On 06 Apr 2016, at 17:15, Brian E Carpenter wrote: >> >> On 06/04/2016 22:46, Stefano Previdi (sprevidi) wrote: >>> >>>> On Apr 4, 2016, at 9:46 PM, Bob Hinden wrote:= >>>> >>>> Brian, >>>> >>>>> On Mar 28, 2016, at 9:30 PM, Brian E Carpenter wrote: >>>>> >>>>> Hi, >>>>> >>>>> rfc2460bis doesn't fix an ambiguity in interpretation of RFC 2460 t= hat >>>>> seems to come up repeatedly. >>>>> >>>>> Are intermediate systems allowed to insert, change or delete Extens= ion Headers, >>>>> apart from specified cases (routing headers, and HbH options that m= ay change >>>>> en route)? And in the cases where changes are allowed, are intermed= iate systems >>>>> allowed to change the *length* of headers or option data? >>>> >>>> Some relevant words from rfc2460bis Section 4. "IPv6 Extension Heade= r": >>>> >>>> Extension headers must never be inserted by any node other than the= >>>> source of the packet. IP Encapsulation must be used to meet any >>>> requirement for inserting headers, for example, as defined in >>>> [RFC2473]. >>> >>> >>> in a controlled environment where boundaries are clearly identified a= nd with the appropriate security mechanisms, I don=E2=80=99t see why an e= xtension header can=E2=80=99t be inserted, as long as whatever you insert= is removed when existing the controlled domain. >>> >>> As a matter of fact, it does happen already thanks to multiple intero= perable implementations (segment routing header, RH4) and I know networks= where this is being deployed. >>> >>> Again, this is a controlled environment. >>> >>> Stating that "Extension headers must never be inserted by any node=E2= =80=A6=E2=80=9D looks a bit extreme to me and I=E2=80=99d prefer to =E2=80= =9Crecommend=E2=80=9D not to insert rather than just ignoring what happen= s in real networks and for real use cases. >> >> I disagree. We're fixing some poor writing in 2460, which failed to st= ate what >> seemed obvious at the time. Of course, there are no protocol police an= d people >> can do what they want in a closed domain, but if we relax the "must no= t" we have >> done nothing to fix the poor writing; we've actually made it worse. >> >> I completely agree with Erik that there's a real probability of leakag= e, which >> is another reason for the "must not" approach. >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Wed Apr 6 18:49:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403E712D111 for ; Wed, 6 Apr 2016 18:49:48 -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 zIqi9HQUFtYY for ; Wed, 6 Apr 2016 18:49:45 -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 84B2812D181 for ; Wed, 6 Apr 2016 18:49:45 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c20so45046974pfc.1 for ; Wed, 06 Apr 2016 18:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8wGVlC+m1+a15kQc3axfCTe8T8lXB5W/TC5uWWoqN8w=; b=kbnxy3s0NZ+bmDFKm3MomrQX91McaumB7hu7MtTTZlegln87Et36objTWhAhEdXcEf InlfKgw4YR/MY0boRCw0p2Mx7K0sNfL4Ifm466AYUEEA2pq1lkZvMQkCey4ZMW73Pkd8 gO6xPazyZ3OR3YJE9JSfnU7w8YXd4NwRLKDdKCvm4B0fO9RJSWEnUYPgwAGXaGsGLLjd 2gIn4TKtO2i9iZe4XXqjqpKeZpr16VZPjysakr1JziVjWvmlIjXjnqb6VNnHo2P0yL+W dUylVXjsDE0vqOPVm0H1zFm9d+oPyPWgExRn/1zLPHrIFzuVQUznz5ZuWjMOfvomSzvP 0Bdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=8wGVlC+m1+a15kQc3axfCTe8T8lXB5W/TC5uWWoqN8w=; b=Q4YJ3frT13cN79WBTtKfstQ6VST7klWOZ4al41wBjFgcLdjf7zPgtaxnn7SWVfPAGE GTongdW21AZMUVC2CUUIcccxodJQVCgz5Twwto7O9Oa3sBs3RbCb9bx6OTw0mIorgv5D mIZqnz0YW+5AMJIIs7ufPPnsSHvEqT+0eng6Z17ipSiq0KhBbMeDL2qLFiceOEagy9Pm PlEsOpNGAeGmTI8XsZt6iqQ0HMraa54jBeJ54jvcpDmhOXSXhIamjWeFvYfgPMPrN2GW QuS6qXWb7bcqTwrU8G24dELkTTtI37ZbJodCE5X87E+L1/rOPlmzC8gsmaRctZQJxt0g 4M2g== X-Gm-Message-State: AD7BkJJu9NjjO75Q/IxI8qrtYr1I7Syo7JErdFJhtqg7FtucJbg5wl8ZCr2Uxban+m8SEQ== X-Received: by 10.98.67.67 with SMTP id q64mr808747pfa.44.1459993785076; Wed, 06 Apr 2016 18:49:45 -0700 (PDT) Received: from ?IPv6:2406:e007:481c:1:28cc:dc4c:9703:6781? ([2406:e007:481c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c9sm7646905pfd.24.2016.04.06.18.49.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 18:49:43 -0700 (PDT) Subject: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network To: "Mudric, Dusan (Dusan)" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5705BCBA.1030007@gmail.com> Date: Thu, 7 Apr 2016 13:49:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 01:49:48 -0000 Dusan, As far as I know we are only changing the A=L=0 case. If A=0, the prefix is not used for SLAAC at all, and if L=0 the prefix should not be added to the on-link prefix list. To be clear, L=0 doesn't mean the prefix is off-link. It just means "I'm not telling you it's on-link". So previously a host could simply ignore the PIO with A=L=0. But now it will be a useful next-hop router signal to the host, if addresses in that prefix have been assigned in another way, typically by DHCPv6. Does that make sense? Brian On 07/04/2016 07:40, Mudric, Dusan (Dusan) wrote: > Hi Brian, > > "Routing packets from hosts in a multi-prefix network" says: > A router > that advertises a prefix indicates that it is able to appropriately > route packets with source addresses within that prefix, regardless of > the setting of the L and A flags in the PIO. > > a host SHOULD NOT ignore a PIO simply because both L and > A flags are cleared; a router SHOULD be able to send such a PIO. > > A host SHOULD select > default routers for each prefix it is assigned an address in. > > The prefix list is used to find out if the destination address is on-link. > > If the router can route the packets from a host with the source address using L=0 prefix, theoretically off-link prefix can be used for SLAAC address. The problem is that L=0 prefix might be used on other links and if the host creates SLAAC address using L=0 prefix, the host will not be able to detect if the address is in use (DAD does not work between different router links). For that reason looks like L=0 prefix should not be used for SLAAC. If L=0 prefix is not use for SLAAC, there will be no source address with L=0 prefix and L=0 prefixes will not help host to find the first hop router. Consequently, hosts can ignore L=0 prefixes. > > Am I missing something about L=0 prefixes? > > Thanks, > Dusan. > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of ipv6-request@ietf.org > Sent: Monday, February 22, 2016 3:00 PM > To: ipv6@ietf.org > Subject: ipv6 Digest, Vol 142, Issue 35 > > Send ipv6 mailing list submissions to > ipv6@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=v1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e= > or, via email, send a message with subject or body 'help' to > ipv6-request@ietf.org > > You can reach the person managing the list at > ipv6-owner@ietf.org > > When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..." > > > Today's Topics: > > 1. I-D Action: draft-ietf-6man-multi-homed-host-05.txt > (internet-drafts@ietf.org) > 2. I-D Action: draft-ietf-6man-multi-homed-host-06.txt > (internet-drafts@ietf.org) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Feb 2016 10:32:52 -0800 > From: internet-drafts@ietf.org > To: > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-multi-homed-host-05.txt > Message-ID: <20160222183252.21102.35271.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > 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 : Routing packets from hosts in a multi-prefix network > Authors : Fred Baker > Brian Carpenter > Filename : draft-ietf-6man-multi-homed-host-05.txt > Pages : 13 > Date : 2016-02-22 > > Abstract: > This document describes expected IPv6 host behavior in a network that > has more than one prefix, each allocated by an upstream network that > implements BCP 38 ingress filtering, when the host has multiple > routers to choose from. It also applies to other scenarios such as > the usage of stateful firewalls that effectively act as address-based > filters. This host behavior may interact with source address > selection in a given implementation, but logically follows it. Given > that the network or host is, or appears to be, multihomed with > multiple provider-allocated addresses, that the host has elected to > use a source address in a given prefix, and that some but not all > neighboring routers are advertising that prefix in their Router > Advertisement Prefix Information Options, this document specifies to > which router a host should present its transmission. It updates RFC > 4861. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=PUqjeSn4pUOrtWVBsNjNailsRew5_ZvzDS1STFtTjDg&e= > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=Wqnr6PzhAWzCUOMlH0v2MPK87KyhpIfl1sDF96UNhP4&e= > > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=vPYONcimyGIvGJFl1Th6RV-kSJv79qPXaULdoyeOHEo&e= > > > 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: > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=DKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e= > > > > ------------------------------ > > Message: 2 > Date: Mon, 22 Feb 2016 10:55:30 -0800 > From: internet-drafts@ietf.org > To: > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-multi-homed-host-06.txt > Message-ID: <20160222185530.5662.71093.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > 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 : Routing packets from hosts in a multi-prefix network > Authors : Fred Baker > Brian Carpenter > Filename : draft-ietf-6man-multi-homed-host-06.txt > Pages : 13 > Date : 2016-02-22 > > Abstract: > This document describes expected IPv6 host behavior in a network that > has more than one prefix, each allocated by an upstream network that > implements BCP 38 ingress filtering, when the host has multiple > routers to choose from. It also applies to other scenarios such as > the usage of stateful firewalls that effectively act as address-based > filters. This host behavior may interact with source address > selection in a given implementation, but logically follows it. Given > that the network or host is, or appears to be, multihomed with > multiple provider-allocated addresses, that the host has elected to > use a source address in a given prefix, and that some but not all > neighboring routers are advertising that prefix in their Router > Advertisement Prefix Information Options, this document specifies to > which router a host should present its transmission. It updates RFC > 4861. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=PUqjeSn4pUOrtWVBsNjNailsRew5_ZvzDS1STFtTjDg&e= > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=lGfMGfWC7GV6V-rewMLkuXhmMv8qCGBHIxhCsFmkOnY&e= > > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=UFS97FbjEQDBE-DJBZaJF7J3umdmn66PA1Z4yc95xjU&e= > > > 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: > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=DKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e= > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ipv6 mailing list > ipv6@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=lhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=v1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e= > > > ------------------------------ > > End of ipv6 Digest, Vol 142, Issue 35 > ************************************* > From nobody Thu Apr 7 05:54:03 2016 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 32A1212D901; Thu, 7 Apr 2016 05:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rdnss-rfc6106bis-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407125359.19792.35352.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 05:53:59 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:53:59 -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 : IPv6 Router Advertisement Options for DNS Configuration Authors : Jaehoon Paul Jeong Soohong Daniel Park Luc Beloeil Syam Madanapalli Filename : draft-ietf-6man-rdnss-rfc6106bis-12.txt Pages : 17 Date : 2016-04-07 Abstract: This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document obsoletes RFC 6106 and allows a higher default value of the lifetime of the RA DNS options to avoid the frequent expiry of the options on links with a relatively high rate of packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rdnss-rfc6106bis-12 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 Thu Apr 7 05:59:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971912D8CD for ; Thu, 7 Apr 2016 05:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_HK_NAME_FM_MR_MRS=0.01] 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 7oqu0zHDS9bF for ; Thu, 7 Apr 2016 05:59:03 -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 C315F12D8E1 for ; Thu, 7 Apr 2016 05:59:03 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id i84so88963708ywc.2 for ; Thu, 07 Apr 2016 05:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZiMu4BKf0WMoo75c614CH/VCe7lpVpSF5OzYKame81o=; b=ov21zbm5pTylu42iw01b2kcsXz2vZvOFy7U+1JwSibYnIzV5wdzV2f4mWg0sJ85YgH jU0p8HC0DgvN2tZolQQxDh9RjTR71g7uTDPEilanRgQ5RuU/fMAripEuLwV/eOgHVL+f 1D1bAU23EZik8rSqkn/zTGshl205LyHr6jCExhGLevHmuwnNGe5eLM+TPDFgwesqwENr eyNJaqaMkX90i1ZezLPhegGtLnWltq5TM/0UUoOTut6JLmQEl5yr/xZcezIYBWWsgVxf L87HL31Tg9IiB6CA/21b1y+FJOzes2wDs/eP7efWIngFNEFAZYaHMq4j2nVb7GcpXUtr 2+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZiMu4BKf0WMoo75c614CH/VCe7lpVpSF5OzYKame81o=; b=A5b4nfR3E1sp59TG3rot7hsg4JdwQYcmtJCxI9ON7qUfZoAne3Yf5A7N8Z2OgGUQSA tDxbfeoEw3D4BX4jbi0u7a9rpvKew4AdiiY4dAHbvrBV5JuaHOk4TugnfcMCpEaWcerb A8wE0We73cSHzjC9nVcXZMsyP5qazxSYNyAbks+tmXWouY94wsyDszSOSMZUet0miyxY A4xALT1IXuE29chdOceop9H03GtT1Pft/UQXgbi0hTRogRkyhWl+Ztlw7dHEZ1eifaz5 mLVty340+U1A2PspEK25ctP0lGdIc1ObO4BWkCS/4xAmna/0+bH2gb6sRWiP/O/CL5DD /lWg== X-Gm-Message-State: AD7BkJJAaXXpkhh/7w5C+FjxZLUE2N5QGZOKxWbjPQdeY6R11YWU8sdHdhzvxaw5SQohNZmbvfQEfiJjAQS85g== X-Received: by 10.129.148.2 with SMTP id l2mr1373320ywg.298.1460033942859; Thu, 07 Apr 2016 05:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.4.22 with HTTP; Thu, 7 Apr 2016 05:58:33 -0700 (PDT) In-Reply-To: References: <6AC58C26-01B6-4C16-851F-0C1228CDD2AF@employees.org> <73EEC8CE-EDC8-45FC-AE4F-F390F965304F@employees.org> <56EA8D27.3060704@forthnet.gr> <56EAAD36.20901@si6networks.com> <1C086B9C-C1FD-4C53-823D-0A58A2DDE607@employees.org> <56EBCC78.6030206@forthnet.gr> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 7 Apr 2016 09:58:33 -0300 Message-ID: Subject: Re: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis To: Fernando Gont , Ole Troan Content-Type: multipart/alternative; boundary=94eb2c07b51686356b052fe4a40f Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:59:06 -0000 --94eb2c07b51686356b052fe4a40f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fernando and Ole, I believe that I have addresses all of the comments from 6man WG with the following revision: https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-12 Could you review it and make it forward from WGLC? Thanks. Paul On Mon, Mar 21, 2016 at 9:41 PM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Tassos, > Thanks for your comments. > I put my answers inline below with "=3D>". > > On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzithomaoglou < > achatz@forthnet.gr> wrote: > >> otroan@employees.org wrote on 18/3/2016 10:44 =CF=80=CE=BC: >> > Paul, >> > >> >> I took a look at the draft of >> https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt. >> >> >> >> From Case 4 (all RA flags are set, that is, M=3D1, A=3D1, O=3D1) in A= .2.2, >> >> Fedora 21 and Centos 7 let the DNS of the RAs have higher priority, b= ut >> >> MAC OS-X lets the DNS of DHCPv6 have higher priority. >> >> In the current implementations, there is no consistency to handle >> RDNSS options from RA and DHCPv6. >> >> >> >> Thus, I suggest the following text with the preference for DHCPv6 >> because >> >> there is no a stong rationale, but there must be somehow a guidance t= o >> handle this case: >> >> >> >> The DNS options from Router Advertisements and DHCP SHOULD be >> >> stored into the DNS Repository and Resolver Repository so that >> >> information from DHCP appears there first and therefore takes >> >> precedence. This document recommends that the DNS information >> >> from DHCP should have higher priority than that of RA for >> >> DNS queries to handle the case of the coexistence of RA and DHCP. >> >> >> >> If anyone does not object this text, I will revise the draft with it. >> > I would prefer this document focused solely on specifying the RA DNS >> options, and did not stray into more general configuration complexity. >> > >> > getting information from multiple sources is a more general problem in >> IPv6, and I don't want us to "solve" (if that's possible) that problem i= n >> this document. >> > >> > "the less you say, the less likely you are to say something wrong". ;-= ) >> > >> > Best regards, >> > Ole >> > >> So we leave the DHCP/RA preference choice to the implementers? >> > =3D> Since this issue is not standardized yet, we will leave it to the > implementers. > > >> >> Something else that doesn't seem ok to me. >> > However, the security of these RA options for DNS configuration does >> > not affect ND protocol security [RFC4861]. This is because learnin= g >> > DNS information via the RA options cannot be worse than learning ba= d >> > router information via the RA options. Therefore, the vulnerabilit= y >> > of ND is not worse and is a subset of the attacks that any node >> > attached to a LAN can do. >> >> I do not agree with the statement "learning DNS information via the RA >> options cannot be worse than learning bad router information via the RA >> options". >> I believe that bad router exploitation is at a local level, while bad >> DNS exploitation is at a global level. So while the origin of the attack >> can be the same (a node attached to the LAN), the easiness/effectiveness >> of the attack can be greater in the case of DNS. >> >> =3D> By the invalid RDNSS addresses, the DNS query messages from > IPv6 hosts can be generated and sent toward those addresses over th= e > link > to which the hosts are attached. However, in the aspect of IPv6 > hosts, > the vulnerability level for ND service seems still the same. > > >> >> Also, i have spotted a few more places for further clarification: >> >> > Step (c): For each RDNSS address, if it already exists in the DNS >> > Server List, then... >> >> Step (c): For each RDNSS address, if it already exists in the DNS >> Server List and the RDNSS option's Lifetime field is not set to >> zero, then.... >> >> =3D> This clarification looks good. I will reflect this in the revision= . > > >> > Step (d): For each RDNSS address, if it does not exist in the DNS >> > Server List, register the RDNSS address and Lifetime with the DN= S >> > Server List and then insert the RDNSS address in front of the >> > Resolver Repository. >> >> ...and then insert the RDNSS address as the first one in the Resolver >> Repository. >> >> =3D> This clarification looks good, too. I will reflect this in the > revision. > > > Thanks. > > Best Regards, > Paul > > >> -- >> Tassos >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > > -- > =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 > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --=20 =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 Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --94eb2c07b51686356b052fe4a40f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fernando and Ole,
I believe that I have addresses a= ll of the comments from 6man WG with the following revision:
<= div>
Could you review it and make it forward from WGLC?
=

Thanks.

Paul


On Mon, Mar 21= , 2016 at 9:41 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com= > wrote:
Hi Tassos,
Than= ks for your comments.
I put my answers inline below with "= =3D>".

On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzithomaoglou <achatz= @forthnet.gr> wrote:
otroan@employees.org wr= ote on 18/3/2016 10:44 =CF=80=CE=BC:
> Paul,
>
>> I took a look at the draft of https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt= .
>>
>> From Case 4 (all RA flags are set, that is, M=3D1, A=3D1, O=3D1) i= n A.2.2,
>> Fedora 21 and Centos 7 let the DNS of the RAs have higher priority= , but
>> MAC OS-X lets the DNS of DHCPv6 have higher priority.
>> In the current implementations, there is no consistency to handle = RDNSS options from RA and DHCPv6.
>>
>> Thus, I suggest the following text with the preference for DHCPv6 = because
>> there is no a stong rationale, but there must be somehow a guidanc= e to handle this case:
>>
>> The DNS options from Router Advertisements and DHCP SHOULD be
>> stored into the DNS Repository and Resolver Repository so that
>> information from DHCP appears there first and therefore takes
>> precedence. This document recommends that the DNS information
>> from DHCP should have higher priority than that of RA for
>> DNS queries to handle the case of the coexistence of RA and DHCP.<= br> >>
>> If anyone does not object this text, I will revise the draft with = it.
> I would prefer this document focused solely on specifying the RA DNS o= ptions, and did not stray into more general configuration complexity.
>
> getting information from multiple sources is a more general problem in= IPv6, and I don't want us to "solve" (if that's possible= ) that problem in this document.
>
> "the less you say, the less likely you are to say something wrong= ". ;-)
>
> Best regards,
> Ole
>
So we leave the DHCP/RA preference choice to the implementers?<= br>
=C2=A0=3D> Since this issue =C2=A0is not sta= ndardized yet, we will leave it to the implementers.



Something else that doesn't seem ok to me.
> However, the security of these RA options for DNS configuration does >=C2=A0 =C2=A0 not affect ND protocol security [RFC4861].=C2=A0 This is = because learning
>=C2=A0 =C2=A0 DNS information via the RA options cannot be worse than l= earning bad
>=C2=A0 =C2=A0 router information via the RA options.=C2=A0 Therefore, t= he vulnerability
>=C2=A0 =C2=A0 of ND is not worse and is a subset of the attacks that an= y node
>=C2=A0 =C2=A0 attached to a LAN can do.

I do not agree with the statement "learning DNS information via the RA=
options cannot be worse than learning bad router information via the RA
options".
I believe that bad router exploitation is at a local level, while bad
DNS exploitation is at a global level. So while the origin of the attack can be the same (a node attached to the LAN), the easiness/effectiveness of the attack can be greater in the case of DNS.

=C2=A0=3D> By the invalid RDNSS addresses, = the DNS query messages from
=C2=A0 =C2=A0 =C2=A0 IPv6 hosts can b= e generated and sent toward those addresses over the link
=C2=A0 = =C2=A0 =C2=A0 to which the hosts are attached. However, in the aspect of IP= v6 hosts,=C2=A0
=C2=A0 =C2=A0 =C2=A0 the vulnerability level for = ND service seems still the same. =C2=A0 =C2=A0 =C2=A0
=C2= =A0=C2=A0

Also, i have spotted a few more places for further clarification:

> Step (c): For each RDNSS address, if it already exists in the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List, then...

Step (c): For each RDNSS address, if it already exists in the DNS
=C2=A0 =C2=A0 =C2=A0 Server List and the RDNSS option's Lifetime field = is not set to
zero, then....

=C2=A0=3D> This clarification looks good. I= will reflect this in the revision.
=C2=A0
> Step (d): For each RDNSS address, if it does not exist in the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List, register the RDNSS address and = Lifetime with the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List and then insert the RDNSS addres= s in front of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Resolver Repository.

...and then insert the RDNSS address as the first one in the Resolver
Repository.

=C2=A0 =3D> This clarification looks good, = too. I will reflect this in the revision.=C2=A0

=C2=A0Thanks.

=C2=A0Best Regards,
=C2=A0Paul


--
Tassos


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



=
--
=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
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
D= epartment of Software
Sungkyunkwan University
Office: +82-31-299-4957=
Email: = jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal= Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
=



--
=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
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,= =C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab= .skku.edu/people-jaehoon-jeong.php
--94eb2c07b51686356b052fe4a40f-- From nobody Thu Apr 7 06:27:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE54A12D840 for ; Thu, 7 Apr 2016 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 JV6j45XE8nr8 for ; Thu, 7 Apr 2016 06:27:12 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1D912D841 for ; Thu, 7 Apr 2016 06:27:12 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AC422D789D; Thu, 7 Apr 2016 06:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=rK2KdxnJMbeVjlxXTMy9mkrYEcQ=; b= BpRadVpzoDp8WyMOtYr3LClt6YaXHU/sAiIDvhrl3UAT98Hwus6pvih4kA9IE4eI G13umZF3F09RG6PAEnYktNC8FeeUoev+sj3mUbtZT/d+CApB0cY1qbvoJP+noIBC xSbhvcx/M4Qm71YVRpKax+26TcPMAPtMfgxCwN7Z7YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=V4mR6jFLV+RYsfusLndfroPLdO RSB77ZmTNH6+g0GpUUt4Q/bsHsNNWrOLrkI8tbcPn76OmUUEqWQKn5Q2zz9c0EzH nXAQxa7Vzb7PB9mJ/M50ZpfEwm5P/Mubq5pPHyFgMsavyvldevoDOJhvEcZ2GtIT unrspcVaFdt0sr2/Q= Received: from h.hanazo.no (dhcp-b1da.meeting.ietf.org [31.133.177.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 20F3ED7882; Thu, 7 Apr 2016 06:27:10 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 81A5D1415945; Thu, 7 Apr 2016 10:27:07 -0300 (ART) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2CE2595D-DCA4-4A08-92DB-B169083EA304"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160406220411.GC518778@eidolon> Date: Thu, 7 Apr 2016 10:27:07 -0300 Message-Id: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:27:14 -0000 --Apple-Mail=_2CE2595D-DCA4-4A08-92DB-B169083EA304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In general I'd prefer that we reuse existing mechanisms for path mtu = discovery, and not invent new ones purely for the case of two directly = connected neighbors. Could we make this work by adding the RFC4861 MTU option to NS/NA = messages, and require that PLMTUD probing is used to verify the end to = end MTU. Then the mechanism used is the same for directly connected neighbors and = off-link neighbors (apart from the initial discovery). If we were to invent new probing mechanisms, I would hope we did so = under the PLMTUD (4821) umbrella. Best regards, Ole > On 06 Apr 2016, at 19:04, David Lamparter wrote: >=20 > On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote: >> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: >>> On 4/6/16 12:18 PM, David Lamparter wrote: >>>> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: >>>> Ok... easy comments/opinions first: >>>> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion = to >>>> piggyback on NUD sounds great, though admittedly I haven't = thought it >>>> through looking for pitfalls. >>> One issue compared to a dedicate probe is that a NUD (a unicast NS) = of >>> size X wouldn't necessarily result in a unicast NA that is also = padded; >>> perhaps one can add such behavior so that we can get the = bidirectional >>> probe in both directions. >>=20 >> That might be (half of) a feature: if the MTU probe is a NS option, = and >> the target host does not support it, we still get a NA reply. That's >> better than timing out waiting. The downside is that a NA without = the >> "MTU response" option doesn't mean that the host doesn't implement = the >> protocol -- the NA could be in response to something else. >=20 > Obvious easy way: have the "ND NODEMTU" option described in draft sec. = 5 > mandatory on all NAs if the host implements the protocol; receipt of = any > NA without the option can then flag the sender as mtu-probe-incapable. >=20 > (Not sure if the last paragraph of sec. 9.1 already implies the option > MUST be put on all NAs and NSs? Certainly needs better wording.) >=20 > -David >=20 >> That said, I'd expect the probability of a host ignoring a new NS = option >> is much lower than it filtering out unknown new ICMP (sub)types or = UDP >> ports. If that reduces useless probing (or even waiting), I'm all = for >> it. >>=20 >> (As I understand it, the draft in no case suggests waiting for the >> probes to come back, so it's not much of an argument. Might still >> reduce useless probe traffic?) >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_2CE2595D-DCA4-4A08-92DB-B169083EA304 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBmArAAoJEL7aWKiYQt92NpgQAK6W/0AEQJ77i78g0xNqqR/J KwxZfJtdc6syt4dHoEAwgP4WLcEuzjH+NdjJoM6M2EFsJRYwwVCrTV8SmdXh0PFs sSEQf2lqscqxm4us6shL4DTV294MTiKlKBGe43+hv5rXw2EfwWYdC/w15RQAewuC WnMTDyl0M30VtF0PgCraKdNCd099BsIGLRrrehqYbAOWUQgZkFxgUa6h3Mvwq8af F1JNLOF00JFx5EbBVf7vECjtW+canjmjj/D/EIihWyEfBqSnrRhH0ivGDC30whLJ Nt3gr7zHQ4Zs8Xp2VRjHCglGOysXxZYJo0MXK3snw7LBdj+lwsmCSyGtYSLjUjNC TGmDKxEUVvtiUpiufdPIvLjsBL9MCxzE6VDWbeJ13VZfCQh2SenUJksEPzQnKwIX n849moi3l/fm+GX/+FJyhuYWUU1d99OUwMgTsnGoKJY3+OKrFroMXdHi+G+RMbNr sgX1YNqh6rbSn6iCU+p4YYICPtP0KXBw2Wlmj4+kUt5ww0/XL7mjR2rHxBLxXC+r iS5TUFPk1G6dX/dlb4t897E6kNHJhPDqjP4/w7BHOa2iyMwzDynnPejVNp6QfaU7 wo5akWxkpzq3RxmBYHV0Fqq8i87bq9ltGOibQauJHZKgZGAJdJf4GrkLUegU59j4 aQpv54rcR+uWs66j+/EI =kK0j -----END PGP SIGNATURE----- --Apple-Mail=_2CE2595D-DCA4-4A08-92DB-B169083EA304-- From nobody Thu Apr 7 06:46:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1012D501 for ; Thu, 7 Apr 2016 06:46: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] 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 FaCerxMZV75z for ; Thu, 7 Apr 2016 06:46:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD212D1B0 for ; Thu, 7 Apr 2016 06:46:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aoAGX-0000FOC; Thu, 7 Apr 2016 15:46:33 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: draft-van-beijnum-multi-mtu-05.txt From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> In-reply-to: Your message of "Thu, 7 Apr 2016 10:27:07 -0300 ." Date: Thu, 07 Apr 2016 15:46:31 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:46:41 -0000 >In general I'd prefer that we reuse existing mechanisms for path mtu >discovery, and not invent new ones purely for the case of two directly >connected neighbors. I think making them the same is likely to be sub-optimal. The nice thing about the current proposal is that the MTU is verified before any application traffic is sent. This not going to fly on the internet as a whole. There is no way that busy DNS servers are first going to send ping traffic back to the client before sending the DNS reply. On the other hand, the model behind existing PMTU discovery is reactive. The loss of a data packet triggers downward adjustment of the estimated PMTU. In the context of ethernet jumbograms, such a reactive approach is likely to be unattractive to operators. So I'd say that from a PMTU perspective directly connected neighbors are quite different from the internet as a whole. From nobody Thu Apr 7 07:02:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3824212D0CF for ; Thu, 7 Apr 2016 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 RIctA4gvxd8T for ; Thu, 7 Apr 2016 07:02:08 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB0012D1D1 for ; Thu, 7 Apr 2016 07:02:01 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 65605D789E; Thu, 7 Apr 2016 07:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ryHYBd9LhKh8am4+Yufgz+CHwW8=; b= n5FbWUGBC6tlul2lZgmMWz+OXku7VDz0vHqQvJ2JI580xz2GXvZ4XpRapy5QURT7 37jM00tsglndwdUjCQxUSllARj/pG8tfCJJl2ct3inJjxx7JPHlz+/+puLzsqIAI VIpIgNpjkazn+EUjxi2jfwTdfbInwLIuU/0nYLS6/Ug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=H7vfja+h/dHDxaMW+Bt7gEvjyX UwCLzZ/i8rV5k1w3rVMQsu59oTrNIR6e/8iFLnVNAToDmq9eLZR4gGKK/sNAtNpl ikLFLrsMdE2RYCAXR5MR/2b8cRmLw/koz9czNYO7NfGA82voUMJFGPSi5LORtmoL 7+x7kCkgEQzZCeHxk= Received: from h.hanazo.no (dhcp-b1da.meeting.ietf.org [31.133.177.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 06334D789D; Thu, 7 Apr 2016 07:02:01 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A41661415E61; Thu, 7 Apr 2016 11:01:57 -0300 (ART) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B1EC309C-CB17-49E0-8993-085390560E51"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <5705B94E.4030704@gmail.com> Date: Thu, 7 Apr 2016 11:01:56 -0300 Message-Id: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:02:15 -0000 --Apple-Mail=_B1EC309C-CB17-49E0-8993-085390560E51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Brian, Thank you for your comments. >> Let me add on to the comments that I made during the meeting today: >>=20 >> There is a high bar to introduce changes to RFC2460. Changes are = limited to those described in RFC6410 in addition to "Updated by" = documents. >>=20 >> The proposed change presented today is: (note that is updated from = what is in the draft) >>=20 >> "Extension headers must never be deleted or changed in size by any = node on the path the packet takes. >> The contents of an Extension header or Option in an Extension = header may be modified if this is permitted >> by the definition of the Extension header or option." >>=20 >> There is no errata or updated-by document concerning this issue. >=20 > Correct. But I was extremely surprised the first time I saw a proposal = to > insert headers en route, since I had *always* read RFC2460 (and = RFC1883) > to imply that headers are only created by the source node. So I = maintain > that it is a drafting ambiguity (in RFC1883, actually) and therefore = fair game > for clarification during the revisions allowed by RFC6410. >=20 > If you really want to see it as an erratum, that would only take a few > minutes. I don't think you were alone about being surprised by those proposals. It is an ambiguity that we have lived with in the Internet since RFC791 = though. >> It is not an unused feature, since the proposal is to add new text to = RFC2460. >>=20 >> As far as I am aware, there is no interoperability issue caused by = the current RFC2460 text. >=20 > Yes there is, because it does not forbid insertion of an extension = header by a third > party, whereas the interoperability model for extension headers is = that both the > source and the destination need to understand the extension header (a = "consenting > adults" model). An unknown inserted header will cause a lost packet: >=20 > " If, as a result of processing a header, a node is required to = proceed > to the next header but the Next Header value in the current header = is > unrecognized by the node, it should discard the packet and send an > ICMP Parameter Problem message to the source of the packet..." What I meant was that there is no currently known interoperability = problem with existing implementation or existing protocol = specifications. I agree with you that there are many issues if a future specification = would require to do header injection. We could deal with those issues if = or when those proposals where made. > It might also cause PMTUD anomalies, too. Indeed, as far I can see it wouldn't only create anomalies but it would = break it. >> And as far as I can tell the proposed addition is unlikely to create = interoperability issues either. >>=20 >> There is RFC4782, that allows for deletion of extension headers. That = is an experimental RFC, and I'm unaware of what the conclusion from the = experiment is. RFC791 allows the introduction of options in certain = cases. >>=20 >> Resolving how header insertion or deletion of extension headers / = option is done is outside the scope of the changes we can make to 2460. >=20 > Obviously, I disagree. I do understand your concern. We can argue if that concern should be = tackled while taking 2460 to IS, or if it should be tackled whenever a = proposal to do it comes up. >> Those considerations should be done in the protocol specification for = those proposed extension headers / options. >>=20 >> My current view on this, is that it would appear that like to have = this additional text, not to fix an existing problem, but to fend off = what should be allowed in new protocol specifications. >>=20 >> As I said at the microphone, my position as chair is that by = _default_, the text in RFC2460 is left unchanged. >=20 > Agreed, but when that text is actually interpreted differently by = different people, > which is clearly the case here, we are IMHO obliged to clarify it. I'm not sure that is true. Some level of ambiguity in specifications is = good. Ambiguity equals freedom and room for innovation. In any case, if there was clear a consensus about what to say, this = would be simpler. If there isn't, then saying nothing is the safer = option, rather than saying the wrong thing. Best regards, Ole --Apple-Mail=_B1EC309C-CB17-49E0-8993-085390560E51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBmhVAAoJEL7aWKiYQt92ZNgP/3VWTO6ljxYPWn7DktzFDMVu 3Idy8s4rivr3DQXJsUfAA4vZRu/iVs8ewjzUfL9M4BVCwTwBWID4sTBNJ+WY6xrt xs1RyUvAn1NBEaUwxGcts3pGETIMuV7oLS7WsW/NjYYnZjNrLHOg7PP9OELUj70o /ah85iQYchgJEUdPesqilY0z1f9ZRZ+lWua4Adzx+pbi2M+gHrbu7JVmLggARe1V DLZmwAqQXIyS9tGfsu/f0X7q8nnkkZ6nTgi5M6CYN6ZfRuZTQoCBVqJzc2jQBgBf As2ruox6i5Wcmhub+jRZ2RkzkeF7pBhh0axeWmc0vlfE3+pbrqw1YmFabjmCauwA Pp3d9LvG139l7D6yw+hOjST2jqDnKzwTvk5eK9xYRtql40cpzFguhcLgAKv95wVH ZGBiSFwBeGSPmqmn8hsjt2KqsV4JWnvYxk0h5OUB1793xdVBYAPma8KcKQ6y8eCm zdIXmR2rWfOh0XGaQqrxvA2Xfbk+hf0T63ccsDzkNW0NBabqVk+/5szlY3I88lkj UOvU5Y2MOh9ydIepAT6zbVioIln8uMuA0o4jZFr3ypdv39dUcJ026b46NE1q5MQz TbDZbbcRT5iM+yPYE0hskpEhlDh6wkpk2xoZAleSjksP478aY4gGpQiRycJ7XukS n7XaV6owG2KpkaD+fQOM =E43j -----END PGP SIGNATURE----- --Apple-Mail=_B1EC309C-CB17-49E0-8993-085390560E51-- From nobody Thu Apr 7 09:30:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B312D145 for ; Thu, 7 Apr 2016 09:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 VGmSpMyDyAlu for ; Thu, 7 Apr 2016 09:29:58 -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 803AC12D139 for ; Thu, 7 Apr 2016 09:29:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9ED7E2009E for ; Thu, 7 Apr 2016 12:33:33 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A916F63755 for ; Thu, 7 Apr 2016 12:29:57 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: draft-van-beijnum-multi-mtu-05.txt In-Reply-To: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 16:30:00 -0000 --=-=-= Content-Type: text/plain otroan@employees.org wrote: > In general I'd prefer that we reuse existing mechanisms for path mtu > discovery, and not invent new ones purely for the case of two directly > connected neighbors. > Could we make this work by adding the RFC4861 MTU option to NS/NA > messages, and require that PLMTUD probing is used to verify the end to > end MTU. Yes, but plmtud can only be provided as a service to applications when they use TCP or SCTP. It can't find bigger UDP paths at present: that would have to be built in to the application. But, the kernel can provide the service for UDP users by doing the discovery in NUD.... Basically we can run the plpmtud mechanism with NUD in the kernel. There is another use for this MTU option: it appears that it is sometimes possible to run both 802.15.4-2012 (the 127 byte version) and 802.15.4g (the 2K or something byte version) on the same radios. ("802.15.4-2015" includes 802.15.4g, btw, thus the need for a year to be precise) A 15.4g MAC ought to be able to speak to a -2012 MAC by using all of our 6lowpan mechanisms, but two 15.4g would like to discover that they don't need to fragment. I had *assumed* that the RA MTU option could be used for this, and was surprised when I read that it wasn't specified for this.... So I'm in favour of having this ND option defined; and I care not if it's a new number or reuses the RA number. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwaLA4CLcPvd0N1lAQJStQf8DcbynuM8ZixKtsgbWTSS9BaR07j/CzBK W5/wI18M6t8ngGzcfogW6rzM7A52J7RybjgmryCYXHMflKBBpr9wIzwOA3pU6u/m cNgDPkEvv8wrLW4CEhaB9c26870oxhS6vIxcc8ED2ZNPYd6H9jPm2AjglyY8yiYA bsZNttiS+wCeZBzQaIonoyqSx5doI7X4Hsw/yecENz9VeOhCkX7LSpGHz+6AjG1D T77BUSFZBSeJG1HBgqSYr0a9aoZgBPZ8xnqZl8qFKmoTx3BPotp7KT9uBl8UMygl 0e5ELO43pKYZJBCnaw587kTkc6LQUW9vkjY64sS5tY8Xtk8BVtQ0gA== =d4rW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 7 10:27:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5950612D1A3 for ; Thu, 7 Apr 2016 10:27:32 -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 rXk-kJKJaktl for ; Thu, 7 Apr 2016 10:27:28 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 3294C12D1DE for ; Thu, 7 Apr 2016 10:27:28 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id ui10so76592042igc.1 for ; Thu, 07 Apr 2016 10:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=4RYzXEOJ+VZy6Va6V3UTRij4vowQufkP9VnLvmt4tcI=; b=dZc6xhMkh70QXhiXC5xWYh1JV5bu4T6p4coGdMPGTJDjejso8XSmT7t7+S2XWmVoZ4 R6PBgoJzzobALuOVEhXr+7gA19JP+TsYjKHHhfmh63IAdV1SWbDqGni4NgirzzgglSFD 24Wk0vT0pOwRcMHe7PqT9uQsT6TTPJXF8gnQtMVTcMMXE6Dbo9yiK9faD9uFhPNMHGAr nWmQ1bVZyI8NNaafkLhmUQMGtZ9/0ZJUfPNTKHUDeKMXgcKB5jUg7qMyPDaVwiVzTDF1 17P43fDcMxfNOhKGIQf3yCi9FzM3XzD+09g2byxj5YcF5WcK3Ji5LEgV9WcQwQ7iCyQW SQeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4RYzXEOJ+VZy6Va6V3UTRij4vowQufkP9VnLvmt4tcI=; b=UV1SScJpHY9ZJLM2CfzR7B20989w1BC3j4d/W9PJmlqXI1LjkZx8a48R6FRYvAugIj io3NaoI7ge667T+wpJpAowEayVoE40bNVLV4RxHb2+elphO2hwDNKqb+aAvZEcMROZO7 GHmNOqlHSvscppV5ZQVi2G7dCrvvYa+6UXs2v5ur99uH5ebsT/5hZfFeAN5BMnC+/xDg l14nTsIM3IGKYM48Evqh9/+x8/WF/7cQMp6z4r4j3ZRMLJ5k3F4dWUpMKKaPwviIlxaI WiMOoedOhvUVfbDAyO+8+jOjqROYoP9IShiv6bK099m+bAbYUjhvXCrsdiMW26P7anaI 0oJA== X-Gm-Message-State: AD7BkJL8XFAOqBfZYTDgHLs9iyPlVBeG2Qdm2cGoA4/a7+XSPkNr/RzxeTlHdJOUMYa5sfaN7K4S3FPvitjNTg== MIME-Version: 1.0 X-Received: by 10.50.30.41 with SMTP id p9mr4433684igh.86.1460050047551; Thu, 07 Apr 2016 10:27:27 -0700 (PDT) Sender: fgont.mobile@gmail.com Received: by 10.36.110.13 with HTTP; Thu, 7 Apr 2016 10:27:27 -0700 (PDT) Received: by 10.36.110.13 with HTTP; Thu, 7 Apr 2016 10:27:27 -0700 (PDT) In-Reply-To: References: <6AC58C26-01B6-4C16-851F-0C1228CDD2AF@employees.org> <73EEC8CE-EDC8-45FC-AE4F-F390F965304F@employees.org> <56EA8D27.3060704@forthnet.gr> <56EAAD36.20901@si6networks.com> <1C086B9C-C1FD-4C53-823D-0A58A2DDE607@employees.org> <56EBCC78.6030206@forthnet.gr> Date: Thu, 7 Apr 2016 19:27:27 +0200 X-Google-Sender-Auth: Zg_WMia3-Z2zIY-UIRatXC_h2pY Message-ID: Subject: Re: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis From: Fernando Gont To: "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary=047d7bdc1b687051d7052fe864a2 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:27:32 -0000 --047d7bdc1b687051d7052fe864a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. I will be reviewing evrything and preparing the proto writeup no later than tomorrow. Thanks! Fernando El 7/4/2016 9:59, "Mr. Jaehoon Paul Jeong" escribi=C3=B3: > Hi Fernando and Ole, > I believe that I have addresses all of the comments from 6man WG with the > following revision: > https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-12 > > Could you review it and make it forward from WGLC? > > Thanks. > > Paul > > > On Mon, Mar 21, 2016 at 9:41 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> Hi Tassos, >> Thanks for your comments. >> I put my answers inline below with "=3D>". >> >> On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzithomaoglou < >> achatz@forthnet.gr> wrote: >> >>> otroan@employees.org wrote on 18/3/2016 10:44 =CF=80=CE=BC: >>> > Paul, >>> > >>> >> I took a look at the draft of >>> https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt. >>> >> >>> >> From Case 4 (all RA flags are set, that is, M=3D1, A=3D1, O=3D1) in = A.2.2, >>> >> Fedora 21 and Centos 7 let the DNS of the RAs have higher priority, >>> but >>> >> MAC OS-X lets the DNS of DHCPv6 have higher priority. >>> >> In the current implementations, there is no consistency to handle >>> RDNSS options from RA and DHCPv6. >>> >> >>> >> Thus, I suggest the following text with the preference for DHCPv6 >>> because >>> >> there is no a stong rationale, but there must be somehow a guidance >>> to handle this case: >>> >> >>> >> The DNS options from Router Advertisements and DHCP SHOULD be >>> >> stored into the DNS Repository and Resolver Repository so that >>> >> information from DHCP appears there first and therefore takes >>> >> precedence. This document recommends that the DNS information >>> >> from DHCP should have higher priority than that of RA for >>> >> DNS queries to handle the case of the coexistence of RA and DHCP. >>> >> >>> >> If anyone does not object this text, I will revise the draft with it= . >>> > I would prefer this document focused solely on specifying the RA DNS >>> options, and did not stray into more general configuration complexity. >>> > >>> > getting information from multiple sources is a more general problem i= n >>> IPv6, and I don't want us to "solve" (if that's possible) that problem = in >>> this document. >>> > >>> > "the less you say, the less likely you are to say something wrong". ;= -) >>> > >>> > Best regards, >>> > Ole >>> > >>> So we leave the DHCP/RA preference choice to the implementers? >>> >> =3D> Since this issue is not standardized yet, we will leave it to the >> implementers. >> >> >>> >>> Something else that doesn't seem ok to me. >>> > However, the security of these RA options for DNS configuration does >>> > not affect ND protocol security [RFC4861]. This is because learni= ng >>> > DNS information via the RA options cannot be worse than learning b= ad >>> > router information via the RA options. Therefore, the vulnerabili= ty >>> > of ND is not worse and is a subset of the attacks that any node >>> > attached to a LAN can do. >>> >>> I do not agree with the statement "learning DNS information via the RA >>> options cannot be worse than learning bad router information via the RA >>> options". >>> I believe that bad router exploitation is at a local level, while bad >>> DNS exploitation is at a global level. So while the origin of the attac= k >>> can be the same (a node attached to the LAN), the easiness/effectivenes= s >>> of the attack can be greater in the case of DNS. >>> >>> =3D> By the invalid RDNSS addresses, the DNS query messages from >> IPv6 hosts can be generated and sent toward those addresses over >> the link >> to which the hosts are attached. However, in the aspect of IPv6 >> hosts, >> the vulnerability level for ND service seems still the same. >> >> >>> >>> Also, i have spotted a few more places for further clarification: >>> >>> > Step (c): For each RDNSS address, if it already exists in the DNS >>> > Server List, then... >>> >>> Step (c): For each RDNSS address, if it already exists in the DNS >>> Server List and the RDNSS option's Lifetime field is not set to >>> zero, then.... >>> >>> =3D> This clarification looks good. I will reflect this in the revisio= n. >> >> >>> > Step (d): For each RDNSS address, if it does not exist in the DNS >>> > Server List, register the RDNSS address and Lifetime with the D= NS >>> > Server List and then insert the RDNSS address in front of the >>> > Resolver Repository. >>> >>> ...and then insert the RDNSS address as the first one in the Resolver >>> Repository. >>> >>> =3D> This clarification looks good, too. I will reflect this in the >> revision. >> >> >> Thanks. >> >> Best Regards, >> Paul >> >> >>> -- >>> Tassos >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> >> -- >> =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 >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Email: jaehoon.paul@gmail.com, pauljeong@skku.edu >> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> > > > > -- > =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 > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > --047d7bdc1b687051d7052fe864a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes. I will be reviewing evrything and preparing the proto w= riteup no later than tomorrow.

Thanks!
Fernando

El 7/4/2016 9:59, "Mr. Jaehoon Paul Jeong&q= uot; <jaehoon.paul@gmail.com> escribi=C3=B3:
Hi Fernando and Ole,
I believe that I have addresses= all of the comments from 6man WG with the following revision:

Could you review it and make it forw= ard from WGLC?

Thanks.

Pa= ul


On Mon, Mar 21, 2016 at 9:41 PM, Mr. Jaehoon Paul Jeong <jaehoo= n.paul@gmail.com> wrote:
Hi Tassos,
Thanks for your comments.
I put my answers inline= below with "=3D>".

On Fri, Mar 18, 2016 at 6:38 PM, Tassos Chatzith= omaoglou <achatz@forthnet.gr> wrote:
=
otroan@= employees.org wrote on 18/3/2016 10:44 =CF=80=CE=BC:
> Paul,
>
>> I took a look at the draft of https://www.ietf.org/id/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt= .
>>
>> From Case 4 (all RA flags are set, that is, M=3D1, A=3D1, O=3D1) i= n A.2.2,
>> Fedora 21 and Centos 7 let the DNS of the RAs have higher priority= , but
>> MAC OS-X lets the DNS of DHCPv6 have higher priority.
>> In the current implementations, there is no consistency to handle = RDNSS options from RA and DHCPv6.
>>
>> Thus, I suggest the following text with the preference for DHCPv6 = because
>> there is no a stong rationale, but there must be somehow a guidanc= e to handle this case:
>>
>> The DNS options from Router Advertisements and DHCP SHOULD be
>> stored into the DNS Repository and Resolver Repository so that
>> information from DHCP appears there first and therefore takes
>> precedence. This document recommends that the DNS information
>> from DHCP should have higher priority than that of RA for
>> DNS queries to handle the case of the coexistence of RA and DHCP.<= br> >>
>> If anyone does not object this text, I will revise the draft with = it.
> I would prefer this document focused solely on specifying the RA DNS o= ptions, and did not stray into more general configuration complexity.
>
> getting information from multiple sources is a more general problem in= IPv6, and I don't want us to "solve" (if that's possible= ) that problem in this document.
>
> "the less you say, the less likely you are to say something wrong= ". ;-)
>
> Best regards,
> Ole
>
So we leave the DHCP/RA preference choice to the implementers?<= br>
=C2=A0=3D> Since this issue =C2=A0is not sta= ndardized yet, we will leave it to the implementers.



Something else that doesn't seem ok to me.
> However, the security of these RA options for DNS configuration does >=C2=A0 =C2=A0 not affect ND protocol security [RFC4861].=C2=A0 This is = because learning
>=C2=A0 =C2=A0 DNS information via the RA options cannot be worse than l= earning bad
>=C2=A0 =C2=A0 router information via the RA options.=C2=A0 Therefore, t= he vulnerability
>=C2=A0 =C2=A0 of ND is not worse and is a subset of the attacks that an= y node
>=C2=A0 =C2=A0 attached to a LAN can do.

I do not agree with the statement "learning DNS information via the RA=
options cannot be worse than learning bad router information via the RA
options".
I believe that bad router exploitation is at a local level, while bad
DNS exploitation is at a global level. So while the origin of the attack can be the same (a node attached to the LAN), the easiness/effectiveness of the attack can be greater in the case of DNS.

=C2=A0=3D> By the invalid RDNSS addresses, = the DNS query messages from
=C2=A0 =C2=A0 =C2=A0 IPv6 hosts can b= e generated and sent toward those addresses over the link
=C2=A0 = =C2=A0 =C2=A0 to which the hosts are attached. However, in the aspect of IP= v6 hosts,=C2=A0
=C2=A0 =C2=A0 =C2=A0 the vulnerability level for = ND service seems still the same. =C2=A0 =C2=A0 =C2=A0
=C2= =A0=C2=A0

Also, i have spotted a few more places for further clarification:

> Step (c): For each RDNSS address, if it already exists in the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List, then...

Step (c): For each RDNSS address, if it already exists in the DNS
=C2=A0 =C2=A0 =C2=A0 Server List and the RDNSS option's Lifetime field = is not set to
zero, then....

=C2=A0=3D> This clarification looks good. I= will reflect this in the revision.
=C2=A0
> Step (d): For each RDNSS address, if it does not exist in the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List, register the RDNSS address and = Lifetime with the DNS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server List and then insert the RDNSS addres= s in front of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Resolver Repository.

...and then insert the RDNSS address as the first one in the Resolver
Repository.

=C2=A0 =3D> This clarification looks good, = too. I will reflect this in the revision.=C2=A0

=C2=A0Thanks.

=C2=A0Best Regards,
=C2=A0Paul


--
Tassos


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



=
--
=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
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
D= epartment of Software
Sungkyunkwan University
Office: +82-31-299-4957=
Email: = jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Personal= Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
=



--
=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
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,= =C2=A0pauljeong@skku.edu
Personal Homepage: http://iotlab= .skku.edu/people-jaehoon-jeong.php
--047d7bdc1b687051d7052fe864a2-- From nobody Thu Apr 7 10:42:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8CF12D5CF for ; Thu, 7 Apr 2016 10:42:30 -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 o6rVqrybnHHq for ; Thu, 7 Apr 2016 10:42:28 -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 0AD3312D565 for ; Thu, 7 Apr 2016 10:42:28 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:8d8f:be82:5f7:ab59] (unknown [IPv6:2001:67c:370:160:8d8f:be82:5f7:ab59]) (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 5618E80D8F; Thu, 7 Apr 2016 19:42:21 +0200 (CEST) Subject: Re: rfc2460bis question To: otroan@employees.org, Brian E Carpenter References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57068CBD.8020704@si6networks.com> Date: Thu, 7 Apr 2016 13:37:17 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:42:31 -0000 Ole, On 04/07/2016 11:01 AM, otroan@employees.org wrote: >>> There is no errata or updated-by document concerning this issue. >> >> Correct. But I was extremely surprised the first time I saw a >> proposal to insert headers en route, since I had *always* read >> RFC2460 (and RFC1883) to imply that headers are only created by the >> source node. So I maintain that it is a drafting ambiguity (in >> RFC1883, actually) and therefore fair game for clarification during >> the revisions allowed by RFC6410. >> >> If you really want to see it as an erratum, that would only take a >> few minutes. > > I don't think you were alone about being surprised by those > proposals. It is an ambiguity that we have lived with in the Internet > since RFC791 though. And we have lived without IPv6 as Internet Standard for 30 years... so? >> " If, as a result of processing a header, a node is required to >> proceed to the next header but the Next Header value in the current >> header is unrecognized by the node, it should discard the packet >> and send an ICMP Parameter Problem message to the source of the >> packet..." > > What I meant was that there is no currently known interoperability > problem with existing implementation or existing protocol > specifications. I agree with you that there are many issues if a > future specification would require to do header injection. We could > deal with those issues if or when those proposals where made. Working on revised protocol spec an intentionally keeping a well-noted ambiguity is a bad idea, and would be a poor job on our side. 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 7 15:20:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D06212D0C1 for ; Thu, 7 Apr 2016 15:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 rSe3-CCVu928 for ; Thu, 7 Apr 2016 15:20:10 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E91B12D0BF for ; Thu, 7 Apr 2016 15:20:10 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BCB7ED7883; Thu, 7 Apr 2016 15:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=8BsmxbBGs4vcU8p9ttCCVnyMg88=; b= Z2FNvXIeL+sz9jPADBrPe6vmRejeIG3XoYKw3t4RRr9aObikj91jw55HvVhMKVlo DTbtzS/5/toRBWh0qjv1lcxW7G1+FlUzwqkIj2ylgtEk1qX3raSY7Co+MGsiPx69 6NRaa9/o9E9itvVMgvKwthkSKxHfYFTmJvfrPJKcCho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=FF0rXBR3bu3oVsnbAZ3MHFS+q8 t99Z2Ijac1TYKjCctS/C5wq//JYTCXJBhSaem5pVV9wzpBap1yFDIt4tZihp0XQc dvTN/Sb7dbQWuq0JT7w4RslSoBIj5Pik5mIQ8+j3tGFEEt61Na0iuzX/KM7sRSSj C4qtSBLpWb4DM1Agk= Received: from h.hanazo.no (dhcp-b1da.meeting.ietf.org [31.133.177.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 3B2D8D78A2; Thu, 7 Apr 2016 15:20:09 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B7423141D662; Thu, 7 Apr 2016 19:20:04 -0300 (ART) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_54A64C0F-F44A-4456-9F32-271BFCC3F7F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <29889.1460046597@obiwan.sandelman.ca> Date: Thu, 7 Apr 2016 19:20:03 -0300 Message-Id: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <29889.1460046597@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:20:12 -0000 --Apple-Mail=_54A64C0F-F44A-4456-9F32-271BFCC3F7F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michaell, >> In general I'd prefer that we reuse existing mechanisms for path mtu >> discovery, and not invent new ones purely for the case of two = directly >> connected neighbors. >=20 >> Could we make this work by adding the RFC4861 MTU option to NS/NA >> messages, and require that PLMTUD probing is used to verify the end = to >> end MTU. >=20 > Yes, but plmtud can only be provided as a service to applications when = they > use TCP or SCTP. It can't find bigger UDP paths at present: that = would have > to be built in to the application. But, the kernel can provide the = service > for UDP users by doing the discovery in NUD.... > Basically we can run the plpmtud mechanism with NUD in the kernel. UDP applications already need to do that today. Isn't it a great step backwards if an application first has to detect if = the peer is directly connected or not, and behave differently depending = on the answer? Path MTU is a path property. I'm reluctant to make too much out of a = special case where path length is 1. I do agree that we need to do something in ND to allow nodes capable of = a higher MTU than the RA advertised default MTU to signal that between = each other. > There is another use for this MTU option: it appears that it is = sometimes > possible to run both 802.15.4-2012 (the 127 byte version) and = 802.15.4g (the > 2K or something byte version) on the same radios. > ("802.15.4-2015" includes 802.15.4g, btw, thus the need for a year to = be precise) >=20 > A 15.4g MAC ought to be able to speak to a -2012 MAC by using all of = our 6lowpan > mechanisms, but two 15.4g would like to discover that they don't need = to > fragment. I had *assumed* that the RA MTU option could be used for = this, and > was surprised when I read that it wasn't specified for this.... >=20 > So I'm in favour of having this ND option defined; and I care not if = it's a > new number or reuses the RA number. Best regards, Ole --Apple-Mail=_54A64C0F-F44A-4456-9F32-271BFCC3F7F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXBt0UAAoJEL7aWKiYQt927g4P+wcObD4NmjZaUH+L7+pUN+BB 9c8pl/SHuZizgLcmx4wQ8wdWEmvhHw2czsinR5wNWsb0GQazVctOnDI43xs1nlj+ JvmCQC+woU9llGinijCnW/jlWHuMANmH/zP+Ga9ZVvZmYuggNvIVnbzAOd4/iDs6 ia59q5dvbIV9/L5SYvrKvtd/VlYuaxJ+ejE09z1pIypVo5B7mtwKT//1XDGouBgj 6GbKxysBBjyyHMLK8M+gd8OvPUI2HnXKIzHPSnsvS8QaxSVO3elBH0gMtZ24NSMH 4I0ry3/sdz2A7CYmw8S9bgDumOVaYZ7IiNWfFbNZnhnwmDnS5Kv+LKgZUh/VwseJ jdcZTbK6zJqptml8/aZ1m8YaHx5xmgKF1w5j2V18vgZBSTTzu/6Kk9xqJf2SPLAa jiag1DfNnJ+b0biC0c6W2fG6BzBZv2Wqe7yToWZTFPiRF2XA2xL2N90clBJQS9rn 6JUMahqRj6uPtSancy9x1iQPZfqNCRfdZzH7fbGFxfyjlj/iOpxyKyXHlB0doOkF oE0mysOywSoIq7+WpzPQ7sQd7ZwxT4MSUWBKkxCV6rY727L8u6gsSC6RLHLQJ4cn 16+o0GJ01tkzFhZMoJe1TXqNzJqiI1TNnJHoEUOwRMIjzltDDrO0bzm7SIrZGrki bH27Q37XJm8nAm4VjZkS =k9V8 -----END PGP SIGNATURE----- --Apple-Mail=_54A64C0F-F44A-4456-9F32-271BFCC3F7F2-- From nobody Thu Apr 7 21:21:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B617112D576 for ; Thu, 7 Apr 2016 21:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 xQ-wXWWOTHQy for ; Thu, 7 Apr 2016 21:21:18 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7571112D0DB for ; Thu, 7 Apr 2016 21:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1460089277; x=1461298877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/vx1l/9sgy5ctryYCfcjSHKaJzxBIchuWyAmM9UMdSY=; b=FZRI1x87SmPhwiOysMPi+TyvyhO2MKoMGRbZleIPwb55eVuKWHtVwaZf WtU4ksB0PsE7fmY1JHGw3G5pGERbAT3S6I4MWVMHPE1adqADgXALHB/UH f204RvOFhhXqldDkZACLjt/irSIEgFI2NGzZjUY9E7IJx4Kt0ZUsF6A4n U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCVMAdX/xbLJq1dhAp9BrpAAQ2Bc?= =?us-ascii?q?xcKhWwCHIFbFAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgOCgICJgICAiU?= =?us-ascii?q?LFRACBA4FiB8IDrAQkhMBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJYF1CIJOh?= =?us-ascii?q?FWCaiuCKwWHcJAUAY4LgWeHdYUxjyQBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="676624294" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 04:21:15 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u384LENn005810 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 04:21:15 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.1104.5; Fri, 8 Apr 2016 00:21:13 -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.1104.009; Fri, 8 Apr 2016 00:21:13 -0400 From: "Stefano Previdi (sprevidi)" To: Fernando Gont Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRkEEWGbjOPkFJykCCV3KDKYtuDg== Date: Fri, 8 Apr 2016 04:21:13 +0000 Message-ID: <19F7120B-8163-436B-AA20-2E7A404C8871@cisco.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <57068CBD.8020704@si6networks.com> In-Reply-To: <57068CBD.8020704@si6networks.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.67.182] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:21:19 -0000 DQo+IE9uIEFwciA3LCAyMDE2LCBhdCA2OjM3IFBNLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZu ZXR3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gT2xlLA0KPiANCj4gT24gMDQvMDcvMjAxNiAxMTow MSBBTSwgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+Pj4+IFRoZXJlIGlzIG5vIGVycmF0 YSBvciB1cGRhdGVkLWJ5IGRvY3VtZW50IGNvbmNlcm5pbmcgdGhpcyBpc3N1ZS4NCj4+PiANCj4+ PiBDb3JyZWN0LiBCdXQgSSB3YXMgZXh0cmVtZWx5IHN1cnByaXNlZCB0aGUgZmlyc3QgdGltZSBJ IHNhdyBhDQo+Pj4gcHJvcG9zYWwgdG8gaW5zZXJ0IGhlYWRlcnMgZW4gcm91dGUsIHNpbmNlIEkg aGFkICphbHdheXMqIHJlYWQNCj4+PiBSRkMyNDYwIChhbmQgUkZDMTg4MykgdG8gaW1wbHkgdGhh dCBoZWFkZXJzIGFyZSBvbmx5IGNyZWF0ZWQgYnkgdGhlDQo+Pj4gc291cmNlIG5vZGUuIFNvIEkg bWFpbnRhaW4gdGhhdCBpdCBpcyBhIGRyYWZ0aW5nIGFtYmlndWl0eSAoaW4NCj4+PiBSRkMxODgz LCBhY3R1YWxseSkgYW5kIHRoZXJlZm9yZSBmYWlyIGdhbWUgZm9yIGNsYXJpZmljYXRpb24gZHVy aW5nDQo+Pj4gdGhlIHJldmlzaW9ucyBhbGxvd2VkIGJ5IFJGQzY0MTAuDQo+Pj4gDQo+Pj4gSWYg eW91IHJlYWxseSB3YW50IHRvIHNlZSBpdCBhcyBhbiBlcnJhdHVtLCB0aGF0IHdvdWxkIG9ubHkg dGFrZSBhDQo+Pj4gZmV3IG1pbnV0ZXMuDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsgeW91IHdlcmUg YWxvbmUgYWJvdXQgYmVpbmcgc3VycHJpc2VkIGJ5IHRob3NlDQo+PiBwcm9wb3NhbHMuIEl0IGlz IGFuIGFtYmlndWl0eSB0aGF0IHdlIGhhdmUgbGl2ZWQgd2l0aCBpbiB0aGUgSW50ZXJuZXQNCj4+ IHNpbmNlIFJGQzc5MSB0aG91Z2guDQo+IA0KPiBBbmQgd2UgaGF2ZSBsaXZlZCB3aXRob3V0IElQ djYgYXMgSW50ZXJuZXQgU3RhbmRhcmQgZm9yIDMwIHllYXJzLi4uIHNvPw0KPiANCj4gDQo+IA0K PiANCj4gDQo+Pj4gIiAgSWYsIGFzIGEgcmVzdWx0IG9mIHByb2Nlc3NpbmcgYSBoZWFkZXIsIGEg bm9kZSBpcyByZXF1aXJlZCB0bw0KPj4+IHByb2NlZWQgdG8gdGhlIG5leHQgaGVhZGVyIGJ1dCB0 aGUgTmV4dCBIZWFkZXIgdmFsdWUgaW4gdGhlIGN1cnJlbnQNCj4+PiBoZWFkZXIgaXMgdW5yZWNv Z25pemVkIGJ5IHRoZSBub2RlLCBpdCBzaG91bGQgZGlzY2FyZCB0aGUgcGFja2V0DQo+Pj4gYW5k IHNlbmQgYW4gSUNNUCBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlIHRvIHRoZSBzb3VyY2Ugb2Yg dGhlDQo+Pj4gcGFja2V0Li4uIg0KPj4gDQo+PiBXaGF0IEkgbWVhbnQgd2FzIHRoYXQgdGhlcmUg aXMgbm8gY3VycmVudGx5IGtub3duIGludGVyb3BlcmFiaWxpdHkNCj4+IHByb2JsZW0gd2l0aCBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbiBvciBleGlzdGluZyBwcm90b2NvbA0KPj4gc3BlY2lmaWNh dGlvbnMuIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGVyZSBhcmUgbWFueSBpc3N1ZXMgaWYgYQ0K Pj4gZnV0dXJlIHNwZWNpZmljYXRpb24gd291bGQgcmVxdWlyZSB0byBkbyBoZWFkZXIgaW5qZWN0 aW9uLiBXZSBjb3VsZA0KPj4gZGVhbCB3aXRoIHRob3NlIGlzc3VlcyBpZiBvciB3aGVuIHRob3Nl IHByb3Bvc2FscyB3aGVyZSBtYWRlLg0KPiANCj4gV29ya2luZyBvbiByZXZpc2VkIHByb3RvY29s IHNwZWMgYW4gaW50ZW50aW9uYWxseSBrZWVwaW5nIGEgd2VsbC1ub3RlZA0KPiBhbWJpZ3VpdHkg aXMgYSBiYWQgaWRlYSwgYW5kIHdvdWxkIGJlIGEgcG9vciBqb2Igb24gb3VyIHNpZGUuDQoNCg0K aXTigJlzIG5vdCAia2VlcGluZyBhbiBhbWJpZ3VpdHnigJ0ganVzdCBmb3IgZnVuLg0KDQpJdOKA mXMgd2FpdGluZyB0byBoYXZlIHRoZSBjb3JyZWN0IGFuYWx5c2lzIHByaW9yIHRvIGRlY2lkZSB3 aGljaCBiZWhhdmlvciB0byBtYW5kYXRlLiBXZSBjYW7igJl0IHJlYWxseSBpZ25vcmUgd2hhdCB0 aGUgaW5kdXN0cnkgaXMgd29ya2luZyBhdCwgY2FuIHdlID8NCg0KVGhhbmtzLg0Kcy4NCg0KDQo+ IA0KPiBUaGFua3MsDQo+IC0tIA0KPiBGZXJuYW5kbyBHb250DQo+IFNJNiBOZXR3b3Jrcw0KPiBl LW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNvbQ0KPiBQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFD NiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTINCj4gDQo+IA0KPiANCj4g DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0K PiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Thu Apr 7 21:23:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7533B12D0DB for ; Thu, 7 Apr 2016 21:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DiFzW1wejAX8 for ; Thu, 7 Apr 2016 21:23:12 -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 968EF12D78E for ; Thu, 7 Apr 2016 21:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6626; q=dns/txt; s=iport; t=1460089392; x=1461298992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vC5OquZhhu9tHfkC/+VKGuV9T92FdTn9Tiek6in1fg8=; b=dUK+tXfUC1nQ455umydYH8NkFRFFWQoO7HzRp5ucTXCnqtb1y+6ViDuB UO33i+Fc3g+aD5p0yT9fdpMT1CUHagvZoQ4Xd4lcOdc7PA6iZUoz/DIlw 6O4EJKkx43mDEbHcmtDFWuDOLuJZVaQzoM7DYAfW3MGQqNSgsHg+fAaoU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AgD1MQdX/5hdJa1dgzeBAU8GukABD?= =?us-ascii?q?YFzhg0CHIEjOBQBAQEBAQEBZRwLhEEBAQEDASMRRQULAgEIGAICJgICAjAVEAI?= =?us-ascii?q?EDgWIHwiwFpIUAQEBAQEBAQEBAQEBAQEBAQEBARd8hSWBdYFUgQKEDQwkgwIrg?= =?us-ascii?q?isFmAQBjguBZ4d1hTGPJAEeAQFCggQZgUpsh3w/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="89194778" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 04:22:58 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u384Mwsq003646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 04:22:58 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.1104.5; Fri, 8 Apr 2016 00:22:57 -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.1104.009; Fri, 8 Apr 2016 00:22:57 -0400 From: "Stefano Previdi (sprevidi)" To: "otroan@employees.org" Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRkEEWGbjOPkFJykCCV3KDKYtuDp99wTCAgAA8zQCAANClAIAA8JIA Date: Fri, 8 Apr 2016 04:22:57 +0000 Message-ID: <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@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.67.182] Content-Type: text/plain; charset="utf-8" Content-ID: <8F1189DE2A21EE4EB25E9B5D9BD2DA28@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:23:14 -0000 T2xlLA0KDQpJIGFncmVlIHdpdGggeW91ciBwb2ludCBhbmQgdGhlIHBvaW50IE1hcmsgKFRvd25z bGV5KSBtYWRlIGR1cmluZyB0aGUgbWVldGluZy4NCg0KSSB0aGluayB3ZSBuZWVkIHRvIGV2YWx1 YXRlIGJldHRlciB0aGUgdXNlIGNhc2VzIGFuZCBjdXJyZW50IHRlY2hub2xvZ3kgZGV2ZWxvcG1l bnQgdGhhdCBvcGVyYXRvcnMgYXJlIHVuZGVyZ29pbmcgYmVmb3JlIHRha2luZyBkcmFzdGljIGFy Y2hpdGVjdHVyYWwgYW5kIHByb3RvY29sIHNwZWNpZmljYXRpb24gZGVjaXNpb25zLg0KDQpJ4oCZ bSBub3Qgc2F5aW5nIHRoYXQgZXZlcnl0aGluZyBpdOKAmXMgcGVyZmVjdCBhcyBpdCBpcyBub3cu IEnigJltIHNheWluZyB0aGF0IHdlIG1heSBoYXZlIHRvIGRpZyBtb3JlIGJlZm9yZSBqdW1waW5n IGludG8gY29uY2x1c2lvbnMuDQoNClRoYW5rcy4NCnMuDQoNCg0KDQoNCj4gT24gQXByIDcsIDIw MTYsIGF0IDQ6MDEgUE0sIG90cm9hbkBlbXBsb3llZXMub3JnIHdyb3RlOg0KPiANCj4gRGVhciBC cmlhbiwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4gDQo+Pj4gTGV0IG1l IGFkZCBvbiB0byB0aGUgY29tbWVudHMgdGhhdCBJIG1hZGUgZHVyaW5nIHRoZSBtZWV0aW5nIHRv ZGF5Og0KPj4+IA0KPj4+IFRoZXJlIGlzIGEgaGlnaCBiYXIgdG8gaW50cm9kdWNlIGNoYW5nZXMg dG8gUkZDMjQ2MC4gQ2hhbmdlcyBhcmUgbGltaXRlZCB0byB0aG9zZSBkZXNjcmliZWQgaW4gUkZD NjQxMCBpbiBhZGRpdGlvbiB0byAiVXBkYXRlZCBieSIgZG9jdW1lbnRzLg0KPj4+IA0KPj4+IFRo ZSBwcm9wb3NlZCBjaGFuZ2UgcHJlc2VudGVkIHRvZGF5IGlzOiAobm90ZSB0aGF0IGlzIHVwZGF0 ZWQgZnJvbSB3aGF0IGlzIGluIHRoZSBkcmFmdCkNCj4+PiANCj4+PiAgIkV4dGVuc2lvbiBoZWFk ZXJzIG11c3QgbmV2ZXIgYmUgZGVsZXRlZCBvciBjaGFuZ2VkIGluIHNpemUgYnkgYW55IG5vZGUg b24gdGhlIHBhdGggdGhlIHBhY2tldCB0YWtlcy4NCj4+PiAgIFRoZSBjb250ZW50cyBvZiBhbiBF eHRlbnNpb24gaGVhZGVyIG9yIE9wdGlvbiBpbiBhbiBFeHRlbnNpb24gaGVhZGVyIG1heSBiZSBt b2RpZmllZCBpZiB0aGlzIGlzIHBlcm1pdHRlZA0KPj4+ICAgYnkgdGhlIGRlZmluaXRpb24gb2Yg dGhlIEV4dGVuc2lvbiBoZWFkZXIgb3Igb3B0aW9uLiINCj4+PiANCj4+PiBUaGVyZSBpcyBubyBl cnJhdGEgb3IgdXBkYXRlZC1ieSBkb2N1bWVudCBjb25jZXJuaW5nIHRoaXMgaXNzdWUuDQo+PiAN Cj4+IENvcnJlY3QuIEJ1dCBJIHdhcyBleHRyZW1lbHkgc3VycHJpc2VkIHRoZSBmaXJzdCB0aW1l IEkgc2F3IGEgcHJvcG9zYWwgdG8NCj4+IGluc2VydCBoZWFkZXJzIGVuIHJvdXRlLCBzaW5jZSBJ IGhhZCAqYWx3YXlzKiByZWFkIFJGQzI0NjAgKGFuZCBSRkMxODgzKQ0KPj4gdG8gaW1wbHkgdGhh dCBoZWFkZXJzIGFyZSBvbmx5IGNyZWF0ZWQgYnkgdGhlIHNvdXJjZSBub2RlLiBTbyBJIG1haW50 YWluDQo+PiB0aGF0IGl0IGlzIGEgZHJhZnRpbmcgYW1iaWd1aXR5IChpbiBSRkMxODgzLCBhY3R1 YWxseSkgYW5kIHRoZXJlZm9yZSBmYWlyIGdhbWUNCj4+IGZvciBjbGFyaWZpY2F0aW9uIGR1cmlu ZyB0aGUgcmV2aXNpb25zIGFsbG93ZWQgYnkgUkZDNjQxMC4NCj4+IA0KPj4gSWYgeW91IHJlYWxs eSB3YW50IHRvIHNlZSBpdCBhcyBhbiBlcnJhdHVtLCB0aGF0IHdvdWxkIG9ubHkgdGFrZSBhIGZl dw0KPj4gbWludXRlcy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgeW91IHdlcmUgYWxvbmUgYWJvdXQg YmVpbmcgc3VycHJpc2VkIGJ5IHRob3NlIHByb3Bvc2Fscy4NCj4gSXQgaXMgYW4gYW1iaWd1aXR5 IHRoYXQgd2UgaGF2ZSBsaXZlZCB3aXRoIGluIHRoZSBJbnRlcm5ldCBzaW5jZSBSRkM3OTEgdGhv dWdoLg0KPiANCj4+PiBJdCBpcyBub3QgYW4gdW51c2VkIGZlYXR1cmUsIHNpbmNlIHRoZSBwcm9w b3NhbCBpcyB0byBhZGQgbmV3IHRleHQgdG8gUkZDMjQ2MC4NCj4+PiANCj4+PiBBcyBmYXIgYXMg SSBhbSBhd2FyZSwgdGhlcmUgaXMgbm8gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZSBjYXVzZWQgYnkg dGhlIGN1cnJlbnQgUkZDMjQ2MCB0ZXh0Lg0KPj4gDQo+PiBZZXMgdGhlcmUgaXMsIGJlY2F1c2Ug aXQgZG9lcyBub3QgZm9yYmlkIGluc2VydGlvbiBvZiBhbiBleHRlbnNpb24gaGVhZGVyIGJ5IGEg dGhpcmQNCj4+IHBhcnR5LCB3aGVyZWFzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IG1vZGVsIGZvciBl eHRlbnNpb24gaGVhZGVycyBpcyB0aGF0IGJvdGggdGhlDQo+PiBzb3VyY2UgYW5kIHRoZSBkZXN0 aW5hdGlvbiBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGV4dGVuc2lvbiBoZWFkZXIgKGEgImNvbnNl bnRpbmcNCj4+IGFkdWx0cyIgbW9kZWwpLiBBbiB1bmtub3duIGluc2VydGVkIGhlYWRlciB3aWxs IGNhdXNlIGEgbG9zdCBwYWNrZXQ6DQo+PiANCj4+ICIgIElmLCBhcyBhIHJlc3VsdCBvZiBwcm9j ZXNzaW5nIGEgaGVhZGVyLCBhIG5vZGUgaXMgcmVxdWlyZWQgdG8gcHJvY2VlZA0KPj4gIHRvIHRo ZSBuZXh0IGhlYWRlciBidXQgdGhlIE5leHQgSGVhZGVyIHZhbHVlIGluIHRoZSBjdXJyZW50IGhl YWRlciBpcw0KPj4gIHVucmVjb2duaXplZCBieSB0aGUgbm9kZSwgaXQgc2hvdWxkIGRpc2NhcmQg dGhlIHBhY2tldCBhbmQgc2VuZCBhbg0KPj4gIElDTVAgUGFyYW1ldGVyIFByb2JsZW0gbWVzc2Fn ZSB0byB0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQuLi4iDQo+IA0KPiBXaGF0IEkgbWVhbnQgd2Fz IHRoYXQgdGhlcmUgaXMgbm8gY3VycmVudGx5IGtub3duIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIG9yIGV4aXN0aW5nIHByb3RvY29sIHNwZWNp ZmljYXRpb25zLg0KPiBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmUgYXJlIG1hbnkgaXNzdWVz IGlmIGEgZnV0dXJlIHNwZWNpZmljYXRpb24gd291bGQgcmVxdWlyZSB0byBkbyBoZWFkZXIgaW5q ZWN0aW9uLiBXZSBjb3VsZCBkZWFsIHdpdGggdGhvc2UgaXNzdWVzIGlmIG9yIHdoZW4gdGhvc2Ug cHJvcG9zYWxzIHdoZXJlIG1hZGUuDQo+IA0KPj4gSXQgbWlnaHQgYWxzbyBjYXVzZSBQTVRVRCBh bm9tYWxpZXMsIHRvby4NCj4gDQo+IEluZGVlZCwgYXMgZmFyIEkgY2FuIHNlZSBpdCB3b3VsZG4n dCBvbmx5IGNyZWF0ZSBhbm9tYWxpZXMgYnV0IGl0IHdvdWxkIGJyZWFrIGl0Lg0KPiANCj4+PiBB bmQgYXMgZmFyIGFzIEkgY2FuIHRlbGwgdGhlIHByb3Bvc2VkIGFkZGl0aW9uIGlzIHVubGlrZWx5 IHRvIGNyZWF0ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBlaXRoZXIuDQo+Pj4gDQo+Pj4gVGhl cmUgaXMgUkZDNDc4MiwgdGhhdCBhbGxvd3MgZm9yIGRlbGV0aW9uIG9mIGV4dGVuc2lvbiBoZWFk ZXJzLiBUaGF0IGlzIGFuIGV4cGVyaW1lbnRhbCBSRkMsIGFuZCBJJ20gdW5hd2FyZSBvZiB3aGF0 IHRoZSBjb25jbHVzaW9uIGZyb20gdGhlIGV4cGVyaW1lbnQgaXMuIFJGQzc5MSBhbGxvd3MgdGhl IGludHJvZHVjdGlvbiBvZiBvcHRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQo+Pj4gDQo+Pj4gUmVz b2x2aW5nIGhvdyBoZWFkZXIgaW5zZXJ0aW9uIG9yIGRlbGV0aW9uIG9mIGV4dGVuc2lvbiBoZWFk ZXJzIC8gb3B0aW9uIGlzIGRvbmUgIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBjaGFuZ2Vz IHdlIGNhbiBtYWtlIHRvIDI0NjAuDQo+PiANCj4+IE9idmlvdXNseSwgSSBkaXNhZ3JlZS4NCj4g DQo+IEkgZG8gdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4uIFdlIGNhbiBhcmd1ZSBpZiB0aGF0IGNv bmNlcm4gc2hvdWxkIGJlIHRhY2tsZWQgd2hpbGUgdGFraW5nIDI0NjAgdG8gSVMsIG9yIGlmIGl0 IHNob3VsZCBiZSB0YWNrbGVkIHdoZW5ldmVyIGEgcHJvcG9zYWwgdG8gZG8gaXQgY29tZXMgdXAu DQo+IA0KPj4+IFRob3NlIGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBkb25lIGluIHRoZSBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uIGZvciB0aG9zZSBwcm9wb3NlZCBleHRlbnNpb24gaGVhZGVycyAv IG9wdGlvbnMuDQo+Pj4gDQo+Pj4gTXkgY3VycmVudCB2aWV3IG9uIHRoaXMsIGlzIHRoYXQgaXQg d291bGQgYXBwZWFyIHRoYXQgbGlrZSB0byBoYXZlIHRoaXMgYWRkaXRpb25hbCB0ZXh0LCBub3Qg dG8gZml4IGFuIGV4aXN0aW5nIHByb2JsZW0sIGJ1dCB0byBmZW5kIG9mZiB3aGF0IHNob3VsZCBi ZSBhbGxvd2VkIGluIG5ldyBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4NCj4+PiANCj4+PiBBcyBJ IHNhaWQgYXQgdGhlIG1pY3JvcGhvbmUsIG15IHBvc2l0aW9uIGFzIGNoYWlyIGlzIHRoYXQgYnkg X2RlZmF1bHRfLCB0aGUgdGV4dCBpbiBSRkMyNDYwIGlzIGxlZnQgdW5jaGFuZ2VkLg0KPj4gDQo+ PiBBZ3JlZWQsIGJ1dCB3aGVuIHRoYXQgdGV4dCBpcyBhY3R1YWxseSBpbnRlcnByZXRlZCBkaWZm ZXJlbnRseSBieSBkaWZmZXJlbnQgcGVvcGxlLA0KPj4gd2hpY2ggaXMgY2xlYXJseSB0aGUgY2Fz ZSBoZXJlLCB3ZSBhcmUgSU1ITyBvYmxpZ2VkIHRvIGNsYXJpZnkgaXQuDQo+IA0KPiBJJ20gbm90 IHN1cmUgdGhhdCBpcyB0cnVlLiBTb21lIGxldmVsIG9mIGFtYmlndWl0eSBpbiBzcGVjaWZpY2F0 aW9ucyBpcyBnb29kLiBBbWJpZ3VpdHkgZXF1YWxzIGZyZWVkb20gYW5kIHJvb20gZm9yIGlubm92 YXRpb24uDQo+IA0KPiBJbiBhbnkgY2FzZSwgaWYgdGhlcmUgd2FzIGNsZWFyIGEgY29uc2Vuc3Vz IGFib3V0IHdoYXQgdG8gc2F5LCB0aGlzIHdvdWxkIGJlIHNpbXBsZXIuIElmIHRoZXJlIGlzbid0 LCB0aGVuIHNheWluZyBub3RoaW5nIGlzIHRoZSBzYWZlciBvcHRpb24sIHJhdGhlciB0aGFuIHNh eWluZyB0aGUgd3JvbmcgdGhpbmcuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IE9sZQ0KDQo= From nobody Thu Apr 7 22:31:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8D12D144 for ; Thu, 7 Apr 2016 22:31: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, 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 vEAr3FnABYpf for ; Thu, 7 Apr 2016 22:31:01 -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 B093212D0A3 for ; Thu, 7 Apr 2016 22:31:01 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e128so69594311pfe.3 for ; Thu, 07 Apr 2016 22:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/+g1B5qpJCIiYYfXJV295CkLduEXNExn63XHBpsH/bI=; b=Qh3upSGq89sb3e7eKjAw4IB4YuxBCvlKbFXbAvo4pdaaUP85nnWRdD8bA65JZ/kIyY A2n4z+fa3kUhe+HyH7JJ4Uk19Ov1E9uiBQGuQ0wSW2N6aEA2v2onxHUZ646U2QQEn33X hiNmu13ZHwCS/2+eRT6GEXTvO/qjed1bMcU5ZNOFl3m81o+30AhAFPTWRzkqPazvf1ae NTYF3og28GL9ZWzoBDHz5qu9gAA1Skxgnyyl3/7mHByHyqsLbOiviDRxoDYobkG42XF8 vk2ZBzIrzfPs+tdkWQnkzywpB5Ahvz0XoAmFcBntvRUkeE5oQly5N9+oOx3JmYYXJkfw 7imQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=/+g1B5qpJCIiYYfXJV295CkLduEXNExn63XHBpsH/bI=; b=FZEX0IKMOLsEE28Nxb1NmFs0cxtHPARHBmN9XbPf58q9xe6iazLCUj+raCbK7679Om eMtGaf7R9hIfIyNb789xSUPLfcnefUa465GBq0XOXtngEuFB9/LU6GkPdU3j5Mex38O3 13Slji4oOP/ZuF+rUtvSJFUffECgteHRXBZVYX9m0VuO3FFJJvJppYYwP8Hu3pOLmFJn frEoYPjbeE3hA8x4TF8g20J1pESCnxOTj505ZG7d3Hf0lU8WffrcCXoy3UpVjwX71Iie sTXMoUrQ6/SfDHdpvSTU3rQAgtjaFbCqVeen6s/Uz7rAqGpwZeIDMys36jBYp9HySTeJ urOg== X-Gm-Message-State: AD7BkJLg9Y2IhCtM+rRESsDG2Qe4y1e/eemp/kT7MnmWQ3B3wAsadEQryhbi5oEShD+iJg== X-Received: by 10.98.13.130 with SMTP id 2mr10032661pfn.97.1460093461273; Thu, 07 Apr 2016 22:31:01 -0700 (PDT) Received: from ?IPv6:2406:e007:78d0:1:28cc:dc4c:9703:6781? ([2406:e007:78d0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id zp5sm15822656pac.9.2016.04.07.22.30.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 22:30:59 -0700 (PDT) Subject: Re: rfc2460bis question To: "Stefano Previdi (sprevidi)" , "otroan@employees.org" References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57074219.2020908@gmail.com> Date: Fri, 8 Apr 2016 17:31:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 05:31:04 -0000 On 08/04/2016 16:22, Stefano Previdi (sprevidi) wrote: > Ole, >=20 > I agree with your point and the point Mark (Townsley) made during the m= eeting. >=20 > I think we need to evaluate better the use cases and current technology= development that operators are undergoing before taking drastic architec= tural and protocol specification decisions. >=20 > I=E2=80=99m not saying that everything it=E2=80=99s perfect as it is no= w. I=E2=80=99m saying that we may have to dig more before jumping into co= nclusions. "Extension headers must never be deleted or changed in size by any node o= n the path the packet takes." There's no jumping to conclusions. We know that this breaks IPsec/AH and = PMTUD. It's explicit in 2460 that in the case of options, only the "Option Data"= may change, not the "Option Type" or "Opt Data Len", because of AH. But the same stat= ement is not made about other extension headers. As far as I'm concerned that's a clea= r error of omission in 2460. Of course inserting an extension header also breaks AH and PMTUD. "The contents of an Extension header or Option in an Extension header may= be modified if this is permitted by the definition of the Extension header or option." That actually should be s/may/may only/ to change anything. It's more deb= atable because it doesn't damage PMTUD. But since AH is not immunised against ch= anges to extension headers in the same way that it's immunised against changes = in "Option Data", I think this is also a clear omission. The fact that AH is no longer loved by the security community is a separa= te issue. If the security community was ready to make AH Historic, that would chang= e the discussion. Regards Brian >=20 > Thanks. > s. >=20 >=20 >=20 >=20 >> On Apr 7, 2016, at 4:01 PM, otroan@employees.org wrote: >> >> Dear Brian, >> >> Thank you for your comments. >> >>>> Let me add on to the comments that I made during the meeting today: >>>> >>>> There is a high bar to introduce changes to RFC2460. Changes are lim= ited to those described in RFC6410 in addition to "Updated by" documents.= >>>> >>>> The proposed change presented today is: (note that is updated from w= hat is in the draft) >>>> >>>> "Extension headers must never be deleted or changed in size by any = node on the path the packet takes. >>>> The contents of an Extension header or Option in an Extension head= er may be modified if this is permitted >>>> by the definition of the Extension header or option." >>>> >>>> There is no errata or updated-by document concerning this issue. >>> >>> Correct. But I was extremely surprised the first time I saw a proposa= l to >>> insert headers en route, since I had *always* read RFC2460 (and RFC18= 83) >>> to imply that headers are only created by the source node. So I maint= ain >>> that it is a drafting ambiguity (in RFC1883, actually) and therefore = fair game >>> for clarification during the revisions allowed by RFC6410. >>> >>> If you really want to see it as an erratum, that would only take a fe= w >>> minutes. >> >> I don't think you were alone about being surprised by those proposals.= >> It is an ambiguity that we have lived with in the Internet since RFC79= 1 though. >> >>>> It is not an unused feature, since the proposal is to add new text t= o RFC2460. >>>> >>>> As far as I am aware, there is no interoperability issue caused by t= he current RFC2460 text. >>> >>> Yes there is, because it does not forbid insertion of an extension he= ader by a third >>> party, whereas the interoperability model for extension headers is th= at both the >>> source and the destination need to understand the extension header (a= "consenting >>> adults" model). An unknown inserted header will cause a lost packet: >>> >>> " If, as a result of processing a header, a node is required to proc= eed >>> to the next header but the Next Header value in the current header i= s >>> unrecognized by the node, it should discard the packet and send an >>> ICMP Parameter Problem message to the source of the packet..." >> >> What I meant was that there is no currently known interoperability pro= blem with existing implementation or existing protocol specifications. >> I agree with you that there are many issues if a future specification = would require to do header injection. We could deal with those issues if = or when those proposals where made. >> >>> It might also cause PMTUD anomalies, too. >> >> Indeed, as far I can see it wouldn't only create anomalies but it woul= d break it. >> >>>> And as far as I can tell the proposed addition is unlikely to create= interoperability issues either. >>>> >>>> There is RFC4782, that allows for deletion of extension headers. Tha= t is an experimental RFC, and I'm unaware of what the conclusion from the= experiment is. RFC791 allows the introduction of options in certain case= s. >>>> >>>> Resolving how header insertion or deletion of extension headers / op= tion is done is outside the scope of the changes we can make to 2460. >>> >>> Obviously, I disagree. >> >> I do understand your concern. We can argue if that concern should be t= ackled while taking 2460 to IS, or if it should be tackled whenever a pro= posal to do it comes up. >> >>>> Those considerations should be done in the protocol specification fo= r those proposed extension headers / options. >>>> >>>> My current view on this, is that it would appear that like to have t= his additional text, not to fix an existing problem, but to fend off what= should be allowed in new protocol specifications. >>>> >>>> As I said at the microphone, my position as chair is that by _defaul= t_, the text in RFC2460 is left unchanged. >>> >>> Agreed, but when that text is actually interpreted differently by dif= ferent people, >>> which is clearly the case here, we are IMHO obliged to clarify it. >> >> I'm not sure that is true. Some level of ambiguity in specifications i= s good. Ambiguity equals freedom and room for innovation. >> >> In any case, if there was clear a consensus about what to say, this wo= uld be simpler. If there isn't, then saying nothing is the safer option, = rather than saying the wrong thing. >> >> Best regards, >> Ole >=20 From nobody Thu Apr 7 22:48:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04012D159 for ; Thu, 7 Apr 2016 22:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7leLhOCss2HN for ; Thu, 7 Apr 2016 22:47:59 -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 5CF3012D095 for ; Thu, 7 Apr 2016 22:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9234; q=dns/txt; s=iport; t=1460094479; x=1461304079; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AGfEitXnupDKrplGp9ym6Tv+EZnTn2MyRNTt6e5EEFQ=; b=kIKG2gWY1y0PmFJpC5EP3s+HV8nvDSZzQEv1oYUEhQRx3TYq8SsuSJWI bXaUi54u08GQtiI4jtMXm93PHvSqiJiZD8p73xaaDWRG+pnO3xboENMZz bPPGr2DrbPbGyz80L4s7igZHwg4pKpUakPgnMNk8tLNZZ9m9uXY2dyPO4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AgCxRAdX/5hdJa1dgzeBAU8GrmiLW?= =?us-ascii?q?AENgXOGDQIcgSM4FAEBAQEBAQFlJ4RBAQEBAwEjEUUFCwIBCBgCAiYCAgIfERU?= =?us-ascii?q?QAgQOBRSHfgMKCLAHjGoNhR4BAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUlgXUIg?= =?us-ascii?q?UyBAoJBgUwMPIJqK4IrBZdTMQGMFoF1CoFdh3WFMYdKh1oBHgEBQoIEGYFKbAG?= =?us-ascii?q?Hez9+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258777607" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 05:47:58 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u385lvd9014899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 05:47:58 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.1104.5; Fri, 8 Apr 2016 01:47: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.1104.009; Fri, 8 Apr 2016 01:47:56 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRkEEWGbjOPkFJykCCV3KDKYtuDp99wTCAgAA8zQCAANClAIAAwIsDgABHxoA= Date: Fri, 8 Apr 2016 05:47:56 +0000 Message-ID: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <57074219.2020908@gmail.com> In-Reply-To: <57074219.2020908@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.237.109] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 05:48:01 -0000 DQo+IE9uIEFwciA4LCAyMDE2LCBhdCA3OjMxIEFNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4u ZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDA4LzA0LzIwMTYgMTY6MjIs IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIHdyb3RlOg0KPj4gT2xlLA0KPj4gDQo+PiBJIGFn cmVlIHdpdGggeW91ciBwb2ludCBhbmQgdGhlIHBvaW50IE1hcmsgKFRvd25zbGV5KSBtYWRlIGR1 cmluZyB0aGUgbWVldGluZy4NCj4+IA0KPj4gSSB0aGluayB3ZSBuZWVkIHRvIGV2YWx1YXRlIGJl dHRlciB0aGUgdXNlIGNhc2VzIGFuZCBjdXJyZW50IHRlY2hub2xvZ3kgZGV2ZWxvcG1lbnQgdGhh dCBvcGVyYXRvcnMgYXJlIHVuZGVyZ29pbmcgYmVmb3JlIHRha2luZyBkcmFzdGljIGFyY2hpdGVj dHVyYWwgYW5kIHByb3RvY29sIHNwZWNpZmljYXRpb24gZGVjaXNpb25zLg0KPj4gDQo+PiBJ4oCZ bSBub3Qgc2F5aW5nIHRoYXQgZXZlcnl0aGluZyBpdOKAmXMgcGVyZmVjdCBhcyBpdCBpcyBub3cu IEnigJltIHNheWluZyB0aGF0IHdlIG1heSBoYXZlIHRvIGRpZyBtb3JlIGJlZm9yZSBqdW1waW5n IGludG8gY29uY2x1c2lvbnMuDQo+IA0KPiAiRXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBuZXZlciBi ZSBkZWxldGVkIG9yIGNoYW5nZWQgaW4gc2l6ZSBieSBhbnkgbm9kZSBvbiB0aGUgcGF0aCB0aGUg cGFja2V0IHRha2VzLiINCj4gDQo+IFRoZXJlJ3Mgbm8ganVtcGluZyB0byBjb25jbHVzaW9ucy4g V2Uga25vdyB0aGF0IHRoaXMgYnJlYWtzIElQc2VjL0FIIGFuZCBQTVRVRC4NCg0KDQppbiBhIGNv cmUgd2hlcmUgaGVhZGVyIGlzIGluc2VydGVkIGFuZCB3aGVyZSB0aGUgbXR1IGlzIG92ZXIgOEsg SSBkb27igJl0IHNlZSBob3cgcG10dWQgbWF5IGJlIGJyb2tlbi4gQWxzbywgd2hhdGV2ZXIgeW91 IGRvIHRvIHRoZSBwYWNrZXQsIGlmIHlvdSBkZWxpdmVyIGl0IGluIHRoZSBzYW1lIHNoYXBlIHlv dSByZWNlaXZlZCBpdCwgdGhlcmXigJlzIG5vdGhpbmcgd3JpbmcuIEF0IGxlYXN0IGZyb20gYW4g b3BlcmF0aW9uYWwgcGVyc3BlY3RpdmUgaXTigJlzIGhhcHBlbmluZyBkYWlseS4NCg0KDQpUaGFu a3MuDQpzLg0KDQoNCg0KPiBJdCdzIGV4cGxpY2l0IGluIDI0NjAgdGhhdCBpbiB0aGUgY2FzZSBv ZiBvcHRpb25zLCBvbmx5IHRoZSAiT3B0aW9uIERhdGEiIG1heSBjaGFuZ2UsDQo+IG5vdCB0aGUg Ik9wdGlvbiBUeXBlIiBvciAiT3B0IERhdGEgTGVuIiwgYmVjYXVzZSBvZiBBSC4gQnV0IHRoZSBz YW1lIHN0YXRlbWVudCBpcyBub3QNCj4gbWFkZSBhYm91dCBvdGhlciBleHRlbnNpb24gaGVhZGVy cy4gQXMgZmFyIGFzIEknbSBjb25jZXJuZWQgdGhhdCdzIGEgY2xlYXIgZXJyb3Igb2Ygb21pc3Np b24NCj4gaW4gMjQ2MC4NCj4gDQo+IE9mIGNvdXJzZSBpbnNlcnRpbmcgYW4gZXh0ZW5zaW9uIGhl YWRlciBhbHNvIGJyZWFrcyBBSCBhbmQgUE1UVUQuDQo+IA0KPiAiVGhlIGNvbnRlbnRzIG9mIGFu IEV4dGVuc2lvbiBoZWFkZXIgb3IgT3B0aW9uIGluIGFuIEV4dGVuc2lvbiBoZWFkZXIgbWF5IGJl IG1vZGlmaWVkIGlmIHRoaXMgaXMgcGVybWl0dGVkIGJ5IHRoZSBkZWZpbml0aW9uIG9mDQo+IHRo ZSBFeHRlbnNpb24gaGVhZGVyIG9yIG9wdGlvbi4iDQo+IA0KPiBUaGF0IGFjdHVhbGx5IHNob3Vs ZCBiZSBzL21heS9tYXkgb25seS8gdG8gY2hhbmdlIGFueXRoaW5nLiBJdCdzIG1vcmUgZGViYXRh YmxlDQo+IGJlY2F1c2UgaXQgZG9lc24ndCBkYW1hZ2UgUE1UVUQuIEJ1dCBzaW5jZSBBSCBpcyBu b3QgaW1tdW5pc2VkIGFnYWluc3QgY2hhbmdlcw0KPiB0byBleHRlbnNpb24gaGVhZGVycyBpbiB0 aGUgc2FtZSB3YXkgdGhhdCBpdCdzIGltbXVuaXNlZCBhZ2FpbnN0IGNoYW5nZXMgaW4NCj4gIk9w dGlvbiBEYXRhIiwgSSB0aGluayB0aGlzIGlzIGFsc28gYSBjbGVhciBvbWlzc2lvbi4NCj4gDQo+ IFRoZSBmYWN0IHRoYXQgQUggaXMgbm8gbG9uZ2VyIGxvdmVkIGJ5IHRoZSBzZWN1cml0eSBjb21t dW5pdHkgaXMgYSBzZXBhcmF0ZSBpc3N1ZS4NCj4gSWYgdGhlIHNlY3VyaXR5IGNvbW11bml0eSB3 YXMgcmVhZHkgdG8gbWFrZSBBSCBIaXN0b3JpYywgdGhhdCB3b3VsZCBjaGFuZ2UgdGhlDQo+IGRp c2N1c3Npb24uDQo+IA0KPiBSZWdhcmRzDQo+ICBCcmlhbg0KPiANCj4+IA0KPj4gVGhhbmtzLg0K Pj4gcy4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4+IE9uIEFwciA3LCAyMDE2LCBhdCA0OjAxIFBN LCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+PiANCj4+PiBEZWFyIEJyaWFuLA0KPj4+ IA0KPj4+IFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4+PiANCj4+Pj4+IExldCBtZSBh ZGQgb24gdG8gdGhlIGNvbW1lbnRzIHRoYXQgSSBtYWRlIGR1cmluZyB0aGUgbWVldGluZyB0b2Rh eToNCj4+Pj4+IA0KPj4+Pj4gVGhlcmUgaXMgYSBoaWdoIGJhciB0byBpbnRyb2R1Y2UgY2hhbmdl cyB0byBSRkMyNDYwLiBDaGFuZ2VzIGFyZSBsaW1pdGVkIHRvIHRob3NlIGRlc2NyaWJlZCBpbiBS RkM2NDEwIGluIGFkZGl0aW9uIHRvICJVcGRhdGVkIGJ5IiBkb2N1bWVudHMuDQo+Pj4+PiANCj4+ Pj4+IFRoZSBwcm9wb3NlZCBjaGFuZ2UgcHJlc2VudGVkIHRvZGF5IGlzOiAobm90ZSB0aGF0IGlz IHVwZGF0ZWQgZnJvbSB3aGF0IGlzIGluIHRoZSBkcmFmdCkNCj4+Pj4+IA0KPj4+Pj4gIkV4dGVu c2lvbiBoZWFkZXJzIG11c3QgbmV2ZXIgYmUgZGVsZXRlZCBvciBjaGFuZ2VkIGluIHNpemUgYnkg YW55IG5vZGUgb24gdGhlIHBhdGggdGhlIHBhY2tldCB0YWtlcy4NCj4+Pj4+ICBUaGUgY29udGVu dHMgb2YgYW4gRXh0ZW5zaW9uIGhlYWRlciBvciBPcHRpb24gaW4gYW4gRXh0ZW5zaW9uIGhlYWRl ciBtYXkgYmUgbW9kaWZpZWQgaWYgdGhpcyBpcyBwZXJtaXR0ZWQNCj4+Pj4+ICBieSB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgRXh0ZW5zaW9uIGhlYWRlciBvciBvcHRpb24uIg0KPj4+Pj4gDQo+Pj4+ PiBUaGVyZSBpcyBubyBlcnJhdGEgb3IgdXBkYXRlZC1ieSBkb2N1bWVudCBjb25jZXJuaW5nIHRo aXMgaXNzdWUuDQo+Pj4+IA0KPj4+PiBDb3JyZWN0LiBCdXQgSSB3YXMgZXh0cmVtZWx5IHN1cnBy aXNlZCB0aGUgZmlyc3QgdGltZSBJIHNhdyBhIHByb3Bvc2FsIHRvDQo+Pj4+IGluc2VydCBoZWFk ZXJzIGVuIHJvdXRlLCBzaW5jZSBJIGhhZCAqYWx3YXlzKiByZWFkIFJGQzI0NjAgKGFuZCBSRkMx ODgzKQ0KPj4+PiB0byBpbXBseSB0aGF0IGhlYWRlcnMgYXJlIG9ubHkgY3JlYXRlZCBieSB0aGUg c291cmNlIG5vZGUuIFNvIEkgbWFpbnRhaW4NCj4+Pj4gdGhhdCBpdCBpcyBhIGRyYWZ0aW5nIGFt YmlndWl0eSAoaW4gUkZDMTg4MywgYWN0dWFsbHkpIGFuZCB0aGVyZWZvcmUgZmFpciBnYW1lDQo+ Pj4+IGZvciBjbGFyaWZpY2F0aW9uIGR1cmluZyB0aGUgcmV2aXNpb25zIGFsbG93ZWQgYnkgUkZD NjQxMC4NCj4+Pj4gDQo+Pj4+IElmIHlvdSByZWFsbHkgd2FudCB0byBzZWUgaXQgYXMgYW4gZXJy YXR1bSwgdGhhdCB3b3VsZCBvbmx5IHRha2UgYSBmZXcNCj4+Pj4gbWludXRlcy4NCj4+PiANCj4+ PiBJIGRvbid0IHRoaW5rIHlvdSB3ZXJlIGFsb25lIGFib3V0IGJlaW5nIHN1cnByaXNlZCBieSB0 aG9zZSBwcm9wb3NhbHMuDQo+Pj4gSXQgaXMgYW4gYW1iaWd1aXR5IHRoYXQgd2UgaGF2ZSBsaXZl ZCB3aXRoIGluIHRoZSBJbnRlcm5ldCBzaW5jZSBSRkM3OTEgdGhvdWdoLg0KPj4+IA0KPj4+Pj4g SXQgaXMgbm90IGFuIHVudXNlZCBmZWF0dXJlLCBzaW5jZSB0aGUgcHJvcG9zYWwgaXMgdG8gYWRk IG5ldyB0ZXh0IHRvIFJGQzI0NjAuDQo+Pj4+PiANCj4+Pj4+IEFzIGZhciBhcyBJIGFtIGF3YXJl LCB0aGVyZSBpcyBubyBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlIGNhdXNlZCBieSB0aGUgY3VycmVu dCBSRkMyNDYwIHRleHQuDQo+Pj4+IA0KPj4+PiBZZXMgdGhlcmUgaXMsIGJlY2F1c2UgaXQgZG9l cyBub3QgZm9yYmlkIGluc2VydGlvbiBvZiBhbiBleHRlbnNpb24gaGVhZGVyIGJ5IGEgdGhpcmQN Cj4+Pj4gcGFydHksIHdoZXJlYXMgdGhlIGludGVyb3BlcmFiaWxpdHkgbW9kZWwgZm9yIGV4dGVu c2lvbiBoZWFkZXJzIGlzIHRoYXQgYm90aCB0aGUNCj4+Pj4gc291cmNlIGFuZCB0aGUgZGVzdGlu YXRpb24gbmVlZCB0byB1bmRlcnN0YW5kIHRoZSBleHRlbnNpb24gaGVhZGVyIChhICJjb25zZW50 aW5nDQo+Pj4+IGFkdWx0cyIgbW9kZWwpLiBBbiB1bmtub3duIGluc2VydGVkIGhlYWRlciB3aWxs IGNhdXNlIGEgbG9zdCBwYWNrZXQ6DQo+Pj4+IA0KPj4+PiAiICBJZiwgYXMgYSByZXN1bHQgb2Yg cHJvY2Vzc2luZyBhIGhlYWRlciwgYSBub2RlIGlzIHJlcXVpcmVkIHRvIHByb2NlZWQNCj4+Pj4g dG8gdGhlIG5leHQgaGVhZGVyIGJ1dCB0aGUgTmV4dCBIZWFkZXIgdmFsdWUgaW4gdGhlIGN1cnJl bnQgaGVhZGVyIGlzDQo+Pj4+IHVucmVjb2duaXplZCBieSB0aGUgbm9kZSwgaXQgc2hvdWxkIGRp c2NhcmQgdGhlIHBhY2tldCBhbmQgc2VuZCBhbg0KPj4+PiBJQ01QIFBhcmFtZXRlciBQcm9ibGVt IG1lc3NhZ2UgdG8gdGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0Li4uIg0KPj4+IA0KPj4+IFdoYXQg SSBtZWFudCB3YXMgdGhhdCB0aGVyZSBpcyBubyBjdXJyZW50bHkga25vd24gaW50ZXJvcGVyYWJp bGl0eSBwcm9ibGVtIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gb3IgZXhpc3RpbmcgcHJv dG9jb2wgc3BlY2lmaWNhdGlvbnMuDQo+Pj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZXJlIGFy ZSBtYW55IGlzc3VlcyBpZiBhIGZ1dHVyZSBzcGVjaWZpY2F0aW9uIHdvdWxkIHJlcXVpcmUgdG8g ZG8gaGVhZGVyIGluamVjdGlvbi4gV2UgY291bGQgZGVhbCB3aXRoIHRob3NlIGlzc3VlcyBpZiBv ciB3aGVuIHRob3NlIHByb3Bvc2FscyB3aGVyZSBtYWRlLg0KPj4+IA0KPj4+PiBJdCBtaWdodCBh bHNvIGNhdXNlIFBNVFVEIGFub21hbGllcywgdG9vLg0KPj4+IA0KPj4+IEluZGVlZCwgYXMgZmFy IEkgY2FuIHNlZSBpdCB3b3VsZG4ndCBvbmx5IGNyZWF0ZSBhbm9tYWxpZXMgYnV0IGl0IHdvdWxk IGJyZWFrIGl0Lg0KPj4+IA0KPj4+Pj4gQW5kIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBwcm9w b3NlZCBhZGRpdGlvbiBpcyB1bmxpa2VseSB0byBjcmVhdGUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1 ZXMgZWl0aGVyLg0KPj4+Pj4gDQo+Pj4+PiBUaGVyZSBpcyBSRkM0NzgyLCB0aGF0IGFsbG93cyBm b3IgZGVsZXRpb24gb2YgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoYXQgaXMgYW4gZXhwZXJpbWVudGFs IFJGQywgYW5kIEknbSB1bmF3YXJlIG9mIHdoYXQgdGhlIGNvbmNsdXNpb24gZnJvbSB0aGUgZXhw ZXJpbWVudCBpcy4gUkZDNzkxIGFsbG93cyB0aGUgaW50cm9kdWN0aW9uIG9mIG9wdGlvbnMgaW4g Y2VydGFpbiBjYXNlcy4NCj4+Pj4+IA0KPj4+Pj4gUmVzb2x2aW5nIGhvdyBoZWFkZXIgaW5zZXJ0 aW9uIG9yIGRlbGV0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIC8gb3B0aW9uIGlzIGRvbmUgIGlz IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBjaGFuZ2VzIHdlIGNhbiBtYWtlIHRvIDI0NjAuDQo+ Pj4+IA0KPj4+PiBPYnZpb3VzbHksIEkgZGlzYWdyZWUuDQo+Pj4gDQo+Pj4gSSBkbyB1bmRlcnN0 YW5kIHlvdXIgY29uY2Vybi4gV2UgY2FuIGFyZ3VlIGlmIHRoYXQgY29uY2VybiBzaG91bGQgYmUg dGFja2xlZCB3aGlsZSB0YWtpbmcgMjQ2MCB0byBJUywgb3IgaWYgaXQgc2hvdWxkIGJlIHRhY2ts ZWQgd2hlbmV2ZXIgYSBwcm9wb3NhbCB0byBkbyBpdCBjb21lcyB1cC4NCj4+PiANCj4+Pj4+IFRo b3NlIGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBkb25lIGluIHRoZSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uIGZvciB0aG9zZSBwcm9wb3NlZCBleHRlbnNpb24gaGVhZGVycyAvIG9wdGlvbnMuDQo+ Pj4+PiANCj4+Pj4+IE15IGN1cnJlbnQgdmlldyBvbiB0aGlzLCBpcyB0aGF0IGl0IHdvdWxkIGFw cGVhciB0aGF0IGxpa2UgdG8gaGF2ZSB0aGlzIGFkZGl0aW9uYWwgdGV4dCwgbm90IHRvIGZpeCBh biBleGlzdGluZyBwcm9ibGVtLCBidXQgdG8gZmVuZCBvZmYgd2hhdCBzaG91bGQgYmUgYWxsb3dl ZCBpbiBuZXcgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMuDQo+Pj4+PiANCj4+Pj4+IEFzIEkgc2Fp ZCBhdCB0aGUgbWljcm9waG9uZSwgbXkgcG9zaXRpb24gYXMgY2hhaXIgaXMgdGhhdCBieSBfZGVm YXVsdF8sIHRoZSB0ZXh0IGluIFJGQzI0NjAgaXMgbGVmdCB1bmNoYW5nZWQuDQo+Pj4+IA0KPj4+ PiBBZ3JlZWQsIGJ1dCB3aGVuIHRoYXQgdGV4dCBpcyBhY3R1YWxseSBpbnRlcnByZXRlZCBkaWZm ZXJlbnRseSBieSBkaWZmZXJlbnQgcGVvcGxlLA0KPj4+PiB3aGljaCBpcyBjbGVhcmx5IHRoZSBj YXNlIGhlcmUsIHdlIGFyZSBJTUhPIG9ibGlnZWQgdG8gY2xhcmlmeSBpdC4NCj4+PiANCj4+PiBJ J20gbm90IHN1cmUgdGhhdCBpcyB0cnVlLiBTb21lIGxldmVsIG9mIGFtYmlndWl0eSBpbiBzcGVj aWZpY2F0aW9ucyBpcyBnb29kLiBBbWJpZ3VpdHkgZXF1YWxzIGZyZWVkb20gYW5kIHJvb20gZm9y IGlubm92YXRpb24uDQo+Pj4gDQo+Pj4gSW4gYW55IGNhc2UsIGlmIHRoZXJlIHdhcyBjbGVhciBh IGNvbnNlbnN1cyBhYm91dCB3aGF0IHRvIHNheSwgdGhpcyB3b3VsZCBiZSBzaW1wbGVyLiBJZiB0 aGVyZSBpc24ndCwgdGhlbiBzYXlpbmcgbm90aGluZyBpcyB0aGUgc2FmZXIgb3B0aW9uLCByYXRo ZXIgdGhhbiBzYXlpbmcgdGhlIHdyb25nIHRoaW5nLg0KPj4+IA0KPj4+IEJlc3QgcmVnYXJkcywN Cj4+PiBPbGUNCj4+IA0KPiANCg0K From nobody Fri Apr 8 01:38:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C6F12D546 for ; Fri, 8 Apr 2016 01:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.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=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8h2pnTZH7ydf for ; Fri, 8 Apr 2016 01:38:14 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 48CE312D1E2 for ; Fri, 8 Apr 2016 01:38:14 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id c4so130084729vkb.3 for ; Fri, 08 Apr 2016 01:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=DHKQWGbUMCSZva8fMFVwNB5PuUJGGewFyUMV1HKUa/8=; b=attGmSIp0zg/UjODpu9gRQmdmwxqq//c//oCpYre9ViQyljv1LTsF8zWR5SYXhdP0f sUieSLaLKAZnIHl/Gl+guHILRJqz1KOQY8wuJVX2NOMcQm4fWwJgLV/sKA3TxwmV69Y8 Qt/0Xj+kvpkhdfQVhOTR4cHd6lEHn9VoC/nUuf8zXvqpJ98fTU/bM6thRPiHEjrkdpV+ qjUbhwYFXEQyLTn4Pb7XNvhi1QDO/qwRje+Adgu7G/08nmW5+Qgixay74JV+cicQInSv Tbrh/AKleWR6iZIu6Mwv/rfVffIoG65dtIsGASeV75SyjmxauiT1RgerLK3zmvIomD4f u2og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DHKQWGbUMCSZva8fMFVwNB5PuUJGGewFyUMV1HKUa/8=; b=hYfVBWjfEQj+FVb9oOUI89mPYIx48+H101a32sgr1e3EcZQyQqPioew50/P47UJ1fz Vtx58b412WoF/xA+9k7elUvrvMSGyhoF+IiHdpPCsN6LqkDi5671HytdBKlc2ympv2kL zVm0Y17eopKDGQ2cQvO+8ne1Z6T0IeegSh2F+97ZnKCLJc6JleVznv/tidMwGChzaLMf A7eVFkjBD2Kd1jO7VpsvtCWRYgCXx5QZgJwiF2irx7W0o6cTn217kyVedarv7564floM dABZDLpy3ZSrakWU+Q0Hvqjp3L65fcTFlxO50iNcoR0x2lNQhlVQ//j5C7AX2ObmBMxe zcJw== X-Gm-Message-State: AD7BkJJSCci6+Ayb9PT1sWK26g4CxQKPJmDw7DI8ueeetcAaItNiW8kNGvC9yf7/d3q48GiJiWz52AToWdlDkw== MIME-Version: 1.0 X-Received: by 10.31.167.195 with SMTP id q186mr3427780vke.113.1460104693357; Fri, 08 Apr 2016 01:38:13 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Fri, 8 Apr 2016 01:38:13 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Fri, 8 Apr 2016 01:38:13 -0700 (PDT) In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <57074219.2020908@gmail.com> Date: Fri, 8 Apr 2016 18:38:13 +1000 Message-ID: Subject: Re: rfc2460bis question From: Mark Smith To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=001a11425fba952559052ff51d70 Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:38:17 -0000 --001a11425fba952559052ff51d70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 Apr 2016 3:48 PM, "Stefano Previdi (sprevidi)" wrote: > > > > On Apr 8, 2016, at 7:31 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > > On 08/04/2016 16:22, Stefano Previdi (sprevidi) wrote: > >> Ole, > >> > >> I agree with your point and the point Mark (Townsley) made during the meeting. > >> > >> I think we need to evaluate better the use cases and current technology development that operators are undergoing before taking drastic architectural and protocol specification decisions. > >> > >> I=E2=80=99m not saying that everything it=E2=80=99s perfect as it is n= ow. I=E2=80=99m saying that we may have to dig more before jumping into conclusions. > > > > "Extension headers must never be deleted or changed in size by any node on the path the packet takes." > > > > There's no jumping to conclusions. We know that this breaks IPsec/AH and PMTUD. > > > in a core where header is inserted and where the mtu is over 8K I don=E2= =80=99t see how pmtud may be broken. Also, whatever you do to the packet, if you deliver it in the same shape you received it, there=E2=80=99s nothing wring= . At least from an operational perspective it=E2=80=99s happening daily. > Has anybody troubleshooted broken devices yet? What is the objection to tunneling? Regards, Mark. > > Thanks. > s. > > > > > It's explicit in 2460 that in the case of options, only the "Option Data" may change, > > not the "Option Type" or "Opt Data Len", because of AH. But the same statement is not > > made about other extension headers. As far as I'm concerned that's a clear error of omission > > in 2460. > > > > Of course inserting an extension header also breaks AH and PMTUD. > > > > "The contents of an Extension header or Option in an Extension header may be modified if this is permitted by the definition of > > the Extension header or option." > > > > That actually should be s/may/may only/ to change anything. It's more debatable > > because it doesn't damage PMTUD. But since AH is not immunised against changes > > to extension headers in the same way that it's immunised against changes in > > "Option Data", I think this is also a clear omission. > > > > The fact that AH is no longer loved by the security community is a separate issue. > > If the security community was ready to make AH Historic, that would change the > > discussion. > > > > Regards > > Brian > > > >> > >> Thanks. > >> s. > >> > >> > >> > >> > >>> On Apr 7, 2016, at 4:01 PM, otroan@employees.org wrote: > >>> > >>> Dear Brian, > >>> > >>> Thank you for your comments. > >>> > >>>>> Let me add on to the comments that I made during the meeting today: > >>>>> > >>>>> There is a high bar to introduce changes to RFC2460. Changes are limited to those described in RFC6410 in addition to "Updated by" documents= . > >>>>> > >>>>> The proposed change presented today is: (note that is updated from what is in the draft) > >>>>> > >>>>> "Extension headers must never be deleted or changed in size by any node on the path the packet takes. > >>>>> The contents of an Extension header or Option in an Extension header may be modified if this is permitted > >>>>> by the definition of the Extension header or option." > >>>>> > >>>>> There is no errata or updated-by document concerning this issue. > >>>> > >>>> Correct. But I was extremely surprised the first time I saw a proposal to > >>>> insert headers en route, since I had *always* read RFC2460 (and RFC1883) > >>>> to imply that headers are only created by the source node. So I maintain > >>>> that it is a drafting ambiguity (in RFC1883, actually) and therefore fair game > >>>> for clarification during the revisions allowed by RFC6410. > >>>> > >>>> If you really want to see it as an erratum, that would only take a few > >>>> minutes. > >>> > >>> I don't think you were alone about being surprised by those proposals= . > >>> It is an ambiguity that we have lived with in the Internet since RFC791 though. > >>> > >>>>> It is not an unused feature, since the proposal is to add new text to RFC2460. > >>>>> > >>>>> As far as I am aware, there is no interoperability issue caused by the current RFC2460 text. > >>>> > >>>> Yes there is, because it does not forbid insertion of an extension header by a third > >>>> party, whereas the interoperability model for extension headers is that both the > >>>> source and the destination need to understand the extension header (a "consenting > >>>> adults" model). An unknown inserted header will cause a lost packet: > >>>> > >>>> " If, as a result of processing a header, a node is required to proceed > >>>> to the next header but the Next Header value in the current header i= s > >>>> unrecognized by the node, it should discard the packet and send an > >>>> ICMP Parameter Problem message to the source of the packet..." > >>> > >>> What I meant was that there is no currently known interoperability problem with existing implementation or existing protocol specifications. > >>> I agree with you that there are many issues if a future specification would require to do header injection. We could deal with those issues if or when those proposals where made. > >>> > >>>> It might also cause PMTUD anomalies, too. > >>> > >>> Indeed, as far I can see it wouldn't only create anomalies but it would break it. > >>> > >>>>> And as far as I can tell the proposed addition is unlikely to create interoperability issues either. > >>>>> > >>>>> There is RFC4782, that allows for deletion of extension headers. That is an experimental RFC, and I'm unaware of what the conclusion from the experiment is. RFC791 allows the introduction of options in certain cases. > >>>>> > >>>>> Resolving how header insertion or deletion of extension headers / option is done is outside the scope of the changes we can make to 2460. > >>>> > >>>> Obviously, I disagree. > >>> > >>> I do understand your concern. We can argue if that concern should be tackled while taking 2460 to IS, or if it should be tackled whenever a proposal to do it comes up. > >>> > >>>>> Those considerations should be done in the protocol specification for those proposed extension headers / options. > >>>>> > >>>>> My current view on this, is that it would appear that like to have this additional text, not to fix an existing problem, but to fend off what should be allowed in new protocol specifications. > >>>>> > >>>>> As I said at the microphone, my position as chair is that by _default_, the text in RFC2460 is left unchanged. > >>>> > >>>> Agreed, but when that text is actually interpreted differently by different people, > >>>> which is clearly the case here, we are IMHO obliged to clarify it. > >>> > >>> I'm not sure that is true. Some level of ambiguity in specifications is good. Ambiguity equals freedom and room for innovation. > >>> > >>> In any case, if there was clear a consensus about what to say, this would be simpler. If there isn't, then saying nothing is the safer option, rather than saying the wrong thing. > >>> > >>> Best regards, > >>> Ole > >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a11425fba952559052ff51d70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 8 Apr 2016 3:48 PM, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com> wrote:
>
>
> > On Apr 8, 2016, at 7:31 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:<= br> > >
> > On 08/04/2016 16:22, Stefano Previdi (sprevidi) wrote:
> >> Ole,
> >>
> >> I agree with your point and the point Mark (Townsley) made du= ring the meeting.
> >>
> >> I think we need to evaluate better the use cases and current = technology development that operators are undergoing before taking drastic = architectural and protocol specification decisions.
> >>
> >> I=E2=80=99m not saying that everything it=E2=80=99s perfect a= s it is now. I=E2=80=99m saying that we may have to dig more before jumping= into conclusions.
> >
> > "Extension headers must never be deleted or changed in size = by any node on the path the packet takes."
> >
> > There's no jumping to conclusions. We know that this breaks I= Psec/AH and PMTUD.
>
>
> in a core where header is inserted and where the mtu is over 8K I don= =E2=80=99t see how pmtud may be broken. Also, whatever you do to the packet= , if you deliver it in the same shape you received it, there=E2=80=99s noth= ing wring. At least from an operational perspective it=E2=80=99s happening = daily.
>

Has anybody troubleshooted broken devices yet?

What is the objection to tunneling?

Regards,
Mark.

>
> Thanks.
> s.
>
>
>
> > It's explicit in 2460 that in the case of options, only the &= quot;Option Data" may change,
> > not the "Option Type" or "Opt Data Len", beca= use of AH. But the same statement is not
> > made about other extension headers. As far as I'm concerned t= hat's a clear error of omission
> > in 2460.
> >
> > Of course inserting an extension header also breaks AH and PMTUD.=
> >
> > "The contents of an Extension header or Option in an Extensi= on header may be modified if this is permitted by the definition of
> > the Extension header or option."
> >
> > That actually should be s/may/may only/ to change anything. It= 9;s more debatable
> > because it doesn't damage PMTUD. But since AH is not immunise= d against changes
> > to extension headers in the same way that it's immunised agai= nst changes in
> > "Option Data", I think this is also a clear omission. > >
> > The fact that AH is no longer loved by the security community is = a separate issue.
> > If the security community was ready to make AH Historic, that wou= ld change the
> > discussion.
> >
> > Regards
> >=C2=A0 Brian
> >
> >>
> >> Thanks.
> >> s.
> >>
> >>
> >>
> >>
> >>> On Apr 7, 2016, at 4:01 PM, otroan@employees.org wrote:
> >>>
> >>> Dear Brian,
> >>>
> >>> Thank you for your comments.
> >>>
> >>>>> Let me add on to the comments that I made during = the meeting today:
> >>>>>
> >>>>> There is a high bar to introduce changes to RFC24= 60. Changes are limited to those described in RFC6410 in addition to "= Updated by" documents.
> >>>>>
> >>>>> The proposed change presented today is: (note tha= t is updated from what is in the draft)
> >>>>>
> >>>>> "Extension headers must never be deleted or = changed in size by any node on the path the packet takes.
> >>>>>=C2=A0 The contents of an Extension header or Opti= on in an Extension header may be modified if this is permitted
> >>>>>=C2=A0 by the definition of the Extension header o= r option."
> >>>>>
> >>>>> There is no errata or updated-by document concern= ing this issue.
> >>>>
> >>>> Correct. But I was extremely surprised the first time= I saw a proposal to
> >>>> insert headers en route, since I had *always* read RF= C2460 (and RFC1883)
> >>>> to imply that headers are only created by the source = node. So I maintain
> >>>> that it is a drafting ambiguity (in RFC1883, actually= ) and therefore fair game
> >>>> for clarification during the revisions allowed by RFC= 6410.
> >>>>
> >>>> If you really want to see it as an erratum, that woul= d only take a few
> >>>> minutes.
> >>>
> >>> I don't think you were alone about being surprised by= those proposals.
> >>> It is an ambiguity that we have lived with in the Interne= t since RFC791 though.
> >>>
> >>>>> It is not an unused feature, since the proposal i= s to add new text to RFC2460.
> >>>>>
> >>>>> As far as I am aware, there is no interoperabilit= y issue caused by the current RFC2460 text.
> >>>>
> >>>> Yes there is, because it does not forbid insertion of= an extension header by a third
> >>>> party, whereas the interoperability model for extensi= on headers is that both the
> >>>> source and the destination need to understand the ext= ension header (a "consenting
> >>>> adults" model). An unknown inserted header will = cause a lost packet:
> >>>>
> >>>> "=C2=A0 If, as a result of processing a header, = a node is required to proceed
> >>>> to the next header but the Next Header value in the c= urrent header is
> >>>> unrecognized by the node, it should discard the packe= t and send an
> >>>> ICMP Parameter Problem message to the source of the p= acket..."
> >>>
> >>> What I meant was that there is no currently known interop= erability problem with existing implementation or existing protocol specifi= cations.
> >>> I agree with you that there are many issues if a future s= pecification would require to do header injection. We could deal with those= issues if or when those proposals where made.
> >>>
> >>>> It might also cause PMTUD anomalies, too.
> >>>
> >>> Indeed, as far I can see it wouldn't only create anom= alies but it would break it.
> >>>
> >>>>> And as far as I can tell the proposed addition is= unlikely to create interoperability issues either.
> >>>>>
> >>>>> There is RFC4782, that allows for deletion of ext= ension headers. That is an experimental RFC, and I'm unaware of what th= e conclusion from the experiment is. RFC791 allows the introduction of opti= ons in certain cases.
> >>>>>
> >>>>> Resolving how header insertion or deletion of ext= ension headers / option is done=C2=A0 is outside the scope of the changes w= e can make to 2460.
> >>>>
> >>>> Obviously, I disagree.
> >>>
> >>> I do understand your concern. We can argue if that concer= n should be tackled while taking 2460 to IS, or if it should be tackled whe= never a proposal to do it comes up.
> >>>
> >>>>> Those considerations should be done in the protoc= ol specification for those proposed extension headers / options.
> >>>>>
> >>>>> My current view on this, is that it would appear = that like to have this additional text, not to fix an existing problem, but= to fend off what should be allowed in new protocol specifications.
> >>>>>
> >>>>> As I said at the microphone, my position as chair= is that by _default_, the text in RFC2460 is left unchanged.
> >>>>
> >>>> Agreed, but when that text is actually interpreted di= fferently by different people,
> >>>> which is clearly the case here, we are IMHO obliged t= o clarify it.
> >>>
> >>> I'm not sure that is true. Some level of ambiguity in= specifications is good. Ambiguity equals freedom and room for innovation.<= br> > >>>
> >>> In any case, if there was clear a consensus about what to= say, this would be simpler. If there isn't, then saying nothing is the= safer option, rather than saying the wrong thing.
> >>>
> >>> Best regards,
> >>> Ole
> >>
> >
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--001a11425fba952559052ff51d70-- From nobody Fri Apr 8 03:35:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A5312D5CA for ; Fri, 8 Apr 2016 03:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yIhWSkw9YKbQ for ; Fri, 8 Apr 2016 03:35:10 -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 893B512D5A4 for ; Fri, 8 Apr 2016 03:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1102; q=dns/txt; s=iport; t=1460111710; x=1461321310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0r/lS9XO6zq3bzTr4QbNvIMrr2czMSPi2/J1JHfFYYU=; b=UkKGqiQYv+zo6maF9vdUUMjyLteU30gvXcIB09OxZSVsyAg9zqEOjbev n6YvSaIqfsU8Prh0FXHOMikIvatuo1A0NoXWNJijSSyOvnHTLazSBMNtq OSV1PFuRU0JHyGDKL/ZTqxGOb4h1p1rY5d/8yBxQxe54Nm/7VjbdZJoKa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQB6iAdX/4QNJK1cgzeBUAa6PwENg?= =?us-ascii?q?XOGDQIcgRo4FAEBAQEBAQFlJ4RBAQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEAQ0FCIgfrW2SBgEBAQEBAQEBAQEBAQEBAQEBAQEBARV8iG6BAoRVgmqCV?= =?us-ascii?q?gWYBAGOBI8UjyQBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="258932940" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 10:35:09 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u38AZ9IY014915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 10:35:09 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 06:35:08 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 06:35:08 -0400 From: "Hemant Singh (shemant)" To: "Stefano Previdi (sprevidi)" , "otroan@employees.org" Subject: RE: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRiVI+9XPFzG+wQEibDtD1Ck+sIp96ha6AgAKN7wCAAJ76AIAAHHeAgAA8zQCAANClAIAA8JGAgAAkR+A= Date: Fri, 8 Apr 2016 10:35:08 +0000 Message-ID: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> In-Reply-To: <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.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.82.246.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 10:35:12 -0000 SSBsaWtlIHdoYXQgT2xlIHByb3Bvc2VkLiAgQmVmb3JlIHRoZSBkcmFzdGljIHRleHQsIHVzZSBh ICJCeSBkZWZhdWx0LCIsIHNvIHRoYXQgb3RoZXIgYmVoYXZpb3JzIGFyZSBwb3NzaWJsZS4gIA0K DQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0 bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVmYW5vIFByZXZpZGkgKHNw cmV2aWRpKQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiAxMjoyMyBBTQ0KVG86IG90cm9h bkBlbXBsb3llZXMub3JnDQpDYzogQm9iIEhpbmRlbjsgNm1hbiBXRw0KU3ViamVjdDogUmU6IHJm YzI0NjBiaXMgcXVlc3Rpb24NCg0KT2xlLA0KDQpJIGFncmVlIHdpdGggeW91ciBwb2ludCBhbmQg dGhlIHBvaW50IE1hcmsgKFRvd25zbGV5KSBtYWRlIGR1cmluZyB0aGUgbWVldGluZy4NCg0KSSB0 aGluayB3ZSBuZWVkIHRvIGV2YWx1YXRlIGJldHRlciB0aGUgdXNlIGNhc2VzIGFuZCBjdXJyZW50 IHRlY2hub2xvZ3kgZGV2ZWxvcG1lbnQgdGhhdCBvcGVyYXRvcnMgYXJlIHVuZGVyZ29pbmcgYmVm b3JlIHRha2luZyBkcmFzdGljIGFyY2hpdGVjdHVyYWwgYW5kIHByb3RvY29sIHNwZWNpZmljYXRp b24gZGVjaXNpb25zLg0KDQpJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgZXZlcnl0aGluZyBpdOKAmXMg cGVyZmVjdCBhcyBpdCBpcyBub3cuIEnigJltIHNheWluZyB0aGF0IHdlIG1heSBoYXZlIHRvIGRp ZyBtb3JlIGJlZm9yZSBqdW1waW5nIGludG8gY29uY2x1c2lvbnMuDQoNClRoYW5rcy4NCnMuDQoN Cg0KDQo= From nobody Fri Apr 8 04:28:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E112D7C6; Fri, 8 Apr 2016 04:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 x78XUcAKApia; Fri, 8 Apr 2016 04:27:52 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239E012D6B3; Fri, 8 Apr 2016 04:27:52 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 7DCF7D7887; Fri, 8 Apr 2016 04:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; s= selector1; bh=P9pGALzfzx5HWirbEuvfz6Ix06w=; b=Pa/Lhoh/hsX/YEdkBm l3cSr7lBJTAa2KGmK8AKDacr6x9T4ryKJgSCuFxJ6i2roAncCAOl3jpe2F20Lo1B sciW25UdvrtJ+lYNH2takkZGZTpDfSnNcU6oM+Kphlkx0AhC6Bt2Dr063o6/N12T bw2YUS18gWeLwfvzdJCnrV3Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; q=dns; s= selector1; b=BOA58PxnnAtQsFLC+r7bypUUj+GkpPzxKy7LA1hSynY6QrrZMyC 1sSoFSaH30eOpNaokZX6n83CR21FOoTo0DJrXqQLzQpGoJ+b2pCtIWspaCG21fWA IDPlCHuPJ/otop/IBgu7h+lKiB75e9Wb1hsaJUdsYRdik3XsPT2qggjU= Received: from h.hanazo.no (dhcp-895e.meeting.ietf.org [31.133.137.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 40C76D7884; Fri, 8 Apr 2016 04:27:51 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CAC071437E10; Fri, 8 Apr 2016 08:27:47 -0300 (ART) From: otroan@employees.org X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: DNS AAAA for free Date: Fri, 8 Apr 2016 08:27:46 -0300 Message-Id: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: 6man WG , v6ops list Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:27:58 -0000 --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is an interesting draft being presented in dnsop today. = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 The proposal is to allow AAAA records in response to A queries. Best regards, Ole --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXB5WzAAoJEL7aWKiYQt923j0P/RnNiGRMJPMPD3utFiGqUYby IpfAPnOUiZwxnnMNlASUGmNDds/+lgmgMLoo68m2HjliC1iScXJWadJd/gR4bzqD 4EzQMTSNcKWvAa077+dgIfOQR8L2Wjet6zBYX4qsOCpjhx1znOfNUCAEE8js2Gqj M7Qe6KWsyrgycO/dF+mz6jPzULd3ILOTmjw4m+qhxGzOS4IB+Ii7mNfXv4c5+3Fb utTl+ZLb/qsQjpo7k6g5MsVA5WItP9s1LgH9uzVsNanZFki7Ckp0P6GWc8482Uzu qCbjaz/9VaOR3q/hZvQfrcPEMUKtgkCdxOAzDSj+7Jkd+2Gmdf9eHcLY8GZ6nQgM TDBfH0eO/hdtVPjh/v0xToNYRaWtfLZ3qvzx7HTD74bGzFHyoC+8GYyttcHyBSYp G8cKmOyAyqJXIxY3kYZFREeJbEXF775b3mIO7fLmXKqORophPUgVRah+wPJY+gqB x7tZg/fQ8Q2IFgWiFKZ5hzlpLSjT3zIKrJDpbIUtow1pL5qcRx1DVnN5V6+wqMXr gIMRAK0xcXsKYwcG33evBmW65F+pgbfft1usuDIj4r37yKhZ0M83elfabh/jqfq6 mEeGMwNJO8sRhN53VfTuco2ppSf5zUfGMowukgSiO4FWUZi/zX31rGWPVrReCd4D SGRjPIMutIfv1SEgJUMo =rTDj -----END PGP SIGNATURE----- --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B-- From nobody Fri Apr 8 07:15:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2300812D65D for ; Fri, 8 Apr 2016 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0PHb-dPsSJVS for ; Fri, 8 Apr 2016 07:15:32 -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 A99C412D914 for ; Fri, 8 Apr 2016 07:15:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 798332009E; Fri, 8 Apr 2016 10:18:56 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C81963755; Fri, 8 Apr 2016 10:15:17 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: draft-van-beijnum-multi-mtu-05.txt In-Reply-To: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <29889.1460046597@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:15:34 -0000 --=-=-= Content-Type: text/plain otroan@employees.org wrote: >>> In general I'd prefer that we reuse existing mechanisms for path mtu >>> discovery, and not invent new ones purely for the case of two directly >>> connected neighbors. >> >>> Could we make this work by adding the RFC4861 MTU option to NS/NA >>> messages, and require that PLMTUD probing is used to verify the end to >>> end MTU. >> >> Yes, but plmtud can only be provided as a service to applications when they >> use TCP or SCTP. It can't find bigger UDP paths at present: that would have >> to be built in to the application. But, the kernel can provide the service >> for UDP users by doing the discovery in NUD.... >> Basically we can run the plpmtud mechanism with NUD in the kernel. > UDP applications already need to do that today. Yes, that's a good point. In v4-land, we can just send and experience fragmentation. In v6, we can't, so most WAN applications that care about >1280 always include fragmentation at that level regardless. So you are right: the applications already do it. There is a class of application that is today running over LANs using UDP. I recall the days of "HIPPI" which had 64K packet sizes doing stuff. I have an ATSC TV tuner that does this, and I've seen IP audio applications that also do the same. Right now, I think they don't even have default route support... I think that those devices could benefit from the ND solution. > Isn't it a great step backwards if an application first has to detect > if the peer is directly connected or not, and behave differently > depending on the answer? Yes, that's a good point. So I withdraw my suggestion... the question is perhaps, can we come up with a slightly application-neutral way to do plpmtud. I suspect that SPUD already provides this. > Path MTU is a path property. I'm reluctant to make too much out of a > special case where path length is 1. > I do agree that we need to do something in ND to allow nodes capable of > a higher MTU than the RA advertised default MTU to signal that between > each other. Good. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVwe88oCLcPvd0N1lAQJplgf/f4LvSWzj61NwG7g6vS2U66ZA4QSG5Dh3 oFmSQIZIRQiABzaBRort9PeGlvGuxhEq7tDpEIUdDL+B7Q108h1mTgrZeXkz7ccx Tr9bJKP+KADBDA34fhDrraECPXgUMbKv2N438PCs5nIPjh3JgWnH5fRwpsfXGYDk dRDkEM9r8/CI14gVe0IDEBvIaQHSXg098KIGeaYRm3n+Vl1/q54/H+63BySPS16l Vwo89oI48VXULTduUr1B/7vG4hZl4cV+eZ287Ez+A2MQKYrrylYBhUrPeawWxDE8 TjRsJBmXvnRVoscUDXc+VYtovOvvPeunKStn1gWPtlroJhdFg8i9Fg== =E52N -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 8 11:29:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0371A12D5A7 for ; Fri, 8 Apr 2016 11:29:55 -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 FzPRHlkG5jeQ for ; Fri, 8 Apr 2016 11:29:52 -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 8DA1C12D597 for ; Fri, 8 Apr 2016 11:29:52 -0700 (PDT) Received: from [192.168.3.107] (unknown [181.165.122.68]) (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 C601380D92; Fri, 8 Apr 2016 20:29:46 +0200 (CEST) Subject: Re: rfc2460bis question To: "Stefano Previdi (sprevidi)" , "otroan@employees.org" References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5707F80C.9030602@si6networks.com> Date: Fri, 8 Apr 2016 15:27:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:29:55 -0000 On 04/08/2016 01:22 AM, Stefano Previdi (sprevidi) wrote: > Ole, > > I agree with your point and the point Mark (Townsley) made during the > meeting. > > I think we need to evaluate better the use cases and current > technology development that operators are undergoing before taking > drastic architectural and protocol specification decisions. There are no drastic decision. It's a clarification about a part of the spec that, while evident to the authors and other folks, was not spelled out clearly, and should be. 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 8 11:54:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5F112D54A for ; Fri, 8 Apr 2016 11:53:59 -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 W4nPe6XUA5S7 for ; Fri, 8 Apr 2016 11:53: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 4A0CB12D510 for ; Fri, 8 Apr 2016 11:53:58 -0700 (PDT) Received: from [192.168.3.107] (unknown [181.165.122.68]) (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 396FA800B8; Fri, 8 Apr 2016 20:53:53 +0200 (CEST) Subject: Re: rfc2460bis question To: "Stefano Previdi (sprevidi)" References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <57068CBD.8020704@si6networks.com> <19F7120B-8163-436B-AA20-2E7A404C8871@cisco.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5707FD96.3060506@si6networks.com> Date: Fri, 8 Apr 2016 15:51:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <19F7120B-8163-436B-AA20-2E7A404C8871@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:54:00 -0000 On 04/08/2016 01:21 AM, Stefano Previdi (sprevidi) wrote: >>>> " If, as a result of processing a header, a node is required to >>>> proceed to the next header but the Next Header value in the current >>>> header is unrecognized by the node, it should discard the packet >>>> and send an ICMP Parameter Problem message to the source of the >>>> packet..." >>> >>> What I meant was that there is no currently known interoperability >>> problem with existing implementation or existing protocol >>> specifications. I agree with you that there are many issues if a >>> future specification would require to do header injection. We could >>> deal with those issues if or when those proposals where made. >> >> Working on revised protocol spec an intentionally keeping a well-noted >> ambiguity is a bad idea, and would be a poor job on our side. > > it’s not "keeping an ambiguity†just for fun. Ambiguity in a protocol specification is a bad thing. If you want to change RFC2460 to allow for the insertion of EHs, that's fair enough: write an I-D. THer might be valid reasons for that. But inserting EHs is not part of RFC2460. So rfc2460bis should clarify this. And if we want that to change, there's a process for that. > It’s waiting to have the correct analysis prior to decide which behavior to mandate. It's the other way around: that behavior is already mandated. Just not clearly stated in the specs. -- that's why rfc2460bis should include a clarification. > We can’t really ignore what the industry is working at, can we ? We're not ignoring anything. For instance, segment routing is a work item of this wg. And the decision of this wg was to employ encapsualtion (rather than header insertion, which would violate RFC2460). 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 8 14:24:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F312F12D665 for ; Fri, 8 Apr 2016 14:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] 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 qjxLREeZAtmU for ; Fri, 8 Apr 2016 14:24:01 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD16212D58F for ; Fri, 8 Apr 2016 14:24:01 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 588A1D7887; Fri, 8 Apr 2016 14:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=PDiZCXbloFt6KjyzVKzEfYR5eh4=; b= SobLeWcUwzpSC+OZ6PL5ozJPIhcsJI7jcDhGH5A9nITdRbSsW3H2uLbk7qLeQbE5 7gLpNpgEZYruNeGFsCx2V5lOyD4TMFNMRp8exg0nCsPrExPHo1najAU5We2w4XCy W1Mr3tiI7BGEuMb1d5ho/RSbSB5e5YeEjkjxzSGb0YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ryt0jzR+/31yraF2Xvrk1a2D79 NlfgcEoTqaewWcLKI+YsK3vI3pcZz7w5WZySVSjMbDk/a7n+2Rjc58g7OBfeD8LA gW6igiOJnnpoNvgPlde9+u5mkpMAfipwtmF9zQhfs+t5kUugp9Jvd5yzn9TN9EzU 6diOpdk/2tDWBneHA= Received: from h.hanazo.no (unknown [88.128.83.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id BF0A3D7884; Fri, 8 Apr 2016 14:23:59 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 17C81143BD64; Fri, 8 Apr 2016 18:23:48 -0300 (ART) Subject: Re: rfc2460bis question Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A93A3E47-0B03-493B-9CAD-20F6D5B46BD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Fri, 8 Apr 2016 18:23:47 -0300 Message-Id: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> To: 6man WG X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:24:04 -0000 --Apple-Mail=_A93A3E47-0B03-493B-9CAD-20F6D5B46BD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let me clarify what my position is, since there are some nuances here. While a discussion on header insertion may be necessary, it is not in = context for taking RFC2460 to IS. If a proposal is made, then the = working group should discuss that in the context of that proposal. The RFC2460 text has not caused interoperability issues. Which is why = I'm not convinced this change was required. The default action, unless we can come to a different agreement, is to = leave the RFC2460 text unchanged in RFC2460bis. Please do not view that as if I am condoning header insertion. That = would have to be future work. RFC2460 is clear that routers should not = look further into packets than the base IPv6 header. Best regards, Ole --Apple-Mail=_A93A3E47-0B03-493B-9CAD-20F6D5B46BD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXCCFjAAoJEL7aWKiYQt92v1QQAJYG6ZTZBPCBLpqP9vBZY33J XnoSOCcQEPsJjSLXMsHE/zZs0e6emWRpFY4eVBMHRc9MIJRhH4vlrq9J4xwWHAR4 E8+D8A4rC0HrJHJCBY5Axr6+XsOngDhTGU8DRyy7QhK3yaxoQO09pUtnX/VsqZb+ SZuLlBJCoCW1dq2hBEdR/DxBj/lnYi8YpzPC92/OYUJ+v9eeMtyM726po4fjAqBl qNA7LQk2dsPFAcr4vcZwdf5Fd2LgMk3CaSpzFnk1qoA4v7J7U5Yqe0r82BzEO9IR eskQwbRvBXqyxStuGEP96C1GSd4NbYfvSIyoHrCYxcEsJsSsTBKSCJct67r+wfHI y4lflsRmZ5Q3MfO/SDc7Po9uDe0ZcevpA4ArDkJhOtjE/hvjY0nCcglqq02tUIGF VDZKUk/anSot2epnwBi+6bD3cWC0ZSPFNwp8o+hxjFMwGdshRbl/HpQX7ak/M6Qp 8BnsfMdUw+Bq8cYtcHubKhvN0rtClqt07PFIqDzt8L9l6M1bWakpUKgKcMPIGQul DM8i9ADUTgIJev/57WUlBEgDRMz9U8RIIaElUEAGmPpVUds0fS72YmK+KQN7u1jF WDc07hLNJqAM99IAXIVDMeunRdmTq8qJd1WH7Uwvd7THXwB40UNV9II8i2laCoCp 3dVHzKvOnQPUjQfdMVJR =n43s -----END PGP SIGNATURE----- --Apple-Mail=_A93A3E47-0B03-493B-9CAD-20F6D5B46BD2-- From nobody Fri Apr 8 14:35:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180712D6D8 for ; Fri, 8 Apr 2016 14:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AyVdLRFhL-7C for ; Fri, 8 Apr 2016 14:35:08 -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 D841812D5EC for ; Fri, 8 Apr 2016 14:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1051; q=dns/txt; s=iport; t=1460151307; x=1461360907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bbRPqGwRUD2b0if2YYsB+GQxY5rShnQ51o7m4qS+JPA=; b=XieiQ+pdojB0TqvJH7CcqX2+KZ98WdrKROzqsru51xXPobdVzCERaPDC TNInDzO1f5ElpBLEWPY8KeK7SwK5S0zrQSv9F7p9e7mMy9mmbcsZdWaFf A3dbAertM+y0F5JJCAthQuuCg9PPo5QQosnCOPjw9VXumPE2e1njjfYdp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDeIwhX/5JdJa1cgzeBUAa6QgENg?= =?us-ascii?q?XOGDQKBMzgUAQEBAQEBAWUnhEEBAQEEOj8MBAIBCBEEAQEfCQcyFAkIAgQBDQU?= =?us-ascii?q?IiB/AdQEBAQEBAQEBAQEBAQEBAQEBAQEBARWKbIoVAQSYBAGOBIFuhE2IWY8kA?= =?us-ascii?q?R4BAUKDZ2yIO34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="259075659" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 21:34:43 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u38LYgYw005821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 21:34:42 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 17:34:42 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 17:34:42 -0400 From: "Hemant Singh (shemant)" To: "otroan@employees.org" , 6man WG Subject: RE: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRiVI+9XPFzG+wQEibDtD1Ck+sIp96ha6AgAKN7wCAAJ76AIAAHHeAgAA8zQCAANClAIAA8JGAgAAkR+CAAPjwgP//v/FQ Date: Fri, 8 Apr 2016 21:34:41 +0000 Message-ID: <952867b558d2498bb995480710f9302a@XCH-RTP-005.cisco.com> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> In-Reply-To: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> 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.82.170.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:35:09 -0000 Ole, Sounds reasonable to me - thanks. Hemant -----Original Message----- From: otroan@employees.org [mailto:otroan@employees.org]=20 Sent: Friday, April 08, 2016 5:24 PM To: 6man WG Cc: Stefano Previdi (sprevidi); Bob Hinden; Hemant Singh (shemant) Subject: Re: rfc2460bis question Let me clarify what my position is, since there are some nuances here. While a discussion on header insertion may be necessary, it is not in conte= xt for taking RFC2460 to IS. If a proposal is made, then the working group = should discuss that in the context of that proposal. The RFC2460 text has not caused interoperability issues. Which is why I'm n= ot convinced this change was required. The default action, unless we can come to a different agreement, is to leav= e the RFC2460 text unchanged in RFC2460bis. Please do not view that as if I am condoning header insertion. That would h= ave to be future work. RFC2460 is clear that routers should not look furthe= r into packets than the base IPv6 header. Best regards, Ole From nobody Sat Apr 9 00:55:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20112D09D; Sat, 9 Apr 2016 00:55:35 -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, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001] 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 pfZQ3PMfzY-p; Sat, 9 Apr 2016 00:55:34 -0700 (PDT) Received: from mail.gguy.me (2001-44b8-314b-5f01-62a4-4cff-fe5f-1144.static.ipv6.internode.on.net [IPv6:2001:44b8:314b:5f01:62a4:4cff:fe5f:1144]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F392512D0C7; Sat, 9 Apr 2016 00:55:33 -0700 (PDT) Received: from [192.168.1.102] (ppp59-167-129-219.static.internode.on.net [59.167.129.219]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.gguy.me (Postfix) with ESMTPSA id 17EE536200BB; Sat, 9 Apr 2016 17:55:31 +1000 (AEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: DNS AAAA for free From: Geordie Guy X-Mailer: iPhone Mail (13E234) In-Reply-To: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> Date: Sat, 9 Apr 2016 17:55:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: otroan@employees.org Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 07:55:36 -0000 This is genuinely awesome.=20 Geordie Sent from my mobile. Please excuse any unusual brevity or typos while I'm on= the go.=20 > On 8 Apr 2016, at 9:27 PM, otroan@employees.org wrote: >=20 > Here is an interesting draft being presented in dnsop today. > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 >=20 > The proposal is to allow AAAA records in response to A queries. >=20 > Best regards, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Apr 9 03:55:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9C12D0E6; Sat, 9 Apr 2016 03:55: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UgKezw3pyEO; Sat, 9 Apr 2016 03:55:14 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 66D9D12D0BB; Sat, 9 Apr 2016 03:55:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A547838; Sat, 9 Apr 2016 12:55:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1460199309; bh=4W+o1sPFvXJfBB4RHmBskjwW/V50 m/j3COY2A2a5w0E=; b=H2fvv1QO7l38sOz2kxayHoEJ7Tl+k0HW+ArU9wzyU4p6 4IaiMLHlWFmFCloNAoIsu0fslL5r+8B71gF24xLzpJdKI/y+8bdUU5JF6bL97vxf Lcr1D9r9/OOqzT/GCq8oNruR9s6MFFU6C9j7r1PDghOI3eKyUqB53AgeAun9AbQ= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YpcSBgfCY9BC; Sat, 9 Apr 2016 12:55:09 +0200 (CEST) Received: from [IPv6:2a00:8640:1::3c8b:3db7:267:4e94] (unknown [IPv6:2a00:8640:1:0:3c8b:3db7:267:4e94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 800B337; Sat, 9 Apr 2016 12:55:06 +0200 (CEST) Subject: Re: DNS AAAA for free Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> Date: Sat, 9 Apr 2016 12:55:05 +0200 Message-Id: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 10:55:16 -0000 --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: >=20 > Here is an interesting draft being presented in dnsop today. > = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 >=20 > The proposal is to allow AAAA records in response to A queries. One question: if clients send requests for both A and AAAA records = simultaneously, how will including the AAAA answer in the A request = help? The client will just get the AAAA answer twice: once on the A = request and once on the AAAA request. If lookups were serialised and the = A request/response was completed before starting the AAAA request it = would make the second request unnecessary, but that's not what I see in = practice... It looks like good intentions, I'm just trying to figure out how this = would work in practice :) Cheers! Sander --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXCN+JAAoJEKAtA7D+JBO5zugH/iRbnTGny3OJ1r6QyEuJJyDJ qvFvGgzNqewxmx9TuP9AEV8cdlcFo3tOTOvZW+pLBq6XSpJioSn9brA0UtS2gFfV mNG5s++qvZhlspxU3zRPJGIy8hrgyOLJe7/rO0DAbY4QEHG9Yxc23MWd/25z0Cdv Q2GlGfRFMiZL3Ml4cjg8r3zigRC3bVIRUmq4o28fgFhKRZDVu4IjQ7XnI2/m5+gS +GVsJwzLA7G5RhTu8z8d878Sq/emCe8dfAAuFVlch+UrHciwdehO8kTjNnI6NMit mJHrLQy/QB2WGP5ZLUCQTc1zdSF2+kuxtWpq++e/8D4nMIXw4lXU6cS7WwfSAvo= =b0Py -----END PGP SIGNATURE----- --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF-- From nobody Sat Apr 9 06:11:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3D12D69B; Sat, 9 Apr 2016 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.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=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 l9-TNCZ6FV_S; Sat, 9 Apr 2016 06:11:12 -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 3E66012D69A; Sat, 9 Apr 2016 06:11:12 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id e185so166820082vkb.1; Sat, 09 Apr 2016 06:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rNhXv2jjs5r/ChBBNbmkrVSX/H+m3LIwdO0cyxuHnIU=; b=t8+Fj361+iAe/u7lqzRPZMhK5p9zDbGR0yY1kEcPl2qT31lcvnDavZE9R1VzDXho8U 8xE8eqKBxklXvrHBqBbUMoSypTCd8gc7Aj8rqB40rmFRIA6CaXiS5KBi6xFe54rgDjFe HcH6zvn7rH0Gj+XvzK5GnYkK3jui/WIA3bCT+Ykc/pTsROZsDWJoryYVZ14SxoNMEyKs +wQdzyS6m0Dzfd2CUydJNu+XJV3iIWqo5H/89ft3dJDj/e4KSBYrfZzm3As4kMhVEa9j YAH7IGPzdSldnhkgjXNiYH3QM8TaJbzRqF0OxCFprqiQFKmfOQaq4jLD6D/hPVAPuiyw G3Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rNhXv2jjs5r/ChBBNbmkrVSX/H+m3LIwdO0cyxuHnIU=; b=IhpTYbAAQXlS2Cpn/6XvhKBrFHDNBI7lyR+4kjSXYvGnRZUjhUIcdBotIfCp8rOion FlfCsK+6UwS8OpnGXZQEud3ka1HgHDxD4003G8UL4uL4wTNcsBcvNQMlR6hdR+5iHF7L Cfrww8AL+EPkawKZ2V0N0e2HU6HZicn/yICRIT8XtzGaRt58fXDE0+JuyH/EMm0PXjoW ZcGmmSBOccfFklDd7fiI8eX4IXI3rjQd69py8KI0JzZJsGWUk24fyWIYukMBScd8oFP6 tRg6emfFv00IngMbO5WNoUz/twk2qWfZeYP3PVfKEjogecG96ilG5cQgutFEsdofB1vH ApGQ== X-Gm-Message-State: AD7BkJL8jsw8XIqqTiMpYH05HuIDdZ9PxxMDjzm89Vu54vhIiUAmpF3uC9huNOIZEhCSfumkgUyIZLvJIH7q+g== MIME-Version: 1.0 X-Received: by 10.31.54.75 with SMTP id d72mr6644899vka.30.1460207471332; Sat, 09 Apr 2016 06:11:11 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sat, 9 Apr 2016 06:11:11 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sat, 9 Apr 2016 06:11:11 -0700 (PDT) In-Reply-To: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 23:11:11 +1000 Message-ID: Subject: Re: DNS AAAA for free From: Mark Smith To: Sander Steffann Content-Type: multipart/alternative; boundary=001a11430a1ea0946d05300d0b1d Archived-At: Cc: 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 13:11:14 -0000 --001a11430a1ea0946d05300d0b1d Content-Type: text/plain; charset=UTF-8 On 9 Apr 2016 8:55 PM, "Sander Steffann" wrote: > > Hi, > > > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: > > > > Here is an interesting draft being presented in dnsop today. > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > The proposal is to allow AAAA records in response to A queries. > > One question: if clients send requests for both A and AAAA records simultaneously, how will including the AAAA answer in the A request help? The client will just get the AAAA answer twice: once on the A request and once on the AAAA request. If lookups were serialised and the A request/response was completed before starting the AAAA request it would make the second request unnecessary, but that's not what I see in practice... > > It looks like good intentions, I'm just trying to figure out how this would work in practice :) > Having briefly looked at it, it seems there is an efficiency benefit. However, answering an A query with both an A and AAAA response might incentivise just sending A queries. Perhaps the opposite would be better - sending an AAAA query would result in an AAAA and A answer. That might create a small and subtle incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures. Regards, Mark. > Cheers! > Sander > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11430a1ea0946d05300d0b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> Hi,
>
> > On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> > https://datatracker.ietf.org/doc/draft-vavr= usa-dnsop-aaaa-for-free/?include_text=3D1
> >
> > The proposal is to allow AAAA records in response to A queries. >
> One question: if clients send requests for both A and AAAA records sim= ultaneously, how will including the AAAA answer in the A request help? The = client will just get the AAAA answer twice: once on the A request and once = on the AAAA request. If lookups were serialised and the A request/response = was completed before starting the AAAA request it would make the second req= uest unnecessary, but that's not what I see in practice...
>
> It looks like good intentions, I'm just trying to figure out how t= his would work in practice :)
>

Having briefly looked at it, it seems there is an efficiency= benefit. However, answering an A query with both an A and AAAA response mi= ght incentivise just sending A queries.

Perhaps the opposite would be better - sending an AAAA query= would result in an AAAA and A answer. That might create a small and subtle= incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 f= ailures.

Regards,
Mark.=C2=A0

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

--001a11430a1ea0946d05300d0b1d-- From nobody Sat Apr 9 07:32:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57FF12B006; Sat, 9 Apr 2016 07:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 MQs-UXVcYPWH; Sat, 9 Apr 2016 07:32:56 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E6A12009C; Sat, 9 Apr 2016 07:32:56 -0700 (PDT) Received: from [192.168.1.44] ([68.41.30.73]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0Lhwwu-1bc04e1ZTe-00n9FX; Sat, 09 Apr 2016 16:32:50 +0200 Subject: Re: DNS AAAA for free Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: James R Cutler In-Reply-To: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 10:32:38 -0400 Message-Id: References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> To: otroan@employees.org X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:7rmSkndSw0EZSZnsxx8K+v7Uw70VJNQCS5MFP15vq9HANoSPC6h I2AfiiFKuBjHW5AK7HTpEoOFdPb+NT1/hCTSIKEV15VYqYreQjlQon+F7UAjsrxsC+WLs2Y AvSBPo+efpkUWI3qDjTqC9nhSJdvjqoCpZslTnZiJgwE3R01tbCmxqnaVLQjOggB37hbhZx Vx7bVPbKjlykcdZyF7wvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OmGe4s2nb2M=:XDEl8/LLCI0ht2bKsVQQ/T R6RgG5yD1OlSog26LsoyW+6+y3ZsAPwmgQ4D1ENVy3ElYoNEKzXuPmkjt0Q+qgSnY7NQWixxr 5pmcmC6n7U2HYb3jkEgrpdJEqIO8HMXRQI/co6BippiFbWipxnRpVtjeaOMQ5DH4KIAITlfFy yk7XKvHU/WbIcJx5VPe0th+mG7g0b5KQ9V9Gstq/2CWvMkGXiRjIcDQw4iRiQCMZLltva0mzC amo2xORifW2AeLNv/mWF4dZri8CG+ZjoQHW5bi3ozDnEQOJZQ52JNBnD2L4przFcVQsyxIjob Nh9uuqLbtG/uGpG6GpfQY6U63dCHWml5sZySc1UAMkLgy5QmCqt3+CE/pBlZfie2k7BDAVzVU yqH/VnpEFubE8ufUM7jhPyhoWHD142yppT3Y35wJybndj8tTdjpZa9yaQ14pGY3S8qzIgUEFL /ewfIe7aSihVWUlahvgwjS48igfPmdDCc55hO2vAVtvCtU95VN5GRNjnnrruMoN6O+ayVxHw6 vpDwg7sS/rKowSQcdk4OqVj+bZYREjIG53KbLCtJbMdl6K5BsXW19OG08pud+icmBLwv6FyKQ eCvpe605eMw6OXSnobLDkudeBMckhP76AWqix0LcP2sc7BCmAqa6p5Wv/mGsGmdotOCYbh76u 2h0zGuESkfJ6x+yLlRR4Q2JCgHot9FKPobvr7warR8HPq4bhqnCPSeJhKCA/rjw0MYGbasmvS LMTOOYuOT7HaXu+LaMvJCm3dNUuRDvMXAOuzqm6U4616ghbo6NA5uAh6aN8= Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:32:58 -0000 --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE" --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Apr 2016, at 13:27, otroan@employees.org = wrote: >=20 > Here is an interesting draft being presented in dnsop today. > = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 = >=20 > The proposal is to allow AAAA records in response to A queries. In most conversations it is considered polite to answer the question = asked and not to provide confusing extra data. This proposal violates = that. James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 08 Apr 2016, at = 13:27, otroan@employees.org wrote:

Here is an interesting draft being presented = in dnsop today.
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-f= ree/?include_text=3D1

The proposal is = to allow AAAA records in response to A = queries.

In most = conversations it is considered polite to answer the question asked and = not to provide confusing extra data. This proposal violates = that.

James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu


= = --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE-- --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXCRKPAAoJEFTPx1V3wJTLVwkQALKKmm9Y3HCQCj7mGreB2oOk tt8+oD66HQzpjzsJCpQmkhJrSIkobhmOIi1k87XAN2GmNRcUZ03yvfhQD/Hs4AtY nfBESZ7P6/5UsJR551MRaZbUyKurQRBOlKGqVJOWW3FopljbmXRThd6RzE2VR9az qlVHIvkBKl/euKJAsSa0FqwTSk825q2uCctyf/Z0R8Rl503I//DHIXEiaX2o4xb/ gIeKa/SwGuC4sXd9mtvBRMcjQny+SEepLGSU270/Db2bGsxeBbUmnInG3TA1Jq2+ ZdnT6R6LixHXdjUzYAQSUne8qM6dhaZI6K0O7SMuLP9KWd7QIuCimn8xAfwdDin0 rp2qTAfAEwVUjKt58g1i3D7VMaMdDmKhKSncC9daWyBOm8AieS1T017uOqXxvFSq 8i9TAOzcYeDmLhTzd4opYecpG73vLcW+VkIRI/hdi0boSV/GBQFOGlhQFscFYA5B 9KHmKwgN84gVaEfLeWvdr4hq5175g8MfwAFL1D8yBK1an39gvWRZIMJ0FyiRjQKf QaKgqImGrQZafWH9LQpCrS1wntmO3YOSK2gNT+n5a82UGfxDC8Kmjrgf/a4z5Iv7 /1rEGO93mj9DTLmYzh1jg2kA2oBFqk5jvxxVFkEr1JLwiRFgf8+5NMjdJklg+cqc dBeUDsak3Ulsu2t+4H7G =KVNn -----END PGP SIGNATURE----- --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7-- From nobody Sat Apr 9 07:36:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADD12B00C for ; Sat, 9 Apr 2016 07:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 YJurF-fUWPyu for ; Sat, 9 Apr 2016 07:36:20 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 BDD0D12009C for ; Sat, 9 Apr 2016 07:36:19 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id f105so88909809qge.2 for ; Sat, 09 Apr 2016 07:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=HPvapAXiAQ6JgMNIWu7jKuCUFoQn3H3ZrNGSv3AJeIk=; b=tHP7L2Dyh095mY3W1KiosKL2rjDBR6mIHnYx6pagxC5ha0H81NdY2U4FcCJ2zYBaQX rn3h25geKPGn/xFyzP8rkBNE0pKjzwaMn31d8lVoZ/4XKnmVNtO08yYg70QJv0X6/Mbz bukStMM2WoP9LqdsBCjhkTXEiM8U5Ow5aJzqKyBC/Qf+FzO3p9gSpxWncHi0OcCwl+IZ NHl0lanEAci/MIp2nnCETDdMALgB+XTfSI+coktvtIqMjqMYYi+y0hx5NjJcEn1+oClk 2VtJJy3qdzdLHF3S8e3wdkPRDYux9VaPA2viFlr/HiMYyHMJN5U6L5gPP0MBjQxml0ZA i9Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=HPvapAXiAQ6JgMNIWu7jKuCUFoQn3H3ZrNGSv3AJeIk=; b=CtH+Q5yDkER0p6KaLVT7AXwTwPGPz6biKYzyh7cgcDzBZjUUIOA5RS67T8eL/LDfU8 2LT8o+2ybGfiNZNrqBEa5DPKGtPSBa3AsKZ86THgAQfxRVIYq58rc6HDHJLIh5kH8MH+ /Zi6fLMXj17c0v0t8bDWNE8T4gliTS3AWSn/msvcxb+zyEjkKGfftQUHfe8E+6GPBmqa fGWl322GGMhCtTJp1NX4qJzVipxob7riMYrJS4rin+m3fbtc0MHVyJ4y9WVvy+mdKB1Q p7pG5IchZVJNuNgPi23brkbvYFathXUu5cp3beubhhY90Higj28+w0nU7G/u7d4KNmsD qLgw== X-Gm-Message-State: AD7BkJK+IgxKiCwE3cbcTkA4SF7ir79SdUbDXk1osnTOEpS+G6svJU7u8KsXt7vcD3/RPJs43XhCShg4iSzSIA== MIME-Version: 1.0 X-Received: by 10.140.38.199 with SMTP id t65mr17979031qgt.64.1460212578841; Sat, 09 Apr 2016 07:36:18 -0700 (PDT) Received: by 10.140.28.166 with HTTP; Sat, 9 Apr 2016 07:36:18 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Apr 2016 15:36:18 +0100 Message-ID: Subject: Re: ipv6 Digest, Vol 144, Issue 21 From: Badr Harrou To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=001a11c12c560efb9205300e3c20 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:36:22 -0000 --001a11c12c560efb9205300e3c20 Content-Type: text/plain; charset=UTF-8 Thanks :) On 9 April 2016 at 15:32, wrote: > Send ipv6 mailing list submissions to > ipv6@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipv6 > or, via email, send a message with subject or body 'help' to > ipv6-request@ietf.org > > You can reach the person managing the list at > ipv6-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6 digest..." > > > Today's Topics: > > 1. Re: rfc2460bis question (otroan@employees.org) > 2. RE: rfc2460bis question (Hemant Singh (shemant)) > 3. Re: DNS AAAA for free (Geordie Guy) > 4. Re: DNS AAAA for free (Sander Steffann) > 5. Re: DNS AAAA for free (Mark Smith) > 6. Re: DNS AAAA for free (James R Cutler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Apr 2016 18:23:47 -0300 > From: otroan@employees.org > To: 6man WG > Cc: Bob Hinden > Subject: Re: rfc2460bis question > Message-ID: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> > Content-Type: text/plain; charset="us-ascii" > > Let me clarify what my position is, since there are some nuances here. > > While a discussion on header insertion may be necessary, it is not in > context for taking RFC2460 to IS. If a proposal is made, then the working > group should discuss that in the context of that proposal. > > The RFC2460 text has not caused interoperability issues. Which is why I'm > not convinced this change was required. > > The default action, unless we can come to a different agreement, is to > leave the RFC2460 text unchanged in RFC2460bis. > > Please do not view that as if I am condoning header insertion. That would > have to be future work. RFC2460 is clear that routers should not look > further into packets than the base IPv6 header. > > Best regards, > Ole > > > > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 842 bytes > Desc: Message signed with OpenPGP using GPGMail > URL: < > https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160408/883795f5/attachment.asc > > > > ------------------------------ > > Message: 2 > Date: Fri, 8 Apr 2016 21:34:41 +0000 > From: "Hemant Singh (shemant)" > To: "otroan@employees.org" , 6man WG > > Cc: Bob Hinden > Subject: RE: rfc2460bis question > Message-ID: <952867b558d2498bb995480710f9302a@XCH-RTP-005.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > Ole, > > Sounds reasonable to me - thanks. > > Hemant > > -----Original Message----- > From: otroan@employees.org [mailto:otroan@employees.org] > Sent: Friday, April 08, 2016 5:24 PM > To: 6man WG > Cc: Stefano Previdi (sprevidi); Bob Hinden; Hemant Singh (shemant) > Subject: Re: rfc2460bis question > > Let me clarify what my position is, since there are some nuances here. > > While a discussion on header insertion may be necessary, it is not in > context for taking RFC2460 to IS. If a proposal is made, then the working > group should discuss that in the context of that proposal. > > The RFC2460 text has not caused interoperability issues. Which is why I'm > not convinced this change was required. > > The default action, unless we can come to a different agreement, is to > leave the RFC2460 text unchanged in RFC2460bis. > > Please do not view that as if I am condoning header insertion. That would > have to be future work. RFC2460 is clear that routers should not look > further into packets than the base IPv6 header. > > Best regards, > Ole > > > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 9 Apr 2016 17:55:30 +1000 > From: Geordie Guy > To: otroan@employees.org > Cc: v6ops list , 6man WG > Subject: Re: DNS AAAA for free > Message-ID: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> > Content-Type: text/plain; charset=us-ascii > > This is genuinely awesome. > > Geordie > > Sent from my mobile. Please excuse any unusual brevity or typos while I'm > on the go. > > > On 8 Apr 2016, at 9:27 PM, otroan@employees.org wrote: > > > > Here is an interesting draft being presented in dnsop today. > > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > The proposal is to allow AAAA records in response to A queries. > > > > Best regards, > > Ole > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > ------------------------------ > > Message: 4 > Date: Sat, 9 Apr 2016 12:55:05 +0200 > From: Sander Steffann > To: otroan@employees.org > Cc: v6ops list , 6man WG > Subject: Re: DNS AAAA for free > Message-ID: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: > > > > Here is an interesting draft being presented in dnsop today. > > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > The proposal is to allow AAAA records in response to A queries. > > One question: if clients send requests for both A and AAAA records > simultaneously, how will including the AAAA answer in the A request help? > The client will just get the AAAA answer twice: once on the A request and > once on the AAAA request. If lookups were serialised and the A > request/response was completed before starting the AAAA request it would > make the second request unnecessary, but that's not what I see in > practice... > > It looks like good intentions, I'm just trying to figure out how this > would work in practice :) > > Cheers! > Sander > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 455 bytes > Desc: Message signed with OpenPGP using GPGMail > URL: < > https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/ebc82e8f/attachment.asc > > > > ------------------------------ > > Message: 5 > Date: Sat, 9 Apr 2016 23:11:11 +1000 > From: Mark Smith > To: Sander Steffann > Cc: 6man WG , v6ops list > Subject: Re: DNS AAAA for free > Message-ID: > rUmGWMWCtWRgXg@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On 9 Apr 2016 8:55 PM, "Sander Steffann" wrote: > > > > Hi, > > > > > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: > > > > > > Here is an interesting draft being presented in dnsop today. > > > > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > > > The proposal is to allow AAAA records in response to A queries. > > > > One question: if clients send requests for both A and AAAA records > simultaneously, how will including the AAAA answer in the A request help? > The client will just get the AAAA answer twice: once on the A request and > once on the AAAA request. If lookups were serialised and the A > request/response was completed before starting the AAAA request it would > make the second request unnecessary, but that's not what I see in > practice... > > > > It looks like good intentions, I'm just trying to figure out how this > would work in practice :) > > > > Having briefly looked at it, it seems there is an efficiency benefit. > However, answering an A query with both an A and AAAA response might > incentivise just sending A queries. > > Perhaps the opposite would be better - sending an AAAA query would result > in an AAAA and A answer. That might create a small and subtle incentive to > use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures. > > Regards, > Mark. > > > Cheers! > > Sander > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/03f3b360/attachment.html > > > > ------------------------------ > > Message: 6 > Date: Sat, 9 Apr 2016 10:32:38 -0400 > From: James R Cutler > To: otroan@employees.org > Cc: v6ops list , 6man WG > Subject: Re: DNS AAAA for free > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > > On 08 Apr 2016, at 13:27, otroan@employees.org otroan@employees.org> wrote: > > > > Here is an interesting draft being presented in dnsop today. > > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > < > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > > > The proposal is to allow AAAA records in response to A queries. > > In most conversations it is considered polite to answer the question asked > and not to provide confusing extra data. This proposal violates that. > > James R. Cutler > James.cutler@consultant.com > PGP keys at http://pgp.mit.edu > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 872 bytes > Desc: Message signed with OpenPGP using GPGMail > URL: < > https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5/attachment.asc > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ipv6 mailing list > ipv6@ietf.org > https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------ > > End of ipv6 Digest, Vol 144, Issue 21 > ************************************* > --001a11c12c560efb9205300e3c20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks :)

On 9 April 2016 at 15:32, <ipv6-request@ietf.org> wrote:
Send ipv6 mailing li= st submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipv6@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l= istinfo/ipv6
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipv6-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipv6-own= er@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6 digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: rfc2460bis question (otroan@employees.org)
=C2=A0 =C2=A02. RE: rfc2460bis question (Hemant Singh (shemant))
=C2=A0 =C2=A03. Re: DNS AAAA for free (Geordie Guy)
=C2=A0 =C2=A04. Re: DNS AAAA for free (Sander Steffann)
=C2=A0 =C2=A05. Re: DNS AAAA for free (Mark Smith)
=C2=A0 =C2=A06. Re: DNS AAAA for free (James R Cutler)


----------------------------------------------------------------------

Message: 1
Date: Fri, 8 Apr 2016 18:23:47 -0300
From: otroan@employees.org
To: 6man WG <ipv6@ietf.org>
Cc: Bob Hinden <bob.hinden@gmail= .com>
Subject: Re: rfc2460bis question
Message-ID: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org>
Content-Type: text/plain; charset=3D"us-ascii"

Let me clarify what my position is, since there are some nuances here.

While a discussion on header insertion may be necessary, it is not in conte= xt for taking RFC2460 to IS. If a proposal is made, then the working group = should discuss that in the context of that proposal.

The RFC2460 text has not caused interoperability issues. Which is why I'= ;m not convinced this change was required.

The default action, unless we can come to a different agreement, is to leav= e the RFC2460 text unchanged in RFC2460bis.

Please do not view that as if I am condoning header insertion. That would h= ave to be future work. RFC2460 is clear that routers should not look furthe= r into packets than the base IPv6 header.

Best regards,
Ole





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <h= ttps://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160408/883795f5/= attachment.asc>

------------------------------

Message: 2
Date: Fri, 8 Apr 2016 21:34:41 +0000
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "otroan@employees.org&= quot; <otroan@employees.org&= gt;, 6man WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ipv6@ietf.= org>
Cc: Bob Hinden <bob.hinden@gmail= .com>
Subject: RE: rfc2460bis question
Message-ID: <952867b558d2498bb995480710f9302a@XCH-RTP-005.cisco.com&g= t;
Content-Type: text/plain; charset=3D"us-ascii"

Ole,

Sounds reasonable to me - thanks.

Hemant

-----Original Message-----
From: otroan@employees.org [mai= lto:otroan@employees.org]
Sent: Friday, April 08, 2016 5:24 PM
To: 6man WG
Cc: Stefano Previdi (sprevidi); Bob Hinden; Hemant Singh (shemant)
Subject: Re: rfc2460bis question

Let me clarify what my position is, since there are some nuances here.

While a discussion on header insertion may be necessary, it is not in conte= xt for taking RFC2460 to IS. If a proposal is made, then the working group = should discuss that in the context of that proposal.

The RFC2460 text has not caused interoperability issues. Which is why I'= ;m not convinced this change was required.

The default action, unless we can come to a different agreement, is to leav= e the RFC2460 text unchanged in RFC2460bis.

Please do not view that as if I am condoning header insertion. That would h= ave to be future work. RFC2460 is clear that routers should not look furthe= r into packets than the base IPv6 header.

Best regards,
Ole







------------------------------

Message: 3
Date: Sat, 9 Apr 2016 17:55:30 +1000
From: Geordie Guy <geordie@gguy.me>
To: otroan@employees.org
Cc: v6ops list <v6ops@ietf.org>= , 6man WG <ipv6@ietf.org>
Subject: Re: DNS AAAA for free
Message-ID: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me>
Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dus-ascii

This is genuinely awesome.

Geordie

Sent from my mobile. Please excuse any unusual brevity or typos while I'= ;m on the go.

> On 8 Apr 2016, at 9:27 PM, otr= oan@employees.org wrote:
>
> Here is an interesting draft being presented in dnsop today.
> https://dat= atracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=3D1
>
> The proposal is to allow AAAA records in response to A queries.
>
> Best regards,
> Ole
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------


------------------------------

Message: 4
Date: Sat, 9 Apr 2016 12:55:05 +0200
From: Sander Steffann <sander@stef= fann.nl>
To: otroan@employees.org
Cc: v6ops list <v6ops@ietf.org>= , 6man WG <ipv6@ietf.org>
Subject: Re: DNS AAAA for free
Message-ID: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl>
Content-Type: text/plain; charset=3D"us-ascii"

Hi,

> On 08 Apr 2016, at 13:27, otro= an@employees.org wrote:
>
> Here is an interesting draft being presented in dnsop today.
> https://dat= atracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=3D1
>
> The proposal is to allow AAAA records in response to A queries.

One question: if clients send requests for both A and AAAA records simultan= eously, how will including the AAAA answer in the A request help? The clien= t will just get the AAAA answer twice: once on the A request and once on th= e AAAA request. If lookups were serialised and the A request/response was c= ompleted before starting the AAAA request it would make the second request = unnecessary, but that's not what I see in practice...

It looks like good intentions, I'm just trying to figure out how this w= ould work in practice :)

Cheers!
Sander

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <h= ttps://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/ebc82e8f/= attachment.asc>

------------------------------

Message: 5
Date: Sat, 9 Apr 2016 23:11:11 +1000
From: Mark Smith <markzzzsmith= @gmail.com>
To: Sander Steffann <sander@steffa= nn.nl>
Cc: 6man WG <ipv6@ietf.org>, v6o= ps list <v6ops@ietf.org>
Subject: Re: DNS AAAA for free
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAO42Z2wcCNXtOPDNGT8pYL=3DadMyaj3qu4ZY=3DrUmGWMWCtWRgXg@mail.gmail.co= m>
Content-Type: text/plain; charset=3D"utf-8"

On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> Hi,
>
> > On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> >
https://datatrac= ker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=3D1 > >
> > The proposal is to allow AAAA records in response to A queries. >
> One question: if clients send requests for both A and AAAA records
simultaneously, how will including the AAAA answer in the A request help? The client will just get the AAAA answer twice: once on the A request and once on the AAAA request. If lookups were serialised and the A
request/response was completed before starting the AAAA request it would make the second request unnecessary, but that's not what I see in
practice...
>
> It looks like good intentions, I'm just trying to figure out how t= his
would work in practice :)
>

Having briefly looked at it, it seems there is an efficiency benefit.
However, answering an A query with both an A and AAAA response might
incentivise just sending A queries.

Perhaps the opposite would be better - sending an AAAA query would result in an AAAA and A answer. That might create a small and subtle incentive to<= br> use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures.

Regards,
Mark.

> Cheers!
> Sander
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/03f3b360= /attachment.html>

------------------------------

Message: 6
Date: Sat, 9 Apr 2016 10:32:38 -0400
From: James R Cutler <jam= es.cutler@consultant.com>
To: otroan@employees.org
Cc: v6ops list <v6ops@ietf.org>= , 6man WG <ipv6@ietf.org>
Subject: Re: DNS AAAA for free
Message-ID: <CFE92148-462D-497A-B633-534AA3CB0ACB@consultant.com>
Content-Type: text/plain; charset=3D"us-ascii"


On 08 Apr 2016, at 13:27, otroan@em= ployees.org <mailto:otroan@e= mployees.org> wrote:
>
> Here is an interesting draft being presented in dnsop today.
> https://dat= atracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=3D1 <https://d= atatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=3D1= >
>
> The proposal is to allow AAAA records in response to A queries.

In most conversations it is considered polite to answer the question asked = and not to provide confusing extra data. This proposal violates that.

James R. Cutler
James.cutler@consultant.com<= /a>
PGP keys at http://pgp.mit.edu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5= /attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <h= ttps://mailarchive.ietf.org/arch/browse/ipv6/attachments/20160409/c4aad4e5/= attachment.asc>

------------------------------

Subject: Digest Footer

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


------------------------------

End of ipv6 Digest, Vol 144, Issue 21
*************************************

--001a11c12c560efb9205300e3c20-- From nobody Sat Apr 9 08:03:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677B512B014; Sat, 9 Apr 2016 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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] 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 KASnK8eJcBgN; Sat, 9 Apr 2016 08:03: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 0C57912B01A; Sat, 9 Apr 2016 08:03:25 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id 2so163016326ioy.1; Sat, 09 Apr 2016 08:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Q75Iuyherk37BE4KtXx2W/GDoYlQIgayGnLxBLCniNI=; b=E88t2BukXFaqa1TP7iraICylJpcvIsa0KB7XcBc0IZHiO/BJ63DYkpgf8BLYWysZnn 247YXgJgdH6TP8LUX254XvgnCC/zDOEYVmTaWFuVXUtkTRnPGtJv5L/gEWKPeQcczwLJ oFWIcK43VZyeDc9py69WtNm2sP8TxBkFhZ+CTvgmAo6rfn3wMQpGKbfbioIWXHe6Rb38 0w3R0FqKeqI9XIaWVlcahLs44PUWywUF0v6qQOnRYk1OifaRipul9nh4+pQPwAwPkBLt bHX2y/v0UhUlgr9Hi2bOBlVOY+4kgXpJ3imQsAbtvIm/+Tv3FZQdxK/FCojE2X1AyHZz D6vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Q75Iuyherk37BE4KtXx2W/GDoYlQIgayGnLxBLCniNI=; b=Sf82arRPxS+gMbCrhLpaHuINxSuBkhcSfLwww6eNw9XnOo+qAW8jKW0ZmdvM8gHDa+ 0e7Wthzq9owG1pPJn72KDR8TH0ByBQZc9R6tJX7keRNPPA2nA/O4Kg3hTVgQxq6hUUoL YyNssH9aj2FPO1tWMcNgMH6uYdhCZkhNIRx175pzBsXEjSd6VEOnLhHYrh7oQj4AftU3 pyfYKd9tF54JNW3C1t328eDc9by3aogc0BFbQ2eiiyNS82z8QpSESDchwkmD42O3c2s3 Au9RDzbPTvYgpYJHxrnS7wlyhgvC2YLNVI4uJGCZlLBUh6y15n1S+edeprVfzK4BPhOe HZsg== X-Gm-Message-State: AD7BkJLaatqgR6pCtSBD6WhwMqgOoakAydiEBLftbwxt1YgppYuPk56sV7vx9Ee1tMlEXhgt6WPSZA2IXQhBKg== MIME-Version: 1.0 X-Received: by 10.107.13.65 with SMTP id 62mr15310756ion.186.1460214204385; Sat, 09 Apr 2016 08:03:24 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.107.200.14 with HTTP; Sat, 9 Apr 2016 08:03:24 -0700 (PDT) In-Reply-To: References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 12:03:24 -0300 X-Google-Sender-Auth: IQANPdLWBR2VKtG8d7Bih25rGjw Message-ID: Subject: Re: DNS AAAA for free From: Erik Nygren To: Mark Smith Content-Type: multipart/alternative; boundary=001a113ff0ccf2d18505300e9cbb Archived-At: Cc: 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 15:03:26 -0000 --001a113ff0ccf2d18505300e9cbb Content-Type: text/plain; charset=UTF-8 On Sat, Apr 9, 2016 at 10:11 AM, Mark Smith wrote: > > On 9 Apr 2016 8:55 PM, "Sander Steffann" wrote: > > > > > Perhaps the opposite would be better - sending an AAAA query would > result in an AAAA and A answer. That might create a small and subtle > incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 > failures. > +1 Motivations to do this alongside AAAA query responses rather than A queries: - Encourage sending AAAA queries first (generally a good practice) - Don't penalize devices that receive dual-stacked connectivity and do both AAAA and A lookups in cases when the A lookup gets dropped. - Helps DNS64 in the case of a NOERROR for the AAAA if the corresponding A record can be carried alongside. Although... Pros: helps for dual-stacked clients with IPv4-only content. Cons: removes a tiny motivation to dual-stack (in cases where clients behind DNS64 only do a AAAA lookup having a AAAA record improves DNS lookup time during DNS cache misses). If we also look at something like this for stubs to resolvers, once enough resolvers implement this it could let stubs do AAAA lookups serially and only kick off a A lookup if no AAAA (or an empty AAAA with no A additional) is returned. (Although it would be undesirable for servers to wait for a A record before returning a AAAA record, so they'd only want to tag on the A if they already have one in-cache.) Erik --001a113ff0ccf2d18505300e9cbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 9, 2016 at 10:11 AM, Mark Smith <markzzz= smith@gmail.com> wrote:


On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
>

> Perhaps the opposite would be better - s= ending an AAAA query would result in an AAAA and A answer. That might creat= e a small and subtle incentive to use and prefer IPv6, with Happy Eyeballs = covering over IPv6 failures.

=C2=A0
+1 <= br>
Motivations to do this alongside AAAA query responses rat= her than A queries:
  • Encourage sending AAAA queries first (genera= lly a good practice)
  • Don't penalize devices that receive dual-s= tacked connectivity and do both AAAA and A lookups in cases when the A look= up gets dropped.
  • Helps DNS64 in the case of a NOERROR for the A= AAA if the corresponding A record can be carried alongside.=C2=A0 Although.= .. Pros: helps for dual-stacked clients with IPv4-only content.=C2=A0 Cons:= removes a tiny motivation to dual-stack (in cases where clients behind DNS= 64 only do a AAAA lookup having a AAAA record improves DNS lookup time duri= ng DNS cache misses).
If we also look at something = like this for stubs to resolvers, once enough resolvers implement this it c= ould let stubs do AAAA lookups serially and only kick off a A lookup if no = AAAA (or an empty AAAA with no A additional) is returned.=C2=A0 (Although i= t would be undesirable for servers to wait for a A record before returning = a AAAA record, so they'd only want to tag on the A if they already have= one in-cache.)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


--001a113ff0ccf2d18505300e9cbb-- From nobody Mon Apr 11 05:18:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE012ED64 for ; Mon, 11 Apr 2016 05:18:11 -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, 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 yuM7VMmMHT-d for ; Mon, 11 Apr 2016 05:18:08 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 9675A12ED5E for ; Mon, 11 Apr 2016 05:18:08 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id p188so204325843oih.2 for ; Mon, 11 Apr 2016 05:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TmVqSisfcJjXuc57cCCfs/+2GOOpbpDci3M6mPaeQDg=; b=ckuqVBnCKG4jUbzHnRg3YApFlitrjyGsVK6YlT7LmCRxxcvPCAx1km3NGGJbh7JfUk EjEHh5bSqiU5C2URhLnzMUtuUdBZZyWNkJ1JrJlhJ6QvsI29mhWD2wGMYnUVOGlS95Hn D4BkmabVz/FRuKkNg4E9IE4DwzX6PV3AodvKrfyehS4OUVg0+R7IUCHXLNuNP+ZtrEF5 VKEtaUCe3KVTAt53arVbFF8/tVYdnbR4tuAxpDJkFJASbT9Qcd1vRHxMdY6F20K6hfGX XFLEmPUB0TSULgOJKJ9yigUE1B2wxMtGl+useWjKZwelWBwI4nixc6puXgVdKE53LuZ6 jVkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TmVqSisfcJjXuc57cCCfs/+2GOOpbpDci3M6mPaeQDg=; b=GCJyLYPnjs5e4QuSwG3PksJ0O3U/Ot7tDoj5v7xRh2pKjw22D+xY84dqybJKpnD3bS 1OdmYG6dsK4+x30MEZHsIzf7rYFMBwMosHhTV180mi9UQPE/swQKojYkQipAAW5CkXSo Pb3gy6c8wcOBqPN3E9WBcR9H4dQSCuvYcMtMHE11kdFqNIh55A6D84luNGZJnow3iApF 3NXWHVwA6oiw5Kpj9ucEWSGtd1Ho0Mdp5a3E2LLnUHvrvodeJgtajWfiRNy26rGb+lUk rAokR8FJUTxo1l+HgXUdZ8HAgDSUcGiapQTSeSqyCcibxm7AJE2o1NHMeaQr5vLAUI4A Saig== X-Gm-Message-State: AD7BkJKLgDTmL6KBCv+xxPa1q7vz7AhnW6oq7taXpCPClcEB9qChJcF1Ns6T8V+mlcdx6EbK/Xg4EVRcbo+m7w== MIME-Version: 1.0 X-Received: by 10.157.24.107 with SMTP id t40mr9461229ott.142.1460377088013; Mon, 11 Apr 2016 05:18:08 -0700 (PDT) Received: by 10.157.40.114 with HTTP; Mon, 11 Apr 2016 05:18:07 -0700 (PDT) In-Reply-To: <570569C2.4030601@acm.org> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> Date: Mon, 11 Apr 2016 05:18:07 -0700 Message-ID: Subject: Re: draft-van-beijnum-multi-mtu-05.txt From: Sowmini Varadhan To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a1142de9091bd96053034891e Archived-At: Cc: Iljitsch van Beijnum , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:18:12 -0000 --001a1142de9091bd96053034891e Content-Type: text/plain; charset=UTF-8 On Wed, Apr 6, 2016 at 12:55 PM, Erik Nordmark wrote: On 4/6/16 12:18 PM, David Lamparter wrote: > >> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: >> >>> I'll be presenting >>> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on >>> Wednesday. There are operational considerations here, so I encourage >>> people to drop in and/or comment on this draft. >>> >> Ok... easy comments/opinions first: >> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to >> piggyback on NUD sounds great, though admittedly I haven't thought it >> through looking for pitfalls. >> > One issue compared to a dedicate probe is that a NUD (a unicast NS) of > size X wouldn't necessarily result in a unicast NA that is also padded; > perhaps one can add such behavior so that we can get the bidirectional > probe in both directions. there's also the question of what mtu to advertise in the face of pvlans, when there is a router on a promisc port proxying the NA. In practice, since a node typically uses a single interface to talk to multiple onlink neighbors, and jumbo mtu etc is configured per interface, you would end up getting metered down to the lowest common denominator for the subnet, right? --Sowmini --001a1142de9091bd96053034891e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Apr 6, 2016 at 12:55 PM, Erik Nordmark <nordmark@acm.org> wrote:

On 4/6/1= 6 12:18 PM, David Lamparter wrote:
On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote:
I'll be presenting
https://tools.ietf.org/html/draft-van-bei= jnum-multi-mtu-05 in 6man on
Wednesday. There are operational considerations here, so I encourage
people to drop in and/or comment on this draft.
Ok... easy comments/opinions first:
- should definitely be ICMP, not UDP.=C2=A0 Erik Nordmark's suggestion = to
=C2=A0 =C2=A0piggyback on NUD sounds great, though admittedly I haven't= thought it
=C2=A0 =C2=A0through looking for pitfalls.
 One issue compared to a dedicate probe is that a NUD (a unicast NS) of size= X wouldn't necessarily result in a unicast NA that is also padded; per= haps one can add such behavior so that we can get the bidirectional probe i= n both directions.

there's also the que= stion of what mtu to advertise in the face of
pvlans, when t= here is a router on a promisc port proxying the NA.

In pr= actice, since a node typically uses a single interface to talk
to multiple onlink neighbors, and jumbo mtu etc is configured per
interface, you would end up getting metered down to the lowest
common denominator for the subnet, right?

--Sowm= ini

=C2=A0
--001a1142de9091bd96053034891e-- From nobody Mon Apr 11 07:15:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6012D591 for ; Mon, 11 Apr 2016 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.417 X-Spam-Level: X-Spam-Status: No, score=-15.417 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.996, SPF_PASS=-0.001, URIBL_SBL_A=0.1, 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 COcwZHGjAKN7 for ; Mon, 11 Apr 2016 07:15:07 -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 6869712EF07 for ; Mon, 11 Apr 2016 07:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=929; q=dns/txt; s=iport; t=1460384107; x=1461593707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4JPB1oHd/+NbGITtqz8iBPHuf8+8ou9wxf3QctJCYho=; b=dYVIF0bsTmvREohZF15egH+Pz6kauFGMXyk18ZdgfN1+NkbnSrc+b5Ze ZSaVYXg5BwL+GbWqVUQaaBS03L80OoWRTA7L5go8T95ZPObE7/O1eFjkQ NMCiZtyrlrDkVzONbN8sZws3APvh9CA9bafm3mjAnBeh3JraTb4hTIjxv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDCsAtX/4cNJK1dgzeBUAa6VQENg?= =?us-ascii?q?XKGDQKBLDgUAQEBAQEBAWUcC4RBAQEBAwE6PwULAgEIGB4QMiUCBA4FiB8IvmM?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEYhiGBdQiCToQ9gy2CKwEEkxmEawGOC4FnhE2IW?= =?us-ascii?q?Y8lAR4BAUKDZ2yJLX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="259279676" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 14:15:06 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3BEF3qW002751 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 14:15:04 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.1104.5; Mon, 11 Apr 2016 10:15:02 -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.1104.009; Mon, 11 Apr 2016 10:15:02 -0400 From: "Stefano Previdi (sprevidi)" To: "otroan@employees.org" Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRkEEWGbjOPkFJykCCV3KDKYtuDp96ha6AgAKN7wCAAJ76AIAAHHeAgAA8zQCAANClAIAA8JGAgAAkR+CAAOsTgIAEPzKA Date: Mon, 11 Apr 2016 14:15:02 +0000 Message-ID: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> In-Reply-To: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.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.90.146] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 14:15:13 -0000 Ole, I agree with your proposal. s. > On Apr 8, 2016, at 11:23 PM, otroan@employees.org wrote: >=20 > Let me clarify what my position is, since there are some nuances here. >=20 > While a discussion on header insertion may be necessary, it is not in con= text for taking RFC2460 to IS. If a proposal is made, then the working grou= p should discuss that in the context of that proposal. >=20 > The RFC2460 text has not caused interoperability issues. Which is why I'm= not convinced this change was required. >=20 > The default action, unless we can come to a different agreement, is to le= ave the RFC2460 text unchanged in RFC2460bis. >=20 > Please do not view that as if I am condoning header insertion. That would= have to be future work. RFC2460 is clear that routers should not look furt= her into packets than the base IPv6 header. >=20 > Best regards, > Ole >=20 >=20 >=20 >=20 >=20 From nobody Mon Apr 11 08:20:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC09612F051 for ; Mon, 11 Apr 2016 08:20:14 -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 xPsiHwzUreKS for ; Mon, 11 Apr 2016 08:20:13 -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 365AF12F04F for ; Mon, 11 Apr 2016 08:20:12 -0700 (PDT) Received: from [192.168.3.107] (192-174-17-190.fibertel.com.ar [190.17.174.192]) (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 EB0C780D7B; Mon, 11 Apr 2016 17:20:06 +0200 (CEST) Subject: Re: rfc2460bis question To: otroan@employees.org, 6man WG References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <570BC095.6060608@si6networks.com> Date: Mon, 11 Apr 2016 12:19:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:20:15 -0000 On 04/08/2016 06:23 PM, otroan@employees.org wrote: > Let me clarify what my position is, since there are some nuances > here. > > While a discussion on header insertion may be necessary, it is not in > context for taking RFC2460 to IS. If a proposal is made, then the > working group should discuss that in the context of that proposal. Since header insertion is certainly not part of RFC2460, rfc2460bhis should include a clarification that header insertion is not allowed. It would be a shame that we're working on a bis document and we fail to clarify a question that has been raised for RFC2460. > The RFC2460 text has not caused interoperability issues. Which is why > I'm not convinced this change was required. Not has RFC2460 not being IS.... so? > The default action, unless we can come to a different agreement, is > to leave the RFC2460 text unchanged in RFC2460bis. I disagree. Particularly when I've filled an errata about it. The WG has to accept or reject, I'd think. 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 11 09:29:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735D712F120 for ; Mon, 11 Apr 2016 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 ix2Jas_cQS0F for ; Mon, 11 Apr 2016 09:29:16 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFED12F108 for ; Mon, 11 Apr 2016 09:29:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2ACAgBh0AtX/xUHmMZcGQEBAQGCbytTfQaufotYAQ2BciGFbAIcgRE4FAEBAQEBAQFlJ4RBAQEBAQMSEREaIAsMBAIBBgINBAMBAQEBAgIGAhsDAgICHxABFAEICAIEAQ0FCBUEAYdwAxIBDZAckkyKS4xbDYUfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyFJoRKgkGBThEBHhaCaiuCKwWHcI9jMQGFdoYfAYNcToN/gxyFPYdKh1weAQFCggQZFYE1bAEBAYh0NgF9AQEB X-IPAS-Result: A2ACAgBh0AtX/xUHmMZcGQEBAQGCbytTfQaufotYAQ2BciGFbAIcgRE4FAEBAQEBAQFlJ4RBAQEBAQMSEREaIAsMBAIBBgINBAMBAQEBAgIGAhsDAgICHxABFAEICAIEAQ0FCBUEAYdwAxIBDZAckkyKS4xbDYUfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyFJoRKgkGBThEBHhaCaiuCKwWHcI9jMQGFdoYfAYNcToN/gxyFPYdKh1weAQFCggQZFYE1bAEBAYh0NgF9AQEB X-IronPort-AV: E=Sophos;i="5.24,462,1454994000"; d="scan'208";a="179786829" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Apr 2016 12:29:00 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 11 Apr 2016 12:29:00 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Mon, 11 Apr 2016 12:28:59 -0400 From: "Mudric, Dusan (Dusan)" To: Brian E Carpenter , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: RE: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network Thread-Topic: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network Thread-Index: AQHRkG/PHqoahfN+9kSzNancZXc+rJ+E/FLg Date: Mon, 11 Apr 2016 16:28:58 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8CBCC6@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> <5705BCBA.1030007@gmail.com> In-Reply-To: <5705BCBA.1030007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 16:29:19 -0000 SGkgQnJpYW4sDQoNClNob3VsZCB0aGUgZHJhZnQgYmUgbW9yZSBzcGVjaWZpYyBleHBsYWluaW5n IHdoZXJlIHRoZSBBPUw9MCBwcmVmaXggc2hvdWxkIGJlIHN0b3JlZCBhbmQgaG93IHRoZSBwcmVm aXggc2hvdWxkIGJlIHVzZWQ/IExpa2U6DQotIFNob3VsZCBBPUw9MCBwcmVmaXggYmUgYWRkZWQg dG8gdGhlIHByZWZpeCBsaXN0IGFuZCB1c2UgZm9yIG9uLWxpbmsgZGV0ZXJtaW5hdGlvbj8gKHlv dSBzYWlkIG5vKQ0KLSBTaG91bGQgQT1MPTAgcHJlZml4IHVzZWQgZm9yIFNMQUFDPyAoeW91IHNh aWQgbm8pDQotIEhvdyBpcyBBPUw9MCBwcmVmaXggZ29pbmcgdG8gaGVscCB0aGUgZmlyc3QgaG9w IHJvdXRlciBzZWxlY3Rpb24/DQoNClRoYW5rcywNCkR1c2FuLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNiwgMjAxNiA5OjUwIFBN DQpUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pOyDnpZ7mmI7pgZTlk4kNCkNjOiBpcHY2QGlldGYu b3JnDQpTdWJqZWN0OiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdCAtIFJvdXRpbmcg cGFja2V0cyBmcm9tIGhvc3RzIGluIGEgbXVsdGktcHJlZml4IG5ldHdvcmsNCg0KRHVzYW4sDQoN CkFzIGZhciBhcyBJIGtub3cgd2UgYXJlIG9ubHkgY2hhbmdpbmcgdGhlIEE9TD0wIGNhc2UuIElm IEE9MCwgdGhlIHByZWZpeCBpcyBub3QgdXNlZCBmb3IgU0xBQUMgYXQgYWxsLCBhbmQgaWYgTD0w IHRoZSBwcmVmaXggc2hvdWxkIG5vdCBiZSBhZGRlZCB0byB0aGUgb24tbGluayBwcmVmaXggbGlz dC4NCg0KVG8gYmUgY2xlYXIsIEw9MCBkb2Vzbid0IG1lYW4gdGhlIHByZWZpeCBpcyBvZmYtbGlu ay4gSXQganVzdCBtZWFucyAiSSdtIG5vdCB0ZWxsaW5nIHlvdSBpdCdzIG9uLWxpbmsiLg0KDQpT byBwcmV2aW91c2x5IGEgaG9zdCBjb3VsZCBzaW1wbHkgaWdub3JlIHRoZSBQSU8gd2l0aCBBPUw9 MC4gQnV0IG5vdyBpdCB3aWxsIGJlIGEgdXNlZnVsIG5leHQtaG9wIHJvdXRlciBzaWduYWwgdG8g dGhlIGhvc3QsIGlmIGFkZHJlc3NlcyBpbiB0aGF0IHByZWZpeCBoYXZlIGJlZW4gYXNzaWduZWQg aW4gYW5vdGhlciB3YXksIHR5cGljYWxseSBieSBESENQdjYuDQoNCkRvZXMgdGhhdCBtYWtlIHNl bnNlPw0KDQogICBCcmlhbg0KDQpPbiAwNy8wNC8yMDE2IDA3OjQwLCBNdWRyaWMsIER1c2FuIChE dXNhbikgd3JvdGU6DQo+IEhpIEJyaWFuLA0KPiANCj4gIlJvdXRpbmcgcGFja2V0cyBmcm9tIGhv c3RzIGluIGEgbXVsdGktcHJlZml4IG5ldHdvcmsiIHNheXM6DQo+ICAgIEEgcm91dGVyDQo+ICAg IHRoYXQgYWR2ZXJ0aXNlcyBhIHByZWZpeCBpbmRpY2F0ZXMgdGhhdCBpdCBpcyBhYmxlIHRvIGFw cHJvcHJpYXRlbHkNCj4gICAgcm91dGUgcGFja2V0cyB3aXRoIHNvdXJjZSBhZGRyZXNzZXMgd2l0 aGluIHRoYXQgcHJlZml4LCByZWdhcmRsZXNzIG9mDQo+ICAgIHRoZSBzZXR0aW5nIG9mIHRoZSBM IGFuZCBBIGZsYWdzIGluIHRoZSBQSU8uDQo+IA0KPiAgICBhIGhvc3QgU0hPVUxEIE5PVCBpZ25v cmUgYSBQSU8gc2ltcGx5IGJlY2F1c2UgYm90aCBMIGFuZA0KPiAgICBBIGZsYWdzIGFyZSBjbGVh cmVkOyBhIHJvdXRlciBTSE9VTEQgYmUgYWJsZSB0byBzZW5kIHN1Y2ggYSBQSU8uDQo+IA0KPiAg ICBBIGhvc3QgU0hPVUxEIHNlbGVjdA0KPiAgICBkZWZhdWx0IHJvdXRlcnMgZm9yIGVhY2ggcHJl Zml4IGl0IGlzIGFzc2lnbmVkIGFuIGFkZHJlc3MgaW4uDQo+IA0KPiBUaGUgcHJlZml4IGxpc3Qg aXMgdXNlZCB0byBmaW5kIG91dCBpZiB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBvbi1saW5r LiANCj4gDQo+IElmIHRoZSByb3V0ZXIgY2FuIHJvdXRlIHRoZSBwYWNrZXRzIGZyb20gYSBob3N0 IHdpdGggdGhlIHNvdXJjZSBhZGRyZXNzIHVzaW5nIEw9MCBwcmVmaXgsIHRoZW9yZXRpY2FsbHkg b2ZmLWxpbmsgcHJlZml4IGNhbiBiZSB1c2VkIGZvciBTTEFBQyBhZGRyZXNzLiBUaGUgcHJvYmxl bSBpcyB0aGF0IEw9MCBwcmVmaXggbWlnaHQgYmUgdXNlZCBvbiBvdGhlciBsaW5rcyBhbmQgaWYg dGhlIGhvc3QgY3JlYXRlcyBTTEFBQyBhZGRyZXNzIHVzaW5nIEw9MCBwcmVmaXgsIHRoZSBob3N0 IHdpbGwgbm90IGJlIGFibGUgdG8gZGV0ZWN0IGlmIHRoZSBhZGRyZXNzIGlzIGluIHVzZSAoREFE IGRvZXMgbm90IHdvcmsgYmV0d2VlbiBkaWZmZXJlbnQgcm91dGVyIGxpbmtzKS4gRm9yIHRoYXQg cmVhc29uIGxvb2tzIGxpa2UgTD0wIHByZWZpeCBzaG91bGQgbm90IGJlIHVzZWQgZm9yIFNMQUFD LiBJZiBMPTAgcHJlZml4IGlzIG5vdCB1c2UgZm9yIFNMQUFDLCB0aGVyZSB3aWxsIGJlIG5vIHNv dXJjZSBhZGRyZXNzIHdpdGggTD0wIHByZWZpeCBhbmQgTD0wIHByZWZpeGVzIHdpbGwgbm90IGhl bHAgaG9zdCB0byBmaW5kIHRoZSBmaXJzdCBob3Agcm91dGVyLiBDb25zZXF1ZW50bHksIGhvc3Rz IGNhbiBpZ25vcmUgTD0wIHByZWZpeGVzLg0KPiANCj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZyBh Ym91dCBMPTAgcHJlZml4ZXM/DQo+IA0KPiBUaGFua3MsDQo+IER1c2FuLg0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBpcHY2LXJlcXVlc3RAaWV0Zi5vcmcNCj4gU2VudDog TW9uZGF5LCBGZWJydWFyeSAyMiwgMjAxNiAzOjAwIFBNDQo+IFRvOiBpcHY2QGlldGYub3JnDQo+ IFN1YmplY3Q6IGlwdjYgRGlnZXN0LCBWb2wgMTQyLCBJc3N1ZSAzNQ0KPiANCj4gU2VuZCBpcHY2 IG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KPiAJaXB2NkBpZXRmLm9yZw0KPiANCj4gVG8g c3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQo+ IAkNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbA0KPiBtYW5fbGlzdGluZm9faXB2NiZkPUJRSUNBZyZjPUJGcFdR dzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzDQo+IGlDcmhJb1VXQjhZTFpVMjMw MjlzTVFHUTJrWSZtPWxoZmc4bzNzUV9VMHFXaUFjSU82N19PWTZsdHZWZFB5Umoyb1F3d3ENCj4g NTMwJnM9djFBNkFWcWIxV3hZSnJvMV9MLTV5X2I2Ykh4bldaak1acl9qRTU1WDlGbyZlPQ0KPiBv ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg dG8NCj4gCWlwdjYtcmVxdWVzdEBpZXRmLm9yZw0KPiANCj4gWW91IGNhbiByZWFjaCB0aGUgcGVy c29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQo+IAlpcHY2LW93bmVyQGlldGYub3JnDQo+IA0KPiBX aGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3Jl IHNwZWNpZmljIHRoYW4gIlJlOiBDb250ZW50cyBvZiBpcHY2IGRpZ2VzdC4uLiINCj4gDQo+IA0K PiBUb2RheSdzIFRvcGljczoNCj4gDQo+ICAgIDEuIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1h bi1tdWx0aS1ob21lZC1ob3N0LTA1LnR4dA0KPiAgICAgICAoaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnKQ0KPiAgICAyLiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9z dC0wNi50eHQNCj4gICAgICAgKGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZykNCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiBNZXNzYWdlOiAxDQo+IERhdGU6IE1vbiwgMjIgRmViIDIwMTYg MTA6MzI6NTIgLTA4MDANCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFRvOiA8 aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBDYzogaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdC0wNS50eHQNCj4gTWVz c2FnZS1JRDogPDIwMTYwMjIyMTgzMjUyLjIxMTAyLjM1MjcxLmlkdHJhY2tlckBpZXRmYS5hbXNs LmNvbT4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCj4gDQo+ IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIElQdjYgTWFpbnRlbmFuY2Ugb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgIFRpdGxl ICAgICAgICAgICA6IFJvdXRpbmcgcGFja2V0cyBmcm9tIGhvc3RzIGluIGEgbXVsdGktcHJlZml4 IG5ldHdvcmsNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBGcmVkIEJha2VyDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgQnJpYW4gQ2FycGVudGVyDQo+IAlGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdC0wNS50eHQNCj4gCVBhZ2VzICAgICAg ICAgICA6IDEzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE2LTAyLTIyDQo+IA0KPiBBYnN0cmFj dDoNCj4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZXhwZWN0ZWQgSVB2NiBob3N0IGJlaGF2 aW9yIGluIGEgbmV0d29yayB0aGF0DQo+ICAgIGhhcyBtb3JlIHRoYW4gb25lIHByZWZpeCwgZWFj aCBhbGxvY2F0ZWQgYnkgYW4gdXBzdHJlYW0gbmV0d29yayB0aGF0DQo+ICAgIGltcGxlbWVudHMg QkNQIDM4IGluZ3Jlc3MgZmlsdGVyaW5nLCB3aGVuIHRoZSBob3N0IGhhcyBtdWx0aXBsZQ0KPiAg ICByb3V0ZXJzIHRvIGNob29zZSBmcm9tLiAgSXQgYWxzbyBhcHBsaWVzIHRvIG90aGVyIHNjZW5h cmlvcyBzdWNoIGFzDQo+ICAgIHRoZSB1c2FnZSBvZiBzdGF0ZWZ1bCBmaXJld2FsbHMgdGhhdCBl ZmZlY3RpdmVseSBhY3QgYXMgYWRkcmVzcy1iYXNlZA0KPiAgICBmaWx0ZXJzLiAgVGhpcyBob3N0 IGJlaGF2aW9yIG1heSBpbnRlcmFjdCB3aXRoIHNvdXJjZSBhZGRyZXNzDQo+ICAgIHNlbGVjdGlv biBpbiBhIGdpdmVuIGltcGxlbWVudGF0aW9uLCBidXQgbG9naWNhbGx5IGZvbGxvd3MgaXQuICBH aXZlbg0KPiAgICB0aGF0IHRoZSBuZXR3b3JrIG9yIGhvc3QgaXMsIG9yIGFwcGVhcnMgdG8gYmUs IG11bHRpaG9tZWQgd2l0aA0KPiAgICBtdWx0aXBsZSBwcm92aWRlci1hbGxvY2F0ZWQgYWRkcmVz c2VzLCB0aGF0IHRoZSBob3N0IGhhcyBlbGVjdGVkIHRvDQo+ICAgIHVzZSBhIHNvdXJjZSBhZGRy ZXNzIGluIGEgZ2l2ZW4gcHJlZml4LCBhbmQgdGhhdCBzb21lIGJ1dCBub3QgYWxsDQo+ICAgIG5l aWdoYm9yaW5nIHJvdXRlcnMgYXJlIGFkdmVydGlzaW5nIHRoYXQgcHJlZml4IGluIHRoZWlyIFJv dXRlcg0KPiAgICBBZHZlcnRpc2VtZW50IFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zLCB0aGlz IGRvY3VtZW50IHNwZWNpZmllcyB0bw0KPiAgICB3aGljaCByb3V0ZXIgYSBob3N0IHNob3VsZCBw cmVzZW50IGl0cyB0cmFuc21pc3Npb24uICBJdCB1cGRhdGVzIFJGQw0KPiAgICA0ODYxLg0KPiAN Cj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X2RhdGF0cmFja2VyLmlldGYuDQo+IG9yZ19kb2NfZHJhZnQtMkRpZXRmLTJENm1hbi0yRG11bHRp LTJEaG9tZWQtMkRob3N0XyZkPUJRSUNBZyZjPUJGcFdRdzgNCj4gYnN1S3BsMVNnaVpINjRRJnI9 VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWxoZmc4bw0KPiAz c1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9UFVxamVTbjRwVU9ydFdWQnNO ak5haWxzUmV3NV9aDQo+IHZ6RFMxU1RGdFRqRGcmZT0NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0DQo+IG1sX2RyYWZ0 LTJEaWV0Zi0yRDZtYW4tMkRtdWx0aS0yRGhvbWVkLTJEaG9zdC0yRDA1JmQ9QlFJQ0FnJmM9QkZw V1F3OGINCj4gc3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUy MzAyOXNNUUdRMmtZJm09bGhmZzhvMw0KPiBzUV9VMHFXaUFjSU82N19PWTZsdHZWZFB5Umoyb1F3 d3E1MzAmcz1XcW5yNlB6aEFXekNVT01sSDB2Mk1QSzg3S3locElmDQo+IGwxc0RGOTZVTmhQNCZl PQ0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19yZmNkDQo+IGlmZi0zRnVybDItM0RkcmFmdC0yRGlldGYtMkQ2bWFuLTJE bXVsdGktMkRob21lZC0yRGhvc3QtMkQwNSZkPUJRSUNBZyYNCj4gYz1CRnBXUXc4YnN1S3BsMVNn aVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWQ0KPiAm bT1saGZnOG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9dlBZT05jaW15 R0l2R0pGbDFUaDZSDQo+IFYta1NKdjc5cVBYYVVMZG95ZU9IRW8mZT0NCj4gDQo+IA0KPiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5pZXRmLm9yZ19pbnRlcm4NCj4gZXQt MkRkcmFmdHNfJmQ9QlFJQ0FnJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVh SnhoZjNpQ3JoSQ0KPiBvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhmZzhvM3NRX1UwcVdpQWNJ TzY3X09ZNmx0dlZkUHlSajJvUXd3cTUzMCZzDQo+ID1ES0Rwd2JxS3haUnlNWHFnU2tsTnhFLXpQ MURadGRJQUtuck85bkRCV2lzJmU9DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gTWVzc2FnZTogMg0KPiBEYXRlOiBNb24sIDIyIEZlYiAyMDE2IDEw OjU1OjMwIC0wODAwDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBUbzogPGkt ZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLW11bHRpLWhvbWVkLWhvc3QtMDYudHh0DQo+IE1lc3Nh Z2UtSUQ6IDwyMDE2MDIyMjE4NTUzMC41NjYyLjcxMDkzLmlkdHJhY2tlckBpZXRmYS5hbXNsLmNv bT4NCj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCj4gDQo+IA0K PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIElQdjYgTWFpbnRlbmFuY2Ugb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IFJvdXRpbmcgcGFja2V0cyBmcm9tIGhvc3RzIGluIGEgbXVsdGktcHJlZml4IG5l dHdvcmsNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBGcmVkIEJha2VyDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgQnJpYW4gQ2FycGVudGVyDQo+IAlGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdC0wNi50eHQNCj4gCVBhZ2VzICAgICAgICAg ICA6IDEzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE2LTAyLTIyDQo+IA0KPiBBYnN0cmFjdDoN Cj4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZXhwZWN0ZWQgSVB2NiBob3N0IGJlaGF2aW9y IGluIGEgbmV0d29yayB0aGF0DQo+ICAgIGhhcyBtb3JlIHRoYW4gb25lIHByZWZpeCwgZWFjaCBh bGxvY2F0ZWQgYnkgYW4gdXBzdHJlYW0gbmV0d29yayB0aGF0DQo+ICAgIGltcGxlbWVudHMgQkNQ IDM4IGluZ3Jlc3MgZmlsdGVyaW5nLCB3aGVuIHRoZSBob3N0IGhhcyBtdWx0aXBsZQ0KPiAgICBy b3V0ZXJzIHRvIGNob29zZSBmcm9tLiAgSXQgYWxzbyBhcHBsaWVzIHRvIG90aGVyIHNjZW5hcmlv cyBzdWNoIGFzDQo+ICAgIHRoZSB1c2FnZSBvZiBzdGF0ZWZ1bCBmaXJld2FsbHMgdGhhdCBlZmZl Y3RpdmVseSBhY3QgYXMgYWRkcmVzcy1iYXNlZA0KPiAgICBmaWx0ZXJzLiAgVGhpcyBob3N0IGJl aGF2aW9yIG1heSBpbnRlcmFjdCB3aXRoIHNvdXJjZSBhZGRyZXNzDQo+ICAgIHNlbGVjdGlvbiBp biBhIGdpdmVuIGltcGxlbWVudGF0aW9uLCBidXQgbG9naWNhbGx5IGZvbGxvd3MgaXQuICBHaXZl bg0KPiAgICB0aGF0IHRoZSBuZXR3b3JrIG9yIGhvc3QgaXMsIG9yIGFwcGVhcnMgdG8gYmUsIG11 bHRpaG9tZWQgd2l0aA0KPiAgICBtdWx0aXBsZSBwcm92aWRlci1hbGxvY2F0ZWQgYWRkcmVzc2Vz LCB0aGF0IHRoZSBob3N0IGhhcyBlbGVjdGVkIHRvDQo+ICAgIHVzZSBhIHNvdXJjZSBhZGRyZXNz IGluIGEgZ2l2ZW4gcHJlZml4LCBhbmQgdGhhdCBzb21lIGJ1dCBub3QgYWxsDQo+ICAgIG5laWdo Ym9yaW5nIHJvdXRlcnMgYXJlIGFkdmVydGlzaW5nIHRoYXQgcHJlZml4IGluIHRoZWlyIFJvdXRl cg0KPiAgICBBZHZlcnRpc2VtZW50IFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zLCB0aGlzIGRv Y3VtZW50IHNwZWNpZmllcyB0bw0KPiAgICB3aGljaCByb3V0ZXIgYSBob3N0IHNob3VsZCBwcmVz ZW50IGl0cyB0cmFuc21pc3Npb24uICBJdCB1cGRhdGVzIFJGQw0KPiAgICA0ODYxLg0KPiANCj4g DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rh dGF0cmFja2VyLmlldGYuDQo+IG9yZ19kb2NfZHJhZnQtMkRpZXRmLTJENm1hbi0yRG11bHRpLTJE aG9tZWQtMkRob3N0XyZkPUJRSUNBZyZjPUJGcFdRdzgNCj4gYnN1S3BsMVNnaVpINjRRJnI9VVQz Qms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWxoZmc4bw0KPiAzc1Ff VTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9UFVxamVTbjRwVU9ydFdWQnNOak5h aWxzUmV3NV9aDQo+IHZ6RFMxU1RGdFRqRGcmZT0NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0DQo+IG1sX2RyYWZ0LTJE aWV0Zi0yRDZtYW4tMkRtdWx0aS0yRGhvbWVkLTJEaG9zdC0yRDA2JmQ9QlFJQ0FnJmM9QkZwV1F3 OGINCj4gc3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAy OXNNUUdRMmtZJm09bGhmZzhvMw0KPiBzUV9VMHFXaUFjSU82N19PWTZsdHZWZFB5Umoyb1F3d3E1 MzAmcz1sR2ZNR2ZXQzdHVjZWLXJld01Ma3VYaG1NdjhxQ0dCDQo+IEhJeGhDc0Zta09uWSZlPQ0K PiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19yZmNkDQo+IGlmZi0zRnVybDItM0RkcmFmdC0yRGlldGYtMkQ2bWFuLTJEbXVs dGktMkRob21lZC0yRGhvc3QtMkQwNiZkPUJRSUNBZyYNCj4gYz1CRnBXUXc4YnN1S3BsMVNnaVpI NjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWQ0KPiAmbT1s aGZnOG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9VUZTOTdGYmpFUURC RS1ESkJaYUpGDQo+IDdKM3VtZG1uNjZQQTFaNHljOTV4alUmZT0NCj4gDQo+IA0KPiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5pZXRmLm9yZ19pbnRlcm4NCj4gZXQtMkRk cmFmdHNfJmQ9QlFJQ0FnJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnho ZjNpQ3JoSQ0KPiBvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhmZzhvM3NRX1UwcVdpQWNJTzY3 X09ZNmx0dlZkUHlSajJvUXd3cTUzMCZzDQo+ID1ES0Rwd2JxS3haUnlNWHFnU2tsTnhFLXpQMURa dGRJQUtuck85bkRCV2lzJmU9DQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiANCj4gU3ViamVjdDogRGlnZXN0IEZvb3Rlcg0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaXB2NiBtYWlsaW5nIGxpc3QN Cj4gaXB2NkBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQo+IG1hbl9saXN0aW5mb19pcHY2JmQ9 QlFJQ0FnJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjMNCj4gaUNy aElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhmZzhvM3NRX1UwcVdpQWNJTzY3X09ZNmx0dlZk UHlSajJvUXd3cQ0KPiA1MzAmcz12MUE2QVZxYjFXeFlKcm8xX0wtNXlfYjZiSHhuV1pqTVpyX2pF NTVYOUZvJmU9DQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBFbmQgb2YgaXB2NiBEaWdlc3QsIFZvbCAxNDIsIElzc3VlIDM1DQo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gDQo= From nobody Mon Apr 11 10:44:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B3B12F28A for ; Mon, 11 Apr 2016 10:44:22 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 dQZWu1JRusE5 for ; Mon, 11 Apr 2016 10:44:21 -0700 (PDT) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001: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 E343312F286 for ; Mon, 11 Apr 2016 10:44:20 -0700 (PDT) Received: by mail-ig0-x241.google.com with SMTP id fn8so12056005igb.2 for ; Mon, 11 Apr 2016 10:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=/UANWJV0HRdzF9MgLndy09J7X1SFrOx3cl+/q3odmwU=; b=Q6xuk1crzttSByISCxQA+vYtVA+13rGWriBwP0sgLZxrWAXRgXdPjPk6BXhFwHF9C2 CIbLL8pH7Cb1mjT7K0ee9d/zqhmt7t1G94eAsDjr5BQwYM1jcRxBAG9sSY9eR1rAZszw +5P9N6wdLOH5Kehl979Qa+1MFaNoKp2k9ZVTE/H1U1R/Z91bzc324iAj3aZ05CeAaB8K 5rRNeRFqDt276JtJqedAlSLGSwFYNwd0lMRdInid93U67bRLzmVUA8JnREN15I4VLEMp r6wuuVAh9BKmlqagbZyNLPx0OW0CTjk3KxAbJi6xtuyfJ/a+tWKKF8AxDfVjgMk/Nw5J s0+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/UANWJV0HRdzF9MgLndy09J7X1SFrOx3cl+/q3odmwU=; b=CqIBkIMkZUIVocVdSWkhTtwAink4frJdXRARIjHThxOXbRPQhcNtJYnMlyWO2r9LHf eGFzQIrV+Ynlc3vI1DrGl1Av2lcths+Qsp57Q3fafHbCnkzYZFzDwnWjtMFmGkQML87H +acOIsy7gFIUdYlBBZq7CpBSCXeGTtCPmLmJW43bCKKD5by/HHWNxsZ/sSLoRvXvUO6c IQl5l7jh5MWrGbRILSxkIFhFrBe+JZqt6eojlNXPPj6HUegufwLLoeToV5Wkpnmt/4Kb BJoSwnlywyUiSDKJtWLPYzTs8e6VO5uI1rLzkgBbcoIF9dw+6wcwayglzgaSMAZvFA64 QxSA== X-Gm-Message-State: AD7BkJJQGq2kADsVWSnnpDlpfnHCKqGAZ0PgWdWu+mIG+ZwmzyA7EVO+PUa85wxvhfvI/UroX2ogLzre4+hBbg== MIME-Version: 1.0 X-Received: by 10.50.47.82 with SMTP id b18mr18063488ign.41.1460396660183; Mon, 11 Apr 2016 10:44:20 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.198.133 with HTTP; Mon, 11 Apr 2016 10:44:19 -0700 (PDT) In-Reply-To: <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> Date: Mon, 11 Apr 2016 10:44:19 -0700 X-Google-Sender-Auth: EFEJbvG2O5yatUG5qm_Sk6G6pm8 Message-ID: Subject: Re: rfc2460bis question From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:44:23 -0000 At Fri, 8 Apr 2016 18:23:47 -0300, otroan@employees.org wrote: > While a discussion on header insertion may be necessary, it is not > in context for taking RFC2460 to IS. If a proposal is made, then the > working group should discuss that in the context of that proposal. I'm not sure what this "proposal" means...is it the proposed text for rfc2460bis from Bob like this one? https://mailarchive.ietf.org/arch/msg/ipv6/MTOkrjcscodS0C5FLmZm_LJapGY I thought it was a clarification of the original intent of the RFC2460 authors (and the understanding of most of then and now wg members), rather than some new proposal. And since it's apparent that the wording in RFC2460 wasn't really as clear as we originally as we actually saw the "misinterpretation" in RFC4782, I thought it made very sense to clarify that in rfc2460bis (to advance it to IS). > The RFC2460 text has not caused interoperability issues. Which is > why I'm not convinced this change was required. This logic doesn't make sense to me. The fact that we had RFC4782 suggests it's quite possible that we have other standard publications in future that misunterprets the original intent and really cause interoperability issues. I don't know if the violation of RFC2460 by RFC4782 is currently implemented and actually causes an interoperability issue, but even if not, I don't see any reason for not making the clarification because of that. Now, if someone who has a conflict of interest between the original RFC2460 intent and some particular new protocol wants to challenge the original intent, we might be open to consider it, depending on its technical details. But I'd say "the working group should discuss that in the context of that proposal" outside of whether to make a helpful clarification in rfc2460bis. If and when we agree on making such a change, we'll publish a new standard document that updates RFC2460(bis). > The default action, unless we can come to a different agreement, is > to leave the RFC2460 text unchanged in RFC2460bis. So, for one, I disagree with this and I suggest we should come to a "different agreement" (= making this clarification in rfc2460bis). -- JINMEI, Tatuya From nobody Mon Apr 11 11:18:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4787C12E642 for ; Mon, 11 Apr 2016 11:18:06 -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 4o49Yt-uRH1I for ; Mon, 11 Apr 2016 11:18:04 -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 2921412DF54 for ; Mon, 11 Apr 2016 11:18:04 -0700 (PDT) Received: from [192.168.3.107] (192-174-17-190.fibertel.com.ar [190.17.174.192]) (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 5CB79807A5; Mon, 11 Apr 2016 20:17:58 +0200 (CEST) Subject: Re: rfc2460bis question To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Ole Troan References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> From: Fernando Gont Message-ID: <570BE79B.8040300@si6networks.com> Date: Mon, 11 Apr 2016 15:06:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 18:18:06 -0000 On 04/11/2016 02:44 PM, 神明é”哉 wrote: > At Fri, 8 Apr 2016 18:23:47 -0300, > otroan@employees.org wrote: > >> While a discussion on header insertion may be necessary, it is not >> in context for taking RFC2460 to IS. If a proposal is made, then the >> working group should discuss that in the context of that proposal. > > I'm not sure what this "proposal" means...is it the proposed text for > rfc2460bis from Bob like this one? > https://mailarchive.ietf.org/arch/msg/ipv6/MTOkrjcscodS0C5FLmZm_LJapGY > > I thought it was a clarification of the original intent of the RFC2460 > authors (and the understanding of most of then and now wg members), > rather than some new proposal. And since it's apparent that the > wording in RFC2460 wasn't really as clear as we originally as we > actually saw the "misinterpretation" in RFC4782, I thought it made > very sense to clarify that in rfc2460bis (to advance it to IS). > >> The RFC2460 text has not caused interoperability issues. Which is >> why I'm not convinced this change was required. > > This logic doesn't make sense to me. The fact that we had RFC4782 > suggests it's quite possible that we have other standard publications > in future that misunterprets the original intent and really cause > interoperability issues. I don't know if the violation of RFC2460 by > RFC4782 is currently implemented and actually causes an > interoperability issue, but even if not, I don't see any reason for > not making the clarification because of that. > > Now, if someone who has a conflict of interest between the original > RFC2460 intent and some particular new protocol wants to challenge > the original intent, we might be open to consider it, depending > on its technical details. But I'd say "the working group should > discuss that in the context of that proposal" outside of whether to > make a helpful clarification in rfc2460bis. If and when we agree on > making such a change, we'll publish a new standard document that > updates RFC2460(bis). > >> The default action, unless we can come to a different agreement, is >> to leave the RFC2460 text unchanged in RFC2460bis. > > So, for one, I disagree with this and I suggest we should come to a > "different agreement" (= making this clarification in rfc2460bis). +1 (couldn't write it down better than this) -- 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 11 13:12:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D412F2A1 for ; Mon, 11 Apr 2016 13:12:51 -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 h1bgeEP4WiWS for ; Mon, 11 Apr 2016 13:12:48 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 33EFC12F223 for ; Mon, 11 Apr 2016 13:12:48 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id n1so130294786pfn.2 for ; Mon, 11 Apr 2016 13:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N/Gp7eW2tLDjzj4dErhXjr1Ny+r/GX2YgM5H+g5mI5Q=; b=ZXbIi7Lo1873EyE9asunf4Ij9wcy2cZ8bKCHDx4Yc9kQj7KlFlRE3ZrTAMvTLVO+su OKjigHTj4/XuoV6cRX1aIXsd4i3LVGY/xwMHLh1IvWQPCU8l8gRTgegaNqJ936d7rMkk rNB8Ll6jMfR3GXpbjxn/mDePQ0M1/V18K5M2QSYGfU3dZmdHA5cXsBepLX3P+85Mqjcf m3XOaseRW1p1YhgZQYQxAgWM9wNP4BRksM2tenoKOAedNne+F9No+EJDn1Bxbce4mryv f0csX02YO7CpzW7H2AqOoRMZN7dLYEoSMIxMh9DsHF9r71jXfZuF68z6aStF9RhJth0n 51pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=N/Gp7eW2tLDjzj4dErhXjr1Ny+r/GX2YgM5H+g5mI5Q=; b=VDtXDwuT8tUQB/9So+H27nhiquMJthb686PQSoB2VCzN3nrZDEOA4Pg91NYoeeoFSN f7KcgytljMJ2RWRip1ufVjR3aTJpu1B6lHviYNLnLq8wBXCnl0hAiGlJGc0dk+x5AiTd okOC1xN7WdTWW46J31Wf3UdETNiehrH/sAczWsYlNb8t2uyzxuqBuDoc0IILoNXnQTW1 WXzPew5m+443tX+pJt2oGBVtsJ/F2nWOXrMc5l8kOf/XWu0UTyQs5W1Se5SiShU5H8C9 QHao+7U05jQkd/GmCACzBs7i63Dmokj/KuKagN9bAmjJSZJe4bkibafYMQ9XvTtkZ/fe QYWg== X-Gm-Message-State: AD7BkJKWvVYzi5ZU5MxOGpdz0QavpWsk8Q8TUdlsAEX14IasuP+dbfrYY5NNpEQbvS5JMQ== X-Received: by 10.98.10.74 with SMTP id s71mr35346352pfi.86.1460405567809; Mon, 11 Apr 2016 13:12:47 -0700 (PDT) Received: from ?IPv6:2406:e007:4a67:1:28cc:dc4c:9703:6781? ([2406:e007:4a67:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k65sm38134664pfb.30.2016.04.11.13.12.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 13:12:45 -0700 (PDT) Subject: Re: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network To: "Mudric, Dusan (Dusan)" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> <5705BCBA.1030007@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8CBCC6@AZ-US1EXMB03.global.avaya.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570C053C.7050703@gmail.com> Date: Tue, 12 Apr 2016 08:12:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A8CBCC6@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:12:51 -0000 On 12/04/2016 04:28, Mudric, Dusan (Dusan) wrote: > Hi Brian, >=20 > Should the draft be more specific explaining where the A=3DL=3D0 prefix= should be stored and how the prefix should be used? Like: > - Should A=3DL=3D0 prefix be added to the prefix list and use for on-li= nk determination? (you said no) > - Should A=3DL=3D0 prefix used for SLAAC? (you said no) Yes, it would be reasonable to add a sentence clarifying these two points= , which are more or less the definitions of A=3D0 and L=3D0. > - How is A=3DL=3D0 prefix going to help the first hop router selection?= I think that is clear already - i.e., exactly the same as when A=3D1 or L= =3D1. Brian >=20 > Thanks, > Dusan. >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Wednesday, April 06, 2016 9:50 PM > To: Mudric, Dusan (Dusan); =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > Cc: ipv6@ietf.org > Subject: draft-ietf-6man-multi-homed-host - Routing packets from hosts = in a multi-prefix network >=20 > Dusan, >=20 > As far as I know we are only changing the A=3DL=3D0 case. If A=3D0, the= prefix is not used for SLAAC at all, and if L=3D0 the prefix should not = be added to the on-link prefix list. >=20 > To be clear, L=3D0 doesn't mean the prefix is off-link. It just means "= I'm not telling you it's on-link". >=20 > So previously a host could simply ignore the PIO with A=3DL=3D0. But no= w it will be a useful next-hop router signal to the host, if addresses in= that prefix have been assigned in another way, typically by DHCPv6. >=20 > Does that make sense? >=20 > Brian >=20 > On 07/04/2016 07:40, Mudric, Dusan (Dusan) wrote: >> Hi Brian, >> >> "Routing packets from hosts in a multi-prefix network" says: >> A router >> that advertises a prefix indicates that it is able to appropriately= >> route packets with source addresses within that prefix, regardless = of >> the setting of the L and A flags in the PIO. >> >> a host SHOULD NOT ignore a PIO simply because both L and >> A flags are cleared; a router SHOULD be able to send such a PIO. >> >> A host SHOULD select >> default routers for each prefix it is assigned an address in. >> >> The prefix list is used to find out if the destination address is on-l= ink.=20 >> >> If the router can route the packets from a host with the source addres= s using L=3D0 prefix, theoretically off-link prefix can be used for SLAAC= address. The problem is that L=3D0 prefix might be used on other links a= nd if the host creates SLAAC address using L=3D0 prefix, the host will no= t be able to detect if the address is in use (DAD does not work between d= ifferent router links). For that reason looks like L=3D0 prefix should no= t be used for SLAAC. If L=3D0 prefix is not use for SLAAC, there will be = no source address with L=3D0 prefix and L=3D0 prefixes will not help host= to find the first hop router. Consequently, hosts can ignore L=3D0 prefi= xes. >> >> Am I missing something about L=3D0 prefixes? >> >> Thanks, >> Dusan. >> >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of=20 >> ipv6-request@ietf.org >> Sent: Monday, February 22, 2016 3:00 PM >> To: ipv6@ietf.org >> Subject: ipv6 Digest, Vol 142, Issue 35 >> >> Send ipv6 mailing list submissions to >> ipv6@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> =09 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >> man_listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLe= aJxhf3 >> iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQw= wq >> 530&s=3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D >> or, via email, send a message with subject or body 'help' to >> ipv6-request@ietf.org >> >> You can reach the person managing the list at >> ipv6-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific th= an "Re: Contents of ipv6 digest..." >> >> >> Today's Topics: >> >> 1. I-D Action: draft-ietf-6man-multi-homed-host-05.txt >> (internet-drafts@ietf.org) >> 2. I-D Action: draft-ietf-6man-multi-homed-host-06.txt >> (internet-drafts@ietf.org) >> >> >> ----------------------------------------------------------------------= >> >> Message: 1 >> Date: Mon, 22 Feb 2016 10:32:52 -0800 >> From: internet-drafts@ietf.org >> To: >> Cc: ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-multi-homed-host-05.txt >> Message-ID: <20160222183252.21102.35271.idtracker@ietfa.amsl.com> >> Content-Type: text/plain; charset=3D"utf-8" >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the IPv6 Maintenance of the IETF. >> >> Title : Routing packets from hosts in a multi-prefix= network >> Authors : Fred Baker >> Brian Carpenter >> Filename : draft-ietf-6man-multi-homed-host-05.txt >> Pages : 13 >> Date : 2016-02-22 >> >> Abstract: >> This document describes expected IPv6 host behavior in a network th= at >> has more than one prefix, each allocated by an upstream network tha= t >> implements BCP 38 ingress filtering, when the host has multiple >> routers to choose from. It also applies to other scenarios such as= >> the usage of stateful firewalls that effectively act as address-bas= ed >> filters. This host behavior may interact with source address >> selection in a given implementation, but logically follows it. Giv= en >> that the network or host is, or appears to be, multihomed with >> multiple provider-allocated addresses, that the host has elected to= >> use a source address in a given prefix, and that some but not all >> neighboring routers are advertising that prefix in their Router >> Advertisement Prefix Information Options, this document specifies t= o >> which router a host should present its transmission. It updates RF= C >> 4861. >> >> >> The IETF datatracker status page for this draft is: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f. >> org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBFp= WQw8 >> bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o >> 3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew5= _Z >> vzDS1STFtTjDg&e=3D >> >> There's also a htmlized version available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_= ht >> ml_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQICAg&c=3DBFpW= Qw8b >> suKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhf= g8o3 >> sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DWqnr6PzhAWzCUOMlH0v2MPK87Kyhp= If >> l1sDF96UNhP4&e=3D >> >> A diff from the previous version is available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rf= cd >> iff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQICA= g& >> c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQG= Q2kY >> &m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DvPYONcimyGIvGJFl1= Th6R >> V-kSJv79qPXaULdoyeOHEo&e=3D >> >> >> Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.or= g. >> >> Internet-Drafts are also available by anonymous FTP at: >> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_inte= rn >> et-2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf= 3iCrhI >> oUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530= &s >> =3DDKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 22 Feb 2016 10:55:30 -0800 >> From: internet-drafts@ietf.org >> To: >> Cc: ipv6@ietf.org >> Subject: I-D Action: draft-ietf-6man-multi-homed-host-06.txt >> Message-ID: <20160222185530.5662.71093.idtracker@ietfa.amsl.com> >> Content-Type: text/plain; charset=3D"utf-8" >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the IPv6 Maintenance of the IETF. >> >> Title : Routing packets from hosts in a multi-prefix= network >> Authors : Fred Baker >> Brian Carpenter >> Filename : draft-ietf-6man-multi-homed-host-06.txt >> Pages : 13 >> Date : 2016-02-22 >> >> Abstract: >> This document describes expected IPv6 host behavior in a network th= at >> has more than one prefix, each allocated by an upstream network tha= t >> implements BCP 38 ingress filtering, when the host has multiple >> routers to choose from. It also applies to other scenarios such as= >> the usage of stateful firewalls that effectively act as address-bas= ed >> filters. This host behavior may interact with source address >> selection in a given implementation, but logically follows it. Giv= en >> that the network or host is, or appears to be, multihomed with >> multiple provider-allocated addresses, that the host has elected to= >> use a source address in a given prefix, and that some but not all >> neighboring routers are advertising that prefix in their Router >> Advertisement Prefix Information Options, this document specifies t= o >> which router a host should present its transmission. It updates RF= C >> 4861. >> >> >> The IETF datatracker status page for this draft is: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f. >> org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBFp= WQw8 >> bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o >> 3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew5= _Z >> vzDS1STFtTjDg&e=3D >> >> There's also a htmlized version available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_= ht >> ml_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQICAg&c=3DBFpW= Qw8b >> suKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhf= g8o3 >> sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DlGfMGfWC7GV6V-rewMLkuXhmMv8qC= GB >> HIxhCsFmkOnY&e=3D >> >> A diff from the previous version is available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rf= cd >> iff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQICA= g& >> c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQG= Q2kY >> &m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DUFS97FbjEQDBE-DJB= ZaJF >> 7J3umdmn66PA1Z4yc95xjU&e=3D >> >> >> Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.or= g. >> >> Internet-Drafts are also available by anonymous FTP at: >> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_inte= rn >> et-2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf= 3iCrhI >> oUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530= &s >> =3DDKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D >> >> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> ipv6 mailing list >> ipv6@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= il >> man_listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLe= aJxhf3 >> iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQw= wq >> 530&s=3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D >> >> >> ------------------------------ >> >> End of ipv6 Digest, Vol 142, Issue 35 >> ************************************* >> From nobody Mon Apr 11 13:15:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8286612DD5C for ; Mon, 11 Apr 2016 13:15:14 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prgn_CI9aZk6 for ; Mon, 11 Apr 2016 13:15:12 -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 932B812F3B2 for <6man@ietf.org>; Mon, 11 Apr 2016 13:15:08 -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 u3BKF8KS038663; Mon, 11 Apr 2016 13:15:08 -0700 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3BKF0ol038356 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=OK); Mon, 11 Apr 2016 13:15:01 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.181]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.58]) with mapi id 14.03.0294.000; Mon, 11 Apr 2016 13:15:00 -0700 From: "Templin, Fred L" To: Dave Thaler , "Pascal Thubert (pthubert)" , "6man@ietf.org" <6man@ietf.org> Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfgAArF4QAAAd27ABBtI/gA== Date: Mon, 11 Apr 2016 20:14:59 +0000 Message-ID: <2134F8430051B64F815C691A62D98318359029EC@XCH-BLV-105.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-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D98318359029ECXCHBLV105nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:15:14 -0000 --_000_2134F8430051B64F815C691A62D98318359029ECXCHBLV105nwnosb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Section 3 of RFC1981 already says: "Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can to appear to be directly connected but is in fact more than one hop away." This would seem to already imply that there may be nodes on the path that do not decrement the hopcount but could return ICMP PTBs. Do you think this needs further clarification vis-=E0-vis the text you propose= d? Thanks - Fred From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Wednesday, April 06, 2016 7:44 AM To: Pascal Thubert (pthubert) ; 6man@ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Yes, it refers to the node, and good grammatical point. So to take your f= eedback in a different spot: NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node (regardless of whether it decrements the Hop Limit) along= the path, that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. I.e. moved it up to right after the first existing use of "node". From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, April 6, 2016 11:42 AM To: Dave Thaler >; 6man= @ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Hello Dave, If "It" refers to the node, maybe it would be more readable to place the ch= ange at the end of the sentence? Cheers, Pascal From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: mercredi 6 avril 2016 11:21 To: 6man@ietf.org Subject: Proposed RFC 1981bis clarification regarding Hop Limit decrement b= eing orthogonal OLD: If any of the packets sent on that path are too large to be forwarded OLD: by some node along the path, that node will discard them and return OLD: ICMPv6 Packet Too Big messages [ICMPv6]. NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node along the path (regardless of whether it decrements the H= op Limit), that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. That is, just add the phrase "(regardless of whether it decrements the Hop = Limit)" to the existing sentence. Dave --_000_2134F8430051B64F815C691A62D98318359029ECXCHBLV105nwnosb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Section 3 of RFC1981 a= lready says:

 

   “No= te that Path MTU Discovery must be performed even in cases where a

   node &quo= t;thinks" a destination is attached to the same link as itself.

   In a situ= ation such as when a neighboring router acts as proxy [ND]

   for some = destination, the destination can to appear to be directly=

   connected= but is in fact more than one hop away.”

 

This would seem to alr= eady imply that there may be nodes on the path

that do not decrement = the hopcount but could return ICMP PTBs. Do

you think this needs f= urther clarification vis-=E0-vis the text you proposed?

 

Thanks - Fred

 

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] = On Behalf Of Dave Thaler
Sent: Wednesday, April 06, 2016 7:44 AM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; 6man@ietf.= org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Yes, it refers to the = node, and good grammatical point.   So to take your feedback in a= different spot:

 

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node (regardless of whet=
her it decrements the Hop Limit) along the path, that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

I.e. moved it up to ri= ght after the first existing use of “node”.

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Wednesday, April 6, 2016 11:42 AM
To: Dave Thaler <dthaler= @microsoft.com>; 6man@ietf.org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Hello Dave,=

 

If “It” re= fers to the node, maybe it would be more readable to place the change at th= e end of the sentence?

 

Cheers,

 = ;

Pascal

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: mercredi 6 avril 2016 11:21
To: 6man@ietf.org
Subject: Proposed RFC 1981bis clarification regarding Hop Limit decr= ement being orthogonal

 

OLD: If any of the pack=
ets sent on that path are too large to be forwarded

= OLD: by some node along the path, that node will discard them and return

= OLD: ICMPv6 Packet Too Big messages [ICMPv6]. 

=  

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node along the path (reg=
ardless of whether it decrements the Hop Limit), that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

That is, just add the phrase “(rega= rdless of whether it decrements the Hop Limit)” to the existing sente= nce.

 

Dave

--_000_2134F8430051B64F815C691A62D98318359029ECXCHBLV105nwnosb_-- From nobody Mon Apr 11 18:27:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4412DAB5 for ; Mon, 11 Apr 2016 18:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 A0D1hTT5fMCQ for ; Mon, 11 Apr 2016 18:27:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D3F12DAA1 for <6man@ietf.org>; Mon, 11 Apr 2016 18:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xo5Au1e/a3yIuxtQIDnIxjgR49llxNu86YRsjhxIL7I=; b=nbnEqOjubNJGwCN2+z3UHyYtiHiNNUrRejEZguXOYoyCAvLM/PLCIviN1OJym4IG/PtnphWeyNgBpS7q82lgbu08CHslCJoNIWgKSWOVoLW35IhunuBzVBmqwEKAY3dUrXSCUz1UUMvZyb0TkB7dlLqtgx4Qft7+oivV5PfBShc= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 12 Apr 2016 01:27:25 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0447.029; Tue, 12 Apr 2016 01:27:25 +0000 From: Dave Thaler To: "Templin, Fred L" , "Pascal Thubert (pthubert)" , "6man@ietf.org" <6man@ietf.org> Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfgAArF4QAAAd27ABBtI/gAALFPfA Date: Tue, 12 Apr 2016 01:27:25 +0000 Message-ID: References: <2134F8430051B64F815C691A62D98318359029EC@XCH-BLV-105.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D98318359029EC@XCH-BLV-105.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: boeing.com; dkim=none (message not signed) header.d=none;boeing.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::16a] x-ms-office365-filtering-correlation-id: caf3d929-e5f9-43cc-a44d-08d362719ae8 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0717; 5:dXw2j2FPodH/dWmXwyFO3880P1U7RCOjsvIWBkTy/YOazltnt+imwwu5B81poHUkwblyNWqFkGv2xQLHKWvayjEi1hC5l+6xWKfUZZQNEzI2IVeIWGTQCA2pZwP7TPw3KroM6AnCnwYwCQZrHJX+lg==; 24:v4NRQkmOaO8tESYvt5Zot/KAhPZiiSNVUNnuqgFuOKTTEdVjsNXXXAFloyPzJnRs12LrGaCmR4EseFkuwOT7LldHr9wUKqUG0hgiLjht93Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0717; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0717; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0717; x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(81166005)(74316001)(2906002)(87936001)(3660700001)(76576001)(3280700002)(5890100001)(2501003)(19580395003)(33656002)(19300405004)(10400500002)(50986999)(54356999)(76176999)(9686002)(5005710100001)(5001770100001)(5002640100001)(11100500001)(10290500002)(122556002)(5008740100001)(10090500001)(5003600100002)(77096005)(15975445007)(2900100001)(2950100001)(5004730100002)(86362001)(1096002)(1220700001)(92566002)(107886002)(19625215002)(102836003)(790700001)(6116002)(189998001)(99286002)(586003)(19580405001)(16236675004)(93886004)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0717; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB07179B643E9D771513972362A3950DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2016 01:27:25.7104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0717 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 01:27:49 -0000 --_000_DM2PR0301MB07179B643E9D771513972362A3950DM2PR0301MB0717_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes because I think people in general either miss that or misinterpret that= . The text quoted might "imply" that to you but it doesn't to me. For example, if you have a proxy that does decrement TTL, but responds to N= D, then I would say that's what section 3 refers to. From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Monday, April 11, 2016 1:15 PM To: Dave Thaler ; Pascal Thubert (pthubert) ; 6man@ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Hi Dave, Section 3 of RFC1981 already says: "Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can to appear to be directly connected but is in fact more than one hop away." This would seem to already imply that there may be nodes on the path that do not decrement the hopcount but could return ICMP PTBs. Do you think this needs further clarification vis-=E0-vis the text you propose= d? Thanks - Fred From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Wednesday, April 06, 2016 7:44 AM To: Pascal Thubert (pthubert) >; 6man@ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Yes, it refers to the node, and good grammatical point. So to take your f= eedback in a different spot: NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node (regardless of whether it decrements the Hop Limit) along= the path, that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. I.e. moved it up to right after the first existing use of "node". From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, April 6, 2016 11:42 AM To: Dave Thaler >; 6man= @ietf.org Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decreme= nt being orthogonal Hello Dave, If "It" refers to the node, maybe it would be more readable to place the ch= ange at the end of the sentence? Cheers, Pascal From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler Sent: mercredi 6 avril 2016 11:21 To: 6man@ietf.org Subject: Proposed RFC 1981bis clarification regarding Hop Limit decrement b= eing orthogonal OLD: If any of the packets sent on that path are too large to be forwarded OLD: by some node along the path, that node will discard them and return OLD: ICMPv6 Packet Too Big messages [ICMPv6]. NEW: If any of the packets sent on that path are too large to be forwarded NEW: by some node along the path (regardless of whether it decrements the H= op Limit), that node will discard them and return NEW: ICMPv6 Packet Too Big messages [ICMPv6]. That is, just add the phrase "(regardless of whether it decrements the Hop = Limit)" to the existing sentence. Dave --_000_DM2PR0301MB07179B643E9D771513972362A3950DM2PR0301MB0717_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes because I think pe= ople in general either miss that or misinterpret that.

The text quoted might = “imply” that to you but it doesn’t to me.

For example, if you ha= ve a proxy that does decrement TTL, but responds to ND, then I would say th= at’s what section 3 refers to.

 

From: Templin, Fred L [mailto:Fred.L.Templin@= boeing.com]
Sent: Monday, April 11, 2016 1:15 PM
To: Dave Thaler <dthaler@microsoft.com>; Pascal Thubert (pthub= ert) <pthubert@cisco.com>; 6man@ietf.org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Hi Dave,

 

Section 3 of RFC1981 a= lready says:

 

   “No= te that Path MTU Discovery must be performed even in cases where a

   node &quo= t;thinks" a destination is attached to the same link as itself.

   In a situ= ation such as when a neighboring router acts as proxy [ND]

   for some = destination, the destination can to appear to be directly=

   connected= but is in fact more than one hop away.”

 

This would seem to alr= eady imply that there may be nodes on the path

that do not decrement = the hopcount but could return ICMP PTBs. Do

you think this needs f= urther clarification vis-=E0-vis the text you proposed?

 

Thanks - Fred

 

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Wednesday, April 06, 2016 7:44 AM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; 6man@ietf.org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Yes, it refers to the = node, and good grammatical point.   So to take your feedback in a= different spot:

 

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node (regardless of whet=
her it decrements the Hop Limit) along the path, that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

I.e. moved it up to ri= ght after the first existing use of “node”.

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Wednesday, April 6, 2016 11:42 AM
To: Dave Thaler <dthaler= @microsoft.com>; 6man@ietf.org
Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal

 

Hello Dave,=

 

If “It” re= fers to the node, maybe it would be more readable to place the change at th= e end of the sentence?

 

Cheers,

 = ;

Pascal

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: mercredi 6 avril 2016 11:21
To: 6man@ietf.org
Subject: Proposed RFC 1981bis clarification regarding Hop Limit decr= ement being orthogonal

 

OLD: If any of the pack=
ets sent on that path are too large to be forwarded

= OLD: by some node along the path, that node will discard them and return

= OLD: ICMPv6 Packet Too Big messages [ICMPv6]. 

=  

NEW: If any of the packets sent on th=
at path are too large to be forwarded
NEW: by some node along the path (reg=
ardless of whether it decrements the Hop Limit), that node will discard the=
m and return

= NEW: ICMPv6 Packet Too Big messages [ICMPv6]. 

 

That is, just add the phrase “(rega= rdless of whether it decrements the Hop Limit)” to the existing sente= nce.

 

Dave

--_000_DM2PR0301MB07179B643E9D771513972362A3950DM2PR0301MB0717_-- From nobody Tue Apr 12 08:01:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A423A12EED8 for ; Tue, 12 Apr 2016 08:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.916 X-Spam-Level: X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] 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 8rbnVyB1_Xpx for ; Tue, 12 Apr 2016 08:01:46 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525E112DF1B for ; Tue, 12 Apr 2016 08:01:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D1AQB7DQ1X/xUHmMZeGQEBAQGCbytTfQavCItYAQ2BdCGFbAIcgRc4FAEBAQEBAQFlJ4RBAQEBAQIBEhERGiALDAQCAQYCDQQDAQEBAQICBgIbAwICAh8QARQBCAgCBAENBQgVBAGHcQMKCAENkgaSTIpLjHUNhQ0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUmhEqCQYFOEQEeFoJqK4IrBYdyj2UxAYV2hV9BAYNcFzeEAIMchT+HS4dcHgEBQoIEGRWBNWwBAQGITjYBfQEBAQ X-IPAS-Result: A2D1AQB7DQ1X/xUHmMZeGQEBAQGCbytTfQavCItYAQ2BdCGFbAIcgRc4FAEBAQEBAQFlJ4RBAQEBAQIBEhERGiALDAQCAQYCDQQDAQEBAQICBgIbAwICAh8QARQBCAgCBAENBQgVBAGHcQMKCAENkgaSTIpLjHUNhQ0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUmhEqCQYFOEQEeFoJqK4IrBYdyj2UxAYV2hV9BAYNcFzeEAIMchT+HS4dcHgEBQoIEGRWBNWwBAQGITjYBfQEBAQ X-IronPort-AV: E=Sophos;i="5.24,474,1454994000"; d="scan'208";a="169990321" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Apr 2016 11:01:38 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 12 Apr 2016 11:01:31 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Tue, 12 Apr 2016 11:01:29 -0400 From: "Mudric, Dusan (Dusan)" To: Brian E Carpenter , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: RE: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network Thread-Topic: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network Thread-Index: AQHRlC6a7kl0UtKK30iiqx+fIMJHOp+GaVHw Date: Tue, 12 Apr 2016 15:01:28 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8D37A3@AZ-US1EXMB03.global.avaya.com> References: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> <5705BCBA.1030007@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8CBCC6@AZ-US1EXMB03.global.avaya.com> <570C053C.7050703@gmail.com> In-Reply-To: <570C053C.7050703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 15:01:50 -0000 SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGRyYWZ0IHJlZ2FyZGluZyBBPUw9 MCBwcmVmaXguIA0KDQo+PiAtIEhvdyBpcyBBPUw9MCBwcmVmaXggZ29pbmcgdG8gaGVscCB0aGUg Zmlyc3QgaG9wIHJvdXRlciBzZWxlY3Rpb24/DQo+SSB0aGluayB0aGF0IGlzIGNsZWFyIGFscmVh ZHkgLSBpLmUuLCBleGFjdGx5IHRoZSBzYW1lIGFzIHdoZW4gQT0xIG9yIEw9MS4NCg0KSG93IGlz IGl0IGdvaW5nIHRvIHdvcms/IFNBU0Egd2lsbCBzZWxlY3QgdGhlIHNvdXJjZSBhZGRyZXNzIGJh c2VkIG9uIHRoZSBwcmVmaXggdGhhdCB3YXMgYWR2ZXJ0aXNlZCBieSB0aGUgZmlyc3QgaG9wIHJv dXRlciB0byB0aGUgZ2l2ZW4gZGVzdGluYXRpb24uIFNlbmQgYWxnb3JpdGhtIHNlbGVjdCB0aGUg Zmlyc3QgaG9wIHJvdXRlciBmb3Igb2ZmLWxpbmsgZGVzdGluYXRpb25zIHVzaW5nIGEgZGVmYXVs dCByb3V0ZXIgbGlzdC4gDQoNClExOiBIb3cgaXMgdGhlIFNBU0EgYWRkcmVzcyBwcmVmaXggZ29p bmcgdG8gYmUgY29tcGFyZWQgYWdhaW5zdCBBPUw9MCBwcmVmaXggZHVyaW5nIHRoZSBkZWZhdWx0 IHJvdXRlciBzZWxlY3Rpb24/DQpRMjogSXQgbWFrZXMgc2Vuc2UgdG8gc3RvcmUgdGhlIEE9TD0x IHByZWZpeGVzIGZvciBlYWNoIGRlZmF1bHQgcm91dGVyIGVudHJ5IGFuZCBjb21wYXJlIHRoZW0g YWdhaW5zdCBTQVNBIGFkZHJlc3MgcHJlZml4IGR1cmluZyB0aGUgZmlyc3QgaG9wZSByb3V0ZXIg c2VsZWN0aW9uLiBBPUw9MSBwcmVmaXhlcyBhcmUgdXNlZCB0byBjcmVhdGUgZGV2aWNlIGFkZHJl c3Nlcy4gSG93ZXZlciwgQT1MPTAgcHJlZml4ZXMgYXJlIG5vdCB1c2VkIHRvIGNyZWF0ZSBkZXZp Y2UgYWRkcmVzc2VzICh5b3UgYWdyZWVkIG9uIHRoYXQpLiBJdCBkb2VzIG5vdCBtYWtlIHNlbnNl LCB0byBtZSwgdG8gY29tcGFyZSBBPUw9MCBwcmVmaXhlcyBhZ2FpbnN0IFNBU0EgYWRkcmVzcyBw cmVmaXguIFRoZXJlIHdpbGwgbmV2ZXIgYmUgYSBtYXRjaCBiZWNhdXNlIG5vbmUgb2YgU0xBQUMg YWRkcmVzc2VzIHdpbGwgZXZlciBiZSBjcmVhdGVkIHVzaW5nIEE9TD0wIHByZWZpeGVzLiBJIHRo aW5rIEE9TD0wIHByZWZpeGVzIGFyZSBub3QgbmVlZGVkIGFuZCBzaG91bGQgbm90IGJlIHN0b3Jl ZCBpbiBkZWZhdWx0IHJvdXRlciBlbnRyaWVzLg0KUTM6IEkgZGlkIG5vdCBub3RpY2UgeW91IG1l bnRpb25lZCBob3cgQT1MPTEgcHJlZml4ZXMgYXJlIHN0b3JlZCBkdXJpbmcgUkEgYW5kIHVzZWQg ZHVyaW5nIHRoZSBkZWZhdWx0IHJvdXRlciBzZWxlY3Rpb24uIFRoaXMgc2hvdWxkIGJlIGNsYXJp ZmllZCwgaWYgaXMgbm90IGFscmVhZHkuDQoNClJlZ2FyZHMsDQpEdXNhbg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiA0OjEz IFBNDQpUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pOyDnpZ7mmI7pgZTlk4kNCkNjOiBpcHY2QGll dGYub3JnDQpTdWJqZWN0OiBSZTogZHJhZnQtaWV0Zi02bWFuLW11bHRpLWhvbWVkLWhvc3QgLSBS b3V0aW5nIHBhY2tldHMgZnJvbSBob3N0cyBpbiBhIG11bHRpLXByZWZpeCBuZXR3b3JrDQoNCk9u IDEyLzA0LzIwMTYgMDQ6MjgsIE11ZHJpYywgRHVzYW4gKER1c2FuKSB3cm90ZToNCj4gSGkgQnJp YW4sDQo+IA0KPiBTaG91bGQgdGhlIGRyYWZ0IGJlIG1vcmUgc3BlY2lmaWMgZXhwbGFpbmluZyB3 aGVyZSB0aGUgQT1MPTAgcHJlZml4IHNob3VsZCBiZSBzdG9yZWQgYW5kIGhvdyB0aGUgcHJlZml4 IHNob3VsZCBiZSB1c2VkPyBMaWtlOg0KPiAtIFNob3VsZCBBPUw9MCBwcmVmaXggYmUgYWRkZWQg dG8gdGhlIHByZWZpeCBsaXN0IGFuZCB1c2UgZm9yIG9uLWxpbmsgDQo+IGRldGVybWluYXRpb24/ ICh5b3Ugc2FpZCBubykNCj4gLSBTaG91bGQgQT1MPTAgcHJlZml4IHVzZWQgZm9yIFNMQUFDPyAo eW91IHNhaWQgbm8pDQoNClllcywgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0byBhZGQgYSBzZW50 ZW5jZSBjbGFyaWZ5aW5nIHRoZXNlIHR3byBwb2ludHMsIHdoaWNoIGFyZSBtb3JlIG9yIGxlc3Mg dGhlIGRlZmluaXRpb25zIG9mIEE9MCBhbmQgTD0wLg0KDQo+IC0gSG93IGlzIEE9TD0wIHByZWZp eCBnb2luZyB0byBoZWxwIHRoZSBmaXJzdCBob3Agcm91dGVyIHNlbGVjdGlvbj8NCg0KSSB0aGlu ayB0aGF0IGlzIGNsZWFyIGFscmVhZHkgLSBpLmUuLCBleGFjdGx5IHRoZSBzYW1lIGFzIHdoZW4g QT0xIG9yIEw9MS4NCg0KICAgQnJpYW4NCg0KPiANCj4gVGhhbmtzLA0KPiBEdXNhbi4NCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFtt YWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEFw cmlsIDA2LCAyMDE2IDk6NTAgUE0NCj4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKTsg56We5piO 6YGU5ZOJDQo+IENjOiBpcHY2QGlldGYub3JnDQo+IFN1YmplY3Q6IGRyYWZ0LWlldGYtNm1hbi1t dWx0aS1ob21lZC1ob3N0IC0gUm91dGluZyBwYWNrZXRzIGZyb20gaG9zdHMgDQo+IGluIGEgbXVs dGktcHJlZml4IG5ldHdvcmsNCj4gDQo+IER1c2FuLA0KPiANCj4gQXMgZmFyIGFzIEkga25vdyB3 ZSBhcmUgb25seSBjaGFuZ2luZyB0aGUgQT1MPTAgY2FzZS4gSWYgQT0wLCB0aGUgcHJlZml4IGlz IG5vdCB1c2VkIGZvciBTTEFBQyBhdCBhbGwsIGFuZCBpZiBMPTAgdGhlIHByZWZpeCBzaG91bGQg bm90IGJlIGFkZGVkIHRvIHRoZSBvbi1saW5rIHByZWZpeCBsaXN0Lg0KPiANCj4gVG8gYmUgY2xl YXIsIEw9MCBkb2Vzbid0IG1lYW4gdGhlIHByZWZpeCBpcyBvZmYtbGluay4gSXQganVzdCBtZWFu cyAiSSdtIG5vdCB0ZWxsaW5nIHlvdSBpdCdzIG9uLWxpbmsiLg0KPiANCj4gU28gcHJldmlvdXNs eSBhIGhvc3QgY291bGQgc2ltcGx5IGlnbm9yZSB0aGUgUElPIHdpdGggQT1MPTAuIEJ1dCBub3cg aXQgd2lsbCBiZSBhIHVzZWZ1bCBuZXh0LWhvcCByb3V0ZXIgc2lnbmFsIHRvIHRoZSBob3N0LCBp ZiBhZGRyZXNzZXMgaW4gdGhhdCBwcmVmaXggaGF2ZSBiZWVuIGFzc2lnbmVkIGluIGFub3RoZXIg d2F5LCB0eXBpY2FsbHkgYnkgREhDUHY2Lg0KPiANCj4gRG9lcyB0aGF0IG1ha2Ugc2Vuc2U/DQo+ IA0KPiAgICBCcmlhbg0KPiANCj4gT24gMDcvMDQvMjAxNiAwNzo0MCwgTXVkcmljLCBEdXNhbiAo RHVzYW4pIHdyb3RlOg0KPj4gSGkgQnJpYW4sDQo+Pg0KPj4gIlJvdXRpbmcgcGFja2V0cyBmcm9t IGhvc3RzIGluIGEgbXVsdGktcHJlZml4IG5ldHdvcmsiIHNheXM6DQo+PiAgICBBIHJvdXRlcg0K Pj4gICAgdGhhdCBhZHZlcnRpc2VzIGEgcHJlZml4IGluZGljYXRlcyB0aGF0IGl0IGlzIGFibGUg dG8gYXBwcm9wcmlhdGVseQ0KPj4gICAgcm91dGUgcGFja2V0cyB3aXRoIHNvdXJjZSBhZGRyZXNz ZXMgd2l0aGluIHRoYXQgcHJlZml4LCByZWdhcmRsZXNzIG9mDQo+PiAgICB0aGUgc2V0dGluZyBv ZiB0aGUgTCBhbmQgQSBmbGFncyBpbiB0aGUgUElPLg0KPj4NCj4+ICAgIGEgaG9zdCBTSE9VTEQg Tk9UIGlnbm9yZSBhIFBJTyBzaW1wbHkgYmVjYXVzZSBib3RoIEwgYW5kDQo+PiAgICBBIGZsYWdz IGFyZSBjbGVhcmVkOyBhIHJvdXRlciBTSE9VTEQgYmUgYWJsZSB0byBzZW5kIHN1Y2ggYSBQSU8u DQo+Pg0KPj4gICAgQSBob3N0IFNIT1VMRCBzZWxlY3QNCj4+ICAgIGRlZmF1bHQgcm91dGVycyBm b3IgZWFjaCBwcmVmaXggaXQgaXMgYXNzaWduZWQgYW4gYWRkcmVzcyBpbi4NCj4+DQo+PiBUaGUg cHJlZml4IGxpc3QgaXMgdXNlZCB0byBmaW5kIG91dCBpZiB0aGUgZGVzdGluYXRpb24gYWRkcmVz cyBpcyBvbi1saW5rLiANCj4+DQo+PiBJZiB0aGUgcm91dGVyIGNhbiByb3V0ZSB0aGUgcGFja2V0 cyBmcm9tIGEgaG9zdCB3aXRoIHRoZSBzb3VyY2UgYWRkcmVzcyB1c2luZyBMPTAgcHJlZml4LCB0 aGVvcmV0aWNhbGx5IG9mZi1saW5rIHByZWZpeCBjYW4gYmUgdXNlZCBmb3IgU0xBQUMgYWRkcmVz cy4gVGhlIHByb2JsZW0gaXMgdGhhdCBMPTAgcHJlZml4IG1pZ2h0IGJlIHVzZWQgb24gb3RoZXIg bGlua3MgYW5kIGlmIHRoZSBob3N0IGNyZWF0ZXMgU0xBQUMgYWRkcmVzcyB1c2luZyBMPTAgcHJl Zml4LCB0aGUgaG9zdCB3aWxsIG5vdCBiZSBhYmxlIHRvIGRldGVjdCBpZiB0aGUgYWRkcmVzcyBp cyBpbiB1c2UgKERBRCBkb2VzIG5vdCB3b3JrIGJldHdlZW4gZGlmZmVyZW50IHJvdXRlciBsaW5r cykuIEZvciB0aGF0IHJlYXNvbiBsb29rcyBsaWtlIEw9MCBwcmVmaXggc2hvdWxkIG5vdCBiZSB1 c2VkIGZvciBTTEFBQy4gSWYgTD0wIHByZWZpeCBpcyBub3QgdXNlIGZvciBTTEFBQywgdGhlcmUg d2lsbCBiZSBubyBzb3VyY2UgYWRkcmVzcyB3aXRoIEw9MCBwcmVmaXggYW5kIEw9MCBwcmVmaXhl cyB3aWxsIG5vdCBoZWxwIGhvc3QgdG8gZmluZCB0aGUgZmlyc3QgaG9wIHJvdXRlci4gQ29uc2Vx dWVudGx5LCBob3N0cyBjYW4gaWdub3JlIEw9MCBwcmVmaXhlcy4NCj4+DQo+PiBBbSBJIG1pc3Np bmcgc29tZXRoaW5nIGFib3V0IEw9MCBwcmVmaXhlcz8NCj4+DQo+PiBUaGFua3MsDQo+PiBEdXNh bi4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaXB2NiBbbWFp bHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPj4gaXB2Ni1yZXF1ZXN0 QGlldGYub3JnDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIyLCAyMDE2IDM6MDAgUE0NCj4+ IFRvOiBpcHY2QGlldGYub3JnDQo+PiBTdWJqZWN0OiBpcHY2IERpZ2VzdCwgVm9sIDE0MiwgSXNz dWUgMzUNCj4+DQo+PiBTZW5kIGlwdjYgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQo+PiAJ aXB2NkBpZXRmLm9yZw0KPj4NCj4+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhl IFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KPj4gCQ0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpDQo+PiBsDQo+PiBt YW5fbGlzdGluZm9faXB2NiZkPUJRSUNBZyZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNC azljYkxlYUp4aGYNCj4+IDMgDQo+PiBpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmbT1saGZn OG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3cNCj4+IHEgNTMwJnM9djFBNkFWcWIx V3hZSnJvMV9MLTV5X2I2Ykh4bldaak1acl9qRTU1WDlGbyZlPQ0KPj4gb3IsIHZpYSBlbWFpbCwg c2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQo+PiAJaXB2Ni1y ZXF1ZXN0QGlldGYub3JnDQo+Pg0KPj4gWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5n IHRoZSBsaXN0IGF0DQo+PiAJaXB2Ni1vd25lckBpZXRmLm9yZw0KPj4NCj4+IFdoZW4gcmVwbHlp bmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMg dGhhbiAiUmU6IENvbnRlbnRzIG9mIGlwdjYgZGlnZXN0Li4uIg0KPj4NCj4+DQo+PiBUb2RheSdz IFRvcGljczoNCj4+DQo+PiAgICAxLiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tbXVsdGkt aG9tZWQtaG9zdC0wNS50eHQNCj4+ICAgICAgIChpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcpDQo+ PiAgICAyLiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdC0wNi50 eHQNCj4+ICAgICAgIChpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcpDQo+Pg0KPj4NCj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gLQ0KPj4NCj4+IE1lc3NhZ2U6IDENCj4+IERhdGU6IE1vbiwgMjIgRmViIDIw MTYgMTA6MzI6NTIgLTA4MDANCj4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4g VG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+PiBDYzogaXB2NkBpZXRmLm9yZw0KPj4gU3Vi amVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLW11bHRpLWhvbWVkLWhvc3QtMDUudHh0 DQo+PiBNZXNzYWdlLUlEOiA8MjAxNjAyMjIxODMyNTIuMjExMDIuMzUyNzEuaWR0cmFja2VyQGll dGZhLmFtc2wuY29tPg0KPj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYt OCINCj4+DQo+Pg0KPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4gVGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBvZiB0aGUgSUVURi4NCj4+DQo+PiAg ICAgICAgIFRpdGxlICAgICAgICAgICA6IFJvdXRpbmcgcGFja2V0cyBmcm9tIGhvc3RzIGluIGEg bXVsdGktcHJlZml4IG5ldHdvcmsNCj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRnJlZCBC YWtlcg0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBCcmlhbiBDYXJwZW50ZXINCj4+IAlG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLTZtYW4tbXVsdGktaG9tZWQtaG9zdC0wNS50eHQN Cj4+IAlQYWdlcyAgICAgICAgICAgOiAxMw0KPj4gCURhdGUgICAgICAgICAgICA6IDIwMTYtMDIt MjINCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4cGVj dGVkIElQdjYgaG9zdCBiZWhhdmlvciBpbiBhIG5ldHdvcmsgdGhhdA0KPj4gICAgaGFzIG1vcmUg dGhhbiBvbmUgcHJlZml4LCBlYWNoIGFsbG9jYXRlZCBieSBhbiB1cHN0cmVhbSBuZXR3b3JrIHRo YXQNCj4+ICAgIGltcGxlbWVudHMgQkNQIDM4IGluZ3Jlc3MgZmlsdGVyaW5nLCB3aGVuIHRoZSBo b3N0IGhhcyBtdWx0aXBsZQ0KPj4gICAgcm91dGVycyB0byBjaG9vc2UgZnJvbS4gIEl0IGFsc28g YXBwbGllcyB0byBvdGhlciBzY2VuYXJpb3Mgc3VjaCBhcw0KPj4gICAgdGhlIHVzYWdlIG9mIHN0 YXRlZnVsIGZpcmV3YWxscyB0aGF0IGVmZmVjdGl2ZWx5IGFjdCBhcyBhZGRyZXNzLWJhc2VkDQo+ PiAgICBmaWx0ZXJzLiAgVGhpcyBob3N0IGJlaGF2aW9yIG1heSBpbnRlcmFjdCB3aXRoIHNvdXJj ZSBhZGRyZXNzDQo+PiAgICBzZWxlY3Rpb24gaW4gYSBnaXZlbiBpbXBsZW1lbnRhdGlvbiwgYnV0 IGxvZ2ljYWxseSBmb2xsb3dzIGl0LiAgR2l2ZW4NCj4+ICAgIHRoYXQgdGhlIG5ldHdvcmsgb3Ig aG9zdCBpcywgb3IgYXBwZWFycyB0byBiZSwgbXVsdGlob21lZCB3aXRoDQo+PiAgICBtdWx0aXBs ZSBwcm92aWRlci1hbGxvY2F0ZWQgYWRkcmVzc2VzLCB0aGF0IHRoZSBob3N0IGhhcyBlbGVjdGVk IHRvDQo+PiAgICB1c2UgYSBzb3VyY2UgYWRkcmVzcyBpbiBhIGdpdmVuIHByZWZpeCwgYW5kIHRo YXQgc29tZSBidXQgbm90IGFsbA0KPj4gICAgbmVpZ2hib3Jpbmcgcm91dGVycyBhcmUgYWR2ZXJ0 aXNpbmcgdGhhdCBwcmVmaXggaW4gdGhlaXIgUm91dGVyDQo+PiAgICBBZHZlcnRpc2VtZW50IFBy ZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zLCB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyB0bw0KPj4g ICAgd2hpY2ggcm91dGVyIGEgaG9zdCBzaG91bGQgcHJlc2VudCBpdHMgdHJhbnNtaXNzaW9uLiAg SXQgdXBkYXRlcyBSRkMNCj4+ICAgIDQ4NjEuDQo+Pg0KPj4NCj4+IFRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4gaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLg0KPj4g b3JnX2RvY19kcmFmdC0yRGlldGYtMkQ2bWFuLTJEbXVsdGktMkRob21lZC0yRGhvc3RfJmQ9QlFJ Q0FnJmM9QkZwV1F3DQo+PiA4IA0KPj4gYnN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhm M2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWxoZmc4DQo+PiBvIA0KPj4gM3NRX1UwcVdp QWNJTzY3X09ZNmx0dlZkUHlSajJvUXd3cTUzMCZzPVBVcWplU240cFVPcnRXVkJzTmpOYWlsc1Jl dzVfDQo+PiBaDQo+PiB2ekRTMVNURnRUakRnJmU9DQo+Pg0KPj4gVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2gNCj4+IHQgDQo+PiBt bF9kcmFmdC0yRGlldGYtMkQ2bWFuLTJEbXVsdGktMkRob21lZC0yRGhvc3QtMkQwNSZkPUJRSUNB ZyZjPUJGcFdRdzgNCj4+IGINCj4+IHN1S3BsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lD cmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWxoZmc4bw0KPj4gMyANCj4+IHNRX1UwcVdpQWNJ TzY3X09ZNmx0dlZkUHlSajJvUXd3cTUzMCZzPVdxbnI2UHpoQVd6Q1VPTWxIMHYyTVBLODdLeWhw SQ0KPj4gZg0KPj4gbDFzREY5NlVOaFA0JmU9DQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZp b3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcmZjDQo+PiBkIA0KPj4g aWZmLTNGdXJsMi0zRGRyYWZ0LTJEaWV0Zi0yRDZtYW4tMkRtdWx0aS0yRGhvbWVkLTJEaG9zdC0y RDA1JmQ9QlFJQ0FnDQo+PiAmIA0KPj4gYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQzQms5 Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrDQo+PiBZIA0KPj4gJm09bGhmZzhv M3NRX1UwcVdpQWNJTzY3X09ZNmx0dlZkUHlSajJvUXd3cTUzMCZzPXZQWU9OY2lteUdJdkdKRmwx VGg2DQo+PiBSDQo+PiBWLWtTSnY3OXFQWGFVTGRveWVPSEVvJmU9DQo+Pg0KPj4NCj4+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9ZnRwLTNBX19mdHAuaWV0Zi5vcmdfaW50ZXINCj4+IG4g DQo+PiBldC0yRGRyYWZ0c18mZD1CUUlDQWcmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9VVQz Qms5Y2JMZWFKeGhmM2lDcmgNCj4+IEkgDQo+PiBvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhm ZzhvM3NRX1UwcVdpQWNJTzY3X09ZNmx0dlZkUHlSajJvUXd3cTUzMCYNCj4+IHMgPURLRHB3YnFL eFpSeU1YcWdTa2xOeEUtelAxRFp0ZElBS25yTzluREJXaXMmZT0NCj4+DQo+Pg0KPj4NCj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+IE1lc3NhZ2U6IDINCj4+IERhdGU6 IE1vbiwgMjIgRmViIDIwMTYgMTA6NTU6MzAgLTA4MDANCj4+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPj4gVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+PiBDYzogaXB2NkBp ZXRmLm9yZw0KPj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLW11bHRpLWhv bWVkLWhvc3QtMDYudHh0DQo+PiBNZXNzYWdlLUlEOiA8MjAxNjAyMjIxODU1MzAuNTY2Mi43MTA5 My5pZHRyYWNrZXJAaWV0ZmEuYW1zbC5jb20+DQo+PiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47 IGNoYXJzZXQ9InV0Zi04Ig0KPj4NCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE1haW50ZW5hbmNlIG9mIHRoZSBJ RVRGLg0KPj4NCj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUm91dGluZyBwYWNrZXRzIGZy b20gaG9zdHMgaW4gYSBtdWx0aS1wcmVmaXggbmV0d29yaw0KPj4gICAgICAgICBBdXRob3JzICAg ICAgICAgOiBGcmVkIEJha2VyDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJyaWFuIENh cnBlbnRlcg0KPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1tdWx0aS1ob21l ZC1ob3N0LTA2LnR4dA0KPj4gCVBhZ2VzICAgICAgICAgICA6IDEzDQo+PiAJRGF0ZSAgICAgICAg ICAgIDogMjAxNi0wMi0yMg0KPj4NCj4+IEFic3RyYWN0Og0KPj4gICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgZXhwZWN0ZWQgSVB2NiBob3N0IGJlaGF2aW9yIGluIGEgbmV0d29yayB0aGF0DQo+ PiAgICBoYXMgbW9yZSB0aGFuIG9uZSBwcmVmaXgsIGVhY2ggYWxsb2NhdGVkIGJ5IGFuIHVwc3Ry ZWFtIG5ldHdvcmsgdGhhdA0KPj4gICAgaW1wbGVtZW50cyBCQ1AgMzggaW5ncmVzcyBmaWx0ZXJp bmcsIHdoZW4gdGhlIGhvc3QgaGFzIG11bHRpcGxlDQo+PiAgICByb3V0ZXJzIHRvIGNob29zZSBm cm9tLiAgSXQgYWxzbyBhcHBsaWVzIHRvIG90aGVyIHNjZW5hcmlvcyBzdWNoIGFzDQo+PiAgICB0 aGUgdXNhZ2Ugb2Ygc3RhdGVmdWwgZmlyZXdhbGxzIHRoYXQgZWZmZWN0aXZlbHkgYWN0IGFzIGFk ZHJlc3MtYmFzZWQNCj4+ICAgIGZpbHRlcnMuICBUaGlzIGhvc3QgYmVoYXZpb3IgbWF5IGludGVy YWN0IHdpdGggc291cmNlIGFkZHJlc3MNCj4+ICAgIHNlbGVjdGlvbiBpbiBhIGdpdmVuIGltcGxl bWVudGF0aW9uLCBidXQgbG9naWNhbGx5IGZvbGxvd3MgaXQuICBHaXZlbg0KPj4gICAgdGhhdCB0 aGUgbmV0d29yayBvciBob3N0IGlzLCBvciBhcHBlYXJzIHRvIGJlLCBtdWx0aWhvbWVkIHdpdGgN Cj4+ICAgIG11bHRpcGxlIHByb3ZpZGVyLWFsbG9jYXRlZCBhZGRyZXNzZXMsIHRoYXQgdGhlIGhv c3QgaGFzIGVsZWN0ZWQgdG8NCj4+ICAgIHVzZSBhIHNvdXJjZSBhZGRyZXNzIGluIGEgZ2l2ZW4g cHJlZml4LCBhbmQgdGhhdCBzb21lIGJ1dCBub3QgYWxsDQo+PiAgICBuZWlnaGJvcmluZyByb3V0 ZXJzIGFyZSBhZHZlcnRpc2luZyB0aGF0IHByZWZpeCBpbiB0aGVpciBSb3V0ZXINCj4+ICAgIEFk dmVydGlzZW1lbnQgUHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbnMsIHRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIHRvDQo+PiAgICB3aGljaCByb3V0ZXIgYSBob3N0IHNob3VsZCBwcmVzZW50IGl0cyB0 cmFuc21pc3Npb24uICBJdCB1cGRhdGVzIFJGQw0KPj4gICAgNDg2MS4NCj4+DQo+Pg0KPj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFj a2VyLmlldGYuDQo+PiBvcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRDZtYW4tMkRtdWx0aS0yRGhvbWVk LTJEaG9zdF8mZD1CUUlDQWcmYz1CRnBXUXcNCj4+IDggDQo+PiBic3VLcGwxU2dpWkg2NFEmcj1V VDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhmZzgNCj4+IG8g DQo+PiAzc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9UFVxamVTbjRwVU9y dFdWQnNOak5haWxzUmV3NV8NCj4+IFoNCj4+IHZ6RFMxU1RGdFRqRGcmZT0NCj4+DQo+PiBUaGVy ZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdf aA0KPj4gdCANCj4+IG1sX2RyYWZ0LTJEaWV0Zi0yRDZtYW4tMkRtdWx0aS0yRGhvbWVkLTJEaG9z dC0yRDA2JmQ9QlFJQ0FnJmM9QkZwV1F3OA0KPj4gYg0KPj4gc3VLcGwxU2dpWkg2NFEmcj1VVDNC azljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09bGhmZzhvDQo+PiAzIA0K Pj4gc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9bEdmTUdmV0M3R1Y2Vi1y ZXdNTGt1WGhtTXY4cUNHDQo+PiBCDQo+PiBISXhoQ3NGbWtPblkmZT0NCj4+DQo+PiBBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19y ZmMNCj4+IGQgDQo+PiBpZmYtM0Z1cmwyLTNEZHJhZnQtMkRpZXRmLTJENm1hbi0yRG11bHRpLTJE aG9tZWQtMkRob3N0LTJEMDYmZD1CUUlDQWcNCj4+ICYgDQo+PiBjPUJGcFdRdzhic3VLcGwxU2dp Wkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmsNCj4+IFkg DQo+PiAmbT1saGZnOG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJnM9VUZT OTdGYmpFUURCRS1ESkJaYUoNCj4+IEYNCj4+IDdKM3VtZG1uNjZQQTFaNHljOTV4alUmZT0NCj4+ DQo+Pg0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1mdHAtM0FfX2Z0cC5pZXRmLm9y Z19pbnRlcg0KPj4gbiANCj4+IGV0LTJEZHJhZnRzXyZkPUJRSUNBZyZjPUJGcFdRdzhic3VLcGwx U2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaA0KPj4gSSANCj4+IG9VV0I4WUxaVTIzMDI5 c01RR1Eya1kmbT1saGZnOG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJqMm9Rd3dxNTMwJg0K Pj4gcyA9REtEcHdicUt4WlJ5TVhxZ1NrbE54RS16UDFEWnRkSUFLbnJPOW5EQldpcyZlPQ0KPj4N Cj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gU3ViamVj dDogRGlnZXN0IEZvb3Rlcg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBpcHY2IG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpDQo+PiBsDQo+PiBtYW5fbGlzdGluZm9faXB2NiZkPUJRSUNBZyZjPUJG cFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYNCj4+IDMgDQo+PiBpQ3JoSW9V V0I4WUxaVTIzMDI5c01RR1Eya1kmbT1saGZnOG8zc1FfVTBxV2lBY0lPNjdfT1k2bHR2VmRQeVJq Mm9Rd3cNCj4+IHEgNTMwJnM9djFBNkFWcWIxV3hZSnJvMV9MLTV5X2I2Ykh4bldaak1acl9qRTU1 WDlGbyZlPQ0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+ PiBFbmQgb2YgaXB2NiBEaWdlc3QsIFZvbCAxNDIsIElzc3VlIDM1DQo+PiAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQo+Pg0KDQo= From nobody Tue Apr 12 19:31:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3712DB85 for ; Tue, 12 Apr 2016 19:31:37 -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 bVEtveLPO1lQ for ; Tue, 12 Apr 2016 19:31:34 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 3816A12DB69 for ; Tue, 12 Apr 2016 19:31:34 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id fs9so5734092pac.2 for ; Tue, 12 Apr 2016 19:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pSXfdxOP2hgGOAwuvH/W51G4KX51z7FMv2Cqd7rtKQ0=; b=l8e93fAHJKggUHcd6hBKNPaBMcATIoWzQzVB0Tz/HcJe03MPCEA2imUDyeDQMApo++ GU+EIcK3n3dkj2ikIGJd2GNJ5y5vDS4J4ABCf5blYvUN6UB1Owgp18EGt5mKfbTu4SC7 bBg+no+uBP807tt8zh5TveLwxXxwzvyWTp7jj46WdvwyeI1EkbHiSwHekYHyTg0AEN8S Mtk/3hSbb8OAO+YzP9Bcvi90xr0ilODnLFPg+kmkdhJwSbgQMDWNcrtG24Q20X8FuY/m OJRHzmt/tFrfOWesiEJXB4RUMUXGRpwhnKyJRngZX08QbQhdedBTI9YciL9bKg0bP4hx tT6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=pSXfdxOP2hgGOAwuvH/W51G4KX51z7FMv2Cqd7rtKQ0=; b=BhN7Cge7l9KKR4wU4AyALcG3z05TsBgvXtPAKD220xAWwY7JRFw9rofiqFB8qoc53p DgO/OsvNesOFY8qL3zJ7e9fonrLvVPcNCmej/9OFr9JomeyhBnRhGnRe0BSMQTBGFqND LB4Kc4IKVrd0BWHm23a4AMy0NjgnrJ3PnzhSRQZDURoYvX8GbNT67Aw0x/uGJLtpdzKz SEXKgnglJNrcEm0rxVtN3bGFR6Y37tYLcMJpAuDepwbTAinhV8PbID/tQnLbx+TEA8ji A3evf+nhkhz3QH+1eVPRQJ7/30tDcGucVkQ6xs7UR3o6bnWUZCcYFIuiqKgJM1fr6Uxd 675g== X-Gm-Message-State: AOPr4FXvs3PFZU2Y2ki05NH1tcgfnCCJzgUrYUZvY3/xGaq1pektTj7UBmK1ZvPszEfBJA== X-Received: by 10.66.40.236 with SMTP id a12mr9464820pal.58.1460514693733; Tue, 12 Apr 2016 19:31:33 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id p189sm26106665pfb.51.2016.04.12.19.31.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 19:31:32 -0700 (PDT) Subject: Re: draft-ietf-6man-multi-homed-host - Routing packets from hosts in a multi-prefix network To: "Mudric, Dusan (Dusan)" , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <9142206A0C5BF24CB22755C8EC422E457A8C9C42@AZ-US1EXMB03.global.avaya.com> <5705BCBA.1030007@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8CBCC6@AZ-US1EXMB03.global.avaya.com> <570C053C.7050703@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8D37A3@AZ-US1EXMB03.global.avaya.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570DAF86.5060400@gmail.com> Date: Wed, 13 Apr 2016 14:31:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457A8D37A3@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 02:31:37 -0000 Regards Brian Carpenter http://orcid.org/0000-0001-7924-6182 On 13/04/2016 03:01, Mudric, Dusan (Dusan) wrote: > Hi Brian, >=20 > Thanks for updating the draft regarding A=3DL=3D0 prefix.=20 >=20 >>> - How is A=3DL=3D0 prefix going to help the first hop router selectio= n? >> I think that is clear already - i.e., exactly the same as when A=3D1 o= r L=3D1. >=20 > How is it going to work?=20 Isn't that the subject of Section 3 in the draft? I'm not understanding where you see an ambiguity. As far as Section 3 goes, the case A=3DL=3D0 isn't special; it's just another PIO. > SASA will select the source address based on the prefix that was advert= ised by the first hop router to the given destination. Send algorithm sel= ect the first hop router for off-link destinations using a default router= list.=20 >=20 > Q1: How is the SASA address prefix going to be compared against A=3DL=3D= 0 prefix during the default router selection? Nothing special - just do what Section 3 says. > Q2: It makes sense to store the A=3DL=3D1 prefixes for each default rou= ter entry and compare them against SASA address prefix during the first h= ope router selection. A=3DL=3D1 prefixes are used to create device addres= ses. However, A=3DL=3D0 prefixes are not used to create device addresses = (you agreed on that). It does not make sense, to me, to compare A=3DL=3D0= prefixes against SASA address prefix. There will never be a match becaus= e none of SLAAC addresses will ever be created using A=3DL=3D0 prefixes. = I think A=3DL=3D0 prefixes are not needed and should not be stored in def= ault router entries. The whole point is they are a signal saying "I know how to source-route f= rom that prefix." That information needs to be stored. They are not used for SLAAC and they are not asserted to be on-link, so those two bits of infor= mation are not stored. > Q3: I did not notice you mentioned how A=3DL=3D1 prefixes are stored du= ring RA and used during the default router selection. This should be clar= ified, if is not already. I think that is out of scope; we aren't changing what is already done. Brian >=20 > Regards, > Dusan >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Monday, April 11, 2016 4:13 PM > To: Mudric, Dusan (Dusan); =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > Cc: ipv6@ietf.org > Subject: Re: draft-ietf-6man-multi-homed-host - Routing packets from ho= sts in a multi-prefix network >=20 > On 12/04/2016 04:28, Mudric, Dusan (Dusan) wrote: >> Hi Brian, >> >> Should the draft be more specific explaining where the A=3DL=3D0 prefi= x should be stored and how the prefix should be used? Like: >> - Should A=3DL=3D0 prefix be added to the prefix list and use for on-l= ink=20 >> determination? (you said no) >> - Should A=3DL=3D0 prefix used for SLAAC? (you said no) >=20 > Yes, it would be reasonable to add a sentence clarifying these two poin= ts, which are more or less the definitions of A=3D0 and L=3D0. >=20 >> - How is A=3DL=3D0 prefix going to help the first hop router selection= ? >=20 > I think that is clear already - i.e., exactly the same as when A=3D1 or= L=3D1. >=20 > Brian >=20 >> >> Thanks, >> Dusan. >> >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Wednesday, April 06, 2016 9:50 PM >> To: Mudric, Dusan (Dusan); =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 >> Cc: ipv6@ietf.org >> Subject: draft-ietf-6man-multi-homed-host - Routing packets from hosts= =20 >> in a multi-prefix network >> >> Dusan, >> >> As far as I know we are only changing the A=3DL=3D0 case. If A=3D0, th= e prefix is not used for SLAAC at all, and if L=3D0 the prefix should not= be added to the on-link prefix list. >> >> To be clear, L=3D0 doesn't mean the prefix is off-link. It just means = "I'm not telling you it's on-link". >> >> So previously a host could simply ignore the PIO with A=3DL=3D0. But n= ow it will be a useful next-hop router signal to the host, if addresses i= n that prefix have been assigned in another way, typically by DHCPv6. >> >> Does that make sense? >> >> Brian >> >> On 07/04/2016 07:40, Mudric, Dusan (Dusan) wrote: >>> Hi Brian, >>> >>> "Routing packets from hosts in a multi-prefix network" says: >>> A router >>> that advertises a prefix indicates that it is able to appropriatel= y >>> route packets with source addresses within that prefix, regardless= of >>> the setting of the L and A flags in the PIO. >>> >>> a host SHOULD NOT ignore a PIO simply because both L and >>> A flags are cleared; a router SHOULD be able to send such a PIO. >>> >>> A host SHOULD select >>> default routers for each prefix it is assigned an address in. >>> >>> The prefix list is used to find out if the destination address is on-= link.=20 >>> >>> If the router can route the packets from a host with the source addre= ss using L=3D0 prefix, theoretically off-link prefix can be used for SLAA= C address. The problem is that L=3D0 prefix might be used on other links = and if the host creates SLAAC address using L=3D0 prefix, the host will n= ot be able to detect if the address is in use (DAD does not work between = different router links). For that reason looks like L=3D0 prefix should n= ot be used for SLAAC. If L=3D0 prefix is not use for SLAAC, there will be= no source address with L=3D0 prefix and L=3D0 prefixes will not help hos= t to find the first hop router. Consequently, hosts can ignore L=3D0 pref= ixes. >>> >>> Am I missing something about L=3D0 prefixes? >>> >>> Thanks, >>> Dusan. >>> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of=20 >>> ipv6-request@ietf.org >>> Sent: Monday, February 22, 2016 3:00 PM >>> To: ipv6@ietf.org >>> Subject: ipv6 Digest, Vol 142, Issue 35 >>> >>> Send ipv6 mailing list submissions to >>> ipv6@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> =09 >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ai >>> l >>> man_listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL= eaJxhf >>> 3=20 >>> iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQ= ww >>> q 530&s=3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D >>> or, via email, send a message with subject or body 'help' to >>> ipv6-request@ietf.org >>> >>> You can reach the person managing the list at >>> ipv6-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific t= han "Re: Contents of ipv6 digest..." >>> >>> >>> Today's Topics: >>> >>> 1. I-D Action: draft-ietf-6man-multi-homed-host-05.txt >>> (internet-drafts@ietf.org) >>> 2. I-D Action: draft-ietf-6man-multi-homed-host-06.txt >>> (internet-drafts@ietf.org) >>> >>> >>> ---------------------------------------------------------------------= >>> - >>> >>> Message: 1 >>> Date: Mon, 22 Feb 2016 10:32:52 -0800 >>> From: internet-drafts@ietf.org >>> To: >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-multi-homed-host-05.txt >>> Message-ID: <20160222183252.21102.35271.idtracker@ietfa.amsl.com> >>> Content-Type: text/plain; charset=3D"utf-8" >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> This draft is a work item of the IPv6 Maintenance of the IETF. >>> >>> Title : Routing packets from hosts in a multi-prefi= x network >>> Authors : Fred Baker >>> Brian Carpenter >>> Filename : draft-ietf-6man-multi-homed-host-05.txt >>> Pages : 13 >>> Date : 2016-02-22 >>> >>> Abstract: >>> This document describes expected IPv6 host behavior in a network t= hat >>> has more than one prefix, each allocated by an upstream network th= at >>> implements BCP 38 ingress filtering, when the host has multiple >>> routers to choose from. It also applies to other scenarios such a= s >>> the usage of stateful firewalls that effectively act as address-ba= sed >>> filters. This host behavior may interact with source address >>> selection in a given implementation, but logically follows it. Gi= ven >>> that the network or host is, or appears to be, multihomed with >>> multiple provider-allocated addresses, that the host has elected t= o >>> use a source address in a given prefix, and that some but not all >>> neighboring routers are advertising that prefix in their Router >>> Advertisement Prefix Information Options, this document specifies = to >>> which router a host should present its transmission. It updates R= FC >>> 4861. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf. >>> org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBF= pWQw >>> 8=20 >>> bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dl= hfg8 >>> o=20 >>> 3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew= 5_ >>> Z >>> vzDS1STFtTjDg&e=3D >>> >>> There's also a htmlized version available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _h >>> t=20 >>> ml_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQICAg&c=3DBFp= WQw8 >>> b >>> suKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o >>> 3=20 >>> sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DWqnr6PzhAWzCUOMlH0v2MPK87Kyh= pI >>> f >>> l1sDF96UNhP4&e=3D >>> >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_r= fc >>> d=20 >>> iff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D05&d=3DBQIC= Ag >>> &=20 >>> c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQ= GQ2k >>> Y=20 >>> &m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DvPYONcimyGIvGJFl= 1Th6 >>> R >>> V-kSJv79qPXaULdoyeOHEo&e=3D >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.o= rg. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_int= er >>> n=20 >>> et-2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxh= f3iCrh >>> I=20 >>> oUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq53= 0& >>> s =3DDKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Mon, 22 Feb 2016 10:55:30 -0800 >>> From: internet-drafts@ietf.org >>> To: >>> Cc: ipv6@ietf.org >>> Subject: I-D Action: draft-ietf-6man-multi-homed-host-06.txt >>> Message-ID: <20160222185530.5662.71093.idtracker@ietfa.amsl.com> >>> Content-Type: text/plain; charset=3D"utf-8" >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> This draft is a work item of the IPv6 Maintenance of the IETF. >>> >>> Title : Routing packets from hosts in a multi-prefi= x network >>> Authors : Fred Baker >>> Brian Carpenter >>> Filename : draft-ietf-6man-multi-homed-host-06.txt >>> Pages : 13 >>> Date : 2016-02-22 >>> >>> Abstract: >>> This document describes expected IPv6 host behavior in a network t= hat >>> has more than one prefix, each allocated by an upstream network th= at >>> implements BCP 38 ingress filtering, when the host has multiple >>> routers to choose from. It also applies to other scenarios such a= s >>> the usage of stateful firewalls that effectively act as address-ba= sed >>> filters. This host behavior may interact with source address >>> selection in a given implementation, but logically follows it. Gi= ven >>> that the network or host is, or appears to be, multihomed with >>> multiple provider-allocated addresses, that the host has elected t= o >>> use a source address in a given prefix, and that some but not all >>> neighboring routers are advertising that prefix in their Router >>> Advertisement Prefix Information Options, this document specifies = to >>> which router a host should present its transmission. It updates R= FC >>> 4861. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf. >>> org_doc_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost_&d=3DBQICAg&c=3DBF= pWQw >>> 8=20 >>> bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dl= hfg8 >>> o=20 >>> 3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DPUqjeSn4pUOrtWVBsNjNailsRew= 5_ >>> Z >>> vzDS1STFtTjDg&e=3D >>> >>> There's also a htmlized version available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _h >>> t=20 >>> ml_draft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQICAg&c=3DBFp= WQw8 >>> b >>> suKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlh= fg8o >>> 3=20 >>> sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DlGfMGfWC7GV6V-rewMLkuXhmMv8q= CG >>> B >>> HIxhCsFmkOnY&e=3D >>> >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_r= fc >>> d=20 >>> iff-3Furl2-3Ddraft-2Dietf-2D6man-2Dmulti-2Dhomed-2Dhost-2D06&d=3DBQIC= Ag >>> &=20 >>> c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQ= GQ2k >>> Y=20 >>> &m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq530&s=3DUFS97FbjEQDBE-DJ= BZaJ >>> F >>> 7J3umdmn66PA1Z4yc95xjU&e=3D >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission until the htmlized version and diff are available at tools.ietf.o= rg. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_int= er >>> n=20 >>> et-2Ddrafts_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxh= f3iCrh >>> I=20 >>> oUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQwwq53= 0& >>> s =3DDKDpwbqKxZRyMXqgSklNxE-zP1DZtdIAKnrO9nDBWis&e=3D >>> >>> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> ipv6 mailing list >>> ipv6@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ai >>> l >>> man_listinfo_ipv6&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbL= eaJxhf >>> 3=20 >>> iCrhIoUWB8YLZU23029sMQGQ2kY&m=3Dlhfg8o3sQ_U0qWiAcIO67_OY6ltvVdPyRj2oQ= ww >>> q 530&s=3Dv1A6AVqb1WxYJro1_L-5y_b6bHxnWZjMZr_jE55X9Fo&e=3D >>> >>> >>> ------------------------------ >>> >>> End of ipv6 Digest, Vol 142, Issue 35 >>> ************************************* >>> >=20 From nobody Wed Apr 13 03:09:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD512D16F for ; Wed, 13 Apr 2016 03:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.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 IclUe6AUPidS for ; Wed, 13 Apr 2016 03:09: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 A964A12B05A for ; Wed, 13 Apr 2016 03:09:24 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0182.outbound.protection.outlook.com [213.199.154.182]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-37-g5BguZurSsy-CDXT-7EwvQ-1; Wed, 13 Apr 2016 11:09:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0e+vxaHh0VkdonttS3I5QKocchN1JEeOxAXcb5jsI/c=; b=HqOr1QipSkV/bowVkkoeTultTY8O154+3AG3SvAWYG4mfNTYnTAqJYOj4d9wEHGD2GyKadd2FgTkhBFUq5lEjmgdwWTsBVSMpWYuVmBGVdpEYJbHrX+TkFDpT4rTwuZS8p77UJNTB9dplRMCjwLFS/I+crsmUkkrrZadrxuNRwE= Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB463.eurprd07.prod.outlook.com (10.141.231.151) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 10:09:15 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0466.018; Wed, 13 Apr 2016 10:09:15 +0000 From: Tim Chown To: Fernando Gont Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRlWyIkI7jByjAYEGHSJT73UxYMw== Date: Wed, 13 Apr 2016 10:09:15 +0000 Message-ID: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> <570BE79B.8040300@si6networks.com> In-Reply-To: <570BE79B.8040300@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a93e:5914:9e35:ffe3] x-ms-office365-filtering-correlation-id: 44a54838-7146-4dcf-e515-08d36383ab73 x-microsoft-exchange-diagnostics: 1; DBXPR07MB463; 5:qkn5SfQXbVk/MoNETclRkr2wdmtAIgbJPu59/AE6TxyajJSFTlAzBOC0iCm18O6h30kaSmzOl4mriG+RLycCEAq2zJewnuuOSI7rN4lgakAgqowPWJHAGN5baUxVVsP8OTsb8cRk2d74Ls1hgrYXvlfVAw9T9yWm7DG3yxIM0pUUspWiUL163qpUr3TU/R8T; 24:OpHW+AMzLA/OKV/TLA4cBc0Acb+FdAYbIZsVfWQ/HZnRbNJ1w/aTkTP0CXT+S1qPfrrsLuhGFOtGUhkksWg4wIQzgLKrVJJW4Ux4HlGcB2w=; 7:pqe0b/z67akZyu1dV7sPxTEV6P3v3GisPveBAOb4IdUIiw6aAjoVYIH23KObb+H+Z9SxPDpb1IGHzzDapnQ/w+7cNTrrJu8aNyjSGM8udeSbAcYfRIqr6BH4lhWt/a45kPufN9qPwHCCMdvrREfHmdzDW7f6lmZxSYNztAypkk/hZjkSvFFWvoK993ZGAZ46R+xzmcfNJmi/ethVa7An33Wym6NmfcC6i7wfTEoGAic=; 20:o+5eF5lrs+4G81S01hTY9vavS+IoLb+UQGNlcqOaOMT8l2akmZVk8R9zvRv0P0jQpYFKBZOQM9SI34nTfkgQ+RST2mBjt3c2N2yzQK4JScaE4xSb8JyOuWDnwx4c0hVwu0NqcL4+sJ+PLPJoPJo8p/EMwRBwKqNtUJXo+LHnXg4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB463; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB463; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB463; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(252514010)(1220700001)(575784001)(81166005)(15975445007)(87936001)(3660700001)(106116001)(2906002)(77096005)(6116002)(3280700002)(5008740100001)(5004730100002)(2900100001)(33656002)(110136002)(74482002)(561944003)(189998001)(102836003)(11100500001)(586003)(36756003)(2950100001)(83716003)(5002640100001)(50986999)(10400500002)(1096002)(4326007)(92566002)(76176999)(122556002)(86362001)(57306001)(50226001)(19580405001)(93886004)(19580395003)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB463; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 10:09:15.3986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB463 X-MC-Unique: g5BguZurSsy-CDXT-7EwvQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Bob Hinden , 6man WG , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:09:28 -0000 SGksDQoNCj4gT24gMTEgQXByIDIwMTYsIGF0IDE5OjA2LCBGZXJuYW5kbyBHb250IDxmZ29udEBz aTZuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gT24gMDQvMTEvMjAxNiAwMjo0NCBQTSwg56We 5piO6YGU5ZOJIHdyb3RlOg0KPj4gQXQgRnJpLCA4IEFwciAyMDE2IDE4OjIzOjQ3IC0wMzAwLA0K Pj4gb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+PiANCj4+PiBXaGlsZSBhIGRpc2N1c3Np b24gb24gaGVhZGVyIGluc2VydGlvbiBtYXkgYmUgbmVjZXNzYXJ5LCBpdCBpcyBub3QNCj4+PiBp biBjb250ZXh0IGZvciB0YWtpbmcgUkZDMjQ2MCB0byBJUy4gSWYgYSBwcm9wb3NhbCBpcyBtYWRl LCB0aGVuIHRoZQ0KPj4+IHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGRpc2N1c3MgdGhhdCBpbiB0aGUg Y29udGV4dCBvZiB0aGF0IHByb3Bvc2FsLg0KPj4gDQo+PiBJJ20gbm90IHN1cmUgd2hhdCB0aGlz ICJwcm9wb3NhbCIgbWVhbnMuLi5pcyBpdCB0aGUgcHJvcG9zZWQgdGV4dCBmb3INCj4+IHJmYzI0 NjBiaXMgZnJvbSBCb2IgbGlrZSB0aGlzIG9uZT8NCj4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvaXB2Ni9NVE9rcmpjc2NvZFMwQzVGTG1abV9MSmFwR1kNCj4+IA0KPj4g SSB0aG91Z2h0IGl0IHdhcyBhIGNsYXJpZmljYXRpb24gb2YgdGhlIG9yaWdpbmFsIGludGVudCBv ZiB0aGUgUkZDMjQ2MA0KPj4gYXV0aG9ycyAoYW5kIHRoZSB1bmRlcnN0YW5kaW5nIG9mIG1vc3Qg b2YgdGhlbiBhbmQgbm93IHdnIG1lbWJlcnMpLA0KPj4gcmF0aGVyIHRoYW4gc29tZSBuZXcgcHJv cG9zYWwuICBBbmQgc2luY2UgaXQncyBhcHBhcmVudCB0aGF0IHRoZQ0KPj4gd29yZGluZyBpbiBS RkMyNDYwIHdhc24ndCByZWFsbHkgYXMgY2xlYXIgYXMgd2Ugb3JpZ2luYWxseSBhcyB3ZQ0KPj4g YWN0dWFsbHkgc2F3IHRoZSAibWlzaW50ZXJwcmV0YXRpb24iIGluIFJGQzQ3ODIsIEkgdGhvdWdo dCBpdCBtYWRlDQo+PiB2ZXJ5IHNlbnNlIHRvIGNsYXJpZnkgdGhhdCBpbiByZmMyNDYwYmlzICh0 byBhZHZhbmNlIGl0IHRvIElTKS4NCj4+IA0KPj4+IFRoZSBSRkMyNDYwIHRleHQgaGFzIG5vdCBj YXVzZWQgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMuIFdoaWNoIGlzDQo+Pj4gd2h5IEknbSBub3Qg Y29udmluY2VkIHRoaXMgY2hhbmdlIHdhcyByZXF1aXJlZC4NCj4+IA0KPj4gVGhpcyBsb2dpYyBk b2Vzbid0IG1ha2Ugc2Vuc2UgdG8gbWUuICBUaGUgZmFjdCB0aGF0IHdlIGhhZCBSRkM0NzgyDQo+ PiBzdWdnZXN0cyBpdCdzIHF1aXRlIHBvc3NpYmxlIHRoYXQgd2UgaGF2ZSBvdGhlciBzdGFuZGFy ZCBwdWJsaWNhdGlvbnMNCj4+IGluIGZ1dHVyZSB0aGF0IG1pc3VudGVycHJldHMgdGhlIG9yaWdp bmFsIGludGVudCBhbmQgcmVhbGx5IGNhdXNlDQo+PiBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4g IEkgZG9uJ3Qga25vdyBpZiB0aGUgdmlvbGF0aW9uIG9mIFJGQzI0NjAgYnkNCj4+IFJGQzQ3ODIg aXMgY3VycmVudGx5IGltcGxlbWVudGVkIGFuZCBhY3R1YWxseSBjYXVzZXMgYW4NCj4+IGludGVy b3BlcmFiaWxpdHkgaXNzdWUsIGJ1dCBldmVuIGlmIG5vdCwgSSBkb24ndCBzZWUgYW55IHJlYXNv biBmb3INCj4+IG5vdCBtYWtpbmcgdGhlIGNsYXJpZmljYXRpb24gYmVjYXVzZSBvZiB0aGF0Lg0K Pj4gDQo+PiBOb3csIGlmIHNvbWVvbmUgd2hvIGhhcyBhIGNvbmZsaWN0IG9mIGludGVyZXN0IGJl dHdlZW4gdGhlIG9yaWdpbmFsDQo+PiBSRkMyNDYwIGludGVudCBhbmQgc29tZSBwYXJ0aWN1bGFy IG5ldyBwcm90b2NvbCB3YW50cyB0byBjaGFsbGVuZ2UNCj4+IHRoZSBvcmlnaW5hbCBpbnRlbnQs IHdlIG1pZ2h0IGJlIG9wZW4gdG8gY29uc2lkZXIgaXQsIGRlcGVuZGluZw0KPj4gb24gaXRzIHRl Y2huaWNhbCBkZXRhaWxzLiAgQnV0IEknZCBzYXkgInRoZSB3b3JraW5nIGdyb3VwIHNob3VsZA0K Pj4gZGlzY3VzcyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRoYXQgcHJvcG9zYWwiIG91dHNpZGUg b2Ygd2hldGhlciB0bw0KPj4gbWFrZSBhIGhlbHBmdWwgY2xhcmlmaWNhdGlvbiBpbiByZmMyNDYw YmlzLiAgSWYgYW5kIHdoZW4gd2UgYWdyZWUgb24NCj4+IG1ha2luZyBzdWNoIGEgY2hhbmdlLCB3 ZSdsbCBwdWJsaXNoIGEgbmV3IHN0YW5kYXJkIGRvY3VtZW50IHRoYXQNCj4+IHVwZGF0ZXMgUkZD MjQ2MChiaXMpLg0KPj4gDQo+Pj4gVGhlIGRlZmF1bHQgYWN0aW9uLCB1bmxlc3Mgd2UgY2FuIGNv bWUgdG8gYSBkaWZmZXJlbnQgYWdyZWVtZW50LCBpcw0KPj4+IHRvIGxlYXZlIHRoZSBSRkMyNDYw IHRleHQgdW5jaGFuZ2VkIGluIFJGQzI0NjBiaXMuDQo+PiANCj4+IFNvLCBmb3Igb25lLCBJIGRp c2FncmVlIHdpdGggdGhpcyBhbmQgSSBzdWdnZXN0IHdlIHNob3VsZCBjb21lIHRvIGENCj4+ICJk aWZmZXJlbnQgYWdyZWVtZW50IiAoPSBtYWtpbmcgdGhpcyBjbGFyaWZpY2F0aW9uIGluIHJmYzI0 NjBiaXMpLg0KPiANCj4gKzENCj4gDQo+IChjb3VsZG4ndCB3cml0ZSBpdCBkb3duIGJldHRlciB0 aGFuIHRoaXMpDQoNCkkgYWdyZWUuDQoNCkJ1dCBJIHdvdWxkIGFsc28gYWRkIHRoYXQgd2hldGhl ciB3ZSBhZGQgdGhlIHRleHQgb3Igbm90LCB0aGUgKGxhY2sgb2YpIG1hdHVyaXR5IGluIEV4dGVu c2lvbiBIZWFkZXIgZXhwZXJpZW5jZSBtZWFucyB3ZSBzaG91bGQgbm90IGFkdmFuY2UgMjQ2MC1i aXMgdG8gSVMgeWV0LiBUaGF0IHBvaW50IHdhcyBhbHNvIG1hZGUgYXQgdGhlIG1pYyBieSBzb21l b25lIGluIGxhc3Qgd2Vla+KAmXMgbWVldGluZy4NCg0KVGltDQoNCj4gDQo+IC0tIA0KPiBGZXJu YW5kbyBHb250DQo+IFNJNiBOZXR3b3Jrcw0KPiBlLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNv bQ0KPiBQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFFMjUg MEQ1NSAxRDRFIDc0OTINCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Wed Apr 13 04:18:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA07A12DA4A for ; Wed, 13 Apr 2016 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.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 EXlDrevhiGYI for ; Wed, 13 Apr 2016 04:18:37 -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 02D4212DA25 for ; Wed, 13 Apr 2016 04:18:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0010.outbound.protection.outlook.com [213.199.154.10]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-14-g5VLurNmR2CtKWyMbu2FoA-1; Wed, 13 Apr 2016 12:18:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MT2ydvn3qnxIY2wL/uktujSiz1CAt95uyB1PVjVUbE0=; b=ZENRZHvfPBlZXaZhv0svlXN4bvm60rGgAiNUI9TD3kZy8IJwuR3voOR1dTHwAkF+aLVxUmMXmQizX618EhqSGw0Gv47+CoevyHeqh0ZgMGcyTpcoE/GeFn4/0M2P/MdgBwQMluy6RD+kzheljEh+9YtEc1OkY4hE/1enIulCLqk= Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 11:18:24 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0466.018; Wed, 13 Apr 2016 11:18:24 +0000 From: Tim Chown To: Mark Smith Subject: Re: [v6ops] DNS AAAA for free Thread-Topic: [v6ops] DNS AAAA for free Thread-Index: AQHRlXYxcVsCMD2MzkKuvkhxRo9AJg== Date: Wed, 13 Apr 2016 11:18:24 +0000 Message-ID: <90CC41CF-9F3D-44DB-8A23-AFB34321748E@jisc.ac.uk> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> 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.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a93e:5914:9e35:ffe3] x-ms-office365-filtering-correlation-id: 6c3af208-809d-4f63-c3ec-08d3638d546c x-microsoft-exchange-diagnostics: 1; DBXPR07MB462; 5:wCXbP+QoJx16jcoCxQIHPHy2ZWBNs0gpURYlfE/kM/JJ6mC92Nr7XlYmqpVHKavWx5lHwgtSXeXgZ7mm3caeS9r1KU+52kRFsxLNQ/MKmxW5IaMK+Helxhc5ttMQ3ZRsbMiyeKu8NBucMPFyP7x2UkkYzrru+wDZ4gyVyymSyL4rp4D5rFqIiC8Tq912NjJ1; 24:sRbY82J7C0HnXDJ9pFmSQMaS/L9lWjsltV+khG4YvuuK2M3Hov7QvDdLtvMaJYQxVe4jvE9tQvt5Sr0jLym228RcBiVoeH2DSeVlNF23NXs=; 7:NXMN3f0t/ZOp7DqXpZ0hddnOHCfuqVd9CpdFwLSsywdSZWJVlswSaSAzUMghjgP1irIoNdF49NQ72FatxHCUzZT01n1HamTYh0mTQQWgfjWYOMiJTvG7bfr12RYA0unK/L6xB/EmM7JjIiNENwBInr6Jt6fxj++mmuVeHKIwzoFZUJ8v6Pxz+f5zbLsUSk/vRtHV3/7+FWA3OcD8GYXVfyar159Z4EA9k29ICptMzsU=; 20:Se+VsswdyLr2qGMEffw/RWyerve45cbdKf1+DxnZOU7WnfDcgrMzIzMyxOKxONTvYd5FYTiFBXzpJoKpAg+OEorXZpn2xmmlNEMq7XNcLBbtPIvVxqNSOAVchX71k5gM8I157AI/g0B1lLFdeLRfL/FN9j4hSmz19k5OYBg/gNc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB462; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB462; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(3660700001)(82746002)(3280700002)(92566002)(561944003)(5008740100001)(33656002)(122556002)(2906002)(15975445007)(4326007)(74482002)(77096005)(81166005)(50226001)(2950100001)(19580405001)(86362001)(10400500002)(57306001)(110136002)(5004730100002)(16236675004)(189998001)(19580395003)(6116002)(586003)(106116001)(1220700001)(36756003)(50986999)(87936001)(1096002)(76176999)(19617315012)(83716003)(5002640100001)(102836003)(11100500001)(3826002)(104396002)(217873001)(4533004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB462; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 11:18:24.6387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB462 X-MC-Unique: g5VLurNmR2CtKWyMbu2FoA-1 Content-Type: multipart/alternative; boundary="_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_" Archived-At: Cc: 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:18:39 -0000 --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gOSBBcHIgMjAxNiwgYXQgMTQ6MTEsIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5j b208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gOSBBcHIgMjAx NiA4OjU1IFBNLCAiU2FuZGVyIFN0ZWZmYW5uIiA8c2FuZGVyQHN0ZWZmYW5uLm5sPG1haWx0bzpz YW5kZXJAc3RlZmZhbm4ubmw+PiB3cm90ZToNCj4NCj4gSGksDQo+DQo+ID4gT24gMDggQXByIDIw MTYsIGF0IDEzOjI3LCBvdHJvYW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVl cy5vcmc+IHdyb3RlOg0KPiA+DQo+ID4gSGVyZSBpcyBhbiBpbnRlcmVzdGluZyBkcmFmdCBiZWlu ZyBwcmVzZW50ZWQgaW4gZG5zb3AgdG9kYXkuDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdmF2cnVzYS1kbnNvcC1hYWFhLWZvci1mcmVlLz9pbmNsdWRlX3RleHQ9 MQ0KPiA+DQo+ID4gVGhlIHByb3Bvc2FsIGlzIHRvIGFsbG93IEFBQUEgcmVjb3JkcyBpbiByZXNw b25zZSB0byBBIHF1ZXJpZXMuDQo+DQo+IE9uZSBxdWVzdGlvbjogaWYgY2xpZW50cyBzZW5kIHJl cXVlc3RzIGZvciBib3RoIEEgYW5kIEFBQUEgcmVjb3JkcyBzaW11bHRhbmVvdXNseSwgaG93IHdp bGwgaW5jbHVkaW5nIHRoZSBBQUFBIGFuc3dlciBpbiB0aGUgQSByZXF1ZXN0IGhlbHA/IFRoZSBj bGllbnQgd2lsbCBqdXN0IGdldCB0aGUgQUFBQSBhbnN3ZXIgdHdpY2U6IG9uY2Ugb24gdGhlIEEg cmVxdWVzdCBhbmQgb25jZSBvbiB0aGUgQUFBQSByZXF1ZXN0LiBJZiBsb29rdXBzIHdlcmUgc2Vy aWFsaXNlZCBhbmQgdGhlIEEgcmVxdWVzdC9yZXNwb25zZSB3YXMgY29tcGxldGVkIGJlZm9yZSBz dGFydGluZyB0aGUgQUFBQSByZXF1ZXN0IGl0IHdvdWxkIG1ha2UgdGhlIHNlY29uZCByZXF1ZXN0 IHVubmVjZXNzYXJ5LCBidXQgdGhhdCdzIG5vdCB3aGF0IEkgc2VlIGluIHByYWN0aWNlLi4uDQo+ DQo+IEl0IGxvb2tzIGxpa2UgZ29vZCBpbnRlbnRpb25zLCBJJ20ganVzdCB0cnlpbmcgdG8gZmln dXJlIG91dCBob3cgdGhpcyB3b3VsZCB3b3JrIGluIHByYWN0aWNlIDopDQoNCkhhdmluZyBicmll Zmx5IGxvb2tlZCBhdCBpdCwgaXQgc2VlbXMgdGhlcmUgaXMgYW4gZWZmaWNpZW5jeSBiZW5lZml0 LiBIb3dldmVyLCBhbnN3ZXJpbmcgYW4gQSBxdWVyeSB3aXRoIGJvdGggYW4gQSBhbmQgQUFBQSBy ZXNwb25zZSBtaWdodCBpbmNlbnRpdmlzZSBqdXN0IHNlbmRpbmcgQSBxdWVyaWVzLg0KDQpQZXJo YXBzIHRoZSBvcHBvc2l0ZSB3b3VsZCBiZSBiZXR0ZXIgLSBzZW5kaW5nIGFuIEFBQUEgcXVlcnkg d291bGQgcmVzdWx0IGluIGFuIEFBQUEgYW5kIEEgYW5zd2VyLiBUaGF0IG1pZ2h0IGNyZWF0ZSBh IHNtYWxsIGFuZCBzdWJ0bGUgaW5jZW50aXZlIHRvIHVzZSBhbmQgcHJlZmVyIElQdjYsIHdpdGgg SGFwcHkgRXllYmFsbHMgY292ZXJpbmcgb3ZlciBJUHY2IGZhaWx1cmVzLg0KDQpJIGFtIGF3YXJl IG9mIElTUHMgd2hvIGhhdmUgZGVwbG95ZWQgSVB2NiB0byB0aGVpciBjdXN0b21lcnMsIGtub3dp bmcgdGhleSBuZWVkZWQgdG8gc2NhbGUgdGhlaXIgRE5TIHByb3Zpc2lvbiwgYnV0IGhhdmUgc3Rp bGwgaGFkIHRvIGhvbGQgZnVydGhlciBkZXBsb3ltZW50IHVudGlsIHRoaXMgd2FzIGFjaGlldmVk LiAgSXTigJlzIG5vdCBhIGh1Z2UgaXNzdWUsIGJ1dCBhbnkgbWVhc3VyZXMgdG8gaGVscCBhZGRy ZXNzIHNjYWxhYmlsaXR5IGFzIHlvdSBhZGQgSVB2NiBhcmUgbGlrZWx5IHRvIGJlIHdlbGNvbWVk Lg0KDQpCdXQgYXMgb3RoZXJzIGhhdmUgcG9pbnRlZCBvdXQsIHRoZXJlIGFyZSBwcmFjdGljYWxp dGllcyB3aXRoIHRoZSBwcm9wb3NhbC4NCg0KVGltDQo= --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <8813FCC4FA39AD4F848FB29B14619D65@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA5IEFwciAyMDE2LCBhdCAxNDox MSwgTWFyayBTbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20i IGNsYXNzPSIiPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBkaXI9Imx0ciIgY2xhc3M9IiI+T24gOSBBcHIgMjAxNiA4OjU1IFBN LCAmcXVvdDtTYW5kZXIgU3RlZmZhbm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW5kZXJA c3RlZmZhbm4ubmwiIGNsYXNzPSIiPnNhbmRlckBzdGVmZmFubi5ubDwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEhpLDxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgT24gMDggQXByIDIwMTYsIGF0IDEzOjI3LCA8YSBo cmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIGNsYXNzPSIiPm90cm9hbkBlbXBsb3ll ZXMub3JnPC9hPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgSGVyZSBpcyBhbiBpbnRlcmVzdGluZyBkcmFmdCBiZWluZyBwcmVzZW50ZWQgaW4g ZG5zb3AgdG9kYXkuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZhdnJ1c2EtZG5zb3AtYWFhYS1mb3ItZnJlZS8/ aW5jbHVkZV90ZXh0PTEiIGNsYXNzPSIiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdmF2cnVzYS1kbnNvcC1hYWFhLWZvci1mcmVlLz9pbmNsdWRlX3RleHQ9MTwvYT48 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhlIHByb3Bv c2FsIGlzIHRvIGFsbG93IEFBQUEgcmVjb3JkcyBpbiByZXNwb25zZSB0byBBIHF1ZXJpZXMuPGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgT25lIHF1ZXN0aW9uOiBpZiBjbGll bnRzIHNlbmQgcmVxdWVzdHMgZm9yIGJvdGggQSBhbmQgQUFBQSByZWNvcmRzIHNpbXVsdGFuZW91 c2x5LCBob3cgd2lsbCBpbmNsdWRpbmcgdGhlIEFBQUEgYW5zd2VyIGluIHRoZSBBIHJlcXVlc3Qg aGVscD8gVGhlIGNsaWVudCB3aWxsIGp1c3QgZ2V0IHRoZSBBQUFBIGFuc3dlciB0d2ljZTogb25j ZSBvbiB0aGUgQSByZXF1ZXN0IGFuZCBvbmNlIG9uIHRoZSBBQUFBIHJlcXVlc3QuIElmIGxvb2t1 cHMgd2VyZQ0KIHNlcmlhbGlzZWQgYW5kIHRoZSBBIHJlcXVlc3QvcmVzcG9uc2Ugd2FzIGNvbXBs ZXRlZCBiZWZvcmUgc3RhcnRpbmcgdGhlIEFBQUEgcmVxdWVzdCBpdCB3b3VsZCBtYWtlIHRoZSBz ZWNvbmQgcmVxdWVzdCB1bm5lY2Vzc2FyeSwgYnV0IHRoYXQncyBub3Qgd2hhdCBJIHNlZSBpbiBw cmFjdGljZS4uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEl0IGxvb2tz IGxpa2UgZ29vZCBpbnRlbnRpb25zLCBJJ20ganVzdCB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cg dGhpcyB3b3VsZCB3b3JrIGluIHByYWN0aWNlIDopPGJyIGNsYXNzPSIiPg0KPC9wPg0KPHAgZGly PSJsdHIiIGNsYXNzPSIiPkhhdmluZyBicmllZmx5IGxvb2tlZCBhdCBpdCwgaXQgc2VlbXMgdGhl cmUgaXMgYW4gZWZmaWNpZW5jeSBiZW5lZml0LiBIb3dldmVyLCBhbnN3ZXJpbmcgYW4gQSBxdWVy eSB3aXRoIGJvdGggYW4gQSBhbmQgQUFBQSByZXNwb25zZSBtaWdodCBpbmNlbnRpdmlzZSBqdXN0 IHNlbmRpbmcgQSBxdWVyaWVzLjwvcD4NCjxwIGRpcj0ibHRyIiBjbGFzcz0iIj5QZXJoYXBzIHRo ZSBvcHBvc2l0ZSB3b3VsZCBiZSBiZXR0ZXIgLSBzZW5kaW5nIGFuIEFBQUEgcXVlcnkgd291bGQg cmVzdWx0IGluIGFuIEFBQUEgYW5kIEEgYW5zd2VyLiBUaGF0IG1pZ2h0IGNyZWF0ZSBhIHNtYWxs IGFuZCBzdWJ0bGUgaW5jZW50aXZlIHRvIHVzZSBhbmQgcHJlZmVyIElQdjYsIHdpdGggSGFwcHkg RXllYmFsbHMgY292ZXJpbmcgb3ZlciBJUHY2IGZhaWx1cmVzLjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5JIGFtIGF3YXJlIG9mIElTUHMgd2hvIGhhdmUgZGVwbG95 ZWQgSVB2NiB0byB0aGVpciBjdXN0b21lcnMsIGtub3dpbmcgdGhleSBuZWVkZWQgdG8gc2NhbGUg dGhlaXIgRE5TIHByb3Zpc2lvbiwgYnV0IGhhdmUgc3RpbGwgaGFkIHRvIGhvbGQgZnVydGhlciBk ZXBsb3ltZW50IHVudGlsIHRoaXMgd2FzIGFjaGlldmVkLiAmbmJzcDtJdOKAmXMgbm90IGEgaHVn ZSBpc3N1ZSwgYnV0IGFueSBtZWFzdXJlcyB0byBoZWxwIGFkZHJlc3Mgc2NhbGFiaWxpdHkNCiBh cyB5b3UgYWRkIElQdjYgYXJlIGxpa2VseSB0byBiZSB3ZWxjb21lZC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJ1dCBhcyBvdGhlcnMg aGF2ZSBwb2ludGVkIG91dCwgdGhlcmUgYXJlIHByYWN0aWNhbGl0aWVzIHdpdGggdGhlIHByb3Bv c2FsLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGltPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_-- From nobody Wed Apr 13 08:38:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB012D0C9 for ; Wed, 13 Apr 2016 08:38:48 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 zHnLaYHaYG_k for ; Wed, 13 Apr 2016 08:38:47 -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 0F58812D09C for ; Wed, 13 Apr 2016 08:38:47 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id s2so7289673iod.3 for ; Wed, 13 Apr 2016 08:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=kqb1IvTtGWRGJYVxGxfd0yxGprDBM0Xz6JZFZx5S6T8=; b=BmMepzfEtgp0aHcJKtiSzAqcS8+4gGwTZEASSp2RZbpr2h2OyejwVkfm+nbNI/lnpL d5/d5FpqXd9HUXOtwFFs+eonEcjarNt79Uajkd0PRzOS4vebv3Ecennbt4lBIBJck8kE IHMaEt7O0OzxAtDRxHQpqCooQKSpTNmf3eJ5NVbH4JIuZ2mTH3Vati+B92ZMUPo4raFG O354IEPFAiKhmWo2zd/vMKFkkfd+DQOlzcgjV92NUnWkuXCCgtEn7RyX2P9iB4Ot67on j3TeU7BPgji4ANGTReSHTAuaMqVLtYcy4XA6czAljOxTihcf21KjeN4Y/cyTu1cGY6tw ix7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=kqb1IvTtGWRGJYVxGxfd0yxGprDBM0Xz6JZFZx5S6T8=; b=P8JPpkpFDSNrI2yAhJoKXjZ90xbPo+IWQD/M2cwY/n8x7CF16UxUIsUMIXn8mAU8uK vZ62G+2HmNyWePvrZPkhV2BM12KeF3D3KUHR8TACitK4Wy0MxAevWxYo9UAyVoFMFB/f /yukbsSw5Zi9z2u1n6UgqR7+NsgFlrieP55qn8PEWlwnvqy8S+OA2Ch4s0C+4Vb62GCN jDgPBNkC/gW7aWa1/ufqDhpAwe+ueNB/1vnEsxk+fc50NH8Ock0cxZqu2+PO6ibyCRZe +GGZ6kfHCgatkaskpRKohpexupU3NFNKyKdEQG1Yb632uZsyl5xMc9PUkpUZ0VDAoUpp 8KVg== X-Gm-Message-State: AOPr4FWd4LY9aBCAztf7M8/weEVhFEP6pkAuGASTbTyxJHKdgCZSOsugWGjIOzYw7ePU55uBnZImwS6hs65Iug== MIME-Version: 1.0 X-Received: by 10.107.32.20 with SMTP id g20mr11073614iog.149.1460561926442; Wed, 13 Apr 2016 08:38:46 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.30.149 with HTTP; Wed, 13 Apr 2016 08:38:46 -0700 (PDT) In-Reply-To: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> <570BE79B.8040300@si6networks.com> Date: Wed, 13 Apr 2016 08:38:46 -0700 X-Google-Sender-Auth: pdm0d9YL61btqAJX5rBKnFLAIW8 Message-ID: Subject: Re: rfc2460bis question From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:38:49 -0000 At Wed, 13 Apr 2016 11:08:07 +0100, Tim Chown wrote: > But I would also add that whether we add the text or not, the (lack > of) maturity in Extension Header experience means we should not > advance 2460-bis to IS yet. That point was also made at the mic by > someone in last week=E2=80=99s meeting. I didn't attend the meeting locally or remotely, but if our latest agreement is that issues regarding EHs (including whether an intermediate node can insert/remove them) are so substantial that we should cancel the idea of advancing the spec to IS, I'm actually fine with that. I'm not yet convinced that we should allow intermediate nodes to do that, but I'm okay with holding off and discussing the matter. What I mainly disagreed with is to pretend that there is no issue at all (because "the RFC2460 text has not caused interoperability issues") and advance the doc with being silent about it. -- JINMEI, Tatuya From nobody Wed Apr 13 09:08:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1A12DB21 for ; Wed, 13 Apr 2016 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.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 Z00EetwvQfRE for ; Wed, 13 Apr 2016 09:08:07 -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 D077612DA87 for ; Wed, 13 Apr 2016 09:08:06 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0076.outbound.protection.outlook.com [213.199.154.76]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-43-EXo1_85OS3eQUBARUL_2nQ-1; Wed, 13 Apr 2016 17:08:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8dv9WWHmBWKVQXKRvUsM+VgcfDrN2IMoRZZ4SddiexM=; b=GCqXt7TaWzmUPjMxRcfouETF/zhJ2/URqTR8WmSMjvdUvYjrHAfYh5pHB2rMUqjWmrsHDMDhukSfCFX9/R+H7Czdpu1n6c9lI6v8f2dIBZ1OK5I22vAcDsPLbRNCp2kHCHkIk6vw/8IPQOnUmHR44AyCyft5zPo15JVjMqIyaM4= Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB464.eurprd07.prod.outlook.com (10.141.231.152) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 16:07:58 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0466.018; Wed, 13 Apr 2016 16:07:58 +0000 From: Tim Chown To: =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: rfc2460bis question Thread-Topic: rfc2460bis question Thread-Index: AQHRlWyIkI7jByjAYEGHSJT73UxYM5+ICkgAgAAIKIA= Date: Wed, 13 Apr 2016 16:07:58 +0000 Message-ID: References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> <570BE79B.8040300@si6networks.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.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:dce3:1a00:57b1:5621] x-ms-office365-filtering-correlation-id: 7e2a4d3f-4e8b-4f2d-ee38-08d363b5c7fb x-microsoft-exchange-diagnostics: 1; DBXPR07MB464; 5:fBqOyB+QQunTpBOGUUAdRj7YpeylC0ZS5LbZm2TMQOhI1t4Vqfb88FVA3F2etfcSGqqaZxw8CnZNKp62Q5yYNp8aEyeAp79VHsKYn0tHyLa5qZwf7mken7HPs6FkCrA82Y51Kz47kPKy/WJ7txkOuOOzfEGE6vt3ZmHJK7/rrA00uMjSbPv6Vvi9rlaR5fFu; 24:J/6+Rk5cu8amvlAu9NrS61Aj1BrkTQGFAVP/wBnOm5nBkMaAb533UtfGQ+5IWuro2NHU9nJL5hOATV2fwgmuWlxNBS4qusH7w67dAEY/fM8=; 7:tk+cNfNP6ff0EdrfLubtNOvRWEIjp6rhkq3V9NIkGZIBsNOizkoHEf2HITqDDI/k948cxZ/suJada8dWr9b9ME29/cH9KZfAyVBacgd2DDQ+B4+Ccx9yIXCJXXiOUb33kA2pdz97zW94/Fx7JPb3zkl9NP/nC+oFcgHJscHdlUYTdRpByRi6oLXAepxaojUOQurvLnFNYAetDmMXFhtaidt/4Mg0hIqtm6ABtN/oroU=; 20:P7pkcwp9iB3G5tDQRmAcioQeuMWU9AyhWV+Lc9okg04jPFxk1K4qeorKm5Kii74eK6b/ck4Tfhc+3BWGsmLekITOIIbggGU2QNx6HyIY70LxSjUIRZZgIwBOGoLxvBQPfMSiFd+R8IjYCEmnaUH/sDXZF5DJv3jSBHSP+aFyZu8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB464; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB464; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB464; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(50986999)(102836003)(77096005)(3660700001)(3280700002)(86362001)(76176999)(5002640100001)(1220700001)(6116002)(1096002)(4326007)(2906002)(5008740100001)(2950100001)(2900100001)(93886004)(586003)(57306001)(36756003)(11100500001)(87936001)(81166005)(92566002)(83716003)(5004730100002)(110136002)(33656002)(122556002)(50226001)(19580395003)(19580405001)(189998001)(82746002)(10400500002)(74482002)(106116001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB464; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 16:07:58.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB464 X-MC-Unique: EXo1_85OS3eQUBARUL_2nQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Fernando Gont , Bob Hinden , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:08:09 -0000 PiBPbiAxMyBBcHIgMjAxNiwgYXQgMTY6MzgsIOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQu anA+IHdyb3RlOg0KPiANCj4gQXQgV2VkLCAxMyBBcHIgMjAxNiAxMTowODowNyArMDEwMCwNCj4g VGltIENob3duIDx0amNAZWNzLnNvdG9uLmFjLnVrPiB3cm90ZToNCj4gDQo+PiBCdXQgSSB3b3Vs ZCBhbHNvIGFkZCB0aGF0IHdoZXRoZXIgd2UgYWRkIHRoZSB0ZXh0IG9yIG5vdCwgdGhlIChsYWNr DQo+PiBvZikgbWF0dXJpdHkgaW4gRXh0ZW5zaW9uIEhlYWRlciBleHBlcmllbmNlIG1lYW5zIHdl IHNob3VsZCBub3QNCj4+IGFkdmFuY2UgMjQ2MC1iaXMgdG8gSVMgeWV0LiBUaGF0IHBvaW50IHdh cyBhbHNvIG1hZGUgYXQgdGhlIG1pYyBieQ0KPj4gc29tZW9uZSBpbiBsYXN0IHdlZWvigJlzIG1l ZXRpbmcuDQo+IA0KPiBJIGRpZG4ndCBhdHRlbmQgdGhlIG1lZXRpbmcgbG9jYWxseSBvciByZW1v dGVseSwgYnV0IGlmIG91ciBsYXRlc3QNCj4gYWdyZWVtZW50IGlzIHRoYXQgaXNzdWVzIHJlZ2Fy ZGluZyBFSHMgKGluY2x1ZGluZyB3aGV0aGVyIGFuDQo+IGludGVybWVkaWF0ZSBub2RlIGNhbiBp bnNlcnQvcmVtb3ZlIHRoZW0pIGFyZSBzbyBzdWJzdGFudGlhbCB0aGF0IHdlDQo+IHNob3VsZCBj YW5jZWwgdGhlIGlkZWEgb2YgYWR2YW5jaW5nIHRoZSBzcGVjIHRvIElTLCBJJ20gYWN0dWFsbHkg ZmluZQ0KPiB3aXRoIHRoYXQuICBJJ20gbm90IHlldCBjb252aW5jZWQgdGhhdCB3ZSBzaG91bGQg YWxsb3cgaW50ZXJtZWRpYXRlDQo+IG5vZGVzIHRvIGRvIHRoYXQsIGJ1dCBJJ20gb2theSB3aXRo IGhvbGRpbmcgb2ZmIGFuZCBkaXNjdXNzaW5nIHRoZQ0KPiBtYXR0ZXIuDQo+IA0KPiBXaGF0IEkg bWFpbmx5IGRpc2FncmVlZCB3aXRoIGlzIHRvIHByZXRlbmQgdGhhdCB0aGVyZSBpcyBubyBpc3N1 ZSBhdA0KPiBhbGwgKGJlY2F1c2UgInRoZSBSRkMyNDYwIHRleHQgaGFzIG5vdCBjYXVzZWQgaW50 ZXJvcGVyYWJpbGl0eQ0KPiBpc3N1ZXMiKSBhbmQgYWR2YW5jZSB0aGUgZG9jIHdpdGggYmVpbmcg c2lsZW50IGFib3V0IGl0Lg0KDQpXZWxsLCB0aGF0IHdhcyBieSBubyBtZWFucyBhZ3JlZWQsIGJ1 dCBhIG51bWJlciBvZiBwZW9wbGUgaG9sZCB0aGF0IHZpZXcuDQpUaGF0IHZpZXcgbWlnaHQgYmUg aW5kZXBlbmRlbnQgb2Ygdmlld3Mgb24gdGhlIGFkZGl0aW9uIChvciBub3QpIG9mIEVIIGhhbmRs aW5nIHRleHQuDQoNClRpbQ== From nobody Wed Apr 13 13:35:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E412E0AE for ; Wed, 13 Apr 2016 13:35: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 0C76q2IYOcca for ; Wed, 13 Apr 2016 13:35:31 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 55F0012DFD1 for ; Wed, 13 Apr 2016 13:35:31 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id fs9so18850329pac.2 for ; Wed, 13 Apr 2016 13:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UgpuilEg0X5OQriY8v9pNVe/tRps0Fx06LOSF/0AG1A=; b=Uc2w2zZBHSfc3DZFBVfD5dKvaiqXJbrheHkBpdPZVUV6Htbs6lLcwxncRgj7jtMBQM Xx41WTuSZbRMa3mtFNuf4jLU1mBSHUL/Ad47jPATMcyp/Dz7aJHePoy15iGv4eOZhiG7 fhddNiBxi7uWsh1lsLMmxF8MDuaNaeHA8GHSy88SYuJESY4HmrVP9TEuEAL/l3pEOP2e gvpPDCveeixk9TFdLf62+t0KS+etuxQpWHVJHM7Rd6wGKzlaDbw1vs86Q00Ul4YxadR0 b3S4l4iIg/L1dPK7PLCkuFx6WXNFCEmEDjgvGnQ843Z7G5YN4x9s2+MI2Au5xEbhTvzJ zuHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=UgpuilEg0X5OQriY8v9pNVe/tRps0Fx06LOSF/0AG1A=; b=FzXkrJ2hIGDWT7Fq0wE4w7iS0LQR2TrbbacBaxq6EgYlipTWY2WLDkwSyN7vWSxtcA tNcHjKoKCf9w3raM8Rt7Jd5bJeO2hwGrS0kgXLSSSVjP/aHUfJEXU9YLH5sND+ycEAqA VwsFEm+Hk/MRcVr1CNDiTMDLiXYP/phdI6epO88ihwEevXeV6VgcfB5d4M75auKGUKO0 42E6XlZcBysoIFx8hA2gD5z+rTZIYY6bk4EgvBNqevEGU6A4uXc93m8mtucDGIuso3bs Hq/0xCeXzo6RpKUJdCRaTil0rwU3XCNu0xMnL89AO+mtz7oM6mG8sJ8dWIuXbQyR9eHA GeWQ== X-Gm-Message-State: AOPr4FWZjfkroX3gmPN/prAAnCYNQnmkTDo7KXrr9PVKDERdnNEeju6Fq4kf411ARSEXWQ== X-Received: by 10.66.63.104 with SMTP id f8mr15650671pas.109.1460579730948; Wed, 13 Apr 2016 13:35:30 -0700 (PDT) Received: from ?IPv6:2406:e007:5576:1:28cc:dc4c:9703:6781? ([2406:e007:5576:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ak9sm53164394pac.13.2016.04.13.13.35.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 13:35:29 -0700 (PDT) Subject: Re: rfc2460bis question To: Tim Chown , Fernando Gont References: <56F9CCA5.9040101@gmail.com> <8A52FAF7-DDB0-4150-B22E-14A7912375D9@gmail.com> <7633EF5D-418A-4AD7-8A9D-09798AA1FADF@cisco.com> <57056E6C.2090902@gmail.com> <5705B94E.4030704@gmail.com> <54BED520-9C0B-42A8-AC42-D4BE5B70333A@cisco.com> <47F880DB-2DE9-4338-97DD-F9BDCDDA6F00@employees.org> <570BE79B.8040300@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570EAD94.5070908@gmail.com> Date: Thu, 14 Apr 2016 08:35:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 20:35:34 -0000 On 13/04/2016 22:09, Tim Chown wrote: > Hi, >=20 >> On 11 Apr 2016, at 19:06, Fernando Gont wrote:= >> >> On 04/11/2016 02:44 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> At Fri, 8 Apr 2016 18:23:47 -0300, >>> otroan@employees.org wrote: >>> >>>> While a discussion on header insertion may be necessary, it is not >>>> in context for taking RFC2460 to IS. If a proposal is made, then the= >>>> working group should discuss that in the context of that proposal. >>> >>> I'm not sure what this "proposal" means...is it the proposed text for= >>> rfc2460bis from Bob like this one? >>> https://mailarchive.ietf.org/arch/msg/ipv6/MTOkrjcscodS0C5FLmZm_LJapG= Y >>> >>> I thought it was a clarification of the original intent of the RFC246= 0 >>> authors (and the understanding of most of then and now wg members), >>> rather than some new proposal. And since it's apparent that the >>> wording in RFC2460 wasn't really as clear as we originally as we >>> actually saw the "misinterpretation" in RFC4782, I thought it made >>> very sense to clarify that in rfc2460bis (to advance it to IS). >>> >>>> The RFC2460 text has not caused interoperability issues. Which is >>>> why I'm not convinced this change was required. >>> >>> This logic doesn't make sense to me. The fact that we had RFC4782 >>> suggests it's quite possible that we have other standard publications= >>> in future that misunterprets the original intent and really cause >>> interoperability issues. I don't know if the violation of RFC2460 by= >>> RFC4782 is currently implemented and actually causes an >>> interoperability issue, but even if not, I don't see any reason for >>> not making the clarification because of that. >>> >>> Now, if someone who has a conflict of interest between the original >>> RFC2460 intent and some particular new protocol wants to challenge >>> the original intent, we might be open to consider it, depending >>> on its technical details. But I'd say "the working group should >>> discuss that in the context of that proposal" outside of whether to >>> make a helpful clarification in rfc2460bis. If and when we agree on >>> making such a change, we'll publish a new standard document that >>> updates RFC2460(bis). >>> >>>> The default action, unless we can come to a different agreement, is >>>> to leave the RFC2460 text unchanged in RFC2460bis. >>> >>> So, for one, I disagree with this and I suggest we should come to a >>> "different agreement" (=3D making this clarification in rfc2460bis). >> >> +1 >> >> (couldn't write it down better than this) >=20 > I agree. >=20 > But I would also add that whether we add the text or not, the (lack of)= maturity in Extension Header experience means we should not advance 2460= -bis to IS yet. That point was also made at the mic by someone in last we= ek=E2=80=99s meeting. I could argue that in this case the IESG should rescind the Internet Stan= dard status of RFC791, because we have plenty of running code experience that new IPv4 Options cannot be deployed, so there is a distinct lack of matur= ity in IPv4 Option experience. However, the first step is perhaps to await the analysis of the two recen= t errata reported on RFC 2460. Brian From nobody Wed Apr 13 15:27:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8112DAFE for ; Wed, 13 Apr 2016 15:27:55 -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 WrHdXB_XVR0J for ; Wed, 13 Apr 2016 15:27:53 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 BB5C612DB1C for <6man@ietf.org>; Wed, 13 Apr 2016 15:27:53 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id s79so78137151oie.1 for <6man@ietf.org>; Wed, 13 Apr 2016 15:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=i0wfnpsnVJ8bsKoiL8+cAUl1efRkHNBiz1ez4+pBUAA=; b=aUybgRJ1kVYdlPB2HyB2T3VoEPu9zK6L3KPn1VSGbVGOYGpy7yOohrJoJgAp2HoEKH ratghSUO/Woj4gHcZyuwht81iuHmD+tboeT2r+2XghVu9DptvaqAKFsIknsL/oZgOrqV 4+2pBWSNmXqeCQXzyowpOLhak09HtMl/I1GnlPKkRjHKGeNxI8nv67QOxAZ8E9fxd3i+ JtxCAh/XyaB/5zZ1YPjpR8qX2upgpC5Y2Awyi0ly6B5v+NLIEKYkL8O9nQkAitmlriRZ NQj47nrtI4ZkSx5koInfpeb325CDksAlh7JHm4hBBpgYpZU7jLqPnHOetZs3avT6MsTn mavg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=i0wfnpsnVJ8bsKoiL8+cAUl1efRkHNBiz1ez4+pBUAA=; b=beSAkxvN/QktZFEwPD6hjW4r6hYo/1hQvgeuDPKVjo4Y3tatSORlCwpNaBJpk7KsqY bRyfHSbbTR7wXkWxC7fme6iGeBIpk7OMQ5Y0WmrrCFu6PTHq/tp8Mf09XD+Jsf8LAOvX FGMtws6tIyaxQEhkdggjfVr0XWB3TsuSJvk0isSshNSbXHImQhlBSKaLGdjtfIp6BqlP AyFp7CzNkPjq25qVAIlVZqLVEbmuDWRv8HYW0a2p+eQA3+77H9NPBCjE7oAq4Is7dBTA qkDxEJjCDcKXpv02n5uYHPXcpbS51g3C7umGb82ttZ057ioUp0vsLSOZd4UV7JkPm6kl HNyg== X-Gm-Message-State: AOPr4FUufNwE9u2SzhqoRLTky7GR0/zg0gPoxk5O3rLpwOUIbsNUxtDcvL03T2qYliPzKA== X-Received: by 10.202.208.131 with SMTP id h125mr5826627oig.87.1460586473171; Wed, 13 Apr 2016 15:27:53 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id v14sm2248490ota.1.2016.04.13.15.27.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Apr 2016 15:27:51 -0700 (PDT) Subject: Re: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E84C264E-B7CC-4778-8BC8-1FDA82811A7A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Wed, 13 Apr 2016 15:27:48 -0700 Message-Id: References: To: Dave Thaler X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 22:27:55 -0000 --Apple-Mail=_E84C264E-B7CC-4778-8BC8-1FDA82811A7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dave, > On Apr 6, 2016, at 7:44 AM, Dave Thaler wrote: >=20 > Yes, it refers to the node, and good grammatical point. So to take = your feedback in a different spot: >=20 > NEW: If any of the packets sent on that path are too large to be = forwarded > NEW: by some node (regardless of whether it decrements the Hop Limit) = along the path, that node will discard them and return > NEW: ICMPv6 Packet Too Big messages [ICMPv6]. >=20 > I.e. moved it up to right after the first existing use of =E2=80=9Cnode=E2= =80=9D. I am not convinced the original text needs to change. It doesn=E2=80=99t = limit the discarding and sending ICMPv6 PTB only to nodes that decrement = the hope limit. However, if there are folks who read the text as required the decrement = action, I am OK with the clarification you propose. Bob >=20 > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Wednesday, April 6, 2016 11:42 AM > To: Dave Thaler ; 6man@ietf.org > Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal >=20 > Hello Dave, >=20 > If =E2=80=9CIt=E2=80=9D refers to the node, maybe it would be more = readable to place the change at the end of the sentence? >=20 > Cheers, >=20 > Pascal >=20 > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler > Sent: mercredi 6 avril 2016 11:21 > To: 6man@ietf.org > Subject: Proposed RFC 1981bis clarification regarding Hop Limit = decrement being orthogonal >=20 > OLD: If any of the packets sent on that path are too large to be = forwarded > OLD: by some node along the path, that node will discard them and = return > OLD: ICMPv6 Packet Too Big messages [ICMPv6]. >=20 > NEW: If any of the packets sent on that path are too large to be = forwarded > NEW: by some node along the path (regardless of whether it decrements = the Hop Limit), that node will discard them and return > NEW: ICMPv6 Packet Too Big messages [ICMPv6]. >=20 > That is, just add the phrase =E2=80=9C(regardless of whether it = decrements the Hop Limit)=E2=80=9D to the existing sentence. >=20 > Dave > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_E84C264E-B7CC-4778-8BC8-1FDA82811A7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXDsflAAoJEK7rdBF357uoGJ0H+QGEOWZuAYGKTH6lDJzBmJcF O6DNdRZ3nwnDVpMYhc/VgA6EPf+UktdBWM993GdfmAzyzmgetOsufETqKuUPseBW zoe5BrLv5Zij3Po/r4ApmMrh+wRK/cMqmYzrpbOTJDLQJUPtioSGBRy2ppQGGidR /7+1amwE51jhHKX2KWvryE/2eiV1vcpmAs/yPvJUK1qx1ss1jSNFq0E5Mk6VdqXk R+bwaiVnOl+Fe/vOnkl0Z3WvoG0vmJJTbO26Dh5N53HIHLwJgLwFXDzfNviJfFuQ v+KMcN5VLdDUu7bqqHf1/2e6k/71BP7MquzoSTiTiBGSSMXjosz0xClkd2N2GIk= =ACYB -----END PGP SIGNATURE----- --Apple-Mail=_E84C264E-B7CC-4778-8BC8-1FDA82811A7A-- From nobody Wed Apr 13 15:45:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F1912DC98 for ; Wed, 13 Apr 2016 15:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 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_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 aeTp7Cp4DCA0 for ; Wed, 13 Apr 2016 15:45:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDA812DC2B for <6man@ietf.org>; Wed, 13 Apr 2016 15:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+XOTqKzSYVnu/TE9LhONfK2gmiyPnS31Nt1ks1D08YY=; b=kDnQm/n/ENlWqvvs6886NPivvKe0QzUZz3noMIg2uUeuB6RrvWtu4+scwPeUabvl3e2mW05uThs/o7xcLthfUPfsW0eqEET1rZVVWbOVZeddJUnI+CwxJZO8IzrfFqsJ+AxCfMx7T38DnwexzcOCBScsrJKlmmQ4cmdbl36aYX0= Received: from CY1PR0301MB0715.namprd03.prod.outlook.com (10.160.159.145) by CY1PR0301MB0715.namprd03.prod.outlook.com (10.160.159.145) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 13 Apr 2016 22:45:36 +0000 Received: from CY1PR0301MB0715.namprd03.prod.outlook.com ([10.160.159.145]) by CY1PR0301MB0715.namprd03.prod.outlook.com ([10.160.159.145]) with mapi id 15.01.0453.029; Wed, 13 Apr 2016 22:45:36 +0000 From: Dave Thaler To: Bob Hinden Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Topic: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Thread-Index: AdGQD39tabMJTXu1RgqrkGB6j+yhfgAArF4QAAAd27ABcEM0AAAAeIWA Date: Wed, 13 Apr 2016 22:45:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::437] x-ms-office365-filtering-correlation-id: 536b23e8-03c4-45e0-b529-08d363ed549c x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0715; 5:WpQVxRB/nQnS6+jq8dyjdDOajpVnum3WY/kXJhZQTLkC+bxwObRAtQRSnvau2Ag6AhQr1e4dV+L8r49yU4VSC9fooU7p4n9XjQrfsHtAlKaMFpRKRmVaZDt220HSRZArIugjvc96vrGFQ59vWEWpCQ==; 24:NiqOI3KbV5FQ6MgoWiGM2E+8H+wYemxcFewQ8/zvtHO805zbYQJtB6PBMfOlXtp9qSpWHr4g6aP6eAod/CDmIe7VrjfQ9epN3BrD5YLfsaM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0715; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0715; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0715; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(9686002)(99286002)(122556002)(92566002)(81166005)(2906002)(2950100001)(5002640100001)(5003600100002)(2900100001)(50986999)(54356999)(76176999)(76576001)(86612001)(33656002)(19580395003)(4326007)(15975445007)(5004730100002)(11100500001)(87936001)(77096005)(10090500001)(586003)(93886004)(110136002)(189998001)(5008740100001)(86362001)(10290500002)(6116002)(1096002)(74316001)(1220700001)(19580405001)(5005710100001)(10400500002)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0715; H:CY1PR0301MB0715.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 22:45:36.5139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0715 Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 22:45:55 -0000 SSBjZXJ0YWlubHkgYmVsaWV2ZSB0aGF0IHRoZSBjbGFyaWZpY2F0aW9uIGlzIG5lZWRlZC4gIEkg dGFsa2VkIHRvIHNvbWVvbmUgYXQgSUVURg0Kd2hvIHdhcyB2ZXJ5IHN1cnByaXNlZCB3aGVuIEkg dG9sZCB0aGVtIHRoZXJlIHdhcyBubyBzdWNoIHJlc3RyaWN0aW9uLg0KSSBmb3JnZXQgd2hvIGl0 IHdhcyBvZmZoYW5kIChtYXliZSBzb21lb25lIHJlYWRpbmcgdGhpcyB0aHJlYWQpLCBidXQgdGhl IGNvbnRleHQNCndhcyBhcm91bmQgbGlua3Mgd2l0aCBkaWZmZXJlbnQgTVRVcyB0byBkaWZmZXJl bnQgb24tbGluayBkZXN0aW5hdGlvbnMgKGUuZy4sIA0KZGlmZmVyZW50IHNlZ21lbnRzIHdpdGgg ZGlmZmVyZW50IE1UVXMpLg0KDQpEYXZlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQm9iIEhpbmRlbiBbbWFpbHRvOmJvYi5oaW5kZW5AZ21haWwuY29tXQ0KPiBTZW50 OiBXZWRuZXNkYXksIEFwcmlsIDEzLCAyMDE2IDM6MjggUE0NCj4gVG86IERhdmUgVGhhbGVyIDxk dGhhbGVyQG1pY3Jvc29mdC5jb20+DQo+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWls LmNvbT47IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gPHB0aHViZXJ0QGNpc2NvLmNvbT47 IDZtYW5AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFByb3Bvc2VkIFJGQyAxOTgxYmlzIGNsYXJp ZmljYXRpb24gcmVnYXJkaW5nIEhvcCBMaW1pdA0KPiBkZWNyZW1lbnQgYmVpbmcgb3J0aG9nb25h bA0KPiANCj4gRGF2ZSwNCj4gDQo+ID4gT24gQXByIDYsIDIwMTYsIGF0IDc6NDQgQU0sIERhdmUg VGhhbGVyIDxkdGhhbGVyQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gWWVzLCBpdCBy ZWZlcnMgdG8gdGhlIG5vZGUsIGFuZCBnb29kIGdyYW1tYXRpY2FsIHBvaW50LiAgIFNvIHRvIHRh a2UgeW91cg0KPiBmZWVkYmFjayBpbiBhIGRpZmZlcmVudCBzcG90Og0KPiA+DQo+ID4gTkVXOiBJ ZiBhbnkgb2YgdGhlIHBhY2tldHMgc2VudCBvbiB0aGF0IHBhdGggYXJlIHRvbyBsYXJnZSB0byBi ZSBmb3J3YXJkZWQNCj4gPiBORVc6IGJ5IHNvbWUgbm9kZSAocmVnYXJkbGVzcyBvZiB3aGV0aGVy IGl0IGRlY3JlbWVudHMgdGhlIEhvcCBMaW1pdCkNCj4gYWxvbmcgdGhlIHBhdGgsIHRoYXQgbm9k ZSB3aWxsIGRpc2NhcmQgdGhlbSBhbmQgcmV0dXJuDQo+ID4gTkVXOiBJQ01QdjYgUGFja2V0IFRv byBCaWcgbWVzc2FnZXMgW0lDTVB2Nl0uDQo+ID4NCj4gPiBJLmUuIG1vdmVkIGl0IHVwIHRvIHJp Z2h0IGFmdGVyIHRoZSBmaXJzdCBleGlzdGluZyB1c2Ugb2Yg4oCcbm9kZeKAnS4NCj4gDQo+IEkg YW0gbm90IGNvbnZpbmNlZCB0aGUgb3JpZ2luYWwgdGV4dCBuZWVkcyB0byBjaGFuZ2UuICBJdCBk b2VzbuKAmXQgbGltaXQgdGhlDQo+IGRpc2NhcmRpbmcgYW5kIHNlbmRpbmcgSUNNUHY2IFBUQiBv bmx5IHRvIG5vZGVzIHRoYXQgZGVjcmVtZW50IHRoZSBob3BlDQo+IGxpbWl0Lg0KPiANCj4gSG93 ZXZlciwgaWYgdGhlcmUgYXJlIGZvbGtzIHdobyByZWFkIHRoZSB0ZXh0IGFzIHJlcXVpcmVkIHRo ZSBkZWNyZW1lbnQNCj4gYWN0aW9uLCBJIGFtIE9LIHdpdGggdGhlIGNsYXJpZmljYXRpb24geW91 IHByb3Bvc2UuDQo+IA0KPiBCb2INCj4gDQo+IA0KPiANCj4gPg0KPiA+IEZyb206IFBhc2NhbCBU aHViZXJ0IChwdGh1YmVydCkgW21haWx0bzpwdGh1YmVydEBjaXNjby5jb21dDQo+ID4gU2VudDog V2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDExOjQyIEFNDQo+ID4gVG86IERhdmUgVGhhbGVyIDxk dGhhbGVyQG1pY3Jvc29mdC5jb20+OyA2bWFuQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFBy b3Bvc2VkIFJGQyAxOTgxYmlzIGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIEhvcCBMaW1pdA0KPiBk ZWNyZW1lbnQgYmVpbmcgb3J0aG9nb25hbA0KPiA+DQo+ID4gSGVsbG8gRGF2ZSwNCj4gPg0KPiA+ IElmIOKAnEl04oCdIHJlZmVycyB0byB0aGUgbm9kZSwgbWF5YmUgaXQgd291bGQgYmUgbW9yZSBy ZWFkYWJsZSB0byBwbGFjZSB0aGUNCj4gY2hhbmdlIGF0IHRoZSBlbmQgb2YgdGhlIHNlbnRlbmNl Pw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPiBGcm9tOiBpcHY2 IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBUaGFsZXIN Cj4gPiBTZW50OiBtZXJjcmVkaSA2IGF2cmlsIDIwMTYgMTE6MjENCj4gPiBUbzogNm1hbkBpZXRm Lm9yZw0KPiA+IFN1YmplY3Q6IFByb3Bvc2VkIFJGQyAxOTgxYmlzIGNsYXJpZmljYXRpb24gcmVn YXJkaW5nIEhvcCBMaW1pdCBkZWNyZW1lbnQNCj4gYmVpbmcgb3J0aG9nb25hbA0KPiA+DQo+ID4g T0xEOiBJZiBhbnkgb2YgdGhlIHBhY2tldHMgc2VudCBvbiB0aGF0IHBhdGggYXJlIHRvbyBsYXJn ZSB0byBiZSBmb3J3YXJkZWQNCj4gPiBPTEQ6IGJ5IHNvbWUgbm9kZSBhbG9uZyB0aGUgcGF0aCwg dGhhdCBub2RlIHdpbGwgZGlzY2FyZCB0aGVtIGFuZCByZXR1cm4NCj4gPiBPTEQ6IElDTVB2NiBQ YWNrZXQgVG9vIEJpZyBtZXNzYWdlcyBbSUNNUHY2XS4NCj4gPg0KPiA+IE5FVzogSWYgYW55IG9m IHRoZSBwYWNrZXRzIHNlbnQgb24gdGhhdCBwYXRoIGFyZSB0b28gbGFyZ2UgdG8gYmUgZm9yd2Fy ZGVkDQo+ID4gTkVXOiBieSBzb21lIG5vZGUgYWxvbmcgdGhlIHBhdGggKHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBpdCBkZWNyZW1lbnRzDQo+IHRoZSBIb3AgTGltaXQpLCB0aGF0IG5vZGUgd2lsbCBk aXNjYXJkIHRoZW0gYW5kIHJldHVybg0KPiA+IE5FVzogSUNNUHY2IFBhY2tldCBUb28gQmlnIG1l c3NhZ2VzIFtJQ01QdjZdLg0KPiA+DQo+ID4gVGhhdCBpcywganVzdCBhZGQgdGhlIHBocmFzZSDi gJwocmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGRlY3JlbWVudHMgdGhlIEhvcA0KPiBMaW1pdCni gJ0gdG8gdGhlIGV4aXN0aW5nIHNlbnRlbmNlLg0KPiA+DQo+ID4gRGF2ZQ0KPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4gaXB2NkBp ZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Wed Apr 13 16:03:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3ED12E425 for ; Wed, 13 Apr 2016 16:03:12 -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 A_bw1idXzhnA for ; Wed, 13 Apr 2016 16:03:11 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 9958112E423 for <6man@ietf.org>; Wed, 13 Apr 2016 16:03:11 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id f1so133995988igr.1 for <6man@ietf.org>; Wed, 13 Apr 2016 16:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=XRLNjglW5VQw1vaDw1NL2KPgBt+Gz8wpJFqnYwT86zw=; b=W5UXyirJEDmIVOusGZI91XmSUvyOuj/30As0h1hf+m0qq4fpdufcl0Stt6SNvheri9 gQDb93YNJQ8KH9mOs++OEnv+MTBjfe25vQZHGAAo/Qnc4GkYYx4eN0D27w+sypRgE68n xjE2Q+DAuSzY/oKnTptZUz6lTl7KOa5YDMykTGywhK93BrUHWbu7ovN8xiFwlIdhBlDq zV98zvDTMZoQsJHfZXYLVWW34GPIbkaxZpoGwldLhirCj+VsweLlSsCOthpTYdJq5UqS 7kTAAvsFzywbauJFWoQ8QIBkxgg/7btBLzugYyCTYqeAihtNcgM2XnFLCRZkYFJaWXme SIuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=XRLNjglW5VQw1vaDw1NL2KPgBt+Gz8wpJFqnYwT86zw=; b=XDUBSfDhj9SxqVCteF+LHTDHt+mUHkimSFw4Cg5eCblbLapWM5OJ/9eXEqHyfjDXJA POyXXtpjJdLiA9905WvdWV9EnjwEkiDJcPSVjEcus4DG4suei/136P+45mcSG7gIc7kK 9jXGQcrKuA+wi6bFVzNfj7fmwVshixROhsw3nSTbBceHFyyRFoByI+kgKKcQH8RRnPZs REFZUTvbvCw6505Vvil9+hUchL3+fkC+wZHkEa/SfxqjRN4o5o57p2x+8sYdW+Wqbeng gUVwOVg5crLWoWgRbIb4qz+Jr5oOWY3dS/mLW/75lSoCHmE8nTx94ocJJN2cBhc8iNMp rH8A== X-Gm-Message-State: AD7BkJLU67OAQjfPdwQZb/9TZwIUmErR66uncqylt8iCOv4IqYWhbSd8DWoQjlfezyV/f/MZCoHRactprDBVNw== MIME-Version: 1.0 X-Received: by 10.50.23.80 with SMTP id k16mr35165647igf.94.1460588590903; Wed, 13 Apr 2016 16:03:10 -0700 (PDT) Received: by 10.107.142.67 with HTTP; Wed, 13 Apr 2016 16:03:10 -0700 (PDT) Date: Wed, 13 Apr 2016 16:03:10 -0700 Message-ID: Subject: EH end encapsulation in 2460bis From: Tom Herbert To: 6man@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 23:03:12 -0000 Hello, >From draft-ietf-6man-rfc2460bis-04 "Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]." It is unclear to me how/rather IP encapsulation can meet the requirements or at least the intent of a node wanting to insert extension headers. For instance if a middlebox is presented a packet with EHs ABC and it wishes to insert EH X, it's intent might be to create a packet with EHs ABXC. I don't see how this can generally be expressed with encapsulation. For instance, is expected that there is some process of moving/copying certain of the original EHs to the outer headers (like HBH, routing)? Thanks, Tom From nobody Wed Apr 13 16:59:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1061912D5FF for ; Wed, 13 Apr 2016 16:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 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.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 92lf3RtBYEOF for ; Wed, 13 Apr 2016 16:59:31 -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 5427E12DF0A for <6man@ietf.org>; Wed, 13 Apr 2016 16:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3901; q=dns/txt; s=iport; t=1460591971; x=1461801571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fi5JzLU4aM891jcW2aYanvd5CS5FtMJYMi2SWCTmBT8=; b=NeAzGaasSbt54pnMmS6YMxWxM9nQSfyz3sh1AfAC3B8k3EhtNI4gdQWl pskTpTSDTH/yBS71WsFy/YMOjLcnWw48/sg67GRUfAErQIPDOgr2M2IPA YNOaY6YC7Bu6pBZSCPAbtQ286bQjr5IH9l2cgDOFECGOZ5+uYXTdVsIzD s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAgBr3A5X/4cNJK1egzdTfQa6TQ6Bc?= =?us-ascii?q?RcLhWwCgUE4FAEBAQEBAQFlJ4RBAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FDg2?= =?us-ascii?q?IBggOwxEBAQEBAQEBAQEBAQEBAQEBAQEBAQENBASIFoJWh2qCKwWHcpAWAYMjg?= =?us-ascii?q?WZtiBaPEI8mAR4BQ4NnbIh8fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,482,1454976000"; d="asc'?scan'208";a="91556744" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 23:59:30 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3DNxTiP001022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 23:59:30 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 18:59:29 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 18:59:29 -0500 From: "Fred Baker (fred)" To: Tom Herbert Subject: Re: EH end encapsulation in 2460bis Thread-Topic: EH end encapsulation in 2460bis Thread-Index: AQHRldixsJ46CY2X20unwVqHwK89Qp+I6SWA Date: Wed, 13 Apr 2016 23:59:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_359C7212-302B-4D2D-94B6-B77240CBC3B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 23:59:34 -0000 --Apple-Mail=_359C7212-302B-4D2D-94B6-B77240CBC3B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I actually looked pretty hard at this in = https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00. My = segment-routing colleagues wanted pretty badly to insert an SR header at = some point in the network, and then remove it somewhere else before = delivery to the destination. Working through potential failure cases, what worried me was the = security header. Suppose, for example, that the inserted SR header would = have to be removed before being given to the addressed destination, but = the addressed destination was an anycast address? In such a case, the = system that will ultimately respond to the packet advertises itself as = "a" right router capable of forwarding the packet to that address. So, = fine, I give the packet to the "router", and the receiving system = realizes that the destination address is one of its own, and so receives = it as a message addressed to it. Oops; we tripped over an assumption. At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told = me that they had already vacated the field, leaving me with my pants = around my ankles. Thanks, guys. But that is fundamentally the point. We need a solution that has no = sticky failure cases, and delivering the actual packet sent is the only = one that presents itself. Encapsulation does that. Anything else has to = prove the case. > On Apr 13, 2016, at 4:03 PM, Tom Herbert wrote: >=20 > Hello, >=20 >> =46rom draft-ietf-6man-rfc2460bis-04 >=20 > "Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]." >=20 > It is unclear to me how/rather IP encapsulation can meet the > requirements or at least the intent of a node wanting to insert > extension headers. For instance if a middlebox is presented a packet > with EHs ABC and it wishes to insert EH X, it's intent might be to > create a packet with EHs ABXC. I don't see how this can generally be > expressed with encapsulation. For instance, is expected that there is > some process of moving/copying certain of the original EHs to the > outer headers (like HBH, routing)? >=20 > Thanks, > Tom >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_359C7212-302B-4D2D-94B6-B77240CBC3B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVw7dYEayAOS/EQ8MAQKFSw//UpNaVAaPTLNr7LEddw5iPRWKRGWvcwol dG7OP0s6mu8eIk71uy4VLsaLchN0n8yZHjSQrtca1nGj3j1ne5+mVS67gxe/PX98 HpL2rUOz2wAtEm46rQ1MdgelvEg9LvU8TnngJ6hNdrnyTBByXZYPlcR9EKvip2WH MjRUMLA9ReOcS/5+tezFnproqFUURmmeUBsDOyEnz29ZkHBvKuEkghKzipU5jIws ZKKDKAlSRfTZjwXRcmCV/uMq6HJRLkVudBswvmcN9P2WeTBHA2aggp2T0p8KbbPo qheDI9s52r6mv2kUBbk8rv2AHCoOWxEhvhCEohjNz4P6O6xw6LBB7/eK5NaIrYVk celOpTuaPf2BwXaVbXC0uRXlE7Ap4j9F4aSK8ax2Ms8rQUZhYB1l2fj/b/f9HSjn B6k75liSNSjp74uFF13RsBWIcpPr9g+XyMTRIyFLbGYqMN7SE2jY2IE1+BV7zx9x 4oWnWzLTwbtPLME+wPiWyBbL+6L3Gmfg6CY6qh6PYr/VEtQruSJglXJz6313Ar8m GKVPNSO0uJxdhIjs89F0yo1sZglUtvdgKxUF2OG+QDvfw9Tca0QSq7s22UJ/2/fj v3bV43XpJ4RI7lKY6OOzjgUbY0NfMDHfoype5WmUFEFCdFZFkkbbciuU28d8vxW4 eAt0C75ytMs= =vbZC -----END PGP SIGNATURE----- --Apple-Mail=_359C7212-302B-4D2D-94B6-B77240CBC3B7-- From nobody Wed Apr 13 17:58:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E422212E5A7 for ; Wed, 13 Apr 2016 17:58:24 -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 Y8t9HNTPmPVT for ; Wed, 13 Apr 2016 17:58:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 1643A12E5A4 for <6man@ietf.org>; Wed, 13 Apr 2016 17:58:23 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id fs9so20679422pac.2 for <6man@ietf.org>; Wed, 13 Apr 2016 17:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bUP7Xx9Ynvkfy9E6uOWEIUunr4rLZKme1h71yjO08LQ=; b=vCjebkmUVX5+BBGEP0BFPvpDnQNgLhyLMckZrl2/JuPIA4QEBZf9/pzDR37ArFloiv TpGqtQZp/SetutYzP/otluvGtywSaJ7NCTUh6HtvDLgyccJHmfzWfm1Rih6eS4s5W8IA vNJnC7CJLWVQoQHreyWRlj6hGM68I/d533NkxZXODT92QaCK2xcr26Vip0mpBhoJEZjX Yfc+/D6nMwZUJZkXgQS523ahNfWdvFLles05IVCk4Ig5mNlPgHstjrF73LyUrGMYZQkf ywpb82cE8uidrn+PCkar8QcBt8HJvMX73nz01J4reVGOTfj/Hb9yCLB21GFU3SoGLuah NbVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=bUP7Xx9Ynvkfy9E6uOWEIUunr4rLZKme1h71yjO08LQ=; b=PuEGNXm5u+COBDVjnsceYuonVJJJkfA5eIJFw6pFIrLyEfa71tZxX99iwjcE7IYVA/ QjzlgbvktcTQlk3A0dQOCLWtWYvRTF8WGIJAPXhx4saY6x9SwmorVUZH/bIlyOQhDjHK B9Qzr4QYZyd0zC+r+lIiemlPAZqvqfdIo5T6njH6raQAf16Cgp28oQVxjWCn0RiIvOJr nPIw9JzaHVLdSSTEe+T67B/vXd04yTkLzxiEr1PUZd2TdwYDEvfiFMA9ZhunRjI/oFv6 NlJNdzcNbPG1uJYgJUWlQ6udHD/ntANBDqzOswAr/2jq5XVrH6Q5klDtJMcTgj1ugrLM naWQ== X-Gm-Message-State: AOPr4FUQHw0Kj2L+pHuaZmTajOqYanSEBdZyfnsSg78yPvbxzr15FWBOSBeKebpF50Cbmw== X-Received: by 10.66.218.161 with SMTP id ph1mr16870047pac.83.1460595502683; Wed, 13 Apr 2016 17:58:22 -0700 (PDT) Received: from ?IPv6:2406:e007:5576:1:28cc:dc4c:9703:6781? ([2406:e007:5576:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 136sm10791077pfz.44.2016.04.13.17.58.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 17:58:21 -0700 (PDT) Subject: Re: EH end encapsulation in 2460bis To: "Fred Baker (fred)" , Tom Herbert References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <570EEB31.4090003@gmail.com> Date: Thu, 14 Apr 2016 12:58:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 00:58:25 -0000 On 14/04/2016 11:59, Fred Baker (fred) wrote: > I actually looked pretty hard at this in https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-00. My segment-routing colleagues wanted pretty badly to insert an SR header at some point in the network, and then remove it somewhere else before delivery to the destination. > > Working through potential failure cases, what worried me was the security header. Suppose, for example, that the inserted SR header would have to be removed before being given to the addressed destination, but the addressed destination was an anycast address? In such a case, the system that will ultimately respond to the packet advertises itself as "a" right router capable of forwarding the packet to that address. So, fine, I give the packet to the "router", and the receiving system realizes that the destination address is one of its own, and so receives it as a message addressed to it. Oops; we tripped over an assumption. > > At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told me that they had already vacated the field, leaving me with my pants around my ankles. Thanks, guys. > > But that is fundamentally the point. We need a solution that has no sticky failure cases, and delivering the actual packet sent is the only one that presents itself. Encapsulation does that. Anything else has to prove the case. Agreed. And to Tom's question: >> For instance, is expected that there is >> some process of moving/copying certain of the original EHs to the >> outer headers (like HBH, routing)? Afaics, the encapsulator can do whatever it wants as long as the new IPv6 header is valid. It's creating a brand new IP packet that happens to contain the incoming one, so there's no reason it can't copy some of the extension headers. I'm not sure that it *should* do that, if the goal is to get through a part of the Internet that discards certain header types. Brian >> On Apr 13, 2016, at 4:03 PM, Tom Herbert wrote: >> >> Hello, >> >>> From draft-ietf-6man-rfc2460bis-04 >> >> "Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]." >> >> It is unclear to me how/rather IP encapsulation can meet the >> requirements or at least the intent of a node wanting to insert >> extension headers. For instance if a middlebox is presented a packet >> with EHs ABC and it wishes to insert EH X, it's intent might be to >> create a packet with EHs ABXC. I don't see how this can generally be >> expressed with encapsulation. For instance, is expected that there is >> some process of moving/copying certain of the original EHs to the >> outer headers (like HBH, routing)? >> >> Thanks, >> Tom >> >> -------------------------------------------------------------------- >> 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 14 01:12:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A1012E026 for ; Thu, 14 Apr 2016 01:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, 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 Fu-JP4hsmfBR for ; Thu, 14 Apr 2016 01:12:51 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D472712DFF5 for <6man@ietf.org>; Thu, 14 Apr 2016 01:12:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 69CDE4035A; Thu, 14 Apr 2016 10:12:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAfiojY0AoWE; Thu, 14 Apr 2016 10:12:46 +0200 (CEST) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7E20D40356; Thu, 14 Apr 2016 10:12:46 +0200 (CEST) Message-ID: <570F50FF.7040504@globis.net> Date: Thu, 14 Apr 2016 10:12:47 +0200 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Herbert Subject: Re: EH end encapsulation in 2460bis References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020902040503060301040803" Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:12:52 -0000 This is a multi-part message in MIME format. --------------020902040503060301040803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Tom Herbert wrote: > Hello, > > > From draft-ietf-6man-rfc2460bis-04 > > "Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]." > > It is unclear to me how/rather IP encapsulation can meet the > requirements or at least the intent of a node wanting to insert > extension headers. For instance if a middlebox is presented a packet > with EHs ABC and it wishes to insert EH X, it's intent might be to > create a packet with EHs ABXC. I don't see how this can generally be > expressed with encapsulation. For instance, is expected that there is > some process of moving/copying certain of the original EHs to the > outer headers (like HBH, routing)? > > Thanks, > Tom > > A middleware box can't possibly know all the details of the entire downstream topology/MTU limitations/load balancing etc. So it would seem to me that choosing for encapsulation implies that there will be another middleware box somewhere further down the path that will perform an inverse de-encapsulation, so that the original packet gets delivered to the final recipient as sent by the sender. That's how transports like MPLS and WAN optimisation work today, and certainly feels like the right thing to do to me. Otherwise, if an extension header is going to be that valuable to ensure good communications, the source node can insert it itself IMHO. My own €0.02 worth is that inserting/deleting/or otherwise messing around with packet headers, just makes operations much more difficult. [written by someone who experienced the horror of L2 bridging FDDI to Ethernet first hand] -- regards, RayH --------------020902040503060301040803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Tom Herbert wrote:
Hello,

>From draft-ietf-6man-rfc2460bis-04

"Extension headers must never be inserted by any node other than the
source of the packet.  IP Encapsulation must be used to meet any
requirement for inserting headers, for example, as defined in
[RFC2473]."

It is unclear to me how/rather IP encapsulation can meet the
requirements or at least the intent of a node wanting to insert
extension headers. For instance if a middlebox is presented a packet
with EHs ABC and it wishes to insert EH X, it's intent might be to
create a packet with EHs ABXC. I don't see how this can generally be
expressed with encapsulation. For instance, is expected that there is
some process of moving/copying certain of the original EHs to the
outer headers (like HBH, routing)?

Thanks,
Tom
A middleware box can't possibly know all the details of the entire downstream topology/MTU limitations/load balancing etc.

So it would seem to me that choosing for encapsulation implies that there will be another middleware box somewhere further down the path that will perform an inverse de-encapsulation, so that the original packet gets delivered to the final recipient as sent by the sender. That's how transports like MPLS and WAN optimisation work today, and certainly feels like the right thing to do to me.

Otherwise, if an extension header is going to be that valuable to ensure good communications, the source node can insert it itself IMHO.

My own €0.02 worth is that inserting/deleting/or otherwise messing around with packet headers, just makes operations much more difficult. [written by someone who experienced the horror of L2 bridging FDDI to Ethernet first hand]

--
regards,
RayH
--------------020902040503060301040803-- From nobody Thu Apr 14 01:25:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75EB12D9C9 for ; Thu, 14 Apr 2016 01:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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.996, 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 zt-8_BH_e3gi for ; Thu, 14 Apr 2016 01:25:46 -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 21ECD12DA13 for <6man@ietf.org>; Thu, 14 Apr 2016 01:25:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 874B6A2; Thu, 14 Apr 2016 10:25:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1460622343; bh=72oZ5JOUj8ecuPGiWmxqt9hhx7hlohcGv3QS2IVtEPY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gYLM/ElNmQdET6lT/M4dewhtLewghvKVAEQpPRga4SGUgSq4YCU6lSA2VbfW5NQeb 1FTSt8WOWS61+zJ7jEOGKvSMYXLEmac0HiZ7U2h2vOhGx7FCfnEG0+NstGz4GBxPLg ixAjXe0O0kSRTzZI7Ew6RCAdZbl/qyCtJr7yqtOY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6196EA1; Thu, 14 Apr 2016 10:25:43 +0200 (CEST) Date: Thu, 14 Apr 2016 10:25:43 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" Subject: Re: EH end encapsulation in 2460bis 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: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:25:49 -0000 On Wed, 13 Apr 2016, Fred Baker (fred) wrote: > At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told > me that they had already vacated the field, leaving me with my pants > around my ankles. Thanks, guys. Just so I understand this 100%. The SR guys no longer want to do SR header insertion and removal when entering/leaving the SR domain? So SR is now only encap of entire packet? Either in a new IP packet or using MPLS? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 14 01:56:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F78D12E4FD for ; Thu, 14 Apr 2016 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 s1AUGjiV0u_2 for ; Thu, 14 Apr 2016 01:56:26 -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 1576112E4F9 for <6man@ietf.org>; Thu, 14 Apr 2016 01:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1157; q=dns/txt; s=iport; t=1460624186; x=1461833786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lV+yASAiull2AblbfMV1f/NgVTmJUYOU8FPvEpKLEVI=; b=g72Sw78kjBJAUJ6BQAemDNqBXuuPO1rHmWESMMrF12SKHjbCHKcrEEKO Wjg8RbCwhwPdDBqYNjMrIBJMCx3BGvNoU2YEbKCzNC433LXRCb+sV/NCt iAS3kEEXn6lia82y66JmUJeshP9QIwK6GEEDqH49IWBR/ghhnWSgL8NDf w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgAJWg9X/4sNJK1egzhTfQa6KgENg?= =?us-ascii?q?XEXC4VsAoE1OBQBAQEBAQEBZSeEQQEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAgQ?= =?us-ascii?q?OBYghCA7COAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdYJWhA8RARyDLYIrB?= =?us-ascii?q?Yd0kBcBjgwKjwaPKAEeAQFCg2dsiEY2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="261348566" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 08:56:25 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3E8uO8U026740 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 08:56:25 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 04:56:24 -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.1104.009; Thu, 14 Apr 2016 04:56:24 -0400 From: "Stefano Previdi (sprevidi)" To: Mikael Abrahamsson Subject: Re: EH end encapsulation in 2460bis Thread-Topic: EH end encapsulation in 2460bis Thread-Index: AQHRliuFefkLuOietEC7/idgLiN9TA== Date: Thu, 14 Apr 2016 08:56:24 +0000 Message-ID: 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.70.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:56:27 -0000 > On Apr 14, 2016, at 10:25 AM, Mikael Abrahamsson wrote= : >=20 > On Wed, 13 Apr 2016, Fred Baker (fred) wrote: >=20 >> At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told= me that they had already vacated the field, leaving me with my pants aroun= d my ankles. Thanks, guys. >=20 > Just so I understand this 100%. The SR guys no longer want to do SR heade= r insertion and removal when entering/leaving the SR domain? current implementations of Segment Routing over IPv6 dataplane (aka: SRv6) = do SRH insertion at ingress of the domain and SRH removal at egress. > So SR is now only encap of entire packet? Either in a new IP packet or us= ing MPLS? not exactly. All SRv6 implementation I know of, do header insertion only. Thanks. s. > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Apr 14 03:00:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCF612DCF3 for ; Thu, 14 Apr 2016 02:59:59 -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, 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 VZMiwVHGXXUs for ; Thu, 14 Apr 2016 02:59:57 -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 8F15012D93A for <6man@ietf.org>; Thu, 14 Apr 2016 02:59:57 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id c4so103272300vkb.3 for <6man@ietf.org>; Thu, 14 Apr 2016 02:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xe6KNcgrbPtZRY3nmmMI86V4py5tcBOeq7wlBeH61Q0=; b=NN9BVeBcR3i+Oh+3x6qs3QrTS2miVZujkZvr9h8huCLRTCcyEEiszw98Mf9F67W2Mj p7Nr/MlB8kq2yGYYHEmTC5FXAULDNeXxG0Pi6Dl1ZrW2hE6qjQqMXNHebCIiOTx5TAka 4C7CWyXYhIvs1VHKSN/LLdUi9djTmfjtYKpor9xUfQ4TDdhf3d80q9rwb9Do1BitCnZS aJXWRx+THt28dEXVa2LrWujNkrd/1FL+0lBfvVZ6wyAnFyxaPZUMBuIAZ8ggQkTPYARM hbA5x3cTSKy4JN/qYmt7NkkUOqUFaRhxBGYE9LSEiNYfZ6MHla+zJRHiiYOwljNk3ymF oRkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xe6KNcgrbPtZRY3nmmMI86V4py5tcBOeq7wlBeH61Q0=; b=Psep1OaCUK3ZS+04+DnIbd6aGLZPS0uUvNEv5lNjaqJOnSjBEekI4C1z6EfYwLK4hr NeVel0zdhf53Z87euSgkG1q/391hATrEAWvheXmq3tZjWK7WaYf9ls7F8r+SNLi9V8nT nUyiKYJ/TONjLS4+c5Dkhe9yXzPsabQ3jxSukDnMxaCHedB4iO+b67UjP4pNxsPU6/AV eqlIkKWvvbjLA98MWSrEawIrd00geSVpj0lDi4c11YhPp2FCnY/excrskRMz0EA7/DRU CB8Pcs9RfgcxTYXevd+L3a1vxa/IIglyWAejrqmbQfItYKhpQRHRf/HWuRmz7q/0eSQh X8+Q== X-Gm-Message-State: AOPr4FVfydhQF/wGVzWm8Pbm7B/mUsWS88NPrXaihy0ACehTdTg5r/teIk7OcVtkngxGhiA2W4zAmhC9Pc3sHA== MIME-Version: 1.0 X-Received: by 10.176.2.49 with SMTP id 46mr7479255uas.39.1460627996608; Thu, 14 Apr 2016 02:59:56 -0700 (PDT) Received: by 10.176.69.6 with HTTP; Thu, 14 Apr 2016 02:59:56 -0700 (PDT) Received: by 10.176.69.6 with HTTP; Thu, 14 Apr 2016 02:59:56 -0700 (PDT) In-Reply-To: <570F50FF.7040504@globis.net> References: <570F50FF.7040504@globis.net> Date: Thu, 14 Apr 2016 19:59:56 +1000 Message-ID: Subject: Re: EH end encapsulation in 2460bis From: Mark Smith To: "Ray Hunter (v6ops)" Content-Type: multipart/alternative; boundary=001a113edbc0e311da05306ef47a Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 09:59:59 -0000 --001a113edbc0e311da05306ef47a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 Apr 2016 6:13 PM, "Ray Hunter (v6ops)" wrote: > > > > Tom Herbert wrote: >> >> Hello, >> >> >From draft-ietf-6man-rfc2460bis-04 >> >> "Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]." >> >> It is unclear to me how/rather IP encapsulation can meet the >> requirements or at least the intent of a node wanting to insert >> extension headers. For instance if a middlebox is presented a packet >> with EHs ABC and it wishes to insert EH X, it's intent might be to >> create a packet with EHs ABXC. I don't see how this can generally be >> expressed with encapsulation. For instance, is expected that there is >> some process of moving/copying certain of the original EHs to the >> outer headers (like HBH, routing)? >> >> Thanks, >> Tom >> >> > A middleware box can't possibly know all the details of the entire downstream topology/MTU limitations/load balancing etc. > > So it would seem to me that choosing for encapsulation implies that there will be another middleware box somewhere further down the path that will perform an inverse de-encapsulation, so that the original packet gets delivered to the final recipient as sent by the sender. That's how transports like MPLS and WAN optimisation work today, and certainly feels like the right thing to do to me. > A insight Brian C. pointed out in the context of the many addresses per host draft is that tunnelling devices are not middle boxes, they're actually hosts, as they're the end points for the IP packets that are created and sent or received and disposed of during the performance of the tunneling function. The payload, which happens to be another IP packet, is the tunnelling application data. Any EHs that are created after the outer IPv6 header and before the payload IPv6 packet are valid by RFC2460bis, because they're being created by the host originating the packet. Regards, Mark. > Otherwise, if an extension header is going to be that valuable to ensure good communications, the source node can insert it itself IMHO. > > My own =E2=82=AC0.02 worth is that inserting/deleting/or otherwise messin= g around with packet headers, just makes operations much more difficult. [written by someone who experienced the horror of L2 bridging FDDI to Ethernet first hand] > > -- > regards, > RayH > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113edbc0e311da05306ef47a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 Apr 2016 6:13 PM, "Ray Hunter (v6ops)" <v6ops@globis.net> wrote:
>
>
>
> Tom Herbert wrote:
>>
>> Hello,
>>
>> >From draft-ietf-6man-rfc2460bis-04
>>
>> "Extension headers must never be inserted by any node other t= han the
>> source of the packet.=C2=A0 IP Encapsulation must be used to meet = any
>> requirement for inserting headers, for example, as defined in
>> [RFC2473]."
>>
>> It is unclear to me how/rather IP encapsulation can meet the
>> requirements or at least the intent of a node wanting to insert >> extension headers. For instance if a middlebox is presented a pack= et
>> with EHs ABC and it wishes to insert EH X, it's intent might b= e to
>> create a packet with EHs ABXC. I don't see how this can genera= lly be
>> expressed with encapsulation. For instance, is expected that there= is
>> some process of moving/copying certain of the original EHs to the<= br> >> outer headers (like HBH, routing)?
>>
>> Thanks,
>> Tom
>>
>>
> A middleware box can't possibly know all the details of the entire= downstream topology/MTU limitations/load balancing etc.
>
> So it would seem to me that choosing for encapsulation implies that th= ere will be another middleware box somewhere further down the path that wil= l perform an inverse de-encapsulation, so that the original packet gets del= ivered to the final recipient as sent by the sender. That's how transpo= rts like MPLS and WAN optimisation work today, and certainly feels like the= right thing to do to me.
>

A insight Brian C. pointed out in the context of the many ad= dresses per host draft is that tunnelling devices are not middle boxes, the= y're actually hosts, as they're the end points for the IP packets t= hat are created and sent or received and disposed of during the performance= of the tunneling function. The payload, which happens to be another IP pac= ket, is the tunnelling application data.

Any EHs that are created after the outer IPv6 header and bef= ore the payload IPv6 packet are valid by RFC2460bis, because they're be= ing created by the host originating the packet.

Regards,
Mark.

> Otherwise, if an extension header is going to be that v= aluable to ensure good communications, the source node can insert it itself= IMHO.
>
> My own =E2=82=AC0.02 worth is that inserting/deleting/or otherwise mes= sing around with packet headers, just makes operations much more difficult.= [written by someone who experienced the horror of L2 bridging FDDI to Ethe= rnet first hand]
>
> --
> regards,
> RayH
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--001a113edbc0e311da05306ef47a-- From nobody Thu Apr 14 03:18:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08F312D0AF for ; Thu, 14 Apr 2016 03:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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.996, 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 3ZpeEGzxH2Vd for ; Thu, 14 Apr 2016 03:18:52 -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 582BE12B005 for <6man@ietf.org>; Thu, 14 Apr 2016 03:18:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 81F52A2; Thu, 14 Apr 2016 12:18:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1460629129; bh=qxTNb17yre9Thqx0pXkqRxtE2k6iF+ixI39rYsJ/+C4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1DVWzV8QltumHjM4mp7bKKvCqKjDkTwqvcdmXUeJbylh8/Xh4yyLalgteNGtCVBPf BlyW4SpFFsR6oSntBmcRNmBs8yAVGcxQHRJeEUF7BHnO7abZgZYKorrfQlB4+hJXuK pKbmZZ2hgPNmW002xh38W8ZYQd1zltuAsRdnTxcU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 76D98A1; Thu, 14 Apr 2016 12:18:49 +0200 (CEST) Date: Thu, 14 Apr 2016 12:18:49 +0200 (CEST) From: Mikael Abrahamsson To: "Stefano Previdi (sprevidi)" Subject: Re: EH end encapsulation in 2460bis 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; format=flowed; charset=US-ASCII Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:18:54 -0000 On Thu, 14 Apr 2016, Stefano Previdi (sprevidi) wrote: > current implementations of Segment Routing over IPv6 dataplane (aka: > SRv6) do SRH insertion at ingress of the domain and SRH removal at > egress. https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-01 4.1. "An SR domain ingress router encapsulating a received IPv6 packet into an outer IPv6 header followed by an SRH." Does this mean the outer header is a new header, and the received IPv6 packet is completely (and unchanged) encapsulated into a new IPv6 header (with DA being the SR exist node) and SRH? So SR is now tunneling only, it's never "take existing received packet IPv6 header, insert SRH after existing received packet header, then insert rest of original packet EH" (which would be header insertion instead of creating a tunnel packet)? The above draft could be a lot clearer, for instance not saying "an outer IPv6 header". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 14 05:23:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652B712E361 for ; Thu, 14 Apr 2016 05:23:01 -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 xLxUSi-VwscY for ; Thu, 14 Apr 2016 05:22:59 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 041E012E354 for ; Thu, 14 Apr 2016 05:22:58 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1aqgIH-003lCC-Ls; Thu, 14 Apr 2016 14:22:47 +0200 Date: Thu, 14 Apr 2016 14:22:45 +0200 From: David Lamparter To: otroan@employees.org Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160414122245.GN518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:23:01 -0000 On Thu, Apr 07, 2016 at 10:27:07AM -0300, otroan@employees.org wrote: > In general I'd prefer that we reuse existing mechanisms for path mtu > discovery, and not invent new ones purely for the case of two directly > connected neighbors. That's actually the crux of it: this isn't Path MTU discovery. The MTU discovered by this mechanism is the first-hop MTU for a lot of paths in case of a router and it's going to be distinct from the final PMTU towards a particular destination. Plus, state on this only ever exists for direct neighbors, not for any random internet host. > Could we make this work by adding the RFC4861 MTU option to NS/NA > messages, and require that PLMTUD probing is used to verify the end to > end MTU. It's not end-to-end MTU... > Then the mechanism used is the same for directly connected neighbors > and off-link neighbors (apart from the initial discovery). Well, it'd be possible to distinguish first-hop failures from failures later in the path, but with a router there's rarely a direct TCP connection to it to do PLMTUD on. Either way this really needs at least different handling from end-to-end MTU in order to not keep probing towards a router whenever a host decides to talk to another destination in the internet. Some first-hop neighbor concept... If probing hosts for each of their addresses can be avoided, that might be useful too, but that's far less of an issue (and harder to do) than not probing routers for every single internet destination. > If we were to invent new probing mechanisms, I would hope we did so > under the PLMTUD (4821) umbrella. Hm. Maybe the draft can be rewritten as extension to 4821, but quite a few things are different with reason -- not sure this is that good of a fit... Cheers, -David > Best regards, > Ole > > > On 06 Apr 2016, at 19:04, David Lamparter wrote: > > > > On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote: > >> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: > >>> On 4/6/16 12:18 PM, David Lamparter wrote: > >>>> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: > >>>> Ok... easy comments/opinions first: > >>>> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to > >>>> piggyback on NUD sounds great, though admittedly I haven't thought it > >>>> through looking for pitfalls. > >>> One issue compared to a dedicate probe is that a NUD (a unicast NS) of > >>> size X wouldn't necessarily result in a unicast NA that is also padded; > >>> perhaps one can add such behavior so that we can get the bidirectional > >>> probe in both directions. > >> > >> That might be (half of) a feature: if the MTU probe is a NS option, and > >> the target host does not support it, we still get a NA reply. That's > >> better than timing out waiting. The downside is that a NA without the > >> "MTU response" option doesn't mean that the host doesn't implement the > >> protocol -- the NA could be in response to something else. > > > > Obvious easy way: have the "ND NODEMTU" option described in draft sec. 5 > > mandatory on all NAs if the host implements the protocol; receipt of any > > NA without the option can then flag the sender as mtu-probe-incapable. > > > > (Not sure if the last paragraph of sec. 9.1 already implies the option > > MUST be put on all NAs and NSs? Certainly needs better wording.) > > > > -David > > > >> That said, I'd expect the probability of a host ignoring a new NS option > >> is much lower than it filtering out unknown new ICMP (sub)types or UDP > >> ports. If that reduces useless probing (or even waiting), I'm all for > >> it. > >> > >> (As I understand it, the draft in no case suggests waiting for the > >> probes to come back, so it's not much of an argument. Might still > >> reduce useless probe traffic?) > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > From nobody Thu Apr 14 05:27:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E812E422 for ; Thu, 14 Apr 2016 05:27: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 S4EzikxR9soy for ; Thu, 14 Apr 2016 05:27:29 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 3FBDD12E3CF for ; Thu, 14 Apr 2016 05:27:29 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1aqgMo-003lIh-Ae; Thu, 14 Apr 2016 14:27:27 +0200 Date: Thu, 14 Apr 2016 14:27:26 +0200 From: David Lamparter To: Sowmini Varadhan Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160414122726.GO518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:27:31 -0000 On Mon, Apr 11, 2016 at 05:18:07AM -0700, Sowmini Varadhan wrote: > On Wed, Apr 6, 2016 at 12:55 PM, Erik Nordmark wrote: > > On 4/6/16 12:18 PM, David Lamparter wrote: > >> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: > >> > >>> I'll be presenting > >>> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on > >>> Wednesday. There are operational considerations here, so I encourage > >>> people to drop in and/or comment on this draft. > >>> > >> Ok... easy comments/opinions first: > >> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to > >> piggyback on NUD sounds great, though admittedly I haven't thought it > >> through looking for pitfalls. > >> > > One issue compared to a dedicate probe is that a NUD (a unicast NS) of > > size X wouldn't necessarily result in a unicast NA that is also padded; > > perhaps one can add such behavior so that we can get the bidirectional > > probe in both directions. > > > there's also the question of what mtu to advertise in the face of > pvlans, when there is a router on a promisc port proxying the NA. A system doing proxy NA is ultimately a router and should be handled as such; i.e. if done "right" there is only one 1:1 relationship for which first-hop MTU discovery is done. > In practice, since a node typically uses a single interface to talk > to multiple onlink neighbors, and jumbo mtu etc is configured per > interface, you would end up getting metered down to the lowest > common denominator for the subnet, right? No, the per-interface configuration is exactly what this draft is trying to work around. Regards, -David From nobody Thu Apr 14 05:30:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6225312E422 for ; Thu, 14 Apr 2016 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 9C1kVPUbQKlw for ; Thu, 14 Apr 2016 05:30:52 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 16B5A12E43B for ; Thu, 14 Apr 2016 05:30:51 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP; 14 Apr 2016 12:30:50 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 4E9B6D7884; Thu, 14 Apr 2016 05:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=VdfHZcHzNfU5SztZ8fv2rCihtkc=; b= RWgjCOqAD1zGeaW4KIFdEyG3SZgcwdCGWpMfZrK+3EOsylqmAsCTq5v//giU+l/S F4GDiARpQJny3sH6zROX9VcR2e8mTuGuy7aGqtIXLRA/IVRe9TxW+m3S7yd8YY7f wUgPWuOeQSs2HF5Q8MX2VUScIkCrqYPMPo8Pq6NKcOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=AWwrZ2QSYh/VzMkvqDqQF/LRlx Uoi9Dw0xzgRHEBsFF8SLTlCqA4riIKpxyZ9dUIY72Xa6hjwJFd4JIAvBS2qDGbt7 WdnY43H3TWOyECMrYZ45OBwTFRwPtrpdXnr631FXvBDqU7NwEQGhN0VoEQqANFph yJh2NgBjMal1O5h8U= Received: from h.hanazo.no (unknown [173.38.220.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CAF15D7883; Thu, 14 Apr 2016 05:30:48 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id 020881461A46; Thu, 14 Apr 2016 14:30:49 +0200 (CEST) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A82067D6-E121-43E2-A266-08C008A0F291"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160414122245.GN518778@eidolon> Date: Thu, 14 Apr 2016 14:30:49 +0200 Message-Id: <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:30:54 -0000 --Apple-Mail=_A82067D6-E121-43E2-A266-08C008A0F291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, >> In general I'd prefer that we reuse existing mechanisms for path mtu >> discovery, and not invent new ones purely for the case of two = directly >> connected neighbors. >=20 > That's actually the crux of it: this isn't Path MTU discovery. The = MTU > discovered by this mechanism is the first-hop MTU for a lot of paths = in > case of a router and it's going to be distinct from the final PMTU > towards a particular destination. Plus, state on this only ever = exists > for direct neighbors, not for any random internet host. why couldn't it be done as end-to-end MTU? the directly connected mechanism would be just to give a hint that there = might be nodes here capable of a higher MTU. then do normal MTU probing = / detection. what would be gain be to have a specific protocol to probe directly = connected neighbors? Best, Ole >=20 >> Could we make this work by adding the RFC4861 MTU option to NS/NA >> messages, and require that PLMTUD probing is used to verify the end = to >> end MTU. >=20 > It's not end-to-end MTU... >=20 >> Then the mechanism used is the same for directly connected neighbors >> and off-link neighbors (apart from the initial discovery). >=20 > Well, it'd be possible to distinguish first-hop failures from failures > later in the path, but with a router there's rarely a direct TCP > connection to it to do PLMTUD on. >=20 > Either way this really needs at least different handling from = end-to-end > MTU in order to not keep probing towards a router whenever a host > decides to talk to another destination in the internet. Some = first-hop > neighbor concept... >=20 > If probing hosts for each of their addresses can be avoided, that = might > be useful too, but that's far less of an issue (and harder to do) than > not probing routers for every single internet destination. >=20 >> If we were to invent new probing mechanisms, I would hope we did so >> under the PLMTUD (4821) umbrella. >=20 > Hm. Maybe the draft can be rewritten as extension to 4821, but quite = a > few things are different with reason -- not sure this is that good of = a > fit... >=20 > Cheers, >=20 > -David >=20 >> Best regards, >> Ole >>=20 >>> On 06 Apr 2016, at 19:04, David Lamparter = wrote: >>>=20 >>> On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote: >>>> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: >>>>> On 4/6/16 12:18 PM, David Lamparter wrote: >>>>>> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson = wrote: >>>>>> Ok... easy comments/opinions first: >>>>>> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion = to >>>>>> piggyback on NUD sounds great, though admittedly I haven't = thought it >>>>>> through looking for pitfalls. >>>>> One issue compared to a dedicate probe is that a NUD (a unicast = NS) of >>>>> size X wouldn't necessarily result in a unicast NA that is also = padded; >>>>> perhaps one can add such behavior so that we can get the = bidirectional >>>>> probe in both directions. >>>>=20 >>>> That might be (half of) a feature: if the MTU probe is a NS option, = and >>>> the target host does not support it, we still get a NA reply. = That's >>>> better than timing out waiting. The downside is that a NA without = the >>>> "MTU response" option doesn't mean that the host doesn't implement = the >>>> protocol -- the NA could be in response to something else. >>>=20 >>> Obvious easy way: have the "ND NODEMTU" option described in draft = sec. 5 >>> mandatory on all NAs if the host implements the protocol; receipt of = any >>> NA without the option can then flag the sender as = mtu-probe-incapable. >>>=20 >>> (Not sure if the last paragraph of sec. 9.1 already implies the = option >>> MUST be put on all NAs and NSs? Certainly needs better wording.) >>>=20 >>> -David >>>=20 >>>> That said, I'd expect the probability of a host ignoring a new NS = option >>>> is much lower than it filtering out unknown new ICMP (sub)types or = UDP >>>> ports. If that reduces useless probing (or even waiting), I'm all = for >>>> it. >>>>=20 >>>> (As I understand it, the draft in no case suggests waiting for the >>>> probes to come back, so it's not much of an argument. Might still >>>> reduce useless probe traffic?) >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 --Apple-Mail=_A82067D6-E121-43E2-A266-08C008A0F291 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXD415AAoJEL7aWKiYQt92lP0QALQNagb904i1qtln+C8MTgjO 3hczccghUmeRZGLHM6sgsw9jX2N/PlXVNr++vZsFEN7zFCETaXMLu7KDcgVR/NVm 02wdbkPW7yamruyUQJ6Wh1sAXbiRyZCQ6gApsHybQMB6Gx6HQ6qAS81XMFauk2RK 4mqk2sJCQglupV37sJ/WGV+6jcFQr0hkYWdRma1pNGD90r2o2L8CTP2szYK/ms/l jvygpsBVWz1tgCszUwCzMvGElXnCxHt5oLCo0qCjznRHur7JYQ62yttWkDgGhWMK rsgmgItjo1P5CGw3PYBfRj7Lk0t2PPqO3wxVp49a+G3JC6dd920l5OKJ315hy0SY lrzx3QYkYxB9hxXB8He5vMZRATP5VjJSVlExtpK6zREX3BSShQ+89JwRVGMdMZXZ EVGuZyiIwlBsyj6zCEdo490kRIniqUAIbwsJCMSELEn6cXpByYtZkeg+8bVHJNym 8jEsGCVL1aF3jW7RNmjSPekXQGTTFokZ4eUbaatS0N32FsdGbzukrjFUULS5wLkT rYdviQSW6Mu0r0bVer35kPSiPAAvoYGw58dJpxyQ2BowhIgbbkD4CTmBlWY/TSxP +EOQ7IpT9rgwDb1/d6M4n9pcWFatOQ9GX5bltwj1X6QqJC1qxjGJHayMQCzdBQdC EydV1NM250KHQZaSs5LC =NF5O -----END PGP SIGNATURE----- --Apple-Mail=_A82067D6-E121-43E2-A266-08C008A0F291-- From nobody Thu Apr 14 05:48:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD1B12DFBF for ; Thu, 14 Apr 2016 05:48:16 -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 yNofU3I-JEAJ for ; Thu, 14 Apr 2016 05:48:15 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 410D812DF32 for ; Thu, 14 Apr 2016 05:48:15 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1aqggp-003log-UQ; Thu, 14 Apr 2016 14:48:09 +0200 Date: Thu, 14 Apr 2016 14:48:07 +0200 From: David Lamparter To: otroan@employees.org Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160414124807.GP518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:48:16 -0000 On Thu, Apr 14, 2016 at 02:30:49PM +0200, otroan@employees.org wrote: > David, > > >> In general I'd prefer that we reuse existing mechanisms for path mtu > >> discovery, and not invent new ones purely for the case of two directly > >> connected neighbors. > > > > That's actually the crux of it: this isn't Path MTU discovery. The MTU > > discovered by this mechanism is the first-hop MTU for a lot of paths in > > case of a router and it's going to be distinct from the final PMTU > > towards a particular destination. Plus, state on this only ever exists > > for direct neighbors, not for any random internet host. > > why couldn't it be done as end-to-end MTU? > > the directly connected mechanism would be just to give a hint that > there might be nodes here capable of a higher MTU. then do normal MTU > probing / detection. > > what would be gain be to have a specific protocol to probe directly > connected neighbors? It can: - work (pro-)actively and independent of higher-layer protocols, establishing MTU once - contain the different logic to understand that the router's MTU is the upper cap for all destinations behind that router - contain the different probing parameters (being more aggressive) that are appropriate for a local network - optionally carry extra information to reuse probing results across different addresses that a host has on a segment I suppose this can be achieved by using a specialized version of 4821 on the link... something like this: - host does NS as usual, or catches unsolicited NA - NA contains new "MTU discovery" option with contents: - indication of capability of first-hop MTU discovery - known maximum MRU of NA's sender (i.e. upper limit) - link-local address(?) + TCP port number(?) for PLMTUD probing - host establishes one or more TCP sessions to that port with the express and only purpose of probing MTU (may as well do it on an existing TCP session if one exists) - PLMTUD switches into some "first-hop" special mode (lower timers, parallel operation, different values) to establish and store the value with proper semantics (router case) Is that what you have in mind? -David From nobody Thu Apr 14 06:05:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B685812D6B1 for ; Thu, 14 Apr 2016 06:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 lGjIrQHS5S5d for ; Thu, 14 Apr 2016 06:05:16 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 56E8D12D641 for ; Thu, 14 Apr 2016 06:05:16 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP; 14 Apr 2016 13:05:15 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8BAD3D7882; Thu, 14 Apr 2016 06:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=TqEMMWu47/rblqi2wwVDoKygH9M=; b= ijtcO+63Fe3qnBGB5hMVY/fJyufGuyx9LWJXUf/uHqmHPIS5pWejG9LSqYGJI7aI vi0MkxdLyaqFpTDFBk6twKgB91vdMkVluFMhHaW+ZWkkd/YPE7bkXK/Ulwsa3VwZ 0iY0VlGaAdmvLAAH9wPTPsH3LsExUeaWuuEcspndHlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=nJnDQZo4yVkz4BlaUb5LVYakoP ganrhJ68Y504uHz5zdcWqgIzioqWBuV9IKWhN237E/MPy8aUSQeVXWUO0O1/0+Mu ihgO37RWOeUK3Mv2QZuYKy6LBO6Bjgo48Lwb/dxh8FKJ5nmeDzuBx6KmRTOvfJwO No3Te/Ab9cHDLQypQ= Received: from h.hanazo.no (unknown [173.38.220.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 235F1D7886; Thu, 14 Apr 2016 06:05:14 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id C38E214620A0; Thu, 14 Apr 2016 15:05:12 +0200 (CEST) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AC63ADB5-F4D0-4458-972F-AFA7F3E4CED2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160414124807.GP518778@eidolon> Date: Thu, 14 Apr 2016 15:05:11 +0200 Message-Id: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> <20160414124807.GP518778@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:05:17 -0000 --Apple-Mail=_AC63ADB5-F4D0-4458-972F-AFA7F3E4CED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David, >> why couldn't it be done as end-to-end MTU? >>=20 >> the directly connected mechanism would be just to give a hint that >> there might be nodes here capable of a higher MTU. then do normal MTU >> probing / detection. >>=20 >> what would be gain be to have a specific protocol to probe directly >> connected neighbors? >=20 > It can: > - work (pro-)actively and independent of higher-layer protocols, > establishing MTU once to a large extent we have failed at doing MTU discovery at the network = layer. too hard, couldn't do it, let's make it someone else's problem. ;-) transport or application that is. > - contain the different logic to understand that the router's MTU is = the > upper cap for all destinations behind that router > - contain the different probing parameters (being more aggressive) = that > are appropriate for a local network > - optionally carry extra information to reuse probing results across > different addresses that a host has on a segment >=20 > I suppose this can be achieved by using a specialized version of 4821 = on > the link... something like this: >=20 > - host does NS as usual, or catches unsolicited NA > - NA contains new "MTU discovery" option with contents: > - indication of capability of first-hop MTU discovery > - known maximum MRU of NA's sender (i.e. upper limit) > - link-local address(?) + TCP port number(?) for PLMTUD probing > - host establishes one or more TCP sessions to that port with the > express and only purpose of probing MTU > (may as well do it on an existing TCP session if one exists) > - PLMTUD switches into some "first-hop" special mode (lower timers, > parallel operation, different values) to establish and store the = value > with proper semantics (router case) >=20 > Is that what you have in mind? I was thinking of something much simpler. the NS/NA MTU option triggers the stack (transport / application) to use = packets up to that MTU. the transport or application has to do normal PLMTUD. think of it as if you had a p2p link to the neighbor and that the = interface MTU was set to whatever you received in the MTU option from = that neighbour. an on-link router already advertises an MTU in an RA. I'm not sure if it = would make sense if it advertised per neighbor MTU options, and how = those should be interpreted. cheers, Ole --Apple-Mail=_AC63ADB5-F4D0-4458-972F-AFA7F3E4CED2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXD5WIAAoJEL7aWKiYQt92CYkP/jlGqowXWp9GMYmm7/kdTsxf cMzs6WPIAMzpzJ9nVVHUk5qvYfp8hDwC1z82cXd3USgpJdRuF0mYB91/eNv5GzWm btHLVyqP1DGK4AWV38T/vTJSvY2gD71tXCxhC3iG61LvflW4lsWMjzk4uJfTMoJc 60ZfTwVHeTmOx8RTTUNueI01JPsBaJMYMAVldeyGKv853AC4i3sNYpmRYIKsKQYl n4idSgjRyqQY3CaKcjq3U9EVt3pOf7MtQDFaK32ds5fNZYnswwOlEMDOkdB1mD8u Ks+zkiDQs6RVcJJDiNJ3U/6IWfz/wKJ9Ln+AlwhyfUVG9upsEt/aQKlGMbWS7XwX P7vVcb40dppCE2D+QldhoJokBhe5Q1lgzuiprujiLo2RLPPC8O32lHVKzX+RUxLH stNjIrSw7ytYqCXaC1dx2FyzwZjMB1+KXZ6Fp74sy9uQnr1BY46qw5Gu7w+7BPSr jH5PCgPPpWI16u8Kr9RdwFiayrXMpUZqP/FeM/XslhS6QuWet7I/CqzAmFNsLTgG OR/Yn1ZqW7C9jefQY1yK0xCxJ2BXOrl4VhzM7Ts5jpK2f5EQ032HhLAfD/6XBrnC An9a3DttwrJUXiD9NROLL+I6J7CFCFWlVJJdBHmuNnyBXHOcU68Z5TMzTgrkm5FX e8I46qQa6ttAHEgG600l =sraa -----END PGP SIGNATURE----- --Apple-Mail=_AC63ADB5-F4D0-4458-972F-AFA7F3E4CED2-- From nobody Thu Apr 14 06:20:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5559C12E052 for ; Thu, 14 Apr 2016 06:20:01 -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 KxLHNjlh5IDK for ; Thu, 14 Apr 2016 06:20:00 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 A487912E042 for ; Thu, 14 Apr 2016 06:19:51 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1aqhBQ-003mbU-LY; Thu, 14 Apr 2016 15:19:45 +0200 Date: Thu, 14 Apr 2016 15:19:44 +0200 From: David Lamparter To: otroan@employees.org Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160414131944.GR518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> <20160414124807.GP518778@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:20:01 -0000 On Thu, Apr 14, 2016 at 03:05:11PM +0200, otroan@employees.org wrote: > >> what would be gain be to have a specific protocol to probe directly > >> connected neighbors? > > > > It can: > > - work (pro-)actively and independent of higher-layer protocols, > > establishing MTU once > > to a large extent we have failed at doing MTU discovery at the network layer. > too hard, couldn't do it, let's make it someone else's problem. ;-) > transport or application that is. Might be either hope or naïvety, but I don't think we've failed (or even tried) yet at the 1-hop 0-router case :). There are way less pesky ICMPv6-breaking devices in the middle... > > - contain the different logic to understand that the router's MTU is the > > upper cap for all destinations behind that router > > - contain the different probing parameters (being more aggressive) that > > are appropriate for a local network > > - optionally carry extra information to reuse probing results across > > different addresses that a host has on a segment > > > > I suppose this can be achieved by using a specialized version of 4821 on > > the link... something like this: > > > > - host does NS as usual, or catches unsolicited NA > > - NA contains new "MTU discovery" option with contents: > > - indication of capability of first-hop MTU discovery > > - known maximum MRU of NA's sender (i.e. upper limit) > > - link-local address(?) + TCP port number(?) for PLMTUD probing > > - host establishes one or more TCP sessions to that port with the > > express and only purpose of probing MTU > > (may as well do it on an existing TCP session if one exists) > > - PLMTUD switches into some "first-hop" special mode (lower timers, > > parallel operation, different values) to establish and store the value > > with proper semantics (router case) > > > > Is that what you have in mind? > > I was thinking of something much simpler. > the NS/NA MTU option triggers the stack (transport / application) to > use packets up to that MTU. the transport or application has to do > normal PLMTUD. > > think of it as if you had a p2p link to the neighbor and that the > interface MTU was set to whatever you received in the MTU option from > that neighbour. I think the failure modes of that are way worse than with a dedicated first-hop approach, especially for routers (interference from congestion further down) but also for hosts (no parallel probing, and still need special-casing to get more aggressive behaviour). (cont'd below) > an on-link router already advertises an MTU in an RA. I'm not sure if > it would make sense if it advertised per neighbor MTU options, and how > those should be interpreted. The MTU advertised in the RA is for the link, not for the router. In particular, even when doing higher first-hop MTUs, this is the value for all multicast packets. If the router advertises a higher value through a separate new option, the failure modes of that are very non-graceful: a "non-jumbo" ethernet switch in the middle causes every individual destination's PLMTUD to fail independently, without the system having any chance to detect it as an issue towards the router. -David From nobody Thu Apr 14 06:22:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B012E077 for ; Thu, 14 Apr 2016 06:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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.996, 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 zhZQt5TYMuEd for ; Thu, 14 Apr 2016 06:22:13 -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 885F712E0ED for ; Thu, 14 Apr 2016 06:22:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 89B7EA3; Thu, 14 Apr 2016 15:22:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1460640131; bh=SheMKr2KmbmdD6KkVjn/HDUXXAmOWeW+vCsbgRBqUZg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hOUx7Fl2jYmCqNojq2PsYki8VfvuNbPBSNZZveIUOtSsO9b4ul3VUW7Lw62ToLHPL TzeiGgtKPhrfYlW5Qhgng4SplFR2FK2jE1j+iWnYlnt3TNsOTh9+yTJaFP2uFnvkFS q0LV0rkV41XY7VQr8f9juETSt8T/B7UtCltUwGNU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 85CDCA1; Thu, 14 Apr 2016 15:22:11 +0200 (CEST) Date: Thu, 14 Apr 2016 15:22:11 +0200 (CEST) From: Mikael Abrahamsson To: David Lamparter Subject: Re: draft-van-beijnum-multi-mtu-05.txt In-Reply-To: <20160414122245.GN518778@eidolon> Message-ID: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:22:16 -0000 On Thu, 14 Apr 2016, David Lamparter wrote: > That's actually the crux of it: this isn't Path MTU discovery. The MTU > discovered by this mechanism is the first-hop MTU for a lot of paths in > case of a router and it's going to be distinct from the final PMTU > towards a particular destination. Plus, state on this only ever exists > for direct neighbors, not for any random internet host. I don't believe the draft says this. What it does is discover the MTU to an IPv6 address on the same LAN. To then infer that any packets sent VIA this node, is not something the draft (at least explicitly) says. The case could be made to say that any packets sent via the "discovered-to-support-larger-MTU-router" could use this higher MTU, but that's something that isn't obvious, and I think it's up for discussion. So if I have this network: H1 - R1 - R2 - Internet If R1 announces in RA to the LAN where H1 is, that MTU is 1500, but H1 but R1 also sends HintMTU of 9180, should the default route H1 installs based on this RA and points to R1 also have this higher MTU? Maybe. Maybe not. As I said in the session, I would like more fine granular MTU, so that I can have separate MTU for separate entities. For instance, if I know that most of my devices in my home support 9180, but none of my Internet connections do (they only support 1500), then I would like H1 to have this in its routing table: Local /64 HintMTU 9180 RIO with home /56 HintMTU 9180 RIO with ::/0 with HintMTU 1500 Because of this, H1 wouldn't need to spend a lot of time trying to send packets to the Internet with larger MTU than 1500. This would however require that we allow MTUs tied to not only PIO, but also RIO. I still don't know what to do about the implicit default route that one points to anyone one sees an RA from. Personally I consider this design of the IPv6 protocol to be unfortunate. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 14 06:36:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E612E203 for ; Thu, 14 Apr 2016 06:36:03 -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 MZZgFbLpx5aA for ; Thu, 14 Apr 2016 06:36:02 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 00DAF12E1F9 for ; Thu, 14 Apr 2016 06:36:02 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1aqhQy-003myU-6v; Thu, 14 Apr 2016 15:35:48 +0200 Date: Thu, 14 Apr 2016 15:35:48 +0200 From: David Lamparter To: Mikael Abrahamsson Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160414133548.GS518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:36:03 -0000 On Thu, Apr 14, 2016 at 03:22:11PM +0200, Mikael Abrahamsson wrote: > On Thu, 14 Apr 2016, David Lamparter wrote: > > > That's actually the crux of it: this isn't Path MTU discovery. The MTU > > discovered by this mechanism is the first-hop MTU for a lot of paths in > > case of a router and it's going to be distinct from the final PMTU > > towards a particular destination. Plus, state on this only ever exists > > for direct neighbors, not for any random internet host. > > I don't believe the draft says this. It doesn't, but by tracking neighbors as pairs of (L2 address, IP version) it behaves pretty much like that. > What it does is discover the MTU to an IPv6 address on the same LAN. To > then infer that any packets sent VIA this node, is not something the draft > (at least explicitly) says. The case could be made to say that any packets > sent via the "discovered-to-support-larger-MTU-router" could use this > higher MTU, but that's something that isn't obvious, and I think it's up > for discussion. > > So if I have this network: > > H1 - R1 - R2 - Internet > > If R1 announces in RA to the LAN where H1 is, that MTU is 1500, but H1 but > R1 also sends HintMTU of 9180, should the default route H1 installs > based on this RA and points to R1 also have this higher MTU? Maybe. Maybe > not. As mentioned in my other mail: The RA's MTU is for the link, not for the router. There is no MTU value for the route or router itself; and since the RA MTU value doesn't provide any number and we're bumping the "effective" interface MTU towards the router, that does pretty much imply the route to R2/internet inherits that value. > As I said in the session, I would like more fine granular MTU, so that I > can have separate MTU for separate entities. Well - host-wise, doing PLMTUD as Ole suggest would probably work out fine. Need routers to make the problem interesting ;) > For instance, if I know that most of my devices in my home support 9180, > but none of my Internet connections do (they only support 1500), then I > would like H1 to have this in its routing table: > > Local /64 HintMTU 9180 > RIO with home /56 HintMTU 9180 > RIO with ::/0 with HintMTU 1500 > > Because of this, H1 wouldn't need to spend a lot of time trying to send > packets to the Internet with larger MTU than 1500. > > This would however require that we allow MTUs tied to not only PIO, but > also RIO. I still don't know what to do about the implicit default route > that one points to anyone one sees an RA from. Personally I consider this > design of the IPv6 protocol to be unfortunate. Hrm... indeed an annoying problem... -David From nobody Thu Apr 14 08:01:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0750012E4F2 for ; Thu, 14 Apr 2016 08:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 6_Tr1cv6zUY6 for ; Thu, 14 Apr 2016 08:01:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06BC12E4AE for <6man@ietf.org>; Thu, 14 Apr 2016 08:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1460646109; x=1461855709; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rR755sZ1Pg+AoeG+ig5TIT1svWo86wk1t5SDwXSGHPU=; b=H/IJQxQqNVJYlm1V2nm9vpvMH8OCjt/hziwzjX9JIzdHgjSR3R7SVWEh TpR7mqgK/JG6NCXxK9j59lDbYAEsP5GWfzLxKmTo2tkGb8PCpl067vq4w +YMyFLSv1aMX+Mi2c27yxwn7fZML5MpxS4UdmYcrgzb7+uGKk9UMqsZT2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgBtsA9X/5pdJa1egzhTfQa6KQENg?= =?us-ascii?q?XEihWwCgTg4FAEBAQEBAQFlJ4RBAQEBAwE6PwULAgEIDgoeEDIlAgQOBYghCA7?= =?us-ascii?q?CUAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdQiCToQPEQEcgy2CKwWYCwGFd?= =?us-ascii?q?ogWjxCPKAEeAQFCg2dsiBI2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="93751520" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 15:01:48 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3EF1miX026777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 15:01:48 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 11:01:47 -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.1104.009; Thu, 14 Apr 2016 11:01:47 -0400 From: "Stefano Previdi (sprevidi)" To: Mikael Abrahamsson Subject: Re: EH end encapsulation in 2460bis Thread-Topic: EH end encapsulation in 2460bis Thread-Index: AQHRljcJefkLuOietEC7/idgLiN9TJ+J07+A Date: Thu, 14 Apr 2016 15:01:47 +0000 Message-ID: <81CBA2D4-28E1-4E4E-8364-6276B6704234@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.70.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EACF77601544940B2FAA2CC1FE82B66@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:01:53 -0000 > On Apr 14, 2016, at 12:18 PM, Mikael Abrahamsson wrote= : >=20 > On Thu, 14 Apr 2016, Stefano Previdi (sprevidi) wrote: >=20 >> current implementations of Segment Routing over IPv6 dataplane (aka: SRv= 6) do SRH insertion at ingress of the domain and SRH removal at egress. >=20 > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-01 >=20 > 4.1. >=20 > "An SR domain ingress router encapsulating a received IPv6 packet > into an outer IPv6 header followed by an SRH." >=20 > Does this mean the outer header is a new header, and the received IPv6 pa= cket is completely (and unchanged) encapsulated into a new IPv6 header (wit= h DA being the SR exist node) and SRH? yes. > So SR is now tunneling only, it's never "take existing received packet IP= v6 header, insert SRH after existing received packet header, then insert re= st of original packet EH" (which would be header insertion instead of creat= ing a tunnel packet)? it is correct. The current draft assumes only encapsulation. However, this does not reflect the reality o implementation and deployments= where the SRH is in fact inserted after the received ipv6 header. s. > The above draft could be a lot clearer, for instance not saying "an outer= IPv6 header". >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 14 08:14:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8043312D717 for ; Thu, 14 Apr 2016 08:14: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, HTML_MESSAGE=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 lV7dzhLfKnSS for ; Thu, 14 Apr 2016 08:14:43 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96C12B004 for <6man@ietf.org>; Thu, 14 Apr 2016 08:14:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1CB4640356; Thu, 14 Apr 2016 17:14:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QPzSa5SzRSn; Thu, 14 Apr 2016 17:14:39 +0200 (CEST) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3463640167; Thu, 14 Apr 2016 17:14:39 +0200 (CEST) Message-ID: <570FB3E0.1080708@globis.net> Date: Thu, 14 Apr 2016 17:14:40 +0200 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mark Smith Subject: Re: EH end encapsulation in 2460bis References: <570F50FF.7040504@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080807020501050409070504" Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:14:46 -0000 This is a multi-part message in MIME format. --------------080807020501050409070504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > Mark Smith > 14 Apr 2016 11:59 > > > On 14 Apr 2016 6:13 PM, "Ray Hunter (v6ops)" > wrote: > > > > > > > > Tom Herbert wrote: > >> > >> Hello, > >> > >> >From draft-ietf-6man-rfc2460bis-04 > >> > >> "Extension headers must never be inserted by any node other than the > >> source of the packet. IP Encapsulation must be used to meet any > >> requirement for inserting headers, for example, as defined in > >> [RFC2473]." > >> > >> It is unclear to me how/rather IP encapsulation can meet the > >> requirements or at least the intent of a node wanting to insert > >> extension headers. For instance if a middlebox is presented a packet > >> with EHs ABC and it wishes to insert EH X, it's intent might be to > >> create a packet with EHs ABXC. I don't see how this can generally be > >> expressed with encapsulation. For instance, is expected that there is > >> some process of moving/copying certain of the original EHs to the > >> outer headers (like HBH, routing)? > >> > >> Thanks, > >> Tom > >> > >> > > A middleware box can't possibly know all the details of the entire > downstream topology/MTU limitations/load balancing etc. > > > > So it would seem to me that choosing for encapsulation implies that > there will be another middleware box somewhere further down the path > that will perform an inverse de-encapsulation, so that the original > packet gets delivered to the final recipient as sent by the sender. > That's how transports like MPLS and WAN optimisation work today, and > certainly feels like the right thing to do to me. > > > > A insight Brian C. pointed out in the context of the many addresses > per host draft is that tunnelling devices are not middle boxes, > they're actually hosts, as they're the end points for the IP packets > that are created and sent or received and disposed of during the > performance of the tunneling function. The payload, which happens to > be another IP packet, is the tunnelling application data. > > Any EHs that are created after the outer IPv6 header and before the > payload IPv6 packet are valid by RFC2460bis, because they're being > created by the host originating the packet. > > Regards, > Mark. > I agree with that. An IPv6 in IPv6 tunnel could also just as well be considered a special case of what I suggested above for middleware boxes. However, if you're going to do that, you're probably going to want to anyway re-use an existing mechanism like GRE RFC2784, or Generic Packet Tunneling of IPv6 in IPv6 RFC2473. In any case, a tunnel always has at least one peer end point, where the original packet is de-encapsulated back to its original form as sent by the original sender (without any additional extension headers). I think Fred pointed out the danger of mixing the semantics of "payload" and "encapsulation" rather nicely: any leaks between the two can create nasty side affects. > > > Otherwise, if an extension header is going to be that valuable to > ensure good communications, the source node can insert it itself IMHO. > > > > My own €0.02 worth is that inserting/deleting/or otherwise messing > around with packet headers, just makes operations much more difficult. > [written by someone who experienced the horror of L2 bridging FDDI to > Ethernet first hand] > > > > -- > > regards, > > RayH > > > -- regards, RayH --------------080807020501050409070504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

14 Apr 2016 11:59


On 14 Apr 2016 6:13 PM, "Ray Hunter (v6ops)" <v6ops@globis.net> wrote:
>
>
>
> Tom Herbert wrote:
>>
>> Hello,
>>
>> >From draft-ietf-6man-rfc2460bis-04
>>
>> "Extension headers must never be inserted by any node other than the
>> source of the packet.  IP Encapsulation must be used to meet any
>> requirement for inserting headers, for example, as defined in
>> [RFC2473]."
>>
>> It is unclear to me how/rather IP encapsulation can meet the
>> requirements or at least the intent of a node wanting to insert
>> extension headers. For instance if a middlebox is presented a packet
>> with EHs ABC and it wishes to insert EH X, it's intent might be to
>> create a packet with EHs ABXC. I don't see how this can generally be
>> expressed with encapsulation. For instance, is expected that there is
>> some process of moving/copying certain of the original EHs to the
>> outer headers (like HBH, routing)?
>>
>> Thanks,
>> Tom
>>
>>
> A middleware box can't possibly know all the details of the entire downstream topology/MTU limitations/load balancing etc.
>
> So it would seem to me that choosing for encapsulation implies that there will be another middleware box somewhere further down the path that will perform an inverse de-encapsulation, so that the original packet gets delivered to the final recipient as sent by the sender. That's how transports like MPLS and WAN optimisation work today, and certainly feels like the right thing to do to me.
>

A insight Brian C. pointed out in the context of the many addresses per host draft is that tunnelling devices are not middle boxes, they're actually hosts, as they're the end points for the IP packets that are created and sent or received and disposed of during the performance of the tunneling function. The payload, which happens to be another IP packet, is the tunnelling application data.

Any EHs that are created after the outer IPv6 header and before the payload IPv6 packet are valid by RFC2460bis, because they're being created by the host originating the packet.

Regards,
Mark.

I agree with that.

An IPv6 in IPv6 tunnel could also just as well be considered a special case of what I suggested above for middleware boxes.

However, if you're going to do that, you're probably going to want to anyway re-use an existing mechanism like GRE RFC2784, or Generic Packet Tunneling of IPv6 in IPv6 RFC2473.

In any case, a tunnel always has at least one peer end point, where the original packet is de-encapsulated back to its original form as sent by the original sender (without any additional extension headers).

I think Fred pointed out the danger of mixing the semantics of "payload" and "encapsulation" rather nicely: any leaks between the two can create nasty side affects.

> Otherwise, if an extension header is going to be that valuable to ensure good communications, the source node can insert it itself IMHO.
>
> My own €0.02 worth is that inserting/deleting/or otherwise messing around with packet headers, just makes operations much more difficult. [written by someone who experienced the horror of L2 bridging FDDI to Ethernet first hand]
>
> --
> regards,
> RayH
>


--
regards,
RayH
--------------080807020501050409070504-- From nobody Thu Apr 14 08:28:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FD812E207 for ; Thu, 14 Apr 2016 08:28:54 -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 yIbacfytI3MA for ; Thu, 14 Apr 2016 08:28:53 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 DA50812DD27 for <6man@ietf.org>; Thu, 14 Apr 2016 08:28:52 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id f1so150935643igr.1 for <6man@ietf.org>; Thu, 14 Apr 2016 08:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=i8JPSQ5YEXENTTOIjSatsJzQnXKVxh7kggkjlNILAnA=; b=PfQq2Dq95M1RFIKor1WlUeOiXeNjVQ/Eh4+xDehAABops3ACAhh5KwRNa2Mb613CTF StAf9KA0U1DuZUHXNG28wvdC9i1f8OzfJmXfDwfRlESYe2/qDEO517Cf1QISCBmhq/vc CZhRUtez5UpFICXdwgssIAk3b2X3VD1bzI+RoxdFU4Unvj8i0NHgwF9k4FXTybVfqfQ8 kFH2uHWvWkMQZ7tS19SAotFyVrIBZQo3vp6BZUSrNoZHuTBgZhN+YYdoIbPMV+rI6q1X pmt+AszKYEmWAe5L23i6SOCKhh2FklnsmFABhHnFFC0VHwbIeRltP+mGpH7atYRFhVA1 PuPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=i8JPSQ5YEXENTTOIjSatsJzQnXKVxh7kggkjlNILAnA=; b=OBN33XQKQE6kXNgeGJQMsko34vQz4pN69QiuEIHPWNbqGny1E5n3cH8hx7PTi3j7nW 2jP12pmHmY4bFO/rH4CGmjlf9vNq1SDuYqvSSLmPaTWbrJbdrOvF3s/i4X6nm7L6J9hI 06EDU53i2qXKB0iQG37t22VKluq6rnu2EZy3HLxLdV2yYz7BS3b9KB3pa3vMH0ssKh+B im1r/syJdatY64zI7ozRBuuJKsZcEWZnFHrhIhXPaS83LbV0iLBsDAICPyfMkbkFHo7F d0MawDFq0Euagg2We8AxrpUxrWON5owKQM2hhF86qLv8mAopoimIxBqhsFezlrULH3Mj Rd2w== X-Gm-Message-State: AOPr4FWcjJFuqpQmdDByXRfsShf5ZV4V0ZdfpfjruVptaZjyzkzRID7VrZlei3x4hR92SQ== X-Received: by 10.50.119.131 with SMTP id ku3mr16181823igb.75.1460647732107; Thu, 14 Apr 2016 08:28:52 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:199e:eef:e13e:946a? ([2601:647:4d00:abf0:199e:eef:e13e:946a]) by smtp.gmail.com with ESMTPSA id s18sm3298441igr.12.2016.04.14.08.28.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Apr 2016 08:28:51 -0700 (PDT) Subject: Re: Proposed RFC 1981bis clarification regarding Hop Limit decrement being orthogonal Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FC289929-410C-48C8-9C9F-730C842948C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 14 Apr 2016 08:28:48 -0700 Message-Id: <4B059A7B-5743-4A5C-80FF-ADCA9C0D9CD8@gmail.com> References: To: Dave Thaler X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Pascal Thubert \(pthubert\)" , "6man@ietf.org" <6man@ietf.org>, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:28:54 -0000 --Apple-Mail=_FC289929-410C-48C8-9C9F-730C842948C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dave, OK, I will included it in the next update. It is a small clarification. Bob > On Apr 13, 2016, at 3:45 PM, Dave Thaler = wrote: >=20 > I certainly believe that the clarification is needed. I talked to = someone at IETF > who was very surprised when I told them there was no such restriction. > I forget who it was offhand (maybe someone reading this thread), but = the context > was around links with different MTUs to different on-link destinations = (e.g., > different segments with different MTUs). >=20 > Dave >=20 >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >> Sent: Wednesday, April 13, 2016 3:28 PM >> To: Dave Thaler >> Cc: Bob Hinden ; Pascal Thubert (pthubert) >> ; 6man@ietf.org >> Subject: Re: Proposed RFC 1981bis clarification regarding Hop Limit >> decrement being orthogonal >>=20 >> Dave, >>=20 >>> On Apr 6, 2016, at 7:44 AM, Dave Thaler = wrote: >>>=20 >>> Yes, it refers to the node, and good grammatical point. So to take = your >> feedback in a different spot: >>>=20 >>> NEW: If any of the packets sent on that path are too large to be = forwarded >>> NEW: by some node (regardless of whether it decrements the Hop = Limit) >> along the path, that node will discard them and return >>> NEW: ICMPv6 Packet Too Big messages [ICMPv6]. >>>=20 >>> I.e. moved it up to right after the first existing use of = =E2=80=9Cnode=E2=80=9D. >>=20 >> I am not convinced the original text needs to change. It doesn=E2=80=99= t limit the >> discarding and sending ICMPv6 PTB only to nodes that decrement the = hope >> limit. >>=20 >> However, if there are folks who read the text as required the = decrement >> action, I am OK with the clarification you propose. >>=20 >> Bob >>=20 >>=20 >>=20 >>>=20 >>> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >>> Sent: Wednesday, April 6, 2016 11:42 AM >>> To: Dave Thaler ; 6man@ietf.org >>> Subject: RE: Proposed RFC 1981bis clarification regarding Hop Limit >> decrement being orthogonal >>>=20 >>> Hello Dave, >>>=20 >>> If =E2=80=9CIt=E2=80=9D refers to the node, maybe it would be more = readable to place the >> change at the end of the sentence? >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Dave Thaler >>> Sent: mercredi 6 avril 2016 11:21 >>> To: 6man@ietf.org >>> Subject: Proposed RFC 1981bis clarification regarding Hop Limit = decrement >> being orthogonal >>>=20 >>> OLD: If any of the packets sent on that path are too large to be = forwarded >>> OLD: by some node along the path, that node will discard them and = return >>> OLD: ICMPv6 Packet Too Big messages [ICMPv6]. >>>=20 >>> NEW: If any of the packets sent on that path are too large to be = forwarded >>> NEW: by some node along the path (regardless of whether it = decrements >> the Hop Limit), that node will discard them and return >>> NEW: ICMPv6 Packet Too Big messages [ICMPv6]. >>>=20 >>> That is, just add the phrase =E2=80=9C(regardless of whether it = decrements the Hop >> Limit)=E2=80=9D to the existing sentence. >>>=20 >>> Dave >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 --Apple-Mail=_FC289929-410C-48C8-9C9F-730C842948C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXD7cxAAoJEK7rdBF357uodAAH/0N0Wjv1n2Fn8XVTt/EZFqBp CemgYT2X7kFjCyJMrUkkuGyABW1zYesm9SB5dPfWcIY+aYGHCJ4h2WfEWftUIcOg QgotVoIgq6Alwtyn59HvSkp1eCJcFQpwGOU6DU+AXeqjOutF9mZ0jC+B6YtcojCP 7iZ+HRu05tmpe73h8ZYk8UarAsLIWvIt0qsUXvYz3fdRQEhOtRDGwOkYlnNmYdsd iWRFfXN9egYTHgwE87GafF4ZoZFK49GPEbIw3q4hSl60CN5relfn4RhhulXkgR+8 gUXxt7uLD22q0ydO+5GZHAiFmJpUTpQGhSrExyBsX2d0L3ln9RtsfAGm3AIPZr8= =j1g8 -----END PGP SIGNATURE----- --Apple-Mail=_FC289929-410C-48C8-9C9F-730C842948C1-- From nobody Thu Apr 14 08:32:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55C912E619 for ; Thu, 14 Apr 2016 08:32:10 -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 Vhh13yr5yg03 for ; Thu, 14 Apr 2016 08:32:09 -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 61A4E12E61E for <6man@ietf.org>; Thu, 14 Apr 2016 08:32:09 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id u185so107106733iod.3 for <6man@ietf.org>; Thu, 14 Apr 2016 08:32:09 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=QqiHOyPmWmzSKR5TJZPyaEYqG+CSunS+BL1hjC/WmlQ=; b=hZjnTZtWXZe7hlp/YVg/aWiEU0tVjuM+qB/BeOHSzC+l6RbKHSysgrzFxEhvyb4xGt 3cUXpUztKx8+oDFP2UjK+DnmryJCR0KCUHq9E7tLje4PY2MzwKmBh5FN9+DNT5rmjpqv 6bLWAmsVy+ST+cLZtHWnan3Q/t6bzX+BvHlPN2UJxGL6bwdVyHy+ydkTDTeNEcUF7ige 4wgeGq31OLKNAZRMqoObcvFGCG9bf/ID88lqrqWLG5cZcnFyDDk8J3rN9SxhMMrlitPW EXYyBFxTtcHfgY1ThqYOCzVooGAvHMh8VVPoQnIOElU3rJwdwq+rSrT2GWphd8J+07wS 0TSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=QqiHOyPmWmzSKR5TJZPyaEYqG+CSunS+BL1hjC/WmlQ=; b=hw8MOxh23EqCRtl7OnrffdJoK8ejhQu8M4n2GKvMVJ7Hjcw2dK1hL3A3cGAt9Cb8VA Mp7nf3peNg/LYIqvLibz+b5YD3HiZnC7HZzhUVDdtbk2qWJ7r6B/UB8+w6aIU+dq80su +LwmMwcuIogeg+WDtC+GAAQDCdR+PZMg/XTbs9FcPpLoDiJ3jtEVAK3Isw8ru7QxiO8V hLbSWtKQHCuoxpcDJphn/eqGGOhu8lNO57XGsqh4IGJ8Sjf557vz0sCD7AW4aEi4bxV2 QpbdEgkcAq8O/obIA99UESgsc0OJDkg8/1zJWXyDasgxFhjIWCoGtkLrAg410Qbt071r 4Aeg== X-Gm-Message-State: AOPr4FXjD4YOYY4mWGUB1c8Y9SVXAy7TIGp3tABoRKBX3W/b2+7xNhEern033goDZcIqtWux9z1O/YUDwLbBtg== MIME-Version: 1.0 X-Received: by 10.107.7.30 with SMTP id 30mr18699087ioh.107.1460647928548; Thu, 14 Apr 2016 08:32:08 -0700 (PDT) Received: by 10.107.142.67 with HTTP; Thu, 14 Apr 2016 08:32:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Apr 2016 08:32:08 -0700 Message-ID: Subject: Re: EH end encapsulation in 2460bis From: Tom Herbert To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:32:10 -0000 On Wed, Apr 13, 2016 at 4:59 PM, Fred Baker (fred) wrote: > I actually looked pretty hard at this in https://tools.ietf.org/html/draf= t-ietf-6man-hbh-header-handling-00. My segment-routing colleagues wanted pr= etty badly to insert an SR header at some point in the network, and then re= move it somewhere else before delivery to the destination. > I think my real question is a bit more pedantic. Does any mitigation for the inability to insert extension headers even need to be suggested in 2460bis? It does not seem like this is normative to the protocol. Tom > Working through potential failure cases, what worried me was the security= header. Suppose, for example, that the inserted SR header would have to be= removed before being given to the addressed destination, but the addressed= destination was an anycast address? In such a case, the system that will u= ltimately respond to the packet advertises itself as "a" right router capab= le of forwarding the packet to that address. So, fine, I give the packet to= the "router", and the receiving system realizes that the destination addre= ss is one of its own, and so receives it as a message addressed to it. Oops= ; we tripped over an assumption. > > At IETF 94, I tried to make my SR colleague's point, and Bob Hinden told = me that they had already vacated the field, leaving me with my pants around= my ankles. Thanks, guys. > > But that is fundamentally the point. We need a solution that has no stick= y failure cases, and delivering the actual packet sent is the only one that= presents itself. Encapsulation does that. Anything else has to prove the c= ase. > >> On Apr 13, 2016, at 4:03 PM, Tom Herbert wrote: >> >> Hello, >> >>> From draft-ietf-6man-rfc2460bis-04 >> >> "Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]." >> >> It is unclear to me how/rather IP encapsulation can meet the >> requirements or at least the intent of a node wanting to insert >> extension headers. For instance if a middlebox is presented a packet >> with EHs ABC and it wishes to insert EH X, it's intent might be to >> create a packet with EHs ABXC. I don't see how this can generally be >> expressed with encapsulation. For instance, is expected that there is >> some process of moving/copying certain of the original EHs to the >> outer headers (like HBH, routing)? >> >> Thanks, >> Tom >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Thu Apr 14 09:11:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE5712D9B1 for ; Thu, 14 Apr 2016 09:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 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.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 MwamI264GrFq for ; Thu, 14 Apr 2016 09:11:34 -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 8DE8412D920 for <6man@ietf.org>; Thu, 14 Apr 2016 09:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2177; q=dns/txt; s=iport; t=1460650294; x=1461859894; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=slXd6SdgfRZaH7ynxc6tr5E59PVuv4pOuHjD6du7C/o=; b=MMDLHh6L0qBJr0A6UXsVU8FLTjI/Uq6zdNdtU9E4gThUC8Q8ZGyqCkV8 Sd1iDvzDMWuaiOTl0tOsy1ZNhzVQVS5/gWtTdtLiGeVJa79guX4Xd5Ffp je3L/w/M+BVd7nKc55lxyhM7lMzC+KlGUO2nPCJLtjvc7tBG4F7S4iei+ c=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAwD+vw9X/4UNJK1egziBUAa6KQ6Bc?= =?us-ascii?q?YYOAoE6OBQBAQEBAQEBZSeEQQEBAQMBeQULAgEIDgouMiUCBA4FDogTCMJpAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBDQiIFoJWhA8RAYNJgisFmAsBgyOBZokDjxCPK?= =?us-ascii?q?AEeAUOCBBmBSmyIEjZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="asc'?scan'208";a="259648483" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 16:11:33 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3EGBXun002745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 16:11:33 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 11:11:33 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 11:11:33 -0500 From: "Fred Baker (fred)" To: Mikael Abrahamsson Subject: Re: EH end encapsulation in 2460bis Thread-Topic: EH end encapsulation in 2460bis Thread-Index: AQHRldixsJ46CY2X20unwVqHwK89Qp+I6SWAgACNc4CAAIIlgA== Date: Thu, 14 Apr 2016 16:11:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_FF01D193-9270-4D90-8B18-FB6906734BC0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 16:11:36 -0000 --Apple-Mail=_FF01D193-9270-4D90-8B18-FB6906734BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My understanding - this from Bob - is that they agreed to encapsulate in = an IPv6 header with an SR header. I spoke with the about it and they = said they had agreed to encapsulate, but I don't have details on that. > On Apr 14, 2016, at 1:25 AM, Mikael Abrahamsson = wrote: >=20 > On Wed, 13 Apr 2016, Fred Baker (fred) wrote: >=20 >> At IETF 94, I tried to make my SR colleague's point, and Bob Hinden = told me that they had already vacated the field, leaving me with my = pants around my ankles. Thanks, guys. >=20 > Just so I understand this 100%. The SR guys no longer want to do SR = header insertion and removal when entering/leaving the SR domain? >=20 > So SR is now only encap of entire packet? Either in a new IP packet or = using MPLS? >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se --Apple-Mail=_FF01D193-9270-4D90-8B18-FB6906734BC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVw/BNEayAOS/EQ8MAQJGzw/+LQHKsTsmAsloEQ35uKYWdue3MLtDo93L NjrJibCWe1tN+08NMqgB3AZ2iA3lJeDepaD+Pg7UbPbGXgpo9T6UmxlMF0PxzHGt PKbjbVB6yZbTJjwxY0g4Fsfjbgz18zKdjYGg9ZKOX2r/DORdjA6hlfc5yFyu0dzp DQUqHRrIVlGemUBOlhQT3+NDAJEpIBP694vn/CUxiPES22Tf9EUresJ+zsxUqlGf X2ia2E+ZkE2hRhW2+UYlJohElK29pBiWOon/r+AACnQp7ceoDVYLABmCfjatBou0 20fuyORiWTkKGZMDm8qX5ur6xYDkFean6g+UieCDBeKzoCqu89Tow0DkYDuwf0uw OhSoVmW5ucBBx/CDdPkoS6ZjWMPnVrEOdiFQLQaBZR0322zaPAIJQobH2IljRU78 GjDrpF/NgGsf1AS4/6Rfdml/dk3G2A/IIOS9s6WDfjeNhnKJH/pYnUyDVhVA1V3k 9BHnGqNq819ox5A5iuFVqXJYzrf3hQrSj057vXSHlNcfOIuWq3xcK+pEGYtMehWh KvVn5IKSqsQIjewk5sZ0rmg1MvCXovXuG8aPxEfpXj2gWh5iZ0lzomXJAZxzU9U8 44V36rxf56GysSG/ZJC6Ice1TJKCUcUYJiCdDLNgpQBLHqgAkGTH2B50+MfgH7yi 0Vi/BQDsTwE= =NBZf -----END PGP SIGNATURE----- --Apple-Mail=_FF01D193-9270-4D90-8B18-FB6906734BC0-- From nobody Thu Apr 14 13:35:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFB012D634 for ; Thu, 14 Apr 2016 13:35:07 -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 5Fm5g_DW_Ynk for ; Thu, 14 Apr 2016 13:35:06 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 E3A5212D57D for <6man@ietf.org>; Thu, 14 Apr 2016 13:35:05 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id zm5so48051289pac.0 for <6man@ietf.org>; Thu, 14 Apr 2016 13:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=82QCOSsIaMJRbyOR1Z8yB7BgRjjOT2cEk94AO23pMNI=; b=BAhUAWmsy83Gn4ZaeUMj02ylyX87YCfCkxrAfUKkqHHFIhYfwy0z/dFwMKXamr822w c/PCtSlpLSDw/ZFH6/6q5SH1QyfCxl5p1MGYRuwvxJIoRBLU0dAinFfksOQsZAyrxXjX GcMzPMARC8lzKjDjcAwDL7Uqxv1J1X016NzPPMJfgH0i6O8HOn8pM4XhojBjwO+mMUu8 gEb3fFP3LnxAmCKNXJUkwar10oC5ZH+H3zEkfhb1ZvK9EpZiw+qQwVeu4Eczhf6uPgII e5u+p6HpcyB0RQX/u9QAUwKA2ewNtKx5b+JCoYyPGDDMAvnoYB9AmihtsdcyYraemLkX vr2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=82QCOSsIaMJRbyOR1Z8yB7BgRjjOT2cEk94AO23pMNI=; b=ToVTXFCMm16Bs1c5UGtBwNu9XdX/hHB42LSM9FZ3tmhUcuwbnRW8Fv3H39sOlsAsnd Cwj12j0GZc68cxpJnibuyDxXes8J5x8OJUvBtcnLJqwkbnsnEDuga0jEAeuZ8hW1+EGl C4KFWI39ee75NHYEy0JIlG5p5axoFomrUKGIKJkTTkcC5zai9gjiHP4GvPynVDkLvK0y ShYhicluBzbYyk6YriKOxnS68pwGgxErhIVYfzZBQOiaFzGOZiAP5wKDpl8c1NC6qeeJ nJRoCj3k/2kLp8f5v9LcWsrr4j6VHfTDV0A86MTAsbAKg3C29t0bblhdpgdoS7V99f/y kW+w== X-Gm-Message-State: AOPr4FWExRUgm5gv3vp/B9QrEQXV8LNM9Y1uiMrWckWtNR+K9s5Aamg+vKx4ifIERgrs6A== X-Received: by 10.67.21.231 with SMTP id hn7mr24115883pad.150.1460666105445; Thu, 14 Apr 2016 13:35:05 -0700 (PDT) Received: from ?IPv6:2406:e007:4759:1:28cc:dc4c:9703:6781? ([2406:e007:4759:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i9sm59798770pfi.95.2016.04.14.13.35.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 13:35:04 -0700 (PDT) Subject: Re: EH end encapsulation in 2460bis To: "Stefano Previdi (sprevidi)" , Mikael Abrahamsson References: <81CBA2D4-28E1-4E4E-8364-6276B6704234@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <570FFEFE.8080606@gmail.com> Date: Fri, 15 Apr 2016 08:35:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <81CBA2D4-28E1-4E4E-8364-6276B6704234@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 20:35:08 -0000 On 15/04/2016 03:01, Stefano Previdi (sprevidi) wrote: > >> On Apr 14, 2016, at 12:18 PM, Mikael Abrahamsson wrote: >> >> On Thu, 14 Apr 2016, Stefano Previdi (sprevidi) wrote: >> >>> current implementations of Segment Routing over IPv6 dataplane (aka: SRv6) do SRH insertion at ingress of the domain and SRH removal at egress. >> >> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-01 >> >> 4.1. >> >> "An SR domain ingress router encapsulating a received IPv6 packet >> into an outer IPv6 header followed by an SRH." >> >> Does this mean the outer header is a new header, and the received IPv6 packet is completely (and unchanged) encapsulated into a new IPv6 header (with DA being the SR exist node) and SRH? > > > yes. > > >> So SR is now tunneling only, it's never "take existing received packet IPv6 header, insert SRH after existing received packet header, then insert rest of original packet EH" (which would be header insertion instead of creating a tunnel packet)? > > > it is correct. The current draft assumes only encapsulation. > > However, this does not reflect the reality o implementation and deployments where the SRH is in fact inserted after the received ipv6 header. Not being the protocol police, the IETF can't do anything about what consenting adults do in a private network. We write standards for interop across the Internet. Private use of the DSCP field has always been foreseen, but in general the IETF hasn't liked legitimising private uses of other parts of the IP header, for fear they would escape. But if we want to legitimise private use of EH, we could. Brian From nobody Fri Apr 15 01:45:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400F512D873 for ; Fri, 15 Apr 2016 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 04h_CGZSYcH5 for ; Fri, 15 Apr 2016 01:45:12 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6012D6EE for ; Fri, 15 Apr 2016 01:45:11 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP; 15 Apr 2016 08:45:10 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B21DDD7882; Fri, 15 Apr 2016 01:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=w7rJ9YTXY3wPgt9ASz+CErAGa3E=; b= puXLg8xI0Gcsz1A2sFV/g+LfwNUiUopGD51kr0Zt1LZGQs5D4RBZusyzX9fNjgme K3KkshHrpueBDOLy1lx+6o2ZiSzkQ4lP0x6W82GrPC2A/lBb6AGNkIroxltIQQ// CfiKlLPSVnKEqBzTN6eCYxrAXkwEqBIvlALJnCM2dlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=f3+fJ2YtaBOFjLbkrAAZb+8P7d vDIMudTrL9+W5HMFNJJu+FGUh6M4c7a7Qx4JKbfEUzKt8pNAeNb5GhYQePPLzfPE o5lZiSC/Hg8MAcEkq5sr4LJAUkXk2QtiXtNzku3HP8ME9BXCetavWTIxtY2Wv8y7 xuDjko9cQN8AzdszQ= Received: from h.hanazo.no (unknown [173.38.220.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 6FD48D7884; Fri, 15 Apr 2016 01:45:09 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id 7D3BA14650F2; Fri, 15 Apr 2016 10:45:05 +0200 (CEST) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_463440F3-4891-494E-8A27-C84489731B91"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Fri, 15 Apr 2016 10:45:05 +0200 Message-Id: <46AC6821-DB5F-4092-8C30-121D5CA3302A@employees.org> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 08:45:13 -0000 --Apple-Mail=_463440F3-4891-494E-8A27-C84489731B91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, > This would however require that we allow MTUs tied to not only PIO, = but also RIO. I still don't know what to do about the implicit default = route that one points to anyone one sees an RA from. Personally I = consider this design of the IPv6 protocol to be unfortunate. When you get MTU path discovery in BGP advertisements then we'll put it = in the RIO. ;-) Ole --Apple-Mail=_463440F3-4891-494E-8A27-C84489731B91 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXEKoRAAoJEL7aWKiYQt92gewP/2PEgwXmtDFWUM0hmYt+yG0J Jx6spXx6QGTY77E5OzmTOvazkv8K8S9XIQcA3T1V7L5UMoildohBKGFJWqD1JJGR 68czOMVRmvIlX1DCLvdm2Hl3ee8iqqOgiNMBPWDFwgUUOuCnPlun6ZEcF8JlvOFJ MfkGZPFp08U6TqXZ+AFxqdYyDPks0AT2qd3dZXD9KQSwHqk7MUgYB7QpKxCYTBe3 +ebldRBJgrHhMG8SNQ6XSMARcVtYQzyvBRzdVNt1JIMArMlVQ/ieNBbIyOMvGJU0 XGlVhiA7HwjPDciMSG8TdpltlGTm/dedgUgnNLoxomEGYpXcm6YKCGegut5fKooK xtGiFsQrg34QtzZKCRTs6c00j1s8P0uFmAH+0rdcafXbk45L1F+XeukAEfzMj5zn pS7mtsBFI8RpT0RqzkfGkeKzizKcPsVqxEMh3YXuHwOoczMPwbt8CFSRWse9vycU UGiRXmtvLXJ4oM3aeFQ56e7XkGwtfXZb7uj4WI0sfHqKeHl96fbuDl83icmxhQIc 61IkBhGcrFzvqgDMGyVHMSM5OYDPRcZ2XHzU7igsWUoS/nFqtaHFpf/ocVYgF7fz vSgj4Elg2peQOotU1M2vRwBU4quIGWT5x8XI1GVLQgxthCL1rjCv24S3E+SECVfE u0bkMgE5hMdwL+hELuSJ =01/i -----END PGP SIGNATURE----- --Apple-Mail=_463440F3-4891-494E-8A27-C84489731B91-- From nobody Fri Apr 15 06:24:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7DB12DB32 for ; Fri, 15 Apr 2016 06:24:13 -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 7R3L1Y87yQAP for ; Fri, 15 Apr 2016 06:24:10 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (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 7AD8C12D742 for ; Fri, 15 Apr 2016 06:24:10 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.86_2) (envelope-from ) id 1ar3j9-000CY1-32; Fri, 15 Apr 2016 15:24:05 +0200 Date: Fri, 15 Apr 2016 15:24:03 +0200 From: David Lamparter To: otroan@employees.org Subject: Re: draft-van-beijnum-multi-mtu-05.txt Message-ID: <20160415132403.GT518778@eidolon> References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <46AC6821-DB5F-4092-8C30-121D5CA3302A@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46AC6821-DB5F-4092-8C30-121D5CA3302A@employees.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 13:24:13 -0000 On Fri, Apr 15, 2016 at 10:45:05AM +0200, otroan@employees.org wrote: > > This would however require that we allow MTUs tied to not only PIO, but also RIO. I still don't know what to do about the implicit default route that one points to anyone one sees an RA from. Personally I consider this design of the IPv6 protocol to be unfortunate. > > When you get MTU path discovery in BGP advertisements then we'll put it in the RIO. ;-) BGP is TCP, right? Let's put PLMTUD on it :3 -David From nobody Mon Apr 18 00:18:38 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C03412DA48 for ; Mon, 18 Apr 2016 00:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 xMUq0uPmAPtw for ; Mon, 18 Apr 2016 00:18:35 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6F912D9CA for ; Mon, 18 Apr 2016 00:18:34 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP; 18 Apr 2016 07:18:32 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D75B8D7884; Mon, 18 Apr 2016 00:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=NTNYOMCPg9/OxX4rK+nPIdyku1M=; b= JBsbD5OBklTcAyrkgE4BheCcA5YeMhmvmr4V5rQEsBa3Ve1HwyOex69/3x/SnLSf y+uN/evv8Uqtyxh404r7D5733DsEOFXnfmR/f4NgeH5pJiUazwgzbbjtDZ47ksJq YX2OBOcPZneiaKCP+6+dzvUpJx7Yw2TjnZxE57HgT5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=UBrDc7NjI3zje9tf7kY6KNloPy 61IMUj8aWjCx9hApDbdsA47i9yfFwatz3bIv7zvcN94oFkuZQEDdOuKYnW1HvfC8 3+X9IvwSoObSRmXajZCCTpiD/gADtVYK2aeOICQwJHr9IcTBY0fn9Lvr0l4poor0 cGuZRE5NsI/JxlrmU= Received: from h.hanazo.no (unknown [173.38.220.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A2445D7883; Mon, 18 Apr 2016 00:18:27 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id 835A9146996E; Mon, 18 Apr 2016 09:18:39 +0200 (CEST) Subject: Re: draft-van-beijnum-multi-mtu-05.txt Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0ABBEC58-A189-4D64-8A01-4CFAA8DA2331"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160415132403.GT518778@eidolon> Date: Mon, 18 Apr 2016 09:18:39 +0200 Message-Id: References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <46AC6821-DB5F-4092-8C30-121D5CA3302A@employees.org> <20160415132403.GT518778@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:18:37 -0000 --Apple-Mail=_0ABBEC58-A189-4D64-8A01-4CFAA8DA2331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dave, >>> This would however require that we allow MTUs tied to not only PIO, = but also RIO. I still don't know what to do about the implicit default = route that one points to anyone one sees an RA from. Personally I = consider this design of the IPv6 protocol to be unfortunate. >>=20 >> When you get MTU path discovery in BGP advertisements then we'll put = it in the RIO. ;-) >=20 > BGP is TCP, right? Let's put PLMTUD on it :3 You could, but I was more thinking of including MTU information along = with prefix advertisements in BGP. Each BGP writer then rewrites the = announced MTU if it's interface MTU is lower. That would be equivalent = to associating it with an RIO. Unfortunately the BGP signalling path = might not be the same as the data path. ;-) Cheers, Ole --Apple-Mail=_0ABBEC58-A189-4D64-8A01-4CFAA8DA2331 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXFIpPAAoJEL7aWKiYQt92lP8P/0GD61qEZ+LuBPzJ4pVI2XQy UKwXsrM0W53sAxWjz2tm0T26xg7yiONz0YnSVxhj8YO/MJKn9GNtz5oeFYT/RG2j 3w3zviQptC1141vJBcgqyguvp0mXEmMdZvxa4ucyrf11EpaskRf8u5NyC6KJUUFE D6ebkZ6PjBNwWCIF+yP9jq+UsP102a7kWoAVSZbmvnvwJLqdTmhmzAcIaxfhqXTg PgOxnjrx4cUtMrmKluvXTlz1FyAwj3AVCtN8YoLKLm00etp7XotTS1zGbb+SjJ1t 5c44ipeBMW69VxGv3RZ5cB/9bL/f6++ZiG+mhnsJJlz3AgcUIlAsX+85Pnfxk+Ck R5lIs9Rrq4+QyRlqXqPUCnYoEO1DXGHd0fz18WCao6hRX9iDUF0Qeq6sAljImJYe oNe+mZm0f6U6V+SIHt4Pq7HhnB0AKK4qJBlus0jVlg1ze1a8PdFaR5mDSxmb63KD TZqc0+E/XX2GPXlmZeXBjCrj+ESiWMO25McA7/f0hWEYF4Ow4dI2uKwFgdNpe0VV c15mz0409p5uEnKueeMLnICAf2wUwztbc0aVhuMsbFw9cBZpHeSlFAYiaA/z19QE AurUOWJlg1e4eezQq/FGpF3SMlZTbzWz3f1K1ZLsySeIiUa9hxxMuQFdOrq69qow X3pxz09aLIVnRsCvoyKJ =TIFz -----END PGP SIGNATURE----- --Apple-Mail=_0ABBEC58-A189-4D64-8A01-4CFAA8DA2331-- From nobody Wed Apr 20 15:35:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5043E12E77F for ; Wed, 20 Apr 2016 15:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5K-AwmQWt_OH for ; Wed, 20 Apr 2016 15:35:46 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 F138012E426 for ; Wed, 20 Apr 2016 15:35:32 -0700 (PDT) Received: from [172.20.234.49] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u3KMZJNP030130 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Apr 2016 15:35:19 -0700 Subject: Re: draft-van-beijnum-multi-mtu-05.txt To: otroan@employees.org, David Lamparter References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <20160414122245.GN518778@eidolon> <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> From: Erik Nordmark Message-ID: <57180427.2000504@acm.org> Date: Wed, 20 Apr 2016 15:35:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <07555AE0-8B99-464D-8F22-1663BF6579A7@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa0EkByP3eT6LHqLQ3ObMQo1LSZjNUmlUrjRLYOQhOT7KdSfrkp5ZHm255wgXdIjRAAqvp+eJR/OJ4fzdkAAWXh X-Sonic-ID: C;kn45KUgH5hGhDPjNyE/n4w== M;bm9sKUgH5hGhDPjNyE/n4w== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: Erik Nordmark , Iljitsch van Beijnum , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 22:35:48 -0000 On 4/14/16 5:30 AM, otroan@employees.org wrote: > David, > >>> In general I'd prefer that we reuse existing mechanisms for path mtu >>> discovery, and not invent new ones purely for the case of two directly >>> connected neighbors. >> That's actually the crux of it: this isn't Path MTU discovery. The MTU >> discovered by this mechanism is the first-hop MTU for a lot of paths in >> case of a router and it's going to be distinct from the final PMTU >> towards a particular destination. Plus, state on this only ever exists >> for direct neighbors, not for any random internet host. > why couldn't it be done as end-to-end MTU? > > the directly connected mechanism would be just to give a hint that there might be nodes here capable of a higher MTU. then do normal MTU probing / detection. > > what would be gain be to have a specific protocol to probe directly connected neighbors? Ole, AFAIR PLMTUD has an upper limit which is the interface MTU. Thus at least an implementation would need to handle per neighbor MTU instead of per-interface. But that doesn't require any new protocol behavior. If we suppose a mixture of nodes on a link - some with per-neighbor and some per-interface, then I think things will work slightly more efficiently if a per-neighbor node can easily tell whether to bother with something larger than the default interface MTU (often 1500); receiving some new flag or MTU value in a NS/NA would be sufficient as a hint to try larger. That might also help with corner cases where some old NICs fail/reset in interesting ways if they receive a 9k frame. FWIW I think it is a good idea to couple this with implementing PLMTUD. That way at most we need a hint to try larger with the actual probing being done as part of PLMTUD. Erik > > Best, > Ole > >>> Could we make this work by adding the RFC4861 MTU option to NS/NA >>> messages, and require that PLMTUD probing is used to verify the end to >>> end MTU. >> It's not end-to-end MTU... >> >>> Then the mechanism used is the same for directly connected neighbors >>> and off-link neighbors (apart from the initial discovery). >> Well, it'd be possible to distinguish first-hop failures from failures >> later in the path, but with a router there's rarely a direct TCP >> connection to it to do PLMTUD on. >> >> Either way this really needs at least different handling from end-to-end >> MTU in order to not keep probing towards a router whenever a host >> decides to talk to another destination in the internet. Some first-hop >> neighbor concept... >> >> If probing hosts for each of their addresses can be avoided, that might >> be useful too, but that's far less of an issue (and harder to do) than >> not probing routers for every single internet destination. >> >>> If we were to invent new probing mechanisms, I would hope we did so >>> under the PLMTUD (4821) umbrella. >> Hm. Maybe the draft can be rewritten as extension to 4821, but quite a >> few things are different with reason -- not sure this is that good of a >> fit... >> >> Cheers, >> >> -David >> >>> Best regards, >>> Ole >>> >>>> On 06 Apr 2016, at 19:04, David Lamparter wrote: >>>> >>>> On Wed, Apr 06, 2016 at 11:20:48PM +0200, David Lamparter wrote: >>>>> On Wed, Apr 06, 2016 at 04:55:46PM -0300, Erik Nordmark wrote: >>>>>> On 4/6/16 12:18 PM, David Lamparter wrote: >>>>>>> On Mon, Apr 04, 2016 at 11:37:17PM +0200, Mikael Abrahamsson wrote: >>>>>>> Ok... easy comments/opinions first: >>>>>>> - should definitely be ICMP, not UDP. Erik Nordmark's suggestion to >>>>>>> piggyback on NUD sounds great, though admittedly I haven't thought it >>>>>>> through looking for pitfalls. >>>>>> One issue compared to a dedicate probe is that a NUD (a unicast NS) of >>>>>> size X wouldn't necessarily result in a unicast NA that is also padded; >>>>>> perhaps one can add such behavior so that we can get the bidirectional >>>>>> probe in both directions. >>>>> That might be (half of) a feature: if the MTU probe is a NS option, and >>>>> the target host does not support it, we still get a NA reply. That's >>>>> better than timing out waiting. The downside is that a NA without the >>>>> "MTU response" option doesn't mean that the host doesn't implement the >>>>> protocol -- the NA could be in response to something else. >>>> Obvious easy way: have the "ND NODEMTU" option described in draft sec. 5 >>>> mandatory on all NAs if the host implements the protocol; receipt of any >>>> NA without the option can then flag the sender as mtu-probe-incapable. >>>> >>>> (Not sure if the last paragraph of sec. 9.1 already implies the option >>>> MUST be put on all NAs and NSs? Certainly needs better wording.) >>>> >>>> -David >>>> >>>>> That said, I'd expect the probability of a host ignoring a new NS option >>>>> is much lower than it filtering out unknown new ICMP (sub)types or UDP >>>>> ports. If that reduces useless probing (or even waiting), I'm all for >>>>> it. >>>>> >>>>> (As I understand it, the draft in no case suggests waiting for the >>>>> probes to come back, so it's not much of an argument. Might still >>>>> reduce useless probe traffic?) >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- From nobody Wed Apr 27 06:18:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086F12D189; Wed, 27 Apr 2016 06:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lVr-tv5jnRwG; Wed, 27 Apr 2016 06:18:02 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C98312D0F8; Wed, 27 Apr 2016 06:17:59 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4F0BCA0351; Wed, 27 Apr 2016 15:17:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 2662F40066; Wed, 27 Apr 2016 15:17:58 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 15:17:57 +0200 From: To: "spring@ietf.org" , "ipv6@ietf.org" Subject: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcg== Date: Wed, 27 Apr 2016 13:17:57 +0000 Message-ID: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:18:03 -0000 --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: multipart/alternative; boundary="_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_" --_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like some clarification about the treatment of the SRH by an end p= oint (the node that its loopback matches the DA field), In section 3 : You say that the C-flag: Clean-up flag. Set when the SRH has to be removed from the packet when the packet reaches the last segment. Which mean that the last node inspects the SRH flags if the c-flag is set, = the node has to remove the SRH before sending the packet to its final desti= nation. But In section 4.3. You say that the node that decrements the Segments left pointer has to chec= k if the c-flag is set when the new value of the segments left point is equ= al to zero, If the c-flag is set and the segments left pointer =3D=3D 0 then remove the= SRH, What is confusing for me is that the node that decrements the pointer is no= t the last node in the SR path (behavior similar to PHP for MPLS) , which = I find in direct contradiction with section 3. Another question if a node receives a packet with the already segment left = =3D=3D 0, what should that node do with the packet(e.g., drops it?) Bests. [Orange logo] Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I would like some clarification about the treatment = of the  SRH by an end point (the node that its loopback matches the DA= field),

 

In section 3 :

You say that the

C-flag: Clean-up flag.  Set when the SRH has to= be removed from

         the= packet when the packet reaches the last segment.

 

 

Which mean that the last node inspects the SRH flags= if the c-flag is set, the node has to remove the SRH before sending the pa= cket to its final destination.

 

But In section 4.3.

 

You say that the node that decrements the Segments l= eft pointer has to check if the c-flag is set when the new value of the seg= ments left point is equal to zero,

If the c-flag is set and the segments left pointer = =3D=3D 0 then remove the SRH,

 

What is confusing for me is that the node that decre= ments the pointer is not the last node in the SR path (behavior similar to =  PHP for MPLS) , which I find in direct contradiction with section 3.<= o:p>

 

Another question if a node receives a packet with th= e already segment left =3D=3D 0, what should that node do with the packet(e= .g., drops it?)

 

 

Bests.

 

 

3D"Ora=

 <= o:p>

Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

 <= o:p>

Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com

 <= o:p>

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_-- --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=406; creation-date="Wed, 27 Apr 2016 13:17:57 GMT"; modification-date="Wed, 27 Apr 2016 13:17:57 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhKAAyAIQQAP9mAP9wEP95IP+DMP+MQP+WUP+fYP+pcP+zgP+8j//Gn//Pr//Zv//iz//s 3//17////////////////////////////////////////////////////////////////ywAAAAA KAAyAAAF/iAkjmRpnmiqrmzrvnAsz3SdMkCu73zv/zoccEj8CYvI4jHJ9C2b0Nwz2pxSk9arUhvN coHer1PMDJN35rNUvWUP02r4WU6mi+1fPFev5V/9VIBdbm+EYIZGiDkIDA8KBIJFBAgPD5A5AwwQ DgcACQygBA2bBgAMCg4QCQADqaADmZsHArABQqkJo5CbCQgNBakAEA+5EAMNDwe6jQaaAkEAAhAK AAQQjBAB0agiwjgIENY4BeHDDKOlawOq1deaOZUGo94A4OIABuUOCPwE0ADxNDWDwArCggIPCEL4 Fi4VpXDICvh6tqZaQnbvTA0LtrBeuFYQdIE0qK0ippJNHBAsIKAg3KEv4ESEiZQjAAGUP2zo3Mmz p88WIQAAOw== --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_-- From nobody Wed Apr 27 06:50:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DEC12D1D3; Wed, 27 Apr 2016 06:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 HyGBFRP4pCj8; Wed, 27 Apr 2016 06:50:33 -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 EBAC212D5B5; Wed, 27 Apr 2016 06:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3619; q=dns/txt; s=iport; t=1461765030; x=1462974630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OMLw8acIb04LiGlXuK0IKK/BdxopezDvClSlc0yte0s=; b=i0forHs+sPaF6U8L0bPuxjbUFmFDQM0yCtQSSafEaHKQDu7APY1m9J7B WDwxYz9deKKXeMdUQMtBOauBi9/s+sk6eq/x4TvHtVpmEd8r1MEgpH+fZ s0GcR0ubye8gnevAR0b/Op6xWdumlEMsV+REPmaQL0h/L/iThwI7wxeG2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBYwyBX/5hdJa1egzhTfQa5ZgENg?= =?us-ascii?q?XUXC4VtAoErOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGC4bDAslAQE?= =?us-ascii?q?EDgWIIggOxCwBAQEBAQEBAQEBAQEBAQEBAQEBAQERBASGHYF1glaEDxEBHCyCf?= =?us-ascii?q?4IrAQSHdIsYhQQBjhaBZ4RNhCSEOY8vAR4BAUKDa2yHeTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="266615337" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 13:50:29 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3RDoSOs003754 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 13:50:29 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.1104.5; Wed, 27 Apr 2016 09:50:28 -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.1104.009; Wed, 27 Apr 2016 09:50:28 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiA Date: Wed, 27 Apr 2016 13:50:28 +0000 Message-ID: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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.74.154] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:50:36 -0000 > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), > =20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag. =20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. > =20 > But In section 4.3. > =20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, > =20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you=92re right. The node that processes the cleanup flag is the penultimate= segment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 s. > =20 > =20 > Bests. > =20 > =20 > > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com > =20 > =20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Apr 27 07:09:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3012B062; Wed, 27 Apr 2016 07:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ii6vXfbYvsK0; Wed, 27 Apr 2016 07:09:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2998512D129; Wed, 27 Apr 2016 07:09:21 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 034D11801DF; Wed, 27 Apr 2016 16:09:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id C35E11A0081; Wed, 27 Apr 2016 16:09:19 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 16:09:19 +0200 From: To: "Stefano Previdi (sprevidi)" Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAAAgqc4A= Date: Wed, 27 Apr 2016 14:09:19 +0000 Message-ID: <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> In-Reply-To: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 14:09:23 -0000 =20 Yes, i think that a more accurate description is required. I have an additional question, In section 4.1 You say that the source node initializes the Segments left & first segment = pointers to n-1, and the DA =3D segment list[n-1], Do you consider that the first segment of the SR path (the last one in the = segment list field) is the ingress or the next node in the SR path=20 For example, for the following SR path PE1-P2-P3-PE4 does the segment list = =3D=3D [PE4,P3,P2,PE1] or [PE4,P3,P2] Bests =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: mercredi 27 avril 2016 15:50 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), >=20=20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag.=20=20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. >=20=20 > But In section 4.3. >=20=20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, >=20=20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you're right. The node that processes the cleanup flag is the penultimate s= egment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 s. >=20=20 >=20=20 > Bests. >=20=20 >=20=20 > >=20=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Apr 27 07:15:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093112D1C2; Wed, 27 Apr 2016 07:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 5jXrJFZ1o1wM; Wed, 27 Apr 2016 07:15:23 -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 2553112D169; Wed, 27 Apr 2016 07:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1461766523; x=1462976123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OS4PiNdFn4BzP4MkfJZ7n4CMcxrWE3nmGdmxC44DCpM=; b=hakoqd/xP/8zMwTIpHXPa7v2Bw+YX80QnTrvRGvpG7VIVl+a2pHKXNn1 El/e/phyEDS7VTZPoZAuRsRLN2xagjZu9jCJ+7S+6LuWA6tFGNVpqf5ks 7xVLblyvObcOiUpb/7FVxo/BngN/xB7NS01wyV+XZjacj/w5BRsqcBKxj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDkyCBX/5BdJa1egzhTfQa5ZgENg?= =?us-ascii?q?XUXC4VtAoEsOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGCcHGwwLFBE?= =?us-ascii?q?BAQQOBYgiCA7EMgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWCVoQPEQEcL?= =?us-ascii?q?IJ/gisFh3SGGIUAhQQBjhaBZ4RNhCSEOY8vAR4BAUKDa2yHeTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="265943055" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 14:15:22 +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 u3REFL7v006269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 14:15:22 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.1104.5; Wed, 27 Apr 2016 10:15:21 -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.1104.009; Wed, 27 Apr 2016 10:15:21 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAAAgqc4D//8WgAA== Date: Wed, 27 Apr 2016 14:15:20 +0000 Message-ID: <066165DE-5C6E-4CB7-8E2D-5A6F18AC7A20@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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.74.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F784D23B3B3214FA332151AFCDFBD1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 14:15:25 -0000 > On Apr 27, 2016, at 4:09 PM, rabah.guedrez@orange.com wrote: >=20 >=20 > Yes, i think that a more accurate description is required. >=20 > I have an additional question, >=20 > In section 4.1 > You say that the source node initializes the Segments left & first segmen= t pointers to n-1, and the DA =3D segment list[n-1], > Do you consider that the first segment of the SR path (the last one in th= e segment list field) is the ingress or the next node in the SR path=20 not the ingress. The ingress is the node that sets the segment list.=20 > For example, for the following SR path PE1-P2-P3-PE4 does the segment lis= t =3D=3D [PE4,P3,P2,PE1] or [PE4,P3,P2] if the segment list is created at the source of the packet then it will be: [PE4,P3,P2,PE1] if the segment list is created at the ingress (PE1) then it will be: [PE4,P3,P2] s. >=20 > Bests > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : mercredi 27 avril 2016 15:50 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi,=20 >> I would like some clarification about the treatment of the SRH by an en= d point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the=20 >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag. =20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has to c= heck if the c-flag is set when the new value of the segments left point is = equal to zero, >> If the c-flag is set and the segments left pointer =3D=3D 0 then remove = the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment le= ft =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This is d= escribed in RFC2460 section 4.4 >=20 > s. >=20 >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez=20 >> Th=E9sard=20 >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56=20 >> rabah.guedrez@orange.com >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Wed Apr 27 11:53:01 2016 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 70C6812D558; Wed, 27 Apr 2016 11:52:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc1981bis-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427185257.25285.66933.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 11:52:57 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:52:57 -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-02.txt Pages : 17 Date : 2016-04-27 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-02 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 Wed Apr 27 11:59:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96712DB62 for ; Wed, 27 Apr 2016 11:59:35 -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 Pnj7G6cu_sWf for ; Wed, 27 Apr 2016 11:59:34 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 E981512D530 for ; Wed, 27 Apr 2016 11:59:33 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so98035284ywa.0 for ; Wed, 27 Apr 2016 11:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=GhT4itx64+1NmK0QVy32ii0rivCU+ZUll2QpjD6GugY=; b=llxcxF811iOR4WfHw4XnLqR/KSXg+mAw+9CehWrKDy/68apdxcOpLcpKULY6Om+Cml bi/EV4jzNyCbBwoIytWJJxyJmJcEXvIKNx3c45W9JHuhe4FhclTNPX786aHiuMIhnwXN fjtNxJEfgom53IQRFBYRVYgGSAHMHyK/CF4W+KahzsopVTjs7Xf7/WMnIspW+jPKqCkn o9la1wP9rtOfiA/jgIdeRpSlemVpefh08AenH9tjgZZIcJzOGMJzo3KxL0r4tvwXBiTT lbdScTOTyiQKRpjTKUq1p8q/BVdYNct8O+feUSYifmdDzqLS3XIyPtwYMmAmBHfp30ei khXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=GhT4itx64+1NmK0QVy32ii0rivCU+ZUll2QpjD6GugY=; b=glUqAlrnwaJAzLmYZL0VSFaH6aGCIdrju4LWpyGxZftwJl6mT7V8dq4xnsu2OZm3Ds Sk8bTCObXV5OfEb2GVOkYrgjmU0LdEC6wMBN9ouO1Qcp/aGA4zxpnnyKojGwOcvW9ddF MDWsfhJJgLySX9nAuvgElGlG8gw98OJZnwHvOUV0eToM8+X+5SzY2aMFCZmDxxx+KeBQ CDH0wrJp7QmebCtOjBqw0fFF5gjjhb1aBH/u6agRRA23SGowFkI+vvga1+9W3PFU3jAb 9S83aIVOnyo44IchZeFPiRLkuMAsvl2jSefbMJILj0Fy1nMiRCapiGaeKdWEhhOCmUa6 rxiQ== X-Gm-Message-State: AOPr4FVHmNpfSBAytZbr2TKb3gKSL1yB5AIhQPiZmL90RMfgTK4BcL8Mi/NfqqS2yWhQxg== X-Received: by 10.129.76.147 with SMTP id z141mr5650239ywa.136.1461783573255; Wed, 27 Apr 2016 11:59:33 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id i188sm2659027ywc.19.2016.04.27.11.59.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 11:59:32 -0700 (PDT) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_53F50D77-6AA3-4B18-939E-F539F04C4BC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Date: Wed, 27 Apr 2016 11:59:29 -0700 Message-Id: To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:59:35 -0000 --Apple-Mail=_53F50D77-6AA3-4B18-939E-F539F04C4BC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new version of rfc1981bis. Links to the document below. The version has a change that was discussed on the mailing list. The = change is: - Clarified in Section 3. that ICMP Packet Too Big should be sent even if the node doesn't decrement the hop limit A diff from the previous version can be found at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-02.txt= This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > On Apr 27, 2016, at 11:52 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-6man-rfc1981bis-02.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc1981bis > Revision: 02 > Title: Path MTU Discovery for IP version 6 > Document date: 2016-04-27 > Group: 6man > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-02.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-02 >=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 --Apple-Mail=_53F50D77-6AA3-4B18-939E-F539F04C4BC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXIQwSAAoJEK7rdBF357uooGkH/ijEpc8VERxGdoUx0r4nprNM txHKtfyXfItYc2yD3qL4fWgo0r7oFJjO7UepqbmoY0Ax518gJfeQKJpIXlr+8anc XX6AVLBt/adKtR6lKSx1jAQYEfL0NzQ+r+qfzK21MEhJHgvIf2P1Lo6VZH4p8Bgu 2fOsyx8WwP8gaAd8nDGqe6yeHiuCMqdtHd+qXezb/m3tO6FORA0SwDtDrpjg4NUj C+wk2hRRkHTR8L+BzCu5vKN3+6z3syWbMx96KhtbHQlgjIgPSI5qLQQFctBvUiNv z7HxZObIoX/cBl6JjvNVWdOqEAuVD5jTlXYT1hEqciRBBPsCagu4eiwZ+yVPBnE= =W28p -----END PGP SIGNATURE----- --Apple-Mail=_53F50D77-6AA3-4B18-939E-F539F04C4BC1-- From nobody Wed Apr 27 12:10:37 2016 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 230F412DB63; Wed, 27 Apr 2016 12:10:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc4291bis-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427191033.25173.7863.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 12:10:33 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:10:33 -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 : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering Filename : draft-ietf-6man-rfc4291bis-02.txt Pages : 30 Date : 2016-04-27 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-02 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 Wed Apr 27 12:16:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F912D575 for ; Wed, 27 Apr 2016 12:16: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 oBvxnFuxK5we for ; Wed, 27 Apr 2016 12:16:25 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 9C08A12D571 for ; Wed, 27 Apr 2016 12:16:25 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j74so86616635ywg.1 for ; Wed, 27 Apr 2016 12:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:date:cc:message-id:references:to; bh=kXvNRnIeN+rwT0tEkcdgcm0Xjd6CLoTqna0qvS1HDcM=; b=d1CNFhTGUGWSLBCdwo5P/F3XkoA9qNzmr5fLwqE4zj2fe3umJxJxH93v3mPkf0iqZy 9eNycKBNgdI+U5c7fUxjDYKsTc+ikcSp6GqlrrqD2PamMrW4tbw+dyidc2231jfn5aNR VcF1ZrOT/FVFXDppmKq3r+e3nzBZ55eaXslj14VOI9s863jbzu6yElQ3NiO0JODHn4O/ +gCxkoApm6OcHzTCubMC0lccML0nWcIjpc0sSM2LV/SQuQDzMGM7pGC+3ufYgQvbTqZy bckTya1lqNu2Simf49V6Mf2W1xkNhAKiZTS/Kdi0VoTRU/ZqoaS/iQXfKovXoLM4PWq6 wCig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:date:cc:message-id :references:to; bh=kXvNRnIeN+rwT0tEkcdgcm0Xjd6CLoTqna0qvS1HDcM=; b=bVn1ySCzn7k4xV8TFXpNNWmXgULt7j7hAPonzZ+iqJKZWMoE+RxQyriO9Lds3YFpga LdPqACv0TEJqlYHvSneezJlbwX3tmhDbLbw9QInJ6/hxjR+2jy/9DS6NaOt4QJwnBZvW 6peOP6E+q1ihvvK+bKtbblmIPOEZVB2zLruChYFqwbxBjlK0dos9i8Xl/6rc/GiC4jmi k/vl9+0cKVJLajs9gdKFGmOfklTngAGXUIvK5JhEn9uBchlv6J1nK29TVVORSlCvQ7DO eqrY6SAmEYKbxIKl8BEpOcdqsCzFYFW0/DvpIo6VwxCgdq3PLjYfeqDhb+c4RQKA3ilA M6XQ== X-Gm-Message-State: AOPr4FVTN8rBx3a5chSViMKwZ3MlPPy1k9c/Ra1I8qTpqMxtbdhpEGxXhQXw8+WQ2sgxBA== X-Received: by 10.13.219.16 with SMTP id d16mr6806112ywe.9.1461784584948; Wed, 27 Apr 2016 12:16:24 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id b126sm2708480ywd.3.2016.04.27.12.16.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 12:16:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C7530B2C-7E85-4EDF-A439-176333AC38A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden Date: Wed, 27 Apr 2016 12:16:20 -0700 Message-Id: <69198EB8-F3AA-454B-B0C7-1861F51BDA03@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:16:27 -0000 --Apple-Mail=_C7530B2C-7E85-4EDF-A439-176333AC38A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the third 6man w.g. version (-02) of the RFC4291bis draft. = See links below. The change in this version is: Remove changes made by RFC7371 because there isn't any known implementation experience. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-02 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > 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. >=20 > Title : IP Version 6 Addressing Architecture > Authors : Robert M. Hinden > Stephen E. Deering > Filename : draft-ietf-6man-rfc4291bis-02.txt > Pages : 30 > Date : 2016-04-27 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-02 >=20 --Apple-Mail=_C7530B2C-7E85-4EDF-A439-176333AC38A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXIRAFAAoJEK7rdBF357uo3MsIAJ/ihlVEVynw7shH02QZwFrp h1zilaa5gJa4JP1736ujZYZ5Er1WuUZlwNO8fcieilUXfE2CFnMLRSrGdkWEuMc+ zUano9v1JA/btep6Czh6P2d/PsPcEs0euNI/4rxVl+/vuN7vNUI4GY9TMuvnkSJn PKkP5OrSkpHTbecRKotmuLdTzDglEBJ/z7euXk3CD85XfDXn9688lusEltm+UEN8 fdR2ZHyK+8p9eXcIyAn0UCxGi+mc0qx5pAFxq3wekbQumPo/gk/jrY+v9Fkkp9co oaPBJ6mvRMFfAjqNDCXgN16ruqfAAOBRI9PnN21dUm7/k3aT0AM8+/zl7aGi3Cs= =ePaX -----END PGP SIGNATURE----- --Apple-Mail=_C7530B2C-7E85-4EDF-A439-176333AC38A2-- From nobody Wed Apr 27 13:03:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E477A12D56A for ; Wed, 27 Apr 2016 13:03: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 ICe9X9mWZbUZ for ; Wed, 27 Apr 2016 13:03:09 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 B733812DB57 for ; Wed, 27 Apr 2016 13:03:09 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id bt5so23165244pac.3 for ; Wed, 27 Apr 2016 13:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1yTisAlo0GoCSL75cXDXQI1j2l0TCxTiCxwUCFme/Ss=; b=xEzcspx4Fto3F5JF7nQXoft8u7CQfj1jGAe2rx3I4CFubTDL/WlnEeE0pReuv0MGdw lFrPnQ2yypkH1gGURkDXYhAwF3BkvpUSbS8PXtBriSK/SosC2KX0LvwVrKxF++TT+ty2 rwHexNBpD5myLhkNmtncq9vcFyzTGQ1GziRhFSvi0cDINEloiAhMZtGp1Y1b2FmT+SpZ Li/ZxNZMQKmlzmLjwdoMEfYxxsErkpUYPFrq+i8kVVd8znMgBS99ZJJ9KGa4U52MejRO kyZt95hPYGuaEgs56yac+nXlb1w4JB+EIDJyPlZKeIftfsp/moj5kj/95sV9Gr3PZcd1 XjKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1yTisAlo0GoCSL75cXDXQI1j2l0TCxTiCxwUCFme/Ss=; b=dy9aS8KZzqU0geE4D9fs1AA20tee9BKG1lM6LhklqDu+EvC+iUY+9l3W5xIS6/lrVQ +lNwGkKfS09cygoxxBGaTseFFEOvzGXALNY0h5kgTRNPKZf8iecgj0PE6CbfGc87dr08 SRuIbuXHQ1zDYbrxpwhkfHjK/KeW1qQe56qsPlhc/RhkQHMSr+19MnAFJTcXjU0jdHYk qV1pe5ckBeeqPVEwptYdOA7+4syMhGZv9y33+4oDxioRFzsUarHlzfV0Lh5tV7fXV/VE HFNcYh/Thdj4JbbNAl81BuaOAU+Q4KlFpVuGO1nNIQ/HlQko1LyfYNDRqyXjuDtKxDsI rgNg== X-Gm-Message-State: AOPr4FXApgH+jZnahHAldwfZUEi95xBbAhTTEIFqodWSx7fGdVclAkEIx3SrImWN2Vw0Dw== X-Received: by 10.66.88.104 with SMTP id bf8mr14782915pab.129.1461787389311; Wed, 27 Apr 2016 13:03:09 -0700 (PDT) Received: from ?IPv6:2406:e007:6337:1:28cc:dc4c:9703:6781? ([2406:e007:6337:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p1sm10221403paz.8.2016.04.27.13.03.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 13:03:07 -0700 (PDT) Subject: Re: To: Bob Hinden , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <69198EB8-F3AA-454B-B0C7-1861F51BDA03@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <101aaa3c-e185-a3c6-86f7-54840224002d@gmail.com> Date: Thu, 28 Apr 2016 08:03:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <69198EB8-F3AA-454B-B0C7-1861F51BDA03@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 20:03:11 -0000 On 28/04/2016 07:16, Bob Hinden wrote: > Hi, > > I published the third 6man w.g. version (-02) of the RFC4291bis draft. See links below. > > The change in this version is: > > Remove changes made by RFC7371 because there isn't any known > implementation experience. That seems to be correct, but it will leave Proposed Standard RFC7371 in a rather strange state after 4291bis is published. It (RFC7371) will be listed as updating an RFC which is itself obsoleted by an RFC that effectively overrides RFC7371 without saying so. I have no opinion about the value of RFC7371, but this situation makes my head hurt slightly. 7371--updates-->4291 ^ ^ | | overrides obsoletes \ / \--4291bis--/ Brian From nobody Wed Apr 27 14:19:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA412DC2F for ; Wed, 27 Apr 2016 14:19:13 -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 KAnW-brRZMp4 for ; Wed, 27 Apr 2016 14:19:12 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 1D07A12DA2D for ; Wed, 27 Apr 2016 14:19:12 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x19so63334777oix.2 for ; Wed, 27 Apr 2016 14:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=x9McLm/Uwz2q+nAoGSWnE1ZCulA2KC9skDYhCMPYjmA=; b=sNw3l5yurPOPap3L32qAyWCqMs0P+CgyZ6+Smgmnf73cqCZP7eRb8bz28Vb70aqA0j lBSgzkHA0+v83XdVl+I4Rnvx7dZdeLfw6gmm5N+zVRkqCXIXDFxX7BcgCvbnxPDsi/7j 0DYoQX22vXtIukg5c0hiDXho8lii7w62vul1DXUMI3Y/ZNQqNlzOIua6/+AGtsd8E3vz 3YSAYhQ4oA0mUZGsZ+urWCSDHyUSq1VCssgFOLeNRrOUZxMhNn6u/8ilcxULbzJDWl2a tt0QSC9ZtuJ/5dMfN0614S7gxGEByXPWTvJGIFGAo0a7C3cxuES6JgNKs17qDsYJDvEX 5hHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=x9McLm/Uwz2q+nAoGSWnE1ZCulA2KC9skDYhCMPYjmA=; b=Gotcgmo9P1Oc6YDjoOvfTSJxlqioCTVW3TrzjPRLHVocgCwlMVFgWSXuWPLkhMxkWj FlVeE4S6++VwMZxhcUBP5HlomfdJRtvvKNZEm1dZrZsaeIP379N7V5F21Azb7Qzv+Yo+ Q3gHpnSw84zZuU3y05wSMc3on3Fg3ps4qCSMlBoYAparGGIAVXz2Osjc6x+6s9lp7HMY aTytFDnnhNSAjvNEMA6/eKzteqzKocdfpb7fLfoE7xirbNFvaG4AByfd9SRkk0e5COfF TArLit1xydyN2g5UOHpYow6WJxDBCObX2KT0J9kca1Xc9DeW78QLetMgyy0DLFKMHP+O 273A== X-Gm-Message-State: AOPr4FVjv8j/K345GjOBAkPwgECqCy+OHly4YsO2KFl6/TVlPatwBI7lBVAipsIHnRA5Jg== X-Received: by 10.157.18.143 with SMTP id g15mr4578678otg.125.1461791951452; Wed, 27 Apr 2016 14:19:11 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d3sm1874605obq.24.2016.04.27.14.19.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 14:19:10 -0700 (PDT) Subject: Re: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9F010338-D3EF-4F9A-A14C-481716AF858F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <101aaa3c-e185-a3c6-86f7-54840224002d@gmail.com> Date: Wed, 27 Apr 2016 14:19:08 -0700 Message-Id: <0E8BA6F9-278A-4A7C-BD71-BAF45FA81DDD@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <69198EB8-F3AA-454B-B0C7-1861F51BDA03@gmail.com> <101aaa3c-e185-a3c6-86f7-54840224002d@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 21:19:14 -0000 --Apple-Mail=_9F010338-D3EF-4F9A-A14C-481716AF858F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, > On Apr 27, 2016, at 1:03 PM, Brian E Carpenter = wrote: >=20 > On 28/04/2016 07:16, Bob Hinden wrote: >> Hi, >>=20 >> I published the third 6man w.g. version (-02) of the RFC4291bis = draft. See links below. >>=20 >> The change in this version is: >>=20 >> Remove changes made by RFC7371 because there isn't any known >> implementation experience. >=20 > That seems to be correct, but it will leave Proposed Standard RFC7371 = in > a rather strange state after 4291bis is published. It (RFC7371) will = be listed > as updating an RFC which is itself obsoleted by an RFC that = effectively > overrides RFC7371 without saying so. There is the note in the Appendix change log. I suppose as part of the = advancement package we would make RFC7371 historic. Bob >=20 > I have no opinion about the value of RFC7371, but this situation makes > my head hurt slightly. >=20 > 7371--updates-->4291 > ^ ^ > | | > overrides obsoletes > \ / > \--4291bis--/ >=20 > Brian --Apple-Mail=_9F010338-D3EF-4F9A-A14C-481716AF858F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXISzMAAoJEK7rdBF357uo/TwH/3PXPol2ei429qXpRB3eNs63 72Pp51+pfe5JMUp8aBc3sp0lj9h3Lhy1nkFxxhxjJYGvASsfxKpe/Prz3A8NKTqW R8bFmKnqE1TEJ/bLUAnY10HsW0F2beHmBJ1Qht3BJlp+I9ypQ+1Dt0HI4C8QbTaA TVgHtwTetFmj+zV/Of7vRRo8k+oMfdFk6x1GxBoNXn5XTENt75+IjOAmqWRZEKDg ajSVNYcMyvBmlLqvaSRba9G7Tuk5F7ao0PuQcHNsQRg2GSfpq+ti+4fgxhnMTyBx 6W+823kTeq782iK95YDbp56BwSMrcGg0X/C2Hpag94ujRugF+2CTAfiYqv+gM2Q= =iAg7 -----END PGP SIGNATURE----- --Apple-Mail=_9F010338-D3EF-4F9A-A14C-481716AF858F-- From nobody Wed Apr 27 17:49:05 2016 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 5C16712D137; Wed, 27 Apr 2016 17:49:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-default-iids-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 17:49:04 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 00:49:04 -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 : Recommendation on Stable IPv6 Interface Identifiers Authors : Fernando Gont Alissa Cooper Dave Thaler Will Liu Filename : draft-ietf-6man-default-iids-11.txt Pages : 23 Date : 2016-04-27 Abstract: This document changes the default scheme for generating stable Interface Identifiers with SLAAC to that specified in RFC7217, and recommends against embedding link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121, by removing the text in these RFCs that required the IPv6 Interface Identifiers to be derived from the underlying link-layer address, and replacing the aforementioned text with a pointer to this document. Additionally, this document updates RFC3315 by specifying additional requirements on the generation of Interface Identifiers used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It also provides advice to system administrators who employ manual configuration. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-default-iids-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-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 Wed Apr 27 18:18:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2C12D0C8 for ; Wed, 27 Apr 2016 18:18:51 -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 WogSnF_9g2ys for ; Wed, 27 Apr 2016 18:18:50 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 3D36912B040 for ; Wed, 27 Apr 2016 18:18:50 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g133so93978723ywb.2 for ; Wed, 27 Apr 2016 18:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:message-id:cc:to:mime-version; bh=N6M2C+5C3IJr316wmKP4LHvESBrkIpvNlgyOOJ0Qjog=; b=YqmbVflW+ioXFYW5JMBHYBqm2PCirJsfpMy1WJNYCH+B4kaW9sMJt77UN1HgBI8EiI EpQCBLi14+6eFZavnEaDOvqtCxIvw6kQ8ekbSZ49gfvlDB9lqh3FBfecPZRAEpfYNSMe KWgW5c7rzTyT/qiJniSQ3GsXrc8/kJBBsQKrg1Y4+m8oZLveHmxmseoe9k9IfPWCH1p7 v5veq2dZ/ByL5+EI9psEEos60+C6V2nCBJEySDUJN2m7S9X6DEnaxWHVZTzgF08oLGeG DK84begnjvbJ8qY6oM1ceVBMeaZwJxzWoRTQuCe7EqOPmvyli4HiBD4TwmJj8J7+ZhHU eDqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=N6M2C+5C3IJr316wmKP4LHvESBrkIpvNlgyOOJ0Qjog=; b=SUr+tktaQvJNiJ7PLx2E/lqYqUFAEtjD+7WTukPK8VB9ClVpnpoM5KLDW/IpkMxeBK 34hEghd/u6G7efU+/DP+O+L21KhCU/8FWuPwN5BBRlnUGRY5IdeCmXR2a7+rEOY2I7R0 eXtwhXLAYfLX+kONI37hkDiVFuOhSaH80vQkumvy42OLYKm34l5+o3xd2vDMAJemlYSC GXKRouOsk/+7vb9Xbko6RjAfeH+496Pn/6O19G2oIiJ6rk4FK4hFREzTOXH1shLFqXe0 0OMDp0GVUTD3jALY5QPM7fbbFv6Itbmnw3+cLqOBEq7pjXMsLT5G1xzfcHq5cBZjySZC tGXw== X-Gm-Message-State: AOPr4FUVq9dEJuE103qWWdxU0aw35MMCNUfy0jpa4qRv3bSar1E62uy+s3DlMkKG0SWhPw== X-Received: by 10.129.101.139 with SMTP id z133mr7536362ywb.153.1461806329521; Wed, 27 Apr 2016 18:18:49 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:896f:cfff:5225:be7e? ([2601:647:4d00:abf0:896f:cfff:5225:be7e]) by smtp.gmail.com with ESMTPSA id l188sm3489857ywc.0.2016.04.27.18.18.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 18:18:48 -0700 (PDT) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_3884D511-0BDA-48DF-916E-DD751EE8BEC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Inserting Extension Headers or not [was rfc2460bis question ] Date: Wed, 27 Apr 2016 18:18:47 -0700 Message-Id: To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 01:18:52 -0000 --Apple-Mail=_3884D511-0BDA-48DF-916E-DD751EE8BEC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I would like to get closure on the question if inserting IPv6 extension = headers is allowed or not, and should this be a clarification in = rfc2460bis. This topic was discussed in Buenos Aires and on the mailing = list. The relevant text from Section 4 "IPv6 Extension Headers" in = Extension headers must never be inserted by any node other than the source of the packet. IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]. This text was added to the draft in version =E2=80=9401 published on 2 = November 2015. The question is if this text was the original intent of rfc2460. That = would allow it to be part of rfc2460bis going to Internet Standard. If = it is a change, then it should not be included. In my personal view (as one of the authors of rfc2460), I think it was = the original intent to not allow extension headers to be inserted. My = thinking is that not allowing extension headers to be inserted is = related the design of IPv6 that includes only supporting fragmentation = at the source. IPv4 allows the addition of options resulting in = changing the header length, but it includes per-hop fragmentation so any = resulting MTU issues can be dealt with. Even IPv4 fragments can be = fragmented. I think it is a consequence of IPv6 not allow per-hop = fragmentation, that extension headers were not intended to be inserted = along the path to the destination. Note, I think it would be fine for someone to document how to do = extension header insertion, as long as they describe how it works, and = how to deal issues like MTU problems. This can be be an update to = rfc2460bis (after it is published). However, I do not think leaving the rfc2460bis text in an ambiguous = state on this topic is a good idea. Comments? Thanks, Bob --Apple-Mail=_3884D511-0BDA-48DF-916E-DD751EE8BEC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXIWT4AAoJEK7rdBF357uo6S8H/js4nxXBnmgzre1ID0LqpEb9 M1f+1t25RJ8J+dHHy7EirllSrCB4HfgODJ1RW1IAzeQee2kMHJ96o+MJEARv0tg2 eNt3mSwmjnQxeyEK9j42VkaZc+UMKc/Dj24rr10qGerI76gD9cjF2I1nBlVQkvLn FuGMIT16XsGbaWbIRq8zwEPXxoJ08z+oOpOm2vS4KQz/M+Ffll4M7iFzHcMB8BS9 jO29DrEiq7CmZtga1MwlhwfeyKyuwsSe/ZETOdZKLMqetvv6UQLIM5vYZyGYHxMh dnCw3lnUYYVEFOC36mcymK1O8pDhVLi1Dvd34gGRqEh1kZu28oK1u6D1oPszEAo= =ZeAD -----END PGP SIGNATURE----- --Apple-Mail=_3884D511-0BDA-48DF-916E-DD751EE8BEC1-- From nobody Wed Apr 27 19:55:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376D12D59B for ; Wed, 27 Apr 2016 19:55:04 -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 gSUs_7HPNLa9 for ; Wed, 27 Apr 2016 19:55:02 -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 1BA8F12D524 for ; Wed, 27 Apr 2016 19:55:01 -0700 (PDT) Received: from [192.168.3.104] (192-174-17-190.fibertel.com.ar [190.17.174.192]) (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 44B37806C4; Thu, 28 Apr 2016 04:54:55 +0200 (CEST) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] To: Bob Hinden , IPv6 List References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <572173BB.7090709@si6networks.com> Date: Wed, 27 Apr 2016 23:21:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 02:55:05 -0000 On 04/27/2016 10:18 PM, Bob Hinden wrote: > Hi, > > I would like to get closure on the question if inserting IPv6 > extension headers is allowed or not, and should this be a > clarification in rfc2460bis. This topic was discussed in Buenos > Aires and on the mailing list. > > The relevant text from Section 4 "IPv6 Extension Headers" in > > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > This text was added to the draft in version —01 published on 2 > November 2015. > > The question is if this text was the original intent of rfc2460. > That would allow it to be part of rfc2460bis going to Internet > Standard. If it is a change, then it should not be included. > > In my personal view (as one of the authors of rfc2460), I think it > was the original intent to not allow extension headers to be > inserted. My thinking is that not allowing extension headers to be > inserted is related the design of IPv6 that includes only supporting > fragmentation at the source. IPv4 allows the addition of options > resulting in changing the header length, but it includes per-hop > fragmentation so any resulting MTU issues can be dealt with. Even > IPv4 fragments can be fragmented. I think it is a consequence of > IPv6 not allow per-hop fragmentation, that extension headers were not > intended to be inserted along the path to the destination. > > Note, I think it would be fine for someone to document how to do > extension header insertion, as long as they describe how it works, > and how to deal issues like MTU problems. This can be be an update > to rfc2460bis (after it is published). > > However, I do not think leaving the rfc2460bis text in an ambiguous > state on this topic is a good idea. > > Comments? FWIW, I agree with the comments you made above. (the spec should be clarified, and if there is going to be a change to allow the insertion of EHs, that should be the result of an explicit proposal to change rfc2460 or rfc2460bis). 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 Wed Apr 27 20:17:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EF112B077 for ; Wed, 27 Apr 2016 20:17:51 -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, 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 45NO8hrww1fZ for ; Wed, 27 Apr 2016 20:17:48 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 92F9512D544 for ; Wed, 27 Apr 2016 20:17:48 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id m188so16974721vka.1 for ; Wed, 27 Apr 2016 20:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ff4938FjOZ7uRPKwwYRIGcXRD3Gwv+hVFPd0aDJU7aI=; b=VI9oBVjMR/lhkwMk9xy47LBpMtcuRjrPSs7m7SoeC+j3F9CMrSu0LWmLOcB/4Xpc/J i3bgyWYvLvjKtXQnz6KWHQ+w1/LtXsyAkV9veeMepDZEyBOwcXbt7IExsCGH/DpgVKmQ OimSqVdT8bhn2GgnAL6aWP6zysyPDJYikONg9QozDXvX6kxENjAfHcBuDPODHtNSKEy2 lHFOT+llG4uybncv+dAOOO51qaoPzzK4PNDKXknsDIsgFaqNKx0zl0ew43YxCJ3Dp+eb dyM4dFD3PjV+lKzTQVex/nMmnLozE3jrmY9aMZUkFgZVjlgKbbA2aHbqMLPJss0xvBKY F64Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ff4938FjOZ7uRPKwwYRIGcXRD3Gwv+hVFPd0aDJU7aI=; b=jt6/Yw4AtCs0DosGgK1WkHIPrwBocwY7xOibokP8t7TidbejR7EhJsK9WD1sl37qBF L6G1mWslleHz7CO64LrxfBCUAj4Sddim1FO+ZQEsU850YTFfyfC5jV9ZkBJXF5j4V6Fy faK1VCxF0gUm1is+TnfWJm5XGxPpy0XymSFijG7xOOHjz9A477e/KzVbsqJvSUPOl5Pd XlgLo9eBXEUx6nkIJFIH10pV1LJSELSbxs8CnhqK/O5fcz7Wm9mO/loLbSDHaPbBdZRy +iAsKgygnsSZsK/N1p81juxYWmKblxO/EVIght/2QAyBeiL3sLbsJifKHlFVSQfHdRNb 65Rw== X-Gm-Message-State: AOPr4FXnEb9NnGOGPTOp7V9dgNflve4P0/bTKf8tYdPlqziCB6wW9lymO89plRQ3FeMYvrRl5gYf+DjablFiqA== MIME-Version: 1.0 X-Received: by 10.176.6.161 with SMTP id g30mr6561644uag.142.1461813467684; Wed, 27 Apr 2016 20:17:47 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Wed, 27 Apr 2016 20:17:47 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Wed, 27 Apr 2016 20:17:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 13:17:47 +1000 Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: Mark Smith To: Bob Hinden Content-Type: multipart/alternative; boundary=94eb2c047ca0782762053182f86c Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 03:17:51 -0000 --94eb2c047ca0782762053182f86c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 28 Apr 2016 11:19 AM, "Bob Hinden" wrote: > > Hi, > > I would like to get closure on the question if inserting IPv6 extension headers is allowed or not, and should this be a clarification in rfc2460bis. This topic was discussed in Buenos Aires and on the mailing list. > > The relevant text from Section 4 "IPv6 Extension Headers" in > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > This text was added to the draft in version =E2=80=9401 published on 2 No= vember 2015. > > The question is if this text was the original intent of rfc2460. That would allow it to be part of rfc2460bis going to Internet Standard. If it is a change, then it should not be included. > > In my personal view (as one of the authors of rfc2460), I think it was the original intent to not allow extension headers to be inserted. My thinking is that not allowing extension headers to be inserted is related the design of IPv6 that includes only supporting fragmentation at the source. IPv4 allows the addition of options resulting in changing the header length, but it includes per-hop fragmentation so any resulting MTU issues can be dealt with. Even IPv4 fragments can be fragmented. I think it is a consequence of IPv6 not allow per-hop fragmentation, that extension headers were not intended to be inserted along the path to the destination. > > Note, I think it would be fine for someone to document how to do extension header insertion, as long as they describe how it works, and how to deal issues like MTU problems. This can be be an update to rfc2460bis (after it is published). > > However, I do not think leaving the rfc2460bis text in an ambiguous state on this topic is a good idea. > > Comments? > I agree with being more strict, although I personally don't find the second and third paragraphs in the Extension Headers section on this topic (after the diagrams) to be ambiguous. I think there is some ambiguity about what specific actions are involved in "forwarding" (of both unicast and multicast) which has probably created the gap that people who want to add EHs have jumped thorough. Different sections permit certain things during forwarding e.g., increment hop count, change flow label etc., however I haven't come across a specific section in this RFC or any others that specifically define the complete set of actions involved in IPv6 "forwarding". Regards, Mark. > Thanks, > Bob > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c047ca0782762053182f86c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bob,

On 28 Apr 2016 11:19 AM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
> Hi,
>
> I would like to get closure on the question if inserting IPv6 extensio= n headers is allowed or not, and should this be a clarification in rfc2460b= is.=C2=A0 This topic was discussed in Buenos Aires and on the mailing list.=
>
> The relevant text from Section 4 "IPv6 Extension Headers" in= <draft-ietf-6man-rfc2460bis-04.txt>
>
> =C2=A0 =C2=A0Extension headers must never be inserted by any node othe= r than the
> =C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must be used= to meet any
> =C2=A0 =C2=A0requirement for inserting headers, for example, as define= d in
> =C2=A0 =C2=A0[RFC2473].
>
> This text was added to the draft in version =E2=80=9401 published on 2= November 2015.
>
> The question is if this text was the original intent of rfc2460.=C2=A0= That would allow it to be part of rfc2460bis going to Internet Standard.= =C2=A0 If it is a change, then it should not be included.
>
> In my personal view (as one of the authors of rfc2460), I think it was= the original intent to not allow extension headers to be inserted.=C2=A0 M= y thinking is that not allowing extension headers to be inserted is related= the design of IPv6 that includes only supporting fragmentation at the sour= ce.=C2=A0 IPv4 allows the addition of options resulting in changing the hea= der length, but it includes per-hop fragmentation so any resulting MTU issu= es can be dealt with.=C2=A0 Even IPv4 fragments can be fragmented.=C2=A0 I = think it is a consequence of IPv6 not allow per-hop fragmentation, that ext= ension headers were not intended to be inserted along the path to the desti= nation.
>
> Note, I think it would be fine for someone to document how to do exten= sion header insertion, as long as they describe how it works, and how to de= al issues like MTU problems.=C2=A0 This can be be an update to rfc2460bis (= after it is published).
>
> However, I do not think leaving the rfc2460bis text in an ambiguous st= ate on this topic is a good idea.
>
> Comments?
>

I agree with being more strict, although I personally don= 9;t find the second and third paragraphs in the Extension Headers section o= n this topic (after the diagrams) to be ambiguous.

I think there is some ambiguity about what specific actions = are involved in "forwarding" (of both unicast and multicast) whic= h has probably created the gap that people who want to add EHs have jumped = thorough.

Different sections permit certain things during forwarding e= .g., increment hop count, change flow label etc., however I haven't com= e across a=C2=A0 specific section in this RFC or any others that specifical= ly define the complete set of actions involved in IPv6 "forwarding&quo= t;.

Regards,
Mark.

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

--94eb2c047ca0782762053182f86c-- From nobody Wed Apr 27 20:26:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF96812D562 for ; Wed, 27 Apr 2016 20:26:35 -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 jZd8XxOp5eDD for ; Wed, 27 Apr 2016 20:26:33 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 0F8BA12D524 for ; Wed, 27 Apr 2016 20:26:33 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id n1so31437822pfn.2 for ; Wed, 27 Apr 2016 20:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dOJR1hslRevStF8dbR7nmquo4A1IrnnWSz2Nk9mkFMs=; b=Tl5E3gJ2PUUJ3z1pzU9J1Ep9n2fQ6R9sz/th0MXJ1ILDI7CNWbERn+QEzPQ/6S5abc psW5AC7Hso7Is1Ucwhx3xFyGxobCy6lRW7tM4gHvgBI/r77ABFwi7oFXmaG5NnVi+f90 GyMM0D5l96bXRCz5QjvO9HkvYaBRaO3xWmwUYYMkfU5h4vVNEh2J/7gCCCpnW92FGEgI pPqrp2R+dEiNFK2NkrFs+DHIrQ4mAEurGLtgF9fyo9qrE+leQXZ5UFZ/IkmLBF0D+f2d BPVkgSunAz7A8MnphzmkdwrmERJGI0pT3PM0dxnkcHT3J5FRL7ahfVCx6JKtPaTIQQ5Q eMpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dOJR1hslRevStF8dbR7nmquo4A1IrnnWSz2Nk9mkFMs=; b=QCn9gDIPMrIKL4B47PL7oBsQNQ24gRdz5ZRHwqlw0umkEU7cmUjY+Wd+n+R6XMnBCt oP2oPvStdPvU4Qe+SI4zuY/KefS6+FKNaUX5ZBBQKS7JWgjbNnJIMyuuiwAoHqjC7HtB vekRp2YgkNjX25pnKEiNZ7dofpT63Ya0afeXaOAU7Pk6xImmTxFkWykS8gNJZaRdjcdJ OW0G/FD0mH8ozbROmMnZ2RQH0+/5DAFaSuxnU9Wc2+GkSXD3PQTs2jVCTyhgcuPObIul jw9KGirlvQsFsQTefYvEidGglppQeCEEnvzMo+8cYzpebJ1vH4/49jTKzpo9f1JV2EHH EL2w== X-Gm-Message-State: AOPr4FXEl/ezOhboW4WF1D2WBTgbYy9txBgriFnz4rj3l+D4kkEbIUIB18aXmWx1O/oIeQ== X-Received: by 10.98.23.211 with SMTP id 202mr17110970pfx.122.1461813992592; Wed, 27 Apr 2016 20:26:32 -0700 (PDT) Received: from ?IPv6:2406:e007:6337:1:28cc:dc4c:9703:6781? ([2406:e007:6337:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x89sm10188689pfa.87.2016.04.27.20.26.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 20:26:31 -0700 (PDT) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] To: Bob Hinden , IPv6 List References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> Date: Thu, 28 Apr 2016 15:26:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 03:26:36 -0000 On 28/04/2016 13:18, Bob Hinden wrote: > Hi, >=20 > I would like to get closure on the question if inserting IPv6 extension= headers is allowed or not, and should this be a clarification in rfc2460= bis. This topic was discussed in Buenos Aires and on the mailing list. >=20 > The relevant text from Section 4 "IPv6 Extension Headers" in >=20 > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. >=20 > This text was added to the draft in version =E2=80=9401 published on 2 = November 2015. >=20 > The question is if this text was the original intent of rfc2460. That = would allow it to be part of rfc2460bis going to Internet Standard. If i= t is a change, then it should not be included. >=20 > In my personal view (as one of the authors of rfc2460), I think it was = the original intent to not allow extension headers to be inserted. My th= inking is that not allowing extension headers to be inserted is related t= he design of IPv6 that includes only supporting fragmentation at the sour= ce. IPv4 allows the addition of options resulting in changing the header= length, but it includes per-hop fragmentation so any resulting MTU issue= s can be dealt with. Even IPv4 fragments can be fragmented. I think it = is a consequence of IPv6 not allow per-hop fragmentation, that extension = headers were not intended to be inserted along the path to the destinatio= n. I think this exactly correct. I did a bit of archaeology and found the me= ssage where Steve Deering summarised the issues resolved before RFC 1883 (the p= redecessor of RFC 2460) was published in 1995. I've attached it below - look just af= ter "rejected at the Stockholm meeting" i.e. IETF 33. The comment that trigge= red it was in message (IPng 346) from Charlie Lynn sent 30 June 1995. [I knew my mail archives would be useful one day.] Brian > Note, I think it would be fine for someone to document how to do extens= ion header insertion, as long as they describe how it works, and how to d= eal issues like MTU problems. This can be be an update to rfc2460bis (af= ter it is published). >=20 > However, I do not think leaving the rfc2460bis text in an ambiguous sta= te on this topic is a good idea. >=20 > Comments? >=20 > Thanks, > Bob -------- Forwarded Message -------- Subject: (IPng 609) changes to Last Call'ed specs Date: Sun, 27 Aug 1995 20:59:26 PDT From: Steve Deering To: ipng@sunroof.eng.sun.com CC: deering@parc.xerox.com At the request of our ADs, I prepared the following list of agreed-upon changes and outstanding issues with the set of specs that underwent IETF-wide Last Call in June and July. Please let me know of any errors or omissions. Steve =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 IPv6 Specification ------------------ The following changes were posted to the IETF list immediately following the Last Call, so I think we can consider them to also have been Last Cal= led: - In the examples of how to lay out options, on page 29, two places where it says "Hdr Ext Len=3D1" should be "Hdr Ext Len=3D3" (reported by Hamid Asayesh). - In section 6, Flow Labels, I forgot to include the Priority field in the list of fields that must have the same value for all packets in the same flow (reported by Markus Jork). - The description of what the Jumbo Payload Length field covers should be made clearer (reported by Christian Huitema). The following changes were proposed by Charlie Lynn in the only "formal" response to the Last Call, and accepted at the first ipngwg meeting in Stockholm: - For options containing data that can change en-route (and which there= fore have the third-highest-order bit of their Option Type set to 1), make= it clear that *all* bytes of the Option Data field are to be excluded fr= om the Authentication function, and explain that "excluded" means "treat= ed as if they were all zero-valued bytes". - Change the Routing Header to enable it to be ignored by final destina= tions that do not understand the Routing Type. In Stockholm, Deering propo= sed, and the attendees agreed with, the following revised format for the first 32 bits of the Routing Header, for all Routing Types: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | where Hdr Ext Len is the length of the header in 8-octet units, not including the first 8 octets Segments Left is the number of "legs" left to traverse in the route; if this value is zero, the receiver may ignore this header (i.e., it indicates that the route has been completed), whether or not the receiver understands the Routing Type The following additional changes were agreed to either on the mailing lis= t or in the Stockholm meetings: - "Improve" the host/router terminology. What I propose to do is add a= footnote to the terminology section saying something like this: * it is possible, though unusual, to have a device with multiple interfaces configured to forward non-self-destined packets arriving from some set (fewer than all) of its interfaces, and to discard non-self-destined packets arriving from its other interfaces. Such a device must obey the protocol requirements for routers when receiving packets from, and interacting with neighbors over, the former (forwarding) interfaces. It must obey the protocol requirements for hosts when receiving packets from, and interacting with neighbors over, the latter (non- forwarding) interfaces. Comments? - Clarify the operation of Type 0 Routing Header by giving an example, showing the values of the header fields on each segment of the route.= - Clarify the handling of options, extension headers, Next Header field= s, etc. for fragmented packets by giving a few examples of packets befor= e and after fragmentation (suggested by Dimitry Haskins and others). - Specify that fragments cannot reassemble to form a jumbogram (suggest= ed by Craig Metz). ICMPv6 Specification -------------------- - Add note warning about the possibility of upper-layer header being truncated from the returned packet in an error message, due to large number of extension header bytes, which can defeat delivery of the error message to the guilty upper-layer protocol instance. - Delete description of pseudo-header, replacing it with a reference to= the description in the IPv6 spec (suggested by Alistair Bell and Marc Hasson). - Correct example of usage of the pointer in the Parameter Problem message on page 15, by changing "48" to "40" (reported by Dimitry Haskins and Francis Dupont). - Note that there is another exception to the "no ICMP error messages in response to multicasts" rule, which is "unrecognized option" Parameter Problem messages in response to options with high-order bits "10..." (reported by Dimity Haskins). Address Architecture Document ----------------------------- - Add definition of "link-local address" to the terminology section (suggested by Jim Bound). - Specify that "::" is a legal text representation of the Unspecified (all-zeros) Address (suggested by Francis Dupont). =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 The following suggestions in Charlie Lynn's formal response to the Last C= all were rejected at the Stockholm meeting: - Add a bit to the Routing Header indicating whether or not it was inserted into the packet en-route, i.e., by a node other than the packet's originator. reasons for rejection: insertion of extension headers en-route brea= ks PMTU-discovery and can result in ICMP error messages being sent to non-guilty parties. The desired effect can be achieved, and those problems avoided, by using en-route encapsulation (with optional Routing Header) rather than header insertion. - Change ICMP error messages to contain explicit fields identifying the= upper-layer protocol to which the error message should be delivered. reasons for rejection: considered unnecessary complexity to handle = the rare case of truncation of transport header from the returned packe= t because of too many extension header octets. Such error messages a= re still usable for problem diagnosis other than in the upper-layer itself, e.g., if logged at IPv6 layer or observed in a packet trace= =2E Will add warning to the ICMPv6 spec about consequences of long extension header on ICMP error message dispatching. - Change Security Considerations section of ICMPv6 spec to specify when= and how to include an Authentication Header in ICMP error messages. reasons for rejection: group consensus that this belongs in aa IPsec spec instead. =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 The following issues and suggestions have been discussed on the mailing l= ist since the base specs went to Last Call, but no group consensus on these i= ssues has been reached yet: - Fragmentation issues: - change the minimum reassembly buffer size to a number larger than 576? - specify that sources of fragmented packets must use the minimal number of fragments required to fit in the perceived PMTU? - specify that all fragments with the M bit set must be no less than 7 octets shorter than the perceived PMTU? - specify that all fragments with the M bit set must be no shorter than 576 octets? - ignore fragments that partially overlap other fragments of the same packet, or discard any packet that arrives as partially overlapping fragments? - Routing Header issues: - add a "Total Length" field to the fragment header, carrying the length of the original, unfragmented packet? - forbid forwarding of packets with Routing Headers by hosts? (if not, make it clearer that hosts are expected to forward packets with Routing Headers, if they are intermediate targets of such packets.) - specify the reversing rules for packets that are responses to packets that carry a Routing Header? - forbid or discourage reversal of an unauthenticated Routing Header? - forbid or discourage acceptance of a packet with an unauthenticated Routing Header? - Allow the transport-layer checksum to be omitted when the Authenticat= ion header (or the ESP header?) is being used? - Add a Congestion Indication bit to the base IPv6 header? - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields and functions? - Build a single Terminology document, to be shared (either by referenc= e or inclusion) in all IPv6-related specs? - Allow the use of zero in the UDP Length field to indicate that the UD= P length should be derived from the Jumbogram Option? Note: the above list does not include issues concerning those specs that have not yet been subjected to WG or IETF Last Call, e.g., the Neighbor Discovery spec. -------------------------------------------------------------------------= ----- IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-mai= n.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From nobody Thu Apr 28 01:33:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1F12B055 for ; Thu, 28 Apr 2016 01:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.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 W6rBXVVYtzYG for ; Thu, 28 Apr 2016 01:33:45 -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 AB8BB12B021 for ; Thu, 28 Apr 2016 01:33:44 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0083.outbound.protection.outlook.com [213.199.154.83]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-20-0nzFGVcCQAi1OgBFzkHfPg-1; Thu, 28 Apr 2016 09:33:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hc4f2deGEewxE6XGljBCRSqe2zqm1QP4+CcP1zzJXuE=; b=d5O+1BtG9GrK8PVemWs4LxqFvgsYNxhp//2b50f4zkqA2r8m20MrNTleQDIMHf5TC1IXGWLr2wmGspPZzJwNXAGLqXgC+sHA59MWHoEnJB3/ucWstE2DBFiXQUZzW1DX2C2S6xFWR/4lLmfgm3jhBh4px8TU29QZwheC0H4Ql2U= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 28 Apr 2016 08:33:36 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0466.027; Thu, 28 Apr 2016 08:33:36 +0000 From: Tim Chown To: Brian E Carpenter Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoP3VlQq8Gt0oREW1V7Q/DtgVAJ+fD1OA Date: Thu, 28 Apr 2016 08:33:36 +0000 Message-ID: <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> References: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> In-Reply-To: <988dcc9d-102e-735c-68a8-3aaa46059786@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.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: e1465460-37f6-45fa-0188-08d36f3fca95 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:yFGHSRH8MoyBsQ7y59NG7d7tiUwu7QMeqAgpcP0fTyT90taUxiIkvmecmUG2bLKPYJZJmPOMxdTse3ehXvD+kzTzmmyEsKuQi8fm1cVeL0qH83FtPUDfsS7x05pfmMKgMoMPSBXCmS5mNirovPaA1g==; 24:jBc07mXfgBOWc4wKU1zyiv5RfAfeRoQ1gEoB/iQbjofyF0dh/u8oLvFJpkHzd6l71pt2/Xq3YxHdU4Y39AsYSlVo5RDydu/cxUS9DvBU+FE=; 7:phj5zW47MDHex8+3HXLw9xZFv2qoW60W846AFM+QGEPfboFcEjVInHWnnpEBlWIKLVBsOFPSos3Ic6BJJaMXECC80P4SKIyLKR44pyE1RWqv+QvR8QGthaOxH99aPHz6JWJ+4qdVOkkjSGubODpSqH25eYWKZGPKb8L/WFVe/a4NFOB7gTcnJKc2h4V7KD5b; 20:ZusiwE1Pc46BqpCEbUYe+ywJz68gVFE0z4HnbXsqptUJpgZfBcHhKT4HmYT6tVVnr9oWaL4TjTrR+iyynoFpv0egPfAX6T5WwxESWNXT+ldMoNbOoet8KGDOq6vBRrxD2xIGQPp6SAbfQCfPzXL75MZo4UQzDNRJFI555E22vRg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(50226002)(76176999)(122556002)(50986999)(74482002)(4326007)(102836003)(1220700001)(1096002)(586003)(77096005)(3846002)(6116002)(57306001)(83716003)(19580405001)(19580395003)(66066001)(81166005)(82746002)(5008740100001)(189998001)(2950100001)(2900100001)(15975445007)(33656002)(11100500001)(110136002)(5002640100001)(10400500002)(5004730100002)(106116001)(36756003)(5890100001)(86362001)(3660700001)(2906002)(3280700002)(92566002)(87936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <66C3FF4D59AE184C8944B9CE9FEDC367@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 08:33:36.0195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: 0nzFGVcCQAi1OgBFzkHfPg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 08:33:49 -0000 SGksDQoNCj4gT24gMjggQXByIDIwMTYsIGF0IDA0OjI2LCBCcmlhbiBFIENhcnBlbnRlciA8YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIDI4LzA0LzIwMTYgMTM6 MTgsIEJvYiBIaW5kZW4gd3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4gSSB3b3VsZCBsaWtlIHRvIGdl dCBjbG9zdXJlIG9uIHRoZSBxdWVzdGlvbiBpZiBpbnNlcnRpbmcgSVB2NiBleHRlbnNpb24gaGVh ZGVycyBpcyBhbGxvd2VkIG9yIG5vdCwgYW5kIHNob3VsZCB0aGlzIGJlIGEgY2xhcmlmaWNhdGlv biBpbiByZmMyNDYwYmlzLiAgVGhpcyB0b3BpYyB3YXMgZGlzY3Vzc2VkIGluIEJ1ZW5vcyBBaXJl cyBhbmQgb24gdGhlIG1haWxpbmcgbGlzdC4NCj4+IA0KPj4gVGhlIHJlbGV2YW50IHRleHQgZnJv bSBTZWN0aW9uIDQgIklQdjYgRXh0ZW5zaW9uIEhlYWRlcnMiIGluIDxkcmFmdC1pZXRmLTZtYW4t cmZjMjQ2MGJpcy0wNC50eHQ+DQo+PiANCj4+ICAgRXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBuZXZl ciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZSBvdGhlciB0aGFuIHRoZQ0KPj4gICBzb3VyY2Ugb2Yg dGhlIHBhY2tldC4gIElQIEVuY2Fwc3VsYXRpb24gbXVzdCBiZSB1c2VkIHRvIG1lZXQgYW55DQo+ PiAgIHJlcXVpcmVtZW50IGZvciBpbnNlcnRpbmcgaGVhZGVycywgZm9yIGV4YW1wbGUsIGFzIGRl ZmluZWQgaW4NCj4+ICAgW1JGQzI0NzNdLg0KPj4gDQo+PiBUaGlzIHRleHQgd2FzIGFkZGVkIHRv IHRoZSBkcmFmdCBpbiB2ZXJzaW9uIOKAlDAxIHB1Ymxpc2hlZCBvbiAyIE5vdmVtYmVyIDIwMTUu DQo+PiANCj4+IFRoZSBxdWVzdGlvbiBpcyBpZiB0aGlzIHRleHQgd2FzIHRoZSBvcmlnaW5hbCBp bnRlbnQgb2YgcmZjMjQ2MC4gIFRoYXQgd291bGQgYWxsb3cgaXQgdG8gYmUgcGFydCBvZiByZmMy NDYwYmlzIGdvaW5nIHRvIEludGVybmV0IFN0YW5kYXJkLiAgSWYgaXQgaXMgYSBjaGFuZ2UsIHRo ZW4gaXQgc2hvdWxkIG5vdCBiZSBpbmNsdWRlZC4NCj4+IA0KPj4gSW4gbXkgcGVyc29uYWwgdmll dyAoYXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHJmYzI0NjApLCBJIHRoaW5rIGl0IHdhcyB0aGUg b3JpZ2luYWwgaW50ZW50IHRvIG5vdCBhbGxvdyBleHRlbnNpb24gaGVhZGVycyB0byBiZSBpbnNl cnRlZC4gIE15IHRoaW5raW5nIGlzIHRoYXQgbm90IGFsbG93aW5nIGV4dGVuc2lvbiBoZWFkZXJz IHRvIGJlIGluc2VydGVkIGlzIHJlbGF0ZWQgdGhlIGRlc2lnbiBvZiBJUHY2IHRoYXQgaW5jbHVk ZXMgb25seSBzdXBwb3J0aW5nIGZyYWdtZW50YXRpb24gYXQgdGhlIHNvdXJjZS4gIElQdjQgYWxs b3dzIHRoZSBhZGRpdGlvbiBvZiBvcHRpb25zIHJlc3VsdGluZyBpbiBjaGFuZ2luZyB0aGUgaGVh ZGVyIGxlbmd0aCwgYnV0IGl0IGluY2x1ZGVzIHBlci1ob3AgZnJhZ21lbnRhdGlvbiBzbyBhbnkg cmVzdWx0aW5nIE1UVSBpc3N1ZXMgY2FuIGJlIGRlYWx0IHdpdGguICBFdmVuIElQdjQgZnJhZ21l bnRzIGNhbiBiZSBmcmFnbWVudGVkLiAgSSB0aGluayBpdCBpcyBhIGNvbnNlcXVlbmNlIG9mIElQ djYgbm90IGFsbG93IHBlci1ob3AgZnJhZ21lbnRhdGlvbiwgdGhhdCBleHRlbnNpb24gaGVhZGVy cyB3ZXJlIG5vdCBpbnRlbmRlZCB0byBiZSBpbnNlcnRlZCBhbG9uZyB0aGUgcGF0aCB0byB0aGUg ZGVzdGluYXRpb24uDQo+IA0KPiBJIHRoaW5rIHRoaXMgZXhhY3RseSBjb3JyZWN0LiBJIGRpZCBh IGJpdCBvZiBhcmNoYWVvbG9neSBhbmQgZm91bmQgdGhlIG1lc3NhZ2UNCj4gd2hlcmUgU3RldmUg RGVlcmluZyBzdW1tYXJpc2VkIHRoZSBpc3N1ZXMgcmVzb2x2ZWQgYmVmb3JlIFJGQyAxODgzICh0 aGUgcHJlZGVjZXNzb3INCj4gb2YgUkZDIDI0NjApIHdhcyBwdWJsaXNoZWQgaW4gMTk5NS4gSSd2 ZSBhdHRhY2hlZCBpdCBiZWxvdyAtIGxvb2sganVzdCBhZnRlcg0KPiAicmVqZWN0ZWQgYXQgdGhl IFN0b2NraG9sbSBtZWV0aW5nIiBpLmUuIElFVEYgMzMuIFRoZSBjb21tZW50IHRoYXQgdHJpZ2dl cmVkDQo+IGl0IHdhcyBpbiBtZXNzYWdlIChJUG5nIDM0NikgZnJvbSBDaGFybGllIEx5bm4gc2Vu dCAzMCBKdW5lIDE5OTUuDQo+IA0KPiBbSSBrbmV3IG15IG1haWwgYXJjaGl2ZXMgd291bGQgYmUg dXNlZnVsIG9uZSBkYXkuXQ0KDQpTdHVubmluZyByZWNvbGxlY3Rpb24gcG93ZXJzIEJyaWFuIQ0K DQpUaGUgcGFyYWdyYXBoIHlvdSBwb2ludCB0bywgaS5lLjoNCg0KCSJyZWFzb25zIGZvciByZWpl Y3Rpb246IGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBlbi1yb3V0ZSBicmVha3MNCiAg ICAgCVBNVFUtZGlzY292ZXJ5IGFuZCBjYW4gcmVzdWx0IGluIElDTVAgZXJyb3IgbWVzc2FnZXMg YmVpbmcgc2VudCB0bw0KICAgICAJbm9uLWd1aWx0eSBwYXJ0aWVzLiAgVGhlIGRlc2lyZWQgZWZm ZWN0IGNhbiBiZSBhY2hpZXZlZCwgYW5kIHRob3NlDQogICAgIAlwcm9ibGVtcyBhdm9pZGVkLCBi eSB1c2luZyBlbi1yb3V0ZSBlbmNhcHN1bGF0aW9uICh3aXRoIG9wdGlvbmFsDQogICAgIAlSb3V0 aW5nIEhlYWRlcikgcmF0aGVyIHRoYW4gaGVhZGVyIGluc2VydGlvbi7igJ0NCg0Kc3RpbGwgc2Vl bXMgdmFsaWQgdG8gbWUsIGFuZCB0aHVzIEkgYWdyZWUgd2l0aCBCb2LigJlzIHByb3Bvc2FsLiBX aGV0aGVyIHRoZSBhYm92ZSByYXRpb25hbGUgaXMgYWxzbyBpbmNsdWRlZCBpcyBhbiBhZGRpdGlv bmFsIHF1ZXN0aW9uLg0KDQpGb3IgZXhhbXBsZSwgaW4gc2VjdGlvbiAyLjIgb2ZkcmFmdC1pZXRm LTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciwgaXQgc3RhdGVzOiAiQXQgdGhlIGluZ3Jlc3Mg bm9kZSBvZiBhbiBTUiBkb21haW4gd2hlcmUgdGhlIGluZ3Jlc3Mgbm9kZSByZWNlaXZlcyBhbiBJ UHY2IHBhY2tldCBhbmQgZW5jYXBzdWxhdGVzIGl0IGludG8gYW4gb3V0ZXIgSVB2NiBoZWFkZXIg Zm9sbG93ZWQgYnkgYSBTZWdtZW50IFJvdXRpbmcgaGVhZGVyLiINCg0KVGltDQoNCj4gICAgQnJp YW4NCj4gDQo+PiBOb3RlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGZpbmUgZm9yIHNvbWVvbmUgdG8g ZG9jdW1lbnQgaG93IHRvIGRvIGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0aW9uLCBhcyBsb25nIGFz IHRoZXkgZGVzY3JpYmUgaG93IGl0IHdvcmtzLCBhbmQgaG93IHRvIGRlYWwgaXNzdWVzIGxpa2Ug TVRVIHByb2JsZW1zLiAgVGhpcyBjYW4gYmUgYmUgYW4gdXBkYXRlIHRvIHJmYzI0NjBiaXMgKGFm dGVyIGl0IGlzIHB1Ymxpc2hlZCkuDQo+PiANCj4+IEhvd2V2ZXIsIEkgZG8gbm90IHRoaW5rIGxl YXZpbmcgdGhlIHJmYzI0NjBiaXMgdGV4dCBpbiBhbiBhbWJpZ3VvdXMgc3RhdGUgb24gdGhpcyB0 b3BpYyBpcyBhIGdvb2QgaWRlYS4NCj4+IA0KPj4gQ29tbWVudHM/DQo+PiANCj4+IFRoYW5rcywN Cj4+IEJvYg0KPiANCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NCj4gU3Vi amVjdDogKElQbmcgNjA5KSBjaGFuZ2VzIHRvIExhc3QgQ2FsbCdlZCBzcGVjcw0KPiBEYXRlOiBT dW4sIDI3IEF1ZyAxOTk1IDIwOjU5OjI2IFBEVA0KPiBGcm9tOiBTdGV2ZSBEZWVyaW5nIDxkZWVy aW5nQHBhcmMueGVyb3guY29tPg0KPiBUbzogaXBuZ0BzdW5yb29mLmVuZy5zdW4uY29tDQo+IEND OiBkZWVyaW5nQHBhcmMueGVyb3guY29tDQo+IA0KPiBBdCB0aGUgcmVxdWVzdCBvZiBvdXIgQURz LCBJIHByZXBhcmVkIHRoZSBmb2xsb3dpbmcgbGlzdCBvZiBhZ3JlZWQtdXBvbg0KPiBjaGFuZ2Vz IGFuZCBvdXRzdGFuZGluZyBpc3N1ZXMgd2l0aCB0aGUgc2V0IG9mIHNwZWNzIHRoYXQgdW5kZXJ3 ZW50DQo+IElFVEYtd2lkZSBMYXN0IENhbGwgaW4gSnVuZSBhbmQgSnVseS4gIFBsZWFzZSBsZXQg bWUga25vdyBvZiBhbnkgZXJyb3JzDQo+IG9yIG9taXNzaW9ucy4NCj4gDQo+IFN0ZXZlDQo+IA0K PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiANCj4gSVB2NiBTcGVjaWZp Y2F0aW9uDQo+IC0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhlIGZvbGxvd2luZyBjaGFuZ2Vz IHdlcmUgcG9zdGVkIHRvIHRoZSBJRVRGIGxpc3QgaW1tZWRpYXRlbHkgZm9sbG93aW5nDQo+IHRo ZSBMYXN0IENhbGwsIHNvIEkgdGhpbmsgd2UgY2FuIGNvbnNpZGVyIHRoZW0gdG8gYWxzbyBoYXZl IGJlZW4gTGFzdCBDYWxsZWQ6DQo+IA0KPiAgLSBJbiB0aGUgZXhhbXBsZXMgb2YgaG93IHRvIGxh eSBvdXQgb3B0aW9ucywgb24gcGFnZSAyOSwgdHdvIHBsYWNlcw0KPiAgICB3aGVyZSBpdCBzYXlz ICJIZHIgRXh0IExlbj0xIiBzaG91bGQgYmUgIkhkciBFeHQgTGVuPTMiDQo+ICAgIChyZXBvcnRl ZCBieSBIYW1pZCBBc2F5ZXNoKS4NCj4gDQo+ICAtIEluIHNlY3Rpb24gNiwgRmxvdyBMYWJlbHMs IEkgZm9yZ290IHRvIGluY2x1ZGUgdGhlIFByaW9yaXR5IGZpZWxkDQo+ICAgIGluIHRoZSBsaXN0 IG9mIGZpZWxkcyB0aGF0IG11c3QgaGF2ZSB0aGUgc2FtZSB2YWx1ZSBmb3IgYWxsDQo+ICAgIHBh Y2tldHMgaW4gdGhlIHNhbWUgZmxvdyAocmVwb3J0ZWQgYnkgTWFya3VzIEpvcmspLg0KPiANCj4g IC0gVGhlIGRlc2NyaXB0aW9uIG9mIHdoYXQgdGhlIEp1bWJvIFBheWxvYWQgTGVuZ3RoIGZpZWxk IGNvdmVycw0KPiAgICBzaG91bGQgYmUgbWFkZSBjbGVhcmVyIChyZXBvcnRlZCBieSBDaHJpc3Rp YW4gSHVpdGVtYSkuDQo+IA0KPiBUaGUgZm9sbG93aW5nIGNoYW5nZXMgd2VyZSBwcm9wb3NlZCBi eSBDaGFybGllIEx5bm4gaW4gdGhlIG9ubHkgImZvcm1hbCINCj4gcmVzcG9uc2UgdG8gdGhlIExh c3QgQ2FsbCwgYW5kIGFjY2VwdGVkIGF0IHRoZSBmaXJzdCBpcG5nd2cgbWVldGluZyBpbg0KPiBT dG9ja2hvbG06DQo+IA0KPiAgLSBGb3Igb3B0aW9ucyBjb250YWluaW5nIGRhdGEgdGhhdCBjYW4g Y2hhbmdlIGVuLXJvdXRlIChhbmQgd2hpY2ggdGhlcmVmb3JlDQo+ICAgIGhhdmUgdGhlIHRoaXJk LWhpZ2hlc3Qtb3JkZXIgYml0IG9mIHRoZWlyIE9wdGlvbiBUeXBlIHNldCB0byAxKSwgbWFrZSBp dA0KPiAgICBjbGVhciB0aGF0ICphbGwqIGJ5dGVzIG9mIHRoZSBPcHRpb24gRGF0YSBmaWVsZCBh cmUgdG8gYmUgZXhjbHVkZWQgZnJvbQ0KPiAgICB0aGUgQXV0aGVudGljYXRpb24gZnVuY3Rpb24s IGFuZCBleHBsYWluIHRoYXQgImV4Y2x1ZGVkIiBtZWFucyAidHJlYXRlZA0KPiAgICBhcyBpZiB0 aGV5IHdlcmUgYWxsIHplcm8tdmFsdWVkIGJ5dGVzIi4NCj4gDQo+ICAtIENoYW5nZSB0aGUgUm91 dGluZyBIZWFkZXIgdG8gZW5hYmxlIGl0IHRvIGJlIGlnbm9yZWQgYnkgZmluYWwgZGVzdGluYXRp b25zDQo+ICAgIHRoYXQgZG8gbm90IHVuZGVyc3RhbmQgdGhlIFJvdXRpbmcgVHlwZS4gIEluIFN0 b2NraG9sbSwgRGVlcmluZyBwcm9wb3NlZCwNCj4gICAgYW5kIHRoZSBhdHRlbmRlZXMgYWdyZWVk IHdpdGgsIHRoZSBmb2xsb3dpbmcgcmV2aXNlZCBmb3JtYXQgZm9yIHRoZQ0KPiAgICBmaXJzdCAz MiBiaXRzIG9mIHRoZSBSb3V0aW5nIEhlYWRlciwgZm9yIGFsbCBSb3V0aW5nIFR5cGVzOg0KPiAN Cj4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQo+ICAgICB8ICBOZXh0IEhlYWRlciAgfCAgSGRyIEV4dCBMZW4gIHwg IFJvdXRpbmcgVHlwZSB8IFNlZ21lbnRzIExlZnQgfA0KPiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+IA0KPiAgICB3aGVyZQ0KPiANCj4gCUhkciBFeHQgTGVuICAgaXMgdGhlIGxlbmd0 aCBvZiB0aGUgaGVhZGVyIGluIDgtb2N0ZXQgdW5pdHMsIG5vdA0KPiAJICAgICAgICAgICAgICBp bmNsdWRpbmcgdGhlIGZpcnN0IDggb2N0ZXRzDQo+IA0KPiAJU2VnbWVudHMgTGVmdCBpcyB0aGUg bnVtYmVyIG9mICJsZWdzIiBsZWZ0IHRvIHRyYXZlcnNlIGluIHRoZQ0KPiAgICAgICAgICAgICAg ICAgICAgICByb3V0ZTsgaWYgdGhpcyB2YWx1ZSBpcyB6ZXJvLCB0aGUgcmVjZWl2ZXIgbWF5DQo+ IAkgICAgICAgICAgICAgIGlnbm9yZSB0aGlzIGhlYWRlciAoaS5lLiwgaXQgaW5kaWNhdGVzIHRo YXQgdGhlDQo+IAkgICAgICAgICAgICAgIHJvdXRlIGhhcyBiZWVuIGNvbXBsZXRlZCksIHdoZXRo ZXIgb3Igbm90IHRoZQ0KPiAJICAgICAgICAgICAgICByZWNlaXZlciB1bmRlcnN0YW5kcyB0aGUg Um91dGluZyBUeXBlDQo+IA0KPiBUaGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgY2hhbmdlcyB3ZXJl IGFncmVlZCB0byBlaXRoZXIgb24gdGhlIG1haWxpbmcgbGlzdA0KPiBvciBpbiB0aGUgU3RvY2to b2xtIG1lZXRpbmdzOg0KPiANCj4gIC0gIkltcHJvdmUiIHRoZSBob3N0L3JvdXRlciB0ZXJtaW5v bG9neS4gIFdoYXQgSSBwcm9wb3NlIHRvIGRvIGlzIGFkZCBhDQo+ICAgIGZvb3Rub3RlIHRvIHRo ZSB0ZXJtaW5vbG9neSBzZWN0aW9uIHNheWluZyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPiANCj4g CSogaXQgaXMgcG9zc2libGUsIHRob3VnaCB1bnVzdWFsLCB0byBoYXZlIGEgZGV2aWNlIHdpdGgg bXVsdGlwbGUNCj4gICAgICAgICAgaW50ZXJmYWNlcyBjb25maWd1cmVkIHRvIGZvcndhcmQgbm9u LXNlbGYtZGVzdGluZWQgcGFja2V0cw0KPiAgICAgICAgICBhcnJpdmluZyBmcm9tIHNvbWUgc2V0 IChmZXdlciB0aGFuIGFsbCkgb2YgaXRzIGludGVyZmFjZXMsIGFuZA0KPiAJICB0byBkaXNjYXJk IG5vbi1zZWxmLWRlc3RpbmVkIHBhY2tldHMgYXJyaXZpbmcgZnJvbSBpdHMgb3RoZXINCj4gCSAg aW50ZXJmYWNlcy4gIFN1Y2ggYSBkZXZpY2UgbXVzdCBvYmV5IHRoZSBwcm90b2NvbCByZXF1aXJl bWVudHMNCj4gCSAgZm9yIHJvdXRlcnMgd2hlbiByZWNlaXZpbmcgcGFja2V0cyBmcm9tLCBhbmQg aW50ZXJhY3Rpbmcgd2l0aA0KPiAJICBuZWlnaGJvcnMgb3ZlciwgdGhlIGZvcm1lciAoZm9yd2Fy ZGluZykgaW50ZXJmYWNlcy4gIEl0IG11c3QNCj4gCSAgb2JleSB0aGUgcHJvdG9jb2wgcmVxdWly ZW1lbnRzIGZvciBob3N0cyB3aGVuIHJlY2VpdmluZyBwYWNrZXRzDQo+IAkgIGZyb20sIGFuZCBp bnRlcmFjdGluZyB3aXRoIG5laWdoYm9ycyBvdmVyLCB0aGUgbGF0dGVyIChub24tDQo+IAkgIGZv cndhcmRpbmcpIGludGVyZmFjZXMuDQo+IA0KPiAgICBDb21tZW50cz8NCj4gDQo+ICAtIENsYXJp ZnkgdGhlIG9wZXJhdGlvbiBvZiBUeXBlIDAgUm91dGluZyBIZWFkZXIgYnkgZ2l2aW5nIGFuIGV4 YW1wbGUsDQo+ICAgIHNob3dpbmcgdGhlIHZhbHVlcyBvZiB0aGUgaGVhZGVyIGZpZWxkcyBvbiBl YWNoIHNlZ21lbnQgb2YgdGhlIHJvdXRlLg0KPiANCj4gIC0gQ2xhcmlmeSB0aGUgaGFuZGxpbmcg b2Ygb3B0aW9ucywgZXh0ZW5zaW9uIGhlYWRlcnMsIE5leHQgSGVhZGVyIGZpZWxkcywNCj4gICAg ZXRjLiBmb3IgZnJhZ21lbnRlZCBwYWNrZXRzIGJ5IGdpdmluZyBhIGZldyBleGFtcGxlcyBvZiBw YWNrZXRzIGJlZm9yZQ0KPiAgICBhbmQgYWZ0ZXIgZnJhZ21lbnRhdGlvbiAoc3VnZ2VzdGVkIGJ5 IERpbWl0cnkgSGFza2lucyBhbmQgb3RoZXJzKS4NCj4gDQo+ICAtIFNwZWNpZnkgdGhhdCBmcmFn bWVudHMgY2Fubm90IHJlYXNzZW1ibGUgdG8gZm9ybSBhIGp1bWJvZ3JhbSAoc3VnZ2VzdGVkDQo+ ICAgIGJ5IENyYWlnIE1ldHopLg0KPiANCj4gDQo+IElDTVB2NiBTcGVjaWZpY2F0aW9uDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAgLSBBZGQgbm90ZSB3YXJuaW5nIGFib3V0IHRoZSBw b3NzaWJpbGl0eSBvZiB1cHBlci1sYXllciBoZWFkZXIgYmVpbmcNCj4gICAgdHJ1bmNhdGVkIGZy b20gdGhlIHJldHVybmVkIHBhY2tldCBpbiBhbiBlcnJvciBtZXNzYWdlLCBkdWUgdG8gbGFyZ2UN Cj4gICAgbnVtYmVyIG9mIGV4dGVuc2lvbiBoZWFkZXIgYnl0ZXMsIHdoaWNoIGNhbiBkZWZlYXQg ZGVsaXZlcnkgb2YgdGhlDQo+ICAgIGVycm9yIG1lc3NhZ2UgdG8gdGhlIGd1aWx0eSB1cHBlci1s YXllciBwcm90b2NvbCBpbnN0YW5jZS4NCj4gDQo+ICAtIERlbGV0ZSBkZXNjcmlwdGlvbiBvZiBw c2V1ZG8taGVhZGVyLCByZXBsYWNpbmcgaXQgd2l0aCBhIHJlZmVyZW5jZSB0bw0KPiAgICB0aGUg ZGVzY3JpcHRpb24gaW4gdGhlIElQdjYgc3BlYyAoc3VnZ2VzdGVkIGJ5IEFsaXN0YWlyIEJlbGwg YW5kDQo+ICAgIE1hcmMgSGFzc29uKS4NCj4gDQo+ICAtIENvcnJlY3QgZXhhbXBsZSBvZiB1c2Fn ZSBvZiB0aGUgcG9pbnRlciBpbiB0aGUgUGFyYW1ldGVyIFByb2JsZW0NCj4gICAgbWVzc2FnZSBv biBwYWdlIDE1LCBieSBjaGFuZ2luZyAiNDgiIHRvICI0MCIgKHJlcG9ydGVkIGJ5IERpbWl0cnkN Cj4gICAgSGFza2lucyBhbmQgRnJhbmNpcyBEdXBvbnQpLg0KPiANCj4gIC0gTm90ZSB0aGF0IHRo ZXJlIGlzIGFub3RoZXIgZXhjZXB0aW9uIHRvIHRoZSAibm8gSUNNUCBlcnJvciBtZXNzYWdlcw0K PiAgICBpbiByZXNwb25zZSB0byBtdWx0aWNhc3RzIiBydWxlLCB3aGljaCBpcyAidW5yZWNvZ25p emVkIG9wdGlvbiINCj4gICAgUGFyYW1ldGVyIFByb2JsZW0gbWVzc2FnZXMgaW4gcmVzcG9uc2Ug dG8gb3B0aW9ucyB3aXRoIGhpZ2gtb3JkZXINCj4gICAgYml0cyAiMTAuLi4iIChyZXBvcnRlZCBi eSBEaW1pdHkgSGFza2lucykuDQo+IA0KPiBBZGRyZXNzIEFyY2hpdGVjdHVyZSBEb2N1bWVudA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gIC0gQWRkIGRlZmluaXRpb24g b2YgImxpbmstbG9jYWwgYWRkcmVzcyIgdG8gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24NCj4gICAg KHN1Z2dlc3RlZCBieSBKaW0gQm91bmQpLg0KPiANCj4gIC0gU3BlY2lmeSB0aGF0ICI6OiIgaXMg YSBsZWdhbCB0ZXh0IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBVbnNwZWNpZmllZA0KPiAgICAoYWxs LXplcm9zKSBBZGRyZXNzIChzdWdnZXN0ZWQgYnkgRnJhbmNpcyBEdXBvbnQpLg0KPiANCj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+IFRoZSBmb2xsb3dpbmcgc3Vn Z2VzdGlvbnMgaW4gQ2hhcmxpZSBMeW5uJ3MgZm9ybWFsIHJlc3BvbnNlIHRvIHRoZSBMYXN0IENh bGwNCj4gd2VyZSByZWplY3RlZCBhdCB0aGUgU3RvY2tob2xtIG1lZXRpbmc6DQo+IA0KPiAgLSBB ZGQgYSBiaXQgdG8gdGhlIFJvdXRpbmcgSGVhZGVyIGluZGljYXRpbmcgd2hldGhlciBvciBub3Qg aXQgd2FzDQo+ICAgIGluc2VydGVkIGludG8gdGhlIHBhY2tldCBlbi1yb3V0ZSwgaS5lLiwgYnkg YSBub2RlIG90aGVyIHRoYW4gdGhlDQo+ICAgIHBhY2tldCdzIG9yaWdpbmF0b3IuDQo+IA0KPiAg ICAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJz IGVuLXJvdXRlIGJyZWFrcw0KPiAgICAgIFBNVFUtZGlzY292ZXJ5IGFuZCBjYW4gcmVzdWx0IGlu IElDTVAgZXJyb3IgbWVzc2FnZXMgYmVpbmcgc2VudCB0bw0KPiAgICAgIG5vbi1ndWlsdHkgcGFy dGllcy4gIFRoZSBkZXNpcmVkIGVmZmVjdCBjYW4gYmUgYWNoaWV2ZWQsIGFuZCB0aG9zZQ0KPiAg ICAgIHByb2JsZW1zIGF2b2lkZWQsIGJ5IHVzaW5nIGVuLXJvdXRlIGVuY2Fwc3VsYXRpb24gKHdp dGggb3B0aW9uYWwNCj4gICAgICBSb3V0aW5nIEhlYWRlcikgcmF0aGVyIHRoYW4gaGVhZGVyIGlu c2VydGlvbi4NCj4gDQo+ICAtIENoYW5nZSBJQ01QIGVycm9yIG1lc3NhZ2VzIHRvIGNvbnRhaW4g ZXhwbGljaXQgZmllbGRzIGlkZW50aWZ5aW5nIHRoZQ0KPiAgICB1cHBlci1sYXllciBwcm90b2Nv bCB0byB3aGljaCB0aGUgZXJyb3IgbWVzc2FnZSBzaG91bGQgYmUgZGVsaXZlcmVkLg0KPiANCj4g ICAgICByZWFzb25zIGZvciByZWplY3Rpb246IGNvbnNpZGVyZWQgdW5uZWNlc3NhcnkgY29tcGxl eGl0eSB0byBoYW5kbGUgdGhlDQo+ICAgICAgcmFyZSBjYXNlIG9mIHRydW5jYXRpb24gb2YgdHJh bnNwb3J0IGhlYWRlciBmcm9tIHRoZSByZXR1cm5lZCBwYWNrZXQNCj4gICAgICBiZWNhdXNlIG9m IHRvbyBtYW55IGV4dGVuc2lvbiBoZWFkZXIgb2N0ZXRzLiAgU3VjaCBlcnJvciBtZXNzYWdlcyBh cmUNCj4gICAgICBzdGlsbCB1c2FibGUgZm9yIHByb2JsZW0gZGlhZ25vc2lzIG90aGVyIHRoYW4g aW4gdGhlIHVwcGVyLWxheWVyDQo+ICAgICAgaXRzZWxmLCBlLmcuLCBpZiBsb2dnZWQgYXQgSVB2 NiBsYXllciBvciBvYnNlcnZlZCBpbiBhIHBhY2tldCB0cmFjZS4NCj4gICAgICBXaWxsIGFkZCB3 YXJuaW5nIHRvIHRoZSBJQ01QdjYgc3BlYyBhYm91dCBjb25zZXF1ZW5jZXMgb2YgbG9uZw0KPiAg ICAgIGV4dGVuc2lvbiBoZWFkZXIgb24gSUNNUCBlcnJvciBtZXNzYWdlIGRpc3BhdGNoaW5nLg0K PiANCj4gIC0gQ2hhbmdlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgSUNNUHY2 IHNwZWMgdG8gc3BlY2lmeSB3aGVuDQo+ICAgIGFuZCBob3cgdG8gaW5jbHVkZSBhbiBBdXRoZW50 aWNhdGlvbiBIZWFkZXIgaW4gSUNNUCBlcnJvciBtZXNzYWdlcy4NCj4gDQo+ICAgICAgcmVhc29u cyBmb3IgcmVqZWN0aW9uOiBncm91cCBjb25zZW5zdXMgdGhhdCB0aGlzIGJlbG9uZ3MgaW4gYWEN Cj4gICAgICBJUHNlYyBzcGVjIGluc3RlYWQuDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KPiANCj4gVGhlIGZvbGxvd2luZyBpc3N1ZXMgYW5kIHN1Z2dlc3Rpb25z IGhhdmUgYmVlbiBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdA0KPiBzaW5jZSB0aGUgYmFz ZSBzcGVjcyB3ZW50IHRvIExhc3QgQ2FsbCwgYnV0IG5vIGdyb3VwIGNvbnNlbnN1cyBvbiB0aGVz ZSBpc3N1ZXMNCj4gaGFzIGJlZW4gcmVhY2hlZCB5ZXQ6DQo+IA0KPiAgLSBGcmFnbWVudGF0aW9u IGlzc3VlczoNCj4gCS0gY2hhbmdlIHRoZSBtaW5pbXVtIHJlYXNzZW1ibHkgYnVmZmVyIHNpemUg dG8gYSBudW1iZXIgbGFyZ2VyDQo+IAkgIHRoYW4gNTc2Pw0KPiAJLSBzcGVjaWZ5IHRoYXQgc291 cmNlcyBvZiBmcmFnbWVudGVkIHBhY2tldHMgbXVzdCB1c2UgdGhlIG1pbmltYWwNCj4gCSAgbnVt YmVyIG9mIGZyYWdtZW50cyByZXF1aXJlZCB0byBmaXQgaW4gdGhlIHBlcmNlaXZlZCBQTVRVPw0K PiAJLSBzcGVjaWZ5IHRoYXQgYWxsIGZyYWdtZW50cyB3aXRoIHRoZSBNIGJpdCBzZXQgbXVzdCBi ZSBubyBsZXNzDQo+IAkgIHRoYW4gNyBvY3RldHMgc2hvcnRlciB0aGFuIHRoZSBwZXJjZWl2ZWQg UE1UVT8NCj4gCS0gc3BlY2lmeSB0aGF0IGFsbCBmcmFnbWVudHMgd2l0aCB0aGUgTSBiaXQgc2V0 IG11c3QgYmUgbm8gc2hvcnRlcg0KPiAJICB0aGFuIDU3NiBvY3RldHM/DQo+IAktIGlnbm9yZSBm cmFnbWVudHMgdGhhdCBwYXJ0aWFsbHkgb3ZlcmxhcCBvdGhlciBmcmFnbWVudHMgb2YgdGhlDQo+ IAkgIHNhbWUgcGFja2V0LCBvciBkaXNjYXJkIGFueSBwYWNrZXQgdGhhdCBhcnJpdmVzIGFzIHBh cnRpYWxseQ0KPiAJICBvdmVybGFwcGluZyBmcmFnbWVudHM/DQo+IA0KPiAgLSBSb3V0aW5nIEhl YWRlciBpc3N1ZXM6DQo+IAktIGFkZCBhICJUb3RhbCBMZW5ndGgiIGZpZWxkIHRvIHRoZSBmcmFn bWVudCBoZWFkZXIsIGNhcnJ5aW5nIHRoZQ0KPiAJICBsZW5ndGggb2YgdGhlIG9yaWdpbmFsLCB1 bmZyYWdtZW50ZWQgcGFja2V0Pw0KPiAJLSBmb3JiaWQgZm9yd2FyZGluZyBvZiBwYWNrZXRzIHdp dGggUm91dGluZyBIZWFkZXJzIGJ5IGhvc3RzPw0KPiAJICAoaWYgbm90LCBtYWtlIGl0IGNsZWFy ZXIgdGhhdCBob3N0cyBhcmUgZXhwZWN0ZWQgdG8gZm9yd2FyZA0KPiAJICBwYWNrZXRzIHdpdGgg Um91dGluZyBIZWFkZXJzLCBpZiB0aGV5IGFyZSBpbnRlcm1lZGlhdGUgdGFyZ2V0cw0KPiAJICBv ZiBzdWNoIHBhY2tldHMuKQ0KPiAJLSBzcGVjaWZ5IHRoZSByZXZlcnNpbmcgcnVsZXMgZm9yIHBh Y2tldHMgdGhhdCBhcmUgcmVzcG9uc2VzIHRvDQo+IAkgIHBhY2tldHMgdGhhdCBjYXJyeSBhIFJv dXRpbmcgSGVhZGVyPw0KPiAJLSBmb3JiaWQgb3IgZGlzY291cmFnZSByZXZlcnNhbCBvZiBhbiB1 bmF1dGhlbnRpY2F0ZWQgUm91dGluZyBIZWFkZXI/DQo+IAktIGZvcmJpZCBvciBkaXNjb3VyYWdl IGFjY2VwdGFuY2Ugb2YgYSBwYWNrZXQgd2l0aCBhbiB1bmF1dGhlbnRpY2F0ZWQNCj4gCSAgUm91 dGluZyBIZWFkZXI/DQo+IA0KPiAgLSBBbGxvdyB0aGUgdHJhbnNwb3J0LWxheWVyIGNoZWNrc3Vt IHRvIGJlIG9taXR0ZWQgd2hlbiB0aGUgQXV0aGVudGljYXRpb24NCj4gICAgaGVhZGVyIChvciB0 aGUgRVNQIGhlYWRlcj8pIGlzIGJlaW5nIHVzZWQ/DQo+IA0KPiAgLSBBZGQgYSBDb25nZXN0aW9u IEluZGljYXRpb24gYml0IHRvIHRoZSBiYXNlIElQdjYgaGVhZGVyPw0KPiANCj4gIC0gQWRkIE1V U1QvU0hPVUxEL01BWSBjb25mb3JtYW5jZSByZXF1aXJlbWVudHMgZm9yIGFsbCBJUHY2IGZpZWxk cyBhbmQNCj4gICAgZnVuY3Rpb25zPw0KPiANCj4gIC0gQnVpbGQgYSBzaW5nbGUgVGVybWlub2xv Z3kgZG9jdW1lbnQsIHRvIGJlIHNoYXJlZCAoZWl0aGVyIGJ5IHJlZmVyZW5jZQ0KPiAgICBvciBp bmNsdXNpb24pIGluIGFsbCBJUHY2LXJlbGF0ZWQgc3BlY3M/DQo+IA0KPiAgLSBBbGxvdyB0aGUg dXNlIG9mIHplcm8gaW4gdGhlIFVEUCBMZW5ndGggZmllbGQgdG8gaW5kaWNhdGUgdGhhdCB0aGUg VURQDQo+ICAgIGxlbmd0aCBzaG91bGQgYmUgZGVyaXZlZCBmcm9tIHRoZSBKdW1ib2dyYW0gT3B0 aW9uPw0KPiANCj4gTm90ZTogdGhlIGFib3ZlIGxpc3QgZG9lcyBub3QgaW5jbHVkZSBpc3N1ZXMg Y29uY2VybmluZyB0aG9zZSBzcGVjcyB0aGF0DQo+IGhhdmUgbm90IHlldCBiZWVuIHN1YmplY3Rl ZCB0byBXRyBvciBJRVRGIExhc3QgQ2FsbCwgZS5nLiwgdGhlIE5laWdoYm9yDQo+IERpc2NvdmVy eSBzcGVjLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVBuZyBNYWlsaW5n IExpc3QJCSAgICAgIEZUUCBhcmNoaXZlOiBmdHAucGFyYy54ZXJveC5jb206L3B1Yi9pcG5nDQo+ IElQbmcgSG9tZSBQYWdlOiAgICAgICAgICBodHRwOi8vcGxheWdyb3VuZC5zdW4uY29tL3B1Yi9p cG5nL2h0bWwvaXBuZy1tYWluLmh0bWwNCj4gRGlyZWN0IGFsbCBhZG1pbmlzdHJhdGl2ZSByZXF1 ZXN0cyB0byBtYWpvcmRvbW9Ac3Vucm9vZi5lbmcuc3VuLmNvbQ0KPiANCj4gDQo+IA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBp ZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Thu Apr 28 02:13:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6512D5F6; Thu, 28 Apr 2016 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cjhpDTMa3Kmd; Thu, 28 Apr 2016 02:13:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F233112D0B9; Thu, 28 Apr 2016 02:13:52 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 814B1C056C; Thu, 28 Apr 2016 11:13:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4FF1E1A0082; Thu, 28 Apr 2016 11:13:51 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 11:13:51 +0200 From: To: "Stefano Previdi (sprevidi)" Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnA= Date: Thu, 28 Apr 2016 09:13:50 +0000 Message-ID: <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> In-Reply-To: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 09:13:56 -0000 =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: mercredi 27 avril 2016 15:50 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), >=20=20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag.=20=20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. >=20=20 > But In section 4.3. >=20=20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, >=20=20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you're right. The node that processes the cleanup flag is the penultimate s= egment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 Rabah : >>>>>> do you consider that the c-flag must be set for all the pack= ets. if we consider that setting the c-flag is not obligatory, then the egress= would receive an SRH with : 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 The SRH has to be ignored based on RFC2460, is that corrects= ? which in my opinion is not the intended behavior . s. Rabah >=20=20 >=20=20 > Bests. >=20=20 >=20=20 > >=20=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Apr 28 03:30:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D212D64C; Thu, 28 Apr 2016 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 3QQXcyrxAY-o; Thu, 28 Apr 2016 03:30:50 -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 D347912D647; Thu, 28 Apr 2016 03:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6366; q=dns/txt; s=iport; t=1461839449; x=1463049049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=75tp9V5n8n42Pki6kHMWxC4tmiN/Al9F+aqPyGAVW6s=; b=DQMtAHwco5pAFyH4KT87k09ViS/NJGYj0wRerg13xm6agjAe2G7sn2Ei G9VvsQ9tNS2c2T1nxCoETq35a2AggpcZME0wVUC70IA/doVm6JghRgz2B HFi0jH4sePyyI5cN85DCLMXCk4nYfXtTblyhmCo8KbwYQTWbkxSei801U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgDD5SFX/4sNJK1egzhTfQa5bQENg?= =?us-ascii?q?XYXC4VtAoEjOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGCcHGwwLFBE?= =?us-ascii?q?BAQQOBYgiCA7DFgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWCVoQPEQEcL?= =?us-ascii?q?IJ/gisBBId0ixiFBAGOFoFnhE2EJIQ5jy8BHgEBQoNrbIgBNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208";a="265322724" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 10:30:48 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3SAUmte000434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 10:30:48 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.1104.5; Thu, 28 Apr 2016 06:30:47 -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.1104.009; Thu, 28 Apr 2016 06:30:47 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAA== Date: Thu, 28 Apr 2016 10:30:47 +0000 Message-ID: <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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.238.46] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9B3DB3A1A6268F49867C1361A2A53A56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 10:30:52 -0000 On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: >=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : mercredi 27 avril 2016 15:50 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi,=20 >> I would like some clarification about the treatment of the SRH by an en= d point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the=20 >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag. =20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has to c= heck if the c-flag is set when the new value of the segments left point is = equal to zero, >> If the c-flag is set and the segments left pointer =3D=3D 0 then remove = the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment le= ft =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This is d= escribed in RFC2460 section 4.4 >=20 > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don=92t set the c-flag, then the egress = receives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by =93not the intended behavior=94 ? s. > s. > Rabah >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez=20 >> Th=E9sard=20 >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56=20 >> rabah.guedrez@orange.com >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Thu Apr 28 03:58:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286A512D658; Thu, 28 Apr 2016 03:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 2K2iXzwFDGGA; Thu, 28 Apr 2016 03:58:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7B12D114; Thu, 28 Apr 2016 03:58:14 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 383F72065D; Thu, 28 Apr 2016 12:58:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 1161F1A0075; Thu, 28 Apr 2016 12:58:13 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 12:58:13 +0200 From: To: "Stefano Previdi (sprevidi)" Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAAAH55oQ Date: Thu, 28 Apr 2016 10:58:12 +0000 Message-ID: <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> In-Reply-To: <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 10:58:17 -0000 You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: jeudi 28 avril 2016 12:31 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: >=20 > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com >=20=20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :=20 > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :=20 > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:=20 > draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi, >> I would like some clarification about the treatment of the SRH by an=20 >> end point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag.=20=20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has=20 >> to check if the c-flag is set when the new value of the segments left=20 >> point is equal to zero, If the c-flag is set and the segments left=20 >> pointer =3D=3D 0 then remove the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment=20 >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This=20 > is described in RFC2460 section 4.4 >=20 > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >>=20 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Apr 28 04:46:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362A12B022; Thu, 28 Apr 2016 04:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 y1scRvqhsqhu; Thu, 28 Apr 2016 04:46:04 -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 90B1912D12A; Thu, 28 Apr 2016 04:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20706; q=dns/txt; s=iport; t=1461843964; x=1463053564; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Slu7o+S9hamIvEQG78ht9YDX26/8U2qdTr8oFzA8/hA=; b=Mk7BGKOpl6SODtb5xVNh30IcFQ/QBQS9QPs70Cz3wEVZTCAZegdOgWHe 2Ri1EnY5lvkNJwsqIzsEiDSJMz1DPpew1pIjI7DyGwKKxqfPk0CHdBYfq Vbrd4CfQdmiiWqP/VXVROok43pbv+QcOJCrTxE+FE+P33G/pTV45FWmW7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgDg9iFX/5JdJa1egmxMU321AIRzA?= =?us-ascii?q?Q2BdhcBCoVtAoEkOBQBAQEBAQEBZRwLhEEBAQEDAQEBASpBCwUHAgICAQgVAgE?= =?us-ascii?q?nBxsMCxQJCAIEDgUIiBoIDsJ3AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQQEhh2DS?= =?us-ascii?q?YEChA8RASImCoUgBYd0hhiFAIUEAY4PgW6ETYQkhDmPLwEeAQFCggUbgUtsiAG?= =?us-ascii?q?BNQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208,217";a="101545491" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 11:46:02 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3SBk2YJ024919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 11:46:02 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.1104.5; Thu, 28 Apr 2016 07:46:01 -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.1104.009; Thu, 28 Apr 2016 07:46:01 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AQHRoTzev8IxaMPY3kOJ15ohq3wgDJ+fRJn9 Date: Thu, 28 Apr 2016 11:46:01 +0000 Message-ID: <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com>, <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 11:46:06 -0000 --_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are many operators and use cases where, instead of encapsulation, srh= insertion is a far better option. In fact all current implementations are doing srh insertion. Still, from a spec perspective, the srh processis the same. s. -----Original Message----- From: rabah.guedrez@orange.com [rabah.guedrez@orange.com] Received: Thursday, 28 Apr 2016, 12:58 To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org] Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com -----Message d'origine----- De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 12:31 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com > > > > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc : > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: > draft-ietf-6man-segment-routing-header-01.txt > > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >> >> Hi, >> I would like some clarification about the treatment of the SRH by an >> end point (the node that its loopback matches the DA field), >> >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. > > > the text is confusing but the semantic is correct ;-) > > the cleanup flag is processed so that the last segment receives a packet = without any SRH. > > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: > > C-flag: Clean-up flag. > Set when the SRH has to be removed from > the packet prior to forward the packet > towards the last segment. > > > >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >> >> But In section 4.3. >> >> You say that the node that decrements the Segments left pointer has >> to check if the c-flag is set when the new value of the segments left >> point is equal to zero, If the c-flag is set and the segments left >> pointer =3D=3D 0 then remove the SRH, >> >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. > > > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. > > >> Another question if a node receives a packet with the already segment >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) > > > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 > > MUST ignore the routing header and process the packet normally. This > is described in RFC2460 section 4.4 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah > >> >> >> Bests. >> >> >> >> >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >> >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There are many operators and use cases where, instead of e= ncapsulation, srh insertion is a far better option.

In fact all current implementations are doing srh insertion.

Still, from a spec perspective, the srh processis the same.

s.

-----Original Message-----
From: rabah.guedrez@orange.com [rabah.guedrez@orange.com]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org]=
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.t= xt

You have said in a previous response to a question= that the draft only consider the encapsulation of client packet into a new= IPV6 header with SRH, and not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic  (not modify the header of the client packets for sec= urity reasons).

If you only consider encapsulation, does keeping  c-flag relevant?
 
Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ
 
Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com
 


-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 12:31
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt<= br>
On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote:
>
> Rabah Guedrez
> Th=E9sard
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
> 
> Phone: +33 2 96 07 18 56
> rabah.guedrez@orange.com
> 
>
>
> -----Message d'origine-----
> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :
> mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :
> spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:
> draft-ietf-6man-segment-routing-header-01.txt
>
>
>> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote:
>>
>> Hi,
>> I would like some clarification about the treatment of the  S= RH by an
>> end point (the node that its loopback matches the DA field),
>>
>> In section 3 :
>> You say that the
>> C-flag: Clean-up flag.  Set when the SRH has to be removed fr= om
>>         the packet when th= e packet reaches the last segment.
>
>
> the text is confusing but the semantic is correct ;-)
>
> the cleanup flag is processed so that the last segment receives a pack= et without any SRH.
>
> However, as you figured out, the processing of the C flag is done on t= he segment before last (penultimate segment). So, probably a more accurate = text would be:
>
>  C-flag: Clean-up flag. 
>          Set when the SRH= has to be removed from
>          the packet prior= to forward the packet
>          towards the last= segment.
>
>
>
>> Which mean that the last node inspects the SRH flags if the c-flag= is set, the node has to remove the SRH before sending the packet to its fi= nal destination.
>>
>> But In section 4.3.
>>
>> You say that the node that decrements the Segments left pointer ha= s
>> to check if the c-flag is set when the new value of the segments l= eft
>> point is equal to zero, If the c-flag is set and the segments left=
>> pointer =3D=3D 0 then remove the SRH,
>>
>> What is confusing for me is that the node that decrements the poin= ter is not the last node in the SR path (behavior similar to  PHP for = MPLS) , which I find in direct contradiction with section 3.
>
>
> you're right. The node that processes the cleanup flag is the penultim= ate segment, not the last.
>
>
>> Another question if a node receives a packet with the already segm= ent
>> left =3D=3D 0, what should that node do with the packet(e.g., drop= s it?)
>
>
> a node receiving a packet where:
>        1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0 >
> MUST ignore the routing header and process the packet normally. This <= br> > is described in RFC2460 section 4.4
>
> Rabah : >>>>>> do you consider that the c-flag must = be set for all the packets.


no.

The c-flag is to be set when you insert an SRH into an existing packet.

You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination.


> if we consider that setting the c-flag is not obligatory, then the&nbs= p; egress would receive an SRH with :
>            = ;   1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0

when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above.


>            = ;   The SRH has to be ignored based on RFC2460, is that corrects = ?


yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket).


> which in my opinion is not the intended behavior .


can you explain what you mean by "not the intended behavior" ?
s.


> s.
> Rabah
>
>>
>>
>> Bests.
>>
>>
>> <image001.gif>
>>
>> Rabah Guedrez
>> Th=E9sard
>> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>>
>> Phone: +33 2 96 07 18 56
>> rabah.guedrez@orange.com
>>
>>
>> __________________________________________________________________= ___
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d'= alteration, Orange decline toute responsabilite si ce message a ete altere,= deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender= and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified.
>> Thank you.
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>
>
> ______________________________________________________________________=
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
> exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

 --_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_-- From nobody Thu Apr 28 07:34:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF30A12D7E1 for ; Thu, 28 Apr 2016 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 ePWdUrLYZFbe for ; Thu, 28 Apr 2016 07:34:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C9312D7DC for ; Thu, 28 Apr 2016 07:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19440; q=dns/txt; s=iport; t=1461854033; x=1463063633; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SmIlPDiFUYsoCI9ds8G6ZG4dDynbUB6jL4jTAeOrIlw=; b=B6a+XRHK1ZBMjHpAsA58MQxnT7xGfR4tB4lqa9MKt8R+VJmylplgkQFP k+2/cthmm+qRZtQo4Ba924O3At/VKWPoz8lr5ojzI6U29xTBBBoeN47Tu KVPrJLMhP1fQ0SDCdYJNml7thlCyOxdneYlqlFy/GGiSx1tdRHQ9S8iw0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgDxHiJX/4MNJK1YBg6DKlN9Bq4Ri?= =?us-ascii?q?14BDYF2FwuFbQIcgQs4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgQAQE?= =?us-ascii?q?CAQIBAgImAgICHwYLFQIGCAIEDgWIFQMKCA6yJIxBDYRLAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFXyFJYF1CIJOgkGBbg4HECOCRiuCKwWHdAqHCIhZMQGFe4J3gy6?= =?us-ascii?q?BdoFnToN/iF2GJIEth14BHgEBQoICAxuBEDtsAYZofwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="98918195" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 14:33:52 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SEXpE4001756 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 14:33:51 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.1104.5; Thu, 28 Apr 2016 10:33:50 -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.1104.009; Thu, 28 Apr 2016 10:33:50 -0400 From: "Stefano Previdi (sprevidi)" To: Tim Chown Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoVr7bGnipPO6gUicbFHJemALvA== Date: Thu, 28 Apr 2016 14:33:50 +0000 Message-ID: <95B92AF8-CA66-4380-8F38-480A896C1B6B@cisco.com> References: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> In-Reply-To: <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> 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.238.46] Content-Type: text/plain; charset="utf-8" Content-ID: <13CF2E83941F704BB2A481257AF53BA7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:34:21 -0000 DQo+IE9uIEFwciAyOCwgMjAxNiwgYXQgMTA6MzMgQU0sIFRpbSBDaG93biA8VGltLkNob3duQGpp c2MuYWMudWs+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPj4gT24gMjggQXByIDIwMTYsIGF0IDA0 OjI2LCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90 ZToNCj4+IA0KPj4gT24gMjgvMDQvMjAxNiAxMzoxOCwgQm9iIEhpbmRlbiB3cm90ZToNCj4+PiBI aSwNCj4+PiANCj4+PiBJIHdvdWxkIGxpa2UgdG8gZ2V0IGNsb3N1cmUgb24gdGhlIHF1ZXN0aW9u IGlmIGluc2VydGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGlzIGFsbG93ZWQgb3Igbm90LCBh bmQgc2hvdWxkIHRoaXMgYmUgYSBjbGFyaWZpY2F0aW9uIGluIHJmYzI0NjBiaXMuICBUaGlzIHRv cGljIHdhcyBkaXNjdXNzZWQgaW4gQnVlbm9zIEFpcmVzIGFuZCBvbiB0aGUgbWFpbGluZyBsaXN0 Lg0KPj4+IA0KPj4+IFRoZSByZWxldmFudCB0ZXh0IGZyb20gU2VjdGlvbiA0ICJJUHY2IEV4dGVu c2lvbiBIZWFkZXJzIiBpbiA8ZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMtMDQudHh0Pg0KPj4+ IA0KPj4+ICBFeHRlbnNpb24gaGVhZGVycyBtdXN0IG5ldmVyIGJlIGluc2VydGVkIGJ5IGFueSBu b2RlIG90aGVyIHRoYW4gdGhlDQo+Pj4gIHNvdXJjZSBvZiB0aGUgcGFja2V0LiAgSVAgRW5jYXBz dWxhdGlvbiBtdXN0IGJlIHVzZWQgdG8gbWVldCBhbnkNCj4+PiAgcmVxdWlyZW1lbnQgZm9yIGlu c2VydGluZyBoZWFkZXJzLCBmb3IgZXhhbXBsZSwgYXMgZGVmaW5lZCBpbg0KPj4+ICBbUkZDMjQ3 M10uDQo+Pj4gDQo+Pj4gVGhpcyB0ZXh0IHdhcyBhZGRlZCB0byB0aGUgZHJhZnQgaW4gdmVyc2lv biDigJQwMSBwdWJsaXNoZWQgb24gMiBOb3ZlbWJlciAyMDE1Lg0KPj4+IA0KPj4+IFRoZSBxdWVz dGlvbiBpcyBpZiB0aGlzIHRleHQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgcmZjMjQ2MC4g IFRoYXQgd291bGQgYWxsb3cgaXQgdG8gYmUgcGFydCBvZiByZmMyNDYwYmlzIGdvaW5nIHRvIElu dGVybmV0IFN0YW5kYXJkLiAgSWYgaXQgaXMgYSBjaGFuZ2UsIHRoZW4gaXQgc2hvdWxkIG5vdCBi ZSBpbmNsdWRlZC4NCj4+PiANCj4+PiBJbiBteSBwZXJzb25hbCB2aWV3IChhcyBvbmUgb2YgdGhl IGF1dGhvcnMgb2YgcmZjMjQ2MCksIEkgdGhpbmsgaXQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQg dG8gbm90IGFsbG93IGV4dGVuc2lvbiBoZWFkZXJzIHRvIGJlIGluc2VydGVkLiAgTXkgdGhpbmtp bmcgaXMgdGhhdCBub3QgYWxsb3dpbmcgZXh0ZW5zaW9uIGhlYWRlcnMgdG8gYmUgaW5zZXJ0ZWQg aXMgcmVsYXRlZCB0aGUgZGVzaWduIG9mIElQdjYgdGhhdCBpbmNsdWRlcyBvbmx5IHN1cHBvcnRp bmcgZnJhZ21lbnRhdGlvbiBhdCB0aGUgc291cmNlLiAgSVB2NCBhbGxvd3MgdGhlIGFkZGl0aW9u IG9mIG9wdGlvbnMgcmVzdWx0aW5nIGluIGNoYW5naW5nIHRoZSBoZWFkZXIgbGVuZ3RoLCBidXQg aXQgaW5jbHVkZXMgcGVyLWhvcCBmcmFnbWVudGF0aW9uIHNvIGFueSByZXN1bHRpbmcgTVRVIGlz c3VlcyBjYW4gYmUgZGVhbHQgd2l0aC4gIEV2ZW4gSVB2NCBmcmFnbWVudHMgY2FuIGJlIGZyYWdt ZW50ZWQuICBJIHRoaW5rIGl0IGlzIGEgY29uc2VxdWVuY2Ugb2YgSVB2NiBub3QgYWxsb3cgcGVy LWhvcCBmcmFnbWVudGF0aW9uLCB0aGF0IGV4dGVuc2lvbiBoZWFkZXJzIHdlcmUgbm90IGludGVu ZGVkIHRvIGJlIGluc2VydGVkIGFsb25nIHRoZSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbi4NCj4+ IA0KPj4gSSB0aGluayB0aGlzIGV4YWN0bHkgY29ycmVjdC4gSSBkaWQgYSBiaXQgb2YgYXJjaGFl b2xvZ3kgYW5kIGZvdW5kIHRoZSBtZXNzYWdlDQo+PiB3aGVyZSBTdGV2ZSBEZWVyaW5nIHN1bW1h cmlzZWQgdGhlIGlzc3VlcyByZXNvbHZlZCBiZWZvcmUgUkZDIDE4ODMgKHRoZSBwcmVkZWNlc3Nv cg0KPj4gb2YgUkZDIDI0NjApIHdhcyBwdWJsaXNoZWQgaW4gMTk5NS4gSSd2ZSBhdHRhY2hlZCBp dCBiZWxvdyAtIGxvb2sganVzdCBhZnRlcg0KPj4gInJlamVjdGVkIGF0IHRoZSBTdG9ja2hvbG0g bWVldGluZyIgaS5lLiBJRVRGIDMzLiBUaGUgY29tbWVudCB0aGF0IHRyaWdnZXJlZA0KPj4gaXQg d2FzIGluIG1lc3NhZ2UgKElQbmcgMzQ2KSBmcm9tIENoYXJsaWUgTHlubiBzZW50IDMwIEp1bmUg MTk5NS4NCj4+IA0KPj4gW0kga25ldyBteSBtYWlsIGFyY2hpdmVzIHdvdWxkIGJlIHVzZWZ1bCBv bmUgZGF5Ll0NCj4gDQo+IFN0dW5uaW5nIHJlY29sbGVjdGlvbiBwb3dlcnMgQnJpYW4hDQo+IA0K PiBUaGUgcGFyYWdyYXBoIHlvdSBwb2ludCB0bywgaS5lLjoNCj4gDQo+IAkicmVhc29ucyBmb3Ig cmVqZWN0aW9uOiBpbnNlcnRpb24gb2YgZXh0ZW5zaW9uIGhlYWRlcnMgZW4tcm91dGUgYnJlYWtz DQo+ICAgICAJUE1UVS1kaXNjb3ZlcnkgYW5kIGNhbiByZXN1bHQgaW4gSUNNUCBlcnJvciBtZXNz YWdlcyBiZWluZyBzZW50IHRvDQo+ICAgICAJbm9uLWd1aWx0eSBwYXJ0aWVzLiAgVGhlIGRlc2ly ZWQgZWZmZWN0IGNhbiBiZSBhY2hpZXZlZCwgYW5kIHRob3NlDQo+ICAgICAJcHJvYmxlbXMgYXZv aWRlZCwgYnkgdXNpbmcgZW4tcm91dGUgZW5jYXBzdWxhdGlvbiAod2l0aCBvcHRpb25hbA0KPiAg ICAgCVJvdXRpbmcgSGVhZGVyKSByYXRoZXIgdGhhbiBoZWFkZXIgaW5zZXJ0aW9uLuKAnQ0KPiAN Cj4gc3RpbGwgc2VlbXMgdmFsaWQgdG8gbWUsIGFuZCB0aHVzIEkgYWdyZWUgd2l0aCBCb2LigJlz IHByb3Bvc2FsLiBXaGV0aGVyIHRoZSBhYm92ZSByYXRpb25hbGUgaXMgYWxzbyBpbmNsdWRlZCBp cyBhbiBhZGRpdGlvbmFsIHF1ZXN0aW9uLg0KPiANCj4gRm9yIGV4YW1wbGUsIGluIHNlY3Rpb24g Mi4yIG9mZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGl0IHN0YXRlczog IkF0IHRoZSBpbmdyZXNzIG5vZGUgb2YgYW4gU1IgZG9tYWluIHdoZXJlIHRoZSBpbmdyZXNzIG5v ZGUgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRlcyBpdCBpbnRvIGFuIG91 dGVyIElQdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGEgU2VnbWVudCBSb3V0aW5nIGhlYWRlci7igJ0N Cg0KDQpDb3JyZWN0LiBUaGUgZGlzY3Vzc2lvbiB3ZeKAmXJlIGhhdmluZyBpcyBub3QgcmVsYXRl ZCB0byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBidXQgcmF0aGVyIG9u IGEgdXNhZ2Ugb2YgdGhlIFNSSCB0aGF0IHRoZSBpbmR1c3RyeSBpcyBhZG9wdGluZyBhbmQgdGhh dCBpbmNsdWRlcyBoZWFkZXIgaW5zZXJ0aW9uLiANCg0Kcy4NCg0KDQo+IA0KPiBUaW0NCj4gDQo+ PiAgIEJyaWFuDQo+PiANCj4+PiBOb3RlLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGZpbmUgZm9yIHNv bWVvbmUgdG8gZG9jdW1lbnQgaG93IHRvIGRvIGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0aW9uLCBh cyBsb25nIGFzIHRoZXkgZGVzY3JpYmUgaG93IGl0IHdvcmtzLCBhbmQgaG93IHRvIGRlYWwgaXNz dWVzIGxpa2UgTVRVIHByb2JsZW1zLiAgVGhpcyBjYW4gYmUgYmUgYW4gdXBkYXRlIHRvIHJmYzI0 NjBiaXMgKGFmdGVyIGl0IGlzIHB1Ymxpc2hlZCkuDQo+Pj4gDQo+Pj4gSG93ZXZlciwgSSBkbyBu b3QgdGhpbmsgbGVhdmluZyB0aGUgcmZjMjQ2MGJpcyB0ZXh0IGluIGFuIGFtYmlndW91cyBzdGF0 ZSBvbiB0aGlzIHRvcGljIGlzIGEgZ29vZCBpZGVhLg0KPj4+IA0KPj4+IENvbW1lbnRzPw0KPj4+ IA0KPj4+IFRoYW5rcywNCj4+PiBCb2INCj4+IA0KPj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3Nh Z2UgLS0tLS0tLS0NCj4+IFN1YmplY3Q6IChJUG5nIDYwOSkgY2hhbmdlcyB0byBMYXN0IENhbGwn ZWQgc3BlY3MNCj4+IERhdGU6IFN1biwgMjcgQXVnIDE5OTUgMjA6NTk6MjYgUERUDQo+PiBGcm9t OiBTdGV2ZSBEZWVyaW5nIDxkZWVyaW5nQHBhcmMueGVyb3guY29tPg0KPj4gVG86IGlwbmdAc3Vu cm9vZi5lbmcuc3VuLmNvbQ0KPj4gQ0M6IGRlZXJpbmdAcGFyYy54ZXJveC5jb20NCj4+IA0KPj4g QXQgdGhlIHJlcXVlc3Qgb2Ygb3VyIEFEcywgSSBwcmVwYXJlZCB0aGUgZm9sbG93aW5nIGxpc3Qg b2YgYWdyZWVkLXVwb24NCj4+IGNoYW5nZXMgYW5kIG91dHN0YW5kaW5nIGlzc3VlcyB3aXRoIHRo ZSBzZXQgb2Ygc3BlY3MgdGhhdCB1bmRlcndlbnQNCj4+IElFVEYtd2lkZSBMYXN0IENhbGwgaW4g SnVuZSBhbmQgSnVseS4gIFBsZWFzZSBsZXQgbWUga25vdyBvZiBhbnkgZXJyb3JzDQo+PiBvciBv bWlzc2lvbnMuDQo+PiANCj4+IFN0ZXZlDQo+PiANCj4+ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo+PiANCj4+IElQdjYgU3BlY2lmaWNhdGlvbg0KPj4gLS0tLS0tLS0tLS0t LS0tLS0tDQo+PiANCj4+IFRoZSBmb2xsb3dpbmcgY2hhbmdlcyB3ZXJlIHBvc3RlZCB0byB0aGUg SUVURiBsaXN0IGltbWVkaWF0ZWx5IGZvbGxvd2luZw0KPj4gdGhlIExhc3QgQ2FsbCwgc28gSSB0 aGluayB3ZSBjYW4gY29uc2lkZXIgdGhlbSB0byBhbHNvIGhhdmUgYmVlbiBMYXN0IENhbGxlZDoN Cj4+IA0KPj4gLSBJbiB0aGUgZXhhbXBsZXMgb2YgaG93IHRvIGxheSBvdXQgb3B0aW9ucywgb24g cGFnZSAyOSwgdHdvIHBsYWNlcw0KPj4gICB3aGVyZSBpdCBzYXlzICJIZHIgRXh0IExlbj0xIiBz aG91bGQgYmUgIkhkciBFeHQgTGVuPTMiDQo+PiAgIChyZXBvcnRlZCBieSBIYW1pZCBBc2F5ZXNo KS4NCj4+IA0KPj4gLSBJbiBzZWN0aW9uIDYsIEZsb3cgTGFiZWxzLCBJIGZvcmdvdCB0byBpbmNs dWRlIHRoZSBQcmlvcml0eSBmaWVsZA0KPj4gICBpbiB0aGUgbGlzdCBvZiBmaWVsZHMgdGhhdCBt dXN0IGhhdmUgdGhlIHNhbWUgdmFsdWUgZm9yIGFsbA0KPj4gICBwYWNrZXRzIGluIHRoZSBzYW1l IGZsb3cgKHJlcG9ydGVkIGJ5IE1hcmt1cyBKb3JrKS4NCj4+IA0KPj4gLSBUaGUgZGVzY3JpcHRp b24gb2Ygd2hhdCB0aGUgSnVtYm8gUGF5bG9hZCBMZW5ndGggZmllbGQgY292ZXJzDQo+PiAgIHNo b3VsZCBiZSBtYWRlIGNsZWFyZXIgKHJlcG9ydGVkIGJ5IENocmlzdGlhbiBIdWl0ZW1hKS4NCj4+ IA0KPj4gVGhlIGZvbGxvd2luZyBjaGFuZ2VzIHdlcmUgcHJvcG9zZWQgYnkgQ2hhcmxpZSBMeW5u IGluIHRoZSBvbmx5ICJmb3JtYWwiDQo+PiByZXNwb25zZSB0byB0aGUgTGFzdCBDYWxsLCBhbmQg YWNjZXB0ZWQgYXQgdGhlIGZpcnN0IGlwbmd3ZyBtZWV0aW5nIGluDQo+PiBTdG9ja2hvbG06DQo+ PiANCj4+IC0gRm9yIG9wdGlvbnMgY29udGFpbmluZyBkYXRhIHRoYXQgY2FuIGNoYW5nZSBlbi1y b3V0ZSAoYW5kIHdoaWNoIHRoZXJlZm9yZQ0KPj4gICBoYXZlIHRoZSB0aGlyZC1oaWdoZXN0LW9y ZGVyIGJpdCBvZiB0aGVpciBPcHRpb24gVHlwZSBzZXQgdG8gMSksIG1ha2UgaXQNCj4+ICAgY2xl YXIgdGhhdCAqYWxsKiBieXRlcyBvZiB0aGUgT3B0aW9uIERhdGEgZmllbGQgYXJlIHRvIGJlIGV4 Y2x1ZGVkIGZyb20NCj4+ICAgdGhlIEF1dGhlbnRpY2F0aW9uIGZ1bmN0aW9uLCBhbmQgZXhwbGFp biB0aGF0ICJleGNsdWRlZCIgbWVhbnMgInRyZWF0ZWQNCj4+ICAgYXMgaWYgdGhleSB3ZXJlIGFs bCB6ZXJvLXZhbHVlZCBieXRlcyIuDQo+PiANCj4+IC0gQ2hhbmdlIHRoZSBSb3V0aW5nIEhlYWRl ciB0byBlbmFibGUgaXQgdG8gYmUgaWdub3JlZCBieSBmaW5hbCBkZXN0aW5hdGlvbnMNCj4+ICAg dGhhdCBkbyBub3QgdW5kZXJzdGFuZCB0aGUgUm91dGluZyBUeXBlLiAgSW4gU3RvY2tob2xtLCBE ZWVyaW5nIHByb3Bvc2VkLA0KPj4gICBhbmQgdGhlIGF0dGVuZGVlcyBhZ3JlZWQgd2l0aCwgdGhl IGZvbGxvd2luZyByZXZpc2VkIGZvcm1hdCBmb3IgdGhlDQo+PiAgIGZpcnN0IDMyIGJpdHMgb2Yg dGhlIFJvdXRpbmcgSGVhZGVyLCBmb3IgYWxsIFJvdXRpbmcgVHlwZXM6DQo+PiANCj4+ICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+PiAgICB8ICBOZXh0IEhlYWRlciAgfCAgSGRyIEV4dCBMZW4gIHwgIFJvdXRpbmcg VHlwZSB8IFNlZ21lbnRzIExlZnQgfA0KPj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+ICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ PiANCj4+ICAgd2hlcmUNCj4+IA0KPj4gCUhkciBFeHQgTGVuICAgaXMgdGhlIGxlbmd0aCBvZiB0 aGUgaGVhZGVyIGluIDgtb2N0ZXQgdW5pdHMsIG5vdA0KPj4gCSAgICAgICAgICAgICAgaW5jbHVk aW5nIHRoZSBmaXJzdCA4IG9jdGV0cw0KPj4gDQo+PiAJU2VnbWVudHMgTGVmdCBpcyB0aGUgbnVt YmVyIG9mICJsZWdzIiBsZWZ0IHRvIHRyYXZlcnNlIGluIHRoZQ0KPj4gICAgICAgICAgICAgICAg ICAgICByb3V0ZTsgaWYgdGhpcyB2YWx1ZSBpcyB6ZXJvLCB0aGUgcmVjZWl2ZXIgbWF5DQo+PiAJ ICAgICAgICAgICAgICBpZ25vcmUgdGhpcyBoZWFkZXIgKGkuZS4sIGl0IGluZGljYXRlcyB0aGF0 IHRoZQ0KPj4gCSAgICAgICAgICAgICAgcm91dGUgaGFzIGJlZW4gY29tcGxldGVkKSwgd2hldGhl ciBvciBub3QgdGhlDQo+PiAJICAgICAgICAgICAgICByZWNlaXZlciB1bmRlcnN0YW5kcyB0aGUg Um91dGluZyBUeXBlDQo+PiANCj4+IFRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBjaGFuZ2VzIHdl cmUgYWdyZWVkIHRvIGVpdGhlciBvbiB0aGUgbWFpbGluZyBsaXN0DQo+PiBvciBpbiB0aGUgU3Rv Y2tob2xtIG1lZXRpbmdzOg0KPj4gDQo+PiAtICJJbXByb3ZlIiB0aGUgaG9zdC9yb3V0ZXIgdGVy bWlub2xvZ3kuICBXaGF0IEkgcHJvcG9zZSB0byBkbyBpcyBhZGQgYQ0KPj4gICBmb290bm90ZSB0 byB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBzYXlpbmcgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4+ IA0KPj4gCSogaXQgaXMgcG9zc2libGUsIHRob3VnaCB1bnVzdWFsLCB0byBoYXZlIGEgZGV2aWNl IHdpdGggbXVsdGlwbGUNCj4+ICAgICAgICAgaW50ZXJmYWNlcyBjb25maWd1cmVkIHRvIGZvcndh cmQgbm9uLXNlbGYtZGVzdGluZWQgcGFja2V0cw0KPj4gICAgICAgICBhcnJpdmluZyBmcm9tIHNv bWUgc2V0IChmZXdlciB0aGFuIGFsbCkgb2YgaXRzIGludGVyZmFjZXMsIGFuZA0KPj4gCSAgdG8g ZGlzY2FyZCBub24tc2VsZi1kZXN0aW5lZCBwYWNrZXRzIGFycml2aW5nIGZyb20gaXRzIG90aGVy DQo+PiAJICBpbnRlcmZhY2VzLiAgU3VjaCBhIGRldmljZSBtdXN0IG9iZXkgdGhlIHByb3RvY29s IHJlcXVpcmVtZW50cw0KPj4gCSAgZm9yIHJvdXRlcnMgd2hlbiByZWNlaXZpbmcgcGFja2V0cyBm cm9tLCBhbmQgaW50ZXJhY3Rpbmcgd2l0aA0KPj4gCSAgbmVpZ2hib3JzIG92ZXIsIHRoZSBmb3Jt ZXIgKGZvcndhcmRpbmcpIGludGVyZmFjZXMuICBJdCBtdXN0DQo+PiAJICBvYmV5IHRoZSBwcm90 b2NvbCByZXF1aXJlbWVudHMgZm9yIGhvc3RzIHdoZW4gcmVjZWl2aW5nIHBhY2tldHMNCj4+IAkg IGZyb20sIGFuZCBpbnRlcmFjdGluZyB3aXRoIG5laWdoYm9ycyBvdmVyLCB0aGUgbGF0dGVyIChu b24tDQo+PiAJICBmb3J3YXJkaW5nKSBpbnRlcmZhY2VzLg0KPj4gDQo+PiAgIENvbW1lbnRzPw0K Pj4gDQo+PiAtIENsYXJpZnkgdGhlIG9wZXJhdGlvbiBvZiBUeXBlIDAgUm91dGluZyBIZWFkZXIg YnkgZ2l2aW5nIGFuIGV4YW1wbGUsDQo+PiAgIHNob3dpbmcgdGhlIHZhbHVlcyBvZiB0aGUgaGVh ZGVyIGZpZWxkcyBvbiBlYWNoIHNlZ21lbnQgb2YgdGhlIHJvdXRlLg0KPj4gDQo+PiAtIENsYXJp ZnkgdGhlIGhhbmRsaW5nIG9mIG9wdGlvbnMsIGV4dGVuc2lvbiBoZWFkZXJzLCBOZXh0IEhlYWRl ciBmaWVsZHMsDQo+PiAgIGV0Yy4gZm9yIGZyYWdtZW50ZWQgcGFja2V0cyBieSBnaXZpbmcgYSBm ZXcgZXhhbXBsZXMgb2YgcGFja2V0cyBiZWZvcmUNCj4+ICAgYW5kIGFmdGVyIGZyYWdtZW50YXRp b24gKHN1Z2dlc3RlZCBieSBEaW1pdHJ5IEhhc2tpbnMgYW5kIG90aGVycykuDQo+PiANCj4+IC0g U3BlY2lmeSB0aGF0IGZyYWdtZW50cyBjYW5ub3QgcmVhc3NlbWJsZSB0byBmb3JtIGEganVtYm9n cmFtIChzdWdnZXN0ZWQNCj4+ICAgYnkgQ3JhaWcgTWV0eikuDQo+PiANCj4+IA0KPj4gSUNNUHY2 IFNwZWNpZmljYXRpb24NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IC0gQWRkIG5v dGUgd2FybmluZyBhYm91dCB0aGUgcG9zc2liaWxpdHkgb2YgdXBwZXItbGF5ZXIgaGVhZGVyIGJl aW5nDQo+PiAgIHRydW5jYXRlZCBmcm9tIHRoZSByZXR1cm5lZCBwYWNrZXQgaW4gYW4gZXJyb3Ig bWVzc2FnZSwgZHVlIHRvIGxhcmdlDQo+PiAgIG51bWJlciBvZiBleHRlbnNpb24gaGVhZGVyIGJ5 dGVzLCB3aGljaCBjYW4gZGVmZWF0IGRlbGl2ZXJ5IG9mIHRoZQ0KPj4gICBlcnJvciBtZXNzYWdl IHRvIHRoZSBndWlsdHkgdXBwZXItbGF5ZXIgcHJvdG9jb2wgaW5zdGFuY2UuDQo+PiANCj4+IC0g RGVsZXRlIGRlc2NyaXB0aW9uIG9mIHBzZXVkby1oZWFkZXIsIHJlcGxhY2luZyBpdCB3aXRoIGEg cmVmZXJlbmNlIHRvDQo+PiAgIHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgSVB2NiBzcGVjIChzdWdn ZXN0ZWQgYnkgQWxpc3RhaXIgQmVsbCBhbmQNCj4+ICAgTWFyYyBIYXNzb24pLg0KPj4gDQo+PiAt IENvcnJlY3QgZXhhbXBsZSBvZiB1c2FnZSBvZiB0aGUgcG9pbnRlciBpbiB0aGUgUGFyYW1ldGVy IFByb2JsZW0NCj4+ICAgbWVzc2FnZSBvbiBwYWdlIDE1LCBieSBjaGFuZ2luZyAiNDgiIHRvICI0 MCIgKHJlcG9ydGVkIGJ5IERpbWl0cnkNCj4+ICAgSGFza2lucyBhbmQgRnJhbmNpcyBEdXBvbnQp Lg0KPj4gDQo+PiAtIE5vdGUgdGhhdCB0aGVyZSBpcyBhbm90aGVyIGV4Y2VwdGlvbiB0byB0aGUg Im5vIElDTVAgZXJyb3IgbWVzc2FnZXMNCj4+ICAgaW4gcmVzcG9uc2UgdG8gbXVsdGljYXN0cyIg cnVsZSwgd2hpY2ggaXMgInVucmVjb2duaXplZCBvcHRpb24iDQo+PiAgIFBhcmFtZXRlciBQcm9i bGVtIG1lc3NhZ2VzIGluIHJlc3BvbnNlIHRvIG9wdGlvbnMgd2l0aCBoaWdoLW9yZGVyDQo+PiAg IGJpdHMgIjEwLi4uIiAocmVwb3J0ZWQgYnkgRGltaXR5IEhhc2tpbnMpLg0KPj4gDQo+PiBBZGRy ZXNzIEFyY2hpdGVjdHVyZSBEb2N1bWVudA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+IA0KPj4gLSBBZGQgZGVmaW5pdGlvbiBvZiAibGluay1sb2NhbCBhZGRyZXNzIiB0byB0 aGUgdGVybWlub2xvZ3kgc2VjdGlvbg0KPj4gICAoc3VnZ2VzdGVkIGJ5IEppbSBCb3VuZCkuDQo+ PiANCj4+IC0gU3BlY2lmeSB0aGF0ICI6OiIgaXMgYSBsZWdhbCB0ZXh0IHJlcHJlc2VudGF0aW9u IG9mIHRoZSBVbnNwZWNpZmllZA0KPj4gICAoYWxsLXplcm9zKSBBZGRyZXNzIChzdWdnZXN0ZWQg YnkgRnJhbmNpcyBEdXBvbnQpLg0KPj4gDQo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj4gDQo+PiBUaGUgZm9sbG93aW5nIHN1Z2dlc3Rpb25zIGluIENoYXJsaWUgTHlu bidzIGZvcm1hbCByZXNwb25zZSB0byB0aGUgTGFzdCBDYWxsDQo+PiB3ZXJlIHJlamVjdGVkIGF0 IHRoZSBTdG9ja2hvbG0gbWVldGluZzoNCj4+IA0KPj4gLSBBZGQgYSBiaXQgdG8gdGhlIFJvdXRp bmcgSGVhZGVyIGluZGljYXRpbmcgd2hldGhlciBvciBub3QgaXQgd2FzDQo+PiAgIGluc2VydGVk IGludG8gdGhlIHBhY2tldCBlbi1yb3V0ZSwgaS5lLiwgYnkgYSBub2RlIG90aGVyIHRoYW4gdGhl DQo+PiAgIHBhY2tldCdzIG9yaWdpbmF0b3IuDQo+PiANCj4+ICAgICByZWFzb25zIGZvciByZWpl Y3Rpb246IGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBlbi1yb3V0ZSBicmVha3MNCj4+ ICAgICBQTVRVLWRpc2NvdmVyeSBhbmQgY2FuIHJlc3VsdCBpbiBJQ01QIGVycm9yIG1lc3NhZ2Vz IGJlaW5nIHNlbnQgdG8NCj4+ICAgICBub24tZ3VpbHR5IHBhcnRpZXMuICBUaGUgZGVzaXJlZCBl ZmZlY3QgY2FuIGJlIGFjaGlldmVkLCBhbmQgdGhvc2UNCj4+ICAgICBwcm9ibGVtcyBhdm9pZGVk LCBieSB1c2luZyBlbi1yb3V0ZSBlbmNhcHN1bGF0aW9uICh3aXRoIG9wdGlvbmFsDQo+PiAgICAg Um91dGluZyBIZWFkZXIpIHJhdGhlciB0aGFuIGhlYWRlciBpbnNlcnRpb24uDQo+PiANCj4+IC0g Q2hhbmdlIElDTVAgZXJyb3IgbWVzc2FnZXMgdG8gY29udGFpbiBleHBsaWNpdCBmaWVsZHMgaWRl bnRpZnlpbmcgdGhlDQo+PiAgIHVwcGVyLWxheWVyIHByb3RvY29sIHRvIHdoaWNoIHRoZSBlcnJv ciBtZXNzYWdlIHNob3VsZCBiZSBkZWxpdmVyZWQuDQo+PiANCj4+ICAgICByZWFzb25zIGZvciBy ZWplY3Rpb246IGNvbnNpZGVyZWQgdW5uZWNlc3NhcnkgY29tcGxleGl0eSB0byBoYW5kbGUgdGhl DQo+PiAgICAgcmFyZSBjYXNlIG9mIHRydW5jYXRpb24gb2YgdHJhbnNwb3J0IGhlYWRlciBmcm9t IHRoZSByZXR1cm5lZCBwYWNrZXQNCj4+ICAgICBiZWNhdXNlIG9mIHRvbyBtYW55IGV4dGVuc2lv biBoZWFkZXIgb2N0ZXRzLiAgU3VjaCBlcnJvciBtZXNzYWdlcyBhcmUNCj4+ICAgICBzdGlsbCB1 c2FibGUgZm9yIHByb2JsZW0gZGlhZ25vc2lzIG90aGVyIHRoYW4gaW4gdGhlIHVwcGVyLWxheWVy DQo+PiAgICAgaXRzZWxmLCBlLmcuLCBpZiBsb2dnZWQgYXQgSVB2NiBsYXllciBvciBvYnNlcnZl ZCBpbiBhIHBhY2tldCB0cmFjZS4NCj4+ICAgICBXaWxsIGFkZCB3YXJuaW5nIHRvIHRoZSBJQ01Q djYgc3BlYyBhYm91dCBjb25zZXF1ZW5jZXMgb2YgbG9uZw0KPj4gICAgIGV4dGVuc2lvbiBoZWFk ZXIgb24gSUNNUCBlcnJvciBtZXNzYWdlIGRpc3BhdGNoaW5nLg0KPj4gDQo+PiAtIENoYW5nZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIElDTVB2NiBzcGVjIHRvIHNwZWNpZnkg d2hlbg0KPj4gICBhbmQgaG93IHRvIGluY2x1ZGUgYW4gQXV0aGVudGljYXRpb24gSGVhZGVyIGlu IElDTVAgZXJyb3IgbWVzc2FnZXMuDQo+PiANCj4+ICAgICByZWFzb25zIGZvciByZWplY3Rpb246 IGdyb3VwIGNvbnNlbnN1cyB0aGF0IHRoaXMgYmVsb25ncyBpbiBhYQ0KPj4gICAgIElQc2VjIHNw ZWMgaW5zdGVhZC4NCj4+IA0KPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4+IA0KPj4gVGhlIGZvbGxvd2luZyBpc3N1ZXMgYW5kIHN1Z2dlc3Rpb25zIGhhdmUgYmVlbiBk aXNjdXNzZWQgb24gdGhlIG1haWxpbmcgbGlzdA0KPj4gc2luY2UgdGhlIGJhc2Ugc3BlY3Mgd2Vu dCB0byBMYXN0IENhbGwsIGJ1dCBubyBncm91cCBjb25zZW5zdXMgb24gdGhlc2UgaXNzdWVzDQo+ PiBoYXMgYmVlbiByZWFjaGVkIHlldDoNCj4+IA0KPj4gLSBGcmFnbWVudGF0aW9uIGlzc3VlczoN Cj4+IAktIGNoYW5nZSB0aGUgbWluaW11bSByZWFzc2VtYmx5IGJ1ZmZlciBzaXplIHRvIGEgbnVt YmVyIGxhcmdlcg0KPj4gCSAgdGhhbiA1NzY/DQo+PiAJLSBzcGVjaWZ5IHRoYXQgc291cmNlcyBv ZiBmcmFnbWVudGVkIHBhY2tldHMgbXVzdCB1c2UgdGhlIG1pbmltYWwNCj4+IAkgIG51bWJlciBv ZiBmcmFnbWVudHMgcmVxdWlyZWQgdG8gZml0IGluIHRoZSBwZXJjZWl2ZWQgUE1UVT8NCj4+IAkt IHNwZWNpZnkgdGhhdCBhbGwgZnJhZ21lbnRzIHdpdGggdGhlIE0gYml0IHNldCBtdXN0IGJlIG5v IGxlc3MNCj4+IAkgIHRoYW4gNyBvY3RldHMgc2hvcnRlciB0aGFuIHRoZSBwZXJjZWl2ZWQgUE1U VT8NCj4+IAktIHNwZWNpZnkgdGhhdCBhbGwgZnJhZ21lbnRzIHdpdGggdGhlIE0gYml0IHNldCBt dXN0IGJlIG5vIHNob3J0ZXINCj4+IAkgIHRoYW4gNTc2IG9jdGV0cz8NCj4+IAktIGlnbm9yZSBm cmFnbWVudHMgdGhhdCBwYXJ0aWFsbHkgb3ZlcmxhcCBvdGhlciBmcmFnbWVudHMgb2YgdGhlDQo+ PiAJICBzYW1lIHBhY2tldCwgb3IgZGlzY2FyZCBhbnkgcGFja2V0IHRoYXQgYXJyaXZlcyBhcyBw YXJ0aWFsbHkNCj4+IAkgIG92ZXJsYXBwaW5nIGZyYWdtZW50cz8NCj4+IA0KPj4gLSBSb3V0aW5n IEhlYWRlciBpc3N1ZXM6DQo+PiAJLSBhZGQgYSAiVG90YWwgTGVuZ3RoIiBmaWVsZCB0byB0aGUg ZnJhZ21lbnQgaGVhZGVyLCBjYXJyeWluZyB0aGUNCj4+IAkgIGxlbmd0aCBvZiB0aGUgb3JpZ2lu YWwsIHVuZnJhZ21lbnRlZCBwYWNrZXQ/DQo+PiAJLSBmb3JiaWQgZm9yd2FyZGluZyBvZiBwYWNr ZXRzIHdpdGggUm91dGluZyBIZWFkZXJzIGJ5IGhvc3RzPw0KPj4gCSAgKGlmIG5vdCwgbWFrZSBp dCBjbGVhcmVyIHRoYXQgaG9zdHMgYXJlIGV4cGVjdGVkIHRvIGZvcndhcmQNCj4+IAkgIHBhY2tl dHMgd2l0aCBSb3V0aW5nIEhlYWRlcnMsIGlmIHRoZXkgYXJlIGludGVybWVkaWF0ZSB0YXJnZXRz DQo+PiAJICBvZiBzdWNoIHBhY2tldHMuKQ0KPj4gCS0gc3BlY2lmeSB0aGUgcmV2ZXJzaW5nIHJ1 bGVzIGZvciBwYWNrZXRzIHRoYXQgYXJlIHJlc3BvbnNlcyB0bw0KPj4gCSAgcGFja2V0cyB0aGF0 IGNhcnJ5IGEgUm91dGluZyBIZWFkZXI/DQo+PiAJLSBmb3JiaWQgb3IgZGlzY291cmFnZSByZXZl cnNhbCBvZiBhbiB1bmF1dGhlbnRpY2F0ZWQgUm91dGluZyBIZWFkZXI/DQo+PiAJLSBmb3JiaWQg b3IgZGlzY291cmFnZSBhY2NlcHRhbmNlIG9mIGEgcGFja2V0IHdpdGggYW4gdW5hdXRoZW50aWNh dGVkDQo+PiAJICBSb3V0aW5nIEhlYWRlcj8NCj4+IA0KPj4gLSBBbGxvdyB0aGUgdHJhbnNwb3J0 LWxheWVyIGNoZWNrc3VtIHRvIGJlIG9taXR0ZWQgd2hlbiB0aGUgQXV0aGVudGljYXRpb24NCj4+ ICAgaGVhZGVyIChvciB0aGUgRVNQIGhlYWRlcj8pIGlzIGJlaW5nIHVzZWQ/DQo+PiANCj4+IC0g QWRkIGEgQ29uZ2VzdGlvbiBJbmRpY2F0aW9uIGJpdCB0byB0aGUgYmFzZSBJUHY2IGhlYWRlcj8N Cj4+IA0KPj4gLSBBZGQgTVVTVC9TSE9VTEQvTUFZIGNvbmZvcm1hbmNlIHJlcXVpcmVtZW50cyBm b3IgYWxsIElQdjYgZmllbGRzIGFuZA0KPj4gICBmdW5jdGlvbnM/DQo+PiANCj4+IC0gQnVpbGQg YSBzaW5nbGUgVGVybWlub2xvZ3kgZG9jdW1lbnQsIHRvIGJlIHNoYXJlZCAoZWl0aGVyIGJ5IHJl ZmVyZW5jZQ0KPj4gICBvciBpbmNsdXNpb24pIGluIGFsbCBJUHY2LXJlbGF0ZWQgc3BlY3M/DQo+ PiANCj4+IC0gQWxsb3cgdGhlIHVzZSBvZiB6ZXJvIGluIHRoZSBVRFAgTGVuZ3RoIGZpZWxkIHRv IGluZGljYXRlIHRoYXQgdGhlIFVEUA0KPj4gICBsZW5ndGggc2hvdWxkIGJlIGRlcml2ZWQgZnJv bSB0aGUgSnVtYm9ncmFtIE9wdGlvbj8NCj4+IA0KPj4gTm90ZTogdGhlIGFib3ZlIGxpc3QgZG9l cyBub3QgaW5jbHVkZSBpc3N1ZXMgY29uY2VybmluZyB0aG9zZSBzcGVjcyB0aGF0DQo+PiBoYXZl IG5vdCB5ZXQgYmVlbiBzdWJqZWN0ZWQgdG8gV0cgb3IgSUVURiBMYXN0IENhbGwsIGUuZy4sIHRo ZSBOZWlnaGJvcg0KPj4gRGlzY292ZXJ5IHNwZWMuDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gSUVURiBJUG5nIE1haWxpbmcgTGlzdAkJICAgICAgRlRQIGFyY2hpdmU6IGZ0cC5w YXJjLnhlcm94LmNvbTovcHViL2lwbmcNCj4+IElQbmcgSG9tZSBQYWdlOiAgICAgICAgICBodHRw Oi8vcGxheWdyb3VuZC5zdW4uY29tL3B1Yi9pcG5nL2h0bWwvaXBuZy1tYWluLmh0bWwNCj4+IERp cmVjdCBhbGwgYWRtaW5pc3RyYXRpdmUgcmVxdWVzdHMgdG8gbWFqb3Jkb21vQHN1bnJvb2YuZW5n LnN1bi5jb20NCj4+IA0KPj4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0 aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYN Cj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1 ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg== From nobody Thu Apr 28 07:42:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8042512D1D8 for ; Thu, 28 Apr 2016 07:42:02 -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=cooperw.in header.b=nLYa7uRL; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=VrIXhYNk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjI9v9hU2FHm for ; Thu, 28 Apr 2016 07:42:00 -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 B039112D176 for ; Thu, 28 Apr 2016 07:42:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C6A24212DF for ; Thu, 28 Apr 2016 10:41:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 28 Apr 2016 10:41:59 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=sM1bMCvbNp+wh/7ZZE/sFrsxqrI=; b=nLYa7u RLOYOQc9ZHQMgN9qV487WP54XkqJQbaLyTDSha0MRSqyV9ZFx/3bcTsdasucMGey ZoWAcJW89JGvBrOx4s3/mMQ9bv0gJVikaPWGCaC+jt9DMpd+Br/90FdwptKTmF8e etvQpqX7Duq4I6pv1yan9gFzj/hkV9+jTmhsM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=sM1bMCvbNp+wh/7 ZZE/sFrsxqrI=; b=VrIXhYNkmH5vZ/tkTBRkQWLXFoDYiDfikvgPomlwgg64nYu zfAT9cQSXo7wWjFM0wZDs1sWZm9xn7aaleN1oKTenlLBTMkd9EdOFNYZFY6lB2wM E7TKEN1Ho884dQH/LHKku/o45tvoyN9AHPJs9pni9Jgo59HH3f1nOD+rV20M= X-Sasl-enc: ymmPnNo7b/+tyiFobOoz855mOAO/9F90CS7VjVUpcHwi 1461854519 Received: from sjc-alcoop-88110.cisco.com (unknown [128.107.241.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 19A48C0001A for ; Thu, 28 Apr 2016 10:41:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-6man-default-iids-11.txt From: Alissa Cooper In-Reply-To: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 07:41:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:42:02 -0000 This version incorporates comments based on discussion before and during = IETF 95 (thanks to Fernando for spinning the rev). I think this version = addresses the comments received and should be ready to move forward. Alissa > On Apr 27, 2016, at 5:49 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Recommendation on Stable IPv6 Interface = Identifiers > Authors : Fernando Gont > Alissa Cooper > Dave Thaler > Will Liu > Filename : draft-ietf-6man-default-iids-11.txt > Pages : 23 > Date : 2016-04-27 >=20 > Abstract: > This document changes the default scheme for generating stable > Interface Identifiers with SLAAC to that specified in RFC7217, and > recommends against embedding link-layer addresses in IPv6 Interface > Identifiers. It formally updates RFC2464, RFC2467, RFC2470, = RFC2491, > RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, > RFC4391, RFC5072, and RFC5121, by removing the text in these RFCs > that required the IPv6 Interface Identifiers to be derived from the > underlying link-layer address, and replacing the aforementioned text > with a pointer to this document. Additionally, this document = updates > RFC3315 by specifying additional requirements on the generation of > Interface Identifiers used in Dynamic Host Configuration Protocol > version 6 (DHCPv6). It also provides advice to system = administrators > who employ manual configuration. This document does not change any > existing recommendations concerning the use of temporary addresses = as > specified in RFC 4941. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-default-iids-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-default-iids-11 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Apr 28 08:50:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC1A12D9AB for ; Thu, 28 Apr 2016 08:50:24 -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 uN9-a469Yl2S for ; Thu, 28 Apr 2016 08:50:23 -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 3CB1D12D8F8 for ; Thu, 28 Apr 2016 08:45:13 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 190so75259964iow.1 for ; Thu, 28 Apr 2016 08:45:13 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=FtqSIvBE4gOKS3R+wAQMaCTAnLYX+S2i76X4lBaUKcA=; b=Bb+uPquzAt2sU6wCvYe9GjTQgV2f8vp6ovQ92ukgfwplY2EyRzF1QM2VYl9Nl+QoJM By0zU+6vkQkW5lmRxTg8S4bzZDcycUQGFhU+VK9p6P113xRo6dUwLXxLCNuNG+ZcKPrT nJmVj4H7vVt7140C7x53CAek5svfoY1CmOxzY4G0/pcnNOeAAEIetCM8qOTKouFSB6Po aD3p+jGKX7+15AcdqN0j6FTotp4U4fu/qWbAyQ10h7thmynOs9a7DU6QzdJF5KyD8LVc eZD8+M8Am3tTlCni1cHLxV72MWkQRo81jMToK4isFwFoyg4smyStaGji2kLD8BY3J1Q/ 39vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=FtqSIvBE4gOKS3R+wAQMaCTAnLYX+S2i76X4lBaUKcA=; b=O72bLZJWO6F3dCR4KEcsmdRcMUBRKGvcdCyBQBVTscn32NlQSpT4THMG5fig40IKT5 8wu1JAXUBHu/tjVszL+2i8nWoqRc5yIG6z2mFzjQEarF+DG/bJkUeGJEXpQQ3arl7EFq YwOQSsh+NQzN/9RumJzbaFlEbSDFyE/1yUQpq+0Psx7yVZW7nu0lfDfPnqiawpDk6kdG ZfhuwBKVcKrYu4F2FnoAk1fliBruHqpkUZ96X4VhaptjrjG3wAakymHqThHHsoFVn6C1 DrwkiJPK3TOeuMD+Cjc67JMC4+6q0gv0/hhnnldRUuF039w1kThsIWDlgXY7dEtzK70e 0/nw== X-Gm-Message-State: AOPr4FXQ+fXqLQDig1Yb6vG5T/1KDII49rogkf/ukKfF0syjOgNFayy9OCax9HAUib/rB9lkcUFgmcIQ36FlWg== MIME-Version: 1.0 X-Received: by 10.107.9.74 with SMTP id j71mr19290764ioi.50.1461858312545; Thu, 28 Apr 2016 08:45:12 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 28 Apr 2016 08:45:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 08:45:12 -0700 Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: Tom Herbert To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 15:50:25 -0000 On Wed, Apr 27, 2016 at 6:18 PM, Bob Hinden wrote: > Hi, > > I would like to get closure on the question if inserting IPv6 extension h= eaders is allowed or not, and should this be a clarification in rfc2460bis.= This topic was discussed in Buenos Aires and on the mailing list. > > The relevant text from Section 4 "IPv6 Extension Headers" in > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > This text was added to the draft in version =E2=80=9401 published on 2 No= vember 2015. > > The question is if this text was the original intent of rfc2460. That wo= uld allow it to be part of rfc2460bis going to Internet Standard. If it is= a change, then it should not be included. > > In my personal view (as one of the authors of rfc2460), I think it was th= e original intent to not allow extension headers to be inserted. My thinki= ng is that not allowing extension headers to be inserted is related the des= ign of IPv6 that includes only supporting fragmentation at the source. IPv= 4 allows the addition of options resulting in changing the header length, b= ut it includes per-hop fragmentation so any resulting MTU issues can be dea= lt with. Even IPv4 fragments can be fragmented. I think it is a consequen= ce of IPv6 not allow per-hop fragmentation, that extension headers were not= intended to be inserted along the path to the destination. > > Note, I think it would be fine for someone to document how to do extensio= n header insertion, as long as they describe how it works, and how to deal = issues like MTU problems. This can be be an update to rfc2460bis (after it= is published). > > However, I do not think leaving the rfc2460bis text in an ambiguous state= on this topic is a good idea. > > Comments? > Bob, I agree that this should be clarified and extension headers cannot be inserted that change the length. It might be reasonable to allow insertion if it doesn't change the packet length though-- specifically I am thinking that a host might be able to set PadN to make space that can be overwritten in the path for inserted EHs. This allows insertion without changing the packet length or meaning of existing headers. Also, per: "IP Encapsulation must be used to meet any requirement for inserting headers, for example, as defined in [RFC2473]. I don't think proposing encapsulation as an alternative to insertion is normative. It won't necessarily have the same effect and it introduces issues regarding encapsulation. I think this statement can just be omitted from rfc2460bis without loss of clarity. Tom > Thanks, > Bob > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Apr 28 08:55:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C312DA22 for ; Thu, 28 Apr 2016 08:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.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 lnWVktQnh9PQ for ; Thu, 28 Apr 2016 08:55:00 -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 5325112DA92 for ; Thu, 28 Apr 2016 08:48:41 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0077.outbound.protection.outlook.com [213.199.154.77]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-14-6HBPwyqmSnCC18tHkwWoVQ-1; Thu, 28 Apr 2016 16:48:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n8jSYL1aGGZILIpTXgHWc8UETspYjX1sntdrhu1Z+GY=; b=I/BoDPzZ7SnXZuM3TeGabGhA1md3boKHqhX8TOKLB4b/+NQEBkkV/f8s3MgO0IaJF+ZUitCjmEA/NStkpY4I/Wda8Dylb4POwTCrgMmTd1p247kXqDRQG9E8NZAcixdyTRBfaDaBBAsI/o4rGnQzOwgeFVPNe/AnjXEgk6UH8X4= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 28 Apr 2016 15:48:32 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0466.028; Thu, 28 Apr 2016 15:48:32 +0000 From: Tim Chown To: "Stefano Previdi (sprevidi)" Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoP3VlQq8Gt0oREW1V7Q/DtgVAJ+fD1OAgABkpwCAABTegA== Date: Thu, 28 Apr 2016 15:48:32 +0000 Message-ID: <4EE1E34F-67DD-4F09-98A4-64B19ACCF3E2@jisc.ac.uk> References: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> <95B92AF8-CA66-4380-8F38-480A896C1B6B@cisco.com> In-Reply-To: <95B92AF8-CA66-4380-8F38-480A896C1B6B@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.188.254.49] x-ms-office365-filtering-correlation-id: f00c1f62-6c2a-4279-c2e7-08d36f7c8d51 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:UeTo5uBsWphr6nmFV/BbZvlqjsIv0tWiS1XvPW5t2CEmG42wcw8mv27Mxdqw7wlOBygu7I5V5OYiKVmJZRe/En0GVyTbFiGmHRtjhgF0tOQ+qPKOICTyDWSBZ9KLwKCbX5nyDw/QTy+FUXi1VTnTHg==; 24:Kdldv/IHqekHmkKPm/ExWEEObY/S+x3cHJiz96/WuuYtMxN+P0QnEQrCovxP6dRCfxko7D2SDB1C0RT8po91zxReF3ZYN2EPEMy9I8rtsbU=; 7:NeBKR+8quCKY3MIEeoIPf+bhqJ29jKKKIi/RVrhWY/DMG++sLW6max/8KEfjgfDywgJ8bmZy8jk/Q8vCsGXHiu/DLV3wawhQ3s7x3VEP2GWf0y4lbX4V387a3cqYnjI9E4J9YHJ7FQHS3trWbbk0qSAoqJHfXjoteZxDf4z+ipv+hBDfY3PWkpLTe8PXOuQL; 20:S94D6fvxciY4HNwtvASlryDHv5DPj5F+gRpqK+++VRym3vZ2mVteYGMeWKrUx5unbBDA9ePrYvjH3VCFJRbe6O0oyPL7cwswxfpSPm3OLu3+Gda2huAw8dqTUQDO878DDPNSuulgXmp97kz5kG/TfJGbKZ2lxBlgJRUTquppfSY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(36756003)(5890100001)(86362001)(106116001)(2906002)(87936001)(92566002)(3280700002)(3660700001)(6116002)(3846002)(102836003)(77096005)(57306001)(81166005)(561944003)(83716003)(66066001)(19580395003)(19580405001)(74482002)(4326007)(50986999)(50226002)(122556002)(76176999)(586003)(1096002)(1220700001)(2950100001)(110136002)(5002640100001)(11100500001)(10400500002)(5008740100001)(93886004)(82746002)(33656002)(15975445007)(5004730100002)(2900100001)(189998001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <8071389A2474104299EAFF485414307F@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 15:48:32.4601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: 6HBPwyqmSnCC18tHkwWoVQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 15:55:04 -0000 PiBPbiAyOCBBcHIgMjAxNiwgYXQgMTU6MzMsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIDxz cHJldmlkaUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4+IE9uIEFwciAyOCwgMjAxNiwgYXQgMTA6 MzMgQU0sIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPj4gDQo+PiBI aSwNCj4+IA0KPj4+IE9uIDI4IEFwciAyMDE2LCBhdCAwNDoyNiwgQnJpYW4gRSBDYXJwZW50ZXIg PGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gT24gMjgvMDQv MjAxNiAxMzoxOCwgQm9iIEhpbmRlbiB3cm90ZToNCj4+Pj4gSGksDQo+Pj4+IA0KPj4+PiBJIHdv dWxkIGxpa2UgdG8gZ2V0IGNsb3N1cmUgb24gdGhlIHF1ZXN0aW9uIGlmIGluc2VydGluZyBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzIGlzIGFsbG93ZWQgb3Igbm90LCBhbmQgc2hvdWxkIHRoaXMgYmUg YSBjbGFyaWZpY2F0aW9uIGluIHJmYzI0NjBiaXMuICBUaGlzIHRvcGljIHdhcyBkaXNjdXNzZWQg aW4gQnVlbm9zIEFpcmVzIGFuZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KPj4+PiANCj4+Pj4gVGhl IHJlbGV2YW50IHRleHQgZnJvbSBTZWN0aW9uIDQgIklQdjYgRXh0ZW5zaW9uIEhlYWRlcnMiIGlu IDxkcmFmdC1pZXRmLTZtYW4tcmZjMjQ2MGJpcy0wNC50eHQ+DQo+Pj4+IA0KPj4+PiBFeHRlbnNp b24gaGVhZGVycyBtdXN0IG5ldmVyIGJlIGluc2VydGVkIGJ5IGFueSBub2RlIG90aGVyIHRoYW4g dGhlDQo+Pj4+IHNvdXJjZSBvZiB0aGUgcGFja2V0LiAgSVAgRW5jYXBzdWxhdGlvbiBtdXN0IGJl IHVzZWQgdG8gbWVldCBhbnkNCj4+Pj4gcmVxdWlyZW1lbnQgZm9yIGluc2VydGluZyBoZWFkZXJz LCBmb3IgZXhhbXBsZSwgYXMgZGVmaW5lZCBpbg0KPj4+PiBbUkZDMjQ3M10uDQo+Pj4+IA0KPj4+ PiBUaGlzIHRleHQgd2FzIGFkZGVkIHRvIHRoZSBkcmFmdCBpbiB2ZXJzaW9uIOKAlDAxIHB1Ymxp c2hlZCBvbiAyIE5vdmVtYmVyIDIwMTUuDQo+Pj4+IA0KPj4+PiBUaGUgcXVlc3Rpb24gaXMgaWYg dGhpcyB0ZXh0IHdhcyB0aGUgb3JpZ2luYWwgaW50ZW50IG9mIHJmYzI0NjAuICBUaGF0IHdvdWxk IGFsbG93IGl0IHRvIGJlIHBhcnQgb2YgcmZjMjQ2MGJpcyBnb2luZyB0byBJbnRlcm5ldCBTdGFu ZGFyZC4gIElmIGl0IGlzIGEgY2hhbmdlLCB0aGVuIGl0IHNob3VsZCBub3QgYmUgaW5jbHVkZWQu DQo+Pj4+IA0KPj4+PiBJbiBteSBwZXJzb25hbCB2aWV3IChhcyBvbmUgb2YgdGhlIGF1dGhvcnMg b2YgcmZjMjQ2MCksIEkgdGhpbmsgaXQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQgdG8gbm90IGFs bG93IGV4dGVuc2lvbiBoZWFkZXJzIHRvIGJlIGluc2VydGVkLiAgTXkgdGhpbmtpbmcgaXMgdGhh dCBub3QgYWxsb3dpbmcgZXh0ZW5zaW9uIGhlYWRlcnMgdG8gYmUgaW5zZXJ0ZWQgaXMgcmVsYXRl ZCB0aGUgZGVzaWduIG9mIElQdjYgdGhhdCBpbmNsdWRlcyBvbmx5IHN1cHBvcnRpbmcgZnJhZ21l bnRhdGlvbiBhdCB0aGUgc291cmNlLiAgSVB2NCBhbGxvd3MgdGhlIGFkZGl0aW9uIG9mIG9wdGlv bnMgcmVzdWx0aW5nIGluIGNoYW5naW5nIHRoZSBoZWFkZXIgbGVuZ3RoLCBidXQgaXQgaW5jbHVk ZXMgcGVyLWhvcCBmcmFnbWVudGF0aW9uIHNvIGFueSByZXN1bHRpbmcgTVRVIGlzc3VlcyBjYW4g YmUgZGVhbHQgd2l0aC4gIEV2ZW4gSVB2NCBmcmFnbWVudHMgY2FuIGJlIGZyYWdtZW50ZWQuICBJ IHRoaW5rIGl0IGlzIGEgY29uc2VxdWVuY2Ugb2YgSVB2NiBub3QgYWxsb3cgcGVyLWhvcCBmcmFn bWVudGF0aW9uLCB0aGF0IGV4dGVuc2lvbiBoZWFkZXJzIHdlcmUgbm90IGludGVuZGVkIHRvIGJl IGluc2VydGVkIGFsb25nIHRoZSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbi4NCj4+PiANCj4+PiBJ IHRoaW5rIHRoaXMgZXhhY3RseSBjb3JyZWN0LiBJIGRpZCBhIGJpdCBvZiBhcmNoYWVvbG9neSBh bmQgZm91bmQgdGhlIG1lc3NhZ2UNCj4+PiB3aGVyZSBTdGV2ZSBEZWVyaW5nIHN1bW1hcmlzZWQg dGhlIGlzc3VlcyByZXNvbHZlZCBiZWZvcmUgUkZDIDE4ODMgKHRoZSBwcmVkZWNlc3Nvcg0KPj4+ IG9mIFJGQyAyNDYwKSB3YXMgcHVibGlzaGVkIGluIDE5OTUuIEkndmUgYXR0YWNoZWQgaXQgYmVs b3cgLSBsb29rIGp1c3QgYWZ0ZXINCj4+PiAicmVqZWN0ZWQgYXQgdGhlIFN0b2NraG9sbSBtZWV0 aW5nIiBpLmUuIElFVEYgMzMuIFRoZSBjb21tZW50IHRoYXQgdHJpZ2dlcmVkDQo+Pj4gaXQgd2Fz IGluIG1lc3NhZ2UgKElQbmcgMzQ2KSBmcm9tIENoYXJsaWUgTHlubiBzZW50IDMwIEp1bmUgMTk5 NS4NCj4+PiANCj4+PiBbSSBrbmV3IG15IG1haWwgYXJjaGl2ZXMgd291bGQgYmUgdXNlZnVsIG9u ZSBkYXkuXQ0KPj4gDQo+PiBTdHVubmluZyByZWNvbGxlY3Rpb24gcG93ZXJzIEJyaWFuIQ0KPj4g DQo+PiBUaGUgcGFyYWdyYXBoIHlvdSBwb2ludCB0bywgaS5lLjoNCj4+IA0KPj4gCSJyZWFzb25z IGZvciByZWplY3Rpb246IGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBlbi1yb3V0ZSBi cmVha3MNCj4+ICAgIAlQTVRVLWRpc2NvdmVyeSBhbmQgY2FuIHJlc3VsdCBpbiBJQ01QIGVycm9y IG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8NCj4+ICAgIAlub24tZ3VpbHR5IHBhcnRpZXMuICBUaGUg ZGVzaXJlZCBlZmZlY3QgY2FuIGJlIGFjaGlldmVkLCBhbmQgdGhvc2UNCj4+ICAgIAlwcm9ibGVt cyBhdm9pZGVkLCBieSB1c2luZyBlbi1yb3V0ZSBlbmNhcHN1bGF0aW9uICh3aXRoIG9wdGlvbmFs DQo+PiAgICAJUm91dGluZyBIZWFkZXIpIHJhdGhlciB0aGFuIGhlYWRlciBpbnNlcnRpb24u4oCd DQo+PiANCj4+IHN0aWxsIHNlZW1zIHZhbGlkIHRvIG1lLCBhbmQgdGh1cyBJIGFncmVlIHdpdGgg Qm9i4oCZcyBwcm9wb3NhbC4gV2hldGhlciB0aGUgYWJvdmUgcmF0aW9uYWxlIGlzIGFsc28gaW5j bHVkZWQgaXMgYW4gYWRkaXRpb25hbCBxdWVzdGlvbi4NCj4+IA0KPj4gRm9yIGV4YW1wbGUsIGlu IHNlY3Rpb24gMi4yIG9mZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGl0 IHN0YXRlczogIkF0IHRoZSBpbmdyZXNzIG5vZGUgb2YgYW4gU1IgZG9tYWluIHdoZXJlIHRoZSBp bmdyZXNzIG5vZGUgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRlcyBpdCBp bnRvIGFuIG91dGVyIElQdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGEgU2VnbWVudCBSb3V0aW5nIGhl YWRlci7igJ0NCj4gDQo+IA0KPiBDb3JyZWN0LiBUaGUgZGlzY3Vzc2lvbiB3ZeKAmXJlIGhhdmlu ZyBpcyBub3QgcmVsYXRlZCB0byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRl ciBidXQgcmF0aGVyIG9uIGEgdXNhZ2Ugb2YgdGhlIFNSSCB0aGF0IHRoZSBpbmR1c3RyeSBpcyBh ZG9wdGluZyBhbmQgdGhhdCBpbmNsdWRlcyBoZWFkZXIgaW5zZXJ0aW9uLiANCg0KQW5kIHVzYWdl IHRoYXQgaXMgbm90IGJlaW5nIHN0YW5kYXJkaXNlZCB3aXRoaW4gdGhlIElFVEYsIG9yIGlzIGl0 PyAgDQoNClRpbQ0KDQo+IHMuDQo+IA0KPiANCj4+IA0KPj4gVGltDQo+PiANCj4+PiAgQnJpYW4N Cj4+PiANCj4+Pj4gTm90ZSwgSSB0aGluayBpdCB3b3VsZCBiZSBmaW5lIGZvciBzb21lb25lIHRv IGRvY3VtZW50IGhvdyB0byBkbyBleHRlbnNpb24gaGVhZGVyIGluc2VydGlvbiwgYXMgbG9uZyBh cyB0aGV5IGRlc2NyaWJlIGhvdyBpdCB3b3JrcywgYW5kIGhvdyB0byBkZWFsIGlzc3VlcyBsaWtl IE1UVSBwcm9ibGVtcy4gIFRoaXMgY2FuIGJlIGJlIGFuIHVwZGF0ZSB0byByZmMyNDYwYmlzIChh ZnRlciBpdCBpcyBwdWJsaXNoZWQpLg0KPj4+PiANCj4+Pj4gSG93ZXZlciwgSSBkbyBub3QgdGhp bmsgbGVhdmluZyB0aGUgcmZjMjQ2MGJpcyB0ZXh0IGluIGFuIGFtYmlndW91cyBzdGF0ZSBvbiB0 aGlzIHRvcGljIGlzIGEgZ29vZCBpZGVhLg0KPj4+PiANCj4+Pj4gQ29tbWVudHM/DQo+Pj4+IA0K Pj4+PiBUaGFua3MsDQo+Pj4+IEJvYg0KPj4+IA0KPj4+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNz YWdlIC0tLS0tLS0tDQo+Pj4gU3ViamVjdDogKElQbmcgNjA5KSBjaGFuZ2VzIHRvIExhc3QgQ2Fs bCdlZCBzcGVjcw0KPj4+IERhdGU6IFN1biwgMjcgQXVnIDE5OTUgMjA6NTk6MjYgUERUDQo+Pj4g RnJvbTogU3RldmUgRGVlcmluZyA8ZGVlcmluZ0BwYXJjLnhlcm94LmNvbT4NCj4+PiBUbzogaXBu Z0BzdW5yb29mLmVuZy5zdW4uY29tDQo+Pj4gQ0M6IGRlZXJpbmdAcGFyYy54ZXJveC5jb20NCj4+ PiANCj4+PiBBdCB0aGUgcmVxdWVzdCBvZiBvdXIgQURzLCBJIHByZXBhcmVkIHRoZSBmb2xsb3dp bmcgbGlzdCBvZiBhZ3JlZWQtdXBvbg0KPj4+IGNoYW5nZXMgYW5kIG91dHN0YW5kaW5nIGlzc3Vl cyB3aXRoIHRoZSBzZXQgb2Ygc3BlY3MgdGhhdCB1bmRlcndlbnQNCj4+PiBJRVRGLXdpZGUgTGFz dCBDYWxsIGluIEp1bmUgYW5kIEp1bHkuICBQbGVhc2UgbGV0IG1lIGtub3cgb2YgYW55IGVycm9y cw0KPj4+IG9yIG9taXNzaW9ucy4NCj4+PiANCj4+PiBTdGV2ZQ0KPj4+IA0KPj4+ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4gDQo+Pj4gSVB2NiBTcGVjaWZpY2F0aW9u DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gDQo+Pj4gVGhlIGZvbGxvd2luZyBjaGFuZ2Vz IHdlcmUgcG9zdGVkIHRvIHRoZSBJRVRGIGxpc3QgaW1tZWRpYXRlbHkgZm9sbG93aW5nDQo+Pj4g dGhlIExhc3QgQ2FsbCwgc28gSSB0aGluayB3ZSBjYW4gY29uc2lkZXIgdGhlbSB0byBhbHNvIGhh dmUgYmVlbiBMYXN0IENhbGxlZDoNCj4+PiANCj4+PiAtIEluIHRoZSBleGFtcGxlcyBvZiBob3cg dG8gbGF5IG91dCBvcHRpb25zLCBvbiBwYWdlIDI5LCB0d28gcGxhY2VzDQo+Pj4gIHdoZXJlIGl0 IHNheXMgIkhkciBFeHQgTGVuPTEiIHNob3VsZCBiZSAiSGRyIEV4dCBMZW49MyINCj4+PiAgKHJl cG9ydGVkIGJ5IEhhbWlkIEFzYXllc2gpLg0KPj4+IA0KPj4+IC0gSW4gc2VjdGlvbiA2LCBGbG93 IExhYmVscywgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgUHJpb3JpdHkgZmllbGQNCj4+PiAgaW4g dGhlIGxpc3Qgb2YgZmllbGRzIHRoYXQgbXVzdCBoYXZlIHRoZSBzYW1lIHZhbHVlIGZvciBhbGwN Cj4+PiAgcGFja2V0cyBpbiB0aGUgc2FtZSBmbG93IChyZXBvcnRlZCBieSBNYXJrdXMgSm9yayku DQo+Pj4gDQo+Pj4gLSBUaGUgZGVzY3JpcHRpb24gb2Ygd2hhdCB0aGUgSnVtYm8gUGF5bG9hZCBM ZW5ndGggZmllbGQgY292ZXJzDQo+Pj4gIHNob3VsZCBiZSBtYWRlIGNsZWFyZXIgKHJlcG9ydGVk IGJ5IENocmlzdGlhbiBIdWl0ZW1hKS4NCj4+PiANCj4+PiBUaGUgZm9sbG93aW5nIGNoYW5nZXMg d2VyZSBwcm9wb3NlZCBieSBDaGFybGllIEx5bm4gaW4gdGhlIG9ubHkgImZvcm1hbCINCj4+PiBy ZXNwb25zZSB0byB0aGUgTGFzdCBDYWxsLCBhbmQgYWNjZXB0ZWQgYXQgdGhlIGZpcnN0IGlwbmd3 ZyBtZWV0aW5nIGluDQo+Pj4gU3RvY2tob2xtOg0KPj4+IA0KPj4+IC0gRm9yIG9wdGlvbnMgY29u dGFpbmluZyBkYXRhIHRoYXQgY2FuIGNoYW5nZSBlbi1yb3V0ZSAoYW5kIHdoaWNoIHRoZXJlZm9y ZQ0KPj4+ICBoYXZlIHRoZSB0aGlyZC1oaWdoZXN0LW9yZGVyIGJpdCBvZiB0aGVpciBPcHRpb24g VHlwZSBzZXQgdG8gMSksIG1ha2UgaXQNCj4+PiAgY2xlYXIgdGhhdCAqYWxsKiBieXRlcyBvZiB0 aGUgT3B0aW9uIERhdGEgZmllbGQgYXJlIHRvIGJlIGV4Y2x1ZGVkIGZyb20NCj4+PiAgdGhlIEF1 dGhlbnRpY2F0aW9uIGZ1bmN0aW9uLCBhbmQgZXhwbGFpbiB0aGF0ICJleGNsdWRlZCIgbWVhbnMg InRyZWF0ZWQNCj4+PiAgYXMgaWYgdGhleSB3ZXJlIGFsbCB6ZXJvLXZhbHVlZCBieXRlcyIuDQo+ Pj4gDQo+Pj4gLSBDaGFuZ2UgdGhlIFJvdXRpbmcgSGVhZGVyIHRvIGVuYWJsZSBpdCB0byBiZSBp Z25vcmVkIGJ5IGZpbmFsIGRlc3RpbmF0aW9ucw0KPj4+ICB0aGF0IGRvIG5vdCB1bmRlcnN0YW5k IHRoZSBSb3V0aW5nIFR5cGUuICBJbiBTdG9ja2hvbG0sIERlZXJpbmcgcHJvcG9zZWQsDQo+Pj4g IGFuZCB0aGUgYXR0ZW5kZWVzIGFncmVlZCB3aXRoLCB0aGUgZm9sbG93aW5nIHJldmlzZWQgZm9y bWF0IGZvciB0aGUNCj4+PiAgZmlyc3QgMzIgYml0cyBvZiB0aGUgUm91dGluZyBIZWFkZXIsIGZv ciBhbGwgUm91dGluZyBUeXBlczoNCj4+PiANCj4+PiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+Pj4gICB8ICBOZXh0 IEhlYWRlciAgfCAgSGRyIEV4dCBMZW4gIHwgIFJvdXRpbmcgVHlwZSB8IFNlZ21lbnRzIExlZnQg fA0KPj4+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4+PiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4gDQo+Pj4gIHdoZXJlDQo+Pj4g DQo+Pj4gCUhkciBFeHQgTGVuICAgaXMgdGhlIGxlbmd0aCBvZiB0aGUgaGVhZGVyIGluIDgtb2N0 ZXQgdW5pdHMsIG5vdA0KPj4+IAkgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgZmlyc3QgOCBv Y3RldHMNCj4+PiANCj4+PiAJU2VnbWVudHMgTGVmdCBpcyB0aGUgbnVtYmVyIG9mICJsZWdzIiBs ZWZ0IHRvIHRyYXZlcnNlIGluIHRoZQ0KPj4+ICAgICAgICAgICAgICAgICAgICByb3V0ZTsgaWYg dGhpcyB2YWx1ZSBpcyB6ZXJvLCB0aGUgcmVjZWl2ZXIgbWF5DQo+Pj4gCSAgICAgICAgICAgICAg aWdub3JlIHRoaXMgaGVhZGVyIChpLmUuLCBpdCBpbmRpY2F0ZXMgdGhhdCB0aGUNCj4+PiAJICAg ICAgICAgICAgICByb3V0ZSBoYXMgYmVlbiBjb21wbGV0ZWQpLCB3aGV0aGVyIG9yIG5vdCB0aGUN Cj4+PiAJICAgICAgICAgICAgICByZWNlaXZlciB1bmRlcnN0YW5kcyB0aGUgUm91dGluZyBUeXBl DQo+Pj4gDQo+Pj4gVGhlIGZvbGxvd2luZyBhZGRpdGlvbmFsIGNoYW5nZXMgd2VyZSBhZ3JlZWQg dG8gZWl0aGVyIG9uIHRoZSBtYWlsaW5nIGxpc3QNCj4+PiBvciBpbiB0aGUgU3RvY2tob2xtIG1l ZXRpbmdzOg0KPj4+IA0KPj4+IC0gIkltcHJvdmUiIHRoZSBob3N0L3JvdXRlciB0ZXJtaW5vbG9n eS4gIFdoYXQgSSBwcm9wb3NlIHRvIGRvIGlzIGFkZCBhDQo+Pj4gIGZvb3Rub3RlIHRvIHRoZSB0 ZXJtaW5vbG9neSBzZWN0aW9uIHNheWluZyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPj4+IA0KPj4+ IAkqIGl0IGlzIHBvc3NpYmxlLCB0aG91Z2ggdW51c3VhbCwgdG8gaGF2ZSBhIGRldmljZSB3aXRo IG11bHRpcGxlDQo+Pj4gICAgICAgIGludGVyZmFjZXMgY29uZmlndXJlZCB0byBmb3J3YXJkIG5v bi1zZWxmLWRlc3RpbmVkIHBhY2tldHMNCj4+PiAgICAgICAgYXJyaXZpbmcgZnJvbSBzb21lIHNl dCAoZmV3ZXIgdGhhbiBhbGwpIG9mIGl0cyBpbnRlcmZhY2VzLCBhbmQNCj4+PiAJICB0byBkaXNj YXJkIG5vbi1zZWxmLWRlc3RpbmVkIHBhY2tldHMgYXJyaXZpbmcgZnJvbSBpdHMgb3RoZXINCj4+ PiAJICBpbnRlcmZhY2VzLiAgU3VjaCBhIGRldmljZSBtdXN0IG9iZXkgdGhlIHByb3RvY29sIHJl cXVpcmVtZW50cw0KPj4+IAkgIGZvciByb3V0ZXJzIHdoZW4gcmVjZWl2aW5nIHBhY2tldHMgZnJv bSwgYW5kIGludGVyYWN0aW5nIHdpdGgNCj4+PiAJICBuZWlnaGJvcnMgb3ZlciwgdGhlIGZvcm1l ciAoZm9yd2FyZGluZykgaW50ZXJmYWNlcy4gIEl0IG11c3QNCj4+PiAJICBvYmV5IHRoZSBwcm90 b2NvbCByZXF1aXJlbWVudHMgZm9yIGhvc3RzIHdoZW4gcmVjZWl2aW5nIHBhY2tldHMNCj4+PiAJ ICBmcm9tLCBhbmQgaW50ZXJhY3Rpbmcgd2l0aCBuZWlnaGJvcnMgb3ZlciwgdGhlIGxhdHRlciAo bm9uLQ0KPj4+IAkgIGZvcndhcmRpbmcpIGludGVyZmFjZXMuDQo+Pj4gDQo+Pj4gIENvbW1lbnRz Pw0KPj4+IA0KPj4+IC0gQ2xhcmlmeSB0aGUgb3BlcmF0aW9uIG9mIFR5cGUgMCBSb3V0aW5nIEhl YWRlciBieSBnaXZpbmcgYW4gZXhhbXBsZSwNCj4+PiAgc2hvd2luZyB0aGUgdmFsdWVzIG9mIHRo ZSBoZWFkZXIgZmllbGRzIG9uIGVhY2ggc2VnbWVudCBvZiB0aGUgcm91dGUuDQo+Pj4gDQo+Pj4g LSBDbGFyaWZ5IHRoZSBoYW5kbGluZyBvZiBvcHRpb25zLCBleHRlbnNpb24gaGVhZGVycywgTmV4 dCBIZWFkZXIgZmllbGRzLA0KPj4+ICBldGMuIGZvciBmcmFnbWVudGVkIHBhY2tldHMgYnkgZ2l2 aW5nIGEgZmV3IGV4YW1wbGVzIG9mIHBhY2tldHMgYmVmb3JlDQo+Pj4gIGFuZCBhZnRlciBmcmFn bWVudGF0aW9uIChzdWdnZXN0ZWQgYnkgRGltaXRyeSBIYXNraW5zIGFuZCBvdGhlcnMpLg0KPj4+ IA0KPj4+IC0gU3BlY2lmeSB0aGF0IGZyYWdtZW50cyBjYW5ub3QgcmVhc3NlbWJsZSB0byBmb3Jt IGEganVtYm9ncmFtIChzdWdnZXN0ZWQNCj4+PiAgYnkgQ3JhaWcgTWV0eikuDQo+Pj4gDQo+Pj4g DQo+Pj4gSUNNUHY2IFNwZWNpZmljYXRpb24NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ IA0KPj4+IC0gQWRkIG5vdGUgd2FybmluZyBhYm91dCB0aGUgcG9zc2liaWxpdHkgb2YgdXBwZXIt bGF5ZXIgaGVhZGVyIGJlaW5nDQo+Pj4gIHRydW5jYXRlZCBmcm9tIHRoZSByZXR1cm5lZCBwYWNr ZXQgaW4gYW4gZXJyb3IgbWVzc2FnZSwgZHVlIHRvIGxhcmdlDQo+Pj4gIG51bWJlciBvZiBleHRl bnNpb24gaGVhZGVyIGJ5dGVzLCB3aGljaCBjYW4gZGVmZWF0IGRlbGl2ZXJ5IG9mIHRoZQ0KPj4+ ICBlcnJvciBtZXNzYWdlIHRvIHRoZSBndWlsdHkgdXBwZXItbGF5ZXIgcHJvdG9jb2wgaW5zdGFu Y2UuDQo+Pj4gDQo+Pj4gLSBEZWxldGUgZGVzY3JpcHRpb24gb2YgcHNldWRvLWhlYWRlciwgcmVw bGFjaW5nIGl0IHdpdGggYSByZWZlcmVuY2UgdG8NCj4+PiAgdGhlIGRlc2NyaXB0aW9uIGluIHRo ZSBJUHY2IHNwZWMgKHN1Z2dlc3RlZCBieSBBbGlzdGFpciBCZWxsIGFuZA0KPj4+ICBNYXJjIEhh c3NvbikuDQo+Pj4gDQo+Pj4gLSBDb3JyZWN0IGV4YW1wbGUgb2YgdXNhZ2Ugb2YgdGhlIHBvaW50 ZXIgaW4gdGhlIFBhcmFtZXRlciBQcm9ibGVtDQo+Pj4gIG1lc3NhZ2Ugb24gcGFnZSAxNSwgYnkg Y2hhbmdpbmcgIjQ4IiB0byAiNDAiIChyZXBvcnRlZCBieSBEaW1pdHJ5DQo+Pj4gIEhhc2tpbnMg YW5kIEZyYW5jaXMgRHVwb250KS4NCj4+PiANCj4+PiAtIE5vdGUgdGhhdCB0aGVyZSBpcyBhbm90 aGVyIGV4Y2VwdGlvbiB0byB0aGUgIm5vIElDTVAgZXJyb3IgbWVzc2FnZXMNCj4+PiAgaW4gcmVz cG9uc2UgdG8gbXVsdGljYXN0cyIgcnVsZSwgd2hpY2ggaXMgInVucmVjb2duaXplZCBvcHRpb24i DQo+Pj4gIFBhcmFtZXRlciBQcm9ibGVtIG1lc3NhZ2VzIGluIHJlc3BvbnNlIHRvIG9wdGlvbnMg d2l0aCBoaWdoLW9yZGVyDQo+Pj4gIGJpdHMgIjEwLi4uIiAocmVwb3J0ZWQgYnkgRGltaXR5IEhh c2tpbnMpLg0KPj4+IA0KPj4+IEFkZHJlc3MgQXJjaGl0ZWN0dXJlIERvY3VtZW50DQo+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+PiAtIEFkZCBkZWZpbml0aW9uIG9m ICJsaW5rLWxvY2FsIGFkZHJlc3MiIHRvIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uDQo+Pj4gIChz dWdnZXN0ZWQgYnkgSmltIEJvdW5kKS4NCj4+PiANCj4+PiAtIFNwZWNpZnkgdGhhdCAiOjoiIGlz IGEgbGVnYWwgdGV4dCByZXByZXNlbnRhdGlvbiBvZiB0aGUgVW5zcGVjaWZpZWQNCj4+PiAgKGFs bC16ZXJvcykgQWRkcmVzcyAoc3VnZ2VzdGVkIGJ5IEZyYW5jaXMgRHVwb250KS4NCj4+PiANCj4+ PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+IA0KPj4+IFRoZSBmb2xs b3dpbmcgc3VnZ2VzdGlvbnMgaW4gQ2hhcmxpZSBMeW5uJ3MgZm9ybWFsIHJlc3BvbnNlIHRvIHRo ZSBMYXN0IENhbGwNCj4+PiB3ZXJlIHJlamVjdGVkIGF0IHRoZSBTdG9ja2hvbG0gbWVldGluZzoN Cj4+PiANCj4+PiAtIEFkZCBhIGJpdCB0byB0aGUgUm91dGluZyBIZWFkZXIgaW5kaWNhdGluZyB3 aGV0aGVyIG9yIG5vdCBpdCB3YXMNCj4+PiAgaW5zZXJ0ZWQgaW50byB0aGUgcGFja2V0IGVuLXJv dXRlLCBpLmUuLCBieSBhIG5vZGUgb3RoZXIgdGhhbiB0aGUNCj4+PiAgcGFja2V0J3Mgb3JpZ2lu YXRvci4NCj4+PiANCj4+PiAgICByZWFzb25zIGZvciByZWplY3Rpb246IGluc2VydGlvbiBvZiBl eHRlbnNpb24gaGVhZGVycyBlbi1yb3V0ZSBicmVha3MNCj4+PiAgICBQTVRVLWRpc2NvdmVyeSBh bmQgY2FuIHJlc3VsdCBpbiBJQ01QIGVycm9yIG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8NCj4+PiAg ICBub24tZ3VpbHR5IHBhcnRpZXMuICBUaGUgZGVzaXJlZCBlZmZlY3QgY2FuIGJlIGFjaGlldmVk LCBhbmQgdGhvc2UNCj4+PiAgICBwcm9ibGVtcyBhdm9pZGVkLCBieSB1c2luZyBlbi1yb3V0ZSBl bmNhcHN1bGF0aW9uICh3aXRoIG9wdGlvbmFsDQo+Pj4gICAgUm91dGluZyBIZWFkZXIpIHJhdGhl ciB0aGFuIGhlYWRlciBpbnNlcnRpb24uDQo+Pj4gDQo+Pj4gLSBDaGFuZ2UgSUNNUCBlcnJvciBt ZXNzYWdlcyB0byBjb250YWluIGV4cGxpY2l0IGZpZWxkcyBpZGVudGlmeWluZyB0aGUNCj4+PiAg dXBwZXItbGF5ZXIgcHJvdG9jb2wgdG8gd2hpY2ggdGhlIGVycm9yIG1lc3NhZ2Ugc2hvdWxkIGJl IGRlbGl2ZXJlZC4NCj4+PiANCj4+PiAgICByZWFzb25zIGZvciByZWplY3Rpb246IGNvbnNpZGVy ZWQgdW5uZWNlc3NhcnkgY29tcGxleGl0eSB0byBoYW5kbGUgdGhlDQo+Pj4gICAgcmFyZSBjYXNl IG9mIHRydW5jYXRpb24gb2YgdHJhbnNwb3J0IGhlYWRlciBmcm9tIHRoZSByZXR1cm5lZCBwYWNr ZXQNCj4+PiAgICBiZWNhdXNlIG9mIHRvbyBtYW55IGV4dGVuc2lvbiBoZWFkZXIgb2N0ZXRzLiAg U3VjaCBlcnJvciBtZXNzYWdlcyBhcmUNCj4+PiAgICBzdGlsbCB1c2FibGUgZm9yIHByb2JsZW0g ZGlhZ25vc2lzIG90aGVyIHRoYW4gaW4gdGhlIHVwcGVyLWxheWVyDQo+Pj4gICAgaXRzZWxmLCBl LmcuLCBpZiBsb2dnZWQgYXQgSVB2NiBsYXllciBvciBvYnNlcnZlZCBpbiBhIHBhY2tldCB0cmFj ZS4NCj4+PiAgICBXaWxsIGFkZCB3YXJuaW5nIHRvIHRoZSBJQ01QdjYgc3BlYyBhYm91dCBjb25z ZXF1ZW5jZXMgb2YgbG9uZw0KPj4+ICAgIGV4dGVuc2lvbiBoZWFkZXIgb24gSUNNUCBlcnJvciBt ZXNzYWdlIGRpc3BhdGNoaW5nLg0KPj4+IA0KPj4+IC0gQ2hhbmdlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gb2YgSUNNUHY2IHNwZWMgdG8gc3BlY2lmeSB3aGVuDQo+Pj4gIGFuZCBo b3cgdG8gaW5jbHVkZSBhbiBBdXRoZW50aWNhdGlvbiBIZWFkZXIgaW4gSUNNUCBlcnJvciBtZXNz YWdlcy4NCj4+PiANCj4+PiAgICByZWFzb25zIGZvciByZWplY3Rpb246IGdyb3VwIGNvbnNlbnN1 cyB0aGF0IHRoaXMgYmVsb25ncyBpbiBhYQ0KPj4+ICAgIElQc2VjIHNwZWMgaW5zdGVhZC4NCj4+ PiANCj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+IA0KPj4+IFRo ZSBmb2xsb3dpbmcgaXNzdWVzIGFuZCBzdWdnZXN0aW9ucyBoYXZlIGJlZW4gZGlzY3Vzc2VkIG9u IHRoZSBtYWlsaW5nIGxpc3QNCj4+PiBzaW5jZSB0aGUgYmFzZSBzcGVjcyB3ZW50IHRvIExhc3Qg Q2FsbCwgYnV0IG5vIGdyb3VwIGNvbnNlbnN1cyBvbiB0aGVzZSBpc3N1ZXMNCj4+PiBoYXMgYmVl biByZWFjaGVkIHlldDoNCj4+PiANCj4+PiAtIEZyYWdtZW50YXRpb24gaXNzdWVzOg0KPj4+IAkt IGNoYW5nZSB0aGUgbWluaW11bSByZWFzc2VtYmx5IGJ1ZmZlciBzaXplIHRvIGEgbnVtYmVyIGxh cmdlcg0KPj4+IAkgIHRoYW4gNTc2Pw0KPj4+IAktIHNwZWNpZnkgdGhhdCBzb3VyY2VzIG9mIGZy YWdtZW50ZWQgcGFja2V0cyBtdXN0IHVzZSB0aGUgbWluaW1hbA0KPj4+IAkgIG51bWJlciBvZiBm cmFnbWVudHMgcmVxdWlyZWQgdG8gZml0IGluIHRoZSBwZXJjZWl2ZWQgUE1UVT8NCj4+PiAJLSBz cGVjaWZ5IHRoYXQgYWxsIGZyYWdtZW50cyB3aXRoIHRoZSBNIGJpdCBzZXQgbXVzdCBiZSBubyBs ZXNzDQo+Pj4gCSAgdGhhbiA3IG9jdGV0cyBzaG9ydGVyIHRoYW4gdGhlIHBlcmNlaXZlZCBQTVRV Pw0KPj4+IAktIHNwZWNpZnkgdGhhdCBhbGwgZnJhZ21lbnRzIHdpdGggdGhlIE0gYml0IHNldCBt dXN0IGJlIG5vIHNob3J0ZXINCj4+PiAJICB0aGFuIDU3NiBvY3RldHM/DQo+Pj4gCS0gaWdub3Jl IGZyYWdtZW50cyB0aGF0IHBhcnRpYWxseSBvdmVybGFwIG90aGVyIGZyYWdtZW50cyBvZiB0aGUN Cj4+PiAJICBzYW1lIHBhY2tldCwgb3IgZGlzY2FyZCBhbnkgcGFja2V0IHRoYXQgYXJyaXZlcyBh cyBwYXJ0aWFsbHkNCj4+PiAJICBvdmVybGFwcGluZyBmcmFnbWVudHM/DQo+Pj4gDQo+Pj4gLSBS b3V0aW5nIEhlYWRlciBpc3N1ZXM6DQo+Pj4gCS0gYWRkIGEgIlRvdGFsIExlbmd0aCIgZmllbGQg dG8gdGhlIGZyYWdtZW50IGhlYWRlciwgY2FycnlpbmcgdGhlDQo+Pj4gCSAgbGVuZ3RoIG9mIHRo ZSBvcmlnaW5hbCwgdW5mcmFnbWVudGVkIHBhY2tldD8NCj4+PiAJLSBmb3JiaWQgZm9yd2FyZGlu ZyBvZiBwYWNrZXRzIHdpdGggUm91dGluZyBIZWFkZXJzIGJ5IGhvc3RzPw0KPj4+IAkgIChpZiBu b3QsIG1ha2UgaXQgY2xlYXJlciB0aGF0IGhvc3RzIGFyZSBleHBlY3RlZCB0byBmb3J3YXJkDQo+ Pj4gCSAgcGFja2V0cyB3aXRoIFJvdXRpbmcgSGVhZGVycywgaWYgdGhleSBhcmUgaW50ZXJtZWRp YXRlIHRhcmdldHMNCj4+PiAJICBvZiBzdWNoIHBhY2tldHMuKQ0KPj4+IAktIHNwZWNpZnkgdGhl IHJldmVyc2luZyBydWxlcyBmb3IgcGFja2V0cyB0aGF0IGFyZSByZXNwb25zZXMgdG8NCj4+PiAJ ICBwYWNrZXRzIHRoYXQgY2FycnkgYSBSb3V0aW5nIEhlYWRlcj8NCj4+PiAJLSBmb3JiaWQgb3Ig ZGlzY291cmFnZSByZXZlcnNhbCBvZiBhbiB1bmF1dGhlbnRpY2F0ZWQgUm91dGluZyBIZWFkZXI/ DQo+Pj4gCS0gZm9yYmlkIG9yIGRpc2NvdXJhZ2UgYWNjZXB0YW5jZSBvZiBhIHBhY2tldCB3aXRo IGFuIHVuYXV0aGVudGljYXRlZA0KPj4+IAkgIFJvdXRpbmcgSGVhZGVyPw0KPj4+IA0KPj4+IC0g QWxsb3cgdGhlIHRyYW5zcG9ydC1sYXllciBjaGVja3N1bSB0byBiZSBvbWl0dGVkIHdoZW4gdGhl IEF1dGhlbnRpY2F0aW9uDQo+Pj4gIGhlYWRlciAob3IgdGhlIEVTUCBoZWFkZXI/KSBpcyBiZWlu ZyB1c2VkPw0KPj4+IA0KPj4+IC0gQWRkIGEgQ29uZ2VzdGlvbiBJbmRpY2F0aW9uIGJpdCB0byB0 aGUgYmFzZSBJUHY2IGhlYWRlcj8NCj4+PiANCj4+PiAtIEFkZCBNVVNUL1NIT1VMRC9NQVkgY29u Zm9ybWFuY2UgcmVxdWlyZW1lbnRzIGZvciBhbGwgSVB2NiBmaWVsZHMgYW5kDQo+Pj4gIGZ1bmN0 aW9ucz8NCj4+PiANCj4+PiAtIEJ1aWxkIGEgc2luZ2xlIFRlcm1pbm9sb2d5IGRvY3VtZW50LCB0 byBiZSBzaGFyZWQgKGVpdGhlciBieSByZWZlcmVuY2UNCj4+PiAgb3IgaW5jbHVzaW9uKSBpbiBh bGwgSVB2Ni1yZWxhdGVkIHNwZWNzPw0KPj4+IA0KPj4+IC0gQWxsb3cgdGhlIHVzZSBvZiB6ZXJv IGluIHRoZSBVRFAgTGVuZ3RoIGZpZWxkIHRvIGluZGljYXRlIHRoYXQgdGhlIFVEUA0KPj4+ICBs ZW5ndGggc2hvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgSnVtYm9ncmFtIE9wdGlvbj8NCj4+PiAN Cj4+PiBOb3RlOiB0aGUgYWJvdmUgbGlzdCBkb2VzIG5vdCBpbmNsdWRlIGlzc3VlcyBjb25jZXJu aW5nIHRob3NlIHNwZWNzIHRoYXQNCj4+PiBoYXZlIG5vdCB5ZXQgYmVlbiBzdWJqZWN0ZWQgdG8g V0cgb3IgSUVURiBMYXN0IENhbGwsIGUuZy4sIHRoZSBOZWlnaGJvcg0KPj4+IERpc2NvdmVyeSBz cGVjLg0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IElFVEYgSVBuZyBNYWls aW5nIExpc3QJCSAgICAgIEZUUCBhcmNoaXZlOiBmdHAucGFyYy54ZXJveC5jb206L3B1Yi9pcG5n DQo+Pj4gSVBuZyBIb21lIFBhZ2U6ICAgICAgICAgIGh0dHA6Ly9wbGF5Z3JvdW5kLnN1bi5jb20v cHViL2lwbmcvaHRtbC9pcG5nLW1haW4uaHRtbA0KPj4+IERpcmVjdCBhbGwgYWRtaW5pc3RyYXRp dmUgcmVxdWVzdHMgdG8gbWFqb3Jkb21vQHN1bnJvb2YuZW5nLnN1bi5jb20NCj4+PiANCj4+PiAN Cj4+PiANCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KPj4+IGlwdjZAaWV0Zi5vcmcNCj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxp bmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQoNCg== From nobody Thu Apr 28 09:04:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893CF12D893 for ; Thu, 28 Apr 2016 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 QQt7BLXPCe2r for ; Thu, 28 Apr 2016 09:04:40 -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 E135012D5B8 for ; Thu, 28 Apr 2016 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20782; q=dns/txt; s=iport; t=1461859035; x=1463068635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y5/bH9TFyvqsexzMySK/chMdUYU31kKeUH48Gj0kLpM=; b=XVbfTcNvm+7QmPB0uKMXif2ysulrLULCk5cAX3fN/BGe+Z02azGUf7V0 rLvVUDKSfZKCI6ExV612cnqN/dK7z2cUJrGAuK0R6eJBa+gw9I/KyInbK vRyQFz8Q6J4wccSLr3Kq9etPEWvPlW6kMTJQYwhz1DOAogzAzFAdDDG4u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgCXMiJX/4sNJK1YBg6DKlN9Bq4Si?= =?us-ascii?q?14BDYF2FwuFbQIcgQs4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgQAQE?= =?us-ascii?q?CAQIBAgImAgICHwYLFQIGCAIEDgWIFQMKCA6yK4xIDYRLAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFXyFJYF1glaCQYFuDgcQI4JGK4IrBYd0CocIiFkxAYV7gneDLoF?= =?us-ascii?q?2gWdOg3+IXYYkgS2HXgEeAQFCggIDG4EQO2wBhmh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="266608861" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 15:57:01 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3SFv1HK032371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 15:57:01 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.1104.5; Thu, 28 Apr 2016 11:57:00 -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.1104.009; Thu, 28 Apr 2016 11:57:00 -0400 From: "Stefano Previdi (sprevidi)" To: Tim Chown Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoP3VlQq8Gt0oREW1V7Q/DtgVAJ+fD1OAgABkpwCAABTegIAARWoA Date: Thu, 28 Apr 2016 15:57:00 +0000 Message-ID: <2F3D6328-4C5C-489C-8E27-E7B1E05AFCBE@cisco.com> References: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> <95B92AF8-CA66-4380-8F38-480A896C1B6B@cisco.com> <4EE1E34F-67DD-4F09-98A4-64B19ACCF3E2@jisc.ac.uk> In-Reply-To: <4EE1E34F-67DD-4F09-98A4-64B19ACCF3E2@jisc.ac.uk> 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.238.46] Content-Type: text/plain; charset="utf-8" Content-ID: <6D17F171F0B90A4189604D603D3BCBB4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:04:46 -0000 DQo+IE9uIEFwciAyOCwgMjAxNiwgYXQgNTo0OCBQTSwgVGltIENob3duIDxUaW0uQ2hvd25Aamlz Yy5hYy51az4gd3JvdGU6DQo+IA0KPj4gT24gMjggQXByIDIwMTYsIGF0IDE1OjMzLCBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKSA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4+ IE9uIEFwciAyOCwgMjAxNiwgYXQgMTA6MzMgQU0sIFRpbSBDaG93biA8VGltLkNob3duQGppc2Mu YWMudWs+IHdyb3RlOg0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+PiBPbiAyOCBBcHIgMjAxNiwg YXQgMDQ6MjYsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ IHdyb3RlOg0KPj4+PiANCj4+Pj4gT24gMjgvMDQvMjAxNiAxMzoxOCwgQm9iIEhpbmRlbiB3cm90 ZToNCj4+Pj4+IEhpLA0KPj4+Pj4gDQo+Pj4+PiBJIHdvdWxkIGxpa2UgdG8gZ2V0IGNsb3N1cmUg b24gdGhlIHF1ZXN0aW9uIGlmIGluc2VydGluZyBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGlzIGFs bG93ZWQgb3Igbm90LCBhbmQgc2hvdWxkIHRoaXMgYmUgYSBjbGFyaWZpY2F0aW9uIGluIHJmYzI0 NjBiaXMuICBUaGlzIHRvcGljIHdhcyBkaXNjdXNzZWQgaW4gQnVlbm9zIEFpcmVzIGFuZCBvbiB0 aGUgbWFpbGluZyBsaXN0Lg0KPj4+Pj4gDQo+Pj4+PiBUaGUgcmVsZXZhbnQgdGV4dCBmcm9tIFNl Y3Rpb24gNCAiSVB2NiBFeHRlbnNpb24gSGVhZGVycyIgaW4gPGRyYWZ0LWlldGYtNm1hbi1yZmMy NDYwYmlzLTA0LnR4dD4NCj4+Pj4+IA0KPj4+Pj4gRXh0ZW5zaW9uIGhlYWRlcnMgbXVzdCBuZXZl ciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZSBvdGhlciB0aGFuIHRoZQ0KPj4+Pj4gc291cmNlIG9m IHRoZSBwYWNrZXQuICBJUCBFbmNhcHN1bGF0aW9uIG11c3QgYmUgdXNlZCB0byBtZWV0IGFueQ0K Pj4+Pj4gcmVxdWlyZW1lbnQgZm9yIGluc2VydGluZyBoZWFkZXJzLCBmb3IgZXhhbXBsZSwgYXMg ZGVmaW5lZCBpbg0KPj4+Pj4gW1JGQzI0NzNdLg0KPj4+Pj4gDQo+Pj4+PiBUaGlzIHRleHQgd2Fz IGFkZGVkIHRvIHRoZSBkcmFmdCBpbiB2ZXJzaW9uIOKAlDAxIHB1Ymxpc2hlZCBvbiAyIE5vdmVt YmVyIDIwMTUuDQo+Pj4+PiANCj4+Pj4+IFRoZSBxdWVzdGlvbiBpcyBpZiB0aGlzIHRleHQgd2Fz IHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgcmZjMjQ2MC4gIFRoYXQgd291bGQgYWxsb3cgaXQgdG8g YmUgcGFydCBvZiByZmMyNDYwYmlzIGdvaW5nIHRvIEludGVybmV0IFN0YW5kYXJkLiAgSWYgaXQg aXMgYSBjaGFuZ2UsIHRoZW4gaXQgc2hvdWxkIG5vdCBiZSBpbmNsdWRlZC4NCj4+Pj4+IA0KPj4+ Pj4gSW4gbXkgcGVyc29uYWwgdmlldyAoYXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHJmYzI0NjAp LCBJIHRoaW5rIGl0IHdhcyB0aGUgb3JpZ2luYWwgaW50ZW50IHRvIG5vdCBhbGxvdyBleHRlbnNp b24gaGVhZGVycyB0byBiZSBpbnNlcnRlZC4gIE15IHRoaW5raW5nIGlzIHRoYXQgbm90IGFsbG93 aW5nIGV4dGVuc2lvbiBoZWFkZXJzIHRvIGJlIGluc2VydGVkIGlzIHJlbGF0ZWQgdGhlIGRlc2ln biBvZiBJUHY2IHRoYXQgaW5jbHVkZXMgb25seSBzdXBwb3J0aW5nIGZyYWdtZW50YXRpb24gYXQg dGhlIHNvdXJjZS4gIElQdjQgYWxsb3dzIHRoZSBhZGRpdGlvbiBvZiBvcHRpb25zIHJlc3VsdGlu ZyBpbiBjaGFuZ2luZyB0aGUgaGVhZGVyIGxlbmd0aCwgYnV0IGl0IGluY2x1ZGVzIHBlci1ob3Ag ZnJhZ21lbnRhdGlvbiBzbyBhbnkgcmVzdWx0aW5nIE1UVSBpc3N1ZXMgY2FuIGJlIGRlYWx0IHdp dGguICBFdmVuIElQdjQgZnJhZ21lbnRzIGNhbiBiZSBmcmFnbWVudGVkLiAgSSB0aGluayBpdCBp cyBhIGNvbnNlcXVlbmNlIG9mIElQdjYgbm90IGFsbG93IHBlci1ob3AgZnJhZ21lbnRhdGlvbiwg dGhhdCBleHRlbnNpb24gaGVhZGVycyB3ZXJlIG5vdCBpbnRlbmRlZCB0byBiZSBpbnNlcnRlZCBh bG9uZyB0aGUgcGF0aCB0byB0aGUgZGVzdGluYXRpb24uDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIHRo aXMgZXhhY3RseSBjb3JyZWN0LiBJIGRpZCBhIGJpdCBvZiBhcmNoYWVvbG9neSBhbmQgZm91bmQg dGhlIG1lc3NhZ2UNCj4+Pj4gd2hlcmUgU3RldmUgRGVlcmluZyBzdW1tYXJpc2VkIHRoZSBpc3N1 ZXMgcmVzb2x2ZWQgYmVmb3JlIFJGQyAxODgzICh0aGUgcHJlZGVjZXNzb3INCj4+Pj4gb2YgUkZD IDI0NjApIHdhcyBwdWJsaXNoZWQgaW4gMTk5NS4gSSd2ZSBhdHRhY2hlZCBpdCBiZWxvdyAtIGxv b2sganVzdCBhZnRlcg0KPj4+PiAicmVqZWN0ZWQgYXQgdGhlIFN0b2NraG9sbSBtZWV0aW5nIiBp LmUuIElFVEYgMzMuIFRoZSBjb21tZW50IHRoYXQgdHJpZ2dlcmVkDQo+Pj4+IGl0IHdhcyBpbiBt ZXNzYWdlIChJUG5nIDM0NikgZnJvbSBDaGFybGllIEx5bm4gc2VudCAzMCBKdW5lIDE5OTUuDQo+ Pj4+IA0KPj4+PiBbSSBrbmV3IG15IG1haWwgYXJjaGl2ZXMgd291bGQgYmUgdXNlZnVsIG9uZSBk YXkuXQ0KPj4+IA0KPj4+IFN0dW5uaW5nIHJlY29sbGVjdGlvbiBwb3dlcnMgQnJpYW4hDQo+Pj4g DQo+Pj4gVGhlIHBhcmFncmFwaCB5b3UgcG9pbnQgdG8sIGkuZS46DQo+Pj4gDQo+Pj4gCSJyZWFz b25zIGZvciByZWplY3Rpb246IGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVycyBlbi1yb3V0 ZSBicmVha3MNCj4+PiAgIAlQTVRVLWRpc2NvdmVyeSBhbmQgY2FuIHJlc3VsdCBpbiBJQ01QIGVy cm9yIG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8NCj4+PiAgIAlub24tZ3VpbHR5IHBhcnRpZXMuICBU aGUgZGVzaXJlZCBlZmZlY3QgY2FuIGJlIGFjaGlldmVkLCBhbmQgdGhvc2UNCj4+PiAgIAlwcm9i bGVtcyBhdm9pZGVkLCBieSB1c2luZyBlbi1yb3V0ZSBlbmNhcHN1bGF0aW9uICh3aXRoIG9wdGlv bmFsDQo+Pj4gICAJUm91dGluZyBIZWFkZXIpIHJhdGhlciB0aGFuIGhlYWRlciBpbnNlcnRpb24u 4oCdDQo+Pj4gDQo+Pj4gc3RpbGwgc2VlbXMgdmFsaWQgdG8gbWUsIGFuZCB0aHVzIEkgYWdyZWUg d2l0aCBCb2LigJlzIHByb3Bvc2FsLiBXaGV0aGVyIHRoZSBhYm92ZSByYXRpb25hbGUgaXMgYWxz byBpbmNsdWRlZCBpcyBhbiBhZGRpdGlvbmFsIHF1ZXN0aW9uLg0KPj4+IA0KPj4+IEZvciBleGFt cGxlLCBpbiBzZWN0aW9uIDIuMiBvZmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVh ZGVyLCBpdCBzdGF0ZXM6ICJBdCB0aGUgaW5ncmVzcyBub2RlIG9mIGFuIFNSIGRvbWFpbiB3aGVy ZSB0aGUgaW5ncmVzcyBub2RlIHJlY2VpdmVzIGFuIElQdjYgcGFja2V0IGFuZCBlbmNhcHN1bGF0 ZXMgaXQgaW50byBhbiBvdXRlciBJUHY2IGhlYWRlciBmb2xsb3dlZCBieSBhIFNlZ21lbnQgUm91 dGluZyBoZWFkZXIu4oCdDQo+PiANCj4+IA0KPj4gQ29ycmVjdC4gVGhlIGRpc2N1c3Npb24gd2Xi gJlyZSBoYXZpbmcgaXMgbm90IHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXIgYnV0IHJhdGhlciBvbiBhIHVzYWdlIG9mIHRoZSBTUkggdGhhdCB0aGUgaW5k dXN0cnkgaXMgYWRvcHRpbmcgYW5kIHRoYXQgaW5jbHVkZXMgaGVhZGVyIGluc2VydGlvbi4gDQo+ IA0KPiBBbmQgdXNhZ2UgdGhhdCBpcyBub3QgYmVpbmcgc3RhbmRhcmRpc2VkIHdpdGhpbiB0aGUg SUVURiwgb3IgaXMgaXQ/ICANCg0KDQppdCB3b3VsZCBiZSBnb29kIHRvIHN0YW5kYXJkaXplIGJl aGF2aW9ycyB1c2VkIGJ5IHRoZSBpbmR1c3RyeSBldmVuIGlmIHRoZXNlIGJlaGF2aW9ycyBhcmUg bm90IHRoZSBvbmVzIG9yaWdpbmFsbHkgcGxhbm5lZCBhdCB0aGUgdGltZSB0aGUgc3BlYyBoYXMg YmVlbiB3cml0dGVuLg0KDQpCeSBzdGFuZGFyZGl6YXRpb24gSSBpbnRlbmQgZGlnIG91dCBhbGwg ZGV0YWlscyB0aGF0IG5lZWRzIHRvIGJlIGNhcmVmdWxseSBhZGRyZXNzZWQuDQoNCnMuDQoNCg0K PiANCj4gVGltDQo+IA0KPj4gcy4NCj4+IA0KPj4gDQo+Pj4gDQo+Pj4gVGltDQo+Pj4gDQo+Pj4+ IEJyaWFuDQo+Pj4+IA0KPj4+Pj4gTm90ZSwgSSB0aGluayBpdCB3b3VsZCBiZSBmaW5lIGZvciBz b21lb25lIHRvIGRvY3VtZW50IGhvdyB0byBkbyBleHRlbnNpb24gaGVhZGVyIGluc2VydGlvbiwg YXMgbG9uZyBhcyB0aGV5IGRlc2NyaWJlIGhvdyBpdCB3b3JrcywgYW5kIGhvdyB0byBkZWFsIGlz c3VlcyBsaWtlIE1UVSBwcm9ibGVtcy4gIFRoaXMgY2FuIGJlIGJlIGFuIHVwZGF0ZSB0byByZmMy NDYwYmlzIChhZnRlciBpdCBpcyBwdWJsaXNoZWQpLg0KPj4+Pj4gDQo+Pj4+PiBIb3dldmVyLCBJ IGRvIG5vdCB0aGluayBsZWF2aW5nIHRoZSByZmMyNDYwYmlzIHRleHQgaW4gYW4gYW1iaWd1b3Vz IHN0YXRlIG9uIHRoaXMgdG9waWMgaXMgYSBnb29kIGlkZWEuDQo+Pj4+PiANCj4+Pj4+IENvbW1l bnRzPw0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBCb2INCj4+Pj4gDQo+Pj4+IC0tLS0t LS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+Pj4+IFN1YmplY3Q6IChJUG5nIDYwOSkg Y2hhbmdlcyB0byBMYXN0IENhbGwnZWQgc3BlY3MNCj4+Pj4gRGF0ZTogU3VuLCAyNyBBdWcgMTk5 NSAyMDo1OToyNiBQRFQNCj4+Pj4gRnJvbTogU3RldmUgRGVlcmluZyA8ZGVlcmluZ0BwYXJjLnhl cm94LmNvbT4NCj4+Pj4gVG86IGlwbmdAc3Vucm9vZi5lbmcuc3VuLmNvbQ0KPj4+PiBDQzogZGVl cmluZ0BwYXJjLnhlcm94LmNvbQ0KPj4+PiANCj4+Pj4gQXQgdGhlIHJlcXVlc3Qgb2Ygb3VyIEFE cywgSSBwcmVwYXJlZCB0aGUgZm9sbG93aW5nIGxpc3Qgb2YgYWdyZWVkLXVwb24NCj4+Pj4gY2hh bmdlcyBhbmQgb3V0c3RhbmRpbmcgaXNzdWVzIHdpdGggdGhlIHNldCBvZiBzcGVjcyB0aGF0IHVu ZGVyd2VudA0KPj4+PiBJRVRGLXdpZGUgTGFzdCBDYWxsIGluIEp1bmUgYW5kIEp1bHkuICBQbGVh c2UgbGV0IG1lIGtub3cgb2YgYW55IGVycm9ycw0KPj4+PiBvciBvbWlzc2lvbnMuDQo+Pj4+IA0K Pj4+PiBTdGV2ZQ0KPj4+PiANCj4+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj4+Pj4gDQo+Pj4+IElQdjYgU3BlY2lmaWNhdGlvbg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0NCj4+Pj4gDQo+Pj4+IFRoZSBmb2xsb3dpbmcgY2hhbmdlcyB3ZXJlIHBvc3RlZCB0byB0aGUg SUVURiBsaXN0IGltbWVkaWF0ZWx5IGZvbGxvd2luZw0KPj4+PiB0aGUgTGFzdCBDYWxsLCBzbyBJ IHRoaW5rIHdlIGNhbiBjb25zaWRlciB0aGVtIHRvIGFsc28gaGF2ZSBiZWVuIExhc3QgQ2FsbGVk Og0KPj4+PiANCj4+Pj4gLSBJbiB0aGUgZXhhbXBsZXMgb2YgaG93IHRvIGxheSBvdXQgb3B0aW9u cywgb24gcGFnZSAyOSwgdHdvIHBsYWNlcw0KPj4+PiB3aGVyZSBpdCBzYXlzICJIZHIgRXh0IExl bj0xIiBzaG91bGQgYmUgIkhkciBFeHQgTGVuPTMiDQo+Pj4+IChyZXBvcnRlZCBieSBIYW1pZCBB c2F5ZXNoKS4NCj4+Pj4gDQo+Pj4+IC0gSW4gc2VjdGlvbiA2LCBGbG93IExhYmVscywgSSBmb3Jn b3QgdG8gaW5jbHVkZSB0aGUgUHJpb3JpdHkgZmllbGQNCj4+Pj4gaW4gdGhlIGxpc3Qgb2YgZmll bGRzIHRoYXQgbXVzdCBoYXZlIHRoZSBzYW1lIHZhbHVlIGZvciBhbGwNCj4+Pj4gcGFja2V0cyBp biB0aGUgc2FtZSBmbG93IChyZXBvcnRlZCBieSBNYXJrdXMgSm9yaykuDQo+Pj4+IA0KPj4+PiAt IFRoZSBkZXNjcmlwdGlvbiBvZiB3aGF0IHRoZSBKdW1ibyBQYXlsb2FkIExlbmd0aCBmaWVsZCBj b3ZlcnMNCj4+Pj4gc2hvdWxkIGJlIG1hZGUgY2xlYXJlciAocmVwb3J0ZWQgYnkgQ2hyaXN0aWFu IEh1aXRlbWEpLg0KPj4+PiANCj4+Pj4gVGhlIGZvbGxvd2luZyBjaGFuZ2VzIHdlcmUgcHJvcG9z ZWQgYnkgQ2hhcmxpZSBMeW5uIGluIHRoZSBvbmx5ICJmb3JtYWwiDQo+Pj4+IHJlc3BvbnNlIHRv IHRoZSBMYXN0IENhbGwsIGFuZCBhY2NlcHRlZCBhdCB0aGUgZmlyc3QgaXBuZ3dnIG1lZXRpbmcg aW4NCj4+Pj4gU3RvY2tob2xtOg0KPj4+PiANCj4+Pj4gLSBGb3Igb3B0aW9ucyBjb250YWluaW5n IGRhdGEgdGhhdCBjYW4gY2hhbmdlIGVuLXJvdXRlIChhbmQgd2hpY2ggdGhlcmVmb3JlDQo+Pj4+ IGhhdmUgdGhlIHRoaXJkLWhpZ2hlc3Qtb3JkZXIgYml0IG9mIHRoZWlyIE9wdGlvbiBUeXBlIHNl dCB0byAxKSwgbWFrZSBpdA0KPj4+PiBjbGVhciB0aGF0ICphbGwqIGJ5dGVzIG9mIHRoZSBPcHRp b24gRGF0YSBmaWVsZCBhcmUgdG8gYmUgZXhjbHVkZWQgZnJvbQ0KPj4+PiB0aGUgQXV0aGVudGlj YXRpb24gZnVuY3Rpb24sIGFuZCBleHBsYWluIHRoYXQgImV4Y2x1ZGVkIiBtZWFucyAidHJlYXRl ZA0KPj4+PiBhcyBpZiB0aGV5IHdlcmUgYWxsIHplcm8tdmFsdWVkIGJ5dGVzIi4NCj4+Pj4gDQo+ Pj4+IC0gQ2hhbmdlIHRoZSBSb3V0aW5nIEhlYWRlciB0byBlbmFibGUgaXQgdG8gYmUgaWdub3Jl ZCBieSBmaW5hbCBkZXN0aW5hdGlvbnMNCj4+Pj4gdGhhdCBkbyBub3QgdW5kZXJzdGFuZCB0aGUg Um91dGluZyBUeXBlLiAgSW4gU3RvY2tob2xtLCBEZWVyaW5nIHByb3Bvc2VkLA0KPj4+PiBhbmQg dGhlIGF0dGVuZGVlcyBhZ3JlZWQgd2l0aCwgdGhlIGZvbGxvd2luZyByZXZpc2VkIGZvcm1hdCBm b3IgdGhlDQo+Pj4+IGZpcnN0IDMyIGJpdHMgb2YgdGhlIFJvdXRpbmcgSGVhZGVyLCBmb3IgYWxs IFJvdXRpbmcgVHlwZXM6DQo+Pj4+IA0KPj4+PiAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+Pj4gIHwgIE5leHQgSGVh ZGVyICB8ICBIZHIgRXh0IExlbiAgfCAgUm91dGluZyBUeXBlIHwgU2VnbWVudHMgTGVmdCB8DQo+ Pj4+ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPj4+PiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4gDQo+Pj4+IHdoZXJlDQo+Pj4+IA0K Pj4+PiAJSGRyIEV4dCBMZW4gICBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBoZWFkZXIgaW4gOC1vY3Rl dCB1bml0cywgbm90DQo+Pj4+IAkgICAgICAgICAgICAgIGluY2x1ZGluZyB0aGUgZmlyc3QgOCBv Y3RldHMNCj4+Pj4gDQo+Pj4+IAlTZWdtZW50cyBMZWZ0IGlzIHRoZSBudW1iZXIgb2YgImxlZ3Mi IGxlZnQgdG8gdHJhdmVyc2UgaW4gdGhlDQo+Pj4+ICAgICAgICAgICAgICAgICAgIHJvdXRlOyBp ZiB0aGlzIHZhbHVlIGlzIHplcm8sIHRoZSByZWNlaXZlciBtYXkNCj4+Pj4gCSAgICAgICAgICAg ICAgaWdub3JlIHRoaXMgaGVhZGVyIChpLmUuLCBpdCBpbmRpY2F0ZXMgdGhhdCB0aGUNCj4+Pj4g CSAgICAgICAgICAgICAgcm91dGUgaGFzIGJlZW4gY29tcGxldGVkKSwgd2hldGhlciBvciBub3Qg dGhlDQo+Pj4+IAkgICAgICAgICAgICAgIHJlY2VpdmVyIHVuZGVyc3RhbmRzIHRoZSBSb3V0aW5n IFR5cGUNCj4+Pj4gDQo+Pj4+IFRoZSBmb2xsb3dpbmcgYWRkaXRpb25hbCBjaGFuZ2VzIHdlcmUg YWdyZWVkIHRvIGVpdGhlciBvbiB0aGUgbWFpbGluZyBsaXN0DQo+Pj4+IG9yIGluIHRoZSBTdG9j a2hvbG0gbWVldGluZ3M6DQo+Pj4+IA0KPj4+PiAtICJJbXByb3ZlIiB0aGUgaG9zdC9yb3V0ZXIg dGVybWlub2xvZ3kuICBXaGF0IEkgcHJvcG9zZSB0byBkbyBpcyBhZGQgYQ0KPj4+PiBmb290bm90 ZSB0byB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBzYXlpbmcgc29tZXRoaW5nIGxpa2UgdGhpczoN Cj4+Pj4gDQo+Pj4+IAkqIGl0IGlzIHBvc3NpYmxlLCB0aG91Z2ggdW51c3VhbCwgdG8gaGF2ZSBh IGRldmljZSB3aXRoIG11bHRpcGxlDQo+Pj4+ICAgICAgIGludGVyZmFjZXMgY29uZmlndXJlZCB0 byBmb3J3YXJkIG5vbi1zZWxmLWRlc3RpbmVkIHBhY2tldHMNCj4+Pj4gICAgICAgYXJyaXZpbmcg ZnJvbSBzb21lIHNldCAoZmV3ZXIgdGhhbiBhbGwpIG9mIGl0cyBpbnRlcmZhY2VzLCBhbmQNCj4+ Pj4gCSAgdG8gZGlzY2FyZCBub24tc2VsZi1kZXN0aW5lZCBwYWNrZXRzIGFycml2aW5nIGZyb20g aXRzIG90aGVyDQo+Pj4+IAkgIGludGVyZmFjZXMuICBTdWNoIGEgZGV2aWNlIG11c3Qgb2JleSB0 aGUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzDQo+Pj4+IAkgIGZvciByb3V0ZXJzIHdoZW4gcmVjZWl2 aW5nIHBhY2tldHMgZnJvbSwgYW5kIGludGVyYWN0aW5nIHdpdGgNCj4+Pj4gCSAgbmVpZ2hib3Jz IG92ZXIsIHRoZSBmb3JtZXIgKGZvcndhcmRpbmcpIGludGVyZmFjZXMuICBJdCBtdXN0DQo+Pj4+ IAkgIG9iZXkgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50cyBmb3IgaG9zdHMgd2hlbiByZWNlaXZp bmcgcGFja2V0cw0KPj4+PiAJICBmcm9tLCBhbmQgaW50ZXJhY3Rpbmcgd2l0aCBuZWlnaGJvcnMg b3ZlciwgdGhlIGxhdHRlciAobm9uLQ0KPj4+PiAJICBmb3J3YXJkaW5nKSBpbnRlcmZhY2VzLg0K Pj4+PiANCj4+Pj4gQ29tbWVudHM/DQo+Pj4+IA0KPj4+PiAtIENsYXJpZnkgdGhlIG9wZXJhdGlv biBvZiBUeXBlIDAgUm91dGluZyBIZWFkZXIgYnkgZ2l2aW5nIGFuIGV4YW1wbGUsDQo+Pj4+IHNo b3dpbmcgdGhlIHZhbHVlcyBvZiB0aGUgaGVhZGVyIGZpZWxkcyBvbiBlYWNoIHNlZ21lbnQgb2Yg dGhlIHJvdXRlLg0KPj4+PiANCj4+Pj4gLSBDbGFyaWZ5IHRoZSBoYW5kbGluZyBvZiBvcHRpb25z LCBleHRlbnNpb24gaGVhZGVycywgTmV4dCBIZWFkZXIgZmllbGRzLA0KPj4+PiBldGMuIGZvciBm cmFnbWVudGVkIHBhY2tldHMgYnkgZ2l2aW5nIGEgZmV3IGV4YW1wbGVzIG9mIHBhY2tldHMgYmVm b3JlDQo+Pj4+IGFuZCBhZnRlciBmcmFnbWVudGF0aW9uIChzdWdnZXN0ZWQgYnkgRGltaXRyeSBI YXNraW5zIGFuZCBvdGhlcnMpLg0KPj4+PiANCj4+Pj4gLSBTcGVjaWZ5IHRoYXQgZnJhZ21lbnRz IGNhbm5vdCByZWFzc2VtYmxlIHRvIGZvcm0gYSBqdW1ib2dyYW0gKHN1Z2dlc3RlZA0KPj4+PiBi eSBDcmFpZyBNZXR6KS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBJQ01QdjYgU3BlY2lmaWNhdGlvbg0K Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiANCj4+Pj4gLSBBZGQgbm90ZSB3YXJuaW5n IGFib3V0IHRoZSBwb3NzaWJpbGl0eSBvZiB1cHBlci1sYXllciBoZWFkZXIgYmVpbmcNCj4+Pj4g dHJ1bmNhdGVkIGZyb20gdGhlIHJldHVybmVkIHBhY2tldCBpbiBhbiBlcnJvciBtZXNzYWdlLCBk dWUgdG8gbGFyZ2UNCj4+Pj4gbnVtYmVyIG9mIGV4dGVuc2lvbiBoZWFkZXIgYnl0ZXMsIHdoaWNo IGNhbiBkZWZlYXQgZGVsaXZlcnkgb2YgdGhlDQo+Pj4+IGVycm9yIG1lc3NhZ2UgdG8gdGhlIGd1 aWx0eSB1cHBlci1sYXllciBwcm90b2NvbCBpbnN0YW5jZS4NCj4+Pj4gDQo+Pj4+IC0gRGVsZXRl IGRlc2NyaXB0aW9uIG9mIHBzZXVkby1oZWFkZXIsIHJlcGxhY2luZyBpdCB3aXRoIGEgcmVmZXJl bmNlIHRvDQo+Pj4+IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgSVB2NiBzcGVjIChzdWdnZXN0ZWQg YnkgQWxpc3RhaXIgQmVsbCBhbmQNCj4+Pj4gTWFyYyBIYXNzb24pLg0KPj4+PiANCj4+Pj4gLSBD b3JyZWN0IGV4YW1wbGUgb2YgdXNhZ2Ugb2YgdGhlIHBvaW50ZXIgaW4gdGhlIFBhcmFtZXRlciBQ cm9ibGVtDQo+Pj4+IG1lc3NhZ2Ugb24gcGFnZSAxNSwgYnkgY2hhbmdpbmcgIjQ4IiB0byAiNDAi IChyZXBvcnRlZCBieSBEaW1pdHJ5DQo+Pj4+IEhhc2tpbnMgYW5kIEZyYW5jaXMgRHVwb250KS4N Cj4+Pj4gDQo+Pj4+IC0gTm90ZSB0aGF0IHRoZXJlIGlzIGFub3RoZXIgZXhjZXB0aW9uIHRvIHRo ZSAibm8gSUNNUCBlcnJvciBtZXNzYWdlcw0KPj4+PiBpbiByZXNwb25zZSB0byBtdWx0aWNhc3Rz IiBydWxlLCB3aGljaCBpcyAidW5yZWNvZ25pemVkIG9wdGlvbiINCj4+Pj4gUGFyYW1ldGVyIFBy b2JsZW0gbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gb3B0aW9ucyB3aXRoIGhpZ2gtb3JkZXINCj4+ Pj4gYml0cyAiMTAuLi4iIChyZXBvcnRlZCBieSBEaW1pdHkgSGFza2lucykuDQo+Pj4+IA0KPj4+ PiBBZGRyZXNzIEFyY2hpdGVjdHVyZSBEb2N1bWVudA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+PiANCj4+Pj4gLSBBZGQgZGVmaW5pdGlvbiBvZiAibGluay1sb2NhbCBh ZGRyZXNzIiB0byB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbg0KPj4+PiAoc3VnZ2VzdGVkIGJ5IEpp bSBCb3VuZCkuDQo+Pj4+IA0KPj4+PiAtIFNwZWNpZnkgdGhhdCAiOjoiIGlzIGEgbGVnYWwgdGV4 dCByZXByZXNlbnRhdGlvbiBvZiB0aGUgVW5zcGVjaWZpZWQNCj4+Pj4gKGFsbC16ZXJvcykgQWRk cmVzcyAoc3VnZ2VzdGVkIGJ5IEZyYW5jaXMgRHVwb250KS4NCj4+Pj4gDQo+Pj4+ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+IA0KPj4+PiBUaGUgZm9sbG93aW5nIHN1 Z2dlc3Rpb25zIGluIENoYXJsaWUgTHlubidzIGZvcm1hbCByZXNwb25zZSB0byB0aGUgTGFzdCBD YWxsDQo+Pj4+IHdlcmUgcmVqZWN0ZWQgYXQgdGhlIFN0b2NraG9sbSBtZWV0aW5nOg0KPj4+PiAN Cj4+Pj4gLSBBZGQgYSBiaXQgdG8gdGhlIFJvdXRpbmcgSGVhZGVyIGluZGljYXRpbmcgd2hldGhl ciBvciBub3QgaXQgd2FzDQo+Pj4+IGluc2VydGVkIGludG8gdGhlIHBhY2tldCBlbi1yb3V0ZSwg aS5lLiwgYnkgYSBub2RlIG90aGVyIHRoYW4gdGhlDQo+Pj4+IHBhY2tldCdzIG9yaWdpbmF0b3Iu DQo+Pj4+IA0KPj4+PiAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogaW5zZXJ0aW9uIG9mIGV4dGVu c2lvbiBoZWFkZXJzIGVuLXJvdXRlIGJyZWFrcw0KPj4+PiAgIFBNVFUtZGlzY292ZXJ5IGFuZCBj YW4gcmVzdWx0IGluIElDTVAgZXJyb3IgbWVzc2FnZXMgYmVpbmcgc2VudCB0bw0KPj4+PiAgIG5v bi1ndWlsdHkgcGFydGllcy4gIFRoZSBkZXNpcmVkIGVmZmVjdCBjYW4gYmUgYWNoaWV2ZWQsIGFu ZCB0aG9zZQ0KPj4+PiAgIHByb2JsZW1zIGF2b2lkZWQsIGJ5IHVzaW5nIGVuLXJvdXRlIGVuY2Fw c3VsYXRpb24gKHdpdGggb3B0aW9uYWwNCj4+Pj4gICBSb3V0aW5nIEhlYWRlcikgcmF0aGVyIHRo YW4gaGVhZGVyIGluc2VydGlvbi4NCj4+Pj4gDQo+Pj4+IC0gQ2hhbmdlIElDTVAgZXJyb3IgbWVz c2FnZXMgdG8gY29udGFpbiBleHBsaWNpdCBmaWVsZHMgaWRlbnRpZnlpbmcgdGhlDQo+Pj4+IHVw cGVyLWxheWVyIHByb3RvY29sIHRvIHdoaWNoIHRoZSBlcnJvciBtZXNzYWdlIHNob3VsZCBiZSBk ZWxpdmVyZWQuDQo+Pj4+IA0KPj4+PiAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogY29uc2lkZXJl ZCB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IHRvIGhhbmRsZSB0aGUNCj4+Pj4gICByYXJlIGNhc2Ug b2YgdHJ1bmNhdGlvbiBvZiB0cmFuc3BvcnQgaGVhZGVyIGZyb20gdGhlIHJldHVybmVkIHBhY2tl dA0KPj4+PiAgIGJlY2F1c2Ugb2YgdG9vIG1hbnkgZXh0ZW5zaW9uIGhlYWRlciBvY3RldHMuICBT dWNoIGVycm9yIG1lc3NhZ2VzIGFyZQ0KPj4+PiAgIHN0aWxsIHVzYWJsZSBmb3IgcHJvYmxlbSBk aWFnbm9zaXMgb3RoZXIgdGhhbiBpbiB0aGUgdXBwZXItbGF5ZXINCj4+Pj4gICBpdHNlbGYsIGUu Zy4sIGlmIGxvZ2dlZCBhdCBJUHY2IGxheWVyIG9yIG9ic2VydmVkIGluIGEgcGFja2V0IHRyYWNl Lg0KPj4+PiAgIFdpbGwgYWRkIHdhcm5pbmcgdG8gdGhlIElDTVB2NiBzcGVjIGFib3V0IGNvbnNl cXVlbmNlcyBvZiBsb25nDQo+Pj4+ICAgZXh0ZW5zaW9uIGhlYWRlciBvbiBJQ01QIGVycm9yIG1l c3NhZ2UgZGlzcGF0Y2hpbmcuDQo+Pj4+IA0KPj4+PiAtIENoYW5nZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIG9mIElDTVB2NiBzcGVjIHRvIHNwZWNpZnkgd2hlbg0KPj4+PiBhbmQg aG93IHRvIGluY2x1ZGUgYW4gQXV0aGVudGljYXRpb24gSGVhZGVyIGluIElDTVAgZXJyb3IgbWVz c2FnZXMuDQo+Pj4+IA0KPj4+PiAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogZ3JvdXAgY29uc2Vu c3VzIHRoYXQgdGhpcyBiZWxvbmdzIGluIGFhDQo+Pj4+ICAgSVBzZWMgc3BlYyBpbnN0ZWFkLg0K Pj4+PiANCj4+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+Pj4gDQo+ Pj4+IFRoZSBmb2xsb3dpbmcgaXNzdWVzIGFuZCBzdWdnZXN0aW9ucyBoYXZlIGJlZW4gZGlzY3Vz c2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QNCj4+Pj4gc2luY2UgdGhlIGJhc2Ugc3BlY3Mgd2VudCB0 byBMYXN0IENhbGwsIGJ1dCBubyBncm91cCBjb25zZW5zdXMgb24gdGhlc2UgaXNzdWVzDQo+Pj4+ IGhhcyBiZWVuIHJlYWNoZWQgeWV0Og0KPj4+PiANCj4+Pj4gLSBGcmFnbWVudGF0aW9uIGlzc3Vl czoNCj4+Pj4gCS0gY2hhbmdlIHRoZSBtaW5pbXVtIHJlYXNzZW1ibHkgYnVmZmVyIHNpemUgdG8g YSBudW1iZXIgbGFyZ2VyDQo+Pj4+IAkgIHRoYW4gNTc2Pw0KPj4+PiAJLSBzcGVjaWZ5IHRoYXQg c291cmNlcyBvZiBmcmFnbWVudGVkIHBhY2tldHMgbXVzdCB1c2UgdGhlIG1pbmltYWwNCj4+Pj4g CSAgbnVtYmVyIG9mIGZyYWdtZW50cyByZXF1aXJlZCB0byBmaXQgaW4gdGhlIHBlcmNlaXZlZCBQ TVRVPw0KPj4+PiAJLSBzcGVjaWZ5IHRoYXQgYWxsIGZyYWdtZW50cyB3aXRoIHRoZSBNIGJpdCBz ZXQgbXVzdCBiZSBubyBsZXNzDQo+Pj4+IAkgIHRoYW4gNyBvY3RldHMgc2hvcnRlciB0aGFuIHRo ZSBwZXJjZWl2ZWQgUE1UVT8NCj4+Pj4gCS0gc3BlY2lmeSB0aGF0IGFsbCBmcmFnbWVudHMgd2l0 aCB0aGUgTSBiaXQgc2V0IG11c3QgYmUgbm8gc2hvcnRlcg0KPj4+PiAJICB0aGFuIDU3NiBvY3Rl dHM/DQo+Pj4+IAktIGlnbm9yZSBmcmFnbWVudHMgdGhhdCBwYXJ0aWFsbHkgb3ZlcmxhcCBvdGhl ciBmcmFnbWVudHMgb2YgdGhlDQo+Pj4+IAkgIHNhbWUgcGFja2V0LCBvciBkaXNjYXJkIGFueSBw YWNrZXQgdGhhdCBhcnJpdmVzIGFzIHBhcnRpYWxseQ0KPj4+PiAJICBvdmVybGFwcGluZyBmcmFn bWVudHM/DQo+Pj4+IA0KPj4+PiAtIFJvdXRpbmcgSGVhZGVyIGlzc3VlczoNCj4+Pj4gCS0gYWRk IGEgIlRvdGFsIExlbmd0aCIgZmllbGQgdG8gdGhlIGZyYWdtZW50IGhlYWRlciwgY2Fycnlpbmcg dGhlDQo+Pj4+IAkgIGxlbmd0aCBvZiB0aGUgb3JpZ2luYWwsIHVuZnJhZ21lbnRlZCBwYWNrZXQ/ DQo+Pj4+IAktIGZvcmJpZCBmb3J3YXJkaW5nIG9mIHBhY2tldHMgd2l0aCBSb3V0aW5nIEhlYWRl cnMgYnkgaG9zdHM/DQo+Pj4+IAkgIChpZiBub3QsIG1ha2UgaXQgY2xlYXJlciB0aGF0IGhvc3Rz IGFyZSBleHBlY3RlZCB0byBmb3J3YXJkDQo+Pj4+IAkgIHBhY2tldHMgd2l0aCBSb3V0aW5nIEhl YWRlcnMsIGlmIHRoZXkgYXJlIGludGVybWVkaWF0ZSB0YXJnZXRzDQo+Pj4+IAkgIG9mIHN1Y2gg cGFja2V0cy4pDQo+Pj4+IAktIHNwZWNpZnkgdGhlIHJldmVyc2luZyBydWxlcyBmb3IgcGFja2V0 cyB0aGF0IGFyZSByZXNwb25zZXMgdG8NCj4+Pj4gCSAgcGFja2V0cyB0aGF0IGNhcnJ5IGEgUm91 dGluZyBIZWFkZXI/DQo+Pj4+IAktIGZvcmJpZCBvciBkaXNjb3VyYWdlIHJldmVyc2FsIG9mIGFu IHVuYXV0aGVudGljYXRlZCBSb3V0aW5nIEhlYWRlcj8NCj4+Pj4gCS0gZm9yYmlkIG9yIGRpc2Nv dXJhZ2UgYWNjZXB0YW5jZSBvZiBhIHBhY2tldCB3aXRoIGFuIHVuYXV0aGVudGljYXRlZA0KPj4+ PiAJICBSb3V0aW5nIEhlYWRlcj8NCj4+Pj4gDQo+Pj4+IC0gQWxsb3cgdGhlIHRyYW5zcG9ydC1s YXllciBjaGVja3N1bSB0byBiZSBvbWl0dGVkIHdoZW4gdGhlIEF1dGhlbnRpY2F0aW9uDQo+Pj4+ IGhlYWRlciAob3IgdGhlIEVTUCBoZWFkZXI/KSBpcyBiZWluZyB1c2VkPw0KPj4+PiANCj4+Pj4g LSBBZGQgYSBDb25nZXN0aW9uIEluZGljYXRpb24gYml0IHRvIHRoZSBiYXNlIElQdjYgaGVhZGVy Pw0KPj4+PiANCj4+Pj4gLSBBZGQgTVVTVC9TSE9VTEQvTUFZIGNvbmZvcm1hbmNlIHJlcXVpcmVt ZW50cyBmb3IgYWxsIElQdjYgZmllbGRzIGFuZA0KPj4+PiBmdW5jdGlvbnM/DQo+Pj4+IA0KPj4+ PiAtIEJ1aWxkIGEgc2luZ2xlIFRlcm1pbm9sb2d5IGRvY3VtZW50LCB0byBiZSBzaGFyZWQgKGVp dGhlciBieSByZWZlcmVuY2UNCj4+Pj4gb3IgaW5jbHVzaW9uKSBpbiBhbGwgSVB2Ni1yZWxhdGVk IHNwZWNzPw0KPj4+PiANCj4+Pj4gLSBBbGxvdyB0aGUgdXNlIG9mIHplcm8gaW4gdGhlIFVEUCBM ZW5ndGggZmllbGQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgVURQDQo+Pj4+IGxlbmd0aCBzaG91bGQg YmUgZGVyaXZlZCBmcm9tIHRoZSBKdW1ib2dyYW0gT3B0aW9uPw0KPj4+PiANCj4+Pj4gTm90ZTog dGhlIGFib3ZlIGxpc3QgZG9lcyBub3QgaW5jbHVkZSBpc3N1ZXMgY29uY2VybmluZyB0aG9zZSBz cGVjcyB0aGF0DQo+Pj4+IGhhdmUgbm90IHlldCBiZWVuIHN1YmplY3RlZCB0byBXRyBvciBJRVRG IExhc3QgQ2FsbCwgZS5nLiwgdGhlIE5laWdoYm9yDQo+Pj4+IERpc2NvdmVyeSBzcGVjLg0KPj4+ PiANCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+IElFVEYgSVBuZyBNYWlsaW5nIExp c3QJCSAgICAgIEZUUCBhcmNoaXZlOiBmdHAucGFyYy54ZXJveC5jb206L3B1Yi9pcG5nDQo+Pj4+ IElQbmcgSG9tZSBQYWdlOiAgICAgICAgICBodHRwOi8vcGxheWdyb3VuZC5zdW4uY29tL3B1Yi9p cG5nL2h0bWwvaXBuZy1tYWluLmh0bWwNCj4+Pj4gRGlyZWN0IGFsbCBhZG1pbmlzdHJhdGl2ZSBy ZXF1ZXN0cyB0byBtYWpvcmRvbW9Ac3Vucm9vZi5lbmcuc3VuLmNvbQ0KPj4+PiANCj4+Pj4gDQo+ Pj4+IA0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QNCj4+Pj4gaXB2NkBpZXRmLm9yZw0KPj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91 cCBtYWlsaW5nIGxpc3QNCj4+PiBpcHY2QGlldGYub3JnDQo+Pj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+PiANCj4gDQoNCg== From nobody Thu Apr 28 09:26:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FC812D934 for ; Thu, 28 Apr 2016 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 togriBVcTkDt for ; Thu, 28 Apr 2016 09:26:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7EE12D1CC for ; Thu, 28 Apr 2016 09:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZPWbTtTXhLMqJE65M+0uw+e1jUuWFxKU4FBtSOSfQbg=; b=aZA4jgUBkbdzZo43cg8vkokL34DdtA1zwy+4ZXxeFt2JHQ4F4WDK/lF6TJoMJW8i5ypiRLE6w5XtGKKirOG5k3Vf0zmMA7zCnSzF7I9eukgxI1IKRgOoV8Xg4qsZGXHUji3IfV9TImvnwdxiuCkZdwsVoIxUycG4FUN0BnvHaNk= Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1988.namprd05.prod.outlook.com (10.162.224.30) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 28 Apr 2016 16:23:01 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0477.012; Thu, 28 Apr 2016 16:23:01 +0000 From: Ronald Bonica To: Bob Hinden , IPv6 List Subject: RE: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoOvwnirshrUy8kK9HDC9bT0iI5+fjRvQ Date: Thu, 28 Apr 2016 16:23:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: b875515d-cf39-4738-f29b-08d36f815e45 x-microsoft-exchange-diagnostics: 1; BLUPR05MB1988; 5:lChnJ/Lr0xUwbnNZKFd0EOD18eNfhHBs0sbrU4/IYi2gVasXF3GYucqwOn7NeL24G6GexLFhN7xeRMWib1kXk1JtNupUlluVZ+LXspzFFiVtFEDTNjaA5eKBab7Dd+0vQ0JEdU8hRQSKSn79RsrRFQ==; 24:4GdstHHfRM+hHnN7qVOmj3sbxDbzY21sJRlmo2TeDL36FcNsziDZCHCXjXICKxiHAjq+ZBKXgXdCLSnJwa0tSlBUtVeW6ib796JYPW9KfTM=; 7:d7080h87OD2C5jWcLAU9L66l8ib7x6LsjihiQ4BixqIKn8fVJ8PFBvPKtcISazrXnMaQ9pt90k5NQX23Mqe2lEa5iqnddgq36PPrIx75HZV5MS7982c2BLNcRwVfUlfRRedCX8hUl04I2fzaa7JX4BEIwN6O49izVhyCiNDzDtRbpqBPBHDz4iph6Xpso0g3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1988; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR05MB1988; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1988; x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(13464003)(377454003)(5001770100001)(33656002)(107886002)(86362001)(5008740100001)(189998001)(92566002)(1220700001)(1096002)(2906002)(6116002)(102836003)(122556002)(5004730100002)(586003)(3846002)(81166005)(87936001)(9686002)(76576001)(19580405001)(106116001)(19580395003)(3660700001)(5003600100002)(11100500001)(76176999)(2900100001)(54356999)(2950100001)(10400500002)(3280700002)(5002640100001)(99286002)(50986999)(77096005)(66066001)(74316001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1988; H:BLUPR05MB1985.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 16:23:01.0759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1988 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:26:34 -0000 Qm9iLA0KDQpNYXliZSB3ZSBzaG91bGQgY2hhbmdlIHRoZSBNVVNUIE5PVCB0byBhIFNIT1VMRCBO T1QuIFRoZSBzdGF0ZW1lbnQgc2hvdWxkIGV4cGxhaW4gdGhhdCBpbiBtYW55IG9wZXJhdGlvbmFs IHNjZW5hcmlvcywgaW5zZXJ0aW9uIG9mIGV4dGVuc2lvbiBoZWFkZXJzIGJ5IHRyYW5zaXQgbm9k ZXMgY2FuIGJyZWFrIFBNVFVELiBIb3dldmVyLCBpbiBvcGVyYXRpb25hbCBzY2VuYXJpb3Mgd2hl cmUgdGhpcyBpcyBub3QgYSBwcm9ibGVtLCBpdCBpcyBPSyBmb3IgdHJhbnNpdCBub2RlcyB0byBp bnNlcnQgZXh0ZW5zaW9uIGhlYWRlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgSGluZGVuDQo+IFNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMjcsIDIwMTYgOToxOSBQTQ0KPiBUbzogSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPg0K PiBDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+DQo+IFN1YmplY3Q6IEluc2Vy dGluZyBFeHRlbnNpb24gSGVhZGVycyBvciBub3QgW3dhcyByZmMyNDYwYmlzIHF1ZXN0aW9uIF0N Cj4gDQo+IEhpLA0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIGdldCBjbG9zdXJlIG9uIHRoZSBxdWVz dGlvbiBpZiBpbnNlcnRpbmcgSVB2NiBleHRlbnNpb24gaGVhZGVycw0KPiBpcyBhbGxvd2VkIG9y IG5vdCwgYW5kIHNob3VsZCB0aGlzIGJlIGEgY2xhcmlmaWNhdGlvbiBpbiByZmMyNDYwYmlzLiAg VGhpcyB0b3BpYw0KPiB3YXMgZGlzY3Vzc2VkIGluIEJ1ZW5vcyBBaXJlcyBhbmQgb24gdGhlIG1h aWxpbmcgbGlzdC4NCj4gDQo+IFRoZSByZWxldmFudCB0ZXh0IGZyb20gU2VjdGlvbiA0ICJJUHY2 IEV4dGVuc2lvbiBIZWFkZXJzIiBpbiA8ZHJhZnQtaWV0Zi0NCj4gNm1hbi1yZmMyNDYwYmlzLTA0 LnR4dD4NCj4gDQo+ICAgIEV4dGVuc2lvbiBoZWFkZXJzIG11c3QgbmV2ZXIgYmUgaW5zZXJ0ZWQg YnkgYW55IG5vZGUgb3RoZXIgdGhhbiB0aGUNCj4gICAgc291cmNlIG9mIHRoZSBwYWNrZXQuICBJ UCBFbmNhcHN1bGF0aW9uIG11c3QgYmUgdXNlZCB0byBtZWV0IGFueQ0KPiAgICByZXF1aXJlbWVu dCBmb3IgaW5zZXJ0aW5nIGhlYWRlcnMsIGZvciBleGFtcGxlLCBhcyBkZWZpbmVkIGluDQo+ICAg IFtSRkMyNDczXS4NCj4gDQo+IFRoaXMgdGV4dCB3YXMgYWRkZWQgdG8gdGhlIGRyYWZ0IGluIHZl cnNpb24g4oCUMDEgcHVibGlzaGVkIG9uIDIgTm92ZW1iZXINCj4gMjAxNS4NCj4gDQo+IFRoZSBx dWVzdGlvbiBpcyBpZiB0aGlzIHRleHQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgcmZjMjQ2 MC4gIFRoYXQgd291bGQgYWxsb3cNCj4gaXQgdG8gYmUgcGFydCBvZiByZmMyNDYwYmlzIGdvaW5n IHRvIEludGVybmV0IFN0YW5kYXJkLiAgSWYgaXQgaXMgYSBjaGFuZ2UsIHRoZW4gaXQNCj4gc2hv dWxkIG5vdCBiZSBpbmNsdWRlZC4NCj4gDQo+IEluIG15IHBlcnNvbmFsIHZpZXcgKGFzIG9uZSBv ZiB0aGUgYXV0aG9ycyBvZiByZmMyNDYwKSwgSSB0aGluayBpdCB3YXMgdGhlDQo+IG9yaWdpbmFs IGludGVudCB0byBub3QgYWxsb3cgZXh0ZW5zaW9uIGhlYWRlcnMgdG8gYmUgaW5zZXJ0ZWQuICBN eSB0aGlua2luZyBpcw0KPiB0aGF0IG5vdCBhbGxvd2luZyBleHRlbnNpb24gaGVhZGVycyB0byBi ZSBpbnNlcnRlZCBpcyByZWxhdGVkIHRoZSBkZXNpZ24gb2YNCj4gSVB2NiB0aGF0IGluY2x1ZGVz IG9ubHkgc3VwcG9ydGluZyBmcmFnbWVudGF0aW9uIGF0IHRoZSBzb3VyY2UuICBJUHY0IGFsbG93 cw0KPiB0aGUgYWRkaXRpb24gb2Ygb3B0aW9ucyByZXN1bHRpbmcgaW4gY2hhbmdpbmcgdGhlIGhl YWRlciBsZW5ndGgsIGJ1dCBpdA0KPiBpbmNsdWRlcyBwZXItaG9wIGZyYWdtZW50YXRpb24gc28g YW55IHJlc3VsdGluZyBNVFUgaXNzdWVzIGNhbiBiZSBkZWFsdA0KPiB3aXRoLiAgRXZlbiBJUHY0 IGZyYWdtZW50cyBjYW4gYmUgZnJhZ21lbnRlZC4gIEkgdGhpbmsgaXQgaXMgYSBjb25zZXF1ZW5j ZSBvZg0KPiBJUHY2IG5vdCBhbGxvdyBwZXItaG9wIGZyYWdtZW50YXRpb24sIHRoYXQgZXh0ZW5z aW9uIGhlYWRlcnMgd2VyZSBub3QNCj4gaW50ZW5kZWQgdG8gYmUgaW5zZXJ0ZWQgYWxvbmcgdGhl IHBhdGggdG8gdGhlIGRlc3RpbmF0aW9uLg0KPiANCj4gTm90ZSwgSSB0aGluayBpdCB3b3VsZCBi ZSBmaW5lIGZvciBzb21lb25lIHRvIGRvY3VtZW50IGhvdyB0byBkbyBleHRlbnNpb24NCj4gaGVh ZGVyIGluc2VydGlvbiwgYXMgbG9uZyBhcyB0aGV5IGRlc2NyaWJlIGhvdyBpdCB3b3JrcywgYW5k IGhvdyB0byBkZWFsDQo+IGlzc3VlcyBsaWtlIE1UVSBwcm9ibGVtcy4gIFRoaXMgY2FuIGJlIGJl IGFuIHVwZGF0ZSB0byByZmMyNDYwYmlzIChhZnRlciBpdCBpcw0KPiBwdWJsaXNoZWQpLg0KPiAN Cj4gSG93ZXZlciwgSSBkbyBub3QgdGhpbmsgbGVhdmluZyB0aGUgcmZjMjQ2MGJpcyB0ZXh0IGlu IGFuIGFtYmlndW91cyBzdGF0ZSBvbg0KPiB0aGlzIHRvcGljIGlzIGEgZ29vZCBpZGVhLg0KPiAN Cj4gQ29tbWVudHM/DQo+IA0KPiBUaGFua3MsDQo+IEJvYg0KPiANCj4gDQoNCg== From nobody Thu Apr 28 09:34:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC12812D87A for ; Thu, 28 Apr 2016 09:34:48 -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 YOgZlrcVEh_D for ; Thu, 28 Apr 2016 09:34:45 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 CF9AC12D9D4 for ; Thu, 28 Apr 2016 09:31:37 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n63so34186804qkf.0 for ; Thu, 28 Apr 2016 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Q1MByOm81IHoAV8X29wMLwLE3T9mJdxrjeD4xcO6Dn0=; b=dVO4O52wvnDta7l3B9L0pHh1xAdy3DH3gxxMeUqxENIblmo35+y9f9ici2vs7FaCgh y/fLzN9ShYCQEywVHXFGQfLDAsO2QcJiu59dlifXDVUE/4OOs6Z+IeQck/C7hdnV8EZ8 BKCd1LuNFvi3tyG7BeoHe4Hud+oZCIiVrj2bSFJ6ztSrP6e0X+xyn+4iAnB8EUEusZ84 XGfqaCXOHRa9VqrPpBOcVKyVM2HQD9Px+3V24l5snxfEze0u/goIxhcMHjCKfTLv0RpT QbfCsPGxM5BYuQQoBf1Et9wsjiE1b4Av+ajFMtJ6MS8/xk5E8MM8rWrTrlawi2UunsRs +oCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Q1MByOm81IHoAV8X29wMLwLE3T9mJdxrjeD4xcO6Dn0=; b=ViXcJKLuwwrDU/rpqX+61nfaezkn5tXRz5cVO+juq49WpcSWIrGHr43LB1rkPEnhiy 6IP8moMSxI768o9mreQeQn3lKMI5hYKXE3zorHgwD03Cnk7lPVWWLcZl8s8bp3LX9RsM AyqX1N8xKerE4BBuC0xFyEuwQoDYodoksxt1o8ScDhUlHUAVgyoyZseC6xGKvXtsTRPs 5Sf8kzA5Q4CI2SVOThyuj25Lv82bw1R8mnm0Vla4obC7cJ/PSK3YuC+wCtyiXzbmjcEN fE6YJcXTlX4qCgcGxoTJ42axVRYfYBr8y/aboxGuZdNG6B93qAQswcKYNFh5Wn6fL6R4 ksow== X-Gm-Message-State: AOPr4FVVgQ7na3NxdMJnhEHPmmfocR7yTCUZLUn4boj1UCm66Lav20ojs1YrmuuxuYjpOg== X-Received: by 10.55.27.21 with SMTP id b21mr15617959qkb.208.1461861096747; Thu, 28 Apr 2016 09:31:36 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1001::272? ([2001:420:c0c4:1001::272]) by smtp.gmail.com with ESMTPSA id v5sm3047513qhv.21.2016.04.28.09.31.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 09:31:35 -0700 (PDT) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7C6D25FC-1441-4535-9A38-E6111F0DDCA1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Ralph Droms In-Reply-To: Date: Thu, 28 Apr 2016 12:31:32 -0400 Message-Id: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> References: To: Ronald Bonica X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:34:49 -0000 --Apple-Mail=_7C6D25FC-1441-4535-9A38-E6111F0DDCA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 28, 2016, at 12:23 PM 4/28/16, Ronald Bonica = wrote: >=20 > Bob, >=20 > Maybe we should change the MUST NOT to a SHOULD NOT. The statement = should explain that in many operational scenarios, insertion of = extension headers by transit nodes can break PMTUD. However, in = operational scenarios where this is not a problem, it is OK for transit = nodes to insert extension headers. I think it should remain MUST NOT. In addition to PMTUD, there is the = problem of inserted headers causing ICMP notifications being delivered = to a host that is unaware of the case of the problem. - Ralph >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >> Sent: Wednesday, April 27, 2016 9:19 PM >> To: IPv6 List >> Cc: Bob Hinden >> Subject: Inserting Extension Headers or not [was rfc2460bis question = ] >>=20 >> Hi, >>=20 >> I would like to get closure on the question if inserting IPv6 = extension headers >> is allowed or not, and should this be a clarification in rfc2460bis. = This topic >> was discussed in Buenos Aires and on the mailing list. >>=20 >> The relevant text from Section 4 "IPv6 Extension Headers" in = > 6man-rfc2460bis-04.txt> >>=20 >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >>=20 >> This text was added to the draft in version =E2=80=9401 published on = 2 November >> 2015. >>=20 >> The question is if this text was the original intent of rfc2460. = That would allow >> it to be part of rfc2460bis going to Internet Standard. If it is a = change, then it >> should not be included. >>=20 >> In my personal view (as one of the authors of rfc2460), I think it = was the >> original intent to not allow extension headers to be inserted. My = thinking is >> that not allowing extension headers to be inserted is related the = design of >> IPv6 that includes only supporting fragmentation at the source. IPv4 = allows >> the addition of options resulting in changing the header length, but = it >> includes per-hop fragmentation so any resulting MTU issues can be = dealt >> with. Even IPv4 fragments can be fragmented. I think it is a = consequence of >> IPv6 not allow per-hop fragmentation, that extension headers were not >> intended to be inserted along the path to the destination. >>=20 >> Note, I think it would be fine for someone to document how to do = extension >> header insertion, as long as they describe how it works, and how to = deal >> issues like MTU problems. This can be be an update to rfc2460bis = (after it is >> published). >>=20 >> However, I do not think leaving the rfc2460bis text in an ambiguous = state on >> this topic is a good idea. >>=20 >> Comments? >>=20 >> Thanks, >> Bob >>=20 >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_7C6D25FC-1441-4535-9A38-E6111F0DDCA1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXIjrlAAoJEINeeBNmFjV5+t0QAKGcCVZia/+C/loyH87koLKf jcc2/2aAZP5va5bRYpnpcxtH/Z0eP+VtlM1IvQXmTd5Gg2oxrFlTmrt3odYstDcE cS6pmRih/JK5IYxcYXhMsFcOJzXDprLjmNbaBP7gfQLAKAweBstEb4qxwJ0dbHVf wsWO3iDZ5WKkSwd7w0dUUEqwtXYuLgQVnO48g9BwuvnHiEy3Y9KCH3NXgIcWsxUC 2OvVAFS1okHpZIoiQOzpg2wRtw5XowSEBr8xMJMO6sfd1NmA4gMZsWWAx8mgTAKX vk8KCyUk6N0ArLAqOcYGpRPKhxSYe4Wr92C6ZvwFXjiwAGIbXCZp/CznoVMIbwrY 3pzAeXhwvUV4TrpKTCwEz2yUfJHun0gssVEWkvOOtSn1GcqSl8r5HlQHGtju/ODr /7Tsp82K5vQJQuZ5kn7kTgbLNWAlc2Ct9Nx7mlZDMJ2qtrmxNpx8RCeV0Z7rSOvb r1afalLDddkjRZUC6VfptjOj+V+xcDdTMENkQoy+1KYar2+Oeeor7mPF9WeyHxxH kZFE9H4+jIY6FqLPBuuhkvrjq4hdUt6sUWbS5FDtQy9q3/ZT7rCjkLmRoJdtvgLr uWqX4YhBhaKJ0b12WKnQ2ha2VhsADmEFuZFOFK2fyxMVn5aVex/C4c5u4BiO9u9C SJWVqDRWMGH1wCKvGQNn =/Q4z -----END PGP SIGNATURE----- --Apple-Mail=_7C6D25FC-1441-4535-9A38-E6111F0DDCA1-- From nobody Thu Apr 28 09:49:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774D012B074 for ; Thu, 28 Apr 2016 09:49:09 -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 qtX3GIZxCgUj for ; Thu, 28 Apr 2016 09:49:06 -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 9F3C512B047 for ; Thu, 28 Apr 2016 09:49:06 -0700 (PDT) Received: from [192.168.1.156] (63-188-16-190.fibertel.com.ar [190.16.188.63]) (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 2508C824E4; Thu, 28 Apr 2016 18:49:00 +0200 (CEST) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] To: Ronald Bonica , Bob Hinden , IPv6 List References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <57223BAA.8010908@gont.com.ar> Date: Thu, 28 Apr 2016 13:34:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:49:09 -0000 On 04/28/2016 01:23 PM, Ronald Bonica wrote: > Bob, > > Maybe we should change the MUST NOT to a SHOULD NOT. The statement > should explain that in many operational scenarios, insertion of > extension headers by transit nodes can break PMTUD. However, in > operational scenarios where this is not a problem, it is OK for > transit nodes to insert extension headers. mmm... I guess you don't need ietf permission to violate the specs in your own walled garden? -- 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 Thu Apr 28 10:57:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8912D8D7 for ; Thu, 28 Apr 2016 10:57:17 -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.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 jAB95GNzcNhL for ; Thu, 28 Apr 2016 10:57:16 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 E5FEB12D8D6 for ; Thu, 28 Apr 2016 10:57:15 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id u10so111556228igr.1 for ; Thu, 28 Apr 2016 10:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=n2qyUY5cdUeK3ry72ZyfGwSOvV29bEp3a4eniYny9nY=; b=QlPpIxDFGnJwaSOtOSrH35Nvk5Z0lAXHXPvaBgf7tsln0em+jTNKyRVNppz6LN6azc lr3rD4rMsfq5oD1e559cWSDj7opb316z1rGuSq4vv9RiLsWRGughQ6AK9jcBMBtc2mdd mAdcbvfLQ3i8evRZzYIbW7UnFA/rFXD6apKkvcWFtFd5/CNWh7DT/9sCztFUYHU9pz6C 2VINCHCj8/q1zmByCW4CRNscxKbwjMbVYP+p833ZZxTWCDLf/LmIwf6Lf2DJvZgAyHVD ikKcVC/BsrlplYWES09e6amT/lEmdHfrhp4CRvaZBEgydpWsaV9tspVmAyrPWL0f3OWV +Zcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=n2qyUY5cdUeK3ry72ZyfGwSOvV29bEp3a4eniYny9nY=; b=RXVcUV09IK3+QJcmm7GAwmQbI93mEWTbUMfrx9II0exqbgUmW3YtPQzo9cAtFyGHUw X4THAGjuNKSTAF+tKqaxsgg/SArZ8M72E4FZZ//Swzbsh9ecfTwmlEqxvdssazxYM6df GAdbRfO69bZkpJwvBoFGbwFSCIh5oq0hH9PiUtbvIELA/cz235diolJ0BmCeaJnoHzol 9BkvkFRSETAlPTZhBk2GTVsWRNecnrKg9GW/EpZdHUZktcxWwmAL/AOuYnPdxXBcDStb 8kqcdR3M/xZyUDx7oZSIZeh7G72j5nhFPhA5CBFck0ufDoLbOeRrRO4HHS+oqgxFY2qB RBAw== X-Gm-Message-State: AOPr4FVtG/NcTLTQfa4S106Y60pZZERvkDYvo40glTVPpETGkivN3mpWsWPWV+rHUI3B8pcQQaIu7OgwrT+otg== MIME-Version: 1.0 X-Received: by 10.50.160.41 with SMTP id xh9mr18948783igb.64.1461866235256; Thu, 28 Apr 2016 10:57:15 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.19.218 with HTTP; Thu, 28 Apr 2016 10:57:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 10:57:15 -0700 X-Google-Sender-Auth: PvNgpV5x-iHhoJXRNvN0NIP4AeQ Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:57:18 -0000 At Wed, 27 Apr 2016 18:18:47 -0700, Bob Hinden wrote: > I would like to get closure on the question if inserting IPv6 extension h= eaders is allowed or not, and should this be a clarification in rfc2460bis.= This topic was discussed in Buenos Aires and on the mailing list. > > The relevant text from Section 4 "IPv6 Extension Headers" in > > Extension headers must never be inserted by any node other than the > source of the packet. IP Encapsulation must be used to meet any > requirement for inserting headers, for example, as defined in > [RFC2473]. > > This text was added to the draft in version =E2=80=9401 published on 2 No= vember 2015. > > The question is if this text was the original intent of rfc2460. That wo= uld allow it to be part of rfc2460bis going to Internet Standard. If it is= a change, then it should not be included. > > In my personal view (as one of the authors of rfc2460), I think it > was the original intent to not allow extension headers to be > inserted. [...] > However, I do not think leaving the rfc2460bis text in an ambiguous > state on this topic is a good idea. I agree with these: The 'personal view' of yours also matches my interpretation of the original intent. I also agree it's better to describe it explicitly. I have one additional question: what about removing an extension header? The rationale for PMTU doesn't apply in this case, but it would generally break AH, and I thought the "original intent" also includes prohibiting non-source nodes from removing an extension header. > Note, I think it would be fine for someone to document how to do > extension header insertion, as long as they describe how it works, > and how to deal issues like MTU problems. This can be be an update > to rfc2460bis (after it is published). I'm fine with this. -- JINMEI, Tatuya From nobody Thu Apr 28 11:41:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3DA12D51E for ; Thu, 28 Apr 2016 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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_Wke9sgkHK0 for ; Thu, 28 Apr 2016 11:41:08 -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 592C612D1EC for ; Thu, 28 Apr 2016 11:41:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2604B2009E for ; Thu, 28 Apr 2016 14:45:56 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 010376375A for ; Thu, 28 Apr 2016 14:41:06 -0400 (EDT) From: Michael Richardson To: IPv6 List Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 18:41:10 -0000 --=-=-= Content-Type: text/plain Bob Hinden wrote: > I would like to get closure on the question if inserting IPv6 extension > headers is allowed or not, and should this be a clarification in > rfc2460bis. This topic was discussed in Buenos Aires and on the > mailing list. I read the read of the thread. There are three issues, I think, why back in 1995 we declared that no headers shall be inserted or removed. 1) ICMP errors going to the wrong place. Are we specifically talking about ICMP too big messages, or are there other ICMP errors that the header-inserting router needs to know about? 2) causing packets to grow too much, causing PMTUD issues 3) breaking AH in transit. While AH can deal with mutable headers, it can not deal with new extension headers being added/deleted. While the SRH-types who want to insert headers seem to also intend to remove them before delivery, I'm concerned that this process might at times not be byte-for-byte identical, yet be semantically equivalent. (I don't have an example right now) My initial take is that PMTUD via ICMP message is broken, and isn't getting fixed anytime soon. PLPMTUD works well (once you get it turned on), we just need a way to generalize it to non-TCP/non-SCTP users, and provide it as a kernel service to applications. If we remove PMTUD as a reason, and we can believe that AH won't be corrupted, then I think going from MUST NOT to SHOULD NOT is reasonable. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVyJZP4CLcPvd0N1lAQLqIggAljPzGijBJPJfA1ABgJAxDQ5h9+ZnUpek YXl0hUFRAIEHtJfjZ8QAE43z6sbCppf0Mk0wTS9Y5RdyuxvIR/VMmlEzHruqI5nb /iO/xwCB3Yr5kq3WXpkfJjtdj9PMSL1pfedbU960JHcLFOg+cP/k/ZGmz1SHSClk CFAJWNLFYuRQSgU40fXlI2dkWe8zPjCVtBQhjbV3K/Yjihk4EiAtBd32wP7k3iQ3 xRv7aVHvWbCezvf4UNsrNQbbKC880NMUgcOvsbeFEWYXUTlhG9wm5LP31ltBEBwv /JSOUkarof6Zx2N8pbFvLiPKRsNROIcydgFSm94pObRLxXSi5wtADA== =aYxf -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 28 15:11:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4B12D8B6 for ; Thu, 28 Apr 2016 15:11:08 -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, 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 jK685GEv-bHT for ; Thu, 28 Apr 2016 15:11:06 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 EF4D612D88C for ; Thu, 28 Apr 2016 15:11:05 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t10so149468566ywa.0 for ; Thu, 28 Apr 2016 15:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JvfhMMXw+MX9SSWjG8/MfrxJpOvDeVMicvYUFd+AiY8=; b=cYWylCwvqMvQEj7JgRjnzbdS+i1yl/h0GfYA/Keus0zc6sV1Ti1TFL/S16Yq0hoK4s cjuqqMIwZRf681FZMfraXG3+eYwvHWsG3Dq618Wkj8ZDkDg0tfkE+CZFE1UEp07m6dWb EXaQWYq6EhTENNTMleVNkEclpu+MmL0R3h+4/MwNXT2qWziYJyZtyLgmJrEHL3VR9LSv RDZC1dEmr2r7utEnfKQGVCN0gKCepxenzJrpRhZhfeYA/T3bDIpZx4GBBvHyelz8JeG5 1FV4bsqBizm7ZoS8lUHKpEcN2WbfZBcib4vPhKNwnoYwb+XjyUSird0oc6wq2z/fFqfz AykA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JvfhMMXw+MX9SSWjG8/MfrxJpOvDeVMicvYUFd+AiY8=; b=IsWnxb8AwX9wC9RtZORwbmiNuDzp4Vb6bA24R4EdQfzBqOWD9n13A5ASgD3pCMLoXm vaKyJNK9YAf4F6JJEbOY2V6N3OIxI2yNN2MCQfYdiiuARvkM33h4FEhKZK9kUK3cwXgW L1wKSWgj0oyB/YdsGE/NBQyHabmg2Y/PZEexApsXPktq4RS+OAdnRu8A1pz/a1F8R9Mb 1vffImcazybA8ZY4C+WPuFsRhah4HMWE9i0t/+qJEqs61lwUjM/bQYl6bu4FG014ew2e pQ05F1B0vtdE3PRefcF1+PCrOFsc2WGMszUUDQhlQK7CUnmY7snFDnRkw9yqqWjuuAz3 N0Iw== X-Gm-Message-State: AOPr4FUthW0vdjw/SckxqaG3+SgFUuJS3yS0mFcnzUeyC9UVA+uwv1Utx7n6+W8RbJAbLJvYPzEAjKMsEnL+jQ== MIME-Version: 1.0 X-Received: by 10.176.6.161 with SMTP id g30mr9471187uag.142.1461881465064; Thu, 28 Apr 2016 15:11:05 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Thu, 28 Apr 2016 15:11:04 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Thu, 28 Apr 2016 15:11:04 -0700 (PDT) In-Reply-To: <12014.1461868866@obiwan.sandelman.ca> References: <12014.1461868866@obiwan.sandelman.ca> Date: Fri, 29 Apr 2016 08:11:04 +1000 Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: Mark Smith To: Michael Richardson Content-Type: multipart/alternative; boundary=94eb2c047ca06dd2de053192cdf1 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:11:08 -0000 --94eb2c047ca06dd2de053192cdf1 Content-Type: text/plain; charset=UTF-8 On 29 Apr 2016 4:41 AM, "Michael Richardson" wrote: > > > Bob Hinden wrote: > > I would like to get closure on the question if inserting IPv6 extension > > headers is allowed or not, and should this be a clarification in > > rfc2460bis. This topic was discussed in Buenos Aires and on the > > mailing list. > > I read the read of the thread. > There are three issues, I think, why back in 1995 we declared that > no headers shall be inserted or removed. > > 1) ICMP errors going to the wrong place. > Are we specifically talking about ICMP too big messages, or are there > other ICMP errors that the header-inserting router needs to know about? > > 2) causing packets to grow too much, causing PMTUD issues > > 3) breaking AH in transit. > While AH can deal with mutable headers, it can not deal with > new extension headers being added/deleted. > While the SRH-types who want to insert headers seem to also intend > to remove them before delivery, I'm concerned that this process might > at times not be byte-for-byte identical, yet be semantically equivalent. > (I don't have an example right now) > 4) troubleshooting modifications that cannot or cannot easily be attributed to a specific node can be very time-consuming, require out of hours work and are likely to require potentially disruptive packet capturing within or downstream of each network element that could have modified the packet (assuming it is possible to access that NE or link). 5) the source address has lost its semantics if more than one node is responsible for the contents of the packet (within a layer) - it is now a multi-source packet, yet only one source is recorded. This is what makes troubleshooting hard, and causes things like PMTUD to fail - the inability to completely attribute creation or modification of the parts of the packet to the respective sources. In the encapsulation model, devices that add to a packet(/frame) also add a source identification field to record their identity as the source of those additions. Regards, Mark. > > My initial take is that PMTUD via ICMP message is broken, and isn't getting > fixed anytime soon. PLPMTUD works well (once you get it turned on), we just > need a way to generalize it to non-TCP/non-SCTP users, and provide it as a > kernel service to applications. > > If we remove PMTUD as a reason, and we can believe that AH won't be > corrupted, then I think going from MUST NOT to SHOULD NOT is reasonable. > > -- > 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 > -------------------------------------------------------------------- > --94eb2c047ca06dd2de053192cdf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Apr 2016 4:41 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>
>
> Bob Hinden <bob.hinden@gmai= l.com> wrote:
> =C2=A0 =C2=A0 > I would like to get closure on the question if inse= rting IPv6 extension
> =C2=A0 =C2=A0 > headers is allowed or not, and should this be a cla= rification in
> =C2=A0 =C2=A0 > rfc2460bis.=C2=A0 This topic was discussed in Bueno= s Aires and on the
> =C2=A0 =C2=A0 > mailing list.
>
> I read the read of the thread.
> There are three issues, I think, why back in 1995 we declared that
> no headers shall be inserted or removed.
>
> 1) ICMP errors going to the wrong place.
> =C2=A0 =C2=A0Are we specifically talking about ICMP too big messages, = or are there
> =C2=A0 =C2=A0other ICMP errors that the header-inserting router needs = to know about?
>
> 2) causing packets to grow too much, causing PMTUD issues
>
> 3) breaking AH in transit.
> =C2=A0 =C2=A0While AH can deal with mutable headers, it can not deal w= ith
> =C2=A0 =C2=A0new extension headers being added/deleted.
> =C2=A0 =C2=A0While the SRH-types who want to insert headers seem to al= so intend
> =C2=A0 =C2=A0to remove them before delivery, I'm concerned that th= is process might
> =C2=A0 =C2=A0at times not be byte-for-byte identical, yet be semantica= lly equivalent.
> =C2=A0 =C2=A0(I don't have an example right now)
>

4) troubleshooting modifications that cannot or cannot easil= y be attributed to a specific node can be very time-consuming, require out = of hours work and are likely to require potentially disruptive packet captu= ring within or downstream of each network element that could have modified = the packet (assuming it is possible to access that NE or link).

5) the source address has lost its semantics if more than on= e node is responsible for the contents of the packet (within a layer) - it = is now a multi-source packet, yet only one source is recorded. This is what= makes troubleshooting hard, and causes things like PMTUD to fail - the ina= bility to completely attribute creation or modification of the parts of the= packet to the respective sources.

In the encapsulation model, devices that add to a packet(/fr= ame) also add a source identification field to record their identity as the= source of those additions.

Regards,
Mark.

>
> My initial take is that PMTUD via ICMP message is broken, and isn'= t getting
> fixed anytime soon.=C2=A0 PLPMTUD works well (once you get it turned o= n), we just
> need a way to generalize it to non-TCP/non-SCTP users, and provide it = as a
> kernel service to applications.
>
> If we remove PMTUD as a reason, and we can believe that AH won't b= e
> corrupted, then I think going from MUST NOT to SHOULD NOT is reasonabl= e.
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> =C2=A0-=3D IPv6 IoT consulting =3D-
>
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--94eb2c047ca06dd2de053192cdf1-- From nobody Thu Apr 28 15:20:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7318912D908 for ; Thu, 28 Apr 2016 15:20:13 -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 WREC-FnEzXEL for ; Thu, 28 Apr 2016 15:20:11 -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 5EB6512D57D for ; Thu, 28 Apr 2016 15:20:11 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g133so131563754ywb.2 for ; Thu, 28 Apr 2016 15:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=nSPZw0b4CTHm41k+DY3W3fzfL61AmScgrQE84NVzGnU=; b=fdEcD3u7ZTud5RkPZRF00dX5T7fuDIPb9xO+CdHCVJmlbkYcmS6IfiW5VQvu7ckekS vPyx5ASDwqhADKHj3rhjZrh2V/qI9AoHsm2ZrtdJKrnOtZ0dHXsRiYkYgKgCrD+vPkar 9B1zxPGGd/bC02AoNoSSkolSXXnRez+FrtaY2SIeLddPmIwFZbDCCztzXTb9aPUTc6iB AJUo6P0Jbwo9mS8wHq7VyXaB2SOqBnAhQmQHG0f4mGo98tygEzt1oJvnziIv18fA3Owj ipMgT30oKu4Crd4KZGZJj827JqLlTba9fkMLymckoB3dL5JyDyFMpWZYbxRs9HJi9ow2 Ehwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=nSPZw0b4CTHm41k+DY3W3fzfL61AmScgrQE84NVzGnU=; b=ZM4iVZk+0rU42oF5ocDKfsw2q3qQIy4TEUDBlXhU6OWlkECWRh8VqVCm8xCZO3/AE2 /Jz3ATKaUdahqlyzo5rpf3NFTzW8n3K3ctLJy7t/QCuXCUtFZaLtBcafshDjWQ5m2Tp3 4q8nmXYObGAG/xzWiSvIW3bmmqBNJYVA4XBJNoVafnnqi3OkpghGiKIj3xEX+6SQgVhR AIO+mlcnzOSKSHXMFEj8s2n5Z4PhBFOsWAbEHiHBtK08GRZIPcXOQoXeWsEuawubLgP9 p5KmvmXMKeqbTOTKva+8chCuILbcaBorGe5G29siO/NDg+59TFi4q3zuR7jKLR/FS/vA qvFQ== X-Gm-Message-State: AOPr4FWKqE0A3hw3nhd/2P8Vylesm5p+j/UsZxQpDpn6jR5R5wQ06GluEU7uOlYwi1/dLg== X-Received: by 10.129.27.6 with SMTP id b6mr11407717ywb.205.1461882010587; Thu, 28 Apr 2016 15:20:10 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f129sm5894960ywd.10.2016.04.28.15.20.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 15:20:08 -0700 (PDT) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0F203F91-8BDB-4468-B953-6C6B9D3D21D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 28 Apr 2016 15:20:05 -0700 Message-Id: References: To: Tom Herbert X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:20:13 -0000 --Apple-Mail=_0F203F91-8BDB-4468-B953-6C6B9D3D21D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom, > On Apr 28, 2016, at 8:45 AM, Tom Herbert wrote: >=20 > On Wed, Apr 27, 2016 at 6:18 PM, Bob Hinden = wrote: >> Hi, >>=20 >> I would like to get closure on the question if inserting IPv6 = extension headers is allowed or not, and should this be a clarification = in rfc2460bis. This topic was discussed in Buenos Aires and on the = mailing list. >>=20 >> The relevant text from Section 4 "IPv6 Extension Headers" in = >>=20 >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >>=20 >> This text was added to the draft in version =E2=80=9401 published on = 2 November 2015. >>=20 >> The question is if this text was the original intent of rfc2460. = That would allow it to be part of rfc2460bis going to Internet Standard. = If it is a change, then it should not be included. >>=20 >> In my personal view (as one of the authors of rfc2460), I think it = was the original intent to not allow extension headers to be inserted. = My thinking is that not allowing extension headers to be inserted is = related the design of IPv6 that includes only supporting fragmentation = at the source. IPv4 allows the addition of options resulting in = changing the header length, but it includes per-hop fragmentation so any = resulting MTU issues can be dealt with. Even IPv4 fragments can be = fragmented. I think it is a consequence of IPv6 not allow per-hop = fragmentation, that extension headers were not intended to be inserted = along the path to the destination. >>=20 >> Note, I think it would be fine for someone to document how to do = extension header insertion, as long as they describe how it works, and = how to deal issues like MTU problems. This can be be an update to = rfc2460bis (after it is published). >>=20 >> However, I do not think leaving the rfc2460bis text in an ambiguous = state on this topic is a good idea. >>=20 >> Comments? >>=20 >=20 > Bob, >=20 > I agree that this should be clarified and extension headers cannot be > inserted that change the length. It might be reasonable to allow > insertion if it doesn't change the packet length though-- specifically > I am thinking that a host might be able to set PadN to make space that > can be overwritten in the path for inserted EHs. This allows insertion > without changing the packet length or meaning of existing headers. This is possible, but would have to be documented including how a host = would know to do that. I don=E2=80=99t think that is appropriate for = rfc2460bis. >=20 > Also, per: >=20 > "IP Encapsulation must be used to meet any requirement for inserting > headers, for example, as defined in [RFC2473]. >=20 > I don't think proposing encapsulation as an alternative to insertion > is normative. It won't necessarily have the same effect and it > introduces issues regarding encapsulation. I think this statement can > just be omitted from rfc2460bis without loss of clarity. Perhaps changing the text to citing encapsulation as an example would = work. Other views? Bob >=20 > Tom >=20 >> Thanks, >> Bob >>=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=_0F203F91-8BDB-4468-B953-6C6B9D3D21D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXIoyWAAoJEK7rdBF357uo+8AH/1etcczHLGFqxZPnFYZJyuiP 7AQGrfH1DOIiL0r9338QwieDS2X/dVIhCo1CwghQzcc+vqHZzo+r6yCbUKwN1ohv FXTDmltBY9ed00Qpo0qblY2QEzExnaFJXtcOPGFhVfZx87xLjtgzMNQg1ehtSoLw vGH1fg8BpkmpryrSELiSnUUkrMXpH3dpBJEWszFlrSmkkhs2/ykqULDvNmgaScE+ xomJFnK4nhnbd2ltApqJGB43Svx9495LiSVt2FWqjp/OdLIk+ntTzaYf/EGju+EH tVrKf5HxA42P4TTAj7ZJ/kU+qcTPd1MIefXFsQI0GATYXfGWqg8H7aJP9EeCxtE= =k+Z6 -----END PGP SIGNATURE----- --Apple-Mail=_0F203F91-8BDB-4468-B953-6C6B9D3D21D8-- From nobody Thu Apr 28 15:24:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A75012D54D for ; Thu, 28 Apr 2016 15:24: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 dzjD47v-HINK for ; Thu, 28 Apr 2016 15:24:40 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002: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 13EBF12D501 for ; Thu, 28 Apr 2016 15:24:40 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g133so131742705ywb.2 for ; Thu, 28 Apr 2016 15:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=GyGXM7G6xJQi0N0L4ix3x4xIecAsu0uXSm8KR7SX6sY=; b=BQYoWWFT8Xaft1FE6AouTs3tZSqMlOvzXjKWgfOBzWoIa8y1fCEE3M0i18f/NhppHd WoC/nN9lgaPWw8b9M6UxT7f2a6/o10QWbHGyExPbj/v5qorIfoVTwZBXL9i5gHnJhPH4 fbyQVznICoRiaOa4Z4OwcKKF+vh4JxNaCvvXd+HN+Ldp+CB+eq0vdB9YvmQ4en8YH0xi 8lhxVCtH01XRCknRmmwjczlE0tBn4+2lOMYI8dOOYHKLj8njU/6Lndg+vxQS41HxOLJQ FJSHAb8GgHBHjtmcXG5uYVZGlsC7llLqLETQFGDONTeVhKz63P1rP+cCHyiBb2okxn2F 9Xew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=GyGXM7G6xJQi0N0L4ix3x4xIecAsu0uXSm8KR7SX6sY=; b=L3kJfO+BVx6o7ruUXKIZFbHcRGXL4zcFQEJ3BKYAxVYR6898PDAuXeb5Kf/Ac+xrL/ VpdiHpRYx4yNB+mA//cV/lZgl4N+JuAJsq+fx5ktxxGcv7e4RorK1wSaPgtKiZLf7zHi fks2E7NpG6mpowYxodIgu6Dgm9pGdIX+DU7V51xKWDctBI+E310f3mZSJRmdFzu1sdBC C+thQz8VImzikzAyqsnR02t/tQZA14x1Nt1Gdk6dQ3qu/IDzz2vPae1j/d4xxwZuoyR7 d5kNyuy5ntQZuIe+YIp7C+8O1pEtegwzLzpou1WObQlwZ6AFsWX7O24YG0iRGx5uR7hR Jz3Q== X-Gm-Message-State: AOPr4FU9DDaqTbQeBVricK0UnkXZhuBbZwO9iikWTtVlFeJr4RsxINdo9dksxYmcFmeZPg== X-Received: by 10.37.49.69 with SMTP id x66mr8887503ybx.181.1461882279409; Thu, 28 Apr 2016 15:24:39 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id p66sm5868260ywc.40.2016.04.28.15.24.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 15:24:38 -0700 (PDT) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_486F0364-5E1E-4B45-B8C4-4AF8EAA85889"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 28 Apr 2016 15:24:36 -0700 Message-Id: <6E667844-B4C1-4363-9CAF-13B70D713945@gmail.com> References: To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:24:42 -0000 --Apple-Mail=_486F0364-5E1E-4B45-B8C4-4AF8EAA85889 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei-san, > On Apr 28, 2016, at 10:57 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Wed, 27 Apr 2016 18:18:47 -0700, > Bob Hinden wrote: >=20 >> I would like to get closure on the question if inserting IPv6 = extension headers is allowed or not, and should this be a clarification = in rfc2460bis. This topic was discussed in Buenos Aires and on the = mailing list. >>=20 >> The relevant text from Section 4 "IPv6 Extension Headers" in = >>=20 >> Extension headers must never be inserted by any node other than the >> source of the packet. IP Encapsulation must be used to meet any >> requirement for inserting headers, for example, as defined in >> [RFC2473]. >>=20 >> This text was added to the draft in version =E2=80=9401 published on = 2 November 2015. >>=20 >> The question is if this text was the original intent of rfc2460. = That would allow it to be part of rfc2460bis going to Internet Standard. = If it is a change, then it should not be included. >>=20 >> In my personal view (as one of the authors of rfc2460), I think it >> was the original intent to not allow extension headers to be >> inserted. [...] >=20 >> However, I do not think leaving the rfc2460bis text in an ambiguous >> state on this topic is a good idea. >=20 > I agree with these: The 'personal view' of yours also matches my > interpretation of the original intent. I also agree it's better to > describe it explicitly. >=20 > I have one additional question: what about removing an extension > header? The rationale for PMTU doesn't apply in this case, but it > would generally break AH, and I thought the "original intent" also > includes prohibiting non-source nodes from removing an extension > header. I was planning to come back to that question, after we get through the = inserting extension header question. Thanks, Bob >=20 >> Note, I think it would be fine for someone to document how to do >> extension header insertion, as long as they describe how it works, >> and how to deal issues like MTU problems. This can be be an update >> to rfc2460bis (after it is published). >=20 > I'm fine with this. >=20 > -- > JINMEI, Tatuya --Apple-Mail=_486F0364-5E1E-4B45-B8C4-4AF8EAA85889 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXIo2kAAoJEK7rdBF357uoJfAH/jAc+qHmMCXDkfNodkyrKkPZ 01kUgGCkOySyIOitwteXC6CDsbgnH/P5qId2KBrGIbJE2DFP+baq8lsEEDlwRx+k CjlpkSe4Si4EsVLlUJgkZEAd4CqEwHGHK0J1AmYJG2x4nuGDq86wlCZbo7TusJSr Hqr6nwUgyJ0PtPALK2O+OHVFRTLexDJqTzu10x5+Jo3GvCZS0Z0MNyYxQON1KNE0 WjFoRwxnwKhWwuV/gXxgfK+TxqPg+XYiz9MEys4WFXaivPC9n/1PBx6CXjDcvPXa irP4PKZKGsgwcAbaN+SuvNN1wU8c9eSVlQ5EJ/nCu6JyW6G5/UiMhOYlW0tBqNo= =ouGu -----END PGP SIGNATURE----- --Apple-Mail=_486F0364-5E1E-4B45-B8C4-4AF8EAA85889-- From nobody Thu Apr 28 15:27:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83812D891 for ; Thu, 28 Apr 2016 15:27:09 -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, 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 5GJ3w1ZGN_EZ for ; Thu, 28 Apr 2016 15:27:07 -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 D907A12D501 for ; Thu, 28 Apr 2016 15:27:06 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j74so131818524ywg.1 for ; Thu, 28 Apr 2016 15:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=M7XFFJdqUO+JJkf54KA2u1AMoxbv8WaPmecPja5PH2k=; b=AVn2eL07o4pCuxNtHkLeou21MH9gTDxiQWu/UOCE5EYN083OSYR/GrFtqj1zPAE6ys I6EJTfHn2NOwviPEXHps5uypvg23Wn76ptEy8k1yKGiqDkYCnSNaSDfb9+CipxlMTcBc CNM2MKsSRojBuuMmectjUGnMmxx4vBePY/NgeyM+zEwZePR62bmpGxQsvzC0Li69wYE1 TygoFqsKy9sSKRfwT0a44PWKAbIU7oDzUldA8SO3lidTtL7j8OlRlYr4BHi5K4V3X7rC xs+9H2hHiKfSrFibcsb6NTq/z/TDQ1KQHHnRQT0eBoGVoFNuG9263AEKg31cVmcuz4zW xKWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=M7XFFJdqUO+JJkf54KA2u1AMoxbv8WaPmecPja5PH2k=; b=CSHLFM8/U08RpGUjC3fr37GDZ6RumUtQcXh/B6CvlUVn6HdYQvR6bSDS/e3tzWkGyP wMeZgIHL3WNsn/LE5NEcYG8xwUUIAMpfXZAFDXhLg9aLgM6w4CFaoztOtPdNhUPW+Tar vVoE17Wi55lbDp3qxXAJMEiLsWzDHDPuwAjt02FGhYejbQ/ufdXVZFbruJtiQp3wkEvW Tv41QhsBGyOYmp+QTgb3axWnTL4Tgk5uEBx74bRdgYXzuhfLjTzCo8MQWKUKKBXumTP4 gWRoHsnypNYbBufRRPAS9kV/37bP7FE7whs++xEy5w4J84e38+CTo96e1UxBCgwGU3mS p8Kg== X-Gm-Message-State: AOPr4FUQ2sgjN4Io85Q4iOTlRJrjd3Ki73k4AfintoMaYrYxcy4i+5gEhCpXkwIcw7pqCO1GpGlxzo1h4dRzqw== MIME-Version: 1.0 X-Received: by 10.159.37.72 with SMTP id 66mr9294352uaz.111.1461882426150; Thu, 28 Apr 2016 15:27:06 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Thu, 28 Apr 2016 15:27:06 -0700 (PDT) Received: by 10.159.41.196 with HTTP; Thu, 28 Apr 2016 15:27:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Apr 2016 08:27:06 +1000 Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: Mark Smith To: Bob Hinden Content-Type: multipart/alternative; boundary=94eb2c122f72b6d86c05319306e1 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:27:09 -0000 --94eb2c122f72b6d86c05319306e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 Apr 2016 8:20 AM, "Bob Hinden" wrote: > > Tom, > > > On Apr 28, 2016, at 8:45 AM, Tom Herbert wrote: > > > > On Wed, Apr 27, 2016 at 6:18 PM, Bob Hinden wrote: > >> Hi, > >> > >> I would like to get closure on the question if inserting IPv6 extension headers is allowed or not, and should this be a clarification in rfc2460bis. This topic was discussed in Buenos Aires and on the mailing list. > >> > >> The relevant text from Section 4 "IPv6 Extension Headers" in > >> > >> Extension headers must never be inserted by any node other than the > >> source of the packet. IP Encapsulation must be used to meet any > >> requirement for inserting headers, for example, as defined in > >> [RFC2473]. > >> > >> This text was added to the draft in version =E2=80=9401 published on 2 November 2015. > >> > >> The question is if this text was the original intent of rfc2460. That would allow it to be part of rfc2460bis going to Internet Standard. If it is a change, then it should not be included. > >> > >> In my personal view (as one of the authors of rfc2460), I think it was the original intent to not allow extension headers to be inserted. My thinking is that not allowing extension headers to be inserted is related the design of IPv6 that includes only supporting fragmentation at the source. IPv4 allows the addition of options resulting in changing the header length, but it includes per-hop fragmentation so any resulting MTU issues can be dealt with. Even IPv4 fragments can be fragmented. I think it is a consequence of IPv6 not allow per-hop fragmentation, that extension headers were not intended to be inserted along the path to the destination. > >> > >> Note, I think it would be fine for someone to document how to do extension header insertion, as long as they describe how it works, and how to deal issues like MTU problems. This can be be an update to rfc2460bis (after it is published). > >> > >> However, I do not think leaving the rfc2460bis text in an ambiguous state on this topic is a good idea. > >> > >> Comments? > >> > > > > Bob, > > > > I agree that this should be clarified and extension headers cannot be > > inserted that change the length. It might be reasonable to allow > > insertion if it doesn't change the packet length though-- specifically > > I am thinking that a host might be able to set PadN to make space that > > can be overwritten in the path for inserted EHs. This allows insertion > > without changing the packet length or meaning of existing headers. > > This is possible, but would have to be documented including how a host would know to do that. I don=E2=80=99t think that is appropriate for rfc24= 60bis. > > > > > Also, per: > > > > "IP Encapsulation must be used to meet any requirement for inserting > > headers, for example, as defined in [RFC2473]. > > > > I don't think proposing encapsulation as an alternative to insertion > > is normative. It won't necessarily have the same effect and it > > introduces issues regarding encapsulation. I think this statement can > > just be omitted from rfc2460bis without loss of clarity. > > Perhaps changing the text to citing encapsulation as an example would work. > +1 Ideally an example where an EH is added between the outer IPv6 header and the inner one - actually GRE would probably do as one example. > Other views? > > Bob > > > > > Tom > > > >> 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 > -------------------------------------------------------------------- > --94eb2c122f72b6d86c05319306e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 Apr 2016 8:20 AM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
> Tom,
>
> > On Apr 28, 2016, at 8:45 AM, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Wed, Apr 27, 2016 at 6:18 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
> >> Hi,
> >>
> >> I would like to get closure on the question if inserting IPv6= extension headers is allowed or not, and should this be a clarification in= rfc2460bis.=C2=A0 This topic was discussed in Buenos Aires and on the mail= ing list.
> >>
> >> The relevant text from Section 4 "IPv6 Extension Headers= " in <draft-ietf-6man-rfc2460bis-04.txt>
> >>
> >>=C2=A0 =C2=A0Extension headers must never be inserted by any n= ode other than the
> >>=C2=A0 =C2=A0source of the packet.=C2=A0 IP Encapsulation must= be used to meet any
> >>=C2=A0 =C2=A0requirement for inserting headers, for example, a= s defined in
> >>=C2=A0 =C2=A0[RFC2473].
> >>
> >> This text was added to the draft in version =E2=80=9401 publi= shed on 2 November 2015.
> >>
> >> The question is if this text was the original intent of rfc24= 60.=C2=A0 That would allow it to be part of rfc2460bis going to Internet St= andard.=C2=A0 If it is a change, then it should not be included.
> >>
> >> In my personal view (as one of the authors of rfc2460), I thi= nk it was the original intent to not allow extension headers to be inserted= .=C2=A0 My thinking is that not allowing extension headers to be inserted i= s related the design of IPv6 that includes only supporting fragmentation at= the source.=C2=A0 IPv4 allows the addition of options resulting in changin= g the header length, but it includes per-hop fragmentation so any resulting= MTU issues can be dealt with.=C2=A0 Even IPv4 fragments can be fragmented.= =C2=A0 I think it is a consequence of IPv6 not allow per-hop fragmentation,= that extension headers were not intended to be inserted along the path to = the destination.
> >>
> >> Note, I think it would be fine for someone to document how to= do extension header insertion, as long as they describe how it works, and = how to deal issues like MTU problems.=C2=A0 This can be be an update to rfc= 2460bis (after it is published).
> >>
> >> However, I do not think leaving the rfc2460bis text in an amb= iguous state on this topic is a good idea.
> >>
> >> Comments?
> >>
> >
> > Bob,
> >
> > I agree that this should be clarified and extension headers canno= t be
> > inserted that change the length. It might be reasonable to allow<= br> > > insertion if it doesn't change the packet length though-- spe= cifically
> > I am thinking that a host might be able to set PadN to make space= that
> > can be overwritten in the path for inserted EHs. This allows inse= rtion
> > without changing the packet length or meaning of existing headers= .
>
> This is possible, but would have to be documented including how a host= would know to do that.=C2=A0 I don=E2=80=99t think that is appropriate for= rfc2460bis.
>
> >
> > Also, per:
> >
> > "IP Encapsulation must be used to meet any requirement for i= nserting
> > headers, for example, as defined in [RFC2473].
> >
> > I don't think proposing encapsulation as an alternative to in= sertion
> > is normative. It won't necessarily have the same effect and i= t
> > introduces issues regarding encapsulation. I think this statement= can
> > just be omitted from rfc2460bis without loss of clarity.
>
> Perhaps changing the text to citing encapsulation as an example would = work.
>

+1

Ideally an example where an EH is added between the outer IP= v6 header and the inner one - actually GRE would probably do as one example= .

> Other views?
>
> Bob
>
> >
> > Tom
> >
> >> 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
> -------------------------------------------------------------------- >

--94eb2c122f72b6d86c05319306e1-- From nobody Thu Apr 28 17:37:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAEF12D137 for ; Thu, 28 Apr 2016 17:37: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 jeiLx9pWIP4d for ; Thu, 28 Apr 2016 17:37:23 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 46E3B12D108 for ; Thu, 28 Apr 2016 17:37:23 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 77so8079920pfv.2 for ; Thu, 28 Apr 2016 17:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GMy57UuXLpxD8tHXLnaDFMhPfuiAq9U3XE8LYlhfyk8=; b=OpzO13KhqYKghWOU4cimZHfoltHo3sDjBGeMZ/O6OVNd3+y7uFnweUBgRML7uWkBHF JhgfVcuOd4IJEHelcaGN8JbCS+7dTjLyvPkPXAw2Fc4u8qmRJ6VIu5t4kibZtMJ0t+s2 efQ7OMmMldq3IpWmMvk7tXo6fUbqcz8XfWp7wr8wYNgKdyfFL9aAEqqtweasFuxX6IUP Q0dnG5duYRVrfb3VfnrcA+d6nWNizH+5gp5Vh7Zd8ui2w62kD1ofZgqn752iLh6KPQCp 7ZY2u69AUKo6ErQR+oHXxbtRqkiOZdW+cr7Ve9vlhgN5SthZUli0shoD1TMvJPoz6yMo dA4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=GMy57UuXLpxD8tHXLnaDFMhPfuiAq9U3XE8LYlhfyk8=; b=ksWmX88XlL+zhwKA40KtzqmB3zbcXk8Iy0EpIIzmHdTB7VKRVZjuFbJuRRbTwDmv3l TM125s2/nH0lrJpuoNvl6srk9yQzYKxOH1yEAbZB/pvJBQMCpaMTLEvuebOYZniOyikR FI619QMoj52cBXSzlbPGz6eTztnpiFGYju9G2FavBKlQcXkHkcaaJAxv0p8Z9xaWyjEV 7utiKQoWZseP0gHDhFxbfzOQ7Gw5X1r9FS5hK/rbpmNZEji16J/vck2bRGWhCMGljA5J jgcvS1LkaGpqZE7D7uDD6PoS5Pwb2LQrMtt+uZSfBwoq0puBaNJR8RNQwk1gWuuL0pxZ 7wIA== X-Gm-Message-State: AOPr4FWlEIOW0XR8AXY5sfpFH/qkgIXGC1odfMfZXmoMzxOtB3sWGfCNqzuSfcC2aKT7kA== X-Received: by 10.98.23.150 with SMTP id 144mr25093542pfx.96.1461890242850; Thu, 28 Apr 2016 17:37:22 -0700 (PDT) Received: from ?IPv6:2406:e007:61f2:1:28cc:dc4c:9703:6781? ([2406:e007:61f2:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ee5sm18306526pac.35.2016.04.28.17.37.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 17:37:21 -0700 (PDT) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] To: Ralph Droms , Ronald Bonica References: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 29 Apr 2016 12:37:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 00:37:25 -0000 On 29/04/2016 04:31, Ralph Droms wrote: > >> On Apr 28, 2016, at 12:23 PM 4/28/16, Ronald Bonica wrote: >> >> Bob, >> >> Maybe we should change the MUST NOT to a SHOULD NOT. The statement should explain that in many operational scenarios, insertion of extension headers by transit nodes can break PMTUD. However, in operational scenarios where this is not a problem, it is OK for transit nodes to insert extension headers. > > I think it should remain MUST NOT. In addition to PMTUD, there is the problem of inserted headers causing ICMP notifications being delivered to a host that is unaware of the case of the problem. Agreed. A "should not" would be a change, a "must not" is a clarification of intent. On 29/04/2016 04:34, Fernando Gont wrote: > mmm... I guess you don't need ietf permission to violate the specs in > your own walled garden? Since the protocol police have been very quiet recently, that is a fact of life. However, if we want to be explicit about it (after 2460bis) we could write it up. Diffserv already allows domain-specific packet mutations; the flow label tolerates mutations in certain circumstances. I don't see why we couldn't also describe the circumstances in which other header mutations are allowed. But first, define the precise meaning of "the open Internet." Brian From nobody Thu Apr 28 18:56:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730F212D0BE for ; Thu, 28 Apr 2016 18:56: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 k0UyYzq7PAQO for ; Thu, 28 Apr 2016 18:56:37 -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 5DEFB12B023 for ; Thu, 28 Apr 2016 18:56:37 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f89so94959492ioi.0 for ; Thu, 28 Apr 2016 18:56:37 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Ksb3DKxrXxnsGBJaJ1lpAATmUsX1bnvBJ2E2YdK9KUs=; b=yA0+k/lZcKqwragh57hc+0x+cdHihVk52x8GQ72NgAqflDqa0cf7D+OzqL0Cc4KibJ /bvedC98WbZ1Uq3pVj4Q983gxyQR3wOBUQjbCnO2oAhviW8RmhOdV1P5kgu4vBS3JakY M3X18SuAg8KBMcZm8GCMXR2gvamPqudxam18ZFbjpisQTtXwtljTGvVheE7z4h1xoCaS 43dwNkC9Rcufnl8tG1I1EDwCoxUBINPH15XUbYnQ0qgab02KwdzsciiHIZLiGFp1J4LJ qHCtdep1SIafZZtBrWD6hIy2g8jS21W0lKt54gVwjcXgSr5dfC6d/sA5yx+t/ahRQCvB /cfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Ksb3DKxrXxnsGBJaJ1lpAATmUsX1bnvBJ2E2YdK9KUs=; b=L7WxMoOWcRmYCALkKGfcTwbM9dM9eQlTaIrc48pDnk3o39SJpF5f2o7ivXoiAZNAyn 7WZMKFCkleCtZn7FmHCVmeIGlUbrfCZOUytd69RXvfuaee+n0QzsVLWANejrIRs5IsRm XEVJstpMUNNuHXO/27V6ZCp0WIBkMCUkK3uwlynnArch0hzdubJKufiTc/5BTyuoYrTz 9QrKSxGWsqaqdUMuL/V8MWsCltG1YS83pIV/dPm2jTGC9KEZveGkM8+GIQ0D1+fsDSB6 0IJjPNeP7/2Vy/4ZA3Ff4JRzyn+KOAvzgbKYJB1GHVycJdUaTZmmpuZNo20Kh630GrCc I1rg== X-Gm-Message-State: AOPr4FVBb9nupHvRiDbeSiQMjyp5zPVxhKVYi2OAeQ6yA97vOZ4FnSvaB2YqOzqk8g7OdddDPUrB4nakCw31/w== MIME-Version: 1.0 X-Received: by 10.107.9.74 with SMTP id j71mr22340762ioi.50.1461894996711; Thu, 28 Apr 2016 18:56:36 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Thu, 28 Apr 2016 18:56:36 -0700 (PDT) In-Reply-To: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> References: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> Date: Thu, 28 Apr 2016 18:56:36 -0700 Message-ID: Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] From: Tom Herbert To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 01:56:39 -0000 On Thu, Apr 28, 2016 at 9:31 AM, Ralph Droms wrote: > >> On Apr 28, 2016, at 12:23 PM 4/28/16, Ronald Bonica wrote: >> >> Bob, >> >> Maybe we should change the MUST NOT to a SHOULD NOT. The statement shoul= d explain that in many operational scenarios, insertion of extension header= s by transit nodes can break PMTUD. However, in operational scenarios where= this is not a problem, it is OK for transit nodes to insert extension head= ers. > > I think it should remain MUST NOT. In addition to PMTUD, there is the pr= oblem of inserted headers causing ICMP notifications being delivered to a h= ost that is unaware of the case of the problem. > +1. This is probably the biggest issue with inserting EH and really is a strong argument that generally header fields should not be modified in the network. If such a modification ever causes a packet loss in a downstream node I don't see any way to address the problem. The node making the modification would not receive an ICMP error or other feedback; the source node would get an ICMP for a packet with headers it didn't send and therefore can't take any corrective action either. Tom > - Ralph > >> >> = Ron >> >> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >>> Sent: Wednesday, April 27, 2016 9:19 PM >>> To: IPv6 List >>> Cc: Bob Hinden >>> Subject: Inserting Extension Headers or not [was rfc2460bis question ] >>> >>> Hi, >>> >>> I would like to get closure on the question if inserting IPv6 extension= headers >>> is allowed or not, and should this be a clarification in rfc2460bis. T= his topic >>> was discussed in Buenos Aires and on the mailing list. >>> >>> The relevant text from Section 4 "IPv6 Extension Headers" in >> 6man-rfc2460bis-04.txt> >>> >>> Extension headers must never be inserted by any node other than the >>> source of the packet. IP Encapsulation must be used to meet any >>> requirement for inserting headers, for example, as defined in >>> [RFC2473]. >>> >>> This text was added to the draft in version =E2=80=9401 published on 2 = November >>> 2015. >>> >>> The question is if this text was the original intent of rfc2460. That = would allow >>> it to be part of rfc2460bis going to Internet Standard. If it is a cha= nge, then it >>> should not be included. >>> >>> In my personal view (as one of the authors of rfc2460), I think it was = the >>> original intent to not allow extension headers to be inserted. My thin= king is >>> that not allowing extension headers to be inserted is related the desig= n of >>> IPv6 that includes only supporting fragmentation at the source. IPv4 a= llows >>> the addition of options resulting in changing the header length, but it >>> includes per-hop fragmentation so any resulting MTU issues can be dealt >>> with. Even IPv4 fragments can be fragmented. I think it is a conseque= nce of >>> IPv6 not allow per-hop fragmentation, that extension headers were not >>> intended to be inserted along the path to the destination. >>> >>> Note, I think it would be fine for someone to document how to do extens= ion >>> header insertion, as long as they describe how it works, and how to dea= l >>> issues like MTU problems. This can be be an update to rfc2460bis (afte= r it is >>> published). >>> >>> However, I do not think leaving the rfc2460bis text in an ambiguous sta= te on >>> this topic is a good idea. >>> >>> Comments? >>> >>> 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 > -------------------------------------------------------------------- > From nobody Fri Apr 29 00:29:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0512D0D9; Fri, 29 Apr 2016 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9DjVN2XTjOCL; Fri, 29 Apr 2016 00:29:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E68126FDC; Fri, 29 Apr 2016 00:29:20 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 25C8A180B73; Fri, 29 Apr 2016 09:29:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E3D9A1A007D; Fri, 29 Apr 2016 09:29:18 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 09:29:18 +0200 From: To: "Stefano Previdi (sprevidi)" Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAAAH55oQ//9xNoD//pPp8A== Date: Fri, 29 Apr 2016 07:29:17 +0000 Message-ID: <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com>, <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> In-Reply-To: <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/related; boundary="_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 07:29:24 -0000 --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: multipart/alternative; boundary="_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_" --_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we consider SRH insertion with IPv6 PHP, the original destination addres= s would be lost when removing the SRH, The packet reaches the egress with a DA that matches egress address, but no= other information how to forward the packet to its final destination [Orange logo] Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 13:46 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt There are many operators and use cases where, instead of encapsulation, srh= insertion is a far better option. In fact all current implementations are doing srh insertion. Still, from a spec perspective, the srh processis the same. s. -----Original Message----- From: rabah.guedrez@orange.com [rabah.gued= rez@orange.com] Received: Thursday, 28 Apr 2016, 12:58 To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.or= g [ipv6@ietf.org] Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com -----Message d'origine----- De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 12:31 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com > > > > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc : > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: > draft-ietf-6man-segment-routing-header-01.txt > > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >> >> Hi, >> I would like some clarification about the treatment of the SRH by an >> end point (the node that its loopback matches the DA field), >> >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. > > > the text is confusing but the semantic is correct ;-) > > the cleanup flag is processed so that the last segment receives a packet = without any SRH. > > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: > > C-flag: Clean-up flag. > Set when the SRH has to be removed from > the packet prior to forward the packet > towards the last segment. > > > >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >> >> But In section 4.3. >> >> You say that the node that decrements the Segments left pointer has >> to check if the c-flag is set when the new value of the segments left >> point is equal to zero, If the c-flag is set and the segments left >> pointer =3D=3D 0 then remove the SRH, >> >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. > > > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. > > >> Another question if a node receives a packet with the already segment >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) > > > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 > > MUST ignore the routing header and process the packet normally. This > is described in RFC2460 section 4.4 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah > >> >> >> Bests. >> >> >> >> >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >> >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If we consider SRH insert= ion with IPv6 PHP, the original destination address would be lost when remo= ving the SRH,

The packet reaches the eg= ress with a DA that matches egress address, but no other information how to= forward the packet to its final destination

 <= /p>

 <= /p>

3D"Orange<= /span>

 

Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

 

Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com

 

 <= /p>

De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 13:46
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-= 01.txt

 

There are many operators and use cases where, instead of encapsulation,= srh insertion is a far better option.

In fact all current implementations are doing srh insertion.

Still, from a spec perspective, the srh processis the same.

s.

-----Original Message-----
From: rabah.guedrez@oran= ge.com [rabah.guedrez@orange.com]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: spring@ietf.org [spring@i= etf.org]; ipv6@ietf.org [ipv6@ietf.org]
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.t= xt

You have said in a previous response to a question that the dra= ft only consider the encapsulation of client packet into a new IPV6 header = with SRH, and not adding only an SRH to an existing packet.
Which make sense especially for service providers who would prefer to tunne= l client traffic  (not modify the header of the client packets for sec= urity reasons).

If you only consider encapsulation, does keeping  c-flag relevant?
 
Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ
 
Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com  


-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 12:31
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt<= br>
On Apr 28, 2016, at 11:13 AM, r= abah.guedrez@orange.com wrote:
>
> Rabah Guedrez
> Th=E9sard
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
> 
> Phone: +33 2 96 07 18 56
> rabah.guedrez@orange.com
> 
>
>
> -----Message d'origine-----
> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :
> mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :
> spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:
> draft-ietf-6man-segment-routing-header-01.txt
>
>
>> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote:
>>
>> Hi,
>> I would like some clarification about the treatment of the  S= RH by an
>> end point (the node that its loopback matches the DA field),
>>
>> In section 3 :
>> You say that the
>> C-flag: Clean-up flag.  Set when the SRH has to be removed fr= om
>>         the packet when th= e packet reaches the last segment.
>
>
> the text is confusing but the semantic is correct ;-)
>
> the cleanup flag is processed so that the last segment receives a pack= et without any SRH.
>
> However, as you figured out, the processing of the C flag is done on t= he segment before last (penultimate segment). So, probably a more accurate = text would be:
>
>  C-flag: Clean-up flag. 
>          Set when the SRH= has to be removed from
>          the packet prior= to forward the packet
>          towards the last= segment.
>
>
>
>> Which mean that the last node inspects the SRH flags if the c-flag= is set, the node has to remove the SRH before sending the packet to its fi= nal destination.
>>
>> But In section 4.3.
>>
>> You say that the node that decrements the Segments left pointer ha= s
>> to check if the c-flag is set when the new value of the segments l= eft
>> point is equal to zero, If the c-flag is set and the segments left=
>> pointer =3D=3D 0 then remove the SRH,
>>
>> What is confusing for me is that the node that decrements the poin= ter is not the last node in the SR path (behavior similar to  PHP for = MPLS) , which I find in direct contradiction with section 3.
>
>
> you're right. The node that processes the cleanup flag is the penultim= ate segment, not the last.
>
>
>> Another question if a node receives a packet with the already segm= ent
>> left =3D=3D 0, what should that node do with the packet(e.g., drop= s it?)
>
>
> a node receiving a packet where:
>        1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0
>
> MUST ignore the routing header and process the packet normally. This <= br> > is described in RFC2460 section 4.4
>
> Rabah : >>>>>> do you consider that the c-flag must = be set for all the packets.


no.

The c-flag is to be set when you insert an SRH into an existing packet.

You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination.


> if we consider that setting the c-flag is not obligatory, then the&nbs= p; egress would receive an SRH with :
>            = ;   1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0


when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above.


>            = ;   The SRH has to be ignored based on RFC2460, is that corrects = ?


yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket).


> which in my opinion is not the intended behavior .


can you explain what you mean by "not the intended behavior" ?

s.


> s.
> Rabah
>
>>
>>
>> Bests.
>>
>>
>> <image001.gif>
>>
>> Rabah Guedrez
>> Th=E9sard
>> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>>
>> Phone: +33 2 96 07 18 56
>> rabah.guedrez@orange.c= om
>>
>>
>> __________________________________________________________________= ___
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d'= alteration, Orange decline toute responsabilite si ce message a ete altere,= deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender= and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified.
>> Thank you.
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>
>
> ______________________________________________________________________=
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
> exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_-- --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=406; creation-date="Fri, 29 Apr 2016 07:29:17 GMT"; modification-date="Fri, 29 Apr 2016 07:29:17 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhKAAyAIQQAP9mAP9wEP95IP+DMP+MQP+WUP+fYP+pcP+zgP+8j//Gn//Pr//Zv//iz//s 3//17////////////////////////////////////////////////////////////////ywAAAAA KAAyAAAF/iAkjmRpnmiqrmzrvnAsz3SdMkCu73zv/zoccEj8CYvI4jHJ9C2b0Nwz2pxSk9arUhvN coHer1PMDJN35rNUvWUP02r4WU6mi+1fPFev5V/9VIBdbm+EYIZGiDkIDA8KBIJFBAgPD5A5AwwQ DgcACQygBA2bBgAMCg4QCQADqaADmZsHArABQqkJo5CbCQgNBakAEA+5EAMNDwe6jQaaAkEAAhAK AAQQjBAB0agiwjgIENY4BeHDDKOlawOq1deaOZUGo94A4OIABuUOCPwE0ADxNDWDwArCggIPCEL4 Fi4VpXDICvh6tqZaQnbvTA0LtrBeuFYQdIE0qK0ippJNHBAsIKAg3KEv4ESEiZQjAAGUP2zo3Mmz p88WIQAAOw== --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_-- From nobody Fri Apr 29 00:49:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9213D12D593 for ; Fri, 29 Apr 2016 00:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 GEuiMx336nkZ for ; Fri, 29 Apr 2016 00:49:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9699812D515 for ; Fri, 29 Apr 2016 00:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23204; q=dns/txt; s=iport; t=1461916168; x=1463125768; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tL3F0rhAA+8BQqFx9RdhgDGtlHnR/1AaM38ss9Pu7c0=; b=INGXpU3rCIgMKnSZuiPO/CzBzdCHx+B6tTO2dgjQuE680mfQ7kXhMcPD kUcp7tKjEJ+4zWrUMagsqA9uYNOoeu+RBixCPQArYaXbvBY82GCVLeEbx KHWNiF0hZnVf/YOR5c7LuVo0NXENRGVVHbXdE58al3ghgcezvbTNdO/S8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgC9ESNX/4YNJK1YBg6DKlN9Bq4Fi?= =?us-ascii?q?2ABDYF2FwuFbQIcgQ44FAEBAQEBAQFlJ4RBAQEBBAEBASAROgsMBAIBCBABAQI?= =?us-ascii?q?BAQEBAgIjAwICAh8GCxQBAgYIAgQBDQUIiA0DEg6yAIxODYRLAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFXyFJYRLgkGBbhUQI4JGglYFh3QKhwiIWjEBhXuCd4MugW+?= =?us-ascii?q?Bbk6Df4hdhiSBLYdeAR4BAUKCAgMbgRA7bAGGaH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,550,1454976000"; d="scan'208";a="102761887" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 07:49:25 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3T7nP1f016434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 07:49:25 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 02:49:24 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 02:49:24 -0500 From: "Pascal Thubert (pthubert)" To: "Stefano Previdi (sprevidi)" , Tim Chown Subject: RE: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoP3Vrq5MIttC4kiRwdIgixwcgp+fD1OAgABkpwCAABTegIAAVjAAgAC0sEA= Date: Fri, 29 Apr 2016 07:49:13 +0000 Deferred-Delivery: Fri, 29 Apr 2016 07:48:39 +0000 Message-ID: <38f4fe6cc8b24aa1a98d09555783699a@XCH-RCD-001.cisco.com> References: <988dcc9d-102e-735c-68a8-3aaa46059786@gmail.com> <44D6DCEE-0BB9-48B1-A77C-316A85E2B96F@jisc.ac.uk> <95B92AF8-CA66-4380-8F38-480A896C1B6B@cisco.com> <4EE1E34F-67DD-4F09-98A4-64B19ACCF3E2@jisc.ac.uk> <2F3D6328-4C5C-489C-8E27-E7B1E05AFCBE@cisco.com> In-Reply-To: <2F3D6328-4C5C-489C-8E27-E7B1E05AFCBE@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 07:49:41 -0000 SGVsbG8gU3RlZmFubzoNCg0KSSBkbyBhZ3JlZSB3aXRoIHRoYXQuIA0KDQpTaW5jZSBoYXZpbmcg dG8gYWRkIElQIGVuY2Fwc3VsYXRpb24gaXMgcmVhbGx5IGRhbWFnaW5nIHRvIElPVCBvcGVyYXRp b24sIGl0IHNvb24gYXBwZWFyZWQgdGhhdCBtYW55IGltcGxlbWVudGF0aW9ucyB3ZXJlIHNraXBw aW5nIHRoYXQgc3RlcCBhbmQgaW5zZXJ0aW5nIGhlYWRlcnMgd2l0aCBubyBpZGVhIG9mIHRoZSBy aXNrcyBhdCBzdGFrZS4gV2Ugc3RhcnRlZCB0byBkb2N1bWVudCB0aGUgcG90ZW50aWFsIGlzc3Vl cyB3aXRoIHRoYXQgYmVoYXZpb3VyIGFuZCBob3cgdG8gYXZvaWQgdGhvc2UgaXNzdWVzIGFzIG11 Y2ggYXMgcG9zc2libGUuDQoNClBsZWFzZSBoYXZlIGEgbG9vayBhdCBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaHVpLTZtYW4tcnBsLWhlYWRlcnMtMDAgDQoNCkNoZWVycywNCg0K UGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFtt YWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlZmFubyBQcmV2aWRp DQo+IChzcHJldmlkaSkNCj4gU2VudDogamV1ZGkgMjggYXZyaWwgMjAxNiAxNzo1Nw0KPiBUbzog VGltIENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51az4NCj4gQ2M6IEJvYiBIaW5kZW4gPGJvYi5o aW5kZW5AZ21haWwuY29tPjsgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBS ZTogSW5zZXJ0aW5nIEV4dGVuc2lvbiBIZWFkZXJzIG9yIG5vdCBbd2FzIHJmYzI0NjBiaXMgcXVl c3Rpb24gXQ0KPiANCj4gDQo+ID4gT24gQXByIDI4LCAyMDE2LCBhdCA1OjQ4IFBNLCBUaW0gQ2hv d24gPFRpbS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCj4gPg0KPiA+PiBPbiAyOCBBcHIgMjAx NiwgYXQgMTU6MzMsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIDxzcHJldmlkaUBjaXNjby5j b20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gT24gQXByIDI4LCAyMDE2LCBhdCAxMDozMyBBTSwg VGltIENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51az4NCj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4g SGksDQo+ID4+Pg0KPiA+Pj4+IE9uIDI4IEFwciAyMDE2LCBhdCAwNDoyNiwgQnJpYW4gRSBDYXJw ZW50ZXINCj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+Pj4NCj4g Pj4+PiBPbiAyOC8wNC8yMDE2IDEzOjE4LCBCb2IgSGluZGVuIHdyb3RlOg0KPiA+Pj4+PiBIaSwN Cj4gPj4+Pj4NCj4gPj4+Pj4gSSB3b3VsZCBsaWtlIHRvIGdldCBjbG9zdXJlIG9uIHRoZSBxdWVz dGlvbiBpZiBpbnNlcnRpbmcgSVB2NiBleHRlbnNpb24NCj4gaGVhZGVycyBpcyBhbGxvd2VkIG9y IG5vdCwgYW5kIHNob3VsZCB0aGlzIGJlIGEgY2xhcmlmaWNhdGlvbiBpbiByZmMyNDYwYmlzLg0K PiBUaGlzIHRvcGljIHdhcyBkaXNjdXNzZWQgaW4gQnVlbm9zIEFpcmVzIGFuZCBvbiB0aGUgbWFp bGluZyBsaXN0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgcmVsZXZhbnQgdGV4dCBmcm9tIFNlY3Rp b24gNCAiSVB2NiBFeHRlbnNpb24gSGVhZGVycyIgaW4NCj4gPj4+Pj4gPGRyYWZ0LWlldGYtNm1h bi1yZmMyNDYwYmlzLTA0LnR4dD4NCj4gPj4+Pj4NCj4gPj4+Pj4gRXh0ZW5zaW9uIGhlYWRlcnMg bXVzdCBuZXZlciBiZSBpbnNlcnRlZCBieSBhbnkgbm9kZSBvdGhlciB0aGFuDQo+ID4+Pj4+IHRo ZSBzb3VyY2Ugb2YgdGhlIHBhY2tldC4gIElQIEVuY2Fwc3VsYXRpb24gbXVzdCBiZSB1c2VkIHRv IG1lZXQNCj4gPj4+Pj4gYW55IHJlcXVpcmVtZW50IGZvciBpbnNlcnRpbmcgaGVhZGVycywgZm9y IGV4YW1wbGUsIGFzIGRlZmluZWQgaW4NCj4gPj4+Pj4gW1JGQzI0NzNdLg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBUaGlzIHRleHQgd2FzIGFkZGVkIHRvIHRoZSBkcmFmdCBpbiB2ZXJzaW9uIOKAlDAxIHB1 Ymxpc2hlZCBvbiAyDQo+IE5vdmVtYmVyIDIwMTUuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBxdWVz dGlvbiBpcyBpZiB0aGlzIHRleHQgd2FzIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgcmZjMjQ2MC4g IFRoYXQNCj4gd291bGQgYWxsb3cgaXQgdG8gYmUgcGFydCBvZiByZmMyNDYwYmlzIGdvaW5nIHRv IEludGVybmV0IFN0YW5kYXJkLiAgSWYgaXQgaXMgYQ0KPiBjaGFuZ2UsIHRoZW4gaXQgc2hvdWxk IG5vdCBiZSBpbmNsdWRlZC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSW4gbXkgcGVyc29uYWwgdmlldyAo YXMgb25lIG9mIHRoZSBhdXRob3JzIG9mIHJmYzI0NjApLCBJIHRoaW5rIGl0IHdhcw0KPiB0aGUg b3JpZ2luYWwgaW50ZW50IHRvIG5vdCBhbGxvdyBleHRlbnNpb24gaGVhZGVycyB0byBiZSBpbnNl cnRlZC4gIE15DQo+IHRoaW5raW5nIGlzIHRoYXQgbm90IGFsbG93aW5nIGV4dGVuc2lvbiBoZWFk ZXJzIHRvIGJlIGluc2VydGVkIGlzIHJlbGF0ZWQgdGhlDQo+IGRlc2lnbiBvZiBJUHY2IHRoYXQg aW5jbHVkZXMgb25seSBzdXBwb3J0aW5nIGZyYWdtZW50YXRpb24gYXQgdGhlIHNvdXJjZS4NCj4g SVB2NCBhbGxvd3MgdGhlIGFkZGl0aW9uIG9mIG9wdGlvbnMgcmVzdWx0aW5nIGluIGNoYW5naW5n IHRoZSBoZWFkZXIgbGVuZ3RoLA0KPiBidXQgaXQgaW5jbHVkZXMgcGVyLWhvcCBmcmFnbWVudGF0 aW9uIHNvIGFueSByZXN1bHRpbmcgTVRVIGlzc3VlcyBjYW4gYmUNCj4gZGVhbHQgd2l0aC4gIEV2 ZW4gSVB2NCBmcmFnbWVudHMgY2FuIGJlIGZyYWdtZW50ZWQuICBJIHRoaW5rIGl0IGlzIGENCj4g Y29uc2VxdWVuY2Ugb2YgSVB2NiBub3QgYWxsb3cgcGVyLWhvcCBmcmFnbWVudGF0aW9uLCB0aGF0 IGV4dGVuc2lvbg0KPiBoZWFkZXJzIHdlcmUgbm90IGludGVuZGVkIHRvIGJlIGluc2VydGVkIGFs b25nIHRoZSBwYXRoIHRvIHRoZSBkZXN0aW5hdGlvbi4NCj4gPj4+Pg0KPiA+Pj4+IEkgdGhpbmsg dGhpcyBleGFjdGx5IGNvcnJlY3QuIEkgZGlkIGEgYml0IG9mIGFyY2hhZW9sb2d5IGFuZCBmb3Vu ZA0KPiA+Pj4+IHRoZSBtZXNzYWdlIHdoZXJlIFN0ZXZlIERlZXJpbmcgc3VtbWFyaXNlZCB0aGUg aXNzdWVzIHJlc29sdmVkDQo+ID4+Pj4gYmVmb3JlIFJGQyAxODgzICh0aGUgcHJlZGVjZXNzb3Ig b2YgUkZDIDI0NjApIHdhcyBwdWJsaXNoZWQgaW4NCj4gPj4+PiAxOTk1LiBJJ3ZlIGF0dGFjaGVk IGl0IGJlbG93IC0gbG9vayBqdXN0IGFmdGVyICJyZWplY3RlZCBhdCB0aGUNCj4gPj4+PiBTdG9j a2hvbG0gbWVldGluZyIgaS5lLiBJRVRGIDMzLiBUaGUgY29tbWVudCB0aGF0IHRyaWdnZXJlZCBp dCB3YXMgaW4NCj4gbWVzc2FnZSAoSVBuZyAzNDYpIGZyb20gQ2hhcmxpZSBMeW5uIHNlbnQgMzAg SnVuZSAxOTk1Lg0KPiA+Pj4+DQo+ID4+Pj4gW0kga25ldyBteSBtYWlsIGFyY2hpdmVzIHdvdWxk IGJlIHVzZWZ1bCBvbmUgZGF5Ll0NCj4gPj4+DQo+ID4+PiBTdHVubmluZyByZWNvbGxlY3Rpb24g cG93ZXJzIEJyaWFuIQ0KPiA+Pj4NCj4gPj4+IFRoZSBwYXJhZ3JhcGggeW91IHBvaW50IHRvLCBp LmUuOg0KPiA+Pj4NCj4gPj4+IAkicmVhc29ucyBmb3IgcmVqZWN0aW9uOiBpbnNlcnRpb24gb2Yg ZXh0ZW5zaW9uIGhlYWRlcnMgZW4tcm91dGUNCj4gYnJlYWtzDQo+ID4+PiAgIAlQTVRVLWRpc2Nv dmVyeSBhbmQgY2FuIHJlc3VsdCBpbiBJQ01QIGVycm9yIG1lc3NhZ2VzIGJlaW5nIHNlbnQgdG8N Cj4gPj4+ICAgCW5vbi1ndWlsdHkgcGFydGllcy4gIFRoZSBkZXNpcmVkIGVmZmVjdCBjYW4gYmUg YWNoaWV2ZWQsIGFuZCB0aG9zZQ0KPiA+Pj4gICAJcHJvYmxlbXMgYXZvaWRlZCwgYnkgdXNpbmcg ZW4tcm91dGUgZW5jYXBzdWxhdGlvbiAod2l0aCBvcHRpb25hbA0KPiA+Pj4gICAJUm91dGluZyBI ZWFkZXIpIHJhdGhlciB0aGFuIGhlYWRlciBpbnNlcnRpb24u4oCdDQo+ID4+Pg0KPiA+Pj4gc3Rp bGwgc2VlbXMgdmFsaWQgdG8gbWUsIGFuZCB0aHVzIEkgYWdyZWUgd2l0aCBCb2LigJlzIHByb3Bv c2FsLiBXaGV0aGVyDQo+IHRoZSBhYm92ZSByYXRpb25hbGUgaXMgYWxzbyBpbmNsdWRlZCBpcyBh biBhZGRpdGlvbmFsIHF1ZXN0aW9uLg0KPiA+Pj4NCj4gPj4+IEZvciBleGFtcGxlLCBpbiBzZWN0 aW9uIDIuMiBvZmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLCBpdA0KPiBz dGF0ZXM6ICJBdCB0aGUgaW5ncmVzcyBub2RlIG9mIGFuIFNSIGRvbWFpbiB3aGVyZSB0aGUgaW5n cmVzcyBub2RlIHJlY2VpdmVzDQo+IGFuIElQdjYgcGFja2V0IGFuZCBlbmNhcHN1bGF0ZXMgaXQg aW50byBhbiBvdXRlciBJUHY2IGhlYWRlciBmb2xsb3dlZCBieSBhDQo+IFNlZ21lbnQgUm91dGlu ZyBoZWFkZXIu4oCdDQo+ID4+DQo+ID4+DQo+ID4+IENvcnJlY3QuIFRoZSBkaXNjdXNzaW9uIHdl 4oCZcmUgaGF2aW5nIGlzIG5vdCByZWxhdGVkIHRvIGRyYWZ0LWlldGYtNm1hbi0NCj4gc2VnbWVu dC1yb3V0aW5nLWhlYWRlciBidXQgcmF0aGVyIG9uIGEgdXNhZ2Ugb2YgdGhlIFNSSCB0aGF0IHRo ZSBpbmR1c3RyeQ0KPiBpcyBhZG9wdGluZyBhbmQgdGhhdCBpbmNsdWRlcyBoZWFkZXIgaW5zZXJ0 aW9uLg0KPiA+DQo+ID4gQW5kIHVzYWdlIHRoYXQgaXMgbm90IGJlaW5nIHN0YW5kYXJkaXNlZCB3 aXRoaW4gdGhlIElFVEYsIG9yIGlzIGl0Pw0KPiANCj4gDQo+IGl0IHdvdWxkIGJlIGdvb2QgdG8g c3RhbmRhcmRpemUgYmVoYXZpb3JzIHVzZWQgYnkgdGhlIGluZHVzdHJ5IGV2ZW4gaWYgdGhlc2UN Cj4gYmVoYXZpb3JzIGFyZSBub3QgdGhlIG9uZXMgb3JpZ2luYWxseSBwbGFubmVkIGF0IHRoZSB0 aW1lIHRoZSBzcGVjIGhhcyBiZWVuDQo+IHdyaXR0ZW4uDQo+IA0KPiBCeSBzdGFuZGFyZGl6YXRp b24gSSBpbnRlbmQgZGlnIG91dCBhbGwgZGV0YWlscyB0aGF0IG5lZWRzIHRvIGJlIGNhcmVmdWxs eQ0KPiBhZGRyZXNzZWQuDQo+IA0KPiBzLg0KPiANCj4gDQo+ID4NCj4gPiBUaW0NCj4gPg0KPiA+ PiBzLg0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IFRpbQ0KPiA+Pj4NCj4gPj4+PiBCcmlhbg0K PiA+Pj4+DQo+ID4+Pj4+IE5vdGUsIEkgdGhpbmsgaXQgd291bGQgYmUgZmluZSBmb3Igc29tZW9u ZSB0byBkb2N1bWVudCBob3cgdG8gZG8NCj4gZXh0ZW5zaW9uIGhlYWRlciBpbnNlcnRpb24sIGFz IGxvbmcgYXMgdGhleSBkZXNjcmliZSBob3cgaXQgd29ya3MsIGFuZCBob3cNCj4gdG8gZGVhbCBp c3N1ZXMgbGlrZSBNVFUgcHJvYmxlbXMuICBUaGlzIGNhbiBiZSBiZSBhbiB1cGRhdGUgdG8gcmZj MjQ2MGJpcw0KPiAoYWZ0ZXIgaXQgaXMgcHVibGlzaGVkKS4NCj4gPj4+Pj4NCj4gPj4+Pj4gSG93 ZXZlciwgSSBkbyBub3QgdGhpbmsgbGVhdmluZyB0aGUgcmZjMjQ2MGJpcyB0ZXh0IGluIGFuIGFt YmlndW91cw0KPiBzdGF0ZSBvbiB0aGlzIHRvcGljIGlzIGEgZ29vZCBpZGVhLg0KPiA+Pj4+Pg0K PiA+Pj4+PiBDb21tZW50cz8NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzLA0KPiA+Pj4+PiBCb2IN Cj4gPj4+Pg0KPiA+Pj4+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+ID4+ Pj4gU3ViamVjdDogKElQbmcgNjA5KSBjaGFuZ2VzIHRvIExhc3QgQ2FsbCdlZCBzcGVjcw0KPiA+ Pj4+IERhdGU6IFN1biwgMjcgQXVnIDE5OTUgMjA6NTk6MjYgUERUDQo+ID4+Pj4gRnJvbTogU3Rl dmUgRGVlcmluZyA8ZGVlcmluZ0BwYXJjLnhlcm94LmNvbT4NCj4gPj4+PiBUbzogaXBuZ0BzdW5y b29mLmVuZy5zdW4uY29tDQo+ID4+Pj4gQ0M6IGRlZXJpbmdAcGFyYy54ZXJveC5jb20NCj4gPj4+ Pg0KPiA+Pj4+IEF0IHRoZSByZXF1ZXN0IG9mIG91ciBBRHMsIEkgcHJlcGFyZWQgdGhlIGZvbGxv d2luZyBsaXN0IG9mDQo+ID4+Pj4gYWdyZWVkLXVwb24gY2hhbmdlcyBhbmQgb3V0c3RhbmRpbmcg aXNzdWVzIHdpdGggdGhlIHNldCBvZiBzcGVjcw0KPiA+Pj4+IHRoYXQgdW5kZXJ3ZW50IElFVEYt d2lkZSBMYXN0IENhbGwgaW4gSnVuZSBhbmQgSnVseS4gIFBsZWFzZSBsZXQgbWUNCj4gPj4+PiBr bm93IG9mIGFueSBlcnJvcnMgb3Igb21pc3Npb25zLg0KPiA+Pj4+DQo+ID4+Pj4gU3RldmUNCj4g Pj4+Pg0KPiA+Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4+Pj4N Cj4gPj4+PiBJUHY2IFNwZWNpZmljYXRpb24NCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pj4+Pg0KPiA+Pj4+IFRoZSBmb2xsb3dpbmcgY2hhbmdlcyB3ZXJlIHBvc3RlZCB0byB0aGUgSUVU RiBsaXN0IGltbWVkaWF0ZWx5DQo+ID4+Pj4gZm9sbG93aW5nIHRoZSBMYXN0IENhbGwsIHNvIEkg dGhpbmsgd2UgY2FuIGNvbnNpZGVyIHRoZW0gdG8gYWxzbyBoYXZlDQo+IGJlZW4gTGFzdCBDYWxs ZWQ6DQo+ID4+Pj4NCj4gPj4+PiAtIEluIHRoZSBleGFtcGxlcyBvZiBob3cgdG8gbGF5IG91dCBv cHRpb25zLCBvbiBwYWdlIDI5LCB0d28gcGxhY2VzDQo+ID4+Pj4gd2hlcmUgaXQgc2F5cyAiSGRy IEV4dCBMZW49MSIgc2hvdWxkIGJlICJIZHIgRXh0IExlbj0zIg0KPiA+Pj4+IChyZXBvcnRlZCBi eSBIYW1pZCBBc2F5ZXNoKS4NCj4gPj4+Pg0KPiA+Pj4+IC0gSW4gc2VjdGlvbiA2LCBGbG93IExh YmVscywgSSBmb3Jnb3QgdG8gaW5jbHVkZSB0aGUgUHJpb3JpdHkgZmllbGQNCj4gPj4+PiBpbiB0 aGUgbGlzdCBvZiBmaWVsZHMgdGhhdCBtdXN0IGhhdmUgdGhlIHNhbWUgdmFsdWUgZm9yIGFsbCBw YWNrZXRzDQo+ID4+Pj4gaW4gdGhlIHNhbWUgZmxvdyAocmVwb3J0ZWQgYnkgTWFya3VzIEpvcmsp Lg0KPiA+Pj4+DQo+ID4+Pj4gLSBUaGUgZGVzY3JpcHRpb24gb2Ygd2hhdCB0aGUgSnVtYm8gUGF5 bG9hZCBMZW5ndGggZmllbGQgY292ZXJzDQo+ID4+Pj4gc2hvdWxkIGJlIG1hZGUgY2xlYXJlciAo cmVwb3J0ZWQgYnkgQ2hyaXN0aWFuIEh1aXRlbWEpLg0KPiA+Pj4+DQo+ID4+Pj4gVGhlIGZvbGxv d2luZyBjaGFuZ2VzIHdlcmUgcHJvcG9zZWQgYnkgQ2hhcmxpZSBMeW5uIGluIHRoZSBvbmx5DQo+ ICJmb3JtYWwiDQo+ID4+Pj4gcmVzcG9uc2UgdG8gdGhlIExhc3QgQ2FsbCwgYW5kIGFjY2VwdGVk IGF0IHRoZSBmaXJzdCBpcG5nd2cgbWVldGluZw0KPiA+Pj4+IGluDQo+ID4+Pj4gU3RvY2tob2xt Og0KPiA+Pj4+DQo+ID4+Pj4gLSBGb3Igb3B0aW9ucyBjb250YWluaW5nIGRhdGEgdGhhdCBjYW4g Y2hhbmdlIGVuLXJvdXRlIChhbmQgd2hpY2gNCj4gPj4+PiB0aGVyZWZvcmUgaGF2ZSB0aGUgdGhp cmQtaGlnaGVzdC1vcmRlciBiaXQgb2YgdGhlaXIgT3B0aW9uIFR5cGUgc2V0DQo+ID4+Pj4gdG8g MSksIG1ha2UgaXQgY2xlYXIgdGhhdCAqYWxsKiBieXRlcyBvZiB0aGUgT3B0aW9uIERhdGEgZmll bGQgYXJlDQo+ID4+Pj4gdG8gYmUgZXhjbHVkZWQgZnJvbSB0aGUgQXV0aGVudGljYXRpb24gZnVu Y3Rpb24sIGFuZCBleHBsYWluIHRoYXQNCj4gPj4+PiAiZXhjbHVkZWQiIG1lYW5zICJ0cmVhdGVk IGFzIGlmIHRoZXkgd2VyZSBhbGwgemVyby12YWx1ZWQgYnl0ZXMiLg0KPiA+Pj4+DQo+ID4+Pj4g LSBDaGFuZ2UgdGhlIFJvdXRpbmcgSGVhZGVyIHRvIGVuYWJsZSBpdCB0byBiZSBpZ25vcmVkIGJ5 IGZpbmFsDQo+ID4+Pj4gZGVzdGluYXRpb25zIHRoYXQgZG8gbm90IHVuZGVyc3RhbmQgdGhlIFJv dXRpbmcgVHlwZS4gIEluDQo+ID4+Pj4gU3RvY2tob2xtLCBEZWVyaW5nIHByb3Bvc2VkLCBhbmQg dGhlIGF0dGVuZGVlcyBhZ3JlZWQgd2l0aCwgdGhlDQo+ID4+Pj4gZm9sbG93aW5nIHJldmlzZWQg Zm9ybWF0IGZvciB0aGUgZmlyc3QgMzIgYml0cyBvZiB0aGUgUm91dGluZyBIZWFkZXIsIGZvcg0K PiBhbGwgUm91dGluZyBUeXBlczoNCj4gPj4+Pg0KPiA+Pj4+ICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+Pj4+ICB8 ICBOZXh0IEhlYWRlciAgfCAgSGRyIEV4dCBMZW4gIHwgIFJvdXRpbmcgVHlwZSB8IFNlZ21lbnRz IExlZnQgfA0KPiA+Pj4+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4+Pj4gIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4+Pj4NCj4gPj4+ PiB3aGVyZQ0KPiA+Pj4+DQo+ID4+Pj4gCUhkciBFeHQgTGVuICAgaXMgdGhlIGxlbmd0aCBvZiB0 aGUgaGVhZGVyIGluIDgtb2N0ZXQgdW5pdHMsIG5vdA0KPiA+Pj4+IAkgICAgICAgICAgICAgIGlu Y2x1ZGluZyB0aGUgZmlyc3QgOCBvY3RldHMNCj4gPj4+Pg0KPiA+Pj4+IAlTZWdtZW50cyBMZWZ0 IGlzIHRoZSBudW1iZXIgb2YgImxlZ3MiIGxlZnQgdG8gdHJhdmVyc2UgaW4gdGhlDQo+ID4+Pj4g ICAgICAgICAgICAgICAgICAgcm91dGU7IGlmIHRoaXMgdmFsdWUgaXMgemVybywgdGhlIHJlY2Vp dmVyIG1heQ0KPiA+Pj4+IAkgICAgICAgICAgICAgIGlnbm9yZSB0aGlzIGhlYWRlciAoaS5lLiwg aXQgaW5kaWNhdGVzIHRoYXQgdGhlDQo+ID4+Pj4gCSAgICAgICAgICAgICAgcm91dGUgaGFzIGJl ZW4gY29tcGxldGVkKSwgd2hldGhlciBvciBub3QgdGhlDQo+ID4+Pj4gCSAgICAgICAgICAgICAg cmVjZWl2ZXIgdW5kZXJzdGFuZHMgdGhlIFJvdXRpbmcgVHlwZQ0KPiA+Pj4+DQo+ID4+Pj4gVGhl IGZvbGxvd2luZyBhZGRpdGlvbmFsIGNoYW5nZXMgd2VyZSBhZ3JlZWQgdG8gZWl0aGVyIG9uIHRo ZQ0KPiA+Pj4+IG1haWxpbmcgbGlzdCBvciBpbiB0aGUgU3RvY2tob2xtIG1lZXRpbmdzOg0KPiA+ Pj4+DQo+ID4+Pj4gLSAiSW1wcm92ZSIgdGhlIGhvc3Qvcm91dGVyIHRlcm1pbm9sb2d5LiAgV2hh dCBJIHByb3Bvc2UgdG8gZG8gaXMNCj4gPj4+PiBhZGQgYSBmb290bm90ZSB0byB0aGUgdGVybWlu b2xvZ3kgc2VjdGlvbiBzYXlpbmcgc29tZXRoaW5nIGxpa2UgdGhpczoNCj4gPj4+Pg0KPiA+Pj4+ IAkqIGl0IGlzIHBvc3NpYmxlLCB0aG91Z2ggdW51c3VhbCwgdG8gaGF2ZSBhIGRldmljZSB3aXRo IG11bHRpcGxlDQo+ID4+Pj4gICAgICAgaW50ZXJmYWNlcyBjb25maWd1cmVkIHRvIGZvcndhcmQg bm9uLXNlbGYtZGVzdGluZWQgcGFja2V0cw0KPiA+Pj4+ICAgICAgIGFycml2aW5nIGZyb20gc29t ZSBzZXQgKGZld2VyIHRoYW4gYWxsKSBvZiBpdHMgaW50ZXJmYWNlcywgYW5kDQo+ID4+Pj4gCSAg dG8gZGlzY2FyZCBub24tc2VsZi1kZXN0aW5lZCBwYWNrZXRzIGFycml2aW5nIGZyb20gaXRzIG90 aGVyDQo+ID4+Pj4gCSAgaW50ZXJmYWNlcy4gIFN1Y2ggYSBkZXZpY2UgbXVzdCBvYmV5IHRoZSBw cm90b2NvbCByZXF1aXJlbWVudHMNCj4gPj4+PiAJICBmb3Igcm91dGVycyB3aGVuIHJlY2Vpdmlu ZyBwYWNrZXRzIGZyb20sIGFuZCBpbnRlcmFjdGluZyB3aXRoDQo+ID4+Pj4gCSAgbmVpZ2hib3Jz IG92ZXIsIHRoZSBmb3JtZXIgKGZvcndhcmRpbmcpIGludGVyZmFjZXMuICBJdCBtdXN0DQo+ID4+ Pj4gCSAgb2JleSB0aGUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGZvciBob3N0cyB3aGVuIHJlY2Vp dmluZyBwYWNrZXRzDQo+ID4+Pj4gCSAgZnJvbSwgYW5kIGludGVyYWN0aW5nIHdpdGggbmVpZ2hi b3JzIG92ZXIsIHRoZSBsYXR0ZXIgKG5vbi0NCj4gPj4+PiAJICBmb3J3YXJkaW5nKSBpbnRlcmZh Y2VzLg0KPiA+Pj4+DQo+ID4+Pj4gQ29tbWVudHM/DQo+ID4+Pj4NCj4gPj4+PiAtIENsYXJpZnkg dGhlIG9wZXJhdGlvbiBvZiBUeXBlIDAgUm91dGluZyBIZWFkZXIgYnkgZ2l2aW5nIGFuDQo+ID4+ Pj4gZXhhbXBsZSwgc2hvd2luZyB0aGUgdmFsdWVzIG9mIHRoZSBoZWFkZXIgZmllbGRzIG9uIGVh Y2ggc2VnbWVudCBvZg0KPiB0aGUgcm91dGUuDQo+ID4+Pj4NCj4gPj4+PiAtIENsYXJpZnkgdGhl IGhhbmRsaW5nIG9mIG9wdGlvbnMsIGV4dGVuc2lvbiBoZWFkZXJzLCBOZXh0IEhlYWRlcg0KPiA+ Pj4+IGZpZWxkcywgZXRjLiBmb3IgZnJhZ21lbnRlZCBwYWNrZXRzIGJ5IGdpdmluZyBhIGZldyBl eGFtcGxlcyBvZg0KPiA+Pj4+IHBhY2tldHMgYmVmb3JlIGFuZCBhZnRlciBmcmFnbWVudGF0aW9u IChzdWdnZXN0ZWQgYnkgRGltaXRyeSBIYXNraW5zDQo+IGFuZCBvdGhlcnMpLg0KPiA+Pj4+DQo+ ID4+Pj4gLSBTcGVjaWZ5IHRoYXQgZnJhZ21lbnRzIGNhbm5vdCByZWFzc2VtYmxlIHRvIGZvcm0g YSBqdW1ib2dyYW0NCj4gPj4+PiAoc3VnZ2VzdGVkIGJ5IENyYWlnIE1ldHopLg0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+PiBJQ01QdjYgU3BlY2lmaWNhdGlvbg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+ID4+Pj4NCj4gPj4+PiAtIEFkZCBub3RlIHdhcm5pbmcgYWJvdXQgdGhlIHBvc3Np YmlsaXR5IG9mIHVwcGVyLWxheWVyIGhlYWRlcg0KPiA+Pj4+IGJlaW5nIHRydW5jYXRlZCBmcm9t IHRoZSByZXR1cm5lZCBwYWNrZXQgaW4gYW4gZXJyb3IgbWVzc2FnZSwgZHVlDQo+ID4+Pj4gdG8g bGFyZ2UgbnVtYmVyIG9mIGV4dGVuc2lvbiBoZWFkZXIgYnl0ZXMsIHdoaWNoIGNhbiBkZWZlYXQN Cj4gPj4+PiBkZWxpdmVyeSBvZiB0aGUgZXJyb3IgbWVzc2FnZSB0byB0aGUgZ3VpbHR5IHVwcGVy LWxheWVyIHByb3RvY29sDQo+IGluc3RhbmNlLg0KPiA+Pj4+DQo+ID4+Pj4gLSBEZWxldGUgZGVz Y3JpcHRpb24gb2YgcHNldWRvLWhlYWRlciwgcmVwbGFjaW5nIGl0IHdpdGggYQ0KPiA+Pj4+IHJl ZmVyZW5jZSB0byB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIElQdjYgc3BlYyAoc3VnZ2VzdGVkIGJ5 DQo+ID4+Pj4gQWxpc3RhaXIgQmVsbCBhbmQgTWFyYyBIYXNzb24pLg0KPiA+Pj4+DQo+ID4+Pj4g LSBDb3JyZWN0IGV4YW1wbGUgb2YgdXNhZ2Ugb2YgdGhlIHBvaW50ZXIgaW4gdGhlIFBhcmFtZXRl ciBQcm9ibGVtDQo+ID4+Pj4gbWVzc2FnZSBvbiBwYWdlIDE1LCBieSBjaGFuZ2luZyAiNDgiIHRv ICI0MCIgKHJlcG9ydGVkIGJ5IERpbWl0cnkNCj4gPj4+PiBIYXNraW5zIGFuZCBGcmFuY2lzIER1 cG9udCkuDQo+ID4+Pj4NCj4gPj4+PiAtIE5vdGUgdGhhdCB0aGVyZSBpcyBhbm90aGVyIGV4Y2Vw dGlvbiB0byB0aGUgIm5vIElDTVAgZXJyb3INCj4gPj4+PiBtZXNzYWdlcyBpbiByZXNwb25zZSB0 byBtdWx0aWNhc3RzIiBydWxlLCB3aGljaCBpcyAidW5yZWNvZ25pemVkDQo+IG9wdGlvbiINCj4g Pj4+PiBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlcyBpbiByZXNwb25zZSB0byBvcHRpb25zIHdp dGggaGlnaC1vcmRlcg0KPiA+Pj4+IGJpdHMgIjEwLi4uIiAocmVwb3J0ZWQgYnkgRGltaXR5IEhh c2tpbnMpLg0KPiA+Pj4+DQo+ID4+Pj4gQWRkcmVzcyBBcmNoaXRlY3R1cmUgRG9jdW1lbnQNCj4g Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+DQo+ID4+Pj4gLSBBZGQg ZGVmaW5pdGlvbiBvZiAibGluay1sb2NhbCBhZGRyZXNzIiB0byB0aGUgdGVybWlub2xvZ3kgc2Vj dGlvbg0KPiA+Pj4+IChzdWdnZXN0ZWQgYnkgSmltIEJvdW5kKS4NCj4gPj4+Pg0KPiA+Pj4+IC0g U3BlY2lmeSB0aGF0ICI6OiIgaXMgYSBsZWdhbCB0ZXh0IHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0K PiA+Pj4+IFVuc3BlY2lmaWVkDQo+ID4+Pj4gKGFsbC16ZXJvcykgQWRkcmVzcyAoc3VnZ2VzdGVk IGJ5IEZyYW5jaXMgRHVwb250KS4NCj4gPj4+Pg0KPiA+Pj4+ID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+ID4+Pj4NCj4gPj4+PiBUaGUgZm9sbG93aW5nIHN1Z2dlc3Rpb25z IGluIENoYXJsaWUgTHlubidzIGZvcm1hbCByZXNwb25zZSB0byB0aGUNCj4gPj4+PiBMYXN0IENh bGwgd2VyZSByZWplY3RlZCBhdCB0aGUgU3RvY2tob2xtIG1lZXRpbmc6DQo+ID4+Pj4NCj4gPj4+ PiAtIEFkZCBhIGJpdCB0byB0aGUgUm91dGluZyBIZWFkZXIgaW5kaWNhdGluZyB3aGV0aGVyIG9y IG5vdCBpdCB3YXMNCj4gPj4+PiBpbnNlcnRlZCBpbnRvIHRoZSBwYWNrZXQgZW4tcm91dGUsIGku ZS4sIGJ5IGEgbm9kZSBvdGhlciB0aGFuIHRoZQ0KPiA+Pj4+IHBhY2tldCdzIG9yaWdpbmF0b3Iu DQo+ID4+Pj4NCj4gPj4+PiAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogaW5zZXJ0aW9uIG9mIGV4 dGVuc2lvbiBoZWFkZXJzIGVuLXJvdXRlIGJyZWFrcw0KPiA+Pj4+ICAgUE1UVS1kaXNjb3Zlcnkg YW5kIGNhbiByZXN1bHQgaW4gSUNNUCBlcnJvciBtZXNzYWdlcyBiZWluZyBzZW50IHRvDQo+ID4+ Pj4gICBub24tZ3VpbHR5IHBhcnRpZXMuICBUaGUgZGVzaXJlZCBlZmZlY3QgY2FuIGJlIGFjaGll dmVkLCBhbmQgdGhvc2UNCj4gPj4+PiAgIHByb2JsZW1zIGF2b2lkZWQsIGJ5IHVzaW5nIGVuLXJv dXRlIGVuY2Fwc3VsYXRpb24gKHdpdGggb3B0aW9uYWwNCj4gPj4+PiAgIFJvdXRpbmcgSGVhZGVy KSByYXRoZXIgdGhhbiBoZWFkZXIgaW5zZXJ0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gLSBDaGFuZ2Ug SUNNUCBlcnJvciBtZXNzYWdlcyB0byBjb250YWluIGV4cGxpY2l0IGZpZWxkcyBpZGVudGlmeWlu Zw0KPiA+Pj4+IHRoZSB1cHBlci1sYXllciBwcm90b2NvbCB0byB3aGljaCB0aGUgZXJyb3IgbWVz c2FnZSBzaG91bGQgYmUNCj4gZGVsaXZlcmVkLg0KPiA+Pj4+DQo+ID4+Pj4gICByZWFzb25zIGZv ciByZWplY3Rpb246IGNvbnNpZGVyZWQgdW5uZWNlc3NhcnkgY29tcGxleGl0eSB0byBoYW5kbGUN Cj4gdGhlDQo+ID4+Pj4gICByYXJlIGNhc2Ugb2YgdHJ1bmNhdGlvbiBvZiB0cmFuc3BvcnQgaGVh ZGVyIGZyb20gdGhlIHJldHVybmVkIHBhY2tldA0KPiA+Pj4+ICAgYmVjYXVzZSBvZiB0b28gbWFu eSBleHRlbnNpb24gaGVhZGVyIG9jdGV0cy4gIFN1Y2ggZXJyb3IgbWVzc2FnZXMNCj4gYXJlDQo+ ID4+Pj4gICBzdGlsbCB1c2FibGUgZm9yIHByb2JsZW0gZGlhZ25vc2lzIG90aGVyIHRoYW4gaW4g dGhlIHVwcGVyLWxheWVyDQo+ID4+Pj4gICBpdHNlbGYsIGUuZy4sIGlmIGxvZ2dlZCBhdCBJUHY2 IGxheWVyIG9yIG9ic2VydmVkIGluIGEgcGFja2V0IHRyYWNlLg0KPiA+Pj4+ICAgV2lsbCBhZGQg d2FybmluZyB0byB0aGUgSUNNUHY2IHNwZWMgYWJvdXQgY29uc2VxdWVuY2VzIG9mIGxvbmcNCj4g Pj4+PiAgIGV4dGVuc2lvbiBoZWFkZXIgb24gSUNNUCBlcnJvciBtZXNzYWdlIGRpc3BhdGNoaW5n Lg0KPiA+Pj4+DQo+ID4+Pj4gLSBDaGFuZ2UgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv biBvZiBJQ01QdjYgc3BlYyB0byBzcGVjaWZ5DQo+ID4+Pj4gd2hlbiBhbmQgaG93IHRvIGluY2x1 ZGUgYW4gQXV0aGVudGljYXRpb24gSGVhZGVyIGluIElDTVAgZXJyb3INCj4gbWVzc2FnZXMuDQo+ ID4+Pj4NCj4gPj4+PiAgIHJlYXNvbnMgZm9yIHJlamVjdGlvbjogZ3JvdXAgY29uc2Vuc3VzIHRo YXQgdGhpcyBiZWxvbmdzIGluIGFhDQo+ID4+Pj4gICBJUHNlYyBzcGVjIGluc3RlYWQuDQo+ID4+ Pj4NCj4gPj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+Pj4+DQo+ ID4+Pj4gVGhlIGZvbGxvd2luZyBpc3N1ZXMgYW5kIHN1Z2dlc3Rpb25zIGhhdmUgYmVlbiBkaXNj dXNzZWQgb24gdGhlDQo+ID4+Pj4gbWFpbGluZyBsaXN0IHNpbmNlIHRoZSBiYXNlIHNwZWNzIHdl bnQgdG8gTGFzdCBDYWxsLCBidXQgbm8gZ3JvdXANCj4gPj4+PiBjb25zZW5zdXMgb24gdGhlc2Ug aXNzdWVzIGhhcyBiZWVuIHJlYWNoZWQgeWV0Og0KPiA+Pj4+DQo+ID4+Pj4gLSBGcmFnbWVudGF0 aW9uIGlzc3VlczoNCj4gPj4+PiAJLSBjaGFuZ2UgdGhlIG1pbmltdW0gcmVhc3NlbWJseSBidWZm ZXIgc2l6ZSB0byBhIG51bWJlciBsYXJnZXINCj4gPj4+PiAJICB0aGFuIDU3Nj8NCj4gPj4+PiAJ LSBzcGVjaWZ5IHRoYXQgc291cmNlcyBvZiBmcmFnbWVudGVkIHBhY2tldHMgbXVzdCB1c2UgdGhl IG1pbmltYWwNCj4gPj4+PiAJICBudW1iZXIgb2YgZnJhZ21lbnRzIHJlcXVpcmVkIHRvIGZpdCBp biB0aGUgcGVyY2VpdmVkIFBNVFU/DQo+ID4+Pj4gCS0gc3BlY2lmeSB0aGF0IGFsbCBmcmFnbWVu dHMgd2l0aCB0aGUgTSBiaXQgc2V0IG11c3QgYmUgbm8gbGVzcw0KPiA+Pj4+IAkgIHRoYW4gNyBv Y3RldHMgc2hvcnRlciB0aGFuIHRoZSBwZXJjZWl2ZWQgUE1UVT8NCj4gPj4+PiAJLSBzcGVjaWZ5 IHRoYXQgYWxsIGZyYWdtZW50cyB3aXRoIHRoZSBNIGJpdCBzZXQgbXVzdCBiZSBubyBzaG9ydGVy DQo+ID4+Pj4gCSAgdGhhbiA1NzYgb2N0ZXRzPw0KPiA+Pj4+IAktIGlnbm9yZSBmcmFnbWVudHMg dGhhdCBwYXJ0aWFsbHkgb3ZlcmxhcCBvdGhlciBmcmFnbWVudHMgb2YgdGhlDQo+ID4+Pj4gCSAg c2FtZSBwYWNrZXQsIG9yIGRpc2NhcmQgYW55IHBhY2tldCB0aGF0IGFycml2ZXMgYXMgcGFydGlh bGx5DQo+ID4+Pj4gCSAgb3ZlcmxhcHBpbmcgZnJhZ21lbnRzPw0KPiA+Pj4+DQo+ID4+Pj4gLSBS b3V0aW5nIEhlYWRlciBpc3N1ZXM6DQo+ID4+Pj4gCS0gYWRkIGEgIlRvdGFsIExlbmd0aCIgZmll bGQgdG8gdGhlIGZyYWdtZW50IGhlYWRlciwgY2FycnlpbmcgdGhlDQo+ID4+Pj4gCSAgbGVuZ3Ro IG9mIHRoZSBvcmlnaW5hbCwgdW5mcmFnbWVudGVkIHBhY2tldD8NCj4gPj4+PiAJLSBmb3JiaWQg Zm9yd2FyZGluZyBvZiBwYWNrZXRzIHdpdGggUm91dGluZyBIZWFkZXJzIGJ5IGhvc3RzPw0KPiA+ Pj4+IAkgIChpZiBub3QsIG1ha2UgaXQgY2xlYXJlciB0aGF0IGhvc3RzIGFyZSBleHBlY3RlZCB0 byBmb3J3YXJkDQo+ID4+Pj4gCSAgcGFja2V0cyB3aXRoIFJvdXRpbmcgSGVhZGVycywgaWYgdGhl eSBhcmUgaW50ZXJtZWRpYXRlIHRhcmdldHMNCj4gPj4+PiAJICBvZiBzdWNoIHBhY2tldHMuKQ0K PiA+Pj4+IAktIHNwZWNpZnkgdGhlIHJldmVyc2luZyBydWxlcyBmb3IgcGFja2V0cyB0aGF0IGFy ZSByZXNwb25zZXMgdG8NCj4gPj4+PiAJICBwYWNrZXRzIHRoYXQgY2FycnkgYSBSb3V0aW5nIEhl YWRlcj8NCj4gPj4+PiAJLSBmb3JiaWQgb3IgZGlzY291cmFnZSByZXZlcnNhbCBvZiBhbiB1bmF1 dGhlbnRpY2F0ZWQgUm91dGluZw0KPiBIZWFkZXI/DQo+ID4+Pj4gCS0gZm9yYmlkIG9yIGRpc2Nv dXJhZ2UgYWNjZXB0YW5jZSBvZiBhIHBhY2tldCB3aXRoIGFuDQo+IHVuYXV0aGVudGljYXRlZA0K PiA+Pj4+IAkgIFJvdXRpbmcgSGVhZGVyPw0KPiA+Pj4+DQo+ID4+Pj4gLSBBbGxvdyB0aGUgdHJh bnNwb3J0LWxheWVyIGNoZWNrc3VtIHRvIGJlIG9taXR0ZWQgd2hlbiB0aGUNCj4gPj4+PiBBdXRo ZW50aWNhdGlvbiBoZWFkZXIgKG9yIHRoZSBFU1AgaGVhZGVyPykgaXMgYmVpbmcgdXNlZD8NCj4g Pj4+Pg0KPiA+Pj4+IC0gQWRkIGEgQ29uZ2VzdGlvbiBJbmRpY2F0aW9uIGJpdCB0byB0aGUgYmFz ZSBJUHY2IGhlYWRlcj8NCj4gPj4+Pg0KPiA+Pj4+IC0gQWRkIE1VU1QvU0hPVUxEL01BWSBjb25m b3JtYW5jZSByZXF1aXJlbWVudHMgZm9yIGFsbCBJUHY2IGZpZWxkcw0KPiA+Pj4+IGFuZCBmdW5j dGlvbnM/DQo+ID4+Pj4NCj4gPj4+PiAtIEJ1aWxkIGEgc2luZ2xlIFRlcm1pbm9sb2d5IGRvY3Vt ZW50LCB0byBiZSBzaGFyZWQgKGVpdGhlciBieQ0KPiA+Pj4+IHJlZmVyZW5jZSBvciBpbmNsdXNp b24pIGluIGFsbCBJUHY2LXJlbGF0ZWQgc3BlY3M/DQo+ID4+Pj4NCj4gPj4+PiAtIEFsbG93IHRo ZSB1c2Ugb2YgemVybyBpbiB0aGUgVURQIExlbmd0aCBmaWVsZCB0byBpbmRpY2F0ZSB0aGF0DQo+ ID4+Pj4gdGhlIFVEUCBsZW5ndGggc2hvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgSnVtYm9ncmFt IE9wdGlvbj8NCj4gPj4+Pg0KPiA+Pj4+IE5vdGU6IHRoZSBhYm92ZSBsaXN0IGRvZXMgbm90IGlu Y2x1ZGUgaXNzdWVzIGNvbmNlcm5pbmcgdGhvc2Ugc3BlY3MNCj4gPj4+PiB0aGF0IGhhdmUgbm90 IHlldCBiZWVuIHN1YmplY3RlZCB0byBXRyBvciBJRVRGIExhc3QgQ2FsbCwgZS5nLiwgdGhlDQo+ ID4+Pj4gTmVpZ2hib3IgRGlzY292ZXJ5IHNwZWMuDQo+ID4+Pj4NCj4gPj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPj4+PiBJRVRGIElQbmcgTWFpbGluZyBMaXN0CQkgICAgICBGVFAgYXJj aGl2ZToNCj4gZnRwLnBhcmMueGVyb3guY29tOi9wdWIvaXBuZw0KPiA+Pj4+IElQbmcgSG9tZSBQ YWdlOiAgICAgICAgICBodHRwOi8vcGxheWdyb3VuZC5zdW4uY29tL3B1Yi9pcG5nL2h0bWwvaXBu Zy0NCj4gbWFpbi5odG1sDQo+ID4+Pj4gRGlyZWN0IGFsbCBhZG1pbmlzdHJhdGl2ZSByZXF1ZXN0 cyB0byBtYWpvcmRvbW9Ac3Vucm9vZi5lbmcuc3VuLmNvbQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pg0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+PiAtIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlDQo+ID4+Pj4gUmVxdWVzdHM6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPj4+PiAtDQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZl DQo+ID4+PiBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBB ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Fri Apr 29 01:40:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8FA12D5AD; Fri, 29 Apr 2016 01:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 EzmoQEhWDGdV; Fri, 29 Apr 2016 01:40:43 -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 4BAF812D5A3; Fri, 29 Apr 2016 01:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11474; q=dns/txt; s=iport; t=1461919243; x=1463128843; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ffy6no1UmmrzXCl4caxrUJgvOUIjW4olkPH+Ngu35zU=; b=SXEvL+7plMV9xxcjUH5K4GrGYRe6ZAbWpnHzTKy2msbhrvls95uBqxph TW0zN1dfzDvEd+sw4FGgKbUkgsKVoOpXDM7plSKPa3Yjg06zpNfuVDe00 6s7b+gqtY7ioZGstKbToiI4nWUA0vZ2i/iLknu0+7JcrOD6FvINSHGYtt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDMHCNX/4UNJK1egzhTfQa5ZQENg?= =?us-ascii?q?XYXC4VtAoErOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQcCAgIBCBUCAScHGww?= =?us-ascii?q?LFAkIAgQOBYgiCA7DRQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWBVIECh?= =?us-ascii?q?A8RARwsgn+CKwEEh3SLGYUEAY4WgWeETYMpe4Q5jy8BHgEBQoIFG4FLbIYzNn8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,551,1454976000"; d="scan'208";a="97283386" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 08:40:41 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3T8ef8f016449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 08:40:41 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.1104.5; Fri, 29 Apr 2016 04:40:40 -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.1104.009; Fri, 29 Apr 2016 04:40:40 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Subject: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AQHRoTzev8IxaMPY3kOJ15ohq3wgDJ+fRJn9gAGNp4CAABPwAA== Date: Fri, 29 Apr 2016 08:40:40 +0000 Message-ID: <8FAD863D-B04B-4D12-BD29-380C34CF61BF@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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.111.237] Content-Type: text/plain; charset="Windows-1252" Content-ID: <321C2EFF5EEEA246A7BA5C96206E9281@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 08:40:45 -0000 well, I think you missed how routing headers are handled in ipv6. Please read rfc2460 section 4.4 and then draft-ietf-6man-segment-routing-he= ader section 4 and especially section 4.3. You=92ll see that the routing header is not an mpls label stack. s. > On Apr 29, 2016, at 9:29 AM, rabah.guedrez@orange.com wrote: >=20 > If we consider SRH insertion with IPv6 PHP, the original destination addr= ess would be lost when removing the SRH, > The packet reaches the egress with a DA that matches egress address, but = no other information how to forward the packet to its final destination > =20 > =20 > > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com > =20 > =20 > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : jeudi 28 avril 2016 13:46 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > =20 > There are many operators and use cases where, instead of encapsulation, s= rh insertion is a far better option. >=20 > In fact all current implementations are doing srh insertion. >=20 > Still, from a spec perspective, the srh processis the same.=20 >=20 > s. >=20 > -----Original Message-----=20 > From: rabah.guedrez@orange.com [rabah.guedrez@orange.com] > Received: Thursday, 28 Apr 2016, 12:58 > To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] > CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org] > Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 > You have said in a previous response to a question that the draft only co= nsider the encapsulation of client packet into a new IPV6 header with SRH, = and not adding only an SRH to an existing packet. > Which make sense especially for service providers who would prefer to tun= nel client traffic (not modify the header of the client packets for securi= ty reasons). >=20 > If you only consider encapsulation, does keeping c-flag relevant? > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : jeudi 28 avril 2016 12:31 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 > On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > >=20 > > Rabah Guedrez > > Th=E9sard > > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > =20 > > Phone: +33 2 96 07 18 56 > > rabah.guedrez@orange.com > > =20 > >=20 > >=20 > > -----Message d'origine----- > > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 := =20 > > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :=20 > > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:=20 > > draft-ietf-6man-segment-routing-header-01.txt > >=20 > >=20 > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: > >>=20 > >> Hi, > >> I would like some clarification about the treatment of the SRH by an= =20 > >> end point (the node that its loopback matches the DA field), > >>=20 > >> In section 3 : > >> You say that the > >> C-flag: Clean-up flag. Set when the SRH has to be removed from > >> the packet when the packet reaches the last segment. > >=20 > >=20 > > the text is confusing but the semantic is correct ;-) > >=20 > > the cleanup flag is processed so that the last segment receives a packe= t without any SRH. > >=20 > > However, as you figured out, the processing of the C flag is done on th= e segment before last (penultimate segment). So, probably a more accurate t= ext would be: > >=20 > > C-flag: Clean-up flag. =20 > > Set when the SRH has to be removed from > > the packet prior to forward the packet=20 > > towards the last segment. > >=20 > >=20 > >=20 > >> Which mean that the last node inspects the SRH flags if the c-flag is = set, the node has to remove the SRH before sending the packet to its final = destination. > >>=20 > >> But In section 4.3. > >>=20 > >> You say that the node that decrements the Segments left pointer has=20 > >> to check if the c-flag is set when the new value of the segments left= =20 > >> point is equal to zero, If the c-flag is set and the segments left=20 > >> pointer =3D=3D 0 then remove the SRH, > >>=20 > >> What is confusing for me is that the node that decrements the pointer = is not the last node in the SR path (behavior similar to PHP for MPLS) , w= hich I find in direct contradiction with section 3. > >=20 > >=20 > > you're right. The node that processes the cleanup flag is the penultima= te segment, not the last. > >=20 > >=20 > >> Another question if a node receives a packet with the already segment= =20 > >> left =3D=3D 0, what should that node do with the packet(e.g., drops it= ?) > >=20 > >=20 > > a node receiving a packet where: > > 1. DA =3D=3D itself > > 2. a routing header is present > > 3. segments_left =3D=3D 0 > >=20 > > MUST ignore the routing header and process the packet normally. This=20 > > is described in RFC2460 section 4.4 > >=20 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the = packets. >=20 >=20 > no. >=20 > The c-flag is to be set when you insert an SRH into an existing packet. >=20 > You set the c-flag so to be sure the SRH is removed before delivering the= packet to its intended destination. >=20 >=20 > > if we consider that setting the c-flag is not obligatory, then the egr= ess would receive an SRH with : > > 1. DA =3D=3D itself > > 2. a routing header is present > > 3. segments_left =3D=3D 0 >=20 >=20 > when you use encapsulation and you don't set the c-flag, then the egress = receives the packet as you described above. >=20 >=20 > > The SRH has to be ignored based on RFC2460, is that corre= cts ? >=20 >=20 > yes, the above is normal behavior when the path is completed (i.e.: all s= egments have been processed and the DA is the intended destination of the p= acket). >=20 >=20 > > which in my opinion is not the intended behavior . >=20 >=20 > can you explain what you mean by "not the intended behavior" ? >=20 > s. >=20 >=20 > > s. > > Rabah > >=20 > >>=20 > >>=20 > >> Bests. > >>=20 > >>=20 > >> > >>=20 > >> Rabah Guedrez > >> Th=E9sard > >> ORANGE/IMT/OLN/WTC/IEE/ITEQ > >>=20 > >> Phone: +33 2 96 07 18 56 > >> rabah.guedrez@orange.com > >>=20 > >>=20 > >> _____________________________________________________________________ > >> ____________________________________________________ > >>=20 > >> Ce message et ses pieces jointes peuvent contenir des informations=20 > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,= =20 > >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. > >>=20 > >> This message and its attachments may contain confidential or=20 > >> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and= delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > >> Thank you. > >>=20 > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >=20 > >=20 > > ______________________________________________________________________ > > ___________________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or=20 > > privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > > Thank you. > >=20 >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Fri Apr 29 09:56:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348E12D59E for ; Fri, 29 Apr 2016 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 5B2AKevRhLFM for ; Fri, 29 Apr 2016 09:56:15 -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 7CCA712D1A4 for ; Fri, 29 Apr 2016 09:56:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E7742009E; Fri, 29 Apr 2016 13:01:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1D6B16375A; Fri, 29 Apr 2016 12:56:14 -0400 (EDT) From: Michael Richardson To: Mark Smith Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] In-Reply-To: References: <12014.1461868866@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 16:56:18 -0000 --=-=-= Content-Type: text/plain Mark Smith wrote: >> 3) breaking AH in transit. While AH can deal with mutable headers, it > 4) troubleshooting modifications that cannot or cannot easily be > attributed to a specific node can be very time-consuming, require out > of hours work and are likely to require potentially disruptive packet > capturing within or downstream of each network element that could have > modified the packet (assuming it is possible to access that NE or > link). I take your point very clearly. In some sense, I'm including this as "breaking AH", as this is my major concern. Something happens in the middle, and packets break, and we can't find out why/where it happened. But, given that we have mutable headers, isn't this an issue ANYWAY? Can we trust that only routers that are inserting headers (via encapsulation or not) are really the only ones that are potentially broken? Or to put it another way: given where we are in IPv6 deployment, particularly for some of the more exotic (non-IPv4-like) features, is there any field experience that the encapsulation actually helped do the diagnosis? Or is our experience limited to disasters that happened in IPv4-land? I have a side modification to the proposal that I'll put in another email. > 5) the source address has lost its semantics if more than one node is > responsible for the contents of the packet (within a layer) - it is now > a multi-source packet, yet only one source is recorded. This is what > makes troubleshooting hard, and causes things like PMTUD to fail - the > inability to completely attribute creation or modification of the parts > of the packet to the respective sources. I don't agree that it's what makes PMTUD fail. Stupid ICMP filters at large insitutions is what killed it. I could name the product which is regularly misconfigured by people who aren't reading this list, nor any NOG list, but I won't. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVyOSK4CLcPvd0N1lAQLh3wf/cu/XmQjGJV71yKJo9eX0PY4FKclGsC1E u1ynevpTKbAuO1AhDgIqYAc0/R7ObzEdu6UuiuqliR1RnFzMyMY8QUWo7Xx6Arl/ rSZCQOZZ9ENNOjfI7gNcQC6TvWdYQP3BYvWCEkBX25l+aGw3KnVYjtl9lWNvOOZ3 rDZ1JNDbRwzwUjfCwEzfT3K2M0r7/HsaY+O/DapXN1rR3yYEZipZJolry7O0uP6F L2n6rpo7vjVaNgWLKfOXfr+4CWQA13nL/tO8AvFmn3UcNrj6gifnN9BF1IuW8Coj t9O3NQRe9qrsbjCk+h8kWu1+KtgjX84HUQGkeGWXYMk7vDrdlT40NA== =5Euu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 29 10:08:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F164112D1A4 for ; Fri, 29 Apr 2016 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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 tqnjgpw-zo_4 for ; Fri, 29 Apr 2016 10:08:30 -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 9949912D1E6 for ; Fri, 29 Apr 2016 10:08:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 355382009E for ; Fri, 29 Apr 2016 13:13:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C683F6375A for ; Fri, 29 Apr 2016 13:08:29 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: when Inserting Extension Headers In-Reply-To: References: <12014.1461868866@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 17:08:33 -0000 --=-=-= Content-Type: text/plain If we decide that it's okay insert extension headers, then I suggest that only extension headers that have a Option Type top-two-bits that are "01" should be insertable. The third bit, mutable, MUST be set, I think. (You may be able to convince me that it should "11" rather than "01") My logic is that current devices that observe 2460 will drop packets with this Option Type, which is a really good defense against that header that was inserted, failing to be removed. Second, newer devices that observe 2460bis, could instead of dropping that extension, could rather remove/omit that extension header completely. This would probably permit AH to continue to work even if the header wasn't removed. (I'd love to also change the behaviour of AH so that one would ignore AH headers if one hasn't got a matching SPI#. That's what kept us from using AH to secure ND back in the SEND days) The LLN uses of insertable extension headers benefit greatly by inserting what they need, and not worrying about removing things before they get to the host. ===== And, it seems that "10", which creates ICMP Parameter Problem messages for multicast destinations, allows for amplication attacks, and we should deprecate that behaviour, period. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVyOVC4CLcPvd0N1lAQLU0wgAorZJUBrx4Jxpe8vDZCl2V//cB/mRYVu8 VKJGIKm6VmmFJXL/HUyua5ApUU1dHTd598fz0rSRCs8qZqAUalRCwDtCbhgKIy+z 6dcZjqB4qPj5dKlC+Gv7Iwoc6RtclhaT8KxGwTpcuQgg+8VazMylul8KQpTsETab R8T5BThU6CPmFauT7rIbhu3Ln1tI+FBEh+G5k5NyZKN7Bgl3nWHESWW/AF9vbJ15 F8p1+b9Q9kF38ltje70aDhh8JIjSNqLnfqPTG5QjF8SjsaeOYb/t5qHHLEyPm58t Y43JEQWuWptudiPFOm+uls3enOcemi8aJnAaXpqYdNWpljmPO1458Q== =yFY/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 29 12:05:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCD912D6E6 for ; Fri, 29 Apr 2016 12:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 1N8BzFj7PTHz for ; Fri, 29 Apr 2016 12:05:35 -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 41C3F12D519 for ; Fri, 29 Apr 2016 12:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9998; q=dns/txt; s=iport; t=1461956735; x=1463166335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2GMG9co/tbZFQZLq207f/1hKwTSPKjPMnRsA3gv7dzo=; b=ftXI/DiXMGImKoA3e/IQv61dFCYiUjpUamn/v+gUtzkbnpaitGqE7Vb6 jEhsiPXYy83bDcOk+JSfCMLYbyyKvV6jRU5zAfH1mdZmaTXK2Nr3BSpKi 6syiM10uKlOZG8xiosrC6LS0RI8kiUoDOsZRM/ajBVfBitIjPCyQ9+QSS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgC1ryNX/4UNJK1dgmxMU30GtHmEc?= =?us-ascii?q?wENgXYihW4CHIEROBQBAQEBAQEBZSeEQgEBBCMKTBACAQhCAgICMCUCBAENDYg?= =?us-ascii?q?iDrMtkSUBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEyHPYJWBZgTAYV7iBSPG?= =?us-ascii?q?I8vAR4BAUKCBRuBS2wBAQGHf38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208,217";a="267009525" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 19:05:34 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3TJ5YdG030760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 19:05:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 14:05:33 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 14:05:33 -0500 From: "Pascal Thubert (pthubert)" To: Mark Smith , Michael Richardson Subject: RE: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Topic: Inserting Extension Headers or not [was rfc2460bis question ] Thread-Index: AQHRoX2FAOBYLPBAKkq1py8LkOsNz5+gRowAgABNrcA= Date: Fri, 29 Apr 2016 19:05:31 +0000 Deferred-Delivery: Fri, 29 Apr 2016 19:04:39 +0000 Message-ID: <4af9c8a2c9c843f9a68f4d10e4c7fa5d@XCH-RCD-001.cisco.com> References: <12014.1461868866@obiwan.sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.225.61] Content-Type: multipart/alternative; boundary="_000_4af9c8a2c9c843f9a68f4d10e4c7fa5dXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 19:05:37 -0000 --_000_4af9c8a2c9c843f9a68f4d10e4c7fa5dXCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWFyazoNCg0Kw5ggIDQpIHRyb3VibGVzaG9vdGluZyBtb2RpZmljYXRpb25zIHRoYXQg Y2Fubm90IG9yIGNhbm5vdCBlYXNpbHkgYmUgYXR0cmlidXRlZCB0byBhIHNwZWNpZmljIG5vZGUg Y2FuIGJlIHZlcnkgdGltZS1jb25zdW1pbmcsIHJlcXVpcmUgb3V0IG9mIGhvdXJzIHdvcmsgYW5k IGFyZSBsaWtlbHkgdG8gcmVxdWlyZSBwb3RlbnRpYWxseSBkaXNydXB0aXZlIHBhY2tldCBjYXB0 dXJpbmcgd2l0aGluIG9yIGRvd25zdHJlYW0gb2YgZWFjaCBuZXR3b3JrIGVsZW1lbnQgdGhhdCBj b3VsZCBoYXZlIG1vZGlmaWVkIHRoZSBwYWNrZXQgKGFzc3VtaW5nIGl0IGlzIHBvc3NpYmxlIHRv IGFjY2VzcyB0aGF0IE5FIG9yIGxpbmspLg0KDQpEZXROZXQgaGFzIHRoZSBjb25jZXB0IG9mIFJl cGxpY2F0aW9uIGFuZCBFbGltaW5hdGlvbiwgd2hpY2ggY3JlYXRlZCBpbnRlcm1lZGlhdGUgc291 cmNlcyBhbmQgc2lua3MsIGFuZCBjZXJ0YWlubHkgb2JzZXJ2ZWQgdGhhdCBuZWVkLg0KDQpXZSBu b3RlZCB0aGF0IGFuc3dlciBpcyBub3QgbmVjZXNzYXJpbHkgdG8gYXZvaWQgcGxheWluZyB3aXRo IGhlYWRlci4gSXQgY2FuIGFsc28gYmUgdG8gcHJvdmlkZSB0cmFjZWFiaWxpdHkgb24gd2hhdCBo YXBwZW5lZCB0byB0aGUgcGFja2V0LCB3aG8gZGlkIHdoYXQuDQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1kdC1kZXRuZXQtZHAtYWx0LTAwI3NlY3Rpb24tNC4yLjcuMiBwcm92 aWRlcyBhIHdheSBvZiBkb2luZyB0aGF0IGluIHRoZSBkZXRuZXQgc3BhY2UgdGhhdCBhdm9pZHMg dW53YW50ZWQgY2hhdHRpbmVzcy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KDQoNCg0K --_000_4af9c8a2c9c843f9a68f4d10e4c7fa5dXCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEw NzgyODYyMDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xMTkzMzYwNTM2IDExNzQxNTcxNDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhl bGxvIE1hcms6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+NCkgdHJvdWJsZXNob290aW5nIG1vZGlmaWNhdGlvbnMgdGhhdCBjYW5ub3Qgb3IgY2Fubm90 IGVhc2lseSBiZSBhdHRyaWJ1dGVkIHRvIGEgc3BlY2lmaWMgbm9kZSBjYW4gYmUgdmVyeSB0aW1l LWNvbnN1bWluZywgcmVxdWlyZSBvdXQgb2YgaG91cnMgd29yayBhbmQgYXJlIGxpa2VseSB0byBy ZXF1aXJlIHBvdGVudGlhbGx5IGRpc3J1cHRpdmUgcGFja2V0IGNhcHR1cmluZyB3aXRoaW4gb3Ig ZG93bnN0cmVhbQ0KIG9mIGVhY2ggbmV0d29yayBlbGVtZW50IHRoYXQgY291bGQgaGF2ZSBtb2Rp ZmllZCB0aGUgcGFja2V0IChhc3N1bWluZyBpdCBpcyBwb3NzaWJsZSB0byBhY2Nlc3MgdGhhdCBO RSBvciBsaW5rKS48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5EZXROZXQgaGFzIHRoZSBjb25jZXB0IG9mIFJlcGxpY2F0aW9uIGFuZCBFbGltaW5hdGlv biwgd2hpY2ggY3JlYXRlZCBpbnRlcm1lZGlhdGUgc291cmNlcyBhbmQgc2lua3MsIGFuZCBjZXJ0 YWlubHkgb2JzZXJ2ZWQgdGhhdCBuZWVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIG5vdGVkIHRoYXQgYW5zd2VyIGlzIG5vdCBu ZWNlc3NhcmlseSB0byBhdm9pZCBwbGF5aW5nIHdpdGggaGVhZGVyLiBJdCBjYW4gYWxzbyBiZSB0 byBwcm92aWRlIHRyYWNlYWJpbGl0eSBvbiB3aGF0IGhhcHBlbmVkIHRvIHRoZSBwYWNrZXQsIHdo byBkaWQgd2hhdC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdC1kZXRuZXQtZHAtYWx0LTAwI3NlY3Rp b24tNC4yLjcuMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZHQtZGV0bmV0LWRwLWFsdC0wMCNzZWN0aW9uLTQuMi43LjI8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4NCiBwcm92aWRlcyBhIHdheSBvZiBkb2luZyB0aGF0 IGluIHRoZSBkZXRuZXQgc3BhY2UgdGhhdCBhdm9pZHMgdW53YW50ZWQgY2hhdHRpbmVzcy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDo0LjhwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4af9c8a2c9c843f9a68f4d10e4c7fa5dXCHRCD001ciscocom_-- From nobody Fri Apr 29 16:52:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF17112D756 for ; Fri, 29 Apr 2016 16:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 M26hrTFu2sML for ; Fri, 29 Apr 2016 16:52:29 -0700 (PDT) Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (nm17-vm2.bullet.mail.ne1.yahoo.com [98.138.91.93]) (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 26B8A12D791 for <6man@ietf.org>; Fri, 29 Apr 2016 16:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461973948; bh=8wKIPUEiVsrcc5pYSKIb5ki6Zvb7vRsK0f38FbnVdgg=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=XmB4mBXIK3a4LPzz4HJu0nzjAnZgCAPn2tNHJI7vlDNUdXkdpwF4ZUzn4VDSgxMmTf+BYYNOdIpLWum19CLugbEPdUjkthmtH2sHJIjluSlwEz8ePnVIp5nezEsAbJ8myX8DollyorGyPeyOymvngy2jvMcvt9kEJ6vL5ZPZBVtXlNSMWJVJU3TwWo0CQL2KCs2SVt8Acl1fOo7E6xGv2aSsxl3+SPeehaWYbV7AA4TNYtYh82HsFRyWtIu3LfiW0rBbalxpmcSJZ6YSKRXWR/Cd+GXroxJGwVDKJoNM15eMiXK3EY68xex9YUpMZS+xDaq2ze8Lfy4x4C3++1VnhQ== Received: from [98.138.100.112] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 Received: from [98.138.226.165] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 510642.93477.bm@omp1066.mail.ne1.yahoo.com X-YMail-OSG: BmBg_1sVM1ln34VrQBwJoR5igqXK7blDkUYC1YDgzK5E_V6yKQmveEWtKq5bufv OGon88D0XF73Ag.qQCIF0Jcp2Lnkxo0JSCLJqu6jLP2IvWygaAZujsghYEXL9su8PzLO2MZap_pX PaI35v_Yrd81vH1LtQnhfgl4OQjP6MvksaPFFcrkdluTWcx5rmOSkYKSGjf8vQT4X_iIVMeT7QO0 17f2ILIqEfpTj9YcHTLs6Q.JA.HjdRPDcyq43W_i4EfzftvIPbnUo7cKYEjgyG0uRFuIyGIT1iAH Plxyl7awj8S2ynFmhzdjl9sxoPqWxHMhUdB3GRUmu1vDFOtoGizlTr_51j0yzhuNCY0cO2iQYBjo Fo01vBi7cTu6WswegmksLPMh2rZn2JdGMXgJwtEJ2SbLvG6Mrl7Ovhhq6sbUIseNI.ed.1.7cpVF Yxdx88iNjsrZxH.b9w.CkECH8jsQR45VZN4CqtL0lNe2y_DE4qXWpWRCe3mRzFOEEahFw7zhPyHN W3ouLDY9UBF0TcVWZC5xPzyu02dtmwkEGSWAkSvAC8rT6BBMYrs4yR1Z.OkTB1XRknO1jcbG4ytm PitSMGDNFpKXTgG2eA3QcTwlQZ4mFJRxNNWoacwo4xKts4ZSbkHx. Received: by 98.138.105.213; Fri, 29 Apr 2016 23:52:28 +0000 Date: Fri, 29 Apr 2016 23:52:27 +0000 (UTC) From: To: V6ops List , "6man@ietf.org" <6man@ietf.org> Message-ID: <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> Subject: Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <384661159.3916418.1461973947146.JavaMail.yahoo.ref@mail.yahoo.com> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 23:52:31 -0000 People, We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. The first draft they are reading is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. I would appreciate your help very much for both of the following, please let me know. 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. 2. If you will be able to help them via email support only. Please help, if you can. BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. Thank you all very much. Nalini Elkins IETF Mentoring Team Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Fri Apr 29 18:04:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D954812D166 for ; Fri, 29 Apr 2016 18:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 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.996, 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 WRaSwXNgHtq7 for ; Fri, 29 Apr 2016 18:04:18 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 DBE5912D13F for <6man@ietf.org>; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id s8so34126868ign.0 for <6man@ietf.org>; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N4WvF4LMG/LYRXbzkURV8EtXmkc9yMX7g6zRXLiv90o=; b=KSwrFW/zssL0JyIx8hvjIuGbVJZcEUGA7nweKQSdLrUJMDZ42tuns4ZS1MvwtXjIwO LxnHYtRPQF/3oHNgpFWtVcqeKmOzNzaAlicxWRkB/7mXhiYIf6HEOQqyyS51jyVMOLmT 7Yap4kv1pkthnFq4syIbLrNIG4OJfoISv2cN5grsjFENabISUAlhO3GMkuN/e11vNtdg 1hugageOE0lCMcPlKAxrg39xKsyUIUPmeDYGNEOK61jJcLrgnXar4giKclWNoDGSLz7k xwMW8rH3C7Es6iz2/uhPsAzs3C0C1GqbAgSXUHttdqEMIZ3xb0Ryf5aS7VPpLPIdDAuM uNVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N4WvF4LMG/LYRXbzkURV8EtXmkc9yMX7g6zRXLiv90o=; b=dl55SiZZjzB3x6vYAYq0dTY6Ab/uqY6auA1V+p0ytnSvvi8QViJKLIZZ7+4XqvMpUa iVBlMzmQ+PhgtKtjyDVIpT10I2g0jb6eQApy/XjNcwSDEAQoiGHViOCACtxdij7/7Zij tc3+nCHIw1QIRKEv300alRuzuIrytssyMI+W+v8UpGjSZjfBYnOTeTfMV1bxBplpfjpi qUPjQrDhCs1dwycRllOYWnvln1rtPcUBnpCpQjIgQ651/fms1tq+0A7CABmut89eFQCh uVxIApfb3VRUy/DUhCGjfJuR17dlMH6kwSTR/SciOR8H4CQ0NkrNE60zLilARi8UmzYG 7gaA== X-Gm-Message-State: AOPr4FUbFD4qtKIguPKovgJcpK3+2wud03vbPB8M1kkcO6lV1wZYXFdJPFOh9SwSN6vtlaPZtmtaKkoIzw+MvftA X-Received: by 10.50.150.107 with SMTP id uh11mr7665979igb.1.1461978257107; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.84 with HTTP; Fri, 29 Apr 2016 18:03:57 -0700 (PDT) In-Reply-To: <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> References: <384661159.3916418.1461973947146.JavaMail.yahoo.ref@mail.yahoo.com> <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> From: Erik Kline Date: Sat, 30 Apr 2016 10:03:57 +0900 Message-ID: Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish To: nalini.elkins@insidethestack.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 01:04:20 -0000 Why start with a document in IESG review as opposed to, say, a document that still currently under discussion in a working group? On 30 April 2016 at 08:52, wrote: > People, > > > We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. > > This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. > > The first draft they are reading is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability > > They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. > > I would appreciate your help very much for both of the following, please let me know. > > 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. > > 2. If you will be able to help them via email support only. > > Please help, if you can. > > BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. > > > Thank you all very much. > > Nalini Elkins > IETF Mentoring Team > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 29 20:52:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18D212D54D for ; Fri, 29 Apr 2016 20:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable 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 Y6-nFPwC5Zar for ; Fri, 29 Apr 2016 20:52:25 -0700 (PDT) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (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 094AE12D1B1 for <6man@ietf.org>; Fri, 29 Apr 2016 20:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461988342; bh=uJpID9kSgxkJ6r+JSgeqm4ByT/8b36FrB/XYnpCLqH0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JzUaueM1/ukd4MQX3gVg1C+C1/SiHqW395Hb3ey3GybyPgnxUqd1poaR3xEIe+s+mnbHpXY+hrEiNMnqtBCk63q8E+kZToBOlG3oKP0RGBr0aX/z/7bdj4N83zZHFjmYjZEdZF82DzX1n/MRoXYcsZAGgfXQceRHWqDLCnH3xBgQRXTSR+RuajwGmzKwgdz+6B/jP5esC8Xm4+7FtxJnxtXIx2Ujgnq7ECtkGr3oFz/FObHx5E1pLE6zlYiDBqDYnwDYK0np6LlvxKjKneiHW/unR1A+JwDZUrWAyu0wOEeqNDKgZtg4YKNwEcudHsV/Tot8HWl1ARNvOPrmfBXeXg== Received: from [98.138.226.179] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 Received: from [98.138.89.170] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 899807.87287.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: IAmri_gVM1l1z6SYK7vK_ZI4PRmZEBktxpTb5HnlnDcLyblgZPB9BCBmJmqd4sq GCN8p4SHDjYV3a.eZQZyfgteM45WXIukZJFQ0yYmFrCmqW9Un_4RepH9O3hvvM6LJ3.MlLLXLHor 6I9rJ4QqbaFNKBZSLtIb7193qFzoG1faUMKbv.VsIPfOiyzRSRg5LiF7ZFqwCqeGWRH4cOcJvgw2 ujfLOpp.ExD.r9oT2NLKwyP9BgX0Ln.m42JkUi05p9twI9NYoWtuMgRNzFBxI99PpT7zzPl4578D BhHlwxhTFd0Da7h2DWUYzpdvX1M1NrfUi17kNYPOEMGT2uQVKmOleDEt.7BnLm9x0mXASAc1NVcd Dd6fVN2M579K434mitqx7GA5J9xcQ2_27n3_H48Vo_uuds_f_PNQRmofbqzyhqBqPuCzPRXPi6oM aLrux1TkMoYnvRAJAMUfERBTKGfVjx5vKNJiNYiGeJ0X9Z2TLusqa_HkrJQkpmgZOtlMBlHTHQBZ 11myJchofHVlXd0qUgnIEOaVJMRR_D0dtF5tfxeEJRpvTl1H_myXrVPz0E8k- Received: by 98.138.105.202; Sat, 30 Apr 2016 03:52:22 +0000 Date: Sat, 30 Apr 2016 03:52:21 +0000 (UTC) From: To: Erik Kline Message-ID: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 03:52:27 -0000 Erik, I am giving people space to find their interests. I told the team to look in either "Active Internet-Drafts" or "Related Internet-Drafts" for a drafts that seemed interesting to them. They came up with 5 drafts. The drafts they picked all happen to be in some phase of having been adopted by the WG. This is fine. The first one is: draft-ietf-v6ops-host-addr-availability-06 It will take time for a Review Team to become really functional and work together well. My hope is that over time, they will stay together & go through the drafts that are individual submissions as well. It will also take time to get a mentor (or mentors) integrated into the team. So, whatever they start with is fine. Actually, this may be more information than you were asking for, but my hope is that the Mentoring program introduce 3 other types of review groups: 1. Internet Draft Review teams (started) 2. Draft Authoring Teams (look for co-authors to help draft) 3. Draft refining teams (have a draft not yet submitted to WG, needs polish) 4. Dry run teams (draft has slot on agenda, needs help to prep) We will start a new type of team after each of the next 3 IETFs. Right now, I am concentrating on #1 - Internet Draft Review Teams. We have about 50 people signed up to be a part of such groups, so I need to get the process really worked out & the teams solid & we can move to the next step. Appreciate any comments. Thanks, Nalini Elkins IETF Mentoring Team Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Erik Kline To: nalini.elkins@insidethestack.com Cc: V6ops List ; "6man@ietf.org" <6man@ietf.org> Sent: Friday, April 29, 2016 6:03 PM Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish Why start with a document in IESG review as opposed to, say, a document that still currently under discussion in a working group? On 30 April 2016 at 08:52, wrote: > People, > > > We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. > > This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. > > The first draft they are reading is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability > > They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. > > I would appreciate your help very much for both of the following, please let me know. > > 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. > > 2. If you will be able to help them via email support only. > > Please help, if you can. > > BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. > > > Thank you all very much. > > Nalini Elkins > IETF Mentoring Team > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 29 22:54:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D112B04A; Fri, 29 Apr 2016 22:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 o-zENl1jI9Ae; Fri, 29 Apr 2016 22:53:56 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B4312B03F; Fri, 29 Apr 2016 22:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2705; q=dns/txt; s=iport; t=1461995636; x=1463205236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=frm/Il05DHin7xppBjlCHn5fUdYX6CeP3hVkK32A6xM=; b=ifPPHli1Ltk9OfhDWCNUjm+RzhvvkULyyOkjeDh6xl+ycCLt5rEpvZNb meOV/HAjE0QOTDySZgzEY35xSEw3T9E0NXLFCUIIlaAcEMtt50dVxBGGz 5dmHZvrAgNeO97qIqFpaNUSSdWDSN/8KcoBA+SlsgPAloLvT1enrIZzBJ g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAgAiRyRX/4UNJK1dgzhTfQa5ag6Bd?= =?us-ascii?q?iSFbAKBJDgUAQEBAQEBAWUnhEEBAQEDAXkFCwIBCBguMiUCBA4FDogUCA7DRgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIgXglaHaIIrBZgTAYMngWdtiBuPEY8vA?= =?us-ascii?q?R4BQ4I2gTVsiAJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,554,1454976000"; d="asc'?scan'208";a="268074565" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2016 05:53:54 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3U5rrJf006621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Apr 2016 05:53:54 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 30 Apr 2016 00:53:52 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Sat, 30 Apr 2016 00:53:52 -0500 From: "Fred Baker (fred)" To: Nalini Elkins Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish Thread-Topic: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish Thread-Index: AQHRoqSsxZDCHMWw6EyjN+b11r24tg== Date: Sat, 30 Apr 2016 05:53:52 +0000 Message-ID: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Erik Kline , V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 05:53:58 -0000 --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: >=20 > Erik, >=20 > I am giving people space to find their interests. I told the team to = look in either "Active Internet-Drafts" or "Related Internet-Drafts" for = a drafts that seemed interesting to them. >=20 > They came up with 5 drafts. The drafts they picked all happen to be = in some phase of having been adopted by the WG. This is fine. The first = one is: >=20 > draft-ietf-v6ops-host-addr-availability-06 I assume you're looking at = https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/.= You might want to think a little harder about its status. The = datatracker actually tracks four different statuses for a document - has = it been updated within the past six months (which we call "active"), = what has the working group done with it, what does the IESG think about = it, and what does the IANA think about it. In this case, it's active, it = has cleared the working group and submitted to the IESG, it's on the = IESG telechat scheduled next Thursday, and the IANA agrees that it = doesn't ask them to do anything. Erik's point is that, barring IESG objections, we're unlikely to change = it at this point. If the team wants to make a difference, in v6ops = draft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice. --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVyRIcEayAOS/EQ8MAQI13A/8D0CtY/18HiC71cAeO64hwl8vByldIOsN ZtvCwwq5xLTdyMPPr9bBE6GnHWZqpjtLVvuTJRbJPv+G4esra7wZ/Qg3n0lTUyaU XcqgOAThuIVq8bZLHkrIlQ9iYrdUnnszKJzWPNMb7DUMkr1S4SGB7iIapVNWwZUh bknkO1r6tz18VgSG5JC35841gLIVz+54lS5tysumB7bZPWe5oBUZTXGmmL58kSrH OtKjERNE6rEyILja3NjFJs7C3D0x/hvbAKMtLWUzEJY3PrbEpb8gPAls+FIstxEv pqS1OUhTVyRbSUwRVan0uP5rwZcg5vexm+zU0aj56eA5uSkBGLybn+KOc2G04dyq y36qFaM56PcTjGtaTT5YAlSvaGDAQqjSgUSQlUbeX121FhQVGXvE9JKpeHpfGMiw zSUL7RmaM+rFEs2eamU+nH3EjdDX3hMMm6oHBghTWojPhwdwD8MLeAXl1eentqDM mX1jlRI5lCvyaPwXYGFW7U2WlqqmFzlg/cMJYQku795lUJRXkFW2RddhzfHBCxPq OQWyo9UKj9FcXIBDNFihVcuf0jqHewiOPacOPNFR0mLZ4PMlmCLHktF5hNh2k6ir +ZjAgu0V5AJRI11rzR8KP7sAKPpbIRvAJh87fxEzqLOLMryVH4Y0vddEvMdgLly9 6VXUkAXWr7A= =SrUh -----END PGP SIGNATURE----- --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04-- From nobody Fri Apr 29 23:46:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA97D12B02B; Fri, 29 Apr 2016 23:46:07 -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 nF2midzURvmr; Fri, 29 Apr 2016 23:46:04 -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 3433712B00A; Fri, 29 Apr 2016 23:46:03 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a17so66736072wme.0; Fri, 29 Apr 2016 23:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y5YRkGrLOykykWaUuZ8WkoeZrBaKdt7N9uRCoI8wztE=; b=0VoR9jW75RO7fP4RTk4C6drIeNMXit8/WSkRKDZ5dQp7d/8PwcuUqc8kP2KUdepZ3O bKJzP5cy7r2uSqLpUob8bHCsU5GTqtJh0zZVeR8/FBONbk3b0Q8FiArZ8MGIvfCdTBHV UxE996bfszzcrpQDJEBCJnsZZprbVYdjUJ7i0p0LAyNvQiIiEW5PoXk1Qd9Zck95pyOk tGCqNLrT3gFCgE/1fwgAQZx/82cNznEnCGO+qbTj2a4wuXW0ofiI7bBZcM5cTi3dMvYk b1ZbECPnsw5TFh7sfF59b8AqoaHCZ/27PiAyafAFIc01Dulob975cbSizqweahcR5iSI i1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y5YRkGrLOykykWaUuZ8WkoeZrBaKdt7N9uRCoI8wztE=; b=VAYi0Q/Rye8WF4Py+N10e9qcezOe7YByiXisqdORVQDiRpDCe9TfNq/xBNgNBANWiF S1QeuUXEAmJkAglHMP10S5tHnx2rnKx0uHVydA2VKH2VJ/Ol84tBj/+SqJUSrRId2NlA +gS2iMv1CBl50bpsXeEQqxr3AuwcqOG8IyX7RLLNgzUbykuU2/NLFN79o4i9UwzJt/zn DqgaHxD1/O0twjLRw9xkPZsG/8v0vwZsiX1iXgeIoVP1ebul6EWAYdDf9apozLHEu1ZC 5B/SMlm0b3RvZmCU+juOHoNc4C3ykeOgkh7AsZQxBZEgpVPKnr2MwkpAQvWSL3a8eQdW /K1g== X-Gm-Message-State: AOPr4FVH5RNfru+kCRxqnPM5EZ2PpKXFZ5KaHDyaj03sZBGzhOFB0QX6YVTFO8cukzkprtCcDOKX62hyDu9tVg== X-Received: by 10.194.37.106 with SMTP id x10mr25884198wjj.135.1461998761804; Fri, 29 Apr 2016 23:46:01 -0700 (PDT) MIME-Version: 1.0 Sender: edwinsc@gmail.com Received: by 10.28.181.143 with HTTP; Fri, 29 Apr 2016 23:45:32 -0700 (PDT) In-Reply-To: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> From: Edwin Cordeiro Date: Sat, 30 Apr 2016 08:45:32 +0200 X-Google-Sender-Auth: HjVVZwBY8T1bp0Mw02uoyX425fg Message-ID: Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b603e2adc0a4e0531ae1c44 Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 06:46:07 -0000 --047d7b603e2adc0a4e0531ae1c44 Content-Type: text/plain; charset=UTF-8 Nalini, I'm not sure if I have enough experience to be a mentor, but I'm willing to help if you think I can. BR Edwin Cordeiro On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker (fred) wrote: > > > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: > > > > Erik, > > > > I am giving people space to find their interests. I told the team to > look in either "Active Internet-Drafts" or "Related Internet-Drafts" for a > drafts that seemed interesting to them. > > > > They came up with 5 drafts. The drafts they picked all happen to be in > some phase of having been adopted by the WG. This is fine. The first one > is: > > > > draft-ietf-v6ops-host-addr-availability-06 > > I assume you're looking at > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/. > > You might want to think a little harder about its status. The datatracker > actually tracks four different statuses for a document - has it been > updated within the past six months (which we call "active"), what has the > working group done with it, what does the IESG think about it, and what > does the IANA think about it. In this case, it's active, it has cleared the > working group and submitted to the IESG, it's on the IESG telechat > scheduled next Thursday, and the IANA agrees that it doesn't ask them to do > anything. > > Erik's point is that, barring IESG objections, we're unlikely to change it > at this point. If the team wants to make a difference, in v6ops > draft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b603e2adc0a4e0531ae1c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nalini,

I&= #39;m not sure if I have enough experience to be a mentor, but I'm will= ing to help if you think I can.

BR

Edwin Cordeiro

On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker = (fred) <fred@cisco.com> wrote:

> On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote:
>
> Erik,
>
> I am giving people space to find their interests.=C2=A0 =C2=A0I told t= he team to look in either "Active Internet-Drafts" or "Relat= ed Internet-Drafts" for a drafts that seemed interesting to them.
>
> They came up with 5 drafts.=C2=A0 The drafts they picked all happen to= be in some phase of having been adopted by the WG. This is fine.=C2=A0 The= first one is:
>
> draft-ietf-v6ops-host-addr-availability-06

I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-ava= ilability/.

You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has th= e working group done with it, what does the IESG think about it, and what d= oes the IANA think about it. In this case, it's active, it has cleared = the working group and submitted to the IESG, it's on the IESG telechat = scheduled next Thursday, and the IANA agrees that it doesn't ask them t= o do anything.

Erik's point is that, barring IESG objections, we're unlikely to ch= ange it at this point. If the team wants to make a difference, in v6ops dra= ft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice.

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


--047d7b603e2adc0a4e0531ae1c44-- From nobody Sat Apr 30 06:25:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0203412D13F for ; Sat, 30 Apr 2016 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 GurNeX-0UrUy for ; Sat, 30 Apr 2016 06:25:13 -0700 (PDT) Received: from nm19-vm5.bullet.mail.ne1.yahoo.com (nm19-vm5.bullet.mail.ne1.yahoo.com [98.138.91.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 EFF5C12B013 for <6man@ietf.org>; Sat, 30 Apr 2016 06:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462022712; bh=v/r4oTfgFBE0gNktijSFH2kVDdL9/DYFW2q/pjMrYOs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=o3Ty+/kN6nf/0SvZ8vvMYEkB1FyzBp7MkpKhfnv/nsH/yIbik/w2FVmlnQtWtwrw55v8lwvtO/8OYo9yhev0533ctW+C4rAVs7yYe3n5eeJcZmDn4BpCM75NLF0+t+a/f7DX1RCjCeBFIicXaEmVM8Lk9e5sUrALjWaAxR+W9Onoi+tQxD02FZO9G3Rn3QLcYrEpqg7UWFg5/jCb+nQ9UvlpvSLO7699mulu8c7w8R96U49HmQaRRRSWEsXos9s9bY8rU0cPfGuINfCr1fX5VVqQkhMGucxYpuqBiIuamw4oTmwTL5X6qJV2wXOFCn02Q7AH7QPFCt5hq/Q8EPNBWg== Received: from [98.138.100.112] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:12 -0000 Received: from [98.138.87.7] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:11 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 974687.68079.bm@omp1007.mail.ne1.yahoo.com X-YMail-OSG: HIs3kRsVM1mCEIEyXpFuNDrX6Qw2rzU.2EYDU6w5UDLDRexxBzyJpnVxq9gHRlD 5w8SY3CMBuWodWLDXF_QJ_8xFNeqoei4GVmv1ySs.Vn1J.qXrxo_vGTUZXOL2Ddevk67hJPOgJzv yLPWHzJ8b47YSfoOlSO28va1jtPPPpUMJF33lzxtK3UjxAnLBc_gvsTUT.VJg._VkHLD_2td4Bfd 14dVFWPgJHT_4UdkQss0qH7_CX3vae9haoiBM.blrptvT9I59hwnXGS_nYhL98SpDUwYcvFGb5wT 9pVrZFTyUBAnbid_V0RpgpPLElq9j1quVyqlbbYck5fgV0p3_SHe62.uL8J_cAhBe8arZrBNBsSW 3hkRuH6801gLGGbsWXRE4fb7q_Ko0MYPhyeGrB8bNs4DdP3EJSJQTHjL1h76qIM5toqdJHQH34nL 06lAztpIXIahzxELk24h4z26mNHfw2i2eRtptDW0qiid6dFa7u9ZdOC7eAKylGf4eerIz77Z.fkp cdODMmf6e_MX8u1YhEt4xw32Eia_QBdxnmW6haz.SwQ9LM2COZCfS35Up_Th5ZoJNlaQVSNbIDzT jgF25OJItJ5I- Received: by 98.138.105.227; Sat, 30 Apr 2016 13:25:11 +0000 Date: Sat, 30 Apr 2016 13:25:10 +0000 (UTC) From: To: "Fred Baker (fred)" Message-ID: <433694511.4134048.1462022710928.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4134047_99542133.1462022710926" Archived-At: Cc: Erik Kline , V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:25:15 -0000 ------=_Part_4134047_99542133.1462022710926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> I am giving people space to find their interests.=C2=A0 I told the team = to look in either "Active Internet-Drafts" or "Related Internet-Drafts" for= a drafts that seemed interesting to them. >>=20 >> They came up with 5 drafts.=C2=A0 The drafts they picked all happen to b= e in some phase of having been adopted by the WG. This is fine.=C2=A0 The f= irst one is: >=20 >> draft-ietf-v6ops-host-addr-availability-06 >I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6o= ps-host-addr-availability/. >You might want to think a little harder about its status. The datatracker = actually tracks four different statuses for a document - has it been update= d within the past six months (which we >call "active"), what has the workin= g group done with it, what does the IESG think about it, and what does the = IANA think about it. In this case, it's active, it has cleared the working = group >and submitted to the IESG, it's on the IESG telechat scheduled next = Thursday, and the IANA agrees that it doesn't ask them to do anything. >Erik's point is that, barring IESG objections, we're unlikely to change it= at this point. If the team wants to make a difference, in v6ops draft-ietf= -v6ops-unique-ipv6-prefix-per-host=C2=A0>would be a better choice. Thanks for explaining. =C2=A0The other drafts that the group is interested = in are: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/ https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ draft-ietf-v6ops-ipv6-ehs-in-real-world-02 =C2=A0=20 But, I will suggest=C2=A0draft-ietf-v6ops-unique-ipv6-prefix-per-host to th= em. Thanks,Nalini =C2=A0 ------=_Part_4134047_99542133.1462022710926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>> I am gi= ving people space to find their interests.  I told the team to look i= n either "Active Internet-Drafts" or "Related Internet-Drafts" for a drafts= that seemed interesting to them.
>>
>> They came up wit= h 5 drafts.  The drafts they picked all happen to be in some phase of = having been adopted by the WG. This is fine.  The first one is:
>= ;
>> draft-ietf-v6ops-host-addr-availability-06

>I assu= me you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host= -addr-availability/.

>You might want to think a little harder abo= ut its status. The datatracker actually tracks four different statuses for = a document - has it been updated within the past six months (which we >c= all "active"), what has the working group done with it, what does the IESG = think about it, and what does the IANA think about it. In this case, it's a= ctive, it has cleared the working group >and submitted to the IESG, it's= on the IESG telechat scheduled next Thursday, and the IANA agrees that it = doesn't ask them to do anything.

>Erik's point is that, barring IESG objections, we're unl= ikely to change it at this point. If the team wants to make a difference, i= n v6ops draft-ietf-v6ops-unique-ipv6-prefix-per-host 
>would be a better choice.
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20109">
Thanks for explaining.  The other dr= afts that the group is interested in are:

https://datatracker.ietf= .org/doc/draft-ietf-v6ops-ula-usage-considerations/
https://datatracker.= ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
https://datatracker.= ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/
draft-ietf-v6ops-ipv6-ehs= -in-real-world-02
 
But, I will suggest draft-ietf-v6ops-unique-ipv6-prefix-per-host to them.
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20161">
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20161">Thanks,
Nalini
 

------=_Part_4134047_99542133.1462022710926-- From nobody Sat Apr 30 06:30:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3CC12B01D for ; Sat, 30 Apr 2016 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 jRwc6YQCWPS1 for ; Sat, 30 Apr 2016 06:30:42 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (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 7EC7512D101 for <6man@ietf.org>; Sat, 30 Apr 2016 06:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462023041; bh=tmQLQZ0+IBzrcI77Sr/Aley6sG0zXCl6Bn8yaiU8p5A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XM7EZArDonQd3I6PlZ8Qegj5/s8URSfxSx8h9dyOeIbQvGihNPvy/m0zFPNQ4YCHMVmW6ltI9PEKyJPLNoJcScAnc/YcugV0FMpMXp6jRGvTfOZH5aRMIVOajdhhZz8D11mSqCsSFr/aggo4K/xNf5PerCbK96wvA0uWuEnw/Zf7ZIzclNjncQDRl3At4o+Y1EEFNdkdj3OOhlXtDdnwxr//5nrKLka0sf7ajTW4eogXexzWn69n8Ulp4JUkWeNFwSkxH42Zn33cuYwALiNrR3iKxuP4BRpgRmzGvBNkkci4CcBElLg5Cy4AXZmUyLzAxPZzFnmlKnXp41677qlnFQ== Received: from [98.138.226.176] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 Received: from [98.138.89.252] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 540723.74005.bm@omp1044.mail.ne1.yahoo.com X-YMail-OSG: ldKKK24VM1mRXv2XZRnlL5ThlOUvxCNhz17xCO5k2BEVPFQm.j3VM8Q7__KV589 a0CxqV2mlLRPm5hqf8OvMcOXCrDvcWw4sCkMgGw0ZI77gaGxF6p3KBiglQa8i10ldSp2gAiQm6NI SJ1FZ.OMA1lPdLJ4RpR6kWb2tLbD._L354rNDoHj8yofiSesM5iNYrQSCSCCYaXlV9VdRyQM0u58 JkRsHnolXwxGGj3f4OXhMgVrigjR0leXudvbVHLVuLoA4oA6juzTdLf44P_v5tUHjIMU8cqAFIfg rKJf3mIzcusohjcbtGup43dNY9.Qwg1Dx4BHArr.QEvKcjP83wvvOTl_JM3VK7IoIL5cJrG9GXZk c5.hnx0ALjWZIDBUJkpTPb6r_d.1X8LCdpPNN4klhpV7Ths5fO.q80bKdskBBnv4unjYuKpyCM4h qVY4YNyHG50cbAtjrHNQd8tw2BRISiKtBciS7ccwJ7lngpdE2fXtw1SLLjfWgiEmP08btYHMw1Sa _92xwxqmUhXbB Received: by 98.138.105.253; Sat, 30 Apr 2016 13:30:41 +0000 Date: Sat, 30 Apr 2016 13:30:40 +0000 (UTC) From: To: Edwin Cordeiro , "Fred Baker (fred)" Message-ID: <2114139823.4097517.1462023040623.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4097516_73119864.1462023040618" Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:30:46 -0000 ------=_Part_4097516_73119864.1462023040618 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Edwin. =C2=A0I am sure you will be great.=C2=A0Ideally, I want each= team to have 2 mentors who can participate in webinars (1 hour per month) = and email contact and a third mentor who can participate by email only. =C2= =A0 This way, no one is overly burdened & there is no bottleneck (where no = mentors are available.) So, folks, if we can get 2 more mentors, that will be wonderful. =C2=A0 Nalini From: Edwin Cordeiro To: Fred Baker (fred) =20 Cc: V6ops List ; "6man@ietf.org" <6man@ietf.org>; "mentorin= g-coordinators@ietf.org" ; Nalini Elkins <= nalini.elkins@insidethestack.com> Sent: Friday, April 29, 2016 11:45 PM Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor Needed: Intern= et Draft Review Team: v6ops / 6man/ sunset4 : Spanish =20 Nalini, I'm not sure if I have enough experience to be a mentor, but I'm willing to= help if you think I can. BR Edwin Cordeiro On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker (fred) wrote: > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: > > Erik, > > I am giving people space to find their interests.=C2=A0 =C2=A0I told the = team to look in either "Active Internet-Drafts" or "Related Internet-Drafts= " for a drafts that seemed interesting to them. > > They came up with 5 drafts.=C2=A0 The drafts they picked all happen to be= in some phase of having been adopted by the WG. This is fine.=C2=A0 The fi= rst one is: > > draft-ietf-v6ops-host-addr-availability-06 I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6op= s-host-addr-availability/. You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has the working = group done with it, what does the IESG think about it, and what does the IA= NA think about it. In this case, it's active, it has cleared the working gr= oup and submitted to the IESG, it's on the IESG telechat scheduled next Thu= rsday, and the IANA agrees that it doesn't ask them to do anything. Erik's point is that, barring IESG objections, we're unlikely to change it = at this point. If the team wants to make a difference, in v6ops draft-ietf-= v6ops-unique-ipv6-prefix-per-host would be a better choice. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ mentoring-coordinators mailing list mentoring-coordinators@ietf.org https://www.ietf.org/mailman/listinfo/mentoring-coordinators ------=_Part_4097516_73119864.1462023040618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Edwin.  I am sure you will= be great.
 
Ideally, I want each team to have 2 mentors who= can participate in webinars (1 hour per month) and email contact and a thi= rd mentor who can participate by email only.   This way, no one is ove= rly burdened & there is no bottleneck (where no mentors are available.)=

So, folks, if we can get 2 more mentors, that= will be wonderful.  

Nalini


From: Edwin C= ordeiro <edwin@scordeiro.net>
To: Fred Baker (fred) <fred@cisco.com>
Cc: V6ops List <v6ops@ietf.org>;= "6man@ietf.org" <6man@ietf.org>; "mentoring-coordinators@ietf.org" &= lt;mentoring-coordinators@ietf.org>; Nalini Elkins <nalini.elkins@ins= idethestack.com>
Sent:<= /b> Friday, April 29, 2016 11:45 PM
Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor N= eeded: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish

Nalini,

I'm not sure i= f I have enough experience to be a mentor, but I'm willing to help if you t= hink I can.

BR

<= div dir=3D"ltr">
Ed= win Cordeiro

On Sat, Apr 30, 20= 16 at 7:53 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com = wrote:
>
> Erik,
>
> I am giving people space to find their interests.   I told t= he team to look in either "Active Internet-Drafts" or "Related Internet-Dra= fts" for a drafts that seemed interesting to them.
>
> They came up with 5 drafts.  The drafts they picked all happen to= be in some phase of having been adopted by the WG. This is fine.  The= first one is:
>
> draft-ietf-v6ops-host-addr-availability-06

I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-= addr-availability/.

You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has the working = group done with it, what does the IESG think about it, and what does the IA= NA think about it. In this case, it's active, it has cleared the working gr= oup and submitted to the IESG, it's on the IESG telechat scheduled next Thu= rsday, and the IANA agrees that it doesn't ask them to do anything.

Erik's point is that, barring IESG objections, we're unlikely to change it = at this point. If the team wants to make a difference, in v6ops draft-ietf-= v6ops-unique-ipv6-prefix-per-host would be a better choice.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops<= /a>


=



= ------=_Part_4097516_73119864.1462023040618-- From nobody Sat Apr 30 18:53:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBE612D18E for ; Sat, 30 Apr 2016 18:53:45 -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 AYoZ9GGeAHzk for ; Sat, 30 Apr 2016 18:53:42 -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 9B90712D166 for ; Sat, 30 Apr 2016 18:53:42 -0700 (PDT) Received: from [192.168.123.130] (unknown [179.40.197.201]) (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 C5EB7802FF; Sun, 1 May 2016 03:53:34 +0200 (CEST) Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ] To: Brian E Carpenter , Ralph Droms , Ronald Bonica References: <17698869-50BC-42EB-AE49-62246080A374@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5722B3FA.1090707@si6networks.com> Date: Thu, 28 Apr 2016 22:08:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 01:53:45 -0000 On 04/28/2016 09:37 PM, Brian E Carpenter wrote: > On 29/04/2016 04:34, Fernando Gont wrote: > >> mmm... I guess you don't need ietf permission to violate the specs in >> your own walled garden? > > Since the protocol police have been very quiet recently, that is a fact of > life. However, if we want to be explicit about it (after 2460bis) we could > write it up. I fully agree. What I meant is: the fact that you could potentially make something work in a walled garden doesn't seem an argument to legitimize that behavior -- particularly when I guess we're supposed to be standarizing more for the general case than for the walled garden case. > Diffserv already allows domain-specific packet mutations; the > flow label tolerates mutations in certain circumstances. I don't see why > we couldn't also describe the circumstances in which other header mutations > are allowed. But first, define the precise meaning of "the open Internet." Have this mutations the same potential implications as the insertion/removal of EHs? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492