From nobody Mon Oct 2 02:21:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA2133341; Mon, 2 Oct 2017 02:20:56 -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=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uToPybDIa4HE; Mon, 2 Oct 2017 02:20:55 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4464F134534; Mon, 2 Oct 2017 02:20:55 -0700 (PDT) Received: from h.hanazo.no (77.16.36.219.tmi.telenormobil.no [77.16.36.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 31B592D4FA6; Mon, 2 Oct 2017 09:20:54 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4E2C4111936E1; Mon, 2 Oct 2017 11:20:54 +0200 (CEST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_4EA78C71-8C54-4700-82F6-68F7069018A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 6MAN IETF100 Call for agenda items Message-Id: Date: Mon, 2 Oct 2017 11:20:53 +0200 Cc: 6man-chairs@ietf.org To: 6man WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 09:20:57 -0000 --Apple-Mail=_4EA78C71-8C54-4700-82F6-68F7069018A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The 6MAN chairs are planning the meeting in Singapore at IETF100. If you have a draft you would like to discuss, please send your request = for agenda time to the 6man chairs. Please include in the request, the = title of the presentation, file name of the draft, the speaker's name = (and email), and how much time you would like. We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, please plan your presentation accordingly. New drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to have support from the working group are = unlikely to get time at the meeting. Please have agenda items to us by 2017-10-30. Remember the draft cut-off date is also 2017-10-30 (2 weeks before the = meeting). Regards, Bob & Ole --Apple-Mail=_4EA78C71-8C54-4700-82F6-68F7069018A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnSBPUACgkQvtpYqJhC 33Yn9Q//aVcRyBW//eo1no65JE9E+ATJbnPCCW1dOxZd/Q7YQ5oKVk26FuiTgKq/ +bP0TtREtNwJliPFLxa3wnsMOc/wjfKSf7XWhnAlNlJYtDz1v250iP524i5QezIi pzQnvUD3r2daDNRtstaDGG7nEHBlLMUEXMvTlOsaHTaRfLGfllFhCG14P0bf98ug pz/EvNJtQQbTfxJV6s7HDt82ExluZmSRAU5jYLlCv+W7Ea+DpG+Upb2JHb2NuMLg VtXfrUKuu4+CRmZBqF4G+3/TzVjM/DsPRPLNgtnAK9xheDmPkxA+jmpBOgB7BC/m vIT/5opuieKl/1pZ955B8ZceHz4LXaHJCNA2s8wbbgPcnO450LIsmvAjk4kJGx1/ CKhVQCnKH7pH0i7x4aKgZwXFOZVOY5za9viPGkw78tnV+xRn+ubDwjd4EbwsSLl8 fIt0V0k6vLnXL4n2zJ4n9DXbQI3cJ1hEwdx2rogMBpr9O8YwdDJmAfyLUKC7+ctJ hVxunEwVYYXXua+NUQ7VWMdD2fzDKrNAuEpExIbsgM7COw1ZB147gp7gnnoXTG3E spYxyFfV1af/+AUmnRzZbkWWhY1ZToaIoxomvzUV8xDHcHexrwkCI2ocz4gQFRs0 GuJJkXXHPb9V+dAQQpGXgSO+hdLGG/MuZ5XH3SJUhtV7LqM0ZKs= =s79k -----END PGP SIGNATURE----- --Apple-Mail=_4EA78C71-8C54-4700-82F6-68F7069018A4-- From nobody Mon Oct 2 19:54:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3450B1342FA; Mon, 2 Oct 2017 19:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxZDAknrCab8; Mon, 2 Oct 2017 19:53:48 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC481342F5; Mon, 2 Oct 2017 19:53:48 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id b21so4733946qte.2; Mon, 02 Oct 2017 19:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=b1Uti1sHm8nCHQf24gwJuWB9MEBq4wvMkGqBp4H6Bgc=; b=umLp7oSAmBe2rJK++fJv5Bcf5x3DzFsZvfLWoHVoyADse8BF4uzDFnx1vEwHGed36m lRCWVCD/JmhkXZTdylwszT9IFCoKMT2LDVkFejAW7E3F89JwkdBbZK7ydeGw4JVckgjt d+Gl/RT2YAEH/wmpunuOjqr6id0XKmo2YYa1u6Bv+5VzkKC5NQBPxLIgq2VTkXzX/WTm pVHCLVlEfECJ+BCBuQ4Rp2M5YWtPRllmj3uszuLDQV8SLgaqqc8FKl+b8ol6N0/DGMVG 6BXFP9yulgOZ83FCtAo9etJosL9Km+IUWrdodj+LkIOSzrNdjFPSKhPNDN/NvTZQtgji WKqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=b1Uti1sHm8nCHQf24gwJuWB9MEBq4wvMkGqBp4H6Bgc=; b=DUq+zU0vqMpWMpaKJvunNreT7usxfr0tRE89Gjckvq3iLZBGWP66m4kt4reaVDHTFs UcZKPWq03H6yiAbmMiw0EvVBJC8EOBnrGvKPUlu2XDyyWWgP0HxrN99flPVfg1twkaf8 v7uQEVF3rSAQjJ4YKhjXSIy1AwZR+sJ2MS1L+8IA4RzPC/x+lVdUTHjpTQD3KwkdobIV jKQ1ud8OUOvT5HGzJOzlik+gG0nQQ2fhaj0XKC/rzZGmyUdh0JLjZlzpWVnF9pmPkqYQ bMQ3wL4WzdqeHSP+WeNve8kDwaCOM03Do69oMVFRrFJ48Kb8lN64GbWO7ncY7KjRZhAU FTPA== X-Gm-Message-State: AHPjjUhd/p3pYCV8JH+B4X0GlPYWNDTDRN85KKr2KmGw06CMheSlvMxy muOC2xp9EypYv/vGrklMW8+Aoo18snc= X-Google-Smtp-Source: AOwi7QBV+uzm3KcJwSwtK0/U7Wcy3PlmNMBEcjlOeAdkuDVKsNCiQUohCj5ICPZWGGXZdPmtU27gTQ== X-Received: by 10.129.78.207 with SMTP id c198mr14223215ywb.121.1506999227029; Mon, 02 Oct 2017 19:53:47 -0700 (PDT) Received: from [10.0.0.12] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id h129sm4647621ywb.67.2017.10.02.19.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 19:53:46 -0700 (PDT) From: Suresh Krishnan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Liaison statement received from ITU-T regarding a "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment" Message-Id: Date: Mon, 2 Oct 2017 22:53:45 -0400 To: 6lo@ietf.org, 6man WG , 6tisch@ietf.org, int-area , int-dir@ietf.org, iot-dir@ietf.org, its@ietf.org, lp-wan@ietf.org, lwip@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 02:53:50 -0000 Hi all, The IETF has received a liaison statement from the ITU-T that their = Study Group SG20 is inviting inputs from the IETF regarding a work item = titled "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment=E2=80=9D and the deadline for providing inputs is 2018/01/28. = The statement can be found at=20 https://datatracker.ietf.org/liaison/1546/ I have no further info and I am trying to get access to the referenced = documents. I just want to provide a heads up while that is in process. Thanks Suresh From nobody Tue Oct 3 01:42:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD22134B7C; Tue, 3 Oct 2017 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8UJTZsjCbAH; Tue, 3 Oct 2017 01:42:23 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 9DA4D132F3E; Tue, 3 Oct 2017 01:42:23 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id i35so2107095uah.9; Tue, 03 Oct 2017 01:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2oLfJMVJk+OBVg8Au/bT6/U2CSf3PkxgQSFq/HxrNi0=; b=uWnSOr8cm3y1NSRI+J/pz6+wtxZAsmN3kmSQz55tWxd/arrfEGAdKEoVO2LbzUcKlB bsU6ZhJlhc6idmXOGmdV/k0SOHTBqPKVFLn0lJmoeSLLd3wgpCRdprNBQbxalS+v94uG 0Yg6CVV+5A6TWYJLZh69eOwxsmaHmFqEvXxA6R64nZh7KCOR2Obk7z2FCjSJMP7aU+w/ NG4jWbFQtAvJsRmSR7eS4oYrNrrHNyEgw5iov+pmGJbL8VMAHe0LRhku7H57nR9OvSeV vlwzFCWVUQvUO1mdcRSdvra/yhThrl7ZOHHaajqjrvMYS/sH+rE2UQPLWxt6lJlkW0PC ypiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2oLfJMVJk+OBVg8Au/bT6/U2CSf3PkxgQSFq/HxrNi0=; b=qnnyzMZOyCCPpZSNyFr7bpKCh9ubdIgaaql+Mt75ZxPa6Gsr712Qt9c7CLyR7DESKY F7Mbtv3nK4dqnnToJVE1YFzQ+glrgFz4F7weFekYTxIM4uyg269o9rahSmpwdxyGZc3w gMxY6FmzLXj9bozoJGrxTSfUOgY4yjCU542FuAR70vnpXbHgWAZ0ciRTex/ohuJa9L+r jyN8hDT3CmnvIkrAQszQj/fxNwslhA517mNXPpCqUXaTwh8/TSVQlcvSA6Q890sI/8Ws Dsh2wev7cJFdhT67FNQxTGvI0SGER+XsX5ppNKx7wBVQLyPgF1nRi0gOzFS9a79cNIyq RhnA== X-Gm-Message-State: AHPjjUisfeR4V0fllef6S/Jy9UkFbMiotBlh8DR+lvocUC0aBngJHjS/ /h3bZl+HT437DZZ+HP0jRAM3Rb2u2qkpusQK6W0= X-Google-Smtp-Source: AOwi7QCf8ThsbM5r4Ny7YD/Ef+qLl1jFxqUL+bphvkQFzwrNg5NjpGvlVqKlRU/x8Tl0YX19BiNUmChtrHEKi16wd3k= X-Received: by 10.176.74.205 with SMTP id t13mr9056178uae.111.1507020142723; Tue, 03 Oct 2017 01:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.129.140 with HTTP; Tue, 3 Oct 2017 01:42:22 -0700 (PDT) In-Reply-To: References: From: Samita Chakrabarti Date: Tue, 3 Oct 2017 01:42:22 -0700 Message-ID: Subject: Re: [6lo] Liaison statement received from ITU-T regarding a "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment" To: Suresh Krishnan Cc: lo <6lo@ietf.org>, 6man WG , 6tisch <6tisch@ietf.org>, int-area , int-dir@ietf.org, iot-dir , its@ietf.org, lp-wan@ietf.org, lwip@ietf.org Content-Type: multipart/alternative; boundary="f403045f8a4c46c781055aa0780a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 08:42:26 -0000 --f403045f8a4c46c781055aa0780a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Suresh, for sharing the information. It looks quite relevant to 6lo WG workarea. We, 6lo-chairs will contact Scott and the ITU-T contact person provided in the liaison note. Will discuss with you on a separate email regarding the steps to connect. -Samita On Mon, Oct 2, 2017 at 7:53 PM, Suresh Krishnan wrote: > Hi all, > The IETF has received a liaison statement from the ITU-T that their > Study Group SG20 is inviting inputs from the IETF regarding a work item > titled "Reference Model of IPv6 Addressing Plan for Internet of Things > Deployment=E2=80=9D and the deadline for providing inputs is 2018/01/28. = The > statement can be found at > > https://datatracker.ietf.org/liaison/1546/ > > I have no further info and I am trying to get access to the referenced > documents. I just want to provide a heads up while that is in process. > > Thanks > Suresh > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > --f403045f8a4c46c781055aa0780a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Suresh, for sharing the information. It looks quite= relevant to 6lo WG workarea. We, 6lo-chairs will contact Scott and the ITU= -T contact person provided in the liaison note.=C2=A0
Will discuss with= you on a separate email regarding the steps to connect.

-Samita

On Mon, Oct 2, 2017 at 7:53 PM, Suresh Krishnan = <suresh.k= rishnan@gmail.com> wrote:
H= i all,
=C2=A0 The IETF has received a liaison statement from the ITU-T that their = Study Group SG20 is inviting inputs from the IETF regarding a work item tit= led "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment=E2=80=9D and the deadline for providing inputs is 2018/01/28. Th= e statement can be found at

https://datatracker.ietf.org/liaison/1546/

I have no further info and I am trying to get access to the referenced docu= ments. I just want to provide a heads up while that is in process.

Thanks
Suresh


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

--f403045f8a4c46c781055aa0780a-- From nobody Tue Oct 3 09:30:30 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF209134F2F; Tue, 3 Oct 2017 09:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m4l9zQJovPE; Tue, 3 Oct 2017 09:30:24 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEE7134F38; Tue, 3 Oct 2017 09:30:20 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id q124so17910233wmb.0; Tue, 03 Oct 2017 09:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=X+xA+lmGX1wr6X0Vf47d1MVAcEkayVAU77OSTVpcngw=; b=SwyCYgIhbnZb2wkopQWSKhmtEjRjHwFEhpZETT9WfKcJE9ngOFgm3ftFVswmKHdjL1 lxFHKXS1QTZldsF8gcScEBj2FIvGwezril5VjwnxdhypY5ypvIvxiDZzjwDlwtSvXUKD 2rtn2Q+7O2elOmtT4R2DFX9EObF3g0qzoDc65EKhfL7Tw0gaoQFpTFIY1KPO+3CpjmTR Iw/F0IRTgG7Dct2vJm9x7fIJDIkhfauekVfEZRsi4kaCwzIoGYu8kPYGST04d1kaHfGI cd7s0Oq/5BRb5hm/Fc1QOXQ9OqUu75hYiFga5iOrcE+iNb4S3kk88L1o5DuxHtsONpZB WcJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=X+xA+lmGX1wr6X0Vf47d1MVAcEkayVAU77OSTVpcngw=; b=i4m4xwNMJFO6qIhyIL62irI43G9zZR0g2ESZN06NOvYjTKr21E41psO0GvDEW9IVKn t7Z1uqPwJHUThYy5Ogonggyo0FdxoR681fhamHByyXGJ9+iwFrM/pFVpMQabwBaDYhX1 kHR3HYBlb/A5cp2V0If/TrlPZlUIgVLBQ4ywn9HG68/wHNTH0ml5Irde6OopNuAp3nJ8 F4+ViYs8ZVLYoP7XMf+FZ+fnIYcZU8poCDwjl+Nx0NjP2CDlIf80l2VQYcQWZimaCp5j c8N4YkcwTxIv/J8wlmwpA5yUAW40RNNju5SpXB4yJ5vbig9E1r7fbnH+EEiB6sAo/inO W24Q== X-Gm-Message-State: AHPjjUisNNQpAxUAHzheiyWaUi7LT9wIaZ6Wh3MR9GscggaOoN/+9eD8 0PhBGn2ziBrVZ4gtVnLNmjo= X-Google-Smtp-Source: AOwi7QBWYAqt5WxmaM7PT924l//yF4ary1dzTFG+2+vC3e3gTJAYnyU8AeM/ze9x8qjtSOXm+fyCVw== X-Received: by 10.28.134.18 with SMTP id i18mr15413184wmd.27.1507048219110; Tue, 03 Oct 2017 09:30:19 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:513d:a67a:c717:2308? ([2601:647:4d01:db10:513d:a67a:c717:2308]) by smtp.gmail.com with ESMTPSA id 69sm14990882wmm.22.2017.10.03.09.30.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 09:30:16 -0700 (PDT) From: Bob Hinden Message-Id: <9F2E96BD-F1C5-4DF4-95DB-0AF5CBB5B6AC@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_091AFA1F-AD88-42AA-AFB6-C6F45CB1560E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [6lo] Liaison statement received from ITU-T regarding a "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment" Date: Tue, 3 Oct 2017 09:30:10 -0700 In-Reply-To: Cc: Bob Hinden , Suresh Krishnan , int-area , its@ietf.org, int-dir@ietf.org, lwip@ietf.org, iot-dir , lo <6lo@ietf.org>, lp-wan@ietf.org, IPv6 List , 6tisch <6tisch@ietf.org> To: Samita Chakrabarti References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 16:30:26 -0000 --Apple-Mail=_091AFA1F-AD88-42AA-AFB6-C6F45CB1560E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 6man as well, depending on what is in the actual document. Bob > On Oct 3, 2017, at 1:42 AM, Samita Chakrabarti = wrote: >=20 > Thanks Suresh, for sharing the information. It looks quite relevant to = 6lo WG workarea. We, 6lo-chairs will contact Scott and the ITU-T contact = person provided in the liaison note. > Will discuss with you on a separate email regarding the steps to = connect. >=20 > -Samita >=20 > On Mon, Oct 2, 2017 at 7:53 PM, Suresh Krishnan = wrote: > Hi all, > The IETF has received a liaison statement from the ITU-T that their = Study Group SG20 is inviting inputs from the IETF regarding a work item = titled "Reference Model of IPv6 Addressing Plan for Internet of Things > Deployment=E2=80=9D and the deadline for providing inputs is = 2018/01/28. The statement can be found at >=20 > https://datatracker.ietf.org/liaison/1546/ >=20 > I have no further info and I am trying to get access to the referenced = documents. I just want to provide a heads up while that is in process. >=20 > Thanks > Suresh >=20 >=20 > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_091AFA1F-AD88-42AA-AFB6-C6F45CB1560E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZ07sTAAoJEK7rdBF357uozaQIALHzU4KrKx/zZk9jUN3v8mHm Defrw+89CJQo14SGRitVIuXO/mO6kIxdK6b+JH1FZgB79Pom5yoWdUColheWBfcr bma2/ziSa4+5D+4veFavuFJCuujxhXWZKdhXiyZvsh417z7DCPyrQYlpoEDIqMBj YsHTR05bmYx9uW3TfRkPMA9h40wHf1JqJBMm2LxEFlqyfwVA8dK2Ye5feCFic6HV Igpm/DT0gakW+tGPjh6/oZwg38CByGhSHvRYx1asj4hIs/HPIJJs3KWafNDon6qH qwtMZSLWMI45kWS8n0w0x8euYp5dYzEVSKRMCj+mT5i7dOXjEO/5+NOVcAPPhK4= =SZ3u -----END PGP SIGNATURE----- --Apple-Mail=_091AFA1F-AD88-42AA-AFB6-C6F45CB1560E-- From nobody Tue Oct 3 10:10:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090F134F88; Tue, 3 Oct 2017 10:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 nQhkBIeUOPuS; Tue, 3 Oct 2017 10:09:59 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63628134F7A; Tue, 3 Oct 2017 10:09:59 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id o44so5072924wrf.11; Tue, 03 Oct 2017 10:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C/p1fQRRgDa7lJGOSMhqZ0h60vAMiOp1C+8cg9zGYGg=; b=ga74aNYXZ4561EfTF7AMuncOVJ4BbmNAAx10A+RdT08LmZMbOjJgpgfH0XvWIjQ7Zy Njnm8xo4KJE8TKXYUa8mjrKFdHuSCitAapyDhHQbC+fyO1c6v2dIHNhZVjef884HEmnb LCAWg+0gkAh4mCnCBHMpnSfTnkPqbyAaB6BGmTh6Pk4s/tB+nX7082/SnOXRHrUrP0Hv lYvBQQx0w/CFuoZvSLeCMLusXQSVjemAFh1fOLcYRLhJtofc2Ta2ox204IG9eUWzfX8I Wl5fTU4XB9PVXG27DDTClk0H2FUPGlFJ8ZeWPUTElRSA5cebQooI3CA7nPEIxS7P3qr7 ER2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=C/p1fQRRgDa7lJGOSMhqZ0h60vAMiOp1C+8cg9zGYGg=; b=DjhPNR/4ldruOwHVrq//bVUf9YMY2auHAGo6zQIqJKtdiXW0oS7NlOFcdvEN62+dMV 5zMHcj3bOsWiSd1np1fqPureAbzKCpZ2Gh7s7buYHSv0cKOGaoRou6ugRbGCF35tTTRJ L3aV2CvQYH0cBpR1cN3c6jUtLfUsCliktERmi8jdAqrwpZpCyXhd8q0tysV/bNjYmUc6 VoGUcEYcO38pySuzARAHKd8BnUyd/PqGVpE5XGhfOFUkhIhLZUYd2Y9LlK8RHXz7VmYH 0BFE+GIn2RJ9ULTEDE0o2210tkidx2DCM0OPOWaoW901ImLCK34lEOqtg3xe3FKZ/Lpy e7eg== X-Gm-Message-State: AMCzsaUjnCKCkFyuRqnV/mPfzBp2/qRnB1C+czJUbgWT9D3dVEfXAv8G 8Ldcfqw8+JeHxnsdlwJQ89mdSIXR X-Google-Smtp-Source: AOwi7QBcFOD2y8a1qmRGLDMoGwIFIxJrzWgs1Cf+jVM+pt7GZN/pIkOj1u9aeED5bjsVU3n4i3CaYw== X-Received: by 10.223.157.74 with SMTP id o10mr7060361wre.213.1507050597649; Tue, 03 Oct 2017 10:09:57 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1ef9? ([2600:8802:5600:e::1ef9]) by smtp.gmail.com with ESMTPSA id 55sm25009972wrw.60.2017.10.03.10.09.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 10:09:56 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AC7519D8-F1F8-4BBC-80B7-99E42407407D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.2\)) Subject: Re: Liaison statement received from ITU-T regarding a "Reference Model of IPv6 Addressing Plan for Internet of Things Deployment" Date: Tue, 3 Oct 2017 10:09:52 -0700 In-Reply-To: Cc: 6lo@ietf.org, 6man WG , 6tisch@ietf.org, int-area , int-dir@ietf.org, iot-dir@ietf.org, its@ietf.org, lp-wan@ietf.org, lwip@ietf.org To: Suresh Krishnan References: X-Mailer: Apple Mail (2.3445.4.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 17:10:01 -0000 --Apple-Mail=_AC7519D8-F1F8-4BBC-80B7-99E42407407D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. I would like to also get operational commentary from v6ops. Like = you, when I search for the document, I come up to a paywall; the = document is not openly available. Please forward either the document or = the link when ITU decides to get serious about asking for comment. A general comment: the model being followed in RFC 4861 and in the = various IOT groups is fundamentally as follows. The IPv6 address = consists of a prefix and an IID. In the general Internet, routing = operates on prefixes, and a subnet is identified by a prefix. Within a = subnet defined by WiFi, Bluetooth, IEEE 802.15.4/4g, Power Line = Communication technologies, and the like, network elements generally use = some form of host routing, whether source or distributed, on the = presumption that topologies may be continuously changing or devices may = be moving. 6LowPAN specifically has some recommendations on the = structure of the address designed to minimize the actual size of an IPv6 = header, and in many of them, that is treated as a lower layer problem. = I'd like to believe that the work party is sufficiently clued in to not = want to materially change that without discussing it with us (putting = documents behind a paywall not being a great example of open = discussion). > On Oct 2, 2017, at 7:53 PM, Suresh Krishnan = wrote: >=20 > Hi all, > The IETF has received a liaison statement from the ITU-T that their = Study Group SG20 is inviting inputs from the IETF regarding a work item = titled "Reference Model of IPv6 Addressing Plan for Internet of Things > Deployment=E2=80=9D and the deadline for providing inputs is = 2018/01/28. The statement can be found at >=20 > https://datatracker.ietf.org/liaison/1546/ >=20 > I have no further info and I am trying to get access to the referenced = documents. I just want to provide a heads up while that is in process. >=20 > Thanks > Suresh >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_AC7519D8-F1F8-4BBC-80B7-99E42407407D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnTxGAACgkQEhdRnd2G P+AF5BAAj9UyZajt/xa+V+GsLX1GtdYWbxcK4uaE+IHh+uiMepuiO8GGsQDGS8gY VVaReppQX78F0Kt1n6bY1h+zBQMZUsOiU6rd0iEJROGw+/3uWFwETlk6ilGXN7z4 ym/rdDuH7H8VdzU1J2Q4DMwNNTGOigckWH25mREzckV9kKpxe7trJaovcMG1GveT x/Z3b25E9xkZ9fea5vBeEuyBYVec67WMdyE8nzcPNDf7dHxbrwFNw1Hj1e6VXoKY sGDtHar8lF9jRncygnahMsJxoOY2bff0a1h3jhP3knCtoy2ohAlfEFD0g8tVCpKH MMyJBfZb8e51NnP7ABfqb16wdoesFamLVxi9rE6Yb5/F+dhbc7UP8n/Mj5PY51mk LzjPPXRAILEf/Gs4hmay6iWhHvyB+CQfgv1AbpwH5ObzU0oXl70QD9sthnleCg6R lHla8TEKjU8iL0ah4bbEEz81/LAcsVQCHTv613YsdrYtnrOq28TNJmf5Shj4spMM AfsGNyqrilfcN0kFcLdNjWWc45EJhrc2n0rbJffu/BKYrpExuRksenE1LRBsMTCx V65kR4wpSz1c/WZeI9/YQ6p/C+f292fFIF832kt5kAIk4zhjC87GFw2xV9KMiIsp qD6kF0lKMmRNx37tlIru5O/uNlK9AhH5ad89/4IisjEztMPK6RQ= =85O7 -----END PGP SIGNATURE----- --Apple-Mail=_AC7519D8-F1F8-4BBC-80B7-99E42407407D-- From nobody Mon Oct 9 03:24:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31421132F69; Mon, 9 Oct 2017 03:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 y_jn27Ygq3D1; Mon, 9 Oct 2017 03:24:42 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C17D13449C; Mon, 9 Oct 2017 03:24:40 -0700 (PDT) Received: from h.hanazo.no (unknown [173.38.220.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 32C7D2D4FD0; Mon, 9 Oct 2017 10:24:38 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 326A420044FA10; Mon, 9 Oct 2017 12:24:34 +0200 (CEST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_F9343BED-5775-48C7-82DB-830632332DD4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Subject: 2nd: 6MAN IETF100 Call for agenda items Date: Mon, 9 Oct 2017 12:24:33 +0200 References: Cc: 6man-chairs@ietf.org, Suresh Krishnan To: 6man WG Message-Id: X-Mailer: Apple Mail (2.3445.1.6) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 10:24:44 -0000 --Apple-Mail=_F9343BED-5775-48C7-82DB-830632332DD4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8787F388-FCD1-485D-A39E-5314F090703B" --Apple-Mail=_8787F388-FCD1-485D-A39E-5314F090703B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, So far we have received 1.5 requests... Ole > Begin forwarded message: >=20 > From: Ole Troan > Subject: 6MAN IETF100 Call for agenda items > Date: 2 October 2017 at 11:20:53 CEST > To: 6man WG > Cc: 6man-chairs@ietf.org > Resent-From: > Resent-To: otroan@employees.org, bob.hinden@gmail.com >=20 > The 6MAN chairs are planning the meeting in Singapore at IETF100. >=20 > If you have a draft you would like to discuss, please send your = request for agenda time to the 6man chairs. Please include in the = request, the title of the presentation, file name of the draft, the = speaker's name (and email), and how much time you would like. >=20 > We will prioritise drafts that are working group items and drafts that = have been actively discussed on the list. >=20 > We expect at least half of each talk=E2=80=99s presentation time to be = used for open discussion, > please plan your presentation accordingly. >=20 > New drafts not discussed on the mailing list prior to the meeting, > or drafts that do not appear to have support from the working group = are unlikely to get time at the meeting. >=20 > Please have agenda items to us by 2017-10-30. > Remember the draft cut-off date is also 2017-10-30 (2 weeks before the = meeting). >=20 > Regards, >=20 > Bob & Ole --Apple-Mail=_8787F388-FCD1-485D-A39E-5314F090703B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

So = far we have received 1.5 requests...

Ole

Begin = forwarded message:

From: = Ole Troan <otroan@employees.org>
Subject: = 6MAN IETF100 Call = for agenda items
Date: 2 = October 2017 at 11:20:53 CEST
To: 6man WG <ipv6@ietf.org>
Cc: 6man-chairs@ietf.org
Resent-From: = <alias-bounces@ietf.org>
Resent-To: = otroan@employees.org, = bob.hinden@gmail.com

The 6MAN chairs are planning = the meeting in Singapore at IETF100.

If you = have a draft you would like to discuss, please send your request for = agenda time to the 6man chairs.   Please include in the = request, the title of the presentation, file name of the draft, the = speaker's name (and email), and how much time you would like.

We will prioritise drafts that are working = group items and drafts that have been actively discussed on the list.

We expect at least half of each talk=E2=80=99s = presentation time to be used for open discussion,
please = plan your presentation accordingly.

New = drafts not discussed on the mailing list prior to the meeting,
or drafts that do not appear to have support from the working = group are unlikely to get time at the meeting.

Please have agenda items to us by 2017-10-30.
Remember the draft cut-off date is also 2017-10-30 (2 weeks = before the meeting).

Regards,

Bob & Ole

= --Apple-Mail=_8787F388-FCD1-485D-A39E-5314F090703B-- --Apple-Mail=_F9343BED-5775-48C7-82DB-830632332DD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnbTmEACgkQvtpYqJhC 33aqwBAAk91z5Z+4WuhEVNYSDNS2GWiAq5jo1cH77ab4wJ3yNxJdE7/vgVyufnH3 99QgxNWqM/vJcET8VNuzcDlJWsNo6CDUmzBWZ2aQEQ+djjIgBc0ZModCugyBTCU3 J5zbVdWPKZyGSEOemKMPY2BlOOA4eChtEt5jZ4Oyi/reQM8ZuUh0heFHXLCP/gdT c2C8GCz6i6b7UtahqLwe7CwPc8ByoD/z8EticAlV4f8ggTyb6uY8TUDljpX2uouK eJXEEs2l1c72eMVm/Idr5O7K/1a02Yg3wkAyt3R/nhYFSgc1EwY8IXpc3fjNWhON EpBGds4mvsfcPRlK/WkixRIC5jbOzf0n7jnE2u9h4Of7gA3PShFeyrsusVHv6kk0 5hSaMw0kWVGESa056nGj1b3I4X91+z4xkKcAFo37npR8xGryUebITFnKXDkoEWz9 oBGQaDG1HYsRi6wDfRnUIiGrz+1xTDE1E6VOXcpYfJleahFY3X6J7Xc9uC7cSnep ZoPRRN9Lp5P533akfa0TU5HnsouhLSrXcp4x34Qu+w2Car3OEa3WSVWyhKoDoH6o cbLmoDB9+RtjNznYpaxfecth2o8QCfhA8bhyeACdMHG8AjqJwVYJHtb6K28lelBl 9kOgjie4lG2Q56jFfLFGwaLRXOFXQHyWJwBkxscyaNRfUOBsq5o= =qyfB -----END PGP SIGNATURE----- --Apple-Mail=_F9343BED-5775-48C7-82DB-830632332DD4-- From nobody Wed Oct 11 11:29:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B763B126B6E for ; Wed, 11 Oct 2017 11:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99dUXqzltU0q for ; Wed, 11 Oct 2017 11:29:28 -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 60A6A126B6D for ; Wed, 11 Oct 2017 11:29:28 -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 DXJ36250; Wed, 11 Oct 2017 18:29:26 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Oct 2017 19:29:25 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Wed, 11 Oct 2017 11:29:22 -0700 From: Lin Han To: "ipv6@ietf.org" Subject: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTQruJwQxCswsciU6P+cp6s4YJt6Le9Q6w Date: Wed, 11 Oct 2017 18:29:22 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD61BE4@sjceml521-mbx.china.huawei.com> References: <150774513055.24791.14896560309088355897.idtracker@ietfa.amsl.com> In-Reply-To: <150774513055.24791.14896560309088355897.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59DE6306.0214, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ddcfbc98a248d466dc12e15c766263e3 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2017 18:29:31 -0000 RGVhciBhbGwsDQoNCkkgaGF2ZSBqdXN0IHVwbG9hZGVkIGEgbmV3IGRyYWZ0LiANClRoaXMgZHJh ZnQgZGVzY3JpYmVzIGEgSVB2NiBpbi1iYW5kIHNpZ25hbGluZyBtZXRob2QgZm9yIFFvUyBzdXBw b3J0IGZvciB0cmFuc3BvcnQgc2VydmljZS4NClRoZSBtZXRob2QgY2FuIGJlIHVzZWQgZm9yIGZp bmUtZ3JhaW5lZCBmbG93cyBzdWNoIGFzIGluZGl2aWR1YWwgVENQIHNlc3Npb24uDQpXZSBhbHNv IGhhdmUgZG9uZSBzb21lIGV4cGVyaW1lbnRzIHdpdGggaW4taG91c2UgaGFyZHdhcmUgdG8gcHJv dmUgdGhlIGNvbmNlcHQsIHBlcmZvcm1hbmNlIGFuZCBzY2FsYWJpbGl0eSwgd2hpY2ggSSBtYXkg cHJlc2VudCBpbiB0aGUgSUVURjEwMCAodXAgdG8gdGhlIGFwcHJvdmUgb2YgV0cgY2hhaXJzKS4N CllvdXIgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBhcmUgYWx3YXlzIHdlbGNvbWUgYW5kIGdyZWF0 bHkgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcw0KDQpMaW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhh bi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW4gSGFuIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5n LWZvci10cmFuc3BvcnQtcW9zDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJSVB2NiBpbi1iYW5kIHNp Z25hbGluZyBmb3IgdGhlIHN1cHBvcnQgb2YgdHJhbnNwb3J0IHdpdGggUW9TDQpEb2N1bWVudCBk YXRlOgkyMDE3LTEwLTExDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk0 MA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o YW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFuLTZtYW4taW4tYmFuZC1z aWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFs aW5nLWZvci10cmFuc3BvcnQtcW9zLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IHByb3Bvc2VzIGEgbWV0aG9kIHRvIHN1cHBvcnQgdGhlIElQIHRyYW5zcG9ydCBzZXJ2aWNlDQog ICB0aGF0IGNvdWxkIGd1YXJhbnRlZSBhIGNlcnRhaW4gbGV2ZWwgb2Ygc2VydmljZSBxdWFsaXR5 IGluIGJhbmR3aWR0aA0KICAgYW5kIGxhdGVuY3kuICBUaGUgbmV3IHRyYW5zcG9ydCBzZXJ2aWNl IGlzIGZpbmUtZ3JhaW5lZCBhbmQgY291bGQNCiAgIGFwcGx5IHRvIGluZGl2aWR1YWwgb3IgYWdn cmVnYXRlZCBUQ1AvVURQIGZsb3cocykuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Thu Oct 12 08:32:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8F134515 for ; Thu, 12 Oct 2017 08:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4zqz-b_dnXw for ; Thu, 12 Oct 2017 08:32:21 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F5213451A for ; Thu, 12 Oct 2017 08:32:21 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d67so1674858qkg.5 for ; Thu, 12 Oct 2017 08:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vJfnyWkGks8Zs7/LndHW2tIyNcRp/7ju9KN+3lQHNTw=; b=2ThjCtudsUZjHAoWpDlSncIxx04HsctyXkkYH/OzLJZMwwql3w72QMh2QRzBEaCaLt cU4HhT7jhJ/8h4pNzevs/vDIAWGv1DiePriNwCgZzSAj/Fgm5uZbLWOWikf+DtCEdS42 i+mgSEZSKAXwyeeTqLN1BVc+3PrTkxJy0Fi+Ppm71nA1FO3aftJjRko5Oqdt84Zwt53s 3t1CDlu6wQUuA8O/uR59Mi09EO0j2SMNvPDd3d+sm+ZZQ5pQ/kt+IZ/UjBS5YHhYB1KA CURi0O8gf53BehTrIQ4fvILGiytTmFI+Zi2nzFASzx3yg723BexTzgxtC2WJUD5QywHr 1WXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vJfnyWkGks8Zs7/LndHW2tIyNcRp/7ju9KN+3lQHNTw=; b=Os9kkPL/pQacUA9NhiOjt0AZ0GwpuCycrJUwI5iK4Wo0Lby4ftvH9rI4El2ESyNmgd xRhcRhjed3Hblh5QgP2PBEPRSDxhLaXZ/II0LsTvpLGlxciqIcyzD3F8tQT1kfkbJVJ0 s5XiwqxSKca1PMkbsDgrj7tiR3plEfUzJ9ihaUOByu3mviEty7y0kDt107T16hIzsUDh pXJClxeFpZF8iZLwriuETZn7n/jOElYL0p42TtYXfXqQAvw4JACWAnapBPcEHyCbs5aK PHXoBCqU5Y3Xbq4WP087oE97mWqEPAu8VTwvJQP3zlL9f5G3SS/7cPeATWZc4PihNXdo QvOA== X-Gm-Message-State: AMCzsaUY/C9o3nMs1ZlzaODwRti37doehk63x14T1WdsuWneBZ0zPbdo koiAWcsFf8t1ajUj2alEHF1b/ZjsySLPzPvy0eQbUw== X-Google-Smtp-Source: ABhQp+SrraD3YIe437PEgAB3PlKmQcN8xoFyKLMqzczv5+K5dwElBL3Tyr22EhJ+/tsXiWxJJDVBvYgorp2z0iy957U= X-Received: by 10.55.106.132 with SMTP id f126mr975709qkc.295.1507822340143; Thu, 12 Oct 2017 08:32:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.144 with HTTP; Thu, 12 Oct 2017 08:32:19 -0700 (PDT) In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD61BE4@sjceml521-mbx.china.huawei.com> References: <150774513055.24791.14896560309088355897.idtracker@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD61BE4@sjceml521-mbx.china.huawei.com> From: Tom Herbert Date: Thu, 12 Oct 2017 08:32:19 -0700 Message-ID: Subject: Re: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Lin Han Cc: "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a11487b0af81356055b5b3e13" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 15:32:24 -0000 --001a11487b0af81356055b5b3e13 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 11, 2017 at 11:29 AM, Lin Han wrote: > Dear all, > > I have just uploaded a new draft. > This draft describes a IPv6 in-band signaling method for QoS support for > transport service. > The method can be used for fine-grained flows such as individual TCP > session. > We also have done some experiments with in-house hardware to prove the > concept, performance and scalability, which I may present in the IETF100 > (up to the approve of WG chairs). > Your comments and questions are always welcome and greatly appreciated. > Hi, I looked at the draft and really like the idea. This seems to be a type of inband opportunistic RSVP with soft state. My major comment is that it is too closely tied to TCP and UDP. Specifically, the requirement that network devices in the datapath identify the state by 5-tuple that includes port numbers seems restrictive. That technique has all the known problems of doing DPI in intermediate nodes and is only applicable to TCP and UDP or at least transport protocols that include port numbers. The alternative I would suggest is to only use the three tuple-- src addr, dst addr, flow label. I believe all the major OSes are now properly setting the flow label to be hash value represented the encapsulated transport layer flow. WIth this, parsing beyond HbH is no longer needed and it works with any transport protocol (even ESP for instance). Tom ---------------------------------------------- > A new version of I-D, draft-han-6man-in-band-signaling-for-transport-qos- > 00.txt > has been successfully submitted by Lin Han and posted to the IETF > repository. > > Name: draft-han-6man-in-band-signaling-for-transport-qos > Revision: 00 > Title: IPv6 in-band signaling for the support of transport with > QoS > Document date: 2017-10-11 > Group: Individual Submission > Pages: 40 > URL: https://www.ietf.org/internet- > drafts/draft-han-6man-in-band-signaling-for-transport-qos-00.txt > Status: https://datatracker.ietf.org/doc/draft-han-6man-in-band- > signaling-for-transport-qos/ > Htmlized: https://tools.ietf.org/html/draft-han-6man-in-band- > signaling-for-transport-qos-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-han-6man-in- > band-signaling-for-transport-qos-00 > > > Abstract: > This document proposes a method to support the IP transport service > that could guarantee a certain level of service quality in bandwidth > and latency. The new transport service is fine-grained and could > apply to individual or aggregated TCP/UDP flow(s). > > > > > 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. > > The IETF Secretariat > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11487b0af81356055b5b3e13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 11, 2017 at 11:29 AM, Lin Han <Lin.Han@huawei.com>= wrote:
Dear all,

I have just uploaded a new draft.
This draft describes a IPv6 in-band signaling method for QoS support for tr= ansport service.
The method can be used for fine-grained flows such as individual TCP sessio= n.
We also have done some experiments with in-house hardware to prove the conc= ept, performance and scalability, which I may present in the IETF100 (up to= the approve of WG chairs).
Your comments and questions are always welcome and greatly appreciated.
=

Hi,

I looked at t= he draft and really like the idea. This seems to be a type of inband opport= unistic RSVP with soft state.

My major comment is = that it is too closely tied to TCP and UDP. Specifically, the requirement t= hat network devices in the datapath identify the state by 5-tuple that incl= udes port numbers seems restrictive. That technique has all the known probl= ems of doing DPI in intermediate nodes and is only applicable to TCP and UD= P or at least transport protocols that include port numbers.

=
The alternative I would suggest is to only use the three tuple--= src addr, dst addr, flow label. I believe all the major OSes are now prope= rly setting the flow label to be hash value represented the encapsulated tr= ansport layer flow. WIth this, parsing beyond HbH is no longer needed and i= t works with any transport protocol (even ESP for instance).

=
Tom

----------------------------------------------
A new version of I-D, draft-han-6man-in-band-signaling-for-transport-q= os-00.txt
has been successfully submitted by Lin Han and posted to the IETF repositor= y.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-han-6man-in-band-s= ignaling-for-transport-qos
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 in-band signaling for the sup= port of transport with QoS
Document date:=C2=A0 2017-10-11
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 40
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-= drafts/draft-han-6man-in-band-signaling-for-transport-qos-00.txt<= /a>
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-han-6m= an-in-band-signaling-for-transport-qos/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-transport-qos-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft= -han-6man-in-band-signaling-for-transport-qos-00


Abstract:
=C2=A0 =C2=A0This document proposes a method to support the IP transport se= rvice
=C2=A0 =C2=A0that could guarantee a certain level of service quality in ban= dwidth
=C2=A0 =C2=A0and latency.=C2=A0 The new transport service is fine-grained a= nd could
=C2=A0 =C2=A0apply to individual or aggregated TCP/UDP flow(s).




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.

The IETF Secretariat

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

--001a11487b0af81356055b5b3e13-- From nobody Thu Oct 12 17:53:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E191342E9 for ; Thu, 12 Oct 2017 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OFIkdPCYHR6 for ; Thu, 12 Oct 2017 17:53:17 -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 7556A133091 for ; Thu, 12 Oct 2017 17:53:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXO09755; Fri, 13 Oct 2017 00:53:14 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Oct 2017 01:53:12 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML703-CHM.china.huawei.com ([169.254.5.15]) with mapi id 14.03.0301.000; Thu, 12 Oct 2017 17:53:10 -0700 From: Lin Han To: Tom Herbert CC: "ipv6@ietf.org" Subject: RE: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTQruJwQxCswsciU6P+cp6s4YJt6Le9Q6wgAHZaICAAB1LIA== Date: Fri, 13 Oct 2017 00:53:09 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD623F8@sjceml521-mbx.china.huawei.com> References: <150774513055.24791.14896560309088355897.idtracker@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD61BE4@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.35] Content-Type: multipart/alternative; boundary="_000_1D30AF33624CDD4A99E8C395069A2A162CD623F8sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59E00E7A.00D8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 96bd42b22ead5bd3b52299a95631ccea Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 00:53:19 -0000 --_000_1D30AF33624CDD4A99E8C395069A2A162CD623F8sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFRvbQ0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cywgc2VlIGlubGluZSBhbnN3ZXJzIHdp dGggW0xIXS4NCg0KUmVnYXJkcw0KDQpMaW4NCg0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0 b21AaGVyYmVydGxhbmQuY29tXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTIsIDIwMTcgODoz MiBBTQ0KVG86IExpbiBIYW4gPExpbi5IYW5AaHVhd2VpLmNvbT4NCkNjOiBpcHY2QGlldGYub3Jn DQpTdWJqZWN0OiBSZTogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFu LTZtYW4taW4tYmFuZC1zaWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDAudHh0DQoNCg0KDQpP biBXZWQsIE9jdCAxMSwgMjAxNyBhdCAxMToyOSBBTSwgTGluIEhhbiA8TGluLkhhbkBodWF3ZWku Y29tPG1haWx0bzpMaW4uSGFuQGh1YXdlaS5jb20+PiB3cm90ZToNCkRlYXIgYWxsLA0KDQpJIGhh dmUganVzdCB1cGxvYWRlZCBhIG5ldyBkcmFmdC4NClRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgSVB2 NiBpbi1iYW5kIHNpZ25hbGluZyBtZXRob2QgZm9yIFFvUyBzdXBwb3J0IGZvciB0cmFuc3BvcnQg c2VydmljZS4NClRoZSBtZXRob2QgY2FuIGJlIHVzZWQgZm9yIGZpbmUtZ3JhaW5lZCBmbG93cyBz dWNoIGFzIGluZGl2aWR1YWwgVENQIHNlc3Npb24uDQpXZSBhbHNvIGhhdmUgZG9uZSBzb21lIGV4 cGVyaW1lbnRzIHdpdGggaW4taG91c2UgaGFyZHdhcmUgdG8gcHJvdmUgdGhlIGNvbmNlcHQsIHBl cmZvcm1hbmNlIGFuZCBzY2FsYWJpbGl0eSwgd2hpY2ggSSBtYXkgcHJlc2VudCBpbiB0aGUgSUVU RjEwMCAodXAgdG8gdGhlIGFwcHJvdmUgb2YgV0cgY2hhaXJzKS4NCllvdXIgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyBhcmUgYWx3YXlzIHdlbGNvbWUgYW5kIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoN CkhpLA0KDQpJIGxvb2tlZCBhdCB0aGUgZHJhZnQgYW5kIHJlYWxseSBsaWtlIHRoZSBpZGVhLiBU aGlzIHNlZW1zIHRvIGJlIGEgdHlwZSBvZiBpbmJhbmQgb3Bwb3J0dW5pc3RpYyBSU1ZQIHdpdGgg c29mdCBzdGF0ZS4NCg0KDQpNeSBtYWpvciBjb21tZW50IGlzIHRoYXQgaXQgaXMgdG9vIGNsb3Nl bHkgdGllZCB0byBUQ1AgYW5kIFVEUC4gU3BlY2lmaWNhbGx5LCB0aGUgcmVxdWlyZW1lbnQgdGhh dCBuZXR3b3JrIGRldmljZXMgaW4gdGhlIGRhdGFwYXRoIGlkZW50aWZ5IHRoZSBzdGF0ZSBieSA1 LXR1cGxlIHRoYXQgaW5jbHVkZXMgcG9ydCBudW1iZXJzIHNlZW1zIHJlc3RyaWN0aXZlLiBUaGF0 IHRlY2huaXF1ZSBoYXMgYWxsIHRoZSBrbm93biBwcm9ibGVtcyBvZiBkb2luZyBEUEkgaW4gaW50 ZXJtZWRpYXRlIG5vZGVzIGFuZCBpcyBvbmx5IGFwcGxpY2FibGUgdG8gVENQIGFuZCBVRFAgb3Ig YXQgbGVhc3QgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IGluY2x1ZGUgcG9ydCBudW1iZXJzLg0K DQpbTEhdIFllYWgsIHRoZSBwb3J0IG51bWJlciBpbiB0dXBsZXMgd2lsbCBsaW1pdCB0aGUgc29s dXRpb24gdG8gbm9uLWVuY3J5cHRlZCBUQ1AsIFVEUC4gVGhpcyBkb2N1bWVudCBvbmx5IGV4ZW1w bGlmeSB0aGUgaW4tYmFuZCBzaWduYWxpbmcgZm9yIG5vbi1lbmNyeXB0ZWQgVENQIGZsb3cgY2Fz ZS4gSWYgYSBmbG93IGlzIGlkZW50aWZpZWQgYnkgMyB0dXBsZXMgKHNyYyBhZGRyLCBkc3QgYWRk ciwgZmxvdyBsYWJlbCksIHRoZSBtZWNoYW5pc20gaXMgdGhlIHNhbWUsIGFzIGxvbmcgYXMgd2Ug ZGVmaW5lIHRoZSDigJxGSeKAnSBhcyAzIHR1cGxlcy4NCg0KDQpUaGUgYWx0ZXJuYXRpdmUgSSB3 b3VsZCBzdWdnZXN0IGlzIHRvIG9ubHkgdXNlIHRoZSB0aHJlZSB0dXBsZS0tIHNyYyBhZGRyLCBk c3QgYWRkciwgZmxvdyBsYWJlbC4gSSBiZWxpZXZlIGFsbCB0aGUgbWFqb3IgT1NlcyBhcmUgbm93 IHByb3Blcmx5IHNldHRpbmcgdGhlIGZsb3cgbGFiZWwgdG8gYmUgaGFzaCB2YWx1ZSByZXByZXNl bnRlZCB0aGUgZW5jYXBzdWxhdGVkIHRyYW5zcG9ydCBsYXllciBmbG93LiBXSXRoIHRoaXMsIHBh cnNpbmcgYmV5b25kIEhiSCBpcyBubyBsb25nZXIgbmVlZGVkIGFuZCBpdCB3b3JrcyB3aXRoIGFu eSB0cmFuc3BvcnQgcHJvdG9jb2wgKGV2ZW4gRVNQIGZvciBpbnN0YW5jZSkuDQoNCltMSF0gSWYg dGhlIGZsb3cgbGFiZWwgaXMgd2lkZWx5IHVzZWQgYnkgbWFqb3IgT1MsIGRlZmluaXRlbHkgd2Ug Y2FuIGRlZmluZSAzIHR1cGxlcywgaW5zdGVhZCBvZiA1IHR1cGxlcywgZm9yIGEgZmxvdyBpZGVu dGlmaWNhdGlvbi4gQmVmb3JlLCBJIHRob3VnaHQgdGhlIGZsb3cgbGFiZWwgaXMgbm90IHVzZWQg aW4gT1MuIEFsbCB0aGUgZGV0YWlscyBvZiB0aGUgc2lnbmFsaW5nIG1ldGhvZCBhbmQgbWVzc2Fn ZSBmb3JtYXQsIHdpbGwgb25seSBiZSBmaW5hbGl6ZWQgdXAgdG8gdGhlIGRlY2lzaW9uIG9mIHRo ZSBJUHY2IGNvbW11bml0eS4NCg0KVG9tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYW4tNm1hbi1p bi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluIEhhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGlu Zy1mb3ItdHJhbnNwb3J0LXFvcw0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAg SVB2NiBpbi1iYW5kIHNpZ25hbGluZyBmb3IgdGhlIHN1cHBvcnQgb2YgdHJhbnNwb3J0IHdpdGgg UW9TDQpEb2N1bWVudCBkYXRlOiAgMjAxNy0xMC0xMQ0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDQwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2ln bmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5n LWZvci10cmFuc3BvcnQtcW9zLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFv cy0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaGFuLTZtYW4taW4tYmFuZC1zaWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBtZXRob2QgdG8gc3Vw cG9ydCB0aGUgSVAgdHJhbnNwb3J0IHNlcnZpY2UNCiAgIHRoYXQgY291bGQgZ3VhcmFudGVlIGEg Y2VydGFpbiBsZXZlbCBvZiBzZXJ2aWNlIHF1YWxpdHkgaW4gYmFuZHdpZHRoDQogICBhbmQgbGF0 ZW5jeS4gIFRoZSBuZXcgdHJhbnNwb3J0IHNlcnZpY2UgaXMgZmluZS1ncmFpbmVkIGFuZCBjb3Vs ZA0KICAgYXBwbHkgdG8gaW5kaXZpZHVhbCBvciBhZ2dyZWdhdGVkIFRDUC9VRFAgZmxvdyhzKS4N Cg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0 Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= --_000_1D30AF33624CDD4A99E8C395069A2A162CD623F8sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGksIFRvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz IGZvciB0aGUgY29tbWVudHMsIHNlZSBpbmxpbmUgYW5zd2VycyB3aXRoIFtMSF0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVG9tIEhlcmJlcnQgW21h aWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBP Y3RvYmVyIDEyLCAyMDE3IDg6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IExpbiBIYW4gJmx0O0xpbi5I YW5AaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGlwdjZAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhh bi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAwLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgT2N0IDExLCAyMDE3IGF0IDExOjI5IEFNLCBMaW4g SGFuICZsdDs8YSBocmVmPSJtYWlsdG86TGluLkhhbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+TGluLkhhbkBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPGJyPg0KPGJyPg0KSSBoYXZl IGp1c3QgdXBsb2FkZWQgYSBuZXcgZHJhZnQuPGJyPg0KVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBJ UHY2IGluLWJhbmQgc2lnbmFsaW5nIG1ldGhvZCBmb3IgUW9TIHN1cHBvcnQgZm9yIHRyYW5zcG9y dCBzZXJ2aWNlLjxicj4NClRoZSBtZXRob2QgY2FuIGJlIHVzZWQgZm9yIGZpbmUtZ3JhaW5lZCBm bG93cyBzdWNoIGFzIGluZGl2aWR1YWwgVENQIHNlc3Npb24uPGJyPg0KV2UgYWxzbyBoYXZlIGRv bmUgc29tZSBleHBlcmltZW50cyB3aXRoIGluLWhvdXNlIGhhcmR3YXJlIHRvIHByb3ZlIHRoZSBj b25jZXB0LCBwZXJmb3JtYW5jZSBhbmQgc2NhbGFiaWxpdHksIHdoaWNoIEkgbWF5IHByZXNlbnQg aW4gdGhlIElFVEYxMDAgKHVwIHRvIHRoZSBhcHByb3ZlIG9mIFdHIGNoYWlycykuPGJyPg0KWW91 ciBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGFyZSBhbHdheXMgd2VsY29tZSBhbmQgZ3JlYXRseSBh cHByZWNpYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGxvb2tlZCBhdCB0aGUgZHJhZnQgYW5kIHJlYWxseSBsaWtlIHRo ZSBpZGVhLiBUaGlzIHNlZW1zIHRvIGJlIGEgdHlwZSBvZiBpbmJhbmQgb3Bwb3J0dW5pc3RpYyBS U1ZQIHdpdGggc29mdCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgbWFqb3IgY29tbWVudCBpcyB0aGF0IGl0IGlzIHRv byBjbG9zZWx5IHRpZWQgdG8gVENQIGFuZCBVRFAuIFNwZWNpZmljYWxseSwgdGhlIHJlcXVpcmVt ZW50IHRoYXQgbmV0d29yayBkZXZpY2VzIGluIHRoZSBkYXRhcGF0aCBpZGVudGlmeSB0aGUgc3Rh dGUgYnkgNS10dXBsZSB0aGF0IGluY2x1ZGVzIHBvcnQgbnVtYmVycyBzZWVtcyByZXN0cmljdGl2 ZS4gVGhhdCB0ZWNobmlxdWUgaGFzIGFsbCB0aGUga25vd24NCiBwcm9ibGVtcyBvZiBkb2luZyBE UEkgaW4gaW50ZXJtZWRpYXRlIG5vZGVzIGFuZCBpcyBvbmx5IGFwcGxpY2FibGUgdG8gVENQIGFu ZCBVRFAgb3IgYXQgbGVhc3QgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IGluY2x1ZGUgcG9ydCBu dW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTEhdIFllYWgsIHRo ZSBwb3J0IG51bWJlciBpbiB0dXBsZXMgd2lsbCBsaW1pdCB0aGUgc29sdXRpb24gdG8gbm9uLWVu Y3J5cHRlZCBUQ1AsIFVEUC4gVGhpcyBkb2N1bWVudCBvbmx5IGV4ZW1wbGlmeSB0aGUgaW4tYmFu ZCBzaWduYWxpbmcgZm9yIG5vbi1lbmNyeXB0ZWQgVENQDQogZmxvdyBjYXNlLiBJZiBhIGZsb3cg aXMgaWRlbnRpZmllZCBieSAzIHR1cGxlcyAoc3JjIGFkZHIsIGRzdCBhZGRyLCBmbG93IGxhYmVs KSwgdGhlIG1lY2hhbmlzbSBpcyB0aGUgc2FtZSwgYXMgbG9uZyBhcyB3ZSBkZWZpbmUgdGhlIOKA nEZJ4oCdIGFzIDMgdHVwbGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhbHRl cm5hdGl2ZSBJIHdvdWxkIHN1Z2dlc3QgaXMgdG8gb25seSB1c2UgdGhlIHRocmVlIHR1cGxlLS0g c3JjIGFkZHIsIGRzdCBhZGRyLCBmbG93IGxhYmVsLiBJIGJlbGlldmUgYWxsIHRoZSBtYWpvciBP U2VzIGFyZSBub3cgcHJvcGVybHkgc2V0dGluZyB0aGUgZmxvdyBsYWJlbCB0byBiZSBoYXNoIHZh bHVlIHJlcHJlc2VudGVkIHRoZSBlbmNhcHN1bGF0ZWQgdHJhbnNwb3J0IGxheWVyIGZsb3cuIFdJ dGgNCiB0aGlzLCBwYXJzaW5nIGJleW9uZCBIYkggaXMgbm8gbG9uZ2VyIG5lZWRlZCBhbmQgaXQg d29ya3Mgd2l0aCBhbnkgdHJhbnNwb3J0IHByb3RvY29sIChldmVuIEVTUCBmb3IgaW5zdGFuY2Up LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTEhdIElmIHRoZSBmbG93IGxh YmVsIGlzIHdpZGVseSB1c2VkIGJ5IG1ham9yIE9TLCBkZWZpbml0ZWx5IHdlIGNhbiBkZWZpbmUg MyB0dXBsZXMsIGluc3RlYWQgb2YgNSB0dXBsZXMsIGZvciBhIGZsb3cgaWRlbnRpZmljYXRpb24u IEJlZm9yZSwgSSB0aG91Z2h0IHRoZSBmbG93DQogbGFiZWwgaXMgbm90IHVzZWQgaW4gT1MuIEFs bCB0aGUgZGV0YWlscyBvZiB0aGUgc2lnbmFsaW5nIG1ldGhvZCBhbmQgbWVzc2FnZSBmb3JtYXQs IHdpbGwgb25seSBiZSBmaW5hbGl6ZWQgdXAgdG8gdGhlIGRlY2lzaW9uIG9mIHRoZSBJUHY2IGNv bW11bml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhbi02bWFuLWluLWJh bmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgTGluIEhhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z aXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9z PGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElQdjYgaW4tYmFuZCBzaWduYWxpbmcg Zm9yIHRoZSBzdXBwb3J0IG9mIHRyYW5zcG9ydCB3aXRoIFFvUzxicj4NCkRvY3VtZW50IGRhdGU6 Jm5ic3A7IDIwMTctMTAtMTE8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgNDA8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAw LnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhbi02bWFuLWlu LWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFs aW5nLWZvci10cmFuc3BvcnQtcW9zLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFu LTZtYW4taW4tYmFuZC1zaWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDAiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFuLTZtYW4taW4tYmFuZC1z aWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDA8L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFv cy0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaGFuLTZtYW4taW4tYmFuZC1zaWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDA8 L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9j dW1lbnQgcHJvcG9zZXMgYSBtZXRob2QgdG8gc3VwcG9ydCB0aGUgSVAgdHJhbnNwb3J0IHNlcnZp Y2U8YnI+DQombmJzcDsgJm5ic3A7dGhhdCBjb3VsZCBndWFyYW50ZWUgYSBjZXJ0YWluIGxldmVs IG9mIHNlcnZpY2UgcXVhbGl0eSBpbiBiYW5kd2lkdGg8YnI+DQombmJzcDsgJm5ic3A7YW5kIGxh dGVuY3kuJm5ic3A7IFRoZSBuZXcgdHJhbnNwb3J0IHNlcnZpY2UgaXMgZmluZS1ncmFpbmVkIGFu ZCBjb3VsZDxicj4NCiZuYnNwOyAmbmJzcDthcHBseSB0byBpbmRpdmlkdWFsIG9yIGFnZ3JlZ2F0 ZWQgVENQL1VEUCBmbG93KHMpLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48 YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_1D30AF33624CDD4A99E8C395069A2A162CD623F8sjceml521mbxchi_-- From nobody Fri Oct 13 18:11:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A07132D17 for ; Fri, 13 Oct 2017 18:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrmgH0wCR0ol for ; Fri, 13 Oct 2017 18:11:49 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A003132332 for ; Fri, 13 Oct 2017 18:11:49 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id r25so2462682pgn.4 for ; Fri, 13 Oct 2017 18:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=lvj4ObMWrZgIC7DQcvN/rYvPKj9sIxcjBkWjoi2QNPM=; b=u+9TtZYFpfwMmwtYMQrogn1zN3X5JIoGDBeQUFFY+yWyNWWRiko+5zpLgxHRLCvhPo Dc7PjdY/puaH0pGf7fzKcH5JyuKx+05g2t0nM1T8PDdT13SXAw0rXcnduvxeU2j+SWOe bpKg1CgPToxaw5uHtLhV+wHcaRyaXdG5x4ZjEMOTv1RXTVaz/sFiOlkOO2BwfAvX1+0q YulJPBR9094EnlvFIrJbXdrU8K5smk4HQQPCAy2xp5Fq4Nap/ioE1ZyTQ+w4s2gwHZVE L+2ieotyn0Qbtu3U7j2yQj0BqD/Viv/y0hbSFsq/jUNoLr3jpX0vlMSNTvOlusF+KMOI 0cAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=lvj4ObMWrZgIC7DQcvN/rYvPKj9sIxcjBkWjoi2QNPM=; b=BUbxIeQHJfKKKChncXQOovJdhUkGYOLpeb/Gvy33a62McCM/hP+acDokbLKaSA0NWd T18yMpGaSgW/06oa/udt3vUndbD2q5zDZXWYw4xZnhnztVXHjlaeDzLo+5+ytCPcnuz0 6m5YryD4VY4+0EABSH4p0VNrTrKHgLJVWme+G3Wd5CUSQcQO3v7VGUKzYL4rl6yrFuqM dwZOllTUwKuYg5P26f/iZlLp08oYdZgzkVqsYu81KpSR2owF+1cwvD+ybVBy9cS96+Js yQchMYmskhFzKMO6YT+TdBmrzTMF7v+Bwd6T8AFYSidDVI3O55zoQJkNuyIspI/Kj5Lh a3zg== X-Gm-Message-State: AMCzsaWZ+MsJdwagmcl8ETPL5HXt+XBDZHiuggCcb0fPcnKTdUOKCjMq dAzVZo5NEszmAZDTpVqfJqPBng== X-Google-Smtp-Source: AOwi7QB+/Apfsn66Ad2WFl7BeLzOT4UexIfabwaPo+e+wJLPu+zGH7q0iQKdfi7KNPeOwcp78BBd1g== X-Received: by 10.101.77.144 with SMTP id p16mr2664403pgq.226.1507943508215; Fri, 13 Oct 2017 18:11:48 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v22sm4710783pgb.65.2017.10.13.18.11.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 18:11:47 -0700 (PDT) To: 6man From: Brian E Carpenter Subject: Loopback interface terminology issue Organization: University of Auckland Message-ID: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> Date: Sat, 14 Oct 2017 14:11:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 01:11:50 -0000 Hi, This come rather late in the day, but it results from some wordsmithing difficulties in a draft in another WG: The IPv6 specs are very clear that an address is assigned to an interface, not to a node, but they don't say anywhere that non-loopback addresses may be assigned to the loopback interface. However, sometimes as a practical matter, it's necessary to assign a routeable address (GUA or ULA) that is not created via a specific IPv6 interface. Conventionally, that is done by assigning it to the loopback interface. However, the only place I have found that defines 'loopback interface' for IPv6 is in the addressing architecture: 'a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere.' (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. Do people agree with something like the following? 'Note that other forms of unicast IPv6 address may be assigned to the loopback interface, in cases where an address is assigned to the node without being assigned to the interface to a specific link.' This is after all common practice in various operating systems; we just never documented it, as far as I know. Regards Brian Carpenter From nobody Fri Oct 13 18:41:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42554133158 for ; Fri, 13 Oct 2017 18:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.081 X-Spam-Level: X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsYczzryTQVD for ; Fri, 13 Oct 2017 18:41:17 -0700 (PDT) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1625D133057 for ; Fri, 13 Oct 2017 18:41:16 -0700 (PDT) Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.142]) ([150.101.127.187]) by ipmail03.adl6.internode.on.net with ESMTP; 14 Oct 2017 12:11:14 +1030 Message-ID: <1507945273.2487.70.camel@biplane.com.au> Subject: Re: Loopback interface terminology issue From: Karl Auer To: ipv6@ietf.org Date: Sat, 14 Oct 2017 12:41:13 +1100 In-Reply-To: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 01:41:20 -0000 On Sat, 2017-10-14 at 14:11 +1300, Brian E Carpenter wrote: > (RFC 4291, section 2.5.3). The text only mentions the loopback > address ::1. Need to stay clear on the difference between a loopback interface and the concept of localhost. ::1 is the localhost address; use it, and you are talking to "this host right here". It doesn't have to be on a loopback interface, but it generally makes sense for it to be, because a device may have no real network interfaces at all, but you still want to be able to talk to services running on it. And similarly, loopback interfaces do not necessarily have to have a localhost address on them. You can have lots of loopback interfaces on a host, and they present variations of "this host right here" e.g. by participating in different routing schemes or having particular services on them. The interface is not the canonical identity of the host, the localhost address is. That is ::1 in IPv6. Things have become confused over the years because of the very strong convention that "the" localhost address is on a loopback interface. The fact that there is only one (1) localhost address in IPv6 vs the entire /8 reserved in IPv4 is, I always thought, specifically to make the distinction clear. Or maybe it's just me. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B From nobody Fri Oct 13 18:52:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA9A1270AE for ; Fri, 13 Oct 2017 18:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qawy28cHVhTH for ; Fri, 13 Oct 2017 18:52:07 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 60B3A132F84 for ; Fri, 13 Oct 2017 18:52:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id DB5E5B8E for ; Sat, 14 Oct 2017 01:52:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epyYoOGPg1EO for ; Fri, 13 Oct 2017 20:52:06 -0500 (CDT) Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id B3D91B7F for ; Fri, 13 Oct 2017 20:52:06 -0500 (CDT) Received: by mail-it0-f71.google.com with SMTP id f187so7672588itb.6 for ; Fri, 13 Oct 2017 18:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nbGQpk9o6cAdobJ8+snRGuqhj908VfGrXe0rFrlmMdY=; b=d5ri+sSSQH6Td+pMQ6wVv0tQpqM8+nkhrdyuQAHjvhJEG6pHWE1h57CQBk/WKclH/E a7BFb26R6ldVlp5laONmlb32CCwjt4CvOY+pCsXl9XxWJK/K8egEIzqulrGn5PQFpL7W M8/OUExaq6y9SQlHeuk0CKog51y9MwkSXEwry0mEkDXQxt+lp1ebZnQlVWLW0blPcqUV AHjCkxZ5KK7YB+/hW7AqEw03iPnxRb4m4Nmj27wsKQwX3YuhArafSfBUQPx2NnzfO731 XBCNJ699F5QFS152IGiBfXNYleAjk6pnXEJBze1CAIx7epi/dv3C/RXsNyU0imeNIYtV szbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nbGQpk9o6cAdobJ8+snRGuqhj908VfGrXe0rFrlmMdY=; b=LHHbOMldNmT4eEvdQXMq7EJpqKinItIHAmTVzch+HaPe/N9IpwcBVFiGxrwtrjAKz6 3+2HXPDttJL8qRBlx+8RTHVahchr5tZPsmt0Gcq1+wZMoo9Pw6qURcFu2MNyzPJRS26h X6BAcDsqZwOswMhUKnolB1l0AUrzIfuHhA5h7USEwh2YvhwgA/VvmwoQCiENEqIHJLgT yDqNGlenTw23i4kV0STaT+bUwosqDDXGPzqdmmVBz8MWi6ZLCbFdN536gGwKh52OX6SS G148lIkXx1KpWkJLbILQOLWKASWj2V3PQJNypkyk4fSq6uuZjov3K5VwXvGOHp2kYLB2 CsDg== X-Gm-Message-State: AMCzsaVCyIYRYbJw38To18PhOXNLCRtyoQj1+9QhFFXPLXDueD5uu00R XOsZV1PDdT7jdvj/2Tilc58MMD/9FWOGAOL1WnF5VJCSV4lbjq3Gv/blVMkCKRMRqdznn8qTJOE d6n18KC64 X-Received: by 10.107.146.134 with SMTP id u128mr4027261iod.209.1507945925851; Fri, 13 Oct 2017 18:52:05 -0700 (PDT) X-Google-Smtp-Source: AOwi7QB+smzCFtxgOr7PSOCc30KrsSXkwGtILEoo3qJebLdx/Kl4r4RnaCR1umsYxoySE7gkONRfCA== X-Received: by 10.107.146.134 with SMTP id u128mr4027248iod.209.1507945925473; Fri, 13 Oct 2017 18:52:05 -0700 (PDT) Received: from [10.154.150.56] (mobile-166-175-62-152.mycingular.net. [166.175.62.152]) by smtp.gmail.com with ESMTPSA id z16sm1156781ioe.51.2017.10.13.18.52.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 18:52:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Loopback interface terminology issue From: David Farmer X-Mailer: iPhone Mail (15A421) In-Reply-To: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> Date: Fri, 13 Oct 2017 20:52:03 -0500 Cc: 6man Content-Transfer-Encoding: quoted-printable Message-Id: References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> To: Brian E Carpenter Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 01:52:09 -0000 > On Oct 13, 2017, at 20:11, Brian E Carpenter = wrote: >=20 > Hi, >=20 > This come rather late in the day, but it results from some wordsmithing > difficulties in a draft in another WG: >=20 > The IPv6 specs are very clear that an address is assigned to an interface,= > not to a node, but they don't say anywhere that non-loopback addresses may= > be assigned to the loopback interface. However, sometimes as a practical > matter, it's necessary to assign a routeable address (GUA or ULA) that > is not created via a specific IPv6 interface. Conventionally, that is > done by assigning it to the loopback interface. >=20 > However, the only place I have found that defines 'loopback interface' for= > IPv6 is in the addressing architecture: 'a virtual interface (typically > called the "loopback interface") to an imaginary link that goes nowhere.' > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1= . >=20 > Do people agree with something like the following? >=20 > 'Note that other forms of unicast IPv6 address may be assigned to the > loopback interface, in cases where an address is assigned to the node > without being assigned to the interface to a specific link.' This makes sense for a router participating in a routing protocol, so other r= outers know how to reach the address, and the hosts they route for. I=E2=80=99= m not sure it necessarily makes sense on typical hosts which do not normally= participate in any routing protocols, even multi-homed hosts for that matte= r. A typical host with an address other that ::1 on a loopback interface wo= uld need static route on a router connected to at least one real interface o= f the host to successfully forward traffic to the address from anywhere othe= r than the host itself. It might also be good to say that such an address on a loopback interface co= mmonly has a /128 prefix length. > This is after all common practice in various operating systems; we > just never documented it, as far as I know. I=E2=80=99d say common practice on routers, not so common on hosts. > Regards > Brian Carpenter >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Oct 13 19:16:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1D1326ED for ; Fri, 13 Oct 2017 19:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXp5GOTfaqkT for ; Fri, 13 Oct 2017 19:16:10 -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 5561C1321DF for ; Fri, 13 Oct 2017 19:16:10 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id x7so11727832pfa.1 for ; Fri, 13 Oct 2017 19:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oOsTkrj/PtqSLYWH20CTvy8tQrQUszJHSvw22bP+6wY=; b=iykv2iBieYj0tzYIN7rYILbEGq9eKT8cHuM09M7KUa897oaQWtqsFXtjXCMz71o2rS ln0FxFUiOxoxP2lmFs4kbl1RwcHnHcdiIZxakpqaI4vWNB0FehuTdunq4sbU2hzIps0D JUUIvhCkPg8uiUXoj4redShb1wwEm1/ySAETZ7aXt7KrcwE/Bo1fN3JbAwQa4laA4Xkx BoQjmZ/DUpOFHo2Es15jfdXPi85+t57nQP4LpKIybOG8p6hswO2F2amsmWx3ff0v4TdP G720UeGLib8UhCJ4dtAXack9TvpaF9Ym7qd6uvgwgi4af26nM14gdIIgf8Wv9ZAkG3y3 9CSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oOsTkrj/PtqSLYWH20CTvy8tQrQUszJHSvw22bP+6wY=; b=ObswBU1JnrjOSU+AGkTnYTOTS1yPUBJkDdzXJWmPvZ2X7KC9rZm+w12CC/+RnCiF/7 YhqIxS0ypzhpkIpRFL2ZIZB7bPmM+QaQbYF7YTNfE/5+VTNKiYZivnos0jA0oW81GtEh outTz/tzkVfGK9vNITpMSaYwblO+2jpWgn51rY34y4mHdhmRdJX+3N5kIse+Rwhnscae awLCRc33Ln8tdtgdygyriLv1BF/AbwrlNiAoDD6QcGS/y7SPZjGklq7GCjJNIg2KT0Fh 9QMz5oC/o8KhiP6RpoAF3dYN9/jyGaM4Vu7vuXDeSqzSECiV41YTw+j73iGhavfZSlh6 Ickw== X-Gm-Message-State: AMCzsaXwacKVts4Wjpg4m4k1o3/QFuWcI75nilobWZBOguXSd71TBlrc ztJYCEuyeleqAud8GR0ZCgUFXA== X-Google-Smtp-Source: AOwi7QDsHWXVTK89KYsY3lfYg70DxJnEhp/a8SWOR7cXqoTvb55TztpqkEmX3MMtWrTfFMzem3VqgQ== X-Received: by 10.159.203.197 with SMTP id r5mr2986533plo.431.1507947369514; Fri, 13 Oct 2017 19:16:09 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d76sm4687833pfk.69.2017.10.13.19.16.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 19:16:08 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: 6man References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 14 Oct 2017 15:16:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150774513036.24791.2138264254901122467@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:16:12 -0000 Hi, RSVP in IPv6 [RFC2205] uses packets with a Router Alert hop-by-hop option. So although it is not embedded in application packets, it is otherwise very similar: in band, following the same path as application packets, and triggering hop-by-hop processing in the same routers. RSVP for Integrated Services was a complete failure. So my first questions are: 1: What is the authors' full analysis of why RSVP failed? 2: How does the proposed solution avoid the same failure? In particular, I do not understand your argument about scalability. While that was an obvious issue for RSVP, it could be fixed in the way you describe: by limiting the number of using applications. The fundamental scaling issue for RSVP was the number of session state items per router, and your solution needs exactly the same number of session state items. So why will you succeed where RSVP failed? > End user application cannot directly use DiffServ. Not true. The advanced socket API allows the transport user to set the DSCP via IPV6_TCLASS [RFC3542]. It's been done for many years, for example in IP telephones. What is lacking is a host software package to make this API feature useful, but any QoS solution needs that. In your terminology, that is the application interface to the closed-loop control system. Note that RTCWEB has chosen to support Diffserv [https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/] > 3.2. IP In-band signaling > > There is no definition for IP in-band signaling. Not true. That's exactly what DiffServ is. You could argue that it's too limited, but after 19 years we have not exhausted the DSCP code space defined in [RFC2474]. (As far as I know, nobody has yet combined use of the DSCP with the Flow Label. There is scope for creativity there.) > Flow level In-band Signaling > The control message and data packet share the same flow > identification. The flow identification could be 5 tuples ... I agree with the comment that the IPv6 flow label is a much better choice. It is already well defined [RFC6437] and widely supported by operating systems, it works for any transport protcol, works for encrypted packets, and works for packets with multiple extension headers. If you want per-flow granularity, the flow label is perfect. > The HbH-EH may be examined and processed by the nodes that are > explicitly configured to do so [RFC8200] which also says in section 4.8: " New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behavior. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized." I believe you need much more explanation of why we should ignore this recommendation. > 8. Security Considerations > > There is no security issue introduced by this document I think this section needs more work. Regards Brian Carpenter On 12/10/2017 07:05, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 in-band signaling for the support of transport with QoS > Authors : Lin Han > Guoping Li > Boyan Tu > Xuefei Tan > Frank Li > Richard Li > Jeff Tantsura > Kevin Smith > Filename : draft-han-6man-in-band-signaling-for-transport-qos-00.txt > Pages : 40 > Date : 2017-10-11 > > Abstract: > This document proposes a method to support the IP transport service > that could guarantee a certain level of service quality in bandwidth > and latency. The new transport service is fine-grained and could > apply to individual or aggregated TCP/UDP flow(s). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-han-6man-in-band-signaling-for-transport-qos/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-transport-qos-00 > https://datatracker.ietf.org/doc/html/draft-han-6man-in-band-signaling-for-transport-qos-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Oct 13 19:22:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39211132944 for ; Fri, 13 Oct 2017 19:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfOgTZa489lg for ; Fri, 13 Oct 2017 19:22:42 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F191241F3 for ; Fri, 13 Oct 2017 19:22:42 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g6so1124849pgn.6 for ; Fri, 13 Oct 2017 19:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iSoOZG7Uc8KcVtANXjDzb74J37ul4YUoGKJ43Wc/Hy0=; b=CKhRdi3a8QSL3IpZ600ja2WqZhik+eKujvM1qnz/CSEOsxQ9/WKT559ENbB6Lsbq2n NzNkOKch6Guk0T017ZZQjNMitMgrF6JsQtuCNm9XARLe+vqSciSjlV7u2cqLGNeXccW9 qseznCgEQX+D6ju+Ehsd6PVuocNkYJ86qMPQpS4nfUJmjTv1QK22+b3dUvMxneaa2UT7 YDXK3dOxFLuJy4syHm5q6kghG0TTCdV5kIETKNRajd4jzsXCNJDGfFU6zZm9PuGXOC7C sBFsZdm0QxKN8Gw7roRU9wVX4dUvmZQZOqQjzj/pjXgMlqpYKGw7wPA+r6fE29oCw4N1 Y28Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=iSoOZG7Uc8KcVtANXjDzb74J37ul4YUoGKJ43Wc/Hy0=; b=hx9TWGHSGGyYQbgQguHKGGws6ICczEndD3i//bGRUdIxmmnZ44aNmrjKyIRloFswdb GFNw1XXbb7zVf5HkAp0QR5CW4UqxkZAifNIERcmAzwZlhzBuYZbZa9hh8uiR892Zw4ZW SnUYvOUiXui2AsoQHAIN/qjfJaUrJ3VQ1ip5cHmZ7gbivHKb3NZW4v1EENv5uGGRBzyu puDtQdYuOWt2Bng80ysu8zFK78nvajBmNevjK8pWaJWG1A/T3KkPplVddLvAVdlES4dB StDa5xingnZ5ylT5NYHgr2EkLbFunqXtZHKqQP1mUv0Pa3HpXovNtT7dHG//rhCe8QO9 r0jg== X-Gm-Message-State: AMCzsaXX+2k/+HMjky0WJXlvzrApdCdHTvtmbszH1zlZyrRw18czIz9D xCgSJIpJx8Rb9jlkxhqwUZtTlQ== X-Google-Smtp-Source: AOwi7QA6K8OtiwVq4KiCbIjNj6NL4hcnP9MoK9T6Z0wx257aXUdNBmCvPA7BQMEX6dE8xMEAaEshYA== X-Received: by 10.101.65.76 with SMTP id x12mr2830972pgp.198.1507947762012; Fri, 13 Oct 2017 19:22:42 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r81sm4263936pfj.106.2017.10.13.19.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 19:22:41 -0700 (PDT) Subject: Re: Loopback interface terminology issue To: David Farmer Cc: 6man References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 14 Oct 2017 15:22:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:22:44 -0000 On 14/10/2017 14:52, David Farmer wrote: >=20 >> On Oct 13, 2017, at 20:11, Brian E Carpenter wrote: >> >> Hi, >> >> This come rather late in the day, but it results from some wordsmithin= g >> difficulties in a draft in another WG: >> >> The IPv6 specs are very clear that an address is assigned to an interf= ace, >> not to a node, but they don't say anywhere that non-loopback addresses= may >> be assigned to the loopback interface. However, sometimes as a practic= al >> matter, it's necessary to assign a routeable address (GUA or ULA) that= >> is not created via a specific IPv6 interface. Conventionally, that is >> done by assigning it to the loopback interface. >> >> However, the only place I have found that defines 'loopback interface'= for >> IPv6 is in the addressing architecture: 'a virtual interface (typicall= y >> called the "loopback interface") to an imaginary link that goes nowher= e.' >> (RFC 4291, section 2.5.3). The text only mentions the loopback address= ::1. >> >> Do people agree with something like the following? >> >> 'Note that other forms of unicast IPv6 address may be assigned to the >> loopback interface, in cases where an address is assigned to the node >> without being assigned to the interface to a specific link.' >=20 > This makes sense for a router participating in a routing protocol, so o= ther routers know how to reach the address, and the hosts they route for.= I=E2=80=99m not sure it necessarily makes sense on typical hosts which d= o not normally participate in any routing protocols, even multi-homed hos= ts for that matter. A typical host with an address other that ::1 on a l= oopback interface would need static route on a router connected to at lea= st one real interface of the host to successfully forward traffic to the = address from anywhere other than the host itself. >=20 > It might also be good to say that such an address on a loopback interfa= ce commonly has a /128 prefix length. Not always, though. BCP198 applies at all times ;-) >=20 >> This is after all common practice in various operating systems; we >> just never documented it, as far as I know. >=20 > I=E2=80=99d say common practice on routers, not so common on hosts. Well, yes, but that includes hosts with one or two explicit routes added by hand, at which point they become de facto routers. So I think it's saf= e to say 'node'. Brian From nobody Fri Oct 13 19:24:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBECA132F84 for ; Fri, 13 Oct 2017 19:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18iS3WeYo8Yy for ; Fri, 13 Oct 2017 19:24:01 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712791241F3 for ; Fri, 13 Oct 2017 19:24:01 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id l188so11713218pfc.6 for ; Fri, 13 Oct 2017 19:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YOzf5O02/Mu/CxWzobxSjDPb5sZuKEhESvd7qVCi4NY=; b=gRoM1tWEhHY4fdeJBafSh++C9Sy/SVdqTCXuGpgAiaGCjbUbmjoxUbfYWexYLe9vPG SogOkeJvt/dg1ggpCm0/AP447P0ulApbcOEGZx1YRYnLpPfXD+rARPvbjXRQ07aknMSi 9EL1aHs9z2NLMEC17YgPjAg+SnpInEhjZl1eqKSQh7S27wg7yEx2SC+6RO8lMHSkl2pj HQZIshWN8xcr0cw7Ea0U/fak18Ma7/zTyQvIl1jcabaWUc7uneXUscbMXdB7yl2b3N9m tCKeZZfWfEQakHd32ShCjDbZqg4lqa3JKkOiJTd5X2HzQ1ZvoMJZFtib4xwjgCDATt8/ 7wHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YOzf5O02/Mu/CxWzobxSjDPb5sZuKEhESvd7qVCi4NY=; b=oqR+YIuESKXW1V/AodQ0wbGjQlkJ2TPGOEeHrqii/xsbn+Z0i8ODb7Xf9HkxQwffVc Q2VzYFhszRn8jtTCMy65Me5XpYsAlwaLO9ZlHpKWsrHff4A1KSgb3OJgYQ63DQJaVa72 OH1gIJr6Z8txgg/ZOSUTbxPuLnr1uMWqMal2/SjRPsMFOusekodymQeMCN24c4w4bIBc OCvrmQLpn3t6n9hG/aa+E3jRlZkxxPTN11WehamSfXJlgQjNXhIbEVHlhBdBGPqrXMnY sHfiDfDpPB1FhvvqTrJxre6Gs5xEgzrc6EmuA3WQvbiri9qoVY8czQQfCnLcwfEaxgr/ 4QXQ== X-Gm-Message-State: AMCzsaUKuvxZXOZIYWIhcuBqLAalvChRw5lXMyfdHpufFcPw+OcgP7mB o0STbcaR+WOS536y90lIhKxkeA== X-Google-Smtp-Source: AOwi7QCS52SUs17RMQHcO9Ql3h4uWuQ5yAca5ZOrCpVJ0lqgZMYOs5bT2cEucr1Bur9IQWPe9RzhXQ== X-Received: by 10.101.76.71 with SMTP id l7mr2838309pgr.242.1507947840428; Fri, 13 Oct 2017 19:24:00 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h1sm3808761pgp.37.2017.10.13.19.23.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 19:23:59 -0700 (PDT) Subject: Re: Loopback interface terminology issue To: ipv6@ietf.org References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <1507945273.2487.70.camel@biplane.com.au> From: Brian E Carpenter Organization: University of Auckland Message-ID: <722554ea-61c6-e8d9-e535-da55c908dfc3@gmail.com> Date: Sat, 14 Oct 2017 15:24:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1507945273.2487.70.camel@biplane.com.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 02:24:03 -0000 On 14/10/2017 14:41, Karl Auer wrote: > On Sat, 2017-10-14 at 14:11 +1300, Brian E Carpenter wrote: >> (RFC 4291, section 2.5.3). The text only mentions the loopback >> address ::1. > > Need to stay clear on the difference between a loopback interface and > the concept of localhost. > > ::1 is the localhost address; use it, and you are talking to "this host > right here". It doesn't have to be on a loopback interface, but it > generally makes sense for it to be, because a device may have no real > network interfaces at all, but you still want to be able to talk to > services running on it. > > And similarly, loopback interfaces do not necessarily have to have a > localhost address on them. You can have lots of loopback interfaces on > a host, and they present variations of "this host right here" e.g. by > participating in different routing schemes or having particular > services on them. The interface is not the canonical identity of the > host, the localhost address is. That is ::1 in IPv6. > > Things have become confused over the years because of the very strong > convention that "the" localhost address is on a loopback interface. > > The fact that there is only one (1) localhost address in IPv6 vs the > entire /8 reserved in IPv4 is, I always thought, specifically to make > the distinction clear. > > Or maybe it's just me. No, I think you're right. ::1 is not really at issue here. Brian From nobody Sat Oct 14 18:36:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748C01320DC for ; Sat, 14 Oct 2017 18:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0Y1EUh54-wh for ; Sat, 14 Oct 2017 18:36:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8C613219E for ; Sat, 14 Oct 2017 18:36:43 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6E22F58C4B0; Sun, 15 Oct 2017 03:36:39 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4B953B0CEA4; Sun, 15 Oct 2017 03:36:39 +0200 (CEST) Date: Sun, 15 Oct 2017 03:36:39 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: 6man Subject: Re: Loopback interface terminology issue Message-ID: <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 01:36:46 -0000 Thanks Brian, for bringing this up I think 4291bis should indeed have an actual definition of a loopback interface. "virtual interface to an imaginary link that goes nowhere" really sucks as a non-definition. IMHO: A loopback interface is an attachment to a node internal "loopback link". If other addresses beside "loopback addresses" are assigned to such a link, then this implies that the interface is configured to forward non-self-destined packets. That second sentence is the key functionality IMHO to define architecturally what efverybody has been doing on routers for decades. Not sure where to best write this into. IMHO its a refinement/update to 8200, but could vbe put into 4291bis (claiming 8200 update). Cheers Toerless On Sat, Oct 14, 2017 at 02:11:54PM +1300, Brian E Carpenter wrote: > Hi, > > This come rather late in the day, but it results from some wordsmithing > difficulties in a draft in another WG: > > The IPv6 specs are very clear that an address is assigned to an interface, > not to a node, but they don't say anywhere that non-loopback addresses may > be assigned to the loopback interface. However, sometimes as a practical > matter, it's necessary to assign a routeable address (GUA or ULA) that > is not created via a specific IPv6 interface. Conventionally, that is > done by assigning it to the loopback interface. > > However, the only place I have found that defines 'loopback interface' for > IPv6 is in the addressing architecture: 'a virtual interface (typically > called the "loopback interface") to an imaginary link that goes nowhere.' > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. > > Do people agree with something like the following? > > 'Note that other forms of unicast IPv6 address may be assigned to the > loopback interface, in cases where an address is assigned to the node > without being assigned to the interface to a specific link.' > > This is after all common practice in various operating systems; we > just never documented it, as far as I know. > > Regards > Brian Carpenter > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Sat Oct 14 18:53:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC91326F6 for ; Sat, 14 Oct 2017 18:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ACTmozLrf8hA for ; Sat, 14 Oct 2017 18:53:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 BA03C1326DF for ; Sat, 14 Oct 2017 18:53:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5A1213AC246; Sun, 15 Oct 2017 01:53:23 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1B6B8160052; Sun, 15 Oct 2017 01:53:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F116C160064; Sun, 15 Oct 2017 01:53:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qDhYl2Az3Bpv; Sun, 15 Oct 2017 01:53:22 +0000 (UTC) Received: from rock.dv.isc.org (new1174826.lnk.telstra.net [120.150.168.54]) by zmx1.isc.org (Postfix) with ESMTPSA id 8BEBA160052; Sun, 15 Oct 2017 01:53:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 764838AF5D66; Sun, 15 Oct 2017 12:53:18 +1100 (AEDT) To: Toerless Eckert Cc: Brian E Carpenter , 6man From: Mark Andrews References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> Subject: Re: Loopback interface terminology issue In-reply-to: Your message of "Sun, 15 Oct 2017 03:36:39 +0200." <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> Date: Sun, 15 Oct 2017 12:53:18 +1100 Message-Id: <20171015015318.764838AF5D66@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 01:53:27 -0000 In message <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de>, Toerless Eckert writes: > Thanks Brian, for bringing this up > > I think 4291bis should indeed have an actual definition of a loopback > interface. "virtual interface to an imaginary link that goes nowhere" > really sucks as a non-definition. > > IMHO: A loopback interface is an attachment to a node internal > "loopback link". If other addresses beside "loopback addresses" are > assigned to such a link, then this implies that the interface > is configured to forward non-self-destined packets. No. Whether such addresses are forwarded by default or not depends on the weak/strong host model in use. > That second sentence is the key functionality IMHO to define > architecturally what efverybody has been doing on routers for decades. > > Not sure where to best write this into. IMHO its a refinement/update > to 8200, but could vbe put into 4291bis (claiming 8200 update). > > Cheers > Toerless Loopback interfaces are also used for test networks wholely constrained to the node. > On Sat, Oct 14, 2017 at 02:11:54PM +1300, Brian E Carpenter wrote: > > Hi, > > > > This come rather late in the day, but it results from some wordsmithing > > difficulties in a draft in another WG: > > > > The IPv6 specs are very clear that an address is assigned to an interface, > > not to a node, but they don't say anywhere that non-loopback addresses may > > be assigned to the loopback interface. However, sometimes as a practical > > matter, it's necessary to assign a routeable address (GUA or ULA) that > > is not created via a specific IPv6 interface. Conventionally, that is > > done by assigning it to the loopback interface. > > > > However, the only place I have found that defines 'loopback interface' for > > IPv6 is in the addressing architecture: 'a virtual interface (typically > > called the "loopback interface") to an imaginary link that goes nowhere.' > > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. > > > > Do people agree with something like the following? > > > > 'Note that other forms of unicast IPv6 address may be assigned to the > > loopback interface, in cases where an address is assigned to the node > > without being assigned to the interface to a specific link.' > > > > This is after all common practice in various operating systems; we > > just never documented it, as far as I know. > > > > Regards > > Brian Carpenter > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -- > --- > tte@cs.fau.de > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Oct 14 19:41:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7931D126BF3 for ; Sat, 14 Oct 2017 19:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiZr-ACzmdJW for ; Sat, 14 Oct 2017 19:41:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D38132031 for ; Sat, 14 Oct 2017 19:41:34 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2189058C4B0; Sun, 15 Oct 2017 04:41:30 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 060F1B0CEA5; Sun, 15 Oct 2017 04:41:29 +0200 (CEST) Date: Sun, 15 Oct 2017 04:41:29 +0200 From: Toerless Eckert To: Mark Andrews Cc: 6man Subject: Re: Loopback interface terminology issue Message-ID: <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171015015318.764838AF5D66@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 02:41:37 -0000 On Sun, Oct 15, 2017 at 12:53:18PM +1100, Mark Andrews wrote: > > IMHO: A loopback interface is an attachment to a node internal > > "loopback link". If other addresses beside "loopback addresses" are > > assigned to such a link, then this implies that the interface > > is configured to forward non-self-destined packets. > > No. Whether such addresses are forwarded by default or not depends on > the weak/strong host model in use. Not really. If the transport stack (a) logically attaches to the loopback interface then the loopback source address is the source address corresponding to the interface. The difference between strong and weak model would only come in if a transport socket (b) binds to a physical interface and tries to send/receive packets for the loopback address. I think the stacks i know logically do (a), althogh i am not sure how cleanly it's implemented. If its 100% clean then the TTL of the sent packet should be decremented by 1 before output on the physcial interface. Not sure which stacks this is done in. > Loopback interfaces are also used for test networks wholely constrained > to the node. Ok. How about: If other addresses beside "loopback addresses" are assigned to such a link, then the interface needs to be configured to forward non-self-destined packets originated from the loopback interface (see rfc8200, section 2). Cheers Toerless > > On Sat, Oct 14, 2017 at 02:11:54PM +1300, Brian E Carpenter wrote: > > > Hi, > > > > > > This come rather late in the day, but it results from some wordsmithing > > > difficulties in a draft in another WG: > > > > > > The IPv6 specs are very clear that an address is assigned to an interface, > > > not to a node, but they don't say anywhere that non-loopback addresses may > > > be assigned to the loopback interface. However, sometimes as a practical > > > matter, it's necessary to assign a routeable address (GUA or ULA) that > > > is not created via a specific IPv6 interface. Conventionally, that is > > > done by assigning it to the loopback interface. > > > > > > However, the only place I have found that defines 'loopback interface' for > > > IPv6 is in the addressing architecture: 'a virtual interface (typically > > > called the "loopback interface") to an imaginary link that goes nowhere.' > > > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. > > > > > > Do people agree with something like the following? > > > > > > 'Note that other forms of unicast IPv6 address may be assigned to the > > > loopback interface, in cases where an address is assigned to the node > > > without being assigned to the interface to a specific link.' > > > > > > This is after all common practice in various operating systems; we > > > just never documented it, as far as I know. > > > > > > Regards > > > Brian Carpenter > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -- > > --- > > tte@cs.fau.de > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Oct 15 18:32:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C157C1332DA for ; Sun, 15 Oct 2017 18:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NNMEkeVeALp for ; Sun, 15 Oct 2017 18:32:29 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 F13331332D4 for ; Sun, 15 Oct 2017 18:32:28 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id s41so8655021uab.10 for ; Sun, 15 Oct 2017 18:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ks7u2TTOditn6/TghwUcGJbRerwGoV76/wj3HOKIUxc=; b=FVCi6aMClabozvBW0SLnIH7yIK1RCeS0pXdME/lProggdDdksKxddl4Ho1agbRYRTC 0lJh5AC3RMSsEHnMC+aO426/qxfkYyo67cYdbeU/VQHni7MD3/QeeDjwH3WrjD1MdiFy npugEF5Biw75l+/BLRgUCwCrwqJ5wA/xMgSn76nJU8Hf36vBhUQD5J8g2A7CNKxoSXaD mtov54jW2jieDSuoYAuyNJiV/Hm8lLJv8H1uW4VW2A8f0gkH6uYrHD9cGvomZBeLFhTo zNd29ZxIZasj3a/vXIGdmXFm7BzYdZSpZd4yT5nAhxBKJ04VMEGLOIDr0qdDqS0bPR6V pdug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ks7u2TTOditn6/TghwUcGJbRerwGoV76/wj3HOKIUxc=; b=ieuu3q6zmyO6+5VlPxpN4T3ShboI3cFiRUt52NJAO5mYmtQMms629x+YcvTvccRQst xYy+FmlEJmEsqm8eR53Qs49Z+U16OwHrlMDsDvg4LFsEGeG7ihFsXr7NPUXXEfvzQ0MH arW2y2Hkz5pzHAQMk0hDtxg4+R7xSmOcN/jMDdTguknharsFDNc33Z5x/hmmWAXpc9+5 cNjFkfZjVOhqQwkxXaYE0QycXxiSIjlvxkgy2NbZscJSOZjGRApkE0ON0Mp4NxhOMmy3 egTCnSprHVjiLZEruq/Fgyh498kcOI2dfDGOJ2mcNEXkQ9FDGSqG/dDK+Djq7ma2pij9 mIsA== X-Gm-Message-State: AMCzsaXXwOw135QjgXFqhzptNJLCXLBQMPC5BxWfBkG3CRt7ed3jhOEn lPyKrh0jq7ce/xt7gsSvUEYIyZYSek+ps+r2ms8= X-Google-Smtp-Source: AOwi7QCBBcfHbiHqN5bPRrSj3jAFgw0oRgfJ4yjLt34p9wj3WGlIqkQ5pw76rHUzT2UnURlqio/l5vCFM/hahCq88aM= X-Received: by 10.176.80.241 with SMTP id d46mr6345183uaa.53.1508117547962; Sun, 15 Oct 2017 18:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Sun, 15 Oct 2017 18:32:27 -0700 (PDT) Received: by 10.159.52.221 with HTTP; Sun, 15 Oct 2017 18:32:27 -0700 (PDT) In-Reply-To: <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> From: Mark Smith Date: Mon, 16 Oct 2017 12:32:27 +1100 Message-ID: Subject: Re: Loopback interface terminology issue To: Toerless Eckert Cc: Mark Andrews , 6man WG Content-Type: multipart/alternative; boundary="94eb2c191064b9d548055b9ffa3d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 01:32:31 -0000 --94eb2c191064b9d548055b9ffa3d Content-Type: text/plain; charset="UTF-8" On 15 Oct. 2017 13:41, "Toerless Eckert" wrote: On Sun, Oct 15, 2017 at 12:53:18PM +1100, Mark Andrews wrote: > > IMHO: A loopback interface is an attachment to a node internal > > "loopback link". If other addresses beside "loopback addresses" are > > assigned to such a link, then this implies that the interface > > is configured to forward non-self-destined packets. > > No. Whether such addresses are forwarded by default or not depends on > the weak/strong host model in use. Not really. If the transport stack (a) logically attaches to the loopback interface then the loopback source address is the source address corresponding to the interface. The difference between strong and weak model would only come in if a transport socket (b) binds to a physical interface and tries to send/receive packets for the loopback address. I think the stacks i know logically do (a), althogh i am not sure how cleanly it's implemented. If its 100% clean then the TTL of the sent packet should be decremented by 1 before output on the physcial interface. Not sure which stacks this is done in. > Loopback interfaces are also used for test networks wholely constrained > to the node. Ok. How about: If other addresses beside "loopback addresses" are assigned to such a link, then the interface needs to be configured to forward non-self-destined packets originated from the loopback interface (see rfc8200, section 2). This draft might help. In IPv4, there are different forwarding rules for hosts and routers over the loopback interface for the 127/8 prefix. This draft proposes a larger IPv6 prefix for loopback, and mirrors those differences. https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04 Cheers Toerless > > On Sat, Oct 14, 2017 at 02:11:54PM +1300, Brian E Carpenter wrote: > > > Hi, > > > > > > This come rather late in the day, but it results from some wordsmithing > > > difficulties in a draft in another WG: > > > > > > The IPv6 specs are very clear that an address is assigned to an interface, > > > not to a node, but they don't say anywhere that non-loopback addresses may > > > be assigned to the loopback interface. However, sometimes as a practical > > > matter, it's necessary to assign a routeable address (GUA or ULA) that > > > is not created via a specific IPv6 interface. Conventionally, that is > > > done by assigning it to the loopback interface. > > > > > > However, the only place I have found that defines 'loopback interface' for > > > IPv6 is in the addressing architecture: 'a virtual interface (typically > > > called the "loopback interface") to an imaginary link that goes nowhere.' > > > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. > > > > > > Do people agree with something like the following? > > > > > > 'Note that other forms of unicast IPv6 address may be assigned to the > > > loopback interface, in cases where an address is assigned to the node > > > without being assigned to the interface to a specific link.' > > > > > > This is after all common practice in various operating systems; we > > > just never documented it, as far as I know. > > > > > > Regards > > > Brian Carpenter > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -- > > --- > > tte@cs.fau.de > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -------------------------------------------------------------------- > 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 -------------------------------------------------------------------- --94eb2c191064b9d548055b9ffa3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 15 Oct. 2017 13:41, "Toerless Eckert" <tte@cs.fau.de> wrote:
On Sun, Oct 15, 2017 a= t 12:53:18PM +1100, Mark Andrews wrote:
> > IMHO: A loopback interface is an attachment to a node internal > > "loopback link". If other addresses beside "loopba= ck addresses" are
> > assigned to such a link, then this implies that the interface
> > is configured to forward non-self-destined packets.
>
> No.=C2=A0 Whether such addresses are forwarded by default or not depen= ds on
> the weak/strong host model in use.

Not really. If the transport stack (a) logically attaches to the loop= back
interface then the loopback source address is the source address correspond= ing
to the interface. The difference between strong and weak model would only come in if a transport socket (b) binds to a physical interface and tries to send/receive packets for the loopback address.

I think the stacks i know logically do (a), althogh i am not sure how
cleanly it's implemented. If its 100% clean then the TTL of the sent pa= cket
should be decremented by 1 before output on the physcial interface. Not
sure which stacks this is done in.

> Loopback interfaces are also used for test networks wholely constraine= d
> to the node.

Ok. How about:

If other addresses beside "loopback addresses" are assigned to su= ch a link,
then the interface needs to be configured to forward non-self-destine= d
packets originated from the loopback interface (see rfc8200, section 2).


This draft might help.

In IPv4, there are different forwarding rules= for hosts and routers over the loopback interface for the 127/8 prefix.

This draft proposes a larg= er IPv6 prefix for loopback, and mirrors those differences.





Cheers
=C2=A0 =C2=A0 Toerless

> > On Sat, Oct 14, 2017 at 02:11:54PM +1300, Brian E Carpenter wrote= :
> > > Hi,
> > >
> > > This come rather late in the day, but it results from some w= ordsmithing
> > > difficulties in a draft in another WG:
> > >
> > > The IPv6 specs are very clear that an address is assigned to= an interface,
> > > not to a node, but they don't say anywhere that non-loop= back addresses may
> > > be assigned to the loopback interface. However, sometimes as= a practical
> > > matter, it's necessary to assign a routeable address (GU= A or ULA) that
> > > is not created via a specific IPv6 interface. Conventionally= , that is
> > > done by assigning it to the loopback interface.
> > >
> > > However, the only place I have found that defines 'loopb= ack interface' for
> > > IPv6 is in the addressing architecture: 'a virtual inter= face (typically
> > > called the "loopback interface") to an imaginary l= ink that goes nowhere.'
> > > (RFC 4291, section 2.5.3). The text only mentions the loopba= ck address ::1.
> > >
> > > Do people agree with something like the following?
> > >
> > > 'Note that other forms of unicast IPv6 address may be as= signed to the
> > > loopback interface, in cases where an address is assigned to= the node
> > > without being assigned to the interface to a specific link.&= #39;
> > >
> > > This is after all common practice in various operating syste= ms; we
> > > just never documented it, as far as I know.
> > >
> > > Regards
> > >=C2=A0 =C2=A0 Brian Carpenter
> > >
> > >
> > > -------------------------------------------------------= -------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
> > > -------------------------------------------------------= -------------
> >
> > --
> > ---
> > tte@cs.fau.de
> >
> > ------------------------------------------------------------= --------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6
> > ------------------------------------------------------------= --------
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: = +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0INTERNET: marka@isc.org
>
> ------------------------------------------------------------= --------
> 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
-----------------------------------------------------------------= ---

--94eb2c191064b9d548055b9ffa3d-- From matao.matao@huawei.com Sun Oct 15 20:51:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA81A1270AE for ; Sun, 15 Oct 2017 20:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvK0jNUmovLx for ; Sun, 15 Oct 2017 20:51:30 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012171320CF for ; Sun, 15 Oct 2017 20:51:29 -0700 (PDT) Received: from 172.30.72.55 (EHLO NKGEML413-HUB.china.huawei.com) ([172.30.72.55]) by dggrg01-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AYE58871; Mon, 16 Oct 2017 11:51:27 +0800 (CST) Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Mon, 16 Oct 2017 11:51:23 +0800 From: "Matao (D)" To: "ipv6@ietfa.amsl.com" Subject: =?gb2312?B?tPC4tDogQ29uZmlybTogaXB2NkBpZXRmYS5hbXNsLmNvbTpXZVFzWFFyQmdf?= =?gb2312?Q?3e:S13e2IY9NOoJeppiffLC345H3yY4vsAwr9vHAQ?= Thread-Topic: Confirm: ipv6@ietfa.amsl.com:WeQsXQrBg_3e:S13e2IY9NOoJeppiffLC345H3yY4vsAwr9vHAQ Thread-Index: AQHTRjHWNcKHGbg+y0qY8Rz6XGkRJqLl16vg Date: Mon, 16 Oct 2017 03:51:23 +0000 Message-ID: <23DD990E3E2E724E887EA303C763DAA54E1F8369@nkgeml514-mbx.china.huawei.com> References: <20171016034949.AD5D61270AE@ietfa.amsl.com> In-Reply-To: <20171016034949.AD5D61270AE@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.162.208] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59E42CBF.008A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 072f89fb07c4e1e93d8874a901aef164 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 03:52:54 -0000 DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpcHY2QGlldGZhLmFtc2wuY29tIFttYWls dG86aXB2NkBpZXRmYS5hbXNsLmNvbV0gDQq3osvNyrG85DogMjAxN8TqMTDUwjE2yNUgMTE6NTAN CsrVvP7IyzogTWF0YW8gKEQpDQrW98ziOiBDb25maXJtOiBpcHY2QGlldGZhLmFtc2wuY29tOldl UXNYUXJCZ18zZTpTMTNlMklZOU5Pb0plcHBpZmZMQzM0NUgzeVk0dnNBd3I5dkhBUQ0KDQoNCkNv bmZpcm1hdGlvbiBvZiBsaXN0IHBvc3RpbmcgLS0gY29uZmlybWF0aW9uIElEOiBXZVFzWFFyQmdf M2UNCg0KVGhlIGlldGYub3JnIG1haWxpbmctbGlzdCBzZXJ2ZXIgaGFzIHJlY2VpdmVkIGEgbGlz dCBwb3N0aW5nIGZyb20gbWF0YW8ubWF0YW9AaHVhd2VpLmNvbSB0byBpcHY2QGlldGZhLmFtc2wu Y29tIHdpdGggdGhlIHN1YmplY3QNCidSZTpSZTogSS1EIEFjdGlvbjoNCiBkcmFmdC1oYW4tNm1h bi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0LXFvcy0wMC50eHQnDQoNCkFzIHRoZSBz ZW5kZXIgYWRkcmVzcyBpc24ndCBzdWJzY3JpYmVkIHRvIHRoZSBsaXN0LCBhbmQgaGFzIG5vdCBi ZWVuIGNvbmZpcm1lZCBlYXJsaWVyLCB3ZSBoYXZlIHRvIHJlcXVlc3QgYSBjb25maXJtYXRpb24g b2YgdGhlIGFkZHJlc3MuDQpUbyBjb25maXJtIHRoZSBhZGRyZXNzLCBzZW5kIGEgbWVzc2FnZSB0 byBpcHY2QGlldGZhLmFtc2wuY29tLCB3aXRoIHRoZSBzYW1lIHN1YmplY3QgbGluZSBhcyB0aGlz IG1lc3NhZ2UuDQoNCihTaW1wbHkgc2VuZGluZyBhICdyZXBseScgdG8gdGhpcyBtZXNzYWdlIHNo b3VsZCB3b3JrIGZyb20gbW9zdCBlbWFpbCBpbnRlcmZhY2VzLCBzaW5jZSB0aGF0IHVzdWFsbHkg bGVhdmVzIHRoZSBzdWJqZWN0IGxpbmUgaW4gdGhlIHJpZ2h0IGZvcm0uICBUaGUgcmVwbHkncyBh ZGRpdGlvbmFsICJSZToiIGlzIG9rLikNCg0KSWYgeW91IGRvIG5vdCB3aXNoIHlvdXIgcG9zdGlu ZyB0byB0aGUgbGlzdCB0byBnbyB0aHJvdWdoLCBzaW1wbHkgZGlzcmVnYXJkIHRoaXMgbWVzc2Fn ZS4gIFF1ZXN0aW9ucyB0byBpZXRmLWFjdGlvbkBpZXRmLm9yZy4NCg0K From matao.matao@huawei.com Sun Oct 15 20:49:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3B13336A for ; Sun, 15 Oct 2017 20:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 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_KAM_HTML_FONT_INVALID=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 K9aMUcS3bO79 for ; Sun, 15 Oct 2017 20:49:47 -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 458FB1270AE for ; Sun, 15 Oct 2017 20:49:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXU33321; Mon, 16 Oct 2017 03:49:44 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 04:49:43 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 16 Oct 2017 11:49:37 +0800 From: "Matao (D)" To: "brian.e.carpenter@gmail.com" CC: "ipv6@ietf.org" Subject: Re:Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: Re:Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AdNGMcjP+UNlN+rGQ5enEdCXcJgexw== Date: Mon, 16 Oct 2017 03:49:36 +0000 Message-ID: <23DD990E3E2E724E887EA303C763DAA54E1F7353@nkgeml514-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.162.208] Content-Type: multipart/alternative; boundary="_000_23DD990E3E2E724E887EA303C763DAA54E1F7353nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59E42C59.005B, 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: 6fe3ee629cbc14bff94fd83975fcb85b Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 04:16:09 -0000 --_000_23DD990E3E2E724E887EA303C763DAA54E1F7353nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 14 Oct. 2017 13:41, Brian E Carpenter > wrote: >> The fundamental scaling issue for RSVP was the number of session state i= tems per router, >> and your solution needs exactly the same number of session state items. >> So why will you succeed where RSVP failed? IMHO, the fundamental scaling issue for RSVP was not the number of session = state items, the real issue was the overhead of maintaining the session sta= te items. RSVP needs periodic signaling messages to refresh the session state. Actual= ly, the overhead of generating and handling the periodic refresh messages l= imits the number of session state. To the contrary, this solution needs no explicit signaling message, but app= lies the data packets to maintain the session state (seen in section 3.5.7)= . It adds no extra overhead to refresh states, which improves its scalabili= ty. Although this solution needs exactly the same number of session state items= , but the overhead of maintaining the same number of session state items is= much smaller than overhead of RSVP. So this solution scales to much more s= ession state items than RSVP. --_000_23DD990E3E2E724E887EA303C763DAA54E1F7353nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On 14 Oct. 2017 13:41, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:

>> The fundamental scaling issue for RSVP w=
as the number of session state items per router,
>> and your solution needs exactly the same=
 number of session state items.
>> So why will you succeed where RSVP faile=
d?

IMHO, the fundamental scaling issue for RSVP was not the num= ber of session state items, the real issue was the overhead of maintaining = the session state items.

RSVP needs periodic signaling messages to refresh the sessio= n state. Actually, the overhead of generating and handling the periodic ref= resh messages limits the number of session state.

To the contrary, this solution needs no explicit signaling m= essage, but applies the data packets to maintain the session state (seen in= section 3.5.7). It adds no extra overhead to refresh states, which improves its scalability.

Although this solution needs exactly the same number of sess= ion state items, but the overhead of maintaining the same number of session= state items is much smaller than overhead of RSVP. So this solution scales to much more session state items than RSV= P.

 

 

--_000_23DD990E3E2E724E887EA303C763DAA54E1F7353nkgeml514mbxchi_-- From nobody Mon Oct 16 05:36:50 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C31313219B; Mon, 16 Oct 2017 05:36:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-6man?= =?utf-8?q?-maxra-03=3A_=28with_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150815740850.32743.6552024740912046925.idtracker@ietfa.amsl.com> Date: Mon, 16 Oct 2017 05:36:48 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 12:36:48 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-6man-maxra-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just one quick question to double-check: Are the defaut values in RFC4861 still recommended or not? Maybe note this in the text to avoid any confusion! Also, as already noted in the sphepherd write-up, the abstract should mention the update. From nobody Mon Oct 16 07:05:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F767132F76 for ; Mon, 16 Oct 2017 07:05:24 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww-EJX6Nw_nS for ; Mon, 16 Oct 2017 07:05:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 557A0132F30 for ; Mon, 16 Oct 2017 07:05:23 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9GDF0vO032128; Mon, 16 Oct 2017 09:23:37 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2dmhh1xd0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Oct 2017 09:23:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9GDNZIE017355; Mon, 16 Oct 2017 09:23:35 -0400 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v9GDNSKT017211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Oct 2017 09:23:30 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi134.aldc.att.com (RSA Interceptor); Mon, 16 Oct 2017 13:23:18 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.103]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0361.001; Mon, 16 Oct 2017 09:23:18 -0400 From: "STARK, BARBARA H" To: Brian E Carpenter CC: 6man Subject: Re: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRIl1xmXDwRAECkiEQH7Zxa7f1qLmeshS Date: Mon, 16 Oct 2017 13:23:17 +0000 Message-ID: <025D5BD2-777E-4A8A-BCD0-A82C7149CE58@att.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> In-Reply-To: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-16_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710160189 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 14:05:24 -0000 > The IPv6 specs are very clear that an address is assigned to an interface= , > not to a node, but they don't say anywhere that non-loopback addresses ma= y > be assigned to the loopback interface. However, sometimes as a practical > matter, it's necessary to assign a routeable address (GUA or ULA) that > is not created via a specific IPv6 interface. Conventionally, that is > done by assigning it to the loopback interface. When crafting the language for WAA-7 in rfc7084 (If ... then [the CE router= ] MUST create a global IPv6 address(es) from its delegated prefix(es) and c= onfigure those on one of its internal virtual network interfaces...), sever= al router vendors explained to me they preferred this phrase "internal virt= ual network interface" over "loopback interface" because they didn't always= assign the address to the loopback interface and didn't want the requireme= nt to constrain the implementation. They said they sometimes use an interfa= ce associated with an internal switch. They said the more complex CE router= s could have a variety of internal interfaces suitable for this purpose.=20 Barbara > However, the only place I have found that defines 'loopback interface' fo= r > IPv6 is in the addressing architecture: 'a virtual interface (typically > called the "loopback interface") to an imaginary link that goes nowhere.' > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::= 1. >=20 > Do people agree with something like the following? >=20 > 'Note that other forms of unicast IPv6 address may be assigned to the > loopback interface, in cases where an address is assigned to the node > without being assigned to the interface to a specific link.' >=20 > This is after all common practice in various operating systems; we > just never documented it, as far as I know. >=20 > Regards > Brian Carpenter >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps-3A__www.ietf.org_mailman_listinfo_ipv6&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQic= vjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DTw4-hGqTflOaLUSMFh5CaOIeUpOoPzuLdwe1pZh= F1tY&s=3DYpenyjKvrrjtyVbBXgY6t7UxFL6uv69mIR4st4L6fWY&e=3D=20 > -------------------------------------------------------------------- From nobody Mon Oct 16 07:32:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730E13301C for ; Mon, 16 Oct 2017 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iagvKiwm_3Mv for ; Mon, 16 Oct 2017 07:32:34 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38151344E6 for ; Mon, 16 Oct 2017 07:32:30 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 62BB02D5065; Mon, 16 Oct 2017 14:32:29 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D3070200561629; Mon, 16 Oct 2017 16:32:27 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CFFCF0E0-5FF4-453E-AB00-11D0BFE09F28"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Loopback interface terminology issue Date: Mon, 16 Oct 2017 16:32:26 +0200 In-Reply-To: <025D5BD2-777E-4A8A-BCD0-A82C7149CE58@att.com> Cc: Brian E Carpenter , 6man WG To: Barbara H Stark References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <025D5BD2-777E-4A8A-BCD0-A82C7149CE58@att.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 14:32:36 -0000 --Apple-Mail=_CFFCF0E0-5FF4-453E-AB00-11D0BFE09F28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > When crafting the language for WAA-7 in rfc7084 (If ... then [the CE = router] MUST create a global IPv6 address(es) from its delegated = prefix(es) and configure those on one of its internal virtual network = interfaces...), several router vendors explained to me they preferred = this phrase "internal virtual network interface" over "loopback = interface" because they didn't always assign the address to the loopback = interface and didn't want the requirement to constrain the = implementation. They said they sometimes use an interface associated = with an internal switch. They said the more complex CE routers could = have a variety of internal interfaces suitable for this purpose. It was to avoid confusion with how typical UNIX systems use a loopback = interface. On most router implementations a loopback interface does not = have the loopback address assigned to them / it. Cheers, Ole --Apple-Mail=_CFFCF0E0-5FF4-453E-AB00-11D0BFE09F28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnkwvsACgkQvtpYqJhC 33a7dhAAxkdkdZRq1+cWM8h6ubGj6dLptkywZj7+oLnC0bauIb89aD1r33DK7S0i /xJ8ay30Y8CmnInBl8U6OQ4xdMaHtaCb8/FdefLCOu4+NAWhUlV9Ch42DW4NkChc oRT9trY05rF9jL2ofpZpi9oN39rImSMo6XlEtsj84jsbY5mEp1GngfrH0rhDHdd8 4Cgj3V4F6syg0Mni8TGRgVSwTtRcIAJ0e1QF9IdPF4wnQKHnTT4zIp91TNqv1A5Q 4C9zqNO7VTSHwA+iRtSTn/CCjQY8hxQgnWdzJJa4szHKdN/NDUI26onPST1PIRBw 6qipYWTiimWOH3uitGxD3674cppDNjOYpyue6d3gTenHbHXWRZp9FqJBUwYE/9QM cqMaiqe2ldsp3XtjE0d2Az/cX36Bxhf+IHUVFS/A2/iFEeJsjNasFZSdPOS38QFu tiU+gOyq6Eqt2PfZEvtvepcnZg8/s6O3g7wfTV7TpPtrXXK2YYpEEt6JUomCr8JL XcbhIYzTFYGZzDwpVBymtg4+Tz+yffkdRHDBOFu2PCG5zwfRo/AK+95enZr2+Lo5 E1ApWrxoYKYPcx79hfpeJwg2rueeNwSad/vYPuOAN3KmGqc6gLO5v+Is0XFl8DuY s29I950s20jg1WI9cUQHwj6hQ16jw1aWjX77CghTu7OeC7S4I3s= =jTFV -----END PGP SIGNATURE----- --Apple-Mail=_CFFCF0E0-5FF4-453E-AB00-11D0BFE09F28-- From nobody Mon Oct 16 08:22:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32A813303F for ; Mon, 16 Oct 2017 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR_JO1jvsIvU for ; Mon, 16 Oct 2017 08:22:39 -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 A5B1613234B for ; Mon, 16 Oct 2017 08:22:39 -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 v9GFMcnq006128; Mon, 16 Oct 2017 08:22:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9GFMbbD006108 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 16 Oct 2017 08:22:37 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-08.nw.nos.boeing.com (137.136.238.222) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Oct 2017 08:22:37 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 16 Oct 2017 08:22:37 -0700 From: "Templin, Fred L" To: Brian E Carpenter , 6man Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRIlzPxn1iJZL+kqA+Ph9pp2qTaLmmu/Q Date: Mon, 16 Oct 2017 15:22:36 +0000 Message-ID: References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> In-Reply-To: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 15:22:41 -0000 Hi Brian, 'draft-templin-v6ops-pdhost' discusses the assignment of IPv6 addresses to internal virtual interfaces such as loopbacks. Also about assignment of delegated prefixes to the virtual interface. Thanks - Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Friday, October 13, 2017 6:12 PM > To: 6man > Subject: Loopback interface terminology issue >=20 > Hi, >=20 > This come rather late in the day, but it results from some wordsmithing > difficulties in a draft in another WG: >=20 > The IPv6 specs are very clear that an address is assigned to an interface= , > not to a node, but they don't say anywhere that non-loopback addresses ma= y > be assigned to the loopback interface. However, sometimes as a practical > matter, it's necessary to assign a routeable address (GUA or ULA) that > is not created via a specific IPv6 interface. Conventionally, that is > done by assigning it to the loopback interface. >=20 > However, the only place I have found that defines 'loopback interface' fo= r > IPv6 is in the addressing architecture: 'a virtual interface (typically > called the "loopback interface") to an imaginary link that goes nowhere.' > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::= 1. >=20 > Do people agree with something like the following? >=20 > 'Note that other forms of unicast IPv6 address may be assigned to the > loopback interface, in cases where an address is assigned to the node > without being assigned to the interface to a specific link.' >=20 > This is after all common practice in various operating systems; we > just never documented it, as far as I know. >=20 > Regards > Brian Carpenter >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Oct 16 10:00:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9985A133208 for ; Mon, 16 Oct 2017 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7JUxVuO3rgT for ; Mon, 16 Oct 2017 10:00:13 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE4A133061 for ; Mon, 16 Oct 2017 10:00:13 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n61so33064902qte.10 for ; Mon, 16 Oct 2017 10:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=84qbRVYWifyOYKjILNQNPdi8aH60SRj7RaJzetBeLVo=; b=Hb9ZjE4e4//ZOIYL5o6JCyDIl3qSPLk52QG6j4Xj8R1vToNnjxLSByGVj3RVry2rsm Nx7yTVhfelin40snhZzVmvfACkb0qpCChA/oBGreY4Uu9AgRMQJWZENKAx17E04R7CBL 4oGGD5tQgPPjFtHR8hhbmkr40xwDPMknRh9EOsRLgFDTpZx84881UBZylk3pdyQsqstU jLjQib1sNVZtcvM2kibdv+51crqea6cR88S0Z5diE0JKVNO5yHkgbCjea3ZP6MuhBkuu K+wOVb4pLuKWdWU2+9Y+H55COByXtfNi9XDMzLKRR79BusGM8bIeInpDm5R3qhI6p4+r TvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=84qbRVYWifyOYKjILNQNPdi8aH60SRj7RaJzetBeLVo=; b=X5JvZZTFp1QIuWRthb+k2b6Dg1oI6MHgmJCd1uuoI4O171Ot7DE3Y7tFa+9sXiM2SQ rqddMMLspNr7qiuYhRKzET4QJO1HDnPNhlsIdLCYnmHBh6gPe+vpCWWHSzoFNfNDI1g/ aY3W1H0aSeFpu5hWNQcEikbAYyXb6JccUxSGim662YhYcmSDFGy2FwxzNVcK2yjd0wpa MNXN92fPDiW2y2EwsR5Icw3HChH9kSs9pRIKAmkNScMUSnOmfQpENTko4DmYtskj8A21 Sb3E/7S4cmM2JS4TijStXIBO7Z6ZzZYHhM6Xn4WyOgerFETvwA8AT4O12g43MH9CqTZU h4Lg== X-Gm-Message-State: AMCzsaViKi/ymHfhH3kgvyyt0d92vzZVFVuzvdaF4EYwPz2hJD036n5w uLbYn489xEVOWQ0fadxXozYx4l+c7InSjDueyaA= X-Google-Smtp-Source: AOwi7QBhuRfaf5gPj9rOsrQxfN55EnkjcyDcwaAOkSTX2sfGSJ2+HZaGBtvurGkKa/2/fV3Qy9pXi3F87xdfdv/OTJs= X-Received: by 10.237.42.27 with SMTP id c27mr16044965qtd.282.1508173212224; Mon, 16 Oct 2017 10:00:12 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.137 with HTTP; Mon, 16 Oct 2017 10:00:11 -0700 (PDT) In-Reply-To: <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Oct 2017 10:00:11 -0700 X-Google-Sender-Auth: pWIiUH9ERm08QEnhDb_8BOTTstg Message-ID: Subject: Re: Loopback interface terminology issue To: Toerless Eckert Cc: Mark Andrews , 6man Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 17:00:16 -0000 At Sun, 15 Oct 2017 04:41:29 +0200, Toerless Eckert wrote: > > > IMHO: A loopback interface is an attachment to a node internal > > > "loopback link". If other addresses beside "loopback addresses" are > > > assigned to such a link, then this implies that the interface > > > is configured to forward non-self-destined packets. > > > > No. Whether such addresses are forwarded by default or not depends on > > the weak/strong host model in use. > > Not really. If the transport stack (a) logically attaches to the loopback > interface then the loopback source address is the source address corresponding > to the interface. The difference between strong and weak model would only > come in if a transport socket (b) binds to a physical interface and tries > to send/receive packets for the loopback address. I don't understand what this means, but in any case I agree with Mark that IMO this is more about the weak/strong host model than forwarding/non-forwarding. > I think the stacks i know logically do (a), althogh i am not sure how > cleanly it's implemented. If its 100% clean then the TTL of the sent packet > should be decremented by 1 before output on the physcial interface. Not > sure which stacks this is done in. In BSD implementations it's perfectly fine to assign non-loopback IPv6 addresses to a loopback interface (it's typically 'lo0'). Since BSDs use the weak host model, when for whatever reason that non-loopback address is chosen as the source address for an outgoing packet, there's no problem in sending the packet out to any interface (either loopback or other 'physical' interface) with that address. It doesn't have to enable the 'ip6.forwarding' system switch to do so, and it doesn't decrement the hop limit (btw there's no "TTL" in the IPv6 layer) when sending out the packet. -- JINMEI, Tatuya From nobody Mon Oct 16 11:14:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B258134519 for ; Mon, 16 Oct 2017 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEKXped5ImK2 for ; Mon, 16 Oct 2017 11:14:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36E413318B for ; Mon, 16 Oct 2017 11:14:46 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D3D4358C4F7; Mon, 16 Oct 2017 20:14:42 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B649EB0CECB; Mon, 16 Oct 2017 20:14:42 +0200 (CEST) Date: Mon, 16 Oct 2017 20:14:42 +0200 From: Toerless Eckert To: ???????????? Cc: Mark Andrews , 6man Subject: Re: Loopback interface terminology issue Message-ID: <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:14:48 -0000 On Mon, Oct 16, 2017 at 10:00:11AM -0700, ???????????? wrote: > > Not really. If the transport stack (a) logically attaches to the loopback > > interface then the loopback source address is the source address corresponding > > to the interface. The difference between strong and weak model would only > > come in if a transport socket (b) binds to a physical interface and tries > > to send/receive packets for the loopback address. > > I don't understand what this means, but in any case I agree with Mark > that IMO this is more about the weak/strong host model than > forwarding/non-forwarding. ---etherB--- host --etherA-- rtr ---etherB--- | host/rtr | Think of a host with an etherA connecting to a router that also has etherB, etherC. Now we just integrate this router into the host and etherthernetA becomes an internal interface, but the apps can still use this interface, and so it is permissible for both strong and weak host models to use the IP address on etherA, whatever exernal ethernetB/ethernetC the packets are sent/received through. The main difference between an internal ethernet and loopback in this modelling is that when you send into a loopback interface, it does not need to run ND to find the link-local address of the router interface and forward the packet to it, but instead the packet is immediately processed by the router forwarding code. > In BSD implementations it's perfectly fine to assign non-loopback IPv6 > addresses to a loopback interface (it's typically 'lo0'). Since BSDs > use the weak host model, when for whatever reason that non-loopback > address is chosen as the source address for an outgoing packet, > there's no problem in sending the packet out to any interface (either > loopback or other 'physical' interface) with that address. It doesn't > have to enable the 'ip6.forwarding' system switch to do so, and it > doesn't decrement the hop limit (btw there's no "TTL" in the IPv6 > layer) when sending out the packet. Sure, i just said it does not depend on it. If you already need to participate in a routing protocol (for the reachability of the address on the loopback interface) i always find it easier to model behavior as a simple host stack and a co-ocated router. In IPv6 thats a lot more attractive IMHO because its a lot more natural not to have those unnecessary global reachable external interface addresses but only link-locals. Anyhow: The question is what would be necessary or beneficial to put into an IPv6 arch update RFC to allow all the common practice uses of it. Cheers Toerless From nobody Mon Oct 16 11:49:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E91134555 for ; Mon, 16 Oct 2017 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieUWlgtN50cj for ; Mon, 16 Oct 2017 11:49:26 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51ABD13454F for ; Mon, 16 Oct 2017 11:49:25 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id v41so23595740qtv.12 for ; Mon, 16 Oct 2017 11:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3kWtQtLVjTIWSxTnpQp1AlscU1ZnKR3Qqxpz0j5LK2I=; b=afZl3J5k7HSQiw9H+2/niua1drtuShmrkZyR/hMe4o+mh4D0tDtXqeNY9UmjcZ/3qk nKSCOrh+X3HwxUakbGIR89QrZ4C7ZjkRJWBNXfb8EL2WCaPPjLYdv2lqJJ1mPAqWvdGW FCfORElGP/rOdgUa1hvlkI9uNtQPWnq4Nt/cx3fN4s2tfX+ldq4DfGIuCyr1XmY3l8LO MWnRvnzCASmmOR0LZ4nrjUqzEzZN3amNFjV4oZ3yUQWXVJn59pTecQ7Z91Z8KN2NQEZv rr1sLxwDoTkdm7uCZ1stmj5nRgsyumUpKNsxDUoZWNC/LmRe0SvnFBR0X3+FggZfDkkE zPFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3kWtQtLVjTIWSxTnpQp1AlscU1ZnKR3Qqxpz0j5LK2I=; b=OXIY+fdfwATRRc1Rsi4WEm9gjVSYVuaGQi3rj2FrK7+oS3emFgTqU9kP3y0iA2Rfi6 jfZ17Mxq9pqoZGlJlJN0RdQIawiIkz+/KyDc+nZ6ObojOAQqa6ewu1U8k6l1WBf3euBg TfPTiA/RwMsKLSkOsXWv+ALfDfKh05NWu56dy5kbW/xvydz4zOv/A+RvVNbiI2SkORly sfNcHwiQWaPlEEWVJ+7OXrVOcSe/rz/eMYkI8RtpejbAT39niKShcQ/ZHkRZeTdyz4Re b6kmidofi2qvXXH1nuUeg3pcF2c6ne+krmvFKInW02v4gJV3NVkC0a18CpfzvXBcMyGe hVfQ== X-Gm-Message-State: AMCzsaX7VPneUoLTN49spJC0CQ3CSZegcnZL6iXa5hvFWeYYSh96h0hU BNV/dmoJf86mM/s0K6j/IgGdiOyzvwvVjAtqw6yIb/jD X-Google-Smtp-Source: AOwi7QCI2WYoL21XXmtWRhbHATvdqDzsbuwd2/D0dNlBiAnRFtxPfkMAhuXF9chQ2qL2B8hTlXBLgqmNgmYuQoD0zqo= X-Received: by 10.237.42.27 with SMTP id c27mr16583808qtd.282.1508179764037; Mon, 16 Oct 2017 11:49:24 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.137 with HTTP; Mon, 16 Oct 2017 11:49:23 -0700 (PDT) In-Reply-To: <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Oct 2017 11:49:23 -0700 X-Google-Sender-Auth: czZWhPdafKd86C_QG17jTHIfUn0 Message-ID: Subject: Re: Loopback interface terminology issue To: Toerless Eckert Cc: 6man , Mark Andrews Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 18:49:27 -0000 At Mon, 16 Oct 2017 20:14:42 +0200, Toerless Eckert wrote: > > I don't understand what this means, but in any case I agree with Mark > > that IMO this is more about the weak/strong host model than > > forwarding/non-forwarding. > > ---etherB--- > host --etherA-- rtr > ---etherB--- > | host/rtr | > > Think of a host with an etherA connecting to a router that also has > etherB, etherC. Now we just integrate this router into the host and etherthernetA > becomes an internal interface, but the apps can still use this interface, > and so it is permissible for both strong and weak host models to use the IP > address on etherA, whatever exernal ethernetB/ethernetC the packets are > sent/received through. > > The main difference between an internal ethernet and loopback in this modelling > is that when you send into a loopback interface, it does not need to run ND to > find the link-local address of the router interface and forward the packet to it, > but instead the packet is immediately processed by the router forwarding code. Okay, I think I now understand what you meant. Such a model seems to be quite a stretch convoluted or even artificial to me, but I wouldn't necessarily deny possible existence of such implementations. But in any event that seems to me quite a stretch from the situation Brian originally raised. And, for these reasons, I personally wouldn't support saying something in the addressing architecture that requires a specific model of integrated host-router architecture. More specifically I disagree with adding to the addrarch doc: If other addresses beside "loopback addresses" are assigned to such a link, then the interface needs to be configured to forward non-self-destined packets originated from the loopback interface (see rfc8200, section 2). If it also notes that it's for a host that adopts the strong host model or the node adopting the hybrid architecture you mentioned above, I might live with it, although I personally think it's too much for the basic architecture document. -- JINMEI, Tatuya From nobody Mon Oct 16 12:49:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FAE132939 for ; Mon, 16 Oct 2017 12:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ai-H1GFlS-4 for ; Mon, 16 Oct 2017 12:49:11 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21479132331 for ; Mon, 16 Oct 2017 12:49:10 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id n89so8925783pfk.11 for ; Mon, 16 Oct 2017 12:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AHXYDd4FtfydnyjVopi7igzWZ9Wou5bOQO9HKP0zLvU=; b=QvLSn2c3sL/PAqn0/f5l+xoiLSkIj8yHmb3nCRPydlmuBppLzx9e2FuwTk/Q3Hds7Y 6155qefTki9LuipJiNeAUKj5MlONhjIT7IYg/58WaDsyi/EKsfJgvv0IhIyyrP3czVWi KE+O3oWZSQot7wbQFrT2pmPHcLac57/KKZUJ1pRaeISqYlbTdsMcNHTr26nwPRtrHWz0 KmxqnXVHuMmOEHr5gDhY5QLdZaS7YK7DRUtn/fEsN910GihSm++AWH+DGYZYZNVZXXTe +9ir4f5jTz96Na3zZoI2t0sLkgMC+ZvgDmDH5s2bowj6cbfgYVCqITFhVW3WZ2c1XqHh N8Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AHXYDd4FtfydnyjVopi7igzWZ9Wou5bOQO9HKP0zLvU=; b=p38ff4EDo65qZICcWtIpclonXZ20JgQcCsNUHyoM/GchD151PeiJlmh/By3q+egx5b z8nyPTGrllm/XS4WX52z48d9kCDgmpgpXBEnkZOgFg7P6BbIgQYR7AEa/+WcCQB88J7X +rlUIknBmk6egIjoiiApi9ZauStee6JzcK/WNUXE3aTEZeRDS+BgnWOVUVKERYmNcz2U n9Tcn6Ui0ebYJxC1ZyUUNMF0/M4UK95hPhz42/yT+4hDoYtQFfMog90gS2kDRQgzjSjp glqxNcmVyDQ83RSLhPvs9KMHgvo9EcK1kjbB/TwUh0ueUIoXlFb4TgupxQObdgex6Mzh 97pA== X-Gm-Message-State: AMCzsaVuAGPBAsxGu09DkV90qJ8+38vO8rdnbwc2riUfkQikOACvSyE1 0GZkVwLbJEjrYvp98FqDWiwcMg== X-Google-Smtp-Source: AOwi7QAA6whvoHgEXlVU/aGW0A2ftF8dtii9gxMFgdoLcBPmH51vXVtKOBHX3/hqroPXoEF071JAsQ== X-Received: by 10.84.197.69 with SMTP id m63mr9771933pld.226.1508183350144; Mon, 16 Oct 2017 12:49:10 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m185sm15237337pfm.181.2017.10.16.12.49.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 12:49:09 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: "Matao (D)" Cc: "ipv6@ietf.org" References: <23DD990E3E2E724E887EA303C763DAA54E1F7353@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <74d37807-e2ed-599f-7cb7-1216b38109cd@gmail.com> Date: Tue, 17 Oct 2017 08:49:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <23DD990E3E2E724E887EA303C763DAA54E1F7353@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 19:49:13 -0000 On 16/10/2017 16:49, Matao (D) wrote: > On 14 Oct. 2017 13:41, Brian E Carpenter > wrote: > >>> The fundamental scaling issue for RSVP was the number of session state items per router, > >>> and your solution needs exactly the same number of session state items. > >>> So why will you succeed where RSVP failed? > IMHO, the fundamental scaling issue for RSVP was not the number of session state items, the real issue was the overhead of maintaining the session state items. > RSVP needs periodic signaling messages to refresh the session state. Actually, the overhead of generating and handling the periodic refresh messages limits the number of session state. > To the contrary, this solution needs no explicit signaling message, but applies the data packets to maintain the session state (seen in section 3.5.7). It adds no extra overhead to refresh states, which improves its scalability. > Although this solution needs exactly the same number of session state items, but the overhead of maintaining the same number of session state items is much smaller than overhead of RSVP. So this solution scales to much more session state items than RSVP. Yes, I agree that there are no additional messages, but of course there is still a more complicated state lookup and some processing for each packet, whereas for diffserv there is just a 6-bit switch to select a queue. I recommend taking this discussion to the transport area in the TSVWG. That is where we find the IETF expertise on this topic. Regards Brian From nobody Mon Oct 16 13:42:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68583133057 for ; Mon, 16 Oct 2017 13:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqqazzWXq6m9 for ; Mon, 16 Oct 2017 13:42:26 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 AD06A124F57 for ; Mon, 16 Oct 2017 13:42:26 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id n61so34481509qte.10 for ; Mon, 16 Oct 2017 13:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zojUTG68/CfeKAxRauT1qN8dKCR0Uolh9uNTBRGsnxw=; b=IQsREUISgtZsNUhYkBZygHGH/bj7uhdZanisj9xwjJBVQIxBtPSPtMXvW8CnsVZsUh UetvHOu4nfeR1ONqDm9KVZyUNTIAUVSA+Nq6c7eikx1X9sAhqD6Go/NUjWQKpPX2alZ2 FT9uIvDv/7s2qMPYcZ52kOAvNTeWZ0sjQIiF++UYNTnld9Rk7Q3KAQJNXYHGZG84IQyZ 0DFCVb3aRQ0Qz+r+H0MvnkS3W4GPQCOMuHUsyJhI0TbBQAOBN6XLsA0OqKn4mrIPiFfh AGBJLsmWD8eWBSNxX+1VSXeBtTK7w7GJhhMkGsjpAWm7xVDcIzeHjrjJnU9Dls7WUilB rt/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zojUTG68/CfeKAxRauT1qN8dKCR0Uolh9uNTBRGsnxw=; b=jzQ3I/LXUdlFmK/Z1tQdLfrtWBhWiXAuMjw7ndr1GvnhkOargYvDEIeoCxMefZKjqi T5xD2ruMCK9FyAtGKGUORzYQlSgR5XtACw8bjYj3aT/335q/NJfbBclDs/gfioN2cn2B W5Cy8D3C/EZseqHpvACWHu0pJARoh8q8t9q19D4hPMN401E61yR/OaSD3DVY1wW35fhV wEuJs3zQR4zaQacvugffKC09CeobbANXxHp5Z19DyzMi+9ib6r5Y7I5bHiSqUY1MAwVE ZrREDKAbp/Lg4ohHtRPudb9eQ3FcpUsHiXfKqFsWFJ95gBdQGrJWchsvIU5HM+xWubez WMRA== X-Gm-Message-State: AMCzsaUWtU/3boghnkGHYUtyF/8MEpHU+d1fEXMtBsDfv9llLm0XxtqY C+mznGmXvUM4eEb16HkwYKe1DCNehfMQPc2WcJfG4w== X-Google-Smtp-Source: AOwi7QDqnhBXo/ldhK6p68TvxgMws8AjWgUgbcbxr/9F4JUot6Zyi5tQH4wXOvdnPeS8GGg85gs3IgdYZcqirUiUCm8= X-Received: by 10.237.49.46 with SMTP id 43mr16784476qtg.27.1508186545673; Mon, 16 Oct 2017 13:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Mon, 16 Oct 2017 13:42:25 -0700 (PDT) In-Reply-To: <74d37807-e2ed-599f-7cb7-1216b38109cd@gmail.com> References: <23DD990E3E2E724E887EA303C763DAA54E1F7353@nkgeml514-mbx.china.huawei.com> <74d37807-e2ed-599f-7cb7-1216b38109cd@gmail.com> From: Tom Herbert Date: Mon, 16 Oct 2017 13:42:25 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Brian E Carpenter Cc: "Matao (D)" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 20:42:28 -0000 On Mon, Oct 16, 2017 at 12:49 PM, Brian E Carpenter wrote: > On 16/10/2017 16:49, Matao (D) wrote: >> On 14 Oct. 2017 13:41, Brian E Carpenter > wrote: >> >>>> The fundamental scaling issue for RSVP was the number of session state= items per router, >> >>>> and your solution needs exactly the same number of session state items= . >> >>>> So why will you succeed where RSVP failed? >> IMHO, the fundamental scaling issue for RSVP was not the number of sessi= on state items, the real issue was the overhead of maintaining the session = state items. >> RSVP needs periodic signaling messages to refresh the session state. Act= ually, the overhead of generating and handling the periodic refresh message= s limits the number of session state. >> To the contrary, this solution needs no explicit signaling message, but = applies the data packets to maintain the session state (seen in section 3.5= .7). It adds no extra overhead to refresh states, which improves its scalab= ility. >> Although this solution needs exactly the same number of session state it= ems, but the overhead of maintaining the same number of session state items= is much smaller than overhead of RSVP. So this solution scales to much mor= e session state items than RSVP. > > Yes, I agree that there are no additional messages, but of course there i= s still > a more complicated state lookup and some processing for each packet, wher= eas for > diffserv there is just a 6-bit switch to select a queue. > Hi Brian, I think the intent here is to allow network resource allocation at flow granularity. This sort of thing is already being done on some large scale deployments (Google's B4 for instance), but most those seem to use out of band signaling to do resource scheduling for anything that goes beyond basic QoS. One advantage of using HBH options is they can be written so that should enable some nice features to report network conditions, queue occupancy to implement QCN, etc. I agree that this is new complexity for intermediate nodes, but at least it can properly use flow label to eliminate the need to parse in transport layer. Also, doing this in EH is far better than putting network layer information into TCP options (like proposed in draft-flinck-mobile-throughput-guidance) or having intermediate devices parse UDP payloads (like PLUS proposed). Tom > I recommend taking this discussion to the transport area in the TSVWG. Th= at is > where we find the IETF expertise on this topic. > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Oct 16 14:33:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1DD1331DC for ; Mon, 16 Oct 2017 14:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oknvRy4jKSjn for ; Mon, 16 Oct 2017 14:33:29 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD9713247A for ; Mon, 16 Oct 2017 14:33:29 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id j3so7853895pga.1 for ; Mon, 16 Oct 2017 14:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OlPOezqqf5U/UYPo+kqVPQgy2JW1LM+0AcXILQoIleI=; b=Oto64UcuKf3/Ydj5EEsvlmhS6Q95BRmPzTjnvvHA8J4rr3V/NCCLtlUYI3bB9ZCJ5/ o+bvZ8DYGQHYm3mhTUZEKmTq8mx3IHLp4LpYJtl+EWk19qm20EV58bs2g3JKf48l49ql lwOuRQrIbvrGgSwub+h86DEmvnZcq0tuP/Y87+ItpH0yswlVc+vl3S/jkQAOS6r/byh4 kg5IIMZvM8npQCIH2QLugtswBUOO4ukG2zXZLHWjJSyCbCb05xH2uUFQ0G1NpIMOeHHB w+NhZUCr11G1Ks2cUQfyyPgbG3gfwCJEumGGWwQJfVMRXtNqeBUuxLNCdXoUtld1M41W BJhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OlPOezqqf5U/UYPo+kqVPQgy2JW1LM+0AcXILQoIleI=; b=tYpGvQljkm0URn0c3OqkY3jXva8b/ALFhckHjzk6OuMLM+pVls609l/EcerfYXsjVR 44+I5QGY32y+SfOR4FCgFn3xNYaWGT7nkAmtH0krXUMOeSJjuD3spAt7jKICPKIfqpXr g9gdn0f7fV3BcdPKcSeGf6+6VDboxZ8tlMM+kkElrkmUy0wAxiy1yZvpmPoOUgOXA2kz LTTuihGMwopI+c9/8r+dgtD9LvgNuJbn5bD9LrIN+dNFw8Pdnla7QWSZ3jmSzP0KSOS5 +XHf1Gve9d8EmTlbI2ZUvIxYKN6rGSWljHvODdXS/+OtY4sFyzQI6nkdcFOj87yrOOUk dZww== X-Gm-Message-State: AMCzsaVlvDdQdlTAljFOoI5TG3kQOtJ6g5RIgae2Z1e8ORNDGx1KNssj OHdswpGq0lZTWtFJu2aO8Ek7OA== X-Google-Smtp-Source: AOwi7QA0LkwaKWXWels8SICQduTN6q2jBvEpS6/RWsx4HgWzTgLkpQIf0TVvKYRUBiIctw5RZ0DTOw== X-Received: by 10.98.197.69 with SMTP id j66mr9720816pfg.135.1508189608243; Mon, 16 Oct 2017 14:33:28 -0700 (PDT) Received: from [130.216.38.84] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.84]) by smtp.gmail.com with ESMTPSA id 74sm18964549pft.184.2017.10.16.14.33.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 14:33:27 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Tom Herbert Cc: "Matao (D)" , "ipv6@ietf.org" References: <23DD990E3E2E724E887EA303C763DAA54E1F7353@nkgeml514-mbx.china.huawei.com> <74d37807-e2ed-599f-7cb7-1216b38109cd@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 17 Oct 2017 10:33:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 21:33:31 -0000 On 17/10/2017 09:42, Tom Herbert wrote: > On Mon, Oct 16, 2017 at 12:49 PM, Brian E Carpenter > wrote: >> On 16/10/2017 16:49, Matao (D) wrote: >>> On 14 Oct. 2017 13:41, Brian E Carpenter > wrote: >>> >>>>> The fundamental scaling issue for RSVP was the number of session state items per router, >>> >>>>> and your solution needs exactly the same number of session state items. >>> >>>>> So why will you succeed where RSVP failed? >>> IMHO, the fundamental scaling issue for RSVP was not the number of session state items, the real issue was the overhead of maintaining the session state items. >>> RSVP needs periodic signaling messages to refresh the session state. Actually, the overhead of generating and handling the periodic refresh messages limits the number of session state. >>> To the contrary, this solution needs no explicit signaling message, but applies the data packets to maintain the session state (seen in section 3.5.7). It adds no extra overhead to refresh states, which improves its scalability. >>> Although this solution needs exactly the same number of session state items, but the overhead of maintaining the same number of session state items is much smaller than overhead of RSVP. So this solution scales to much more session state items than RSVP. >> >> Yes, I agree that there are no additional messages, but of course there is still >> a more complicated state lookup and some processing for each packet, whereas for >> diffserv there is just a 6-bit switch to select a queue. >> > > Hi Brian, > > I think the intent here is to allow network resource allocation at > flow granularity. Yes, of course. But whether that is practical is not a 6man issue; 6man of course has a word to say on defining new extension headers and options, but the main discussion is definitely in the Transport area (IMNSHO). Brian > This sort of thing is already being done on some > large scale deployments (Google's B4 for instance), but most those > seem to use out of band signaling to do resource scheduling for > anything that goes beyond basic QoS. One advantage of using HBH > options is they can be written so that should enable some nice > features to report network conditions, queue occupancy to implement > QCN, etc. > > I agree that this is new complexity for intermediate nodes, but at > least it can properly use flow label to eliminate the need to parse in > transport layer. Also, doing this in EH is far better than putting > network layer information into TCP options (like proposed in > draft-flinck-mobile-throughput-guidance) or having intermediate > devices parse UDP payloads (like PLUS proposed). > > Tom > >> I recommend taking this discussion to the transport area in the TSVWG. That is >> where we find the IETF expertise on this topic. >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Mon Oct 16 15:35:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9084E13458D for ; Mon, 16 Oct 2017 15:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqBFf2ZyOo9U for ; Mon, 16 Oct 2017 15:35:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB11134589 for ; Mon, 16 Oct 2017 15:35:42 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F20CA58C501; Tue, 17 Oct 2017 00:35:37 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D6902B0CEBB; Tue, 17 Oct 2017 00:35:37 +0200 (CEST) Date: Tue, 17 Oct 2017 00:35:37 +0200 From: Toerless Eckert To: "STARK, BARBARA H" Cc: Brian E Carpenter , 6man Subject: Re: Loopback interface terminology issue Message-ID: <20171016223537.GA31973@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <025D5BD2-777E-4A8A-BCD0-A82C7149CE58@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025D5BD2-777E-4A8A-BCD0-A82C7149CE58@att.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:35:45 -0000 Interesting, thanks Barbara. I wonder if other folks would like to have a clearer architectural terminology for "loopback interface" or "internal interface". Or what a better term for "physical" interface is today (in the face of virtual nodes). And see a chance to get such improved terminology into IPv6 arch updates. E.g.: what is an "internal virtual interface" ? Specifically in the face of "use an interface associated with an internal switch." To me an internal interface is simply one that is not associated with a link connecting to other nodes and is still up and running. I can use linux bridge interface to build an internal link in the same way i can use a loopback inerface, but as soon as i would connect the bridge group to other nodes, it would IMHO become an external link (from the perspective of describing TCP/IP node behavior/terminology). In your RFCs example case i think one does not really care if the link is virtual or internal. I think the requirement is really only: The CE needs a global address reachable from SP link even if all other external links are down. However you get that implemented. And if the CE itself consists of multiple (virtualized) TCP/IP nodes, good for your, you've got even more options. Cheers Toerless On Mon, Oct 16, 2017 at 01:23:17PM +0000, STARK, BARBARA H wrote: > > > The IPv6 specs are very clear that an address is assigned to an interface, > > not to a node, but they don't say anywhere that non-loopback addresses may > > be assigned to the loopback interface. However, sometimes as a practical > > matter, it's necessary to assign a routeable address (GUA or ULA) that > > is not created via a specific IPv6 interface. Conventionally, that is > > done by assigning it to the loopback interface. > > When crafting the language for WAA-7 in rfc7084 (If ... then [the CE router] MUST create a global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces...), several router vendors explained to me they preferred this phrase "internal virtual network interface" over "loopback interface" because they didn't always assign the address to the loopback interface and didn't want the requirement to constrain the implementation. They said they sometimes use an interface associated with an internal switch. They said the more complex CE routers could have a variety of internal interfaces suitable for this purpose. > Barbara > > > However, the only place I have found that defines 'loopback interface' for > > IPv6 is in the addressing architecture: 'a virtual interface (typically > > called the "loopback interface") to an imaginary link that goes nowhere.' > > (RFC 4291, section 2.5.3). The text only mentions the loopback address ::1. > > > > Do people agree with something like the following? > > > > 'Note that other forms of unicast IPv6 address may be assigned to the > > loopback interface, in cases where an address is assigned to the node > > without being assigned to the interface to a specific link.' > > > > This is after all common practice in various operating systems; we > > just never documented it, as far as I know. > > > > Regards > > Brian Carpenter > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Tw4-hGqTflOaLUSMFh5CaOIeUpOoPzuLdwe1pZhF1tY&s=YpenyjKvrrjtyVbBXgY6t7UxFL6uv69mIR4st4L6fWY&e= > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Oct 16 15:45:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEA7132055 for ; Mon, 16 Oct 2017 15:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IXRGveqYMcY for ; Mon, 16 Oct 2017 15:45:24 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 950F4132403 for ; Mon, 16 Oct 2017 15:45:24 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id d28so16876647pfe.2 for ; Mon, 16 Oct 2017 15:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GyoSQiHGL141JPS+tZXHj3fNbWxaJLsw+bK5zjPu2FA=; b=QTK8JnPnRV9UAXdOI7qkGXzlHRV/BXPX81MqcAVa+rNHLRarAbTnddQnk+oeUEw9W3 Nm0Ne6EHkFQjHTaA2kRUo89lskYm20yGKHFNU4XpluudcNczSIK2Vt7CB069zzfquzx/ mFeevQy1cyQKRyIxDN7f0h0vOvadZdIsXOJ7yleqokdr5VT1nTgaKcvV6hpXLz2o2KZv ETDT5EshHnxrQ13fzuJtGBkiZMAeFQTNW5eeyo+Y8Vh3btQpUpKPniO45qHY9uLhR/KD S6lILyQnyTcBKjtKd3/4pm0+Zb4nCjArLSmnPBfFmvbmthwusm/ThEv1+FhHaLi3UaNV 8M0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GyoSQiHGL141JPS+tZXHj3fNbWxaJLsw+bK5zjPu2FA=; b=P2Keiqzu7cfa/ZfrV8m571Fxao0KxfeSV0F0Jnkr0nSM+2hMudC+NpMo4GdOr+i2+x HeGilH7E3m4oM174AhVkPAQGQ/PSUHQBS2YoBMX5ARXIRccJrYCrsVEtAR0XRfrxPaJ0 sBx+WLBPAb5TmP+qkQzDYUa/64+y0L/nIf49GDvJNtvkybtyWoJ+vanZlRpOUmPNkb8E vDFXQiG4Q0OFZa1Kj/1wFJ8R8+vEhcg/ZOGg+59ju8Rx7czQzqpyoLc5yowGePzMzXon Ozmu1sYJFbwDmon/+R8xfGE63P1zh8R74B7/sEIJ4Rv26uCKpsHzFRAJVVeKPajZmbPy gf8w== X-Gm-Message-State: AMCzsaXAz62TsZc2jrPjXftYZ5gpgL/J139k2sqUUzeIFHl3CLZjTmKM WHYXjkURYSN1dV8pNOw54Y8dpA== X-Google-Smtp-Source: AOwi7QChIRW/TbNENtzUNqOe973P4xWiWpkKmBe9j843+4k1lw5lQsDrla1jk7w8e1FZurJ6wsXpug== X-Received: by 10.99.160.86 with SMTP id u22mr9231169pgn.283.1508193923834; Mon, 16 Oct 2017 15:45:23 -0700 (PDT) Received: from [130.216.38.84] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.84]) by smtp.gmail.com with ESMTPSA id y206sm17155340pfb.155.2017.10.16.15.45.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 15:45:22 -0700 (PDT) Subject: Re: Loopback interface terminology issue To: ipv6@ietf.org References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> Date: Tue, 17 Oct 2017 11:45:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:45:26 -0000 On 17/10/2017 07:49, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 16 Oct 2017 20:14:42 +0200, > Toerless Eckert wrote: >=20 >>> I don't understand what this means, but in any case I agree with Mark= >>> that IMO this is more about the weak/strong host model than >>> forwarding/non-forwarding. >> >> ---etherB--- >> host --etherA-- rtr >> ---etherB--- >> | host/rtr | >> >> Think of a host with an etherA connecting to a router that also has >> etherB, etherC. Now we just integrate this router into the host and et= herthernetA >> becomes an internal interface, but the apps can still use this interfa= ce, >> and so it is permissible for both strong and weak host models to use t= he IP >> address on etherA, whatever exernal ethernetB/ethernetC the packets ar= e >> sent/received through. >> >> The main difference between an internal ethernet and loopback in this = modelling >> is that when you send into a loopback interface, it does not need to r= un ND to >> find the link-local address of the router interface and forward the pa= cket to it, >> but instead the packet is immediately processed by the router forwardi= ng code. >=20 > Okay, I think I now understand what you meant. Such a model seems to > be quite a stretch convoluted or even artificial to me, but I wouldn't > necessarily deny possible existence of such implementations. But in > any event that seems to me quite a stretch from the situation Brian > originally raised. And, for these reasons, I personally wouldn't > support saying something in the addressing architecture that requires > a specific model of integrated host-router architecture. More > specifically I disagree with adding to the addrarch doc: >=20 > If other addresses beside "loopback addresses" are assigned to such a= link, > then the interface needs to be configured to forward non-self-destine= d > packets originated from the loopback interface (see rfc8200, section = 2). >=20 > If it also notes that it's for a host that adopts the strong host > model or the node adopting the hybrid architecture you mentioned > above, I might live with it, although I personally think it's too much > for the basic architecture document. Yes. I think the point that is lacking in the architecture is that unicast addresses that are not assigned to an operational physical or tunnel interface may be assigned to a virtual interface, which may be a loopback interface.=20 All the rest is indeed implementation-dependent. Brian From nobody Mon Oct 16 16:16:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFF2126DD9 for ; Mon, 16 Oct 2017 16:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydR_E7q6xkcW for ; Mon, 16 Oct 2017 16:16:06 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B360C126BF0 for ; Mon, 16 Oct 2017 16:16:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9GNG5r2002580; Mon, 16 Oct 2017 16:16:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9GNFur1002515 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 16 Oct 2017 16:15:56 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Oct 2017 16:15:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 16 Oct 2017 16:15:55 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRtByPxn1iJZL+kqA+Ph9pp2qTaLnGukA Date: Mon, 16 Oct 2017 23:15:55 +0000 Message-ID: <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> In-Reply-To: <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:16:08 -0000 QnJpYW4sDQoNCkhlcmUgaXMgd2hhdCBpdCBzYXlzIGluICdkcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdCc6DQoNCiAgIlRoaXMgZG9jdW1lbnQgYWxzbyBjb25zaWRlcnMgdGhlIGNhc2Ugd2hlbiAn UicgZG9lcyBub3QgaGF2ZSBhbnkNCiAgIGRvd25zdHJlYW0gaW50ZXJmYWNlcywgYW5kIGNhbiB1 c2UgJ1AnIHNvbGVseSBmb3IgaXRzIG93biBpbnRlcm5hbA0KICAgYWRkcmVzc2luZyBwdXJwb3Nl cy4gIEluIHRoYXQgY2FzZSwgJ1InIGFzc2lnbnMgJ1AnIHRvIGEgdmlydHVhbA0KICAgaW50ZXJm YWNlIChlLmcuLCBhIGxvb3BiYWNrKSB0aGF0IGZpbGxzIHRoZSByb2xlIG9mIGEgZG93bnN0cmVh bQ0KICAgaW50ZXJmYWNlLg0KDQogICAnUicgY2FuIHRoZW4gZnVuY3Rpb24gdW5kZXIgdGhlIHdl YWsgZW5kIHN5c3RlbSAoYWthICJ3ZWFrIGhvc3QiKQ0KICAgbW9kZWwgW1JGQzExMjJdW1JGQzgw MjhdIGJ5IGFzc2lnbmluZyBhZGRyZXNzZXMgdGFrZW4gZnJvbSAnUCcgdG8gYQ0KICAgdmlydHVh bCBpbnRlcmZhY2UgYXMgc2hvd24gaW4gRmlndXJlIDI6Ig0KDQpJbnRlcm5hbCB2aXJ0dWFsIGlu dGVyZmFjZXMgd2VyZSBhbHNvIGRpc2N1c3NlZCBpbiBSRkM1NTU4Lg0KDQpUaGFua3MgLSBGcmVk DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlw djYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQo+IFNl bnQ6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyAzOjQ1IFBNDQo+IFRvOiBpcHY2QGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBMb29wYmFjayBpbnRlcmZhY2UgdGVybWlub2xvZ3kgaXNzdWUNCj4g DQo+IE9uIDE3LzEwLzIwMTcgMDc6NDksIOelnuaYjumBlOWTiSB3cm90ZToNCj4gPiBBdCBNb24s IDE2IE9jdCAyMDE3IDIwOjE0OjQyICswMjAwLA0KPiA+IFRvZXJsZXNzIEVja2VydCA8dHRlQGNz LmZhdS5kZT4gd3JvdGU6DQo+ID4NCj4gPj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoaXMg bWVhbnMsIGJ1dCBpbiBhbnkgY2FzZSBJIGFncmVlIHdpdGggTWFyaw0KPiA+Pj4gdGhhdCBJTU8g dGhpcyBpcyBtb3JlIGFib3V0IHRoZSB3ZWFrL3N0cm9uZyBob3N0IG1vZGVsIHRoYW4NCj4gPj4+ IGZvcndhcmRpbmcvbm9uLWZvcndhcmRpbmcuDQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAtLS1ldGhlckItLS0NCj4gPj4gICAgICAgaG9zdCAtLWV0aGVyQS0tIHJ0cg0KPiA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tZXRoZXJCLS0tDQo+ID4+ICAgICAgIHwgICBo b3N0L3J0ciAgICAgfA0KPiA+Pg0KPiA+PiBUaGluayBvZiBhIGhvc3Qgd2l0aCBhbiBldGhlckEg Y29ubmVjdGluZyB0byBhIHJvdXRlciB0aGF0IGFsc28gaGFzDQo+ID4+IGV0aGVyQiwgZXRoZXJD LiBOb3cgd2UganVzdCBpbnRlZ3JhdGUgdGhpcyByb3V0ZXIgaW50byB0aGUgaG9zdCBhbmQgZXRo ZXJ0aGVybmV0QQ0KPiA+PiBiZWNvbWVzIGFuIGludGVybmFsIGludGVyZmFjZSwgYnV0IHRoZSBh cHBzIGNhbiBzdGlsbCB1c2UgdGhpcyBpbnRlcmZhY2UsDQo+ID4+IGFuZCBzbyBpdCBpcyBwZXJt aXNzaWJsZSBmb3IgYm90aCBzdHJvbmcgYW5kIHdlYWsgaG9zdCBtb2RlbHMgdG8gdXNlIHRoZSBJ UA0KPiA+PiBhZGRyZXNzIG9uIGV0aGVyQSwgd2hhdGV2ZXIgZXhlcm5hbCBldGhlcm5ldEIvZXRo ZXJuZXRDIHRoZSBwYWNrZXRzIGFyZQ0KPiA+PiBzZW50L3JlY2VpdmVkIHRocm91Z2guDQo+ID4+ DQo+ID4+IFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBpbnRlcm5hbCBldGhlcm5ldCBh bmQgbG9vcGJhY2sgaW4gdGhpcyBtb2RlbGxpbmcNCj4gPj4gaXMgdGhhdCB3aGVuIHlvdSBzZW5k IGludG8gYSBsb29wYmFjayBpbnRlcmZhY2UsIGl0IGRvZXMgbm90IG5lZWQgdG8gcnVuIE5EIHRv DQo+ID4+IGZpbmQgdGhlIGxpbmstbG9jYWwgYWRkcmVzcyBvZiB0aGUgcm91dGVyIGludGVyZmFj ZSBhbmQgZm9yd2FyZCB0aGUgcGFja2V0IHRvIGl0LA0KPiA+PiBidXQgaW5zdGVhZCB0aGUgcGFj a2V0IGlzIGltbWVkaWF0ZWx5IHByb2Nlc3NlZCBieSB0aGUgcm91dGVyIGZvcndhcmRpbmcgY29k ZS4NCj4gPg0KPiA+IE9rYXksIEkgdGhpbmsgSSBub3cgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFu dC4gIFN1Y2ggYSBtb2RlbCBzZWVtcyB0bw0KPiA+IGJlIHF1aXRlIGEgc3RyZXRjaCBjb252b2x1 dGVkIG9yIGV2ZW4gYXJ0aWZpY2lhbCB0byBtZSwgYnV0IEkgd291bGRuJ3QNCj4gPiBuZWNlc3Nh cmlseSBkZW55IHBvc3NpYmxlIGV4aXN0ZW5jZSBvZiBzdWNoIGltcGxlbWVudGF0aW9ucy4gIEJ1 dCBpbg0KPiA+IGFueSBldmVudCB0aGF0IHNlZW1zIHRvIG1lIHF1aXRlIGEgc3RyZXRjaCBmcm9t IHRoZSBzaXR1YXRpb24gQnJpYW4NCj4gPiBvcmlnaW5hbGx5IHJhaXNlZC4gIEFuZCwgZm9yIHRo ZXNlIHJlYXNvbnMsIEkgcGVyc29uYWxseSB3b3VsZG4ndA0KPiA+IHN1cHBvcnQgc2F5aW5nIHNv bWV0aGluZyBpbiB0aGUgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgdGhhdCByZXF1aXJlcw0KPiA+ IGEgc3BlY2lmaWMgbW9kZWwgb2YgaW50ZWdyYXRlZCBob3N0LXJvdXRlciBhcmNoaXRlY3R1cmUu ICBNb3JlDQo+ID4gc3BlY2lmaWNhbGx5IEkgZGlzYWdyZWUgd2l0aCBhZGRpbmcgdG8gdGhlIGFk ZHJhcmNoIGRvYzoNCj4gPg0KPiA+ICAgSWYgb3RoZXIgYWRkcmVzc2VzIGJlc2lkZSAibG9vcGJh Y2sgYWRkcmVzc2VzIiBhcmUgYXNzaWduZWQgdG8gc3VjaCBhIGxpbmssDQo+ID4gICB0aGVuIHRo ZSBpbnRlcmZhY2UgbmVlZHMgdG8gYmUgY29uZmlndXJlZCB0byBmb3J3YXJkIG5vbi1zZWxmLWRl c3RpbmVkDQo+ID4gICBwYWNrZXRzIG9yaWdpbmF0ZWQgZnJvbSB0aGUgbG9vcGJhY2sgaW50ZXJm YWNlIChzZWUgcmZjODIwMCwgc2VjdGlvbiAyKS4NCj4gPg0KPiA+IElmIGl0IGFsc28gbm90ZXMg dGhhdCBpdCdzIGZvciBhIGhvc3QgdGhhdCBhZG9wdHMgdGhlIHN0cm9uZyBob3N0DQo+ID4gbW9k ZWwgb3IgdGhlIG5vZGUgYWRvcHRpbmcgdGhlIGh5YnJpZCBhcmNoaXRlY3R1cmUgeW91IG1lbnRp b25lZA0KPiA+IGFib3ZlLCBJIG1pZ2h0IGxpdmUgd2l0aCBpdCwgYWx0aG91Z2ggSSBwZXJzb25h bGx5IHRoaW5rIGl0J3MgdG9vIG11Y2gNCj4gPiBmb3IgdGhlIGJhc2ljIGFyY2hpdGVjdHVyZSBk b2N1bWVudC4NCj4gDQo+IFllcy4gSSB0aGluayB0aGUgcG9pbnQgdGhhdCBpcyBsYWNraW5nIGlu IHRoZSBhcmNoaXRlY3R1cmUgaXMNCj4gdGhhdCB1bmljYXN0IGFkZHJlc3NlcyB0aGF0IGFyZSBu b3QgYXNzaWduZWQgdG8gYW4gb3BlcmF0aW9uYWwNCj4gcGh5c2ljYWwgb3IgdHVubmVsIGludGVy ZmFjZSBtYXkgYmUgYXNzaWduZWQgdG8gYSB2aXJ0dWFsDQo+IGludGVyZmFjZSwgd2hpY2ggbWF5 IGJlIGEgbG9vcGJhY2sgaW50ZXJmYWNlLg0KPiANCj4gQWxsIHRoZSByZXN0IGlzIGluZGVlZCBp bXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuDQo+IA0KPiAgICAgQnJpYW4NCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYu b3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Mon Oct 16 16:52:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D614133018 for ; Mon, 16 Oct 2017 16:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44P0eMvUjaB8 for ; Mon, 16 Oct 2017 16:52:50 -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 C86F7126BF0 for ; Mon, 16 Oct 2017 16:52:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXW10246; Mon, 16 Oct 2017 23:52:47 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 17 Oct 2017 00:52:46 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Mon, 16 Oct 2017 16:52:40 -0700 From: Lin Han To: Brian E Carpenter , 6man Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTRJJxnUgwu2qqQUiZZRbG4Yh0Q6LnHDEw Date: Mon, 16 Oct 2017 23:52:40 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E54650.005D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7cb7accc7f550a75fec5c1cf65323440 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:52:53 -0000 Hi, Brain Thanks for the comments, see my reply in line with [LH] Lin -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Friday, October 13, 2017 7:16 PM To: 6man Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos= -00.txt Hi, RSVP in IPv6 [RFC2205] uses packets with a Router Alert hop-by-hop option. = So although it is not embedded in application packets, it is otherwise very= similar: in band, following the same path as application packets, and trig= gering hop-by-hop processing in the same routers. [LH] The difference of this idea with RSVP is that RSVP needs a separate pr= otocol to be running, but this in-band signaling is always carried in a pac= ket of upper layer protocols (TCP, UDP, etc) and does not need to run a new= protocol. RSVP for Integrated Services was a complete failure. So my first questions = are: 1: What is the authors' full analysis of why RSVP failed? [LH] The complexity of the RSVP makes its scalability an issue. Specificall= y, RSVP needs every router run the protocol and maintain the state for ever= y RSVP session on the router; To maintain the RSVP soft-state, each source = of RSVP session has to periodically (~30sec and configurable) multicast the= PATH message with Tspec to whole network and the interested receiver has t= o return the RESV with Rspec to root of the mcast tree; All these control p= lane work make the RSVP session supported on a router limited by the contro= ller CPU processing power and memory size.=20 2: How does the proposed solution avoid the same failure? [LH] The in-band signaling proposal is based on the following ideas and ass= umptions 1) Network processor widely used in latest network device are capable of no= t only doing table lookup and switching but also doing general packet proce= ssing and other works which was only available by controller CPU (in old ge= neration network device). 2) If we simplify the QoS protocol work in request, reserve and state keep= ing to be fitting into the capability of a NPU, we can greatly reduce the c= omplexity of what RSVP or IntServ tries to do to provision the flow-level Q= oS and maintain the soft-sate for each flow with QoS. 3) Following are some details,=20 3.1) We simplify the Tsepc and Rspec to explicit bandwidth and latency requ= est, and rely on the NPU to program the hardware to satisfy the QoS require= ment, All QoS related traffic shaping, scheduling and queuing are hardware = dependent and should be irrelevant to the control plane;=20 3.2) Instead of using two directional message (in RSVP) to finish the reser= vation for a session, this propose only uses one directional in-band signal= messaging to program the hardware for the QoS for the flow on same directi= on. The reason we can do such simplification is because we don't have to ha= ve the complicated feature like the merging of request in RSVP. The propose= d in-band signaling only supports unicast, but RSVP was designed to support= both unicast and multicast, so, RSVP needs merging feature, and needs two = directional messages to finish the resource reservation. The new idea will = also be fitting to the IP nature that IP path is not symmetric in many scen= arios. As comparison, to use RSVP for asymmetric path is a problem.=20 3.3) The soft-state of each flow's QoS channel is maintained by the data pa= cket with the same flow identification. The QoS state programmed in the har= dware will be erased and the resource will be released if there is no data = packet for a programmed QoS state for a period of time. A host can simply s= end zero-size data packet to refresh the QoS state for the flow if there is= no application data. This could completely remove the state refreshing mec= hanism by a separate control protocol like RSVP which was a big overhead fo= r CPU to be scalable. 3.4) The NPU will use the pre-defined flow identification to forward a pack= et with QoS guarantee, and the forwarding state will be updated at each hop= -by-hop aware node and feed back to the source host. Source host can easily= decide if it needs to re-program the QoS for a flow if there is some failu= re (link, node, topology change, etc) 3.5) In summary, this approach will use a simplified mechanism (compared wi= th RSVP) to provision QoS, and it also moves the QoS control complexity and= processing burden from centralized controller CPU to distributed NPU of li= ne card. Normally there are more NPU than CPU in a router, so, the redistri= bution of the complexity will greatly improve the scalability.=20 3.6) Here are some hypothetical and experimental data in our POC: A typical= Huawei router can only support about 5k RSVP sessions (No data from other = vendors, but should be in same scale hopefully -:)). In POC, we apply the n= ew approach to a low/middle class access router (ATN9xxx, the NPU was desig= ned more than 5 year ago), each NPU can handle about 1k QoS session (The li= mit is majorly caused by the memory for queue and scheduler allocation), th= en whole system can support (num. of NPU) x 1k QoS session. Depending on po= rt configuration, a router can easily have more than 10 NPU.=20 4) Since we only did the experiment with our own proprietary NPU, and not s= ure if other company's NPUs have the similar capability as above, we put th= e document as "informational" (not sure if "experiment" is better, but can = be changed).=20 In particular, I do not understand your argument about scalability. While t= hat was an obvious issue for RSVP, it could be fixed in the way you describ= e: by limiting the number of using applications. The fundamental scaling is= sue for RSVP was the number of session state items per router, and your sol= ution needs exactly the same number of session state items. So why will you succeed where RSVP failed? > End user application cannot directly use DiffServ. Not true. The advanced socket API allows the transport user to set the DSCP= via IPV6_TCLASS [RFC3542]. It's been done for many years, for example in I= P telephones. [LH] agreed, will correct the document. What is lacking is a host software package to make this API feature useful,= but any QoS solution needs that. In your terminology, that is the applicat= ion interface to the closed-loop control system. Note that RTCWEB has chosen to support Diffserv [https://datatracker.ietf.o= rg/doc/draft-ietf-tsvwg-rtcweb-qos/] > 3.2. IP In-band signaling >=20 > There is no definition for IP in-band signaling. Not true. That's exactly what DiffServ is. You could argue that it's too li= mited, but after 19 years we have not exhausted the DSCP code space defined= in [RFC2474]. (As far as I know, nobody has yet combined use of the DSCP w= ith the Flow Label. There is scope for creativity there.) [LH] The difference of this approach with DiffServ is the granularity of Qo= S. DiffServ was very successful. As I stated in the document, some applicat= ion needs much more bandwidth (than others) and we need a way to specify t= he QoS requirement explicitly for those flows.=20 > Flow level In-band Signaling > The control message and data packet share the same flow > identification. The flow identification could be 5 tuples ... I agree with the comment that the IPv6 flow label is a much better choice. = It is already well defined [RFC6437] and widely supported by operating syst= ems, it works for any transport protcol, works for encrypted packets, and w= orks for packets with multiple extension headers. If you want per-flow gran= ularity, the flow label is perfect. [LH] Agreed,=20 > The HbH-EH may be examined and processed by the nodes that are > explicitly configured to do so [RFC8200] which also says in section 4.8: " New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behavior. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized." I believe you need much more explanation of why we should ignore this recom= mendation. [LH] The propose does not introduce new hop-by-hop option header, we only i= ntroduce new option carried in the existing hop-by-hop option header, it is= the same as other defined options carried by hop-by-hop option header, suc= h as "Jumbo Payload", "RPL Option", "Quick-Start", etc. I think the IPv6 do= cument sometime uses the general "hop-by-hop option" word as the " hop-by-h= op option extension header" really confuse people. I believe the above docu= ment does not recommend to introduce new hop-by-hop option extension header= , but not stop introducing new options carried in the current hop-by-hop op= tion header. =20 I will check with IPv6 author for clarification. Below are existing IPv6 hop-by-hop and destination options defined (HbH: ho= p-by-hop option header; Dst: Destination extension header) 0x00 00 0 00000 Pad1 [[IPV6]] - HbH 0x01 00 0 00001 PadN [[IPV6]] - HbH 0xC2 11 0 00010 Jumbo Payload [RFC2675] - HbH 0x63 01 1 00011 RPL Option [RFC6553] - HbH 0x04 00 0 00100 Tunnel Encapsulation Limit [RFC2473] - Dst 0x05 00 0 00101 Router Alert [RFC2711] - HbH 0x26 00 1 00110 Quick-Start [RFC4782][RFC Errata 2034] - HbH 0x07 00 0 00111 CALIPSO [RFC5570] - HbH 0x08 00 0 01000 SMF_DPD [RFC6621] - HbH 0xC9 11 0 01001 Home Address [RFC6275] - Home Addr Dst 0x8A 10 0 01010 Endpoint Identification (DEPRECATED) [[CHARLES LYNN]] 0x8B 10 0 01011 ILNP Nonce [RFC6744] - Dst 0x8C 10 0 01100 Line-Identification Option [RFC6788] - Dst 0x4D 01 0 01101 Deprecated [RFC7731] 0x6D 01 1 01101 MPL Option [RFC7731] - HbH 0xEE 11 1 01110 IP_DFF [RFC6971] -HbH 0x0F 00 0 01111 Performance and Diagnostic Metrics (PDM) [RFC8250] - Dst > 8. Security Considerations >=20 > There is no security issue introduced by this document I think this section needs more work. [LH] Yes, will add more Regards Brian Carpenter On 12/10/2017 07:05, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : IPv6 in-band signaling for the support of trans= port with QoS > Authors : Lin Han > Guoping Li > Boyan Tu > Xuefei Tan > Frank Li > Richard Li > Jeff Tantsura > Kevin Smith > Filename : draft-han-6man-in-band-signaling-for-transport-qos-00.= txt > Pages : 40 > Date : 2017-10-11 >=20 > Abstract: > This document proposes a method to support the IP transport service > that could guarantee a certain level of service quality in bandwidth > and latency. The new transport service is fine-grained and could > apply to individual or aggregated TCP/UDP flow(s). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-han-6man-in-band-signaling-for- > transport-qos/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-trans > port-qos-00 > https://datatracker.ietf.org/doc/html/draft-han-6man-in-band-signaling > -for-transport-qos-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Mon Oct 16 16:58:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A296513202D for ; Mon, 16 Oct 2017 16:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 818GsTCdtfnL for ; Mon, 16 Oct 2017 16:58:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470A9132F2C for ; Mon, 16 Oct 2017 16:58:19 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5B67458C501; Tue, 17 Oct 2017 01:58:15 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 38E61B0CECC; Tue, 17 Oct 2017 01:58:15 +0200 (CEST) Date: Tue, 17 Oct 2017 01:58:15 +0200 From: Toerless Eckert To: ???????????? Cc: 6man , Mark Andrews Subject: Re: Loopback interface terminology issue Message-ID: <20171016235814.GB31973@faui40p.informatik.uni-erlangen.de> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 23:58:24 -0000 On Mon, Oct 16, 2017 at 11:49:23AM -0700, ???????????? wrote: > > The main difference between an internal ethernet and loopback in this modelling > > is that when you send into a loopback interface, it does not need to run ND to > > find the link-local address of the router interface and forward the packet to it, > > but instead the packet is immediately processed by the router forwarding code. > > Okay, I think I now understand what you meant. Such a model seems to > be quite a stretch convoluted or even artificial to me, but I wouldn't > necessarily deny possible existence of such implementations. But in > any event that seems to me quite a stretch from the situation Brian > originally raised. I don't think its that far out. In ANIMA ACP and other solutions, all nodes are forwarders, run routing protocol, do not use external interface global adddresses, but just those "internal" node addresses on eg.: a loopback interface. If you look at the OS infrastructure of those nodes i think it is a lot easier not having to bother with host stack improvements/changes if you can constrain it to forwarder code. But of course my viewpoint may be tainted from work experience. > And, for these reasons, I personally wouldn't > support saying something in the addressing architecture that requires > a specific model of integrated host-router architecture. More > specifically I disagree with adding to the addrarch doc: [...] You're right. Given how it is equally well feasible to to not use forwarder but weak host model, my proposal would constrain the options. So, now i wonder for my ANIMA ACP draft if we should describe that the nodes need to operate in the forwarder model i describe or in the weak host model, or that should be left unsaid. The desired behavior definitely is not possible with strong host model without forwarder. > If it also notes that it's for a host that adopts the strong host > model or the node adopting the hybrid architecture you mentioned > above, I might live with it, although I personally think it's too much > for the basic architecture document. It certainly would be nice to have a description of how to operate what i would call a "node address" in not a solution specific document like our ANIMA ACP doc, but in some IPv6 arch document. Doesn't have to be "basic". Cheers Toerless > > -- > JINMEI, Tatuya From nobody Mon Oct 16 21:04:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3D5132199 for ; Mon, 16 Oct 2017 21:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoQqtM_Dw8Gy for ; Mon, 16 Oct 2017 21:04:36 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 0C6881320DC for ; Mon, 16 Oct 2017 21:04:36 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id n14so398507pfh.8 for ; Mon, 16 Oct 2017 21:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ew2+0FskcIPj/QZ+sTebJ/Zjoox87vRMmloLVHS8YhI=; b=jmIsWkUtb7S7EvOp8QT7GU4w5gayJkBsjEvpduTahxZ51D53xFoUI7e3vJXpO+KnND 2ILIGBmz8oqD9t7pLCdZyYNOjJ2WEWmGw42lf5rwx2oY16QxZ4o+UrRXB1WTz+5Knm0j m2Co+ddvbfJ/tCUNcpNgWvM3Ba149RX3uV3eg/Gio7J4IErcQwYH3nE+bLFJa+wIwfqc lAeLgcLJ+eehoknZgaKoBQQt7l3+3pYStt/HF1mt7jVyn58PLJsJYH83JlXC/RCmLvhK cqXj15F1Prs+ZiA4i6QRshXwVIHiGKXSjV/C57TltBEBEQJ4ACFyb5RQ25ovVB1ghXhs Sb1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Ew2+0FskcIPj/QZ+sTebJ/Zjoox87vRMmloLVHS8YhI=; b=pSudQLR0VB8O0SDjschluMnYfZKfvmzC9sUQffvHDOE4xiHDFnvkva/FXn73uDGtQ9 oAY84D96t8+j5FkSbhYNynVCT0Qe+N6EuzGqHnzyaY7SZ4MdPC37Z4wJ/fdS9zIjeUm9 lkWRnE7y27jHhHHiJYUGB6eN/nxHna9nYtkbUtEyFhhUhJiYTEiELB3VbsWezAw6hRMa v/3m+uaEOLWvYjiu4/vj9Lyf9BgnS1wXxLuMfT4H2nQqXQl9uOZGp0LitqtRyTaRdZN9 xlM0728l1mDjrc4yA2MEtTNKf8651+HB2utC9H/ZLyc/YHBebRgXeAugG+UFxmMTRxDp zhYA== X-Gm-Message-State: AMCzsaVDFnmp1AAvhQXvtDGTtPRStxRvOZ198iwJIyPGgZ+1HGmiTByj +VJkphAgQRk5nIXfU/+O2wc4nw== X-Google-Smtp-Source: AOwi7QC++s3i79HL17tRTJgQOFrLDYcGKwC62L2gC1xp+c+ObjTGiVB4j30sBKjZt96RFhUM6zQ3kQ== X-Received: by 10.84.173.4 with SMTP id o4mr10739424plb.152.1508213075174; Mon, 16 Oct 2017 21:04:35 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l71sm10895220pfj.11.2017.10.16.21.04.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 21:04:34 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Lin Han , 6man References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 17 Oct 2017 17:04:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 04:04:38 -0000 Just replying on one point, since most of this discussion clearly needs to happen in TSVWG: On 17/10/2017 12:52, Lin Han wrote: ... > >> The HbH-EH may be examined and processed by the nodes that are >> explicitly configured to do so [RFC8200] > > which also says in section 4.8: > > " New hop-by-hop options are not recommended because nodes may be > configured to ignore the Hop-by-Hop Options header, drop packets > containing a Hop-by-Hop Options header, or assign packets containing > a Hop-by-Hop Options header to a slow processing path. Designers > considering defining new hop-by-hop options need to be aware of this > likely behavior. There has to be a very clear justification why any > new hop-by-hop option is needed before it is standardized." > > I believe you need much more explanation of why we should ignore this recommendation. > > [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header, Yes, that is exactly what the paragraph from RFC8200 means: it says "New hop-by-hop options are not recommended". Brian From nobody Tue Oct 17 00:11:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C731332D5 for ; Tue, 17 Oct 2017 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hHFvlGaF4KES for ; Tue, 17 Oct 2017 00:11:13 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA481331F1 for ; Tue, 17 Oct 2017 00:11:13 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 3F9EF2D50AF; Tue, 17 Oct 2017 07:11:12 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 97D74200585B54; Tue, 17 Oct 2017 09:11:03 +0200 (CEST) From: Ole Troan Message-Id: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3760EBA3-1BE5-4104-99CC-9635850DF4A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Date: Tue, 17 Oct 2017 09:11:02 +0200 In-Reply-To: Cc: Lin Han , 6man WG To: Brian E Carpenter References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 07:11:15 -0000 --Apple-Mail=_3760EBA3-1BE5-4104-99CC-9635850DF4A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> [LH] The propose does not introduce new hop-by-hop option header, we = only introduce new option carried in the existing hop-by-hop option = header, >=20 > Yes, that is exactly what the paragraph from RFC8200 means: it > says "New hop-by-hop options are not recommended". Blindly reciting rules without also understanding and explaining the = intent leads to unintended consequences. In this particular case, where every hop along the path would need to = support it, then that's the exact use case for the hop by hop header. Ole --Apple-Mail=_3760EBA3-1BE5-4104-99CC-9635850DF4A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnlrQYACgkQvtpYqJhC 33bubQ//f9VS/PPLQVeXYjX53vmM4p/FpBSsQ26OE9pk/zrV8CmS0u1w9xSXRN6A VUZxi3J2Y6hDEhWwpjNvh3Pxgic/vEq09XFQFjllQRPik4zDXZziLmGlym5QKR4P UEs4KU/e5MJHK+V9RsshTgBMedzpApkNXBp6TfDTWtZjUPUZvqL8h0fKEv39Hwqf hspgCuT6Zp6ozPQoRFHiKJACPX9M+E5BQYuExzqH+Y1JTfaDKQLzI+VraIlzsvbY 3VXMhWPtYLrv++K5Tk+SXJFFKeUMT1MD2nw1cTVL91gyi/mMyOobvZmIqOhvqSz3 h62+8xmFD4EYIRvCaND0E3Plbg3WmkJ4pbFg/mJjgQaHh4cQUAGtg0V0c9mn2L0/ S6j2os3BrBQJk1Pg3csFFLpysPXeBa8rZhZ3YwUk/vDDrpVFPuXhGShaRSNUcWp2 h0I1VuAjyfc6lgxMWCr6K/C+U/iDZlh9v/b7SIaXGOprb7yb6legoymdJcgjP7WD nHj0MQHQoYhPPLMuhpxjHNMOlYc4cQi0l5XXViQZYKNxnbDz08KtTpJXq9YFN3NQ 8GKfwKKX5VFc6hdVV1uGHd/YmJL+k81dfSoQGvgGtg/sIu07e5VAG6RMHNApJGJS NPjQf9kfEiXIvTwmb2csnQX6YG7HxGsR8PGbc3iuOTbGowQm3q0= =n2gj -----END PGP SIGNATURE----- --Apple-Mail=_3760EBA3-1BE5-4104-99CC-9635850DF4A9-- From nobody Tue Oct 17 07:35:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410A01332DA for ; Tue, 17 Oct 2017 07:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYw1bBL3V64v for ; Tue, 17 Oct 2017 07:35:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EBF132F84 for ; Tue, 17 Oct 2017 07:35:02 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3A6B058C512; Tue, 17 Oct 2017 16:34:58 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 23254B0CEDF; Tue, 17 Oct 2017 16:34:58 +0200 (CEST) Date: Tue, 17 Oct 2017 16:34:58 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: 6man Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171017143457.GC31973@faui40p.informatik.uni-erlangen.de> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 14:35:06 -0000 > 1: What is the authors' full analysis of why RSVP failed? > 2: How does the proposed solution avoid the same failure? Not an author, but some thoughts: Given the existance of RSVP-TE and GMPLS, i wouldn't say RSVP failed. IMHO there are lots and lots of issues with RSVP-IPs history that we now know how to avoid. I think inband signaling is the one core architecture option we have explored way too little and has only practically become feasible within the last maybe 10 years. IMHO one key reason RSVP(-IP) was not adopted more is because of non-ubiquitous support of the host stack/APIs. And OSs where it once was supported did withdrew support for it. It was also killed by the initial focus on admission control - permit/deny flows. Most customers thought thats what i was good for. And they needed that but came up with faster to deply workarounds (eg: in IPTV). As opposed to unequal bandwidth allocation. And nobody ever wrote a draft showing how to implement the various options how to avoid eg: per-flow queues. By the time we wanted to get back to these topics, there was already the generation of IETF'ler burned by prior bad experience that where pushing back on any innovation in this space ("been there, done that, failed, go away"). Router alert also killed RSVP. Lots of router implementations punt packets with router alert independent of the indicated protocol. So even if you don't run RSVP, your router would punt RSVP router alert packets. So SPs try to get rid of router-alerts on their network edge. I personally think we can't resurrect router alert option like we resurrect ECN but have to choose other options (like what Lin propooses). Onpath signalling from RSVP is also fundamentally different from inband signalling. Just try to get RSVP through a NAT or firewall. Or try to make it stay onpath when you have ECMP. I once had to work through all the path selection rules of one back then popular router OS to propose an architecture how to expose all the options so RSVP could stay onpath. Short summary: @$^%*$(@*&(*&@^$*&. There was absoutely no consideration for RSVP to be designed in a way that would allow for it to be easily processable in the forwarding plane (called NPU in the draft). Or "inband" as we like to call it now. The industry has a lot of experience with high performance per-flow state building from control-plane (CPU) signaling. IP multicast. So we know how much of a pain it is. And the industry hated it. Unlike RSVP they just didn't find any workarounds for IP multicast and had intra-domain end-to-end use-cases (IPTV, finance) so individual vendors could push vendors to make it work - over 20 year. Just check out the interest in BIER to see how the industry wants to get rid of per-flow state maintenance and instead prefers a more lightweight "in-band-singnaling" of replication. In fact, both RSVP/IP-multicast state building was a lot more scaleable on CPU-only forwarding plane type devices 20 years ago then it is in todays CPU/NPU separated systems. Its getting through the bottleneck of IPC between CPU and NPU for example. I could go on... Cheers Toerless On Sat, Oct 14, 2017 at 03:16:16PM +1300, Brian E Carpenter wrote: > Hi, > > RSVP in IPv6 [RFC2205] uses packets with a Router Alert hop-by-hop > option. So although it is not embedded in application packets, it is > otherwise very similar: in band, following the same path as application > packets, and triggering hop-by-hop processing in the same routers. > RSVP for Integrated Services was a complete failure. So my first > questions are: > > 1: What is the authors' full analysis of why RSVP failed? > 2: How does the proposed solution avoid the same failure? > > In particular, I do not understand your argument about > scalability. While that was an obvious issue for RSVP, it > could be fixed in the way you describe: by limiting the number > of using applications. The fundamental scaling issue for > RSVP was the number of session state items per router, and your > solution needs exactly the same number of session state items. > So why will you succeed where RSVP failed? > > > End user application cannot directly use DiffServ. > > Not true. The advanced socket API allows the transport user to set > the DSCP via IPV6_TCLASS [RFC3542]. It's been done for many years, > for example in IP telephones. > > What is lacking is a host software package to make this API feature > useful, but any QoS solution needs that. In your terminology, that > is the application interface to the closed-loop control system. > > Note that RTCWEB has chosen to support Diffserv > [https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/] > > > 3.2. IP In-band signaling > > > > There is no definition for IP in-band signaling. > > Not true. That's exactly what DiffServ is. You could argue that > it's too limited, but after 19 years we have not exhausted the > DSCP code space defined in [RFC2474]. (As far as I know, nobody > has yet combined use of the DSCP with the Flow Label. There is > scope for creativity there.) > > > Flow level In-band Signaling > > The control message and data packet share the same flow > > identification. The flow identification could be 5 tuples ... > > I agree with the comment that the IPv6 flow label is a much better > choice. It is already well defined [RFC6437] and widely supported > by operating systems, it works for any transport protcol, works > for encrypted packets, and works for packets with multiple extension > headers. If you want per-flow granularity, the flow label is perfect. > > > The HbH-EH may be examined and processed by the nodes that are > > explicitly configured to do so [RFC8200] > > which also says in section 4.8: > > " New hop-by-hop options are not recommended because nodes may be > configured to ignore the Hop-by-Hop Options header, drop packets > containing a Hop-by-Hop Options header, or assign packets containing > a Hop-by-Hop Options header to a slow processing path. Designers > considering defining new hop-by-hop options need to be aware of this > likely behavior. There has to be a very clear justification why any > new hop-by-hop option is needed before it is standardized." > > I believe you need much more explanation of why we should ignore > this recommendation. > > > 8. Security Considerations > > > > There is no security issue introduced by this document > > I think this section needs more work. > > Regards > Brian Carpenter > > On 12/10/2017 07:05, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : IPv6 in-band signaling for the support of transport with QoS > > Authors : Lin Han > > Guoping Li > > Boyan Tu > > Xuefei Tan > > Frank Li > > Richard Li > > Jeff Tantsura > > Kevin Smith > > Filename : draft-han-6man-in-band-signaling-for-transport-qos-00.txt > > Pages : 40 > > Date : 2017-10-11 > > > > Abstract: > > This document proposes a method to support the IP transport service > > that could guarantee a certain level of service quality in bandwidth > > and latency. The new transport service is fine-grained and could > > apply to individual or aggregated TCP/UDP flow(s). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-han-6man-in-band-signaling-for-transport-qos/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-transport-qos-00 > > https://datatracker.ietf.org/doc/html/draft-han-6man-in-band-signaling-for-transport-qos-00 > > > > > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Tue Oct 17 08:53:57 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADBE1332CD for ; Tue, 17 Oct 2017 08:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEt6dUSNLXpD for ; Tue, 17 Oct 2017 08:53:54 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E3013303F for ; Tue, 17 Oct 2017 08:53:54 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id p1so4557714qtg.2 for ; Tue, 17 Oct 2017 08:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NH7akRP5p1Tmx+gI1Gw1JhIFZ/x94PHZJDMonT5O4To=; b=D9+EewxJkDcPQCvsqNEb0FOny1jBahuz0KVGZM/VqKbaSo1m9vGpjmwu71rWRHtYwq 0JreZjY52CMOwLC6DtJzA5CZduhck6lynEKqCsVOF/KnYrjEb90vrm4M/eylsxyrS/0p R7N5wZsLdsr38Nzr53OG9oppXH47M+mMbQC2SdUe3x31XQjp1Q6rlMl/9a0Lf3sHhIz5 5jgb8BvLvpcOzbOKLz4E/2pSlgH+H+DCJ77Z4MKbWxbD3UrLHjr7Oh5pZZo2OJFcRvqg qGs6d1LNSEsXrytI1aPzzDMeUTtBAEH4a6NMorERtC85G4JUzCGOf6saJoxfbLaPMEia Ogow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NH7akRP5p1Tmx+gI1Gw1JhIFZ/x94PHZJDMonT5O4To=; b=ftDdepcyg6+4/KUpjDXJWtFs9OHGapLmz5q3dIKkRv0r9dGP9LNk3ka41Qvf8LDk9W 4sz9gtxnhklA7hx12soAtaIJFyW2H/lfLbr3ueQIqEulN9AYCkWI+VvHJlBM+Igg4VQg NvF193c9E8a21QSwiei5Qfbpr+6d4Xiy+0wTnwkJc7MxXYIrYOMBuq+rlrPnyCJOKo58 3ifQyWMwq/2AwBsdMym9z8R7575Uq/J2+zHWw6doYHSPLExPM1sQyjbjTnwBU3EaiVW0 UICe1HAjJe4sGSy2CiZiLi0L4bVMEmKvMH3ING/TuIzkfLkyBpRhXH4JpKH9RyxLOSbC hk6Q== X-Gm-Message-State: AMCzsaWkDr/ZbxpyePc9KXTyW06CQCXTkR5DXuy9O1ud1D3LtNEABuPw EfXaD0lbOZfYLoFqamzQiHvR+FwXtMaBQ1dfXI4P8A== X-Google-Smtp-Source: AOwi7QCQdkXsBxfzH/XDrcRD4Pp8G6gqZl5mimrNGUHq47EXrNeBW5yxFucFjLPXToGT5gWfjgFDgfPAj13Iqxvcu0Y= X-Received: by 10.200.38.118 with SMTP id v51mr20801620qtv.205.1508255633651; Tue, 17 Oct 2017 08:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 08:53:53 -0700 (PDT) In-Reply-To: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> From: Tom Herbert Date: Tue, 17 Oct 2017 08:53:53 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Ole Troan Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 15:53:56 -0000 On Tue, Oct 17, 2017 at 12:11 AM, Ole Troan wrote: >>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header, >> >> Yes, that is exactly what the paragraph from RFC8200 means: it >> says "New hop-by-hop options are not recommended". > > Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences. > RFC8200 also relaxes the requirement that HbH has to be examined by every host which I think mitigates some of the concerns that prompted the recommendation against new hop-by-hop options. > In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header. > I don't think that every hop in the path would necessarily need to support this. It may be the case that traffic engineering is only being done on one or two links in the path (backbone links for instance) so support is needed there, but nodes at other hops could ignore the HbH option. Tom > > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Oct 17 09:28:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB2C134225 for ; Tue, 17 Oct 2017 09:28: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, 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 YmGbOXlId7_B for ; Tue, 17 Oct 2017 09:28:29 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BF4134216 for ; Tue, 17 Oct 2017 09:28:29 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 1C4C32D5074; Tue, 17 Oct 2017 16:28:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 37A5620062A304; Tue, 17 Oct 2017 18:28:19 +0200 (CEST) From: Ole Troan Message-Id: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2377ABF1-217C-42F8-BF29-5D6B576B6473"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Date: Tue, 17 Oct 2017 18:28:18 +0200 In-Reply-To: Cc: Brian E Carpenter , 6man WG To: Tom Herbert References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:28:31 -0000 --Apple-Mail=_2377ABF1-217C-42F8-BF29-5D6B576B6473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, >>>> [LH] The propose does not introduce new hop-by-hop option header, = we only introduce new option carried in the existing hop-by-hop option = header, >>>=20 >>> Yes, that is exactly what the paragraph from RFC8200 means: it >>> says "New hop-by-hop options are not recommended". >>=20 >> Blindly reciting rules without also understanding and explaining the = intent leads to unintended consequences. >>=20 > RFC8200 also relaxes the requirement that HbH has to be examined by > every host which I think mitigates some of the concerns that prompted > the recommendation against new hop-by-hop options. >=20 >> In this particular case, where every hop along the path would need to = support it, then that's the exact use case for the hop by hop header. >>=20 > I don't think that every hop in the path would necessarily need to > support this. It may be the case that traffic engineering is only > being done on one or two links in the path (backbone links for > instance) so support is needed there, but nodes at other hops could > ignore the HbH option. Right. the HBH is the most efficient way we have to inform an = intermediate node, please take a closer look at this packet if you are = configured to do so. There are of course significant deployment issues with HBH and a higher = drop probability if you wanted to carry that header outside of the AS. While the 6man working group can certainly help the authors with those = considerations, I believe the work would have to be owned somewhere = else. And it might be a little too early to go into the details of packet = formats etc. Best regards, Ole --Apple-Mail=_2377ABF1-217C-42F8-BF29-5D6B576B6473 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnmL6IACgkQvtpYqJhC 33Ycmg/7Bsrw+lyAi+wDSgqdF8TOcCw8gYMR9d1XJ3d0S0Xar3mcofu0ScdkJCTZ itbgCRf+SxbehpVIRZevZgvxTUwkIvzhJMLqQQnrRSQwtFGDy7BBxmsceI/zjLyA R9N22eBGccHKuI2e5l4XtfPu8BkJkl+tqMoiW7toFAiumRpUsiMrhoR2qfK2+KLa qMtVJ9PWewBUfCwONIzJhQiVBOe57U6HL6XONUvRW/4dQ99I8Njc3DWTxaDYRmcT MfVuZMSXbVscAhQFCpuP49fVoKO5bNqejuMKqblcKZZvOaYw5CHS5XVKxp0PEPjS DnRAyK6/lVSQdD2HUH9VGW6xxWK/3Rff/luqVsrRUQV9WvWQdayBtn9YIO7Hw3Wt 74rMc6PnZQoWCRIRc/FqCtAojT03PRl4OVHN+BxhI5AL6nDyo+sE2e50m4gKQJi6 BikdV5JG1rQzBixUHHV4aQN25YkK3RudOd/M9HZ8F2Y+7ESljMmeoo0syWuKx+pM 2Lw2rGbmB2k7cuJpr+v+pszx4HDQJglIq1EkQpVUhSnkoWc1//ek8YqUh9KdmuDJ wzYrTXMgTsr5qTpn08tTAl/PXI4DSS6ABnYfHR+kAOqjAzv21CU/QiIm+w/Tnfax /dlMMQOwPzEl5JYMeIPKGrHQYZTpA+XsCM+9lgfFUS1dDzxXhqo= =IY65 -----END PGP SIGNATURE----- --Apple-Mail=_2377ABF1-217C-42F8-BF29-5D6B576B6473-- From nobody Tue Oct 17 09:54:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1C11332DF for ; Tue, 17 Oct 2017 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEtGigPRqPuW for ; Tue, 17 Oct 2017 09:54:53 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F4113207A for ; Tue, 17 Oct 2017 09:54:53 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id z28so4954979qtz.13 for ; Tue, 17 Oct 2017 09:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ibi43jLW6JIwt2qbZcpNV7HgQCY9JJbBZIFMthAtetU=; b=WOJ0kiCYdT+OtQ3MzY1ba4oLQC7m6Y2U6f0oGUIASBbmV6C8q+GvBQd0IXyvzwIZoK zPyXrKQNfJI4meGUfW4lOUz6bJuMH5bBn6mktbUu2213JiZhv7/OhJwJTqejm2+f1UNw 8R+XVo3/zGaU/nqcEhgwmK5pAry1sYcMPN3qKwJNgybA2EF5e2mB/edAvsAzHvxwSvH8 dj3Gi+S7FiniN26shlLw1qbtVTwewsey18WifqWF4AZjM9ohsDrmDmpm9XkAxMPWoWr0 GTR/RsmiAIPkzo9JTIm+mT6ESJg4ZRRj1777W7uaBKiD/YBd9O9rG0pJXQlsmlwUM8zZ 2H0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ibi43jLW6JIwt2qbZcpNV7HgQCY9JJbBZIFMthAtetU=; b=VIraOab0qsnF/+1p5u4lpNNMmz9HA3ctRxqkhPWgC5cP0zeUcz4ojEw3yGwhEaaWV0 CSeWh/3EX2Ms08BH23ez5EiRlwCdA5M4ZZKP66aGt/0jUku5DoVSkZHSrkxhl3EG3egV f60ZtuAu4gU8MYQ08190UPK8GXmcBf7uYhGl2TgSueBxBGznqEz6Tck5NGsLajs5owNF YckSaP7p2wzuVNZujFeJhkxaETkyjzZLrignJjhVeWycBnCDj6+QU3icuewEMgDzmfTJ pwO60XvaAGHZUTK+NkpK2kH1oDqtjmFTvHxi14UbPGkvTvaPm5t4w/fOSlWrrPLN2KE7 wSow== X-Gm-Message-State: AMCzsaUPtfoN2qwjg4arb9EuhosGBXP0k7N/YnhokkEXPS0p+GPwiGF+ XrYkj7zqisxtZWqTmVkRq3UBmxeHpVJ+NMoJ9RNCHQ== X-Google-Smtp-Source: AOwi7QCVf3p+9yqfchl/RWuj2DsU+HM40+FPCX/Kypq00koCrstmfFqX9WdUG8Vb3edsJIssAqaskJ3kvrYTg4P4jss= X-Received: by 10.200.53.89 with SMTP id z25mr21253238qtb.58.1508259292725; Tue, 17 Oct 2017 09:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 09:54:52 -0700 (PDT) In-Reply-To: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> From: Tom Herbert Date: Tue, 17 Oct 2017 09:54:52 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Ole Troan Cc: Brian E Carpenter , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:54:55 -0000 On Tue, Oct 17, 2017 at 9:28 AM, Ole Troan wrote: > Tom, > >>>>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header, >>>> >>>> Yes, that is exactly what the paragraph from RFC8200 means: it >>>> says "New hop-by-hop options are not recommended". >>> >>> Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences. >>> >> RFC8200 also relaxes the requirement that HbH has to be examined by >> every host which I think mitigates some of the concerns that prompted >> the recommendation against new hop-by-hop options. >> >>> In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header. >>> >> I don't think that every hop in the path would necessarily need to >> support this. It may be the case that traffic engineering is only >> being done on one or two links in the path (backbone links for >> instance) so support is needed there, but nodes at other hops could >> ignore the HbH option. > > Right. the HBH is the most efficient way we have to inform an intermediate node, please take a closer look at this packet if you are configured to do so. > There are of course significant deployment issues with HBH and a higher drop probability if you wanted to carry that header outside of the AS. > Ole, On one hand, IETF defined extension headers as the extensibility mechanism of IPv6, but yet on the other hand the message seems to be to not use them because deployed devices don't correctly support the protocol. The upshot is that we see proposals in other WGs of stuffing network layer information into transport protocols (options or payloads) with the full expectation that intermediate nodes will parse into the transport layer, process the embedded information, and possibly even overwrite transport layer information. IMO that is an architectural abomination and further abandonment of the end to end model! > While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. > And it might be a little too early to go into the details of packet formats etc. > Agreed, but I do think the 6man working group has a vested interest to make sure that network layer information stays in the network layer. At some point the information needed is going to be so complex that it won't be able to be conveyed in any fields of the IP header. Tom > Best regards, > Ole From nobody Tue Oct 17 11:16:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF28133073 for ; Tue, 17 Oct 2017 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjf7MDMJnFGl for ; Tue, 17 Oct 2017 11:16:51 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFDE1320B5 for ; Tue, 17 Oct 2017 11:16:50 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A44DF58C4D8; Tue, 17 Oct 2017 20:16:46 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8EADCB0CEE3; Tue, 17 Oct 2017 20:16:46 +0200 (CEST) Date: Tue, 17 Oct 2017 20:16:46 +0200 From: Toerless Eckert To: Tom Herbert Cc: Ole Troan , 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 18:16:53 -0000 As mentioned in my prior mail: RSVP-IP deployments got killed by SPs that filtered packets with router-alert because common network devices punted packets because of the presence of router-alert. Instead of punting them because of presence of RSVP-router-alert option. And of course you can blame IP multicast: every router started to punt router-alert because of MLD (and of course us multicast folks missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), but no RFC told developers to punt because of router-alert + value in the router alert. AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss this issue. IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets because of the presence of this mechanism, but only because of presence of (mechanism,value) where value is intended to be supported by device. If the device can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism as if the option was not present. One simple way to do this is to define hop-by-hop-fixed that does say exactly this and then hopefully allow all existing hop-by-hop TLV to live underneath that fixed hop-by-hop-fixed option. But i would certainly suggest to review processing complexity and extensibility before such a conclusion. Personally i prefer inband UDP layer signaling, not because i do not like IPv6 option headers but because there is just no ubiquitous API to allow apps independent of OS enhancements to set arbitrary options headers, especially ones that are not yet defined (allow apps to fully defined the whole header bit by bit). Lets say from a javascript app in a browser. And i am more interested in ease of adoption than in architectural cleanlyness. But of course its perfectly valid to do the architectural clean appraoch and then prove me wrong and get that option adopted more ;-)) Cheers Toerless On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: > On one hand, IETF defined extension headers as the extensibility > mechanism of IPv6, but yet on the other hand the message seems to be > to not use them because deployed devices don't correctly support the > protocol. The upshot is that we see proposals in other WGs of stuffing > network layer information into transport protocols (options or > payloads) with the full expectation that intermediate nodes will parse > into the transport layer, process the embedded information, and > possibly even overwrite transport layer information. IMO that is an > architectural abomination and further abandonment of the end to end > model! > > > While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. > > And it might be a little too early to go into the details of packet formats etc. > > > Agreed, but I do think the 6man working group has a vested interest to > make sure that network layer information stays in the network layer. > At some point the information needed is going to be so complex that it > won't be able to be conveyed in any fields of the IP header. > > Tom > > > Best regards, > > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Tue Oct 17 12:38:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7113292A for ; Tue, 17 Oct 2017 12:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jwtw_JNZSgt for ; Tue, 17 Oct 2017 12:38:46 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 01621133087 for ; Tue, 17 Oct 2017 12:38:45 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id y184so1030997pgd.12 for ; Tue, 17 Oct 2017 12:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CqKi/1ojUhtIzQn/+kLReitiSxJBaJ/UkqvYrgc5JwQ=; b=cXsNoIL8ZI4yMHGcsGTy9B1K9qAEU9J7dJIuM9PAOQ3QZ+N8vUj3WC0YmeXaGMWza7 iNMsJfG5yDWLQu9oPAqNsJPOYmjS0QdGZ1p1ea+aaU9Sg4jHAP0MV4AQI4sxKqZMaPz+ bI+tUzzpn32IYcjlG4Tz5nm6HXs5biUuqW8jUvWAzsaSaW0IThcl1mntAfhalFM8uCp1 qSszThbl4Z0CMlVMiJVrKahkOIgcUx727CTLUZ+g8MeV0Zy5jGBtos7X59//+L0GC+Sy nSwr3pOSymW5haSkzOg2VOlqElZJQ5+IY3zfohr26S+Hd5HawibRn2gE2noqdR3kyd84 zlOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CqKi/1ojUhtIzQn/+kLReitiSxJBaJ/UkqvYrgc5JwQ=; b=qABGC6qcYjRiVHvz8mmT0C0jWJfUD3EG4LiG+8sWtGTHnENKw1JNG/8nrhOXdigHSA 0zs/tBVI8ijiMfnetfM0fRCAcIB1pS82Nlj+9BKE1WnFmby2iOONhnosTF8mDxVkmLrs nxCq10c+7swxlqwj6dyYnYxIZMOnmcR635oKperRSQNT20NCdOsq9s5h7UdraZK+/Dkf QGwoO+vVRP5whKYXX9TFJg+AcBrVnTYL90J1bm3bPIK1gBZYy1OMRXStbPPVazHYaRMo gEGQbQFFG4e1E3BJswIoCRYOjt9o+er96ENXDlF2Jth9pa1kRaMzRaXNEukr9pJAPzn8 YuKw== X-Gm-Message-State: AMCzsaX2DJHoBACkloKkK32Z4QDaMOWQUJYiwanWoM0YVSNlwFNuqPUt 1D6OgRDWSMViieHxs6j+N+FkTA== X-Google-Smtp-Source: AOwi7QC7DdWWxxVB+rRl9IcwnAYl1G/R9HiAYL1mPjSoBRV55zjC8huRiuEL0hIaTovUyw7PG4oSmg== X-Received: by 10.84.215.9 with SMTP id k9mr12737745pli.284.1508269125036; Tue, 17 Oct 2017 12:38:45 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j68sm12181730pgc.6.2017.10.17.12.38.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 12:38:44 -0700 (PDT) Subject: Re: Loopback interface terminology issue To: "Templin, Fred L" , "ipv6@ietf.org" References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 18 Oct 2017 08:38:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:38:49 -0000 On 17/10/2017 12:15, Templin, Fred L wrote: > Brian, >=20 > Here is what it says in 'draft-templin-v6ops-pdhost': >=20 > "This document also considers the case when 'R' does not have any > downstream interfaces, and can use 'P' solely for its own internal > addressing purposes. In that case, 'R' assigns 'P' to a virtual > interface (e.g., a loopback) that fills the role of a downstream > interface. >=20 > 'R' can then function under the weak end system (aka "weak host") > model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a > virtual interface as shown in Figure 2:" >=20 > Internal virtual interfaces were also discussed in RFC5558. Well yes; indeed this topic is touched on in many RFCs but nowhere is it defined as part of the basic architecture, which is my main point. Using a concept that has no principal definition is generally a source of confusion. Brian >=20 > Thanks - Fred >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpent= er >> Sent: Monday, October 16, 2017 3:45 PM >> To: ipv6@ietf.org >> Subject: Re: Loopback interface terminology issue >> >> On 17/10/2017 07:49, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> At Mon, 16 Oct 2017 20:14:42 +0200, >>> Toerless Eckert wrote: >>> >>>>> I don't understand what this means, but in any case I agree with Ma= rk >>>>> that IMO this is more about the weak/strong host model than >>>>> forwarding/non-forwarding. >>>> >>>> ---etherB--- >>>> host --etherA-- rtr >>>> ---etherB--- >>>> | host/rtr | >>>> >>>> Think of a host with an etherA connecting to a router that also has >>>> etherB, etherC. Now we just integrate this router into the host and = etherthernetA >>>> becomes an internal interface, but the apps can still use this inter= face, >>>> and so it is permissible for both strong and weak host models to use= the IP >>>> address on etherA, whatever exernal ethernetB/ethernetC the packets = are >>>> sent/received through. >>>> >>>> The main difference between an internal ethernet and loopback in thi= s modelling >>>> is that when you send into a loopback interface, it does not need to= run ND to >>>> find the link-local address of the router interface and forward the = packet to it, >>>> but instead the packet is immediately processed by the router forwar= ding code. >>> >>> Okay, I think I now understand what you meant. Such a model seems to= >>> be quite a stretch convoluted or even artificial to me, but I wouldn'= t >>> necessarily deny possible existence of such implementations. But in >>> any event that seems to me quite a stretch from the situation Brian >>> originally raised. And, for these reasons, I personally wouldn't >>> support saying something in the addressing architecture that requires= >>> a specific model of integrated host-router architecture. More >>> specifically I disagree with adding to the addrarch doc: >>> >>> If other addresses beside "loopback addresses" are assigned to such= a link, >>> then the interface needs to be configured to forward non-self-desti= ned >>> packets originated from the loopback interface (see rfc8200, sectio= n 2). >>> >>> If it also notes that it's for a host that adopts the strong host >>> model or the node adopting the hybrid architecture you mentioned >>> above, I might live with it, although I personally think it's too muc= h >>> for the basic architecture document. >> >> Yes. I think the point that is lacking in the architecture is >> that unicast addresses that are not assigned to an operational >> physical or tunnel interface may be assigned to a virtual >> interface, which may be a loopback interface. >> >> All the rest is indeed implementation-dependent. >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Tue Oct 17 12:38:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F13413309D for ; Tue, 17 Oct 2017 12:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYiJqQDf_wZ3 for ; Tue, 17 Oct 2017 12:38:54 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB3C1330AF for ; Tue, 17 Oct 2017 12:38:54 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 1so6081475qtn.3 for ; Tue, 17 Oct 2017 12:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPxrTZAWdVk8cHPmji0Nz38A6e0aWhfNOp3qnnTJoII=; b=u5rEotfz/QokL47ov6bkl29WFpam0oCLDOh7JCW20tHxL+d38IIHXYtltw6lUnY62z sADZyUklOs4I6ZPUXt/FjQ9VA8sBhKFho5je1/HydWDpgRxqLsrAySDBwCOsPkLwBf2L AJH/PkbVvumsfSn7txkcSEifm1g4h1Ct9mC28or8mnvNzRAQmvWnDorkHf5p5B2NrOPF I4DZ0YCBilkPlUuB8qedsltzUYYnor/C2/FGFHfwTX5Tx6pF0pD00J8ZENvr3RjH2n9p o/HkG7fRzfPCI0eLYlAK1Wx1pw8Mt4DYuuqVHGyX/QiyKwCOZ8+mwQkFr8uVbv7NewfN 05Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TPxrTZAWdVk8cHPmji0Nz38A6e0aWhfNOp3qnnTJoII=; b=RDPeTG4sZWkQadr1wGOQZXoq5ZRCSRupxpcvg0oQTJ4wbj19PGKnQoxUO+w3GB5tw5 lYaOoVtjWS3KIZ/Z2n2sUcmRmZR43h/uUJ14dEtViHRbl7UreggDlfddT87dZckCXk2n oE9i0tdBIA8YaywuQnlewq3P2o5pXLW0dRFoUiuyESZ7j54Cd69v+88pVazbco3qF5Yw M5QSdjxonsGJwQR1cD/fwdEEmOX6DRipwp0K9X1u4Qx9z6iSrnAb/UDmgBHf8Aua1dKU F/5RgT/vAfAUsO1pqhXj4JQl2TYLBRn6H+UytJq2Vby5HUysYFb/OLp3mW/tlwtw5/97 CY9A== X-Gm-Message-State: AMCzsaVQiWK+xA6nRB2HYU4TJ5G5SB8vQ7JFbTUO6XIZVi1nILB/pHpd 4xuXDd4nxZKlLS2iFyEKgUiYXtD7lCPMGCf6H3GfJjz6 X-Google-Smtp-Source: AOwi7QC/YJAOhYuaWhj6iT852gg63jiHWxw7wmpjz9myJo10oxQuGVoH/aqDcNwWUv69OwXbAfy+XUO60fP7QZD6jyI= X-Received: by 10.237.49.46 with SMTP id 43mr21908965qtg.27.1508269133460; Tue, 17 Oct 2017 12:38:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 12:38:52 -0700 (PDT) In-Reply-To: <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Tue, 17 Oct 2017 12:38:52 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Toerless Eckert Cc: Ole Troan , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:38:56 -0000 On Tue, Oct 17, 2017 at 11:16 AM, Toerless Eckert wrote: > As mentioned in my prior mail: RSVP-IP deployments got killed by SPs that filtered > packets with router-alert because common network devices punted packets because of > the presence of router-alert. Instead of punting them because of presence of > RSVP-router-alert option. And of course you can blame IP multicast: every router > started to punt router-alert because of MLD (and of course us multicast folks > missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), > but no RFC told developers to punt because of router-alert + value in the router alert. > AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss > this issue. > > IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets > because of the presence of this mechanism, but only because of presence of > (mechanism,value) where value is intended to be supported by device. If the device > can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism > as if the option was not present. > > One simple way to do this is to define hop-by-hop-fixed that does say exactly this > and then hopefully allow all existing hop-by-hop TLV to live underneath that > fixed hop-by-hop-fixed option. But i would certainly suggest to review processing > complexity and extensibility before such a conclusion. > > Personally i prefer inband UDP layer signaling, not because i do not like IPv6 > option headers but because there is just no ubiquitous API to allow apps > independent of OS enhancements to set arbitrary options headers, especially ones The API does exist. OSes like Linux have implemented APIs described in RFC2292 and other common APIs. > that are not yet defined (allow apps to fully defined the whole header bit by bit). > Lets say from a javascript app in a browser. And i am more interested in ease of > adoption than in architectural cleanlyness. But of course its perfectly valid to > do the architectural clean appraoch and then prove me wrong and get that option > adopted more ;-)) It's not just about architectural cleanliness, it's about correctness. In the case that an intermediate node parses a UDP payload it is likely doing this based on the some common destination port number. Port numbers don't have global and persistent meaning (e.g. TCP port 80 does not always have to be HTTP) so this leads to the possibility of misinterpretation as described in RFC7605. If the node improperly writes data into the UDP payload and updates the checksum, then this becomes silent data corruption. Extension headers do not have this possibility of misinterpretation in the network. This potential misinterpretation of UDP ports and many other issues with trying to turn UDP into a network layer protocol were brought up in the SPUD/PLUS discussions. Tom From nobody Tue Oct 17 12:40:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E213308D for ; Tue, 17 Oct 2017 12:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pnhjewf03vk for ; Tue, 17 Oct 2017 12:40:35 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E4213292A for ; Tue, 17 Oct 2017 12:40:35 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id y7so2235746pgb.7 for ; Tue, 17 Oct 2017 12:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Z5ArSg31T0COvI1kZkrgsE1sNSZ64BYv1aERnQ9gA0c=; b=AYaqCJjLfARLtkFRYrG3hZvPMTkA5hea+BuBoyiHeavAjxljZQOdFWux7yGlri4NxU 48GIQ0JLUPyBNeotIPeF/dEQhOUXMFhMlWa+zBiTzbbMOhtL8jgXwRk+Uf2wyLbQVF0l RjBg3tBFOvmytHtymPpjoLWs1TrfXRbdq/rJcHPcMxAwyBRcwYOPVp649R53apysx6Jv 66k6iBUGe1ZEVGaxR9aeMRmOCgVz9Vy8o/X3L3Lc2uhXIQMgHBZBIGvx309ZrLwzIX5Q r5Ag7qmc7YGvk+flASFIg7IViBson68xjjodYBZAjvs1mvCVtFO9SVdEnD5+jfLa17n4 DLsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Z5ArSg31T0COvI1kZkrgsE1sNSZ64BYv1aERnQ9gA0c=; b=LwTsxTmRVEgDaBE4zQCBD+KgrxvH6uuvW8fgCT5jywf2Eet11kfzLa0sVUBRfn3AYV M0LlKMN4mtgG2IQCjB9iwNUMWjra520PVfXqsmKM1QjCyjFNQJ004pfACcjz0pgJDaJc 4vXM5pNCpe2l/QXMJjga4SZlnmh/4R3PKQtAlBM9u9PjC+wUhIYW4vmiZUexYoEP3Xqn c5IutNAXEpE/r4e/FBNBamSNJ47W9UqWJOdW+zj2FmUvyQjulJcoaSt/R6RnGWk69+AI xaG9ZQ4w6h6HUB35qMosW14DZbFQOArvk2Jtt+y5jeuziZEBm/lAx6KuA9Lk23d5vIN9 AOJg== X-Gm-Message-State: AMCzsaVfIvuSyVBgtwyN3ylrV2tjtkrQuGYtOdZfaezSb9xSfo5/mGFK hfAteKjsWwcfIeltwQI7ekvkCA== X-Google-Smtp-Source: ABhQp+Q5rMFf4gf2UNZG2h9MfAiOYMkxX3+HZjUzq1hG6IWj3AgyoxGf5Ld+X8AJ3L2/+gekP36fHA== X-Received: by 10.84.232.202 with SMTP id x10mr9021805plm.101.1508269234888; Tue, 17 Oct 2017 12:40:34 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 62sm19966372pfw.129.2017.10.17.12.40.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 12:40:34 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Ole Troan Cc: Lin Han , 6man WG References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5201440c-445c-4923-3460-86df7e1179da@gmail.com> Date: Wed, 18 Oct 2017 08:40:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:40:37 -0000 On 17/10/2017 20:11, Ole Troan wrote: >>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header, >> >> Yes, that is exactly what the paragraph from RFC8200 means: it >> says "New hop-by-hop options are not recommended". > > Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences. > > In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header. Of course. But that in itself isn't the strong justification that RFC8200 calls for, IMHO. Brian > > > Ole > From nobody Tue Oct 17 12:45:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CD133085 for ; Tue, 17 Oct 2017 12:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb9iumerF1YO for ; Tue, 17 Oct 2017 12:45:19 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C688E13292A for ; Tue, 17 Oct 2017 12:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9HJjHre046173; Tue, 17 Oct 2017 12:45:17 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9HJjGEt046168 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 17 Oct 2017 12:45:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Oct 2017 12:45:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 17 Oct 2017 12:45:15 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRtByPxn1iJZL+kqA+Ph9pp2qTaLnGukAgAHL5YD//4sDIA== Date: Tue, 17 Oct 2017 19:45:15 +0000 Message-ID: <91675feb9b804757b3373d44fb1312ae@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:45:21 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIE9jdG9iZXIgMTcsIDIwMTcgMTI6MzkgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IExvb3BiYWNrIGludGVyZmFjZSB0ZXJtaW5vbG9neSBpc3N1ZQ0KPiANCj4gT24gMTcvMTAv MjAxNyAxMjoxNSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IEJyaWFuLA0KPiA+DQo+ID4g SGVyZSBpcyB3aGF0IGl0IHNheXMgaW4gJ2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0JzoNCj4g Pg0KPiA+ICAgIlRoaXMgZG9jdW1lbnQgYWxzbyBjb25zaWRlcnMgdGhlIGNhc2Ugd2hlbiAnUicg ZG9lcyBub3QgaGF2ZSBhbnkNCj4gPiAgICBkb3duc3RyZWFtIGludGVyZmFjZXMsIGFuZCBjYW4g dXNlICdQJyBzb2xlbHkgZm9yIGl0cyBvd24gaW50ZXJuYWwNCj4gPiAgICBhZGRyZXNzaW5nIHB1 cnBvc2VzLiAgSW4gdGhhdCBjYXNlLCAnUicgYXNzaWducyAnUCcgdG8gYSB2aXJ0dWFsDQo+ID4g ICAgaW50ZXJmYWNlIChlLmcuLCBhIGxvb3BiYWNrKSB0aGF0IGZpbGxzIHRoZSByb2xlIG9mIGEg ZG93bnN0cmVhbQ0KPiA+ICAgIGludGVyZmFjZS4NCj4gPg0KPiA+ICAgICdSJyBjYW4gdGhlbiBm dW5jdGlvbiB1bmRlciB0aGUgd2VhayBlbmQgc3lzdGVtIChha2EgIndlYWsgaG9zdCIpDQo+ID4g ICAgbW9kZWwgW1JGQzExMjJdW1JGQzgwMjhdIGJ5IGFzc2lnbmluZyBhZGRyZXNzZXMgdGFrZW4g ZnJvbSAnUCcgdG8gYQ0KPiA+ICAgIHZpcnR1YWwgaW50ZXJmYWNlIGFzIHNob3duIGluIEZpZ3Vy ZSAyOiINCj4gPg0KPiA+IEludGVybmFsIHZpcnR1YWwgaW50ZXJmYWNlcyB3ZXJlIGFsc28gZGlz Y3Vzc2VkIGluIFJGQzU1NTguDQo+IA0KPiBXZWxsIHllczsgaW5kZWVkIHRoaXMgdG9waWMgaXMg dG91Y2hlZCBvbiBpbiBtYW55IFJGQ3MgYnV0DQo+IG5vd2hlcmUgaXMgaXQgZGVmaW5lZCBhcyBw YXJ0IG9mIHRoZSBiYXNpYyBhcmNoaXRlY3R1cmUsDQo+IHdoaWNoIGlzIG15IG1haW4gcG9pbnQu IFVzaW5nIGEgY29uY2VwdCB0aGF0IGhhcyBubyBwcmluY2lwYWwNCj4gZGVmaW5pdGlvbiBpcyBn ZW5lcmFsbHkgYSBzb3VyY2Ugb2YgY29uZnVzaW9uLg0KDQpJIGFncmVlIHRoYXQgaXQgaGFzIGJl ZW4gdG91Y2hlZCBvbiBpbiBtYW55IGVhcmxpZXIgd29ya3MsIGFsc28NCmluY2x1ZGluZyAnZHJh ZnQtdGVtcGxpbi1hZXJvbGluaycgYW5kIG1hbnkgb2YgbXkgcHVibGlzaGVkIFJGQ3MuDQoNCkJ1 dCwgSSBtdXN0IHNheSB0aGF0IGl0IG5vdyBhbHNvIGFwcGVhcnMgaW4gUkZDNzkzNCAoYSBCQ1Ap Lg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gICAgIEJyaWFuDQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0g RnJlZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGlw djYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENh cnBlbnRlcg0KPiA+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTYsIDIwMTcgMzo0NSBQTQ0KPiA+ PiBUbzogaXB2NkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogTG9vcGJhY2sgaW50ZXJmYWNl IHRlcm1pbm9sb2d5IGlzc3VlDQo+ID4+DQo+ID4+IE9uIDE3LzEwLzIwMTcgMDc6NDksIOelnuaY jumBlOWTiSB3cm90ZToNCj4gPj4+IEF0IE1vbiwgMTYgT2N0IDIwMTcgMjA6MTQ6NDIgKzAyMDAs DQo+ID4+PiBUb2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU+IHdyb3RlOg0KPiA+Pj4NCj4g Pj4+Pj4gSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBtZWFucywgYnV0IGluIGFueSBjYXNl IEkgYWdyZWUgd2l0aCBNYXJrDQo+ID4+Pj4+IHRoYXQgSU1PIHRoaXMgaXMgbW9yZSBhYm91dCB0 aGUgd2Vhay9zdHJvbmcgaG9zdCBtb2RlbCB0aGFuDQo+ID4+Pj4+IGZvcndhcmRpbmcvbm9uLWZv cndhcmRpbmcuDQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgLS0tZXRo ZXJCLS0tDQo+ID4+Pj4gICAgICAgaG9zdCAtLWV0aGVyQS0tIHJ0cg0KPiA+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAtLS1ldGhlckItLS0NCj4gPj4+PiAgICAgICB8ICAgaG9zdC9ydHIg ICAgIHwNCj4gPj4+Pg0KPiA+Pj4+IFRoaW5rIG9mIGEgaG9zdCB3aXRoIGFuIGV0aGVyQSBjb25u ZWN0aW5nIHRvIGEgcm91dGVyIHRoYXQgYWxzbyBoYXMNCj4gPj4+PiBldGhlckIsIGV0aGVyQy4g Tm93IHdlIGp1c3QgaW50ZWdyYXRlIHRoaXMgcm91dGVyIGludG8gdGhlIGhvc3QgYW5kIGV0aGVy dGhlcm5ldEENCj4gPj4+PiBiZWNvbWVzIGFuIGludGVybmFsIGludGVyZmFjZSwgYnV0IHRoZSBh cHBzIGNhbiBzdGlsbCB1c2UgdGhpcyBpbnRlcmZhY2UsDQo+ID4+Pj4gYW5kIHNvIGl0IGlzIHBl cm1pc3NpYmxlIGZvciBib3RoIHN0cm9uZyBhbmQgd2VhayBob3N0IG1vZGVscyB0byB1c2UgdGhl IElQDQo+ID4+Pj4gYWRkcmVzcyBvbiBldGhlckEsIHdoYXRldmVyIGV4ZXJuYWwgZXRoZXJuZXRC L2V0aGVybmV0QyB0aGUgcGFja2V0cyBhcmUNCj4gPj4+PiBzZW50L3JlY2VpdmVkIHRocm91Z2gu DQo+ID4+Pj4NCj4gPj4+PiBUaGUgbWFpbiBkaWZmZXJlbmNlIGJldHdlZW4gYW4gaW50ZXJuYWwg ZXRoZXJuZXQgYW5kIGxvb3BiYWNrIGluIHRoaXMgbW9kZWxsaW5nDQo+ID4+Pj4gaXMgdGhhdCB3 aGVuIHlvdSBzZW5kIGludG8gYSBsb29wYmFjayBpbnRlcmZhY2UsIGl0IGRvZXMgbm90IG5lZWQg dG8gcnVuIE5EIHRvDQo+ID4+Pj4gZmluZCB0aGUgbGluay1sb2NhbCBhZGRyZXNzIG9mIHRoZSBy b3V0ZXIgaW50ZXJmYWNlIGFuZCBmb3J3YXJkIHRoZSBwYWNrZXQgdG8gaXQsDQo+ID4+Pj4gYnV0 IGluc3RlYWQgdGhlIHBhY2tldCBpcyBpbW1lZGlhdGVseSBwcm9jZXNzZWQgYnkgdGhlIHJvdXRl ciBmb3J3YXJkaW5nIGNvZGUuDQo+ID4+Pg0KPiA+Pj4gT2theSwgSSB0aGluayBJIG5vdyB1bmRl cnN0YW5kIHdoYXQgeW91IG1lYW50LiAgU3VjaCBhIG1vZGVsIHNlZW1zIHRvDQo+ID4+PiBiZSBx dWl0ZSBhIHN0cmV0Y2ggY29udm9sdXRlZCBvciBldmVuIGFydGlmaWNpYWwgdG8gbWUsIGJ1dCBJ IHdvdWxkbid0DQo+ID4+PiBuZWNlc3NhcmlseSBkZW55IHBvc3NpYmxlIGV4aXN0ZW5jZSBvZiBz dWNoIGltcGxlbWVudGF0aW9ucy4gIEJ1dCBpbg0KPiA+Pj4gYW55IGV2ZW50IHRoYXQgc2VlbXMg dG8gbWUgcXVpdGUgYSBzdHJldGNoIGZyb20gdGhlIHNpdHVhdGlvbiBCcmlhbg0KPiA+Pj4gb3Jp Z2luYWxseSByYWlzZWQuICBBbmQsIGZvciB0aGVzZSByZWFzb25zLCBJIHBlcnNvbmFsbHkgd291 bGRuJ3QNCj4gPj4+IHN1cHBvcnQgc2F5aW5nIHNvbWV0aGluZyBpbiB0aGUgYWRkcmVzc2luZyBh cmNoaXRlY3R1cmUgdGhhdCByZXF1aXJlcw0KPiA+Pj4gYSBzcGVjaWZpYyBtb2RlbCBvZiBpbnRl Z3JhdGVkIGhvc3Qtcm91dGVyIGFyY2hpdGVjdHVyZS4gIE1vcmUNCj4gPj4+IHNwZWNpZmljYWxs eSBJIGRpc2FncmVlIHdpdGggYWRkaW5nIHRvIHRoZSBhZGRyYXJjaCBkb2M6DQo+ID4+Pg0KPiA+ Pj4gICBJZiBvdGhlciBhZGRyZXNzZXMgYmVzaWRlICJsb29wYmFjayBhZGRyZXNzZXMiIGFyZSBh c3NpZ25lZCB0byBzdWNoIGEgbGluaywNCj4gPj4+ICAgdGhlbiB0aGUgaW50ZXJmYWNlIG5lZWRz IHRvIGJlIGNvbmZpZ3VyZWQgdG8gZm9yd2FyZCBub24tc2VsZi1kZXN0aW5lZA0KPiA+Pj4gICBw YWNrZXRzIG9yaWdpbmF0ZWQgZnJvbSB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIChzZWUgcmZjODIw MCwgc2VjdGlvbiAyKS4NCj4gPj4+DQo+ID4+PiBJZiBpdCBhbHNvIG5vdGVzIHRoYXQgaXQncyBm b3IgYSBob3N0IHRoYXQgYWRvcHRzIHRoZSBzdHJvbmcgaG9zdA0KPiA+Pj4gbW9kZWwgb3IgdGhl IG5vZGUgYWRvcHRpbmcgdGhlIGh5YnJpZCBhcmNoaXRlY3R1cmUgeW91IG1lbnRpb25lZA0KPiA+ Pj4gYWJvdmUsIEkgbWlnaHQgbGl2ZSB3aXRoIGl0LCBhbHRob3VnaCBJIHBlcnNvbmFsbHkgdGhp bmsgaXQncyB0b28gbXVjaA0KPiA+Pj4gZm9yIHRoZSBiYXNpYyBhcmNoaXRlY3R1cmUgZG9jdW1l bnQuDQo+ID4+DQo+ID4+IFllcy4gSSB0aGluayB0aGUgcG9pbnQgdGhhdCBpcyBsYWNraW5nIGlu IHRoZSBhcmNoaXRlY3R1cmUgaXMNCj4gPj4gdGhhdCB1bmljYXN0IGFkZHJlc3NlcyB0aGF0IGFy ZSBub3QgYXNzaWduZWQgdG8gYW4gb3BlcmF0aW9uYWwNCj4gPj4gcGh5c2ljYWwgb3IgdHVubmVs IGludGVyZmFjZSBtYXkgYmUgYXNzaWduZWQgdG8gYSB2aXJ0dWFsDQo+ID4+IGludGVyZmFjZSwg d2hpY2ggbWF5IGJlIGEgbG9vcGJhY2sgaW50ZXJmYWNlLg0KPiA+Pg0KPiA+PiBBbGwgdGhlIHJl c3QgaXMgaW5kZWVkIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4NCj4gPj4NCj4gPj4gICAgIEJy aWFuDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KPiA+PiBpcHY2QGlldGYub3JnDQo+ID4+IEFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQoNCg== From nobody Tue Oct 17 12:57:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25579132705 for ; Tue, 17 Oct 2017 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc-E_Zr0uGOq for ; Tue, 17 Oct 2017 12:57:37 -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 2FC1E132355 for ; Tue, 17 Oct 2017 12:57:37 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e64so2114624pfk.9 for ; Tue, 17 Oct 2017 12:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=txyBk6zpWDjbzOydawvNe0FNvpwgVIWOp0K3/AdGykw=; b=RkDUkrjoHo+4apZSROcQ8MaGPqaI2H56f9fbn31KWePO8S9Ogrxb40EW2IOqVfwWOv qYBl9PZNFK9Mi8P3ItNX7cCPGwmcbkzUWu2BsyRQEhyXnYF2FLZGeMtHK59r+iNMPqAW pRr8fOeZF9T74kBj8jqLda2a+udhe3Q9XpPw8s7YbfX5ntLgioD6LsfszzAgazC5pIs6 vT7DRWSpvrCeED1qphy9YLtR+HyIDtlF95+ksV1E+6gJXtW3pe2o5dAiBAfeMjQ7sBi2 7AMVCoAtk4LgQtJjm4P9q3cum7PlHc8B3eT+9jg/9ILbTr9JjVw86l1UxQg/Dw38gffA 3Pug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=txyBk6zpWDjbzOydawvNe0FNvpwgVIWOp0K3/AdGykw=; b=ek7qOMuA9FXsiZaM7lzW/fMKTOkTgCkUw5SlbKJqU64Mf/Bxk377OekhwexamJEHnE QhaTDf6XQzzwsYI+lyU7R5muLtkFzyZ4W+ENY604x45N8BtxkV9Y7k+NVNJKW+ux+Qad CiGDpdTGCzun3+FidNi0TEjTYe7ptHAV3JluYZkZYx3rNqPnRi7+VFOK1qqEa4h2asxu 6tcGm2EJeT5rEkb6qfzGBRaffAaubtIY5SLx1mKCkqssqkxQDZUkvhQKGeduHiG03kx3 /gu/mIM4vXqA2fKLmezYqeM2nMJV+Fd+BKWNIadqcPemuC8gyUN2A6JB7NZldG/ScuIa c8Kg== X-Gm-Message-State: AMCzsaUcMy9leT5pgMGHRQ3jqAaHpMJiEoTXooeLO9S6n0Yb1jcVBx5n 8t4kSp2atxhgYIFk49X4IT76EQ== X-Google-Smtp-Source: AOwi7QBhP89XmNhj0p17kDinVIKBKJV2Gt8oi8Oo6Ohpw5iDOc7XSQMkSPaKe0l/GGIG0HnrQe1OKg== X-Received: by 10.99.51.6 with SMTP id z6mr11597648pgz.276.1508270256309; Tue, 17 Oct 2017 12:57:36 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c1sm20244160pfa.12.2017.10.17.12.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 12:57:35 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Toerless Eckert , Tom Herbert Cc: 6man WG References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 18 Oct 2017 08:57:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:57:39 -0000 On 18/10/2017 07:16, Toerless Eckert wrote: > As mentioned in my prior mail: RSVP-IP deployments got killed by SPs that filtered > packets with router-alert because common network devices punted packets because of > the presence of router-alert. Router alert in IPv6 *is* a hop-by-hop option [RFC2711], so the code path for this proposal starts exactly the same as the code path for processing an RSVP message. > Instead of punting them because of presence of > RSVP-router-alert option. And of course you can blame IP multicast: every router > started to punt router-alert because of MLD (and of course us multicast folks > missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), > but no RFC told developers to punt because of router-alert + value in the router alert. > AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss > this issue. > > IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets > because of the presence of this mechanism, but only because of presence of > (mechanism,value) where value is intended to be supported by device. If the device > can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism > as if the option was not present. That's pretty much what RFC7045/RC8200 say, except that they say it as a warning. As Ole said - within a domain where hop-by-hop option X is supported, you can reasonably expect that all routers process X. But (excuse me repeating myself), whether X is worth doing is not really a question for 6man. In this case, it belongs where QoS is discussed, which is TSVWG. Brian > One simple way to do this is to define hop-by-hop-fixed that does say exactly this > and then hopefully allow all existing hop-by-hop TLV to live underneath that > fixed hop-by-hop-fixed option. But i would certainly suggest to review processing > complexity and extensibility before such a conclusion. > > Personally i prefer inband UDP layer signaling, not because i do not like IPv6 > option headers but because there is just no ubiquitous API to allow apps > independent of OS enhancements to set arbitrary options headers, especially ones > that are not yet defined (allow apps to fully defined the whole header bit by bit). > Lets say from a javascript app in a browser. And i am more interested in ease of > adoption than in architectural cleanlyness. But of course its perfectly valid to > do the architectural clean appraoch and then prove me wrong and get that option > adopted more ;-)) > > Cheers > Toerless > > On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: >> On one hand, IETF defined extension headers as the extensibility >> mechanism of IPv6, but yet on the other hand the message seems to be >> to not use them because deployed devices don't correctly support the >> protocol. The upshot is that we see proposals in other WGs of stuffing >> network layer information into transport protocols (options or >> payloads) with the full expectation that intermediate nodes will parse >> into the transport layer, process the embedded information, and >> possibly even overwrite transport layer information. IMO that is an >> architectural abomination and further abandonment of the end to end >> model! >> >>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. >>> And it might be a little too early to go into the details of packet formats etc. >>> >> Agreed, but I do think the 6man working group has a vested interest to >> make sure that network layer information stays in the network layer. >> At some point the information needed is going to be so complex that it >> won't be able to be conveyed in any fields of the IP header. >> >> Tom >> >>> Best regards, >>> Ole >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Tue Oct 17 13:16:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF6013302A for ; Tue, 17 Oct 2017 13:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQZhbtIk88WR for ; Tue, 17 Oct 2017 13:16:43 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A452132355 for ; Tue, 17 Oct 2017 13:16:43 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id z19so6280203qtg.11 for ; Tue, 17 Oct 2017 13:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3nIEWLiYudkIMl82bKVvKn2QN3Tol4fVm3dWkzT+dF8=; b=hRgUAHd7/3xnlN25M+LwH02bQkZAMTOpWstF0/zXhCUt6zggCJZYMCOAzbqOQd9onT mBZW5wbLeCG/X52BBgHSZgYCLb/vt1b8wtt1T5mouDIA79yfk1mKS0OQCBO9zhzQLiv1 iLejPKV0L5JroGwjQ5qS1NRloPcEMOQiv+5grZXnsAlFQ+MglRFrXmafjlS5UZOmr6gK YM4n54LVbl6deAKGQzCvPUuqWPnSjOmXEBZUlbdS53+D57Vpv8fkB3lRa5vXy0Cj+5il OErOT3Y3H4wP9VERA/29GagAn5IsTqoqIawtL6PNHUXPiCuVb8q+HJg7TfuckzIqaEcp EI2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3nIEWLiYudkIMl82bKVvKn2QN3Tol4fVm3dWkzT+dF8=; b=QDbkKHHIdI02DFtQIhTPVtE3p0q/LsU86z1EYDaOMofuA3Q9C2C0QzFvk+1rGMLaEc 0q6EjzruaDGMUb0SpzSRBqEX2qhH+pQ/Px86d8L1wdCudjXNWphEwC0R/VsjGAag/6l8 YqyB2jOUPisF7pJBqYERmwbZn60jjMl1noorjSyDz/56FFzi1nv4Vta5cIWX8XpaM8+b 67NSOAKrU8LfkWyAQoh1v0WBZCtL/Cc4w7Rb6zfpcO3mRTd+OE7pC2Q6CII5SiyY7IXq U7zVgxcG9WUWBDoFeLhu5N8pXnom6veiRQcY+pe7CWkh9ecsst/pL/YaZz51nj2+ivYG 1E+A== X-Gm-Message-State: AMCzsaXklkwjZ26RoZCF/wSp20iqkUINx0Fz8UiOklDe23uBg8iYBT0K B9V5toK7SFJYU1Z/c6rgZEJTShJgPrBMgmyDJub4fw== X-Google-Smtp-Source: AOwi7QDkb+hv2izhKq8VsN6KgJoEDZJmb5/mmbi2jQZfpeMrvb5TbC5hfvlQFKMdjbVYT5fewwLVGh4G4Xza6NIkiU0= X-Received: by 10.200.53.89 with SMTP id z25mr22206315qtb.58.1508271402114; Tue, 17 Oct 2017 13:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 13:16:41 -0700 (PDT) In-Reply-To: <5201440c-445c-4923-3460-86df7e1179da@gmail.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <5201440c-445c-4923-3460-86df7e1179da@gmail.com> From: Tom Herbert Date: Tue, 17 Oct 2017 13:16:41 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Brian E Carpenter Cc: Ole Troan , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 20:16:44 -0000 On Tue, Oct 17, 2017 at 12:40 PM, Brian E Carpenter wrote: > On 17/10/2017 20:11, Ole Troan wrote: >>>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header, >>> >>> Yes, that is exactly what the paragraph from RFC8200 means: it >>> says "New hop-by-hop options are not recommended". >> >> Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences. >> >> In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header. > > Of course. But that in itself isn't the strong justification that > RFC8200 calls for, IMHO. > I believe an experimental HbH option number could be use to develop the protocol and help provide the justification if an assignment is needed. Tom From nobody Tue Oct 17 14:38:24 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED641330AD for ; Tue, 17 Oct 2017 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 58P-Vy5WhxwN for ; Tue, 17 Oct 2017 14:38:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218FF13209C for ; Tue, 17 Oct 2017 14:38:21 -0700 (PDT) Received: from mbp-4.local ([IPv6:2601:647:4201:9721:3191:897a:4f32:a2e3]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v9HLcIZt064071 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Oct 2017 21:38:18 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9721:3191:897a:4f32:a2e3] claimed to be mbp-4.local Subject: Re: Loopback interface terminology issue To: Brian E Carpenter , "Templin, Fred L" , "ipv6@ietf.org" References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> From: joel jaeggli Message-ID: Date: Tue, 17 Oct 2017 14:38:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2h8Lm6Vvv7aSeuVmgWBXXIvoqibjKrvwu" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 21:38:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2h8Lm6Vvv7aSeuVmgWBXXIvoqibjKrvwu Content-Type: multipart/mixed; boundary="OOH4d4hlP7ofurGhgWEvBLcq5COCEi9de"; protected-headers="v1" From: joel jaeggli To: Brian E Carpenter , "Templin, Fred L" , "ipv6@ietf.org" Message-ID: Subject: Re: Loopback interface terminology issue References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: --OOH4d4hlP7ofurGhgWEvBLcq5COCEi9de Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 10/17/17 12:38, Brian E Carpenter wrote: > On 17/10/2017 12:15, Templin, Fred L wrote: >> Brian, >> >> Here is what it says in 'draft-templin-v6ops-pdhost': >> >> "This document also considers the case when 'R' does not have any >> downstream interfaces, and can use 'P' solely for its own internal >> addressing purposes. In that case, 'R' assigns 'P' to a virtual >> interface (e.g., a loopback) that fills the role of a downstream >> interface. >> >> 'R' can then function under the weak end system (aka "weak host") >> model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a= >> virtual interface as shown in Figure 2:" >> >> Internal virtual interfaces were also discussed in RFC5558. > Well yes; indeed this topic is touched on in many RFCs but > nowhere is it defined as part of the basic architecture, > which is my main point. Using a concept that has no principal > definition is generally a source of confusion. We tended not to define software interfaces for things which are not required for interoperability. How you describe an address which is not bound to a physical interface is entirely irrelevant outside the scope of your own operating system. > > Brian > >> Thanks - Fred >> >>> -----Original Message----- >>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpen= ter >>> Sent: Monday, October 16, 2017 3:45 PM >>> To: ipv6@ietf.org >>> Subject: Re: Loopback interface terminology issue >>> >>> On 17/10/2017 07:49, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>> At Mon, 16 Oct 2017 20:14:42 +0200, >>>> Toerless Eckert wrote: >>>> >>>>>> I don't understand what this means, but in any case I agree with M= ark >>>>>> that IMO this is more about the weak/strong host model than >>>>>> forwarding/non-forwarding. >>>>> ---etherB--- >>>>> host --etherA-- rtr >>>>> ---etherB--- >>>>> | host/rtr | >>>>> >>>>> Think of a host with an etherA connecting to a router that also has= >>>>> etherB, etherC. Now we just integrate this router into the host and= etherthernetA >>>>> becomes an internal interface, but the apps can still use this inte= rface, >>>>> and so it is permissible for both strong and weak host models to us= e the IP >>>>> address on etherA, whatever exernal ethernetB/ethernetC the packets= are >>>>> sent/received through. >>>>> >>>>> The main difference between an internal ethernet and loopback in th= is modelling >>>>> is that when you send into a loopback interface, it does not need t= o run ND to >>>>> find the link-local address of the router interface and forward the= packet to it, >>>>> but instead the packet is immediately processed by the router forwa= rding code. >>>> Okay, I think I now understand what you meant. Such a model seems t= o >>>> be quite a stretch convoluted or even artificial to me, but I wouldn= 't >>>> necessarily deny possible existence of such implementations. But in= >>>> any event that seems to me quite a stretch from the situation Brian >>>> originally raised. And, for these reasons, I personally wouldn't >>>> support saying something in the addressing architecture that require= s >>>> a specific model of integrated host-router architecture. More >>>> specifically I disagree with adding to the addrarch doc: >>>> >>>> If other addresses beside "loopback addresses" are assigned to suc= h a link, >>>> then the interface needs to be configured to forward non-self-dest= ined >>>> packets originated from the loopback interface (see rfc8200, secti= on 2). >>>> >>>> If it also notes that it's for a host that adopts the strong host >>>> model or the node adopting the hybrid architecture you mentioned >>>> above, I might live with it, although I personally think it's too mu= ch >>>> for the basic architecture document. >>> Yes. I think the point that is lacking in the architecture is >>> that unicast addresses that are not assigned to an operational >>> physical or tunnel interface may be assigned to a virtual >>> interface, which may be a loopback interface. >>> >>> All the rest is indeed implementation-dependent. >>> >>> 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 > -------------------------------------------------------------------- > --OOH4d4hlP7ofurGhgWEvBLcq5COCEi9de-- --2h8Lm6Vvv7aSeuVmgWBXXIvoqibjKrvwu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlnmeEoACgkQ8AA1q7Z/VrICMACfSJzhKEqc683YCrr40xMzC3Hy TEkAnRPJQa2EpNgaD3aCbne2To1t60di =YXvy -----END PGP SIGNATURE----- --2h8Lm6Vvv7aSeuVmgWBXXIvoqibjKrvwu-- From nobody Tue Oct 17 17:27:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4887C1331C2 for ; Tue, 17 Oct 2017 17:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrO44wG-z5qd for ; Tue, 17 Oct 2017 17:27:12 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7DC1270AE for ; Tue, 17 Oct 2017 17:27:12 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id y7so2785022pgb.7 for ; Tue, 17 Oct 2017 17:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0ox0ESb87AQ9FoCSaG18x5EL34N5CQ5adrtXkXhEAj8=; b=DjexwfqReOnoo26GBO8/YL4fJgf8UvksKiZfjiS55N+kIohQU8jaWWhmUS6GIaHqK2 qV5JwHH7IvkGvK4+j7GH2nlJxmbKlXMxSgaG04DbdpBAf+U8piauWifFOzs63uQLhbL3 rSxagqklpO6yPh9tEQZwMA0FvcLVmXKpejCIoi9jBWQ02jNcj/l+BNOIZXx5XEJmKkI6 dOdKdwXynxwvZUbtTVv8KAqZ0BLb2M2kzDbSE8bzlR9KQJ8tfYYOKSvM+Z1hciiwHiTA gb+s1q27DuEabbCK/HYC9iAHwM4u9DNYXdgkfDU8bBu1J273sU9uXOyGWpyoFfnphGhO zIIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0ox0ESb87AQ9FoCSaG18x5EL34N5CQ5adrtXkXhEAj8=; b=LRv/uaaSe1e8uyLyy8jgcUn5yltGdSjGzudDMzgAsOMWJ3In7t4AyjDUfO+wNP1P4s /LGO/Utpc25ef6qtIpz8TtFcpKaNyBaVKyBbuz+KwtBoybMkvYo68NQrzI/npm4ucWmc ZmnTIyMOOXfhtMRU+wha6BOHfqutjmVmej7JkS+qEJiHe9Pdzih7L7TdR7iyPmTD7HId UUtWIGUvPJ/SpIje68Uuno9SE2jEi+JNLcR4eWzEZmGQ0hOk8tvBcDq0jKRhn9WuO62e OO0iitrqmw9eO/ClFhvCHPf04taxL8lhoajyNmiBdG5a5BD5kfeUJPlu7e3oBPTNEgsU Jciw== X-Gm-Message-State: AMCzsaV7T4+swTO5oaaLuWPN1KNKOux7N5CMtwm2GYRSoNDBwax6OMr9 fzkRKiwJCUDkupG5Ee/ch2StVw== X-Google-Smtp-Source: AOwi7QDhpv7fUEMO0NkwAQMyeNj5+ULU8vAivVaLSB/Xn6lfd+01qIgKIsPfGE+7ezqSx9ATB0R/sQ== X-Received: by 10.159.244.133 with SMTP id y5mr13343072plr.193.1508286431494; Tue, 17 Oct 2017 17:27:11 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u186sm18415447pgb.84.2017.10.17.17.27.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 17:27:10 -0700 (PDT) Subject: Re: Loopback interface terminology issue To: joel jaeggli , "Templin, Fred L" , "ipv6@ietf.org" References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> Date: Wed, 18 Oct 2017 13:27:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 00:27:14 -0000 On 18/10/2017 10:38, joel jaeggli wrote: > On 10/17/17 12:38, Brian E Carpenter wrote: >> On 17/10/2017 12:15, Templin, Fred L wrote: >>> Brian, >>> >>> Here is what it says in 'draft-templin-v6ops-pdhost': >>> >>> "This document also considers the case when 'R' does not have any >>> downstream interfaces, and can use 'P' solely for its own internal= >>> addressing purposes. In that case, 'R' assigns 'P' to a virtual >>> interface (e.g., a loopback) that fills the role of a downstream >>> interface. >>> >>> 'R' can then function under the weak end system (aka "weak host") >>> model [RFC1122][RFC8028] by assigning addresses taken from 'P' to = a >>> virtual interface as shown in Figure 2:" >>> >>> Internal virtual interfaces were also discussed in RFC5558. >> Well yes; indeed this topic is touched on in many RFCs but >> nowhere is it defined as part of the basic architecture, >> which is my main point. Using a concept that has no principal >> definition is generally a source of confusion. > We tended not to define software interfaces for things which are not > required for interoperability. How you describe an address which is not= > bound to a physical interface is entirely irrelevant outside the scope > of your own operating system. That's not our experience in trying to be precise in saying what we mean in draft-ietf-anima-autonomic-control-plane. Brian >=20 >> >> Brian >> >>> Thanks - Fred >>> >>>> -----Original Message----- >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpe= nter >>>> Sent: Monday, October 16, 2017 3:45 PM >>>> To: ipv6@ietf.org >>>> Subject: Re: Loopback interface terminology issue >>>> >>>> On 17/10/2017 07:49, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>>>> At Mon, 16 Oct 2017 20:14:42 +0200, >>>>> Toerless Eckert wrote: >>>>> >>>>>>> I don't understand what this means, but in any case I agree with = Mark >>>>>>> that IMO this is more about the weak/strong host model than >>>>>>> forwarding/non-forwarding. >>>>>> ---etherB--- >>>>>> host --etherA-- rtr >>>>>> ---etherB--- >>>>>> | host/rtr | >>>>>> >>>>>> Think of a host with an etherA connecting to a router that also ha= s >>>>>> etherB, etherC. Now we just integrate this router into the host an= d etherthernetA >>>>>> becomes an internal interface, but the apps can still use this int= erface, >>>>>> and so it is permissible for both strong and weak host models to u= se the IP >>>>>> address on etherA, whatever exernal ethernetB/ethernetC the packet= s are >>>>>> sent/received through. >>>>>> >>>>>> The main difference between an internal ethernet and loopback in t= his modelling >>>>>> is that when you send into a loopback interface, it does not need = to run ND to >>>>>> find the link-local address of the router interface and forward th= e packet to it, >>>>>> but instead the packet is immediately processed by the router forw= arding code. >>>>> Okay, I think I now understand what you meant. Such a model seems = to >>>>> be quite a stretch convoluted or even artificial to me, but I would= n't >>>>> necessarily deny possible existence of such implementations. But i= n >>>>> any event that seems to me quite a stretch from the situation Brian= >>>>> originally raised. And, for these reasons, I personally wouldn't >>>>> support saying something in the addressing architecture that requir= es >>>>> a specific model of integrated host-router architecture. More >>>>> specifically I disagree with adding to the addrarch doc: >>>>> >>>>> If other addresses beside "loopback addresses" are assigned to su= ch a link, >>>>> then the interface needs to be configured to forward non-self-des= tined >>>>> packets originated from the loopback interface (see rfc8200, sect= ion 2). >>>>> >>>>> If it also notes that it's for a host that adopts the strong host >>>>> model or the node adopting the hybrid architecture you mentioned >>>>> above, I might live with it, although I personally think it's too m= uch >>>>> for the basic architecture document. >>>> Yes. I think the point that is lacking in the architecture is >>>> that unicast addresses that are not assigned to an operational >>>> physical or tunnel interface may be assigned to a virtual >>>> interface, which may be a loopback interface. >>>> >>>> All the rest is indeed implementation-dependent. >>>> >>>> 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 >> -------------------------------------------------------------------- >> >=20 >=20 From nobody Wed Oct 18 09:44:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADD132C2A for ; Wed, 18 Oct 2017 09:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRZjlkkfnDDC for ; Wed, 18 Oct 2017 09:44:10 -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 EEF061321CB for ; Wed, 18 Oct 2017 09:44:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E581020095 for ; Wed, 18 Oct 2017 12:44:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0795280D36 for ; Wed, 18 Oct 2017 12:44:09 -0400 (EDT) From: Michael Richardson To: "ipv6\@ietf.org" Subject: Re: Loopback interface terminology issue In-Reply-To: <91675feb9b804757b3373d44fb1312ae@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <91675feb9b804757b3373d44fb1312ae@XCH15-06-08.nw.nos.boeing.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:44:11 -0000 --=-=-= Content-Type: text/plain Templin, Fred L wrote: >> On 17/10/2017 12:15, Templin, Fred L wrote: > Brian, >> > >> > Here is what it says in 'draft-templin-v6ops-pdhost': >> > >> > "This document also considers the case when 'R' does not have any > >> downstream interfaces, and can use 'P' solely for its own internal > >> addressing purposes. In that case, 'R' assigns 'P' to a virtual > >> interface (e.g., a loopback) that fills the role of a downstream > >> interface. >> > >> > 'R' can then function under the weak end system (aka "weak host") > >> model [RFC1122][RFC8028] by assigning addresses taken from 'P' to a > >> virtual interface as shown in Figure 2:" >> > >> > Internal virtual interfaces were also discussed in RFC5558. >> >> Well yes; indeed this topic is touched on in many RFCs but nowhere is >> it defined as part of the basic architecture, which is my main >> point. Using a concept that has no principal definition is generally a >> source of confusion. > I agree that it has been touched on in many earlier works, also > including 'draft-templin-aerolink' and many of my published RFCs. > But, I must say that it now also appears in RFC7934 (a BCP). I scanned RFC7934, and it too would have benefitted from some canonical text to explain non-loopback addresses on (virtual) loopback interfaces. The two questions that Brian has are, I think: 1) how can we best explain this in a way that takes what has been a (multi-decade old) operational BCP, and makes it clear that it's a standard mechanism? 2) where would we put this text, such that if we were to write a short document, what would we "Updates" I'm thinking that an update to RFC8028 would make sense, and that the scope/title of an 8028bis might change slightly as a result such text, because maybe all hosts actually live in a multi-prefix networks... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnnhNgACgkQgItw+93Q 3WWpowf8D+Q76QUC6A+5y29wci7OVFp8VA1g33JhJqHvyc3kabnJufsZuP+IJcjT IHcro3dMkGBnAPVWBXPPnp4QdcZJabHpv9q3I0PV/g3UonCI6hv8M1tOket0SnVp wH6VQxxL7HEawyBSLKU6agMBXg7eAEXmgaICGq4hApFExeF+WvqwHpmY97c5+aiP 8Duv/52VacVubZCD1TkEW4jKh9ycuj6R6mVTOcNIcdGRrsRNb9IpQH2N6AS9TkIh ZTABIxubNSMlGytha9KSeUbfV36Bl4GfjvGX/osU/pG4vhJ4fdpRmGzJn4bL+Qx+ hRhZPKk3NUCzlone7VRRRSyCETRxhw== =R0qa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 18 09:52:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F011321CB for ; Wed, 18 Oct 2017 09:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnCxhVxvyt4D for ; Wed, 18 Oct 2017 09:52:09 -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 68E6D13421B for ; Wed, 18 Oct 2017 09:52:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7023020095 for ; Wed, 18 Oct 2017 12:52:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6BC6F80D36 for ; Wed, 18 Oct 2017 12:52:08 -0400 (EDT) From: Michael Richardson To: "ipv6\@ietf.org" Subject: Re: Loopback interface terminology issue In-Reply-To: <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:52:11 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: brian> Well yes; indeed this topic is touched on in many RFCs but nowhere is brian> it defined as part of the basic architecture, which is my main brian> point. Using a concept that has no principal definition is generally brian> a source of confusion. joel> We tended not to define software interfaces for things which are not joel> required for interoperability. How you describe an address which is joel> not bound to a physical interface is entirely irrelevant outside the joel> scope of your own operating system. brian> That's not our experience in trying to be precise in saying what we brian> mean in draft-ietf-anima-autonomic-control-plane. to restate Brian's point slightly differently: The issue is not to tell people how to implement things in their software, but rather to make it clear that we need a standard hook on which to hang our addresses. We'd rather not use the term "loopback interface" at all here if we had another name defined in an RFC somewhere. I think that there is some significant text that might need to be written when defining this hook when in a strong-host model. But, let me also ask a different question: are there router operating systems where there is a way to hang an address on something which is not a virtual/loopback interface? If so, what do they call it? If there are differences in software interfaces in some place that we would be respecting by abstracting this requirement? After 35+ years of router operating systems, has anyone actually innovated in this way? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnnhrcACgkQgItw+93Q 3WWX5AgAnIAPSPD3EbMmumogkBctdZXXvrRQjqMMeOGwCsFDKUk70D2sQfpP3vQb 5U84jct3kvvFRMWL9+zfO2zmaCpemWo0qjwUBol+6Emrfii5X+2CTVw1nPKWS+t7 HI5QpqBC1o3H73niew/hMO7KYuOPUcGQw1CE76+ckJR4oC7L81boMQZKLnsWOOp6 JhPdNR+VukC+XiAeQgLkIjK9KvZz0q5kUkprNvETiVr7u7khT+1eqx+C4zLRQ/gg OSXaCkpuHXCs2RVduj/0qsE61xqEGTlR2yE2+gGZCY8kc4u50XCKSghHTygZzpSD xA/bijx2tSBAqiyMzZafrKB10yY2oQ== =lPHh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 18 09:57:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5246F1321CB for ; Wed, 18 Oct 2017 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnIH0DQdwtgc for ; Wed, 18 Oct 2017 09:57:42 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAE7132031 for ; Wed, 18 Oct 2017 09:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9IGvfZl044372; Wed, 18 Oct 2017 09:57:41 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9IGvcWf044248 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 18 Oct 2017 09:57:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 18 Oct 2017 09:57:37 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 18 Oct 2017 09:57:37 -0700 From: "Templin, Fred L" To: Michael Richardson , "ipv6@ietf.org" Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRtByPxn1iJZL+kqA+Ph9pp2qTaLnGukAgAHL5YD//4sDIIAB1okA//+L48A= Date: Wed, 18 Oct 2017 16:57:37 +0000 Message-ID: <77b1027d7f7f41bea48f8a77073e2bcd@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <91675feb9b804757b3373d44fb1312ae@XCH15-06-08.nw.nos.boeing.com> <436.1508345048@obiwan.sandelman.ca> In-Reply-To: <436.1508345048@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 16:57:44 -0000 Hi Michael, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Wednesday, October 18, 2017 9:44 AM > To: ipv6@ietf.org > Subject: Re: Loopback interface terminology issue >=20 >=20 > Templin, Fred L wrote: > >> On 17/10/2017 12:15, Templin, Fred L wrote: > Brian, > >> > > >> > Here is what it says in 'draft-templin-v6ops-pdhost': > >> > > >> > "This document also considers the case when 'R' does not have an= y > > >> downstream interfaces, and can use 'P' solely for its own internal= > > >> addressing purposes. In that case, 'R' assigns 'P' to a virtual > > >> interface (e.g., a loopback) that fills the role of a downstream > > >> interface. > >> > > >> > 'R' can then function under the weak end system (aka "weak host"= ) > > >> model [RFC1122][RFC8028] by assigning addresses taken from 'P' to = a > > >> virtual interface as shown in Figure 2:" > >> > > >> > Internal virtual interfaces were also discussed in RFC5558. > >> > >> Well yes; indeed this topic is touched on in many RFCs but nowhere= is > >> it defined as part of the basic architecture, which is my main > >> point. Using a concept that has no principal definition is general= ly a > >> source of confusion. >=20 > > I agree that it has been touched on in many earlier works, also > > including 'draft-templin-aerolink' and many of my published RFCs. >=20 > > But, I must say that it now also appears in RFC7934 (a BCP). >=20 > I scanned RFC7934, and it too would have benefitted from some > canonical text to explain non-loopback addresses on (virtual) loopback > interfaces. >=20 > The two questions that Brian has are, I think: >=20 > 1) how can we best explain this in a way that takes what has been a > (multi-decade old) operational BCP, and makes it clear that it's a > standard mechanism? >=20 > 2) where would we put this text, such that if we were to write a short > document, what would we "Updates" >=20 > I'm thinking that an update to RFC8028 would make sense, and that > the scope/title of an 8028bis might change slightly as a result such t= ext, > because maybe all hosts actually live in a multi-prefix networks... Non-loopback addresses that would be assigned to a loopback interface would have to come from a delegated IPv6 prefix. Please see 'draft-templin-v6ops-= pdhost' for procedures of how to assign addresses from a delegated prefix to a loop= back or other virtual interface: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ This document stems from my earlier works including RFC5558, RFC6179 and 'draft-templin-aerolink' which talk about assigning delegated prefixes to internal virtual interfaces such as loopbacks. But, the 'pdhost' draft i= s still open for edits - should it be made standards-track? Thanks - Fred > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Oct 18 19:11:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B528C13304B for ; Wed, 18 Oct 2017 19:11:38 -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 1ErCequUdiSK for ; Wed, 18 Oct 2017 19:11:36 -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 8120313301C for ; Wed, 18 Oct 2017 19:11:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AB83D200E0; Wed, 18 Oct 2017 22:11:42 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 70BBF80D36; Wed, 18 Oct 2017 22:11:35 -0400 (EDT) From: Michael Richardson To: "Templin\, Fred L" cc: "ipv6\@ietf.org" Subject: Re: Loopback interface terminology issue In-Reply-To: <77b1027d7f7f41bea48f8a77073e2bcd@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <91675feb9b804757b3373d44fb1312ae@XCH15-06-08.nw.nos.boeing.com> <436.1508345048@obiwan.sandelman.ca> <77b1027d7f7f41bea48f8a77073e2bcd@XCH15-06-08.nw.nos.boeing.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 02:11:39 -0000 --=-=-= Content-Type: text/plain Templin, Fred L wrote: > Hi Michael, hi, I was beginning to think that your emails were just trolls to get us to read your documents :-) mcr> I'm thinking that an update to RFC8028 would make sense, and that the mcr> scope/title of an 8028bis might change slightly as a result such text, mcr> because maybe all hosts actually live in a multi-prefix networks... > Non-loopback addresses that would be assigned to a loopback interface > would have to come from a delegated IPv6 prefix. Please see > 'draft-templin-v6ops-pdhost' for procedures of how to assign addresses > from a delegated prefix to a loopback or other virtual interface: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > This document stems from my earlier works including RFC5558, RFC6179 > and 'draft-templin-aerolink' which talk about assigning delegated > prefixes to internal virtual interfaces such as loopbacks. But, the > 'pdhost' draft is still open for edits - should it be made > standards-track? okay, so I read the document. I got to the end of section 1, thinking I had reached the end of a nice short document, because it seemed like the problem was described and a solution described in the Introduction. I was going to write: if we had a canonical document that explained how virtual interfaces could be used to hand addresses on, then your document could be even shorter. Then I got to the other sections, where (I was reading rather quickly while eating) you go on to explain the various ways in which these virtual interface interact with (or do not interact with) the pieces of the IPv6 architecture. It was only then that I understood why you felt that this document could perhaps grow to be about loopback/virtual interfaces. So, if we took a small part of your Introduction, and the rest of the document, then I agree, we might have the "Virtual Interfaces in IPv6" document that we all want. Then your current document would be renamed: "Solving the IPv6 Prefix Delegation for Hosts using Virtual Interfaces" and would be only those nice diagrams you have in section 1. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlnoCdcACgkQgItw+93Q 3WX+hQf/YEIilAat6t6+IZ8J/LmWH+/nkNadYg4FW+fbkwIXHReF7nYvXAckj8Wl UhbJkQz+AbH1udVcIQhnPDV+k5Kqu5V70+Y4I+CK42EzWOesQEpPgR/wQe8xv4IT L7bY1QraoviJgmycNCz+0UfQ0gaUwce1VbYFMV8UgikUnpulvhiONVbQPoeHNWld wBgyMcgkUwB/MV32dwWctc3lrd1DA6VS4h/uUDBuEG2jE1sU72oWehJ45PoztqmW FCdytFHAOF2wq/4+SNpUsrIBWf6tqy1TFct1oNZDfBBoau+5rvwg+YmtPS8FR20F VwwBPlPlpV6vIN96LUyTzpoxMCnnnA== =w9bu -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 19 09:54:07 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F11F13420E for ; Thu, 19 Oct 2017 09:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxT9_jH3drQm for ; Thu, 19 Oct 2017 09:54:03 -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 D8E14132CE7 for ; Thu, 19 Oct 2017 09:54:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYB62313; Thu, 19 Oct 2017 16:53:59 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Oct 2017 17:53:58 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Thu, 19 Oct 2017 09:53:51 -0700 From: Lin Han To: Brian E Carpenter , Toerless Eckert , Tom Herbert CC: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTRJJxnUgwu2qqQUiZZRbG4Yh0Q6LnHDEwgADKFoCAADQaAIAAYOmegALw7IA= Date: Thu, 19 Oct 2017 16:53:51 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD75EAA@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59E8D8A8.007E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7cb7accc7f550a75fec5c1cf65323440 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 16:54:05 -0000 Hi, Brain I have forwarded the draft to TSVWG for further discussion and review. Thanks Lin -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, October 17, 2017 12:58 PM To: Toerless Eckert ; Tom Herbert Cc: 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos= -00.txt On 18/10/2017 07:16, Toerless Eckert wrote: > As mentioned in my prior mail: RSVP-IP deployments got killed by SPs=20 > that filtered packets with router-alert because common network devices=20 > punted packets because of the presence of router-alert. Router alert in IPv6 *is* a hop-by-hop option [RFC2711], so the code path f= or this proposal starts exactly the same as the code path for processing an= RSVP message. > Instead of punting them because of presence of RSVP-router-alert=20 > option. And of course you can blame IP multicast: every router started=20 > to punt router-alert because of MLD (and of course us multicast folks=20 > missed the chance to fix this in MLDv2 because it only tried to=20 > duplicate IGMPv3), but no RFC told developers to punt because of router-a= lert + value in the router alert. > AFAIK, the same applies to hop-by-hop option in general. Alas, even=20 > rfc7045 did not discuss this issue. >=20 > IMHO we need a mechanism that specifies: devices MUST NOT punt/slow=20 > down packets because of the presence of this mechanism, but only=20 > because of presence of > (mechanism,value) where value is intended to be supported by device.=20 > If the device can not do this, then it MUST IGNORE this mechanism and=20 > forward packets with the mechanism as if the option was not present. That's pretty much what RFC7045/RC8200 say, except that they say it as a wa= rning. As Ole said - within a domain where hop-by-hop option X is supported, you c= an reasonably expect that all routers process X. But (excuse me repeating myself), whether X is worth doing is not really a = question for 6man. In this case, it belongs where QoS is discussed, which i= s TSVWG. Brian > One simple way to do this is to define hop-by-hop-fixed that does say=20 > exactly this and then hopefully allow all existing hop-by-hop TLV to=20 > live underneath that fixed hop-by-hop-fixed option. But i would=20 > certainly suggest to review processing complexity and extensibility befor= e such a conclusion. >=20 > Personally i prefer inband UDP layer signaling, not because i do not=20 > like IPv6 option headers but because there is just no ubiquitous API=20 > to allow apps independent of OS enhancements to set arbitrary options=20 > headers, especially ones that are not yet defined (allow apps to fully de= fined the whole header bit by bit). > Lets say from a javascript app in a browser. And i am more interested=20 > in ease of adoption than in architectural cleanlyness. But of course=20 > its perfectly valid to do the architectural clean appraoch and then=20 > prove me wrong and get that option adopted more ;-)) >=20 > Cheers > Toerless >=20 > On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: >> On one hand, IETF defined extension headers as the extensibility=20 >> mechanism of IPv6, but yet on the other hand the message seems to be=20 >> to not use them because deployed devices don't correctly support the=20 >> protocol. The upshot is that we see proposals in other WGs of=20 >> stuffing network layer information into transport protocols (options=20 >> or >> payloads) with the full expectation that intermediate nodes will=20 >> parse into the transport layer, process the embedded information, and=20 >> possibly even overwrite transport layer information. IMO that is an=20 >> architectural abomination and further abandonment of the end to end=20 >> model! >> >>> While the 6man working group can certainly help the authors with those = considerations, I believe the work would have to be owned somewhere else. >>> And it might be a little too early to go into the details of packet for= mats etc. >>> >> Agreed, but I do think the 6man working group has a vested interest=20 >> to make sure that network layer information stays in the network layer. >> At some point the information needed is going to be so complex that=20 >> it won't be able to be conveyed in any fields of the IP header. >> >> Tom >> >>> Best regards, >>> Ole >> >> -------------------------------------------------------------------- >> 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 Thu Oct 19 10:29:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B301342FC for ; Thu, 19 Oct 2017 10:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S3Mgxv8vfH7 for ; Thu, 19 Oct 2017 10:28:55 -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 8E58E134219 for ; Thu, 19 Oct 2017 10:28:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQY85132; Thu, 19 Oct 2017 17:28:52 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Oct 2017 18:28:47 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Thu, 19 Oct 2017 10:28:41 -0700 From: Lin Han To: Tom Herbert , Toerless Eckert CC: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTRJJxnUgwu2qqQUiZZRbG4Yh0Q6LnHDEwgADKFoCAADQaAIAAW74OgAL2meA= Date: Thu, 19 Oct 2017 17:28:41 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD75EEC@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59E8E0D5.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c9374dfe7a6cb005bff3ecb8271d0a43 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:28:57 -0000 Hi, Tom Agreed with you. Actually we come out the solution by using IPv6 extension header after we f= ailed in using upper layer information, such as TCP or UDP options. >From the NPU processing point of view, retrieving the signaling message fro= m either part of the data packet have almost no difference in terms of comp= lexity and performance;=20 We selected using transport layer information at the beginning was because = it is independent of IPv4 and IPv6. But later on, we found that this soluti= on will be limited in the case of un-encrypted TCP and UDP, and it cannot a= pply to other newer protocol such as QUIC. Considering the encrypted transp= ort service is almost a default configuration in the future, this limit is = absolutely un-acceptable. We got the same feedback after we chat with some = ICCRG folks in previous IETF meeting. To use upper layer information for th= e network layer purpose is strongly opposed by TCP community. One more thing to inspire us to use the IPv6 HbH is that the very original = in-band singling proposed by John Harper (quoted in the draft) was finally = resulting the TCP Quick-Start (RFC4782). Our draft could be seen as a furth= er step to provide a more complete QoS support for all transport protocols. Regards Lin -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert Sent: Tuesday, October 17, 2017 12:39 PM To: Toerless Eckert Cc: 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos= -00.txt On Tue, Oct 17, 2017 at 11:16 AM, Toerless Eckert wrote: > As mentioned in my prior mail: RSVP-IP deployments got killed by SPs=20 > that filtered packets with router-alert because common network devices=20 > punted packets because of the presence of router-alert. Instead of=20 > punting them because of presence of RSVP-router-alert option. And of=20 > course you can blame IP multicast: every router started to punt=20 > router-alert because of MLD (and of course us multicast folks missed=20 > the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3= ), but no RFC told developers to punt because of router-alert + value in th= e router alert. > AFAIK, the same applies to hop-by-hop option in general. Alas, even=20 > rfc7045 did not discuss this issue. > > IMHO we need a mechanism that specifies: devices MUST NOT punt/slow=20 > down packets because of the presence of this mechanism, but only=20 > because of presence of > (mechanism,value) where value is intended to be supported by device.=20 > If the device can not do this, then it MUST IGNORE this mechanism and=20 > forward packets with the mechanism as if the option was not present. > > One simple way to do this is to define hop-by-hop-fixed that does say=20 > exactly this and then hopefully allow all existing hop-by-hop TLV to=20 > live underneath that fixed hop-by-hop-fixed option. But i would=20 > certainly suggest to review processing complexity and extensibility befor= e such a conclusion. > > Personally i prefer inband UDP layer signaling, not because i do not=20 > like IPv6 option headers but because there is just no ubiquitous API=20 > to allow apps independent of OS enhancements to set arbitrary options=20 > headers, especially ones The API does exist. OSes like Linux have implemented APIs described in RFC2292 and other common APIs. > that are not yet defined (allow apps to fully defined the whole header bi= t by bit). > Lets say from a javascript app in a browser. And i am more interested=20 > in ease of adoption than in architectural cleanlyness. But of course=20 > its perfectly valid to do the architectural clean appraoch and then=20 > prove me wrong and get that option adopted more ;-)) It's not just about architectural cleanliness, it's about correctness. In the case that an intermediate node parses a UDP payload it is likely doi= ng this based on the some common destination port number. Port numbers don't have global and persistent meaning (e.g. TCP port 80 does not always have to be HTTP) so this leads to the possibility of mis= interpretation as described in RFC7605. If the node improperly writes data = into the UDP payload and updates the checksum, then this becomes silent dat= a corruption. Extension headers do not have this possibility of misinterpre= tation in the network. This potential misinterpretation of UDP ports and many other issues with tr= ying to turn UDP into a network layer protocol were brought up in the SPUD/= PLUS discussions. Tom -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Thu Oct 19 12:09:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA87132C2A for ; Thu, 19 Oct 2017 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9XrNhvRh0Dm for ; Thu, 19 Oct 2017 12:09:49 -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 2B20B1321C7 for ; Thu, 19 Oct 2017 12:09:49 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id t188so7352809pfd.10 for ; Thu, 19 Oct 2017 12:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=t3uAFg3Y233LmcgVVz4uDAbS96iqQ3HP1ai6+sICVi8=; b=ivCKdmfqjkKfh3qqTb0AKP0+xpe+ePEjuKnhhhUFubGo7z/g1w8AfsAP9ud+laiqf+ Y1UxjS8ouAScdYi6J6TBY/9hUxzYoLZyw/j3cOoBe1W1rV94CMo2au2Axi1b6XsQfWcM od+pwNfSSdafDEmEulQ0nularwL8vxOayK6b5jYu9+eLu06nYhCK7bUBU928RjSin5F0 BoMXoRMPAkTIBEwEcBt5T6aCdqqItVECwz5wOIUXlsW8Ps4OGTM+Cf44j3swj9LrRpVO 4ZPPPnoX1aQLaatWPRpRgUHGmerkWfXFjXW2qm8looSIbeUAW0eOhcfOf8GJ74c0e0EP VGXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=t3uAFg3Y233LmcgVVz4uDAbS96iqQ3HP1ai6+sICVi8=; b=GxKmcYIDth02bDBq7y2iVLXxmjX8S0XYLSklXaIQFJNpwK1kPni0PNgd3ncjGQlfqs dZVpgt8H8DChBrLrOgSrECYlNxzQhoH8aqDZJ/paKKzRauf1vk+4hbzq9t5ireo0EeEJ VexjO55jYq6R3DokTQG79klKzLe6QgaW+Pu7NoC92FzuNiRzRnAqzStjeP7qoFg+kEiz M3NATk5PvVWr7itY0ljZ/a0wzJ1hgImDQ63KG5Hn3jhr+aE7gziK4jlJUvZwnSIC73Ib EoDxE2NMw3n8y1fWlXIJWhsnHOyy8sfWo6czacZBnRtis6ZAV4GQFv/PhMpZu+wmfDbI f/wQ== X-Gm-Message-State: AMCzsaXIpgE941/zEsrNZCONMbSLRS2QtIiWWIexDr63AttW35FU+BYv gSclw1/XLFm0hsZ11z6WbLj7kA== X-Google-Smtp-Source: ABhQp+RI+Zkd6oz9F88VEsfOUwxpM9xVFDnfg8pohnvuKl/mY8x1i14Esse1LEUXJZsOphxi4vQHqA== X-Received: by 10.98.72.18 with SMTP id v18mr2474474pfa.232.1508440188395; Thu, 19 Oct 2017 12:09:48 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i129sm26458288pgd.21.2017.10.19.12.09.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 12:09:47 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Lin Han , Toerless Eckert , Tom Herbert Cc: 6man WG References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD75EAA@sjceml521-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <72463dcd-9b45-afff-2388-b9c55db188ef@gmail.com> Date: Fri, 20 Oct 2017 08:09:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD75EAA@sjceml521-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 19:09:51 -0000 Thanks. I think we should get some useful discussion over there. Regards Brian On 20/10/2017 05:53, Lin Han wrote: > Hi, Brain > > I have forwarded the draft to TSVWG for further discussion and review. > > Thanks > > Lin > > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Tuesday, October 17, 2017 12:58 PM > To: Toerless Eckert ; Tom Herbert > Cc: 6man WG > Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt > > On 18/10/2017 07:16, Toerless Eckert wrote: >> As mentioned in my prior mail: RSVP-IP deployments got killed by SPs >> that filtered packets with router-alert because common network devices >> punted packets because of the presence of router-alert. > > Router alert in IPv6 *is* a hop-by-hop option [RFC2711], so the code path for this proposal starts exactly the same as the code path for processing an RSVP message. > >> Instead of punting them because of presence of RSVP-router-alert >> option. And of course you can blame IP multicast: every router started >> to punt router-alert because of MLD (and of course us multicast folks >> missed the chance to fix this in MLDv2 because it only tried to >> duplicate IGMPv3), but no RFC told developers to punt because of router-alert + value in the router alert. >> AFAIK, the same applies to hop-by-hop option in general. Alas, even >> rfc7045 did not discuss this issue. >> >> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow >> down packets because of the presence of this mechanism, but only >> because of presence of >> (mechanism,value) where value is intended to be supported by device. >> If the device can not do this, then it MUST IGNORE this mechanism and >> forward packets with the mechanism as if the option was not present. > > That's pretty much what RFC7045/RC8200 say, except that they say it as a warning. > > As Ole said - within a domain where hop-by-hop option X is supported, you can reasonably expect that all routers process X. > But (excuse me repeating myself), whether X is worth doing is not really a question for 6man. In this case, it belongs where QoS is discussed, which is TSVWG. > > Brian > >> One simple way to do this is to define hop-by-hop-fixed that does say >> exactly this and then hopefully allow all existing hop-by-hop TLV to >> live underneath that fixed hop-by-hop-fixed option. But i would >> certainly suggest to review processing complexity and extensibility before such a conclusion. >> >> Personally i prefer inband UDP layer signaling, not because i do not >> like IPv6 option headers but because there is just no ubiquitous API >> to allow apps independent of OS enhancements to set arbitrary options >> headers, especially ones that are not yet defined (allow apps to fully defined the whole header bit by bit). >> Lets say from a javascript app in a browser. And i am more interested >> in ease of adoption than in architectural cleanlyness. But of course >> its perfectly valid to do the architectural clean appraoch and then >> prove me wrong and get that option adopted more ;-)) >> >> Cheers >> Toerless >> >> On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: >>> On one hand, IETF defined extension headers as the extensibility >>> mechanism of IPv6, but yet on the other hand the message seems to be >>> to not use them because deployed devices don't correctly support the >>> protocol. The upshot is that we see proposals in other WGs of >>> stuffing network layer information into transport protocols (options >>> or >>> payloads) with the full expectation that intermediate nodes will >>> parse into the transport layer, process the embedded information, and >>> possibly even overwrite transport layer information. IMO that is an >>> architectural abomination and further abandonment of the end to end >>> model! >>> >>>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. >>>> And it might be a little too early to go into the details of packet formats etc. >>>> >>> Agreed, but I do think the 6man working group has a vested interest >>> to make sure that network layer information stays in the network layer. >>> At some point the information needed is going to be so complex that >>> it won't be able to be conveyed in any fields of the IP header. >>> >>> Tom >>> >>>> Best regards, >>>> Ole >>> >>> -------------------------------------------------------------------- >>> 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 Oct 19 14:16:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE7F132CE7 for ; Thu, 19 Oct 2017 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAzCF62Vo6tZ for ; Thu, 19 Oct 2017 14:16:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E946F1321B6 for ; Thu, 19 Oct 2017 14:16:41 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F221A58C4B6; Thu, 19 Oct 2017 23:16:37 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id DA797B0CF16; Thu, 19 Oct 2017 23:16:37 +0200 (CEST) Date: Thu, 19 Oct 2017 23:16:37 +0200 From: Toerless Eckert To: Tom Herbert Cc: 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 21:16:44 -0000 On Tue, Oct 17, 2017 at 12:38:52PM -0700, Tom Herbert wrote: > The API does exist. OSes like Linux have implemented APIs described in > RFC2292 and other common APIs. >From limited experience in the past, support is fragmented and frustrating. But we only tried to get a few of these things work across various OSs (including android, iOS) and ran into variety of issues. ANd that was all from C. Once you try to go into python, Java or (yikes) javascript, the likelyhood of getting access to any API not needed by 99% of stupid apps becomes lower and lower. > > that are not yet defined (allow apps to fully defined the whole header bit by bit). > > Lets say from a javascript app in a browser. And i am more interested in ease of > > adoption than in architectural cleanlyness. But of course its perfectly valid to > > do the architectural clean appraoch and then prove me wrong and get that option > > adopted more ;-)) > > It's not just about architectural cleanliness, it's about correctness. > In the case that an intermediate node parses a UDP payload it is > likely doing this based on the some common destination port number. > Port numbers don't have global and persistent meaning (e.g. TCP port > 80 does not always have to be HTTP) so this leads to the possibility > of misinterpretation as described in RFC7605. If the node improperly > writes data into the UDP payload and updates the checksum, then this > becomes silent data corruption. Preaching to the choir. Reminds me when i got from IANA one of those sparse < 512 port number for router interception with the explicit intent to minimize use by random other applications - only to run into some obnoxious folks a few years later who said they had used (but of course never registered) that port forever in their app and do not intend to change that. > Extension headers do not have this > possibility of misinterpretation in the network. > This potential misinterpretation of UDP ports and many other issues > with trying to turn UDP into a network layer protocol were brought up > in the SPUD/PLUS discussions. So.... I wish we would have ever gotten to the point where we could really discuss how to best do inband signaling. Alas, SPUD/PLUS was killed way in before by what i would characterize as a perpass crowd attack. IMHO, any inband solution needs to well define an efficient way to do per-flow signaling, aka: not only per-packet. We're talking about per-flow behavior in many cases anyhow, and we well understand what can and can-not be done with per-flow state in middleboxes. Check out 2013 MALICE/DISCUSS which proposed to use STUN packets to signal inband (not every data packet like SPUD but just some STUN packets), and rely on STUN cookie as signature to recognize those inband signaling packets. If we agreed that we wanted per-flow inband signaling, then the STUN signature would be great option to get going. And a redefined router-alert-NG IP extension header might be the architectural correct "look-at-me" option long term. Finally wrt. architectural cleanlyness: Per-flow service negotition IMHO is clearly a transport layer function, there is no concept of 5-tuple flows at IP layer. So there should be no reason to constrain it only to the network layer. We just need to revisit over transport-layer is end-to-end-only dogma. Cheers Toerless > Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Thu Oct 19 14:24:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD73132CE7 for ; Thu, 19 Oct 2017 14:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc9CApyKfYGo for ; Thu, 19 Oct 2017 14:24:11 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0F9134316 for ; Thu, 19 Oct 2017 14:23:57 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2D65358C4B6; Thu, 19 Oct 2017 23:23:54 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 11CFBB0CF16; Thu, 19 Oct 2017 23:23:53 +0200 (CEST) Date: Thu, 19 Oct 2017 23:23:53 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Tom Herbert , 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 21:24:13 -0000 On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote: > > Instead of punting them because of presence of > > RSVP-router-alert option. And of course you can blame IP multicast: every router > > started to punt router-alert because of MLD (and of course us multicast folks > > missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), > > but no RFC told developers to punt because of router-alert + value in the router alert. > > AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss > > this issue. > > > > IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets > > because of the presence of this mechanism, but only because of presence of > > (mechanism,value) where value is intended to be supported by device. If the device > > can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism > > as if the option was not present. > > That's pretty much what RFC7045/RC8200 say, except that they > say it as a warning. It does not analyze the fact that the existing hop-by-hop option (and options carried via it like router alert) are burned because existing router imple entations punt packets with hop-by-hop options even though they do ultimately not need to process the packets (hop by hop option they don't do or router-alert protocol they don't do). And IMHO the existing hop-by-hop option is burned because the architecture RFCs did not well enough express in MUST statements that you must never speed down packets because of hop-by-hop/router-alert unless you really know you will support/do-something with that option. And that you achieve this eg.: by filtering/punting based on option/protocol. And that you can NOT do anything else. This is also the root cause why in our analysis a hacky extraction by eg: STUN signature inside UDP is a lot safer for existing networks than relying on any hop-by-hop option. Badly standardized, badly implemented. > As Ole said - within a domain where hop-by-hop option X is > supported, you can reasonably expect that all routers process X. Ask an enterprise operator with 10 different router models from 3 vendors ;-) Cheers Toerless > But (excuse me repeating myself), whether X is worth doing is not > really a question for 6man. In this case, it belongs where QoS is > discussed, which is TSVWG. > > Brian > > > One simple way to do this is to define hop-by-hop-fixed that does say exactly this > > and then hopefully allow all existing hop-by-hop TLV to live underneath that > > fixed hop-by-hop-fixed option. But i would certainly suggest to review processing > > complexity and extensibility before such a conclusion. > > > > Personally i prefer inband UDP layer signaling, not because i do not like IPv6 > > option headers but because there is just no ubiquitous API to allow apps > > independent of OS enhancements to set arbitrary options headers, especially ones > > that are not yet defined (allow apps to fully defined the whole header bit by bit). > > Lets say from a javascript app in a browser. And i am more interested in ease of > > adoption than in architectural cleanlyness. But of course its perfectly valid to > > do the architectural clean appraoch and then prove me wrong and get that option > > adopted more ;-)) > > > > Cheers > > Toerless > > > > On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: > >> On one hand, IETF defined extension headers as the extensibility > >> mechanism of IPv6, but yet on the other hand the message seems to be > >> to not use them because deployed devices don't correctly support the > >> protocol. The upshot is that we see proposals in other WGs of stuffing > >> network layer information into transport protocols (options or > >> payloads) with the full expectation that intermediate nodes will parse > >> into the transport layer, process the embedded information, and > >> possibly even overwrite transport layer information. IMO that is an > >> architectural abomination and further abandonment of the end to end > >> model! > >> > >>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. > >>> And it might be a little too early to go into the details of packet formats etc. > >>> > >> Agreed, but I do think the 6man working group has a vested interest to > >> make sure that network layer information stays in the network layer. > >> At some point the information needed is going to be so complex that it > >> won't be able to be conveyed in any fields of the IP header. > >> > >> Tom > >> > >>> Best regards, > >>> Ole > >> > >> -------------------------------------------------------------------- > >> 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 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Thu Oct 19 14:41:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E268E132A1A for ; Thu, 19 Oct 2017 14:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctfVOAwilqwd for ; Thu, 19 Oct 2017 14:41:50 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85661321A0 for ; Thu, 19 Oct 2017 14:41:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9JLfnZt030681; Thu, 19 Oct 2017 14:41:49 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9JLfhoI030642 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 14:41:43 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Oct 2017 14:41:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 19 Oct 2017 14:41:43 -0700 From: "Manfredi, Albert E" To: Toerless Eckert CC: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTSR+MnUgwu2qqQUiZZRbG4Yh0Q6LrsV4w Date: Thu, 19 Oct 2017 21:41:42 +0000 Message-ID: <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 21:41:52 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert > Finally wrt. architectural cleanlyness: Per-flow service negotiation > IMHO is clearly a transport layer function, there is no concept of > 5-tuple flows at IP layer. I would agree I principle, although IPv6 does have that flow label that ma= kes the 5-tuple less essential to identify an individual "flow," and it sit= s at layer 3. The problem remains, though: security mechanisms, which rende= r the layer 4 QoS knobs unworkable. Everything outside the "security enclav= es" at either end, and these security enclaves might just be inside the two= end hosts themselves, will have to be delivered best effort. Bert From nobody Thu Oct 19 15:00:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236D3134312 for ; Thu, 19 Oct 2017 15:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KSlD25C5qtK6 for ; Thu, 19 Oct 2017 15:00:36 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9868413430F for ; Thu, 19 Oct 2017 15:00:36 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id p1so16335484qtg.2 for ; Thu, 19 Oct 2017 15:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iPncy83Y2MoUWMAu6CkexFtjVQXJTqbr4RX2lx6M8DY=; b=byniKZP/fdoKNMkQHEjgOYHpVTcwvGSrmWBhUGAyrcc5ny7W87D7EGq/dSIjYZRtvU lFY75Xr/BrBOasYvgN/KwjKy9vKkI9Ltr5kUOV47wD0yqQPMziUnzHtnN1iBpVrNpPfq dzu5zfR8k2ZblKvQoCdho7O1BwFY8usPATu44vb5kOKkh4xHcMJo8pVOE5wnlvRQjqCT gkuVSga9aBiYzBLG3Ga31ry7buk7+DI/Ol+3c0PIqEFNHZ5uDwJ6Ym33yy/CCb1G7dxX 0NYYluRnEpUuELa2CHYHHUlJuGdG7BpxK1vCI2fdNHAw2f2IsWLKABRz8KXeGRPM8Q77 9y0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iPncy83Y2MoUWMAu6CkexFtjVQXJTqbr4RX2lx6M8DY=; b=fWf7H2bek6LV4IMoDtXHwKxnszvOBjcJM4RHPo0Q0ZI0F6WPzvMSNonXMRYcuSrOV1 D0ItyonpvKcoHe1jNlY46rnQYCVt5k0NR2coRyIlIA8W3WiXgSikEY8M3MNqrld0Gq8E dgWl5dBzB48awYIcj8xga1R4vjhrvmWKZnQdGHj38i0tsxwR8Wd75DbBAGHoLszOh/sZ M51ZBMmeYbr/4AKnIcxTM4LHyOVN0gVR2qXQ5IG0khcwVUOAu4pUTBAnuZj8tw5DswvB V8zgD7NjI+od3rpWpAx2aVaSvEq3QmyclO5aPuB3TUcyoKnPlECHTV4XIi5q4hK3WgXB 6Emw== X-Gm-Message-State: AMCzsaUA1E8Mdrmi/PeURhGK1PULACfcGH+OCfoj1KD9v7hF6ktptWi+ sPXKkQj0K/gGruEhWvDNzYbI+09disFobC4gJ/bZ0A== X-Google-Smtp-Source: ABhQp+Sk/Xx6JC5xWKpkjjat5Qk8UUJhRI+tVsP8jtd+ZFfhZWwTviAhcdYzVHD4csvq8+5XkeUniBKIK3aXXjrISBs= X-Received: by 10.237.60.46 with SMTP id t43mr4294299qte.294.1508450435667; Thu, 19 Oct 2017 15:00:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Thu, 19 Oct 2017 15:00:35 -0700 (PDT) In-Reply-To: <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> From: Tom Herbert Date: Thu, 19 Oct 2017 15:00:35 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: "Manfredi, Albert E" Cc: Toerless Eckert , 6man WG Content-Type: multipart/alternative; boundary="94eb2c0e80f0612ca9055bed7c6f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:00:38 -0000 --94eb2c0e80f0612ca9055bed7c6f Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 2:41 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert > > > Finally wrt. architectural cleanlyness: Per-flow service negotiation > > IMHO is clearly a transport layer function, there is no concept of > > 5-tuple flows at IP layer. > > I would agree I principle, although IPv6 does have that flow label that > makes the 5-tuple less essential to identify an individual "flow," and it > sits at layer 3. Right. > The problem remains, though: security mechanisms, which render the layer 4 > QoS knobs unworkable. Everything outside the "security enclaves" at either > end, and these security enclaves might just be inside the two end hosts > themselves, will have to be delivered best effort. > > Bert, I don't follow. One of the big wins using the 3-tuple is that it can still indicate a flow even if all the transport transport headers and payload are encrypted. So this should allow specifying QoS without revealing anything about the content except that the sender wants to group certain packets together as a flow and apply QoS on them. Tom Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c0e80f0612ca9055bed7c6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 2:41 PM, Manfredi, Albert E &= lt;albert= .e.manfredi@boeing.com> wrote:
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ie= tf.org] On Behalf Of Toerless Eckert

> Finally wrt. architectural cleanlyness: Per-flow service negotiation > IMHO is clearly a transport layer function, there is = no concept of
> 5-tuple flows at IP layer.

I would agree I=C2=A0 principle, although IPv6 does have that flow l= abel that makes the 5-tuple less essential to identify an individual "= flow," and it sits at layer 3.

Right.=
=C2=A0
The problem remains, = though: security mechanisms, which render the layer 4 QoS knobs unworkable.= Everything outside the "security enclaves" at either end, and th= ese security enclaves might just be inside the two end hosts themselves, wi= ll have to be delivered best effort.

Bert, I don't follow. One of the big wins using t= he 3-tuple is that it can still indicate a flow even if all the transport t= ransport headers and payload are encrypted. So this should allow specifying= QoS without revealing anything about the content except that the sender wa= nts to group certain packets together as a flow and apply QoS on them.

Tom


Bert


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

--94eb2c0e80f0612ca9055bed7c6f-- From nobody Thu Oct 19 15:09:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614B4134316 for ; Thu, 19 Oct 2017 15:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeM39rL28kwU for ; Thu, 19 Oct 2017 15:09:39 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73F013431F for ; Thu, 19 Oct 2017 15:09:39 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 50F5958C4B6; Fri, 20 Oct 2017 00:09:35 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 335D1B0CF12; Fri, 20 Oct 2017 00:09:35 +0200 (CEST) Date: Fri, 20 Oct 2017 00:09:35 +0200 From: Toerless Eckert To: Tom Herbert Cc: "Manfredi, Albert E" , 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> References: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:09:41 -0000 On Thu, Oct 19, 2017 at 03:00:35PM -0700, Tom Herbert wrote: > Bert, I don't follow. One of the big wins using the 3-tuple is that it can > still indicate a flow even if all the transport transport headers and > payload are encrypted. So this should allow specifying QoS without > revealing anything about the content except that the sender wants to group > certain packets together as a flow and apply QoS on them. Problem with flow label is same as with hop-by-hop option: burned because nobody should dare use it for something useful with all the inconsistent code out in the field. Nothing against redefining it (with new encoding) with a precise set of MUST/MUST-NOTs once we agree on some way to use it. http://snaggletooth.akam.ai/Prague-videos/ -> 03-joel-jaeggli Cheers Toerless From nobody Thu Oct 19 15:13:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6629C13431B for ; Thu, 19 Oct 2017 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsVY2WzpYrb9 for ; Thu, 19 Oct 2017 15:13:19 -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 4530F13420D for ; Thu, 19 Oct 2017 15:13:19 -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 v9JMDI4Y044403; Thu, 19 Oct 2017 15:13:18 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9JMDHC8044399 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 15:13:17 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Oct 2017 15:13:16 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 19 Oct 2017 15:13:17 -0700 From: "Manfredi, Albert E" To: Tom Herbert CC: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTSR+MnUgwu2qqQUiZZRbG4Yh0Q6LrsV4wgAB9HID//4ueQA== Date: Thu, 19 Oct 2017 22:13:16 +0000 Message-ID: <2b3610187ec64b69941d638d48a71373@XCH15-06-11.nw.nos.boeing.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:13:20 -0000 RnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXSANCg0KPj4gVGhl IHByb2JsZW0gcmVtYWlucywgdGhvdWdoOiBzZWN1cml0eSBtZWNoYW5pc21zLCB3aGljaCByZW5k ZXIgdGhlIGxheWVyDQo+PiA0IFFvUyBrbm9icyB1bndvcmthYmxlLiBFdmVyeXRoaW5nIG91dHNp ZGUgdGhlICJzZWN1cml0eSBlbmNsYXZlcyIgYXQNCj4+IGVpdGhlciBlbmQsIGFuZCB0aGVzZSBz ZWN1cml0eSBlbmNsYXZlcyBtaWdodCBqdXN0IGJlIGluc2lkZSB0aGUgdHdvIGVuZA0KPj4gaG9z dHMgdGhlbXNlbHZlcywgd2lsbCBoYXZlIHRvIGJlIGRlbGl2ZXJlZCBiZXN0IGVmZm9ydC4NCj4N Cj4gQmVydCwgSSBkb24ndCBmb2xsb3cuIE9uZSBvZiB0aGUgYmlnIHdpbnMgdXNpbmcgdGhlIDMt dHVwbGUgaXMgdGhhdCBpdCBjYW4NCj4gc3RpbGwgaW5kaWNhdGUgYSBmbG93IGV2ZW4gaWYgYWxs IHRoZSB0cmFuc3BvcnQgdHJhbnNwb3J0IGhlYWRlcnMgYW5kDQo+IHBheWxvYWQgYXJlIGVuY3J5 cHRlZC4gU28gdGhpcyBzaG91bGQgYWxsb3cgc3BlY2lmeWluZyBRb1Mgd2l0aG91dA0KPiByZXZl YWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIGNvbnRlbnQgZXhjZXB0IHRoYXQgdGhlIHNlbmRlciB3 YW50cyB0byBncm91cA0KPiBjZXJ0YWluIHBhY2tldHMgdG9nZXRoZXIgYXMgYSBmbG93IGFuZCBh cHBseSBRb1Mgb24gdGhlbS4NCg0KVHJ1ZSwgVG9tLiBJIHdhcyByZXNwb25kaW5nIHRvIFRvZWxl c3MsIHdoZW4gaGUgc2F5czoNCg0KIkZpbmFsbHkgd3J0LiBhcmNoaXRlY3R1cmFsIGNsZWFubHlu ZXNzOiBQZXItZmxvdyBzZXJ2aWNlIG5lZ290aWF0aW9uIElNSE8gaXMgY2xlYXJseSBhIHRyYW5z cG9ydCBsYXllciBmdW5jdGlvbiwgdGhlcmUgaXMgbm8gY29uY2VwdCBvZiA1LXR1cGxlIGZsb3dz IGF0IElQIGxheWVyLiINCg0KSSBzYXcgdGhhdCBUb2VybGVzcyBqdXN0IHJlc3BvbmRlZCwgc28g aGUgbWlnaHQgYmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nLiBCdXQgY29uc3RyYWluaW5nIHRoZSBp ZGVhIG9mIGluLWJhbmQgc2lnbmFsaW5nIHRvIGp1c3QgSVB2NiBvdWdodCB0byBiZSBtb3JlIHdv cmthYmxlLCBhbHRob3VnaCB5b3UgZG8gbmVlZCB0byBnZXQgYWxsIHRob3NlIGludGVybWVkaWF0 ZSByb3V0ZXJzIGludm9sdmVkLiBJIGR1bm5vLiBUaGlzIGFsd2F5cyBzZWVtcyBsaWtlIHRoZSBB Y2hpbGxlcyBoZWVsLg0KDQpCZXJ0DQoNCg== From nobody Thu Oct 19 15:16:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8542313431B for ; Thu, 19 Oct 2017 15:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n_0XkSvvQVO for ; Thu, 19 Oct 2017 15:16:36 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5318F13420D for ; Thu, 19 Oct 2017 15:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9JMGZHG015801; Thu, 19 Oct 2017 15:16:35 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9JMGO4m015654 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 15:16:24 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Oct 2017 15:16:24 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 19 Oct 2017 15:16:24 -0700 From: "Manfredi, Albert E" To: Tom Herbert CC: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Topic: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Thread-Index: AQHTSR+MnUgwu2qqQUiZZRbG4Yh0Q6LrsV4wgAB9HID//4ueQIAAAy5Q Date: Thu, 19 Oct 2017 22:16:23 +0000 Message-ID: References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <2b3610187ec64b69941d638d48a71373@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <2b3610187ec64b69941d638d48a71373@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:16:37 -0000 Entschuldigen Sie bitte! Toerless! -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E Sent: Thursday, October 19, 2017 18:13 To: Tom Herbert Cc: 6man WG Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos= -00.txt From: Tom Herbert [mailto:tom@herbertland.com]=20 >> The problem remains, though: security mechanisms, which render the layer >> 4 QoS knobs unworkable. Everything outside the "security enclaves" at >> either end, and these security enclaves might just be inside the two end >> hosts themselves, will have to be delivered best effort. > > Bert, I don't follow. One of the big wins using the 3-tuple is that it ca= n > still indicate a flow even if all the transport transport headers and > payload are encrypted. So this should allow specifying QoS without > revealing anything about the content except that the sender wants to grou= p > certain packets together as a flow and apply QoS on them. True, Tom. I was responding to Toeless, when he says: "Finally wrt. architectural cleanlyness: Per-flow service negotiation IMHO = is clearly a transport layer function, there is no concept of 5-tuple flows= at IP layer." I saw that Toerless just responded, so he might be saying the same thing. B= ut constraining the idea of in-band signaling to just IPv6 ought to be more= workable, although you do need to get all those intermediate routers invol= ved. I dunno. This always seems like the Achilles heel. Bert From nobody Thu Oct 19 15:53:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C33132355 for ; Thu, 19 Oct 2017 15:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsykOnlC_Oex for ; Thu, 19 Oct 2017 15:53:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB4132F69 for ; Thu, 19 Oct 2017 15:53:00 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8396958C4B6; Fri, 20 Oct 2017 00:52:56 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6A249B0CF11; Fri, 20 Oct 2017 00:52:56 +0200 (CEST) Date: Fri, 20 Oct 2017 00:52:56 +0200 From: Toerless Eckert To: "Manfredi, Albert E" Cc: Tom Herbert , 6man WG Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt Message-ID: <20171019225256.GE878@faui40p.informatik.uni-erlangen.de> References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <2b3610187ec64b69941d638d48a71373@XCH15-06-11.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:53:03 -0000 On Thu, Oct 19, 2017 at 10:16:23PM +0000, Manfredi, Albert E wrote: > Entschuldigen Sie bitte! Toerless! [ Yeah, last i counted, all my toes are still there. I thought the correct abbreviation was self explanatory: "less" ] All my lamenting here was exactly to avoid running into the achilles heel of existing onpath router code that would mess up good new ideas. Cheers Toerless > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E > Sent: Thursday, October 19, 2017 18:13 > To: Tom Herbert > Cc: 6man WG > Subject: RE: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt > > From: Tom Herbert [mailto:tom@herbertland.com] > > >> The problem remains, though: security mechanisms, which render the layer > >> 4 QoS knobs unworkable. Everything outside the "security enclaves" at > >> either end, and these security enclaves might just be inside the two end > >> hosts themselves, will have to be delivered best effort. > > > > Bert, I don't follow. One of the big wins using the 3-tuple is that it can > > still indicate a flow even if all the transport transport headers and > > payload are encrypted. So this should allow specifying QoS without > > revealing anything about the content except that the sender wants to group > > certain packets together as a flow and apply QoS on them. > > True, Tom. I was responding to Toeless, when he says: > > "Finally wrt. architectural cleanlyness: Per-flow service negotiation IMHO is clearly a transport layer function, there is no concept of 5-tuple flows at IP layer." > > I saw that Toerless just responded, so he might be saying the same thing. But constraining the idea of in-band signaling to just IPv6 ought to be more workable, although you do need to get all those intermediate routers involved. I dunno. This always seems like the Achilles heel. > > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Thu Oct 19 16:38:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3913490C for ; Thu, 19 Oct 2017 16:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 znBgGcaozinE for ; Thu, 19 Oct 2017 16:38:12 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 B4E9C1320DC for ; Thu, 19 Oct 2017 16:38:12 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id l194so12422844qke.13 for ; Thu, 19 Oct 2017 16:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IxoVX8hVzwRI3lrM9GASDp5MCb6K/z7BNyjqLEzsvJs=; b=ukNv4LFihwnhitP4GLU/fing247tpOnKCaAW4jQ4FRvZrrcfPu7IsGXAeSZMdKI0NN GdgFKed3j1qdskXxKzAhv8IYOsW2u1++HiM4RDS4d+Jr6+3bAm2UZmz8DGEtyIt0d1CD NQFUsiPPyYfYJtzUToF6+tWQ4BU+VLNO/QcmFkyfwqgPi7IcpfE1GjPAZk11IbFnhGpG VVpOGJnsI1EdUqa6b/0ALSCjIAXYnR1CiMAqkzy8jqN2hBuLu2QyH0GyrEAOQPn2v+G7 70yK7cuoCO4CWbVqbrqU3RbEEd3csrsgvztrN/IxOivJfeGjPmHk5Sst5IueivPBxtyG JmTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IxoVX8hVzwRI3lrM9GASDp5MCb6K/z7BNyjqLEzsvJs=; b=NzNdQQECebkRi0BsoDe4ANZLQggw+5yB0T+MJ5IazUKKke7XWXpkvWdhSsxT+oL9NL yytw2bQaTHOHaRqeleovj9ZplAwD5J3gTCCbZ2iZTjqfxDdm9o2WNrAj4z8h7S5T78Nv T0NHZZmxVZUB2hbJPlfu1+XGFtzNuoVkA3GlfpcSSXmyI+HtsdQCfSplrLWjhJg3n9Rb An6YJjFjwxlb3M+c+jKP73QutjYBODiuOPmFsDhV7RCLQ8h8SEiWnb/faHqPDhMgXvZD CxSFAPV08DohQUgfo8i/aUX8F9sAJUAlF0QUJeJCPPSWORYgtw3y6Tq9WEYTkPJ80RIr sF7A== X-Gm-Message-State: AMCzsaVje47PW9axGo44/sf1SII3304Ot4ffeD3f4+4sZ5sez/ABKF/3 p5S61J8ECAZC08rVKjRvgpOE5iv/DJxFiYNim2QuFg== X-Google-Smtp-Source: ABhQp+RZQpudxp67G4L4GgXlr0ZqjYK8x1yB3VKfSHo5OLW6wGw99h/aua0hGP3BZo71wurXw2zLbhoEeg70+rb/Q98= X-Received: by 10.55.106.132 with SMTP id f126mr4224257qkc.295.1508456291822; Thu, 19 Oct 2017 16:38:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Thu, 19 Oct 2017 16:38:11 -0700 (PDT) In-Reply-To: <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> References: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Thu, 19 Oct 2017 16:38:11 -0700 Message-ID: Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: Toerless Eckert Cc: "Manfredi, Albert E" , 6man WG Content-Type: multipart/alternative; boundary="001a11487b0a6f0197055beed9b1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 23:38:14 -0000 --001a11487b0a6f0197055beed9b1 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 3:09 PM, Toerless Eckert wrote: > On Thu, Oct 19, 2017 at 03:00:35PM -0700, Tom Herbert wrote: > > Bert, I don't follow. One of the big wins using the 3-tuple is that it > can > > still indicate a flow even if all the transport transport headers and > > payload are encrypted. So this should allow specifying QoS without > > revealing anything about the content except that the sender wants to > group > > certain packets together as a flow and apply QoS on them. > > Problem with flow label is same as with hop-by-hop option: burned because > nobody should dare use it for something useful with all the inconsistent > code out in the field. Nothing against redefining it (with new encoding) > with a precise set of MUST/MUST-NOTs once we agree on some way to use it. > > Toerless, I know that EH is an issue because some implementations drop packets having them. But what is the problem with flow labels? Non-zero flow labels are being used everyday on the Internet without problem, and I know of at least one big DC deployment that is productively using flow labels for ECMP in their network. Tom --001a11487b0a6f0197055beed9b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 3:09 PM, Toerless Eckert <= tte@cs.fau.de> wrote:
On Thu, Oct = 19, 2017 at 03:00:35PM -0700, Tom Herbert wrote:
> Bert, I don't follow. One of the big wins using the 3-tuple is tha= t it can
> still indicate a flow even if all the transport transport headers and<= br> > payload are encrypted. So this should allow specifying QoS without
> revealing anything about the content except that the sender wants to g= roup
> certain packets together as a flow and apply QoS on them.

Problem with flow label is same as with hop-by-hop option: burned be= cause
nobody should dare use it for something useful with all the inconsistent code out in the field.=C2=A0 Nothing against redefining it (with new encodi= ng)
with a precise set of MUST/MUST-NOTs once we agree on some way to use it.
Toerless,

I know that EH is = an issue because some implementations drop packets having them. But what is= the problem with flow labels? Non-zero flow labels are being used everyday= on the Internet without problem, and I know of at least one big DC deploym= ent that is productively using flow labels for ECMP in their network.
=

Tom

--001a11487b0a6f0197055beed9b1-- From nobody Thu Oct 19 17:05:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5611321A1 for ; Thu, 19 Oct 2017 17:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmG__aT_YUaT for ; Thu, 19 Oct 2017 17:05:45 -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 D9268126B7E for ; Thu, 19 Oct 2017 17:05:45 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 17so8356607pfn.12 for ; Thu, 19 Oct 2017 17:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L/nWLb+1APH8ShBi68W91rY0dJrGez6UhkHQaVHQa3Q=; b=XJ8Cp8TOrzwTWKUvYhwEJNqTzhZu0+bbXMNVaAwA92pIcp1aOzH03Es45SL00lfi1T X//Rotgx0goRVGrfAjO1kPmqaZsi16JF1oNQzdCksjmmJnOnolQoqQdbf8a81mjib11+ kFmnmEQyu1p6uqpjcFOiTHpZel5Nf+mC38b3sCmFUnudbhAtds5GoEjqvIWAWWRU0qLN LXEQSzh6zXocF4YXmtC/5/2D9S2pG32uGRsXweB4He5qZYvSZihJ61PWia40lnQKZqKG 8R1u5wN2jq9W8RF7lJOKGJcoFE5x1Yo+CA3IgR+35YhS25c5xer/WaWxPPsc0PdI2jhU /Tbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=L/nWLb+1APH8ShBi68W91rY0dJrGez6UhkHQaVHQa3Q=; b=ufZIZ1zHXhpdGNeYjF826Fz2nf+VXgBwqvln3UnMMu+595OC0ZLhbqPrW+/B7n2Ljx 6pyrPJOFoaPoGeFUgFA0+L4cy/dlHNesy/TJIyRHjI1DtrJD8pu/Nvf0iPtPXU37eU2d IFbS/8WI6gZxEssF/6/GcEFTLxSqluk2aZAebeIziqg8pN3+mpliprL/LntfcwjN0aQh +x94lhgk4yAOAbYQt6sTwMI/xiMQPU6Uig4NfYkri336I7hVPEwZefZjJ13M5jHgArc1 O40cZcj5yg33FH5Dik2rAIYM/cFTVx6eY7t4qxx67wprYGPZ/6X8+FaO/cG6GpAqok/l 5DdQ== X-Gm-Message-State: AMCzsaWqHO0iDj9meHlW/4SdJ8OAt8bmg5CjlYbbXW6NU7b03tqs5+vG 21YX9yqcjHAIHu4heANqOC9mBQ== X-Google-Smtp-Source: ABhQp+TR0TJp8V1KzKd6VY/p7jqQPjOnMku4e20PugCioFkwYPwRD5M8byuygIO24tKhjr7daEFb1w== X-Received: by 10.101.65.200 with SMTP id b8mr2767836pgq.274.1508457944954; Thu, 19 Oct 2017 17:05:44 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h77sm21235891pfj.38.2017.10.19.17.05.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 17:05:43 -0700 (PDT) Subject: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: ipv6@ietf.org References: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> Date: Fri, 20 Oct 2017 13:05:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:05:47 -0000 On 20/10/2017 11:09, Toerless Eckert wrote: > On Thu, Oct 19, 2017 at 03:00:35PM -0700, Tom Herbert wrote: >> Bert, I don't follow. One of the big wins using the 3-tuple is that it can >> still indicate a flow even if all the transport transport headers and >> payload are encrypted. So this should allow specifying QoS without >> revealing anything about the content except that the sender wants to group >> certain packets together as a flow and apply QoS on them. > > Problem with flow label is same as with hop-by-hop option: burned because > nobody should dare use it for something useful with all the inconsistent > code out in the field. Nothing against redefining it (with new encoding) There is no encoding. It's 20 opaque bits (and always has been). Please read https://tools.ietf.org/html/rfc6437. Brian From nobody Thu Oct 19 17:20:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5745C1330B1 for ; Thu, 19 Oct 2017 17:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s79EGuKXurIq for ; Thu, 19 Oct 2017 17:20:37 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D4B132C32 for ; Thu, 19 Oct 2017 17:20:36 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id b6so8403227pfh.7 for ; Thu, 19 Oct 2017 17:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=An8t5nQwlXl4UuWfaEfqaWVfb/lGy3LgYv4U3Sk+kB4=; b=gt+pWGB5mr4GG1bQpB7+jCiX4thbKL+y5Ylc0dLRy01lX0/Man/TDWXyq4Vkg6xb8L aL1OUFKCtcJcsWw65gbj3I8b86q/FiNko+uMnpwdFIn/fg722Ahp+Gk+ybZx/nrO3xTR M+x6yLX0Bgd8X8yOSsF2eRedLBH2H2UMLlIRgS9j74GEviEjYngJwA1bc6FpihAt4QKK qDI6F9dSbsaRg7L6mqEKyLZRjTIHY2oOV7QVwEAI5iT3wJ2TY4KPwSw3sbBDPUf+LfhM f73Dxred2ZceqrL2rr4qd7H3DnA+0D4GTxExxpxvpREfucFdzQUjxN0aW/CORcuYdudC xnYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=An8t5nQwlXl4UuWfaEfqaWVfb/lGy3LgYv4U3Sk+kB4=; b=HiA/jisIlowzgXWlvo0maHKFt+hmZm6KwbFNLxSQMi39qZ//jzO6EIfWYUi1gGPBtq 5SrHC5FHMwzIhcc0lkkmnJXWmrxxOvgUXOqwssIb81ycc49kBoc751CIwu5AK+t7EPG7 9QRUeS9ybRVYkS2wciytq9LW3z52wx00fsL5mJavVIMCT8ZCu4GI4czI+/kknS3U9V5C W2hF07kfayLrtScGSLFlVxNIyCL5QC5KJwlooCldchKKnS+TTipN+/EoJh63zKTNj0EM wQodYW3EdatX5TOV/9Y4701wjyblFqQ41q0e/F2kPoYKZCd5PkYYNTbRhJarROI0yJM5 5bdA== X-Gm-Message-State: AMCzsaXg+pM053r0+9um4noL7lPtGlgzlNOvb5NHpNzcmUBPL5jFxMTL 7ewu/AT/sLi1WsM8kVP0Y8iw6g== X-Google-Smtp-Source: ABhQp+RVr5IUY8N8YqMevDJ9fIJdIeln1aVEn09vTl4JttM1TUbSb6uNek3HBrheKn3bTICE35GNdw== X-Received: by 10.101.65.75 with SMTP id x11mr2779075pgp.388.1508458836113; Thu, 19 Oct 2017 17:20:36 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t18sm3347819pfi.98.2017.10.19.17.20.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 17:20:35 -0700 (PDT) Subject: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Toerless Eckert Cc: Tom Herbert , 6man WG References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Oct 2017 13:20:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:20:41 -0000 On 20/10/2017 10:23, Toerless Eckert wrote: > On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote: >>> Instead of punting them because of presence of >>> RSVP-router-alert option. And of course you can blame IP multicast: every router >>> started to punt router-alert because of MLD (and of course us multicast folks >>> missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), >>> but no RFC told developers to punt because of router-alert + value in the router alert. >>> AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss >>> this issue. >>> >>> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets >>> because of the presence of this mechanism, but only because of presence of >>> (mechanism,value) where value is intended to be supported by device. If the device >>> can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism >>> as if the option was not present. >> >> That's pretty much what RFC7045/RC8200 say, except that they >> say it as a warning. > > It does not analyze the fact that the existing hop-by-hop option (and options > carried via it like router alert) are burned because existing router imple entations > punt packets with hop-by-hop options even though they do ultimately not > need to process the packets (hop by hop option they don't do or router-alert > protocol they don't do). We discussed that before agreeing on the words in 7045, which were +- adopted in 8200. > And IMHO the existing hop-by-hop option is burned because the architecture > RFCs did not well enough express in MUST statements that you must never > speed down packets because of hop-by-hop/router-alert unless you really know > you will support/do-something with that option. And that you achieve this eg.: > by filtering/punting based on option/protocol. And that you can NOT do anything else. The protocol design really shouldn't talk about implementation choices in routers and the fact that FPGA people hate the IPv6 extension header design like the plague, which has led to broken implementations. In 1994 there weren't any 'fast path' router designs, iirc, and the design simply didn't consider this problem to be a problem. So the assumption was that the forwarder CPU would pass on the whole header, and would only branch off the main code path if it saw a HbH header. I know we're 20 years later, but logically that hasn't changed. The problem is that many vendors didn't implement it; they sacrificed correctness for speed. > This is also the root cause why in our analysis a hacky extraction by > eg: STUN signature inside UDP is a lot safer for existing networks than relying > on any hop-by-hop option. Badly standardized, badly implemented. We agree on badly implemented ;-). IPv4 Options are badly implemented, too. >> As Ole said - within a domain where hop-by-hop option X is >> supported, you can reasonably expect that all routers process X. > > Ask an enterprise operator with 10 different router models from 3 vendors ;-) If they want to use X they need to buy routers that support X. Brian > > Cheers > Toerless > >> But (excuse me repeating myself), whether X is worth doing is not >> really a question for 6man. In this case, it belongs where QoS is >> discussed, which is TSVWG. >> >> Brian >> >>> One simple way to do this is to define hop-by-hop-fixed that does say exactly this >>> and then hopefully allow all existing hop-by-hop TLV to live underneath that >>> fixed hop-by-hop-fixed option. But i would certainly suggest to review processing >>> complexity and extensibility before such a conclusion. >>> >>> Personally i prefer inband UDP layer signaling, not because i do not like IPv6 >>> option headers but because there is just no ubiquitous API to allow apps >>> independent of OS enhancements to set arbitrary options headers, especially ones >>> that are not yet defined (allow apps to fully defined the whole header bit by bit). >>> Lets say from a javascript app in a browser. And i am more interested in ease of >>> adoption than in architectural cleanlyness. But of course its perfectly valid to >>> do the architectural clean appraoch and then prove me wrong and get that option >>> adopted more ;-)) >>> >>> Cheers >>> Toerless >>> >>> On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: >>>> On one hand, IETF defined extension headers as the extensibility >>>> mechanism of IPv6, but yet on the other hand the message seems to be >>>> to not use them because deployed devices don't correctly support the >>>> protocol. The upshot is that we see proposals in other WGs of stuffing >>>> network layer information into transport protocols (options or >>>> payloads) with the full expectation that intermediate nodes will parse >>>> into the transport layer, process the embedded information, and >>>> possibly even overwrite transport layer information. IMO that is an >>>> architectural abomination and further abandonment of the end to end >>>> model! >>>> >>>>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. >>>>> And it might be a little too early to go into the details of packet formats etc. >>>>> >>>> Agreed, but I do think the 6man working group has a vested interest to >>>> make sure that network layer information stays in the network layer. >>>> At some point the information needed is going to be so complex that it >>>> won't be able to be conveyed in any fields of the IP header. >>>> >>>> Tom >>>> >>>>> Best regards, >>>>> Ole >>>> >>>> -------------------------------------------------------------------- >>>> 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 Oct 19 17:40:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2381320B5 for ; Thu, 19 Oct 2017 17:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YsJwxszP3eJ0 for ; Thu, 19 Oct 2017 17:40:31 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 BC434132D54 for ; Thu, 19 Oct 2017 17:40:30 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 31so16665805qtz.9 for ; Thu, 19 Oct 2017 17:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XE/hYUH3z6mMHkWBbgIEVpfD3oUHqx1J+eEipSb+v8E=; b=mkV+R5y5oL0kmBvDHO/N+Q1Qa+N8iUzLeEgKjA45seteUdQIcX/pE6z/JzaK64ZdxP uBbuG4CdrwnSrqFzC+GkkDFGhsZ/NTbhDw7Z9NRIGn8YxIV0/1OMFPy8Cp59SoTNfDgw VL306fbUtih1bdvxlAbfjbE+vCynr3SpTth852emqpWVq7386bQzOJOGVsuIljj/NP87 y0AzDmmSScwdgpb2Sdb8LiSoROCKEk5j5xFmF+aLVS6xYp6snlvQwft8R3fy2oidbgwe 91FYrU8dxGvhqh0scmnpkM0gnnnboS2b+LannSUetHSxRtXpiy2C9D2ERyQZ3v+Krtd3 K6nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XE/hYUH3z6mMHkWBbgIEVpfD3oUHqx1J+eEipSb+v8E=; b=heYju5ONEhX0QIn6JwhDipBeJjXKq/pNbvtcfNh1ZbK7qRGr3oUWitXmMPiux1FhS+ FKX1UYOln8TFX4hKY5d1meZcbMP1l7jVHAVXukpxqLQpP52+Nnb9EwnwpU+Ocs79G23u AkDbqe5e2jy6WkjXlMMRdbLm7Vkhvirl6Dwo9sb8e/o87OGxPAJcUrzKX669LZaaz2rT IY8uSN5tsZYlRUC2U6y+e6GGnX4kjy6WZwRkTkNaC3bao2K2kNyHs0KTOZfhCdpBTnnC xGHxuBx+zD0DTIUrOp0Y2JIuuOpRuIFW/k+LEcP+CTLlnQSkv87N+sVvbf+6RsUkuTXH H32w== X-Gm-Message-State: AMCzsaUJZLgW81afDXXC3wmb1N2LRXI7D7uadJ4AacgdySJBKTVVR6yX UwgnGZctQP2eZZxfuLthbHI7XfCnuDrA+VtQoI0l3Q== X-Google-Smtp-Source: ABhQp+QqaAo2kDHItdhDDjEV9vXb2cL/L70eQvkUoG4FXQZ8hIbL4ilTKeDuZYI2JJLbqwDqzOAQNShKyycK1PFTAtw= X-Received: by 10.200.53.89 with SMTP id z25mr5053705qtb.58.1508460029739; Thu, 19 Oct 2017 17:40:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Thu, 19 Oct 2017 17:40:29 -0700 (PDT) In-Reply-To: References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> From: Tom Herbert Date: Thu, 19 Oct 2017 17:40:29 -0700 Message-ID: Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Brian E Carpenter Cc: Toerless Eckert , 6man WG Content-Type: multipart/alternative; boundary="001a113edd803b14be055befb85c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:40:33 -0000 --001a113edd803b14be055befb85c Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 5:20 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 20/10/2017 10:23, Toerless Eckert wrote: > > On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote: > >>> Instead of punting them because of presence of > >>> RSVP-router-alert option. And of course you can blame IP multicast: > every router > >>> started to punt router-alert because of MLD (and of course us > multicast folks > >>> missed the chance to fix this in MLDv2 because it only tried to > duplicate IGMPv3), > >>> but no RFC told developers to punt because of router-alert + value in > the router alert. > >>> AFAIK, the same applies to hop-by-hop option in general. Alas, even > rfc7045 did not discuss > >>> this issue. > >>> > >>> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow > down packets > >>> because of the presence of this mechanism, but only because of > presence of > >>> (mechanism,value) where value is intended to be supported by device. > If the device > >>> can not do this, then it MUST IGNORE this mechanism and forward > packets with the mechanism > >>> as if the option was not present. > >> > >> That's pretty much what RFC7045/RC8200 say, except that they > >> say it as a warning. > > > > It does not analyze the fact that the existing hop-by-hop option (and > options > > carried via it like router alert) are burned because existing router > imple entations > > punt packets with hop-by-hop options even though they do ultimately not > > need to process the packets (hop by hop option they don't do or > router-alert > > protocol they don't do). > > We discussed that before agreeing on the words in 7045, which were +- > adopted > in 8200. > > > And IMHO the existing hop-by-hop option is burned because the > architecture > > RFCs did not well enough express in MUST statements that you must never > > speed down packets because of hop-by-hop/router-alert unless you really > know > > you will support/do-something with that option. And that you achieve > this eg.: > > by filtering/punting based on option/protocol. And that you can NOT do > anything else. > > The protocol design really shouldn't talk about implementation choices > in routers and the fact that FPGA people hate the IPv6 extension header > design like the plague, which has led to broken implementations. In 1994 > there weren't any 'fast path' router designs, iirc, and the design simply > didn't consider this problem to be a problem. So the assumption was that > the forwarder CPU would pass on the whole header, and would only branch > off the main code path if it saw a HbH header. I know we're 20 years > later, but logically that hasn't changed. The problem is that many vendors > didn't implement it; they sacrificed correctness for speed. > > > This is also the root cause why in our analysis a hacky extraction by > > eg: STUN signature inside UDP is a lot safer for existing networks than > relying > > on any hop-by-hop option. Badly standardized, badly implemented. > > We agree on badly implemented ;-). IPv4 Options are badly implemented, too. > > >> As Ole said - within a domain where hop-by-hop option X is > >> supported, you can reasonably expect that all routers process X. > > > > Ask an enterprise operator with 10 different router models from 3 > vendors ;-) > > If they want to use X they need to buy routers that support X. > > Or at least buy routers that ignore X instead of unilaterally dropping packets that contain X (be liberal in what you receive!). --001a113edd803b14be055befb85c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 5:20 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 20/10/2017 10:23, Toerless Eckert wrote:
> On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote:
>>> Instead of punting them because of presence of
>>> RSVP-router-alert option. And of course you can blame IP multi= cast: every router
>>> started to punt router-alert because of MLD (and of course us = multicast folks
>>> missed the chance to fix this in MLDv2 because it only tried t= o duplicate IGMPv3),
>>> but no RFC told developers to punt because of router-alert + v= alue in the router alert.
>>> AFAIK, the same applies to hop-by-hop option in general. Alas,= even rfc7045 did not discuss
>>> this issue.
>>>
>>> IMHO we need a mechanism that specifies: devices MUST NOT punt= /slow down packets
>>> because of the presence of this mechanism, but only because of= presence of
>>> (mechanism,value) where value is intended to be supported by d= evice. If the device
>>> can not do this, then it MUST IGNORE this mechanism and forwar= d packets with the mechanism
>>> as if the option was not present.
>>
>> That's pretty much what RFC7045/RC8200 say, except that they >> say it as a warning.
>
> It does not analyze the fact that the existing hop-by-hop option (and = options
> carried via it like router alert) are burned because existing router i= mple entations
> punt packets with hop-by-hop options even though they do ultimately no= t
> need to process the packets (hop by hop option they don't do or ro= uter-alert
> protocol they don't do).

We discussed that before agreeing on the words in 7045, which were +- adopt= ed
in 8200.

> And IMHO the existing hop-by-hop option is burned because the architec= ture
> RFCs did not well enough express in MUST statements that you must neve= r
> speed down packets because of hop-by-hop/router-alert unless you reall= y know
> you will support/do-something with that option. And that you achieve t= his eg.:
> by filtering/punting based on option/protocol. And that you can NOT do= anything else.

The protocol design really shouldn't talk about implementation choices<= br> in routers and the fact that FPGA people hate the IPv6 extension header
design like the plague, which has led to broken implementations. In 1994 there weren't any 'fast path' router designs, iirc, and the des= ign simply
didn't consider this problem to be a problem. So the assumption was tha= t
the forwarder CPU would pass on the whole header, and would only branch
off the main code path if it saw a HbH header. I know we're 20 years later, but logically that hasn't changed. The problem is that many vend= ors
didn't implement it; they sacrificed correctness for speed.

> This is also the root cause why in our analysis a hacky extraction by<= br> > eg: STUN signature inside UDP is a lot safer for existing networks tha= n relying
> on any hop-by-hop option. Badly standardized, badly implemented.

We agree on badly implemented ;-). IPv4 Options are badly implemented, too.=

>> As Ole said - within a domain where hop-by-hop option X is
>> supported, you can reasonably expect that all routers process X. >
> Ask an enterprise operator with 10 different router models from 3 vend= ors ;-)

If they want to use X they need to buy routers that support X.

Or at least buy routers that ignore X instead of unil= aterally dropping packets that contain X (be liberal in what you receive!).=


--001a113edd803b14be055befb85c-- From nobody Thu Oct 19 17:51:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09F1321D8 for ; Thu, 19 Oct 2017 17:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWwIvUzJl-bi for ; Thu, 19 Oct 2017 17:51:30 -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 9E622134958 for ; Thu, 19 Oct 2017 17:51:29 -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 v9K0pTMq048827; Thu, 19 Oct 2017 17:51:29 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9K0pNLp048818 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 19 Oct 2017 17:51:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Oct 2017 17:51:23 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 19 Oct 2017 17:51:23 -0700 From: "Manfredi, Albert E" To: Brian E Carpenter CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSTlUWQhFM45R6Eu7awJMeidiK6Lr50AA Date: Fri, 20 Oct 2017 00:51:23 +0000 Message-ID: References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 00:51:31 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > If they want to use X they need to buy routers that support X. Absolutely, and that's the rub, isn't it? In-band QoS, no matter really whe= ther it's done using an IPv6 3-tuple, or IP-agnostic 5-tuple (without encry= ption), is ultimately practical only inside walled gardens. These discussions bring me back to ... ATM. Trying to re-create ATM with IP= . But ATM died, in large part, because of this. Bert From nobody Fri Oct 20 07:40:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD921241F3 for ; Fri, 20 Oct 2017 07:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i507LsRYsFQb for ; Fri, 20 Oct 2017 07:40:19 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F06128D0D for ; Fri, 20 Oct 2017 07:40:19 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C9B4858C4B8; Fri, 20 Oct 2017 16:40:15 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id AA4FBB0CF23; Fri, 20 Oct 2017 16:40:15 +0200 (CEST) Date: Fri, 20 Oct 2017 16:40:15 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Message-ID: <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:40:23 -0000 On Fri, Oct 20, 2017 at 01:05:49PM +1300, Brian E Carpenter wrote: > > Problem with flow label is same as with hop-by-hop option: burned because > > nobody should dare use it for something useful with all the inconsistent > > code out in the field. Nothing against redefining it (with new encoding) ^^^^^^^^^^^^^^^^^^^ > There is no encoding. It's 20 opaque bits (and always has been). Please > read https://tools.ietf.org/html/rfc6437. Sorry, lame use of words. Meant to say "stronger definition of DO and DONTs which may include new semantics". I never tried to analyze the state of affairs on flow label as i did for router alert. Just taking it from what i heard, last from Joel at the pechakucha. Btw: IPv6 router alert did already fix one broken piece of IPv4 router alert, the registry is more flexible ;-)) Cheers Toerless > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Fri Oct 20 07:58:25 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0113421F for ; Fri, 20 Oct 2017 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d165_ssrZQNG for ; Fri, 20 Oct 2017 07:58:23 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1327D13420F for ; Fri, 20 Oct 2017 07:58:23 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D1B1A2D5065; Fri, 20 Oct 2017 14:58:21 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D7EA32006ECE7C; Fri, 20 Oct 2017 16:58:16 +0200 (CEST) From: Ole Troan Message-Id: <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_40ED0137-0798-46C3-8797-29937C593A68"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Date: Fri, 20 Oct 2017 16:58:16 +0200 In-Reply-To: <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> Cc: Brian E Carpenter , 6man WG To: Toerless Eckert References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 14:58:24 -0000 --Apple-Mail=_40ED0137-0798-46C3-8797-29937C593A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Toerless, >>> Problem with flow label is same as with hop-by-hop option: burned = because >>> nobody should dare use it for something useful with all the = inconsistent >>> code out in the field. Nothing against redefining it (with new = encoding) > = ^^^^^^^^^^^^^^^^^^^ >> There is no encoding. It's 20 opaque bits (and always has been). = Please >> read https://tools.ietf.org/html/rfc6437. >=20 > Sorry, lame use of words. Meant to say "stronger definition of DO and = DONTs > which may include new semantics". I never tried to analyze the state = of > affairs on flow label as i did for router alert. Just taking it from = what > i heard, last from Joel at the pechakucha. Right. If we take Joel's findings, then it appears the conclusion is = that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too = high probability for failure. It would be very nice to have that fixed. = Until then, we're forcing routers to parse transport headers. Best regards, Ole --Apple-Mail=_40ED0137-0798-46C3-8797-29937C593A68 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnqDwgACgkQvtpYqJhC 33YEBQ/+Po2kz5NVrXXIB/rtAvEF7VgmRkt2PZ/MuZGOTxR5W/6+oRhpyI+09ZKB TDbgflYInbgaGFMJp6T+mfjAwljjc5zLRFDlkoPzno1KIkunebH8PThxzDlzpjgl Y/ZaduhBGhnEOHWpPmJFKqqSPGU04uFYGqcXphRlC/j9fqyERYSJaHd4D57FHPC1 Fq4omow2SR1Bq0omZhXoe9ejmOdeK4B1vYgsz7EKp3TnhaLb4mxK9LJORIF4O1M4 N9kOdLDzOg3GvlFUfS08hihO7aoQnZJOZ1mI47dwf4jIOyFh+TAFMucpQrH6eipj b00njT53r2R9aDRUdJ1MonclfwzFXcoflbFFIvbitQPEtRay7x/NgiIQU2Ymtg7X Lyd1gBEYNhkJs+LqkcMhcoicc1a45eju1aeynGpwkpm96Ld8KI60Wadu9k2D1j8N fCvmxftpKi0tC1glzW0TeUaAC+05P951zTSgzxS7uJFyDGezBx3h4kcOiLS14gt4 Lbeo6L/FmSVRZIF8bA7be68m8V9SqQW4yYT0GGSwpP5iNXZcGAS8IIPa7uTZ4PjI HpcpMAZzD7cNfDw013X75VGnth3Io9zwUkhgbJIyFhcTHzebhVj/ODYyJr8RPCzG 2g2T2s48WFV+EizDraa3DBgO8kd3xd3MmlBArdLU2dIAcem7YBg= =wK1b -----END PGP SIGNATURE----- --Apple-Mail=_40ED0137-0798-46C3-8797-29937C593A68-- From nobody Fri Oct 20 08:34:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77258134210 for ; Fri, 20 Oct 2017 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrfVCA06wVoW for ; Fri, 20 Oct 2017 08:34:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D127E13423A for ; Fri, 20 Oct 2017 08:34:47 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7A7BE58C4B8; Fri, 20 Oct 2017 17:34:43 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5CDC1B0CF24; Fri, 20 Oct 2017 17:34:43 +0200 (CEST) Date: Fri, 20 Oct 2017 17:34:43 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Tom Herbert , 6man WG Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Message-ID: <20171020153443.GB3093@faui40p.informatik.uni-erlangen.de> References: <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:34:50 -0000 On Fri, Oct 20, 2017 at 01:20:40PM +1300, Brian E Carpenter wrote: > The protocol design really shouldn't talk about implementation choices > in routers and the fact that FPGA people hate the IPv6 extension header > design like the plague, which has led to broken implementations. In 1994 > there weren't any 'fast path' router designs, iirc, and the design simply > didn't consider this problem to be a problem. > > So the assumption was that > the forwarder CPU would pass on the whole header, and would only branch > off the main code path if it saw a HbH header. I know we're 20 years > later, but logically that hasn't changed. The problem is that many vendors > didn't implement it; they sacrificed correctness for speed. If you failed twice betting your architecture on correct implementations, maybe its time to try stronger DO and DONTs and explore other options to achieve a better result. Lets also remember that TLS is also seen as a tool to avoid broken middleboxes to mess up your traffic flow. However good intentioned the middlebox may be. So its not a bad idea to consider using encryption to allow only those onpath devices that you trust (to at least work correctly) to be able to do anything. Not easy to design, but possible. But something that would make me prefer doing it in a common "flow-layer" above IP instead of IP extension headers. Like what SPUD was suggesting as well. I also hate the fact that we're redefining the transport prototcol every time we need to improve something. Like we do now with QUIC. Should really start to think more about reusable transport layers. > We agree on badly implemented ;-). IPv4 Options are badly implemented, too. "Judge, its in my genes, my mother already exposed the same bad traits" Yeah, that defense is known to reduce sentencing time but should also make you want to design the next generation differently. > If they want to use X they need to buy routers that support X. http://dilbert.com/strip/2001-04-14 Enough comic relief ;-) Cheers Toerless > Brian > > > Cheers > > Toerless > > > >> But (excuse me repeating myself), whether X is worth doing is not > >> really a question for 6man. In this case, it belongs where QoS is > >> discussed, which is TSVWG. > >> > >> Brian > >> > >>> One simple way to do this is to define hop-by-hop-fixed that does say exactly this > >>> and then hopefully allow all existing hop-by-hop TLV to live underneath that > >>> fixed hop-by-hop-fixed option. But i would certainly suggest to review processing > >>> complexity and extensibility before such a conclusion. > >>> > >>> Personally i prefer inband UDP layer signaling, not because i do not like IPv6 > >>> option headers but because there is just no ubiquitous API to allow apps > >>> independent of OS enhancements to set arbitrary options headers, especially ones > >>> that are not yet defined (allow apps to fully defined the whole header bit by bit). > >>> Lets say from a javascript app in a browser. And i am more interested in ease of > >>> adoption than in architectural cleanlyness. But of course its perfectly valid to > >>> do the architectural clean appraoch and then prove me wrong and get that option > >>> adopted more ;-)) > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote: > >>>> On one hand, IETF defined extension headers as the extensibility > >>>> mechanism of IPv6, but yet on the other hand the message seems to be > >>>> to not use them because deployed devices don't correctly support the > >>>> protocol. The upshot is that we see proposals in other WGs of stuffing > >>>> network layer information into transport protocols (options or > >>>> payloads) with the full expectation that intermediate nodes will parse > >>>> into the transport layer, process the embedded information, and > >>>> possibly even overwrite transport layer information. IMO that is an > >>>> architectural abomination and further abandonment of the end to end > >>>> model! > >>>> > >>>>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else. > >>>>> And it might be a little too early to go into the details of packet formats etc. > >>>>> > >>>> Agreed, but I do think the 6man working group has a vested interest to > >>>> make sure that network layer information stays in the network layer. > >>>> At some point the information needed is going to be so complex that it > >>>> won't be able to be conveyed in any fields of the IP header. > >>>> > >>>> Tom > >>>> > >>>>> Best regards, > >>>>> Ole > >>>> > >>>> -------------------------------------------------------------------- > >>>> 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 > >> -------------------------------------------------------------------- > > -- --- tte@cs.fau.de From nobody Fri Oct 20 08:40:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF2513423A for ; Fri, 20 Oct 2017 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPrZ_0BxCRJV for ; Fri, 20 Oct 2017 08:40:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4BB133343 for ; Fri, 20 Oct 2017 08:40:07 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 55CD458C4B8; Fri, 20 Oct 2017 17:40:04 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 360FCB0CF24; Fri, 20 Oct 2017 17:40:04 +0200 (CEST) Date: Fri, 20 Oct 2017 17:40:04 +0200 From: Toerless Eckert To: Tom Herbert Cc: Brian E Carpenter , 6man WG Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Message-ID: <20171020154004.GC3093@faui40p.informatik.uni-erlangen.de> References: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 15:40:09 -0000 On Thu, Oct 19, 2017 at 05:40:29PM -0700, Tom Herbert wrote: > > If they want to use X they need to buy routers that support X. > > > > Or at least buy routers that ignore X instead of unilaterally dropping > packets that contain X (be liberal in what you receive!). Just ask the SIP crowd about their experiences with SIP proxies dropping every new option by default even the ones meant to be passed on transparently. Aka: the issue of middleboxes isn't limited to IP land. Ultimately its human nature that operators who can act as middle men have a tendency to misbehave, however good intentioned it may be. See my last mail on encryption. Cheers Toerless From nobody Fri Oct 20 09:33:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62013219B for ; Fri, 20 Oct 2017 09:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=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 jp-lfG3_-7bC for ; Fri, 20 Oct 2017 09:33:11 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 B50BE1330AE for ; Fri, 20 Oct 2017 09:33:11 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id z28so19119461qtz.13 for ; Fri, 20 Oct 2017 09:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8f1RW9v6TTu587KWWw4UIz8kFp9u6AbPrwLKhP+rl2A=; b=Zl6+0RpVMuh1tS1xJiaRW8mfKKT2gURXeq3LLdTKQtc+hVhj2kjtCgwKQy9okvnIon TRakxSckodf8OviLnBVJyv3BhKOeLb7YsOTJJwYBKdiYHFIK/m6fOciFWujIg+umiuNh D4fLUKvlELYwLWzwxzP+5KGU+aVGu+VSaCffl6nHoLf5RADL3Gt/ilGAHVLenHzrd1Ij Hj91A31o43vT31kiXt+oSYO4rgAHGeMYfXpS1Zb5w/OrWZOtjqE8qYxjIsIsiWn5td0L WGrMJ9D+5JRP8HuzfKjhrylFhjClSaSQ2QlQbplT+M0DwVtf7lemDO92lOzS9elzp3+f vORw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8f1RW9v6TTu587KWWw4UIz8kFp9u6AbPrwLKhP+rl2A=; b=X9KRBzT5XGSmocMnZazqialWHAMKBc3jsfVFGdt88pINpOR4IMk96Ii20ThmCh2/ol OIS5qgjX1pVWTDVMXaAV6QCVaDXPORUqkVVKLsNo+fruzRC8BeAe5ybOBj+TU4hu6IMM G85EfSsl4rWviUqcnBQQhtV/uhHe8SSKgN5+STF+vwtKb8d5dlaVKEZ8t5K7hJz1uZyP mCwT3AjyF8k86Cl3cSPk1M3Qn/irbe9kmMkNHcCaX/YlNqI+CdMchzQnviNsfRwbMaJK /Lb4G10SIVguml+rQEElsc559VcVQViyTxRlKGnWLxWTuXu2ZbxflMZW5diWwuAUtcZB rttw== X-Gm-Message-State: AMCzsaU3yToMWAod/mXAtl3cJxIlTlHUMwOECKdVVjj8VhZmFNKSlPsf KnbLWU1VfE3xbEKKhuJM3g/eclE2BEn60c90GDw65g== X-Google-Smtp-Source: ABhQp+Rk2MbfGFjanfia/BdEu+NCu9J3U3w67eq8B6jxA3CPNzNrfxCItU9HrL4NwH5+8aUCoQsEi/Nze148JuoKNz0= X-Received: by 10.237.60.46 with SMTP id t43mr8162761qte.294.1508517190856; Fri, 20 Oct 2017 09:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Fri, 20 Oct 2017 09:33:10 -0700 (PDT) In-Reply-To: <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> From: Tom Herbert Date: Fri, 20 Oct 2017 09:33:10 -0700 Message-ID: Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Ole Troan Cc: Toerless Eckert , 6man WG Content-Type: multipart/alternative; boundary="94eb2c0e80f04c8cae055bfd073b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:33:13 -0000 --94eb2c0e80f04c8cae055bfd073b Content-Type: text/plain; charset="UTF-8" On Fri, Oct 20, 2017 at 7:58 AM, Ole Troan wrote: > Toerless, > > >>> Problem with flow label is same as with hop-by-hop option: burned > because > >>> nobody should dare use it for something useful with all the > inconsistent > >>> code out in the field. Nothing against redefining it (with new > encoding) > > > ^^^^^^^^^^^^^^^^^^^ > >> There is no encoding. It's 20 opaque bits (and always has been). Please > >> read https://tools.ietf.org/html/rfc6437. > > > > Sorry, lame use of words. Meant to say "stronger definition of DO and > DONTs > > which may include new semantics". I never tried to analyze the state of > > affairs on flow label as i did for router alert. Just taking it from what > > i heard, last from Joel at the pechakucha. > > Right. If we take Joel's findings, then it appears the conclusion is that > right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too high > probability for failure. It would be very nice to have that fixed. Until > then, we're forcing routers to parse transport headers. > > Ole, I cannot find this presentation. I did find a presentation to nanog about problems with flow labels, but that had more to do with the fact that the flow label does not have to be persistent for the life of a connection which breaks stateful firewalls that require consistent routing for a flow. I didn't see how this is a problem for ECMP itself. Is there a draft on this that details what the problems are? Tom --94eb2c0e80f04c8cae055bfd073b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 20, 2017 at 7:58 AM, Ole Troan <otroan@employees.org> wrote:
Toerless,

>>> Problem with flow label is same as with hop-by-hop option: bur= ned because
>>> nobody should dare use it for something useful with all the in= consistent
>>> code out in the field.=C2=A0 Nothing against redefining it (wi= th new encoding)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^= ^^^^
>> There is no encoding. It's 20 opaque bits (and always has been= ). Please
>> read https://tools.ietf.org/html/rfc6437.
>
> Sorry, lame use of words. Meant to say "stronger definition of DO= and DONTs
> which may include new semantics". I never tried to analyze the st= ate of
> affairs on flow label as i did for router alert. Just taking it from w= hat
> i heard, last from Joel at the pechakucha.

Right. If we take Joel's findings, then it appears the conclusio= n is that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too h= igh probability for failure. It would be very nice to have that fixed. Unti= l then, we're forcing routers to parse transport headers.

Ole,

I cannot find this pres= entation. I did find a presentation to nanog about problems with flow label= s, but that had more to do with the fact that the flow label does not have = to be persistent for the life of a connection which breaks stateful firewal= ls that require consistent routing for a flow. I didn't see how this is= a problem for ECMP itself. Is there a draft on this that details what the = problems are?

Tom

=
--94eb2c0e80f04c8cae055bfd073b-- From nobody Fri Oct 20 09:41:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2C1342EC for ; Fri, 20 Oct 2017 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-k5Q8Wg3B-q for ; Fri, 20 Oct 2017 09:41:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7AB132D67 for ; Fri, 20 Oct 2017 09:41:35 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EFE6958C4B0; Fri, 20 Oct 2017 18:41:31 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D895CB0CF20; Fri, 20 Oct 2017 18:41:31 +0200 (CEST) Date: Fri, 20 Oct 2017 18:41:31 +0200 From: Toerless Eckert To: "Manfredi, Albert E" Cc: Brian E Carpenter , 6man WG Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Message-ID: <20171020164131.GD3093@faui40p.informatik.uni-erlangen.de> References: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:41:40 -0000 On Fri, Oct 20, 2017 at 12:51:23AM +0000, Manfredi, Albert E wrote: > Absolutely, and that's the rub, isn't it? In-band QoS, no matter really whether it's done using an IPv6 3-tuple, or IP-agnostic 5-tuple (without encryption), is ultimately practical only inside walled gardens. IMHO only true for DiffServ QoS unmodified, not for other forms of QoS. DiffServ QoS even has fundamental challenges inside walled gardens: - Way to complex to dynamically adjust queue share of classes in enterprise deployments (only useful in mission specific network with well defineable persistent traffic profiles). - Unnecessary differentiation now that a lot more media traffic is elastic and a lot more best effort traffic not buffer-bloaty > These discussions bring me back to ... ATM. Trying to re-create ATM with IP. But ATM died, in large part, because of this. I don't know. There is this cool flying car from the 50th in the Seattle Museum of Flight. I don't think its historic state proves that planes or cars are bad ideas. 1280 is the the 53 and flying cars are also coming back and so will QoS. Anyhow. Even though DSCP is in IPv6 header and this WG claims that it must be the ones deciding on onpath packet inspection, i fear the mayority here is not interested in QoS, so lets move the discussion to TSVWG. Cheers Toerless > Bert > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Fri Oct 20 09:51:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCB81342DD for ; Fri, 20 Oct 2017 09:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd1Xp8pxomVE for ; Fri, 20 Oct 2017 09:51:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6B71321BB for ; Fri, 20 Oct 2017 09:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/nM+E/VFgnu9p+6c5tGdgeTprBe97kLDk6uR+iJQgiI=; b=Jw0nliA8bmVurpYNsoHVZburJur8sorAXHmeJIbEPWNXDhkXzjx4Ud7ETc4SOueO3X8Lvy3SeOHA9nvLjb/KIrMDGdmnaa2EOA6lmBou1wQcSJEpRojSxmwMRShSf/PxvvyfIyD3yGLfLeCeWQpr1/LPjqtq74gkOaljPzN7cPw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from pc6 (109.149.199.6) by DB5PR07MB1558.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 20 Oct 2017 16:51:27 +0000 Message-ID: <00e201d349c3$581fb640$4001a8c0@gateway.2wire.net> From: "tom p." To: "Michael Richardson" , References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> <2654.1508345528@obiwan.sandelman.ca> Subject: Re: Loopback interface terminology issue Date: Fri, 20 Oct 2017 17:33:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.149.199.6] X-ClientProxiedBy: DB6PR07CA0192.eurprd07.prod.outlook.com (2603:10a6:6:42::22) To DB5PR07MB1558.eurprd07.prod.outlook.com (2a01:111:e400:5bc7::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9d82c565-64ce-463c-c21b-08d517dacec1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DB5PR07MB1558; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1558; 3:8OMhcxAek06Y7ANmqUl6jm7JfVq7SxnS7VflDM1F0wqvtpBRDv8jDP+TMQzjO20z7KLYAAFWO5w55bNxLl+3E4vaTzPoUz9PXu8EGqMgQuCUs54R0WV807yNxjQ4qQfTiaP4DvrsWBdadSXF21JpCYKn+YBpVz0oV/+A8AoJhMzs8S300vRXBxhLFFKTNcx/0Q5DUlpvz3YiQ6LoMScH3I6LcT/kjJ7MoXO1q59w6hOQ2MnK1fDB9WGSAENCtE8f; 25:w4LQS4PmzlmkPrQDbOtpeyrckNX5tGLqFiRYs0vhiZz5/X6ZJkTJbc79phxOsyxSpAOfyXkilRvx0AFx+N0LgzxubrB8GUFqFNebHewCLJPxEP20S10Eq5GvFwxU55R5ZvukFoli8cOFxBOIhJHagamQsQHrp3//Ku5ldooZepYzhbHQApdT/InVigWjpIUEhWNWqpx4kKcZIfRt8gi7n++U0vPtsERoXfDYEaG7ls9HW2EhSPvkyHydIMxBur+NLvBmgJ130G64UpS1axfK+ODFxJX9sxnx01ecmX2IWN8QAqz0xumXlvyg/8g9kh2M7PrlGDmRFNvYA4AKUAf8hA==; 31:iTFjz6lHa8nc8tLwDkwqHv6ocGp9rXf76iYhXDEgv2Ocl5qfjo75D05P7N1iM0hw2LzcT8xbonCfqqfcUh9lT88I4DBZGigOm+yibx0IJOw4mnJFzJwXoRs768+wqcUUSINlDxmiRooFoVFKl4xLboW8Xc+1jGe3EZIe+vHV2eebN/alN1fyVfnJQFXfXABS/Bn8fOYXe3uldXYzbOKhx4xAAQcJNlJOx1iQLECRiVM= X-MS-TrafficTypeDiagnostic: DB5PR07MB1558: X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231020)(10201501046)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB1558; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB1558; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1558; 4:OFD/nzo8wAMASmzSQHvfQ4Oli2pugQVGIR1ytq7tp/UsaPWj/NMuw1yBKCSyUQJyqzri2BhFDmBqqK3Kg1HuU24LAkL7XVnWVsiv0I8xt29fOqP/D8lXJhau54N029iRePlz0KDQECsWFxa1L77IV/X5cGiv4ASP2o67BZUdF6X3OEr9izSYHYlkAA5AufUcifwvj2KWb+pMLaSi83U6FYsfFnyC8rNXArK1ArvanIPrtxJoL7oO0OS64ebEDJ7P X-Forefront-PRVS: 0466CA5A45 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(51444003)(199003)(13464003)(24454002)(189002)(230700001)(4720700003)(1556002)(50466002)(25786009)(5660300001)(116806002)(6496005)(6246003)(478600001)(1456003)(229853002)(8676002)(6666003)(81156014)(9686003)(16526018)(23756003)(6486002)(44736005)(81686999)(50986999)(81816999)(53936002)(105586002)(68736007)(7736002)(8936002)(44716002)(101416001)(3480700004)(61296003)(2906002)(76176999)(305945005)(84392002)(50226002)(110136005)(33646002)(6116002)(14496001)(93886005)(106356001)(316002)(66066001)(86362001)(47776003)(189998001)(3846002)(62236002)(97736004)(81166006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1558; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1558; 23:X194CwVQEoLxb2zvFpRpEphMHfUA5MG8y49raKX?= =?iso-8859-1?Q?FJbDm6fT7iaqjTBjXnVehWn+sJqFyg1u0c7cA+XfdStODZ5zA54hg7/OTh?= =?iso-8859-1?Q?ASWvfYMKHOpINsIYWPRQCsuV4m9x/hgs8L2QQasLU115NkpglEFbH8LRrl?= =?iso-8859-1?Q?JF+WRb1BSR6tiEt7jpVqJYXuGBBZDjYw5Mg9XZZbzf4mGgDIzzx7k/c6lX?= =?iso-8859-1?Q?C0QIC/djhB0VaFl5ydMAwRE6Fx2EtlvP495ndPuW9iZlappUULHf2Sdpg1?= =?iso-8859-1?Q?ucO+0RnK8o8y3vahGxc7r7bG++U+p6CD2CCwOA4T6q2wH30j274nBBMwG2?= =?iso-8859-1?Q?QSEuhg1WSeXy9mKgM5e708tYbUBLgZLjzlDEslJ6zAgIqw6K7oge20OvaC?= =?iso-8859-1?Q?0+nYaw8RDXLw8ii/kcGmGU0TgV3tdrFByPX4ZYFhP5zaEn1NzWKh0ZrkwR?= =?iso-8859-1?Q?lp1T3iUpmP6wm//b9zQqbD2rFPRuWDPHn8hEWXC7h/SZEj3vWjjOaWH8Rh?= =?iso-8859-1?Q?9BKPjumN/7Yw1RzyJTdtJLTM/Fl1AVhe4OtezyojahMyJ75Vv6D4BBUVAE?= =?iso-8859-1?Q?Et4A5890WGDQIoOWDNwFJcAX81ZpFam1YQoFrJ9COEffVnITOvEMPwnRv3?= =?iso-8859-1?Q?hbbcu/Yuq4M+80zjTCuxSTm4RhV0xK8CCa0zCj1eaZ4RQvDMeUYTEYsM0s?= =?iso-8859-1?Q?66dthp8pm+3wrEEOl8LuXrARGdpDcxx9hjSJQwpnNA5+5ADfG0QDWMyk0T?= =?iso-8859-1?Q?Jg9pjRdy5/1IcYLfKA7KZ60A+v+xVPN5ztoWuFGkr6kvV6uAQiG6KeTiGK?= =?iso-8859-1?Q?pN4KDKoSzltX5zjtcyF0WYebq2bETwNp9PlOcmYLrRapLChZAA8HK6IZkL?= =?iso-8859-1?Q?bAQ4HPKdBVhzOWbZTYFaMsI490b+2f6wddzQc4Z37000KpzCRvdYR8Q6CL?= =?iso-8859-1?Q?YVCJyphXXY769001189SX0WkrzYXOY8PMz5z1jqyHm9o5ScT5agVeLR3hi?= =?iso-8859-1?Q?usm/wYqj8GKaxghHC2ebCPXCKnFYETPaO7RRBSXLND3Nef2FGV8xqSxFQ/?= =?iso-8859-1?Q?kBVPR6UhK4w2kbDjUzXtZVAjy2UHT3pvo3zpZaZ40RFZJirDZRD3ipFb+t?= =?iso-8859-1?Q?cqxL4kCprTOiBiiqlTPyl22+t5WlQV02XHx5OLeeK0bSepCtFpvxBlpAah?= =?iso-8859-1?Q?j1kPf5DyJ2d+Gnux1dfYV5iiJCcmrSAXI5yv6/DFatDzlKMd5ptgiZigJL?= =?iso-8859-1?Q?matIdOz6fLW+vnVpKIfGqjnJWK6Rg/8YX6dylB+qzAbzEqRWwgX4cmZJ88?= =?iso-8859-1?Q?YuJkFOzdoJnAxtb/Why6GY+2jB9pNy3UN0S1zFDkGwtLrgIS8BqXanJ3WU?= =?iso-8859-1?Q?1NNUK2Ovfex0w9u4n6eEQu8hZL7nNElC9umENHGKe2topjjaTZwxqlMHYO?= =?iso-8859-1?Q?8PIsy2g0AF7Atz7MuLwaeSpuXV6ox46FCneMrVxIa60DYLUjkcFQTf/aOn?= =?iso-8859-1?Q?saUnbtZ8GfOFYOfIXZuU=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1558; 6:j0CEVpcYsEQWeE3POjgC5tQzL+fk+2AnON6YnahM8ACutNWCqn4SiIruU3OadYR7Sxd9KpqZWZ+sm9tnLM/9xrbV72ESwyHqlqn7Ym//MEFzJeCcHX8qVmm5QW55+3kE8tHnUDwvr7U5tO0hnrFaA/VzVJaSJMbt291NZPVLxsj+lf70d8V2Ok2/7QSkVHNxvHV2jns5FuH4zkxhAFzCKTPns1GFpcTZcL6sAL/mTIipwAh6ZYkUkcKB1CWMOV/WJUTgvvnIOjxyWWOfmdfCWT0qxffpcTzKHVlMHyj0mqQ3wFmeNIwULQfp5NCneETHJKtRwcP5jlJNoqlBNSp1cg==; 5:eP1zmNCwLOtCtLX/sclgV+Gz1rFpzDQVlSnf9VE7oMyuwiS7+aP7zBBp03oUIHqpwJNaPux0mHwoghed0ayDtV1pPZgqa4P4FD9Q/9t78z+FPD/pUVLOwtuZJpzmHguTU5RPPvS86L41l8L3XllVgg==; 24:+wp0E0ZxnW2YRki9BDq4vN86i2GN6OEtuc6uvOKsGSk/N7bRSKGyoZDLlMBt5sth+88MzP/wcNhBtcK3c7iynzy+gopQW6sUgmLL0UQbaRw=; 7:XnFLS6jIKnvHNZUBPknYmNwVD+dp5sWUl+4qOYAd7LyQXPlF4dK2cfPJrovoy3ubXTBHsxJKrg6V5Kpbs39G6dUMK38PP34v+R2pHfNvO2QVIr2LmOcaRJXehdkt+f7eYex1nCl1GTnLmtnOdXfRn/nL3MxZGHNLq5+YNIQu4jznGLBb6G6+j9vKOi6YM8GMVBquKZ71DMSa5m+rcF7OtGnnNwdngqAtYbHRvhhGAfE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2017 16:51:27.9407 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d82c565-64ce-463c-c21b-08d517dacec1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1558 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 16:51:34 -0000 ----- Original Message ----- From: "Michael Richardson" To: Sent: Wednesday, October 18, 2017 5:52 PM > Brian E Carpenter wrote: > brian> Well yes; indeed this topic is touched on in many RFCs but nowhere is > brian> it defined as part of the basic architecture, which is my main > brian> point. Using a concept that has no principal definition is generally > brian> a source of confusion. > > joel> We tended not to define software interfaces for things which are not > joel> required for interoperability. How you describe an address which is > joel> not bound to a physical interface is entirely irrelevant outside the > joel> scope of your own operating system. > > brian> That's not our experience in trying to be precise in saying what we > brian> mean in draft-ietf-anima-autonomic-control-plane. > > to restate Brian's point slightly differently: > > The issue is not to tell people how to implement things in their software, > but rather to make it clear that we need a standard hook on which to hang our > addresses. > > We'd rather not use the term "loopback interface" at all here if we had > another name defined in an RFC somewhere. > > I think that there is some significant text that might need to be written > when defining this hook when in a strong-host model. > > But, let me also ask a different question: are there router operating systems > where there is a way to hang an address on something which is not a > virtual/loopback interface? If so, what do they call it? When I first came to IP, I was surprised to find that L3 addresses were assigned to interfaces, as opposed to nodes, the latter having been the case with other networks I had used previously. I have always seen the creation of a virtual interface as a quirk which overcomes this absence of a node address, or node identifier in the IP namespace. I first encountered the term 'loopback interface' in Cisco documentation, which talks of the ability to configure a 'virtual interface, referred to as a loopback interface'. So for me, 'loopback interface' has always been the Cisco term for a virtual interface but why it should be loopback, as opposed to virtual, I have never found out. Whatever the name is, it does provide an identifier for the node and one, at least in some systems, that is always up and so provides a stable identifiier for protocols that need one, such as a router-id in BGP; and you can have more than one such identifier, separating functions, perhaps by priority, to prevent DoS attacks.. Tom Petch > If there are differences in software interfaces in some place that we would > be respecting by abstracting this requirement? > After 35+ years of router operating systems, has anyone actually innovated in this way? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Fri Oct 20 10:12:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22991342F0 for ; Fri, 20 Oct 2017 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57xHEYnWetcz for ; Fri, 20 Oct 2017 10:12:31 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE78132F30 for ; Fri, 20 Oct 2017 10:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9KHCUVM036594; Fri, 20 Oct 2017 10:12:30 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9KHCR2O036554 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 20 Oct 2017 10:12:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Oct 2017 10:12:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 20 Oct 2017 10:12:26 -0700 From: "Templin, Fred L" To: "tom p." , Michael Richardson , "ipv6@ietf.org" Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRtByPxn1iJZL+kqA+Ph9pp2qTaLnGukAgAXe6fqAAAB1cA== Date: Fri, 20 Oct 2017 17:12:26 +0000 Message-ID: <712d6ca8e6cc41d4b84704d21813e672@XCH15-06-08.nw.nos.boeing.com> References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> <2654.1508345528@obiwan.sandelman.ca> <00e201d349c3$581fb640$4001a8c0@gateway.2wire.net> In-Reply-To: <00e201d349c3$581fb640$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:12:34 -0000 Below: > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of tom p. > Sent: Friday, October 20, 2017 9:33 AM > To: Michael Richardson ; ipv6@ietf.org > Subject: Re: Loopback interface terminology issue >=20 > ----- Original Message ----- > From: "Michael Richardson" > To: > Sent: Wednesday, October 18, 2017 5:52 PM >=20 > > Brian E Carpenter wrote: > > brian> Well yes; indeed this topic is touched on in many RFCs but > nowhere is > > brian> it defined as part of the basic architecture, which is my > main > > brian> point. Using a concept that has no principal definition is > generally > > brian> a source of confusion. > > > > joel> We tended not to define software interfaces for things which > are not > > joel> required for interoperability. How you describe an address > which is > > joel> not bound to a physical interface is entirely irrelevant > outside the > > joel> scope of your own operating system. > > > > brian> That's not our experience in trying to be precise in saying > what we > > brian> mean in draft-ietf-anima-autonomic-control-plane. > > > > to restate Brian's point slightly differently: > > > > The issue is not to tell people how to implement things in their > software, > > but rather to make it clear that we need a standard hook on which to > hang our > > addresses. > > > > We'd rather not use the term "loopback interface" at all here if we > had > > another name defined in an RFC somewhere. > > > > I think that there is some significant text that might need to be > written > > when defining this hook when in a strong-host model. > > > > But, let me also ask a different question: are there router operating > systems > > where there is a way to hang an address on something which is not a > > virtual/loopback interface? If so, what do they call it? >=20 > When I first came to IP, I was surprised to find that L3 addresses were > assigned to interfaces, as opposed to nodes, the latter having been the > case with other networks I had used previously. I have always seen the > creation of a virtual interface as a quirk which overcomes this absence > of a node address, or node identifier in the IP namespace. >=20 > I first encountered the term 'loopback interface' in Cisco > documentation, which talks of the ability to configure a 'virtual > interface, referred to as a loopback interface'. So for me, 'loopback > interface' has always been the Cisco term for a virtual interface but > why it should be loopback, as opposed to virtual, I have never found > out. >=20 > Whatever the name is, it does provide an identifier for the node and > one, at least in some systems, that is always up and so provides a > stable identifiier for protocols that need one, such as a router-id in > BGP; and you can have more than one such identifier, separating > functions, perhaps by priority, to prevent DoS attacks.. In IP, addresses are assigned to interfaces. So, when there is no other alternative the address can be assigned to a loopback (or other virtual interface). Similarly, advertised and delegated prefixes need to be added to an interface's prefix list. Delegated prefixes can be added to a the prefix list of a downstream interface (i.e., even if the downstream interface happens to be a loopback or other virtual interface). Prefixes received in a Router Advertisement (RA) with 'L=3D1' in the Prefix Information Option (PIO) are added to the prefix list of the interface over which the RA was received and with "on-link" set. Prefixes received in RA PIOs with 'L=3D0' are a bit strange, however. RFC4861 seems to imply that the prefixes are associated with the prefix list of the interface over which the RA was received, but the "on-link" value is not set since 'L=3D0' contains no information as to whether the prefix is on- or off-link. (If the prefix was already in the interface's prefix list, however, the "on-link" value is not changed.) Thanks - Fred > Tom Petch >=20 > > If there are differences in software interfaces in some place that we > would > > be respecting by abstracting this requirement? > > After 35+ years of router operating systems, has anyone actually > innovated in this way? > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Oct 20 11:20:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EFB134220 for ; Fri, 20 Oct 2017 11:20:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR-Yz1KHBkLz for ; Fri, 20 Oct 2017 11:20:08 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8E213234B for ; Fri, 20 Oct 2017 11:20:08 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 62D8B2D50F6; Fri, 20 Oct 2017 18:20:06 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7BA352006FE4FF; Fri, 20 Oct 2017 20:20:04 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3B39F044-6F45-4A2B-BBF4-75A4FB39D4AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Date: Fri, 20 Oct 2017 20:20:03 +0200 In-Reply-To: Cc: Toerless Eckert , 6man WG To: Tom Herbert References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:20:11 -0000 --Apple-Mail=_3B39F044-6F45-4A2B-BBF4-75A4FB39D4AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tom, > >>> Problem with flow label is same as with hop-by-hop option: burned = because > >>> nobody should dare use it for something useful with all the = inconsistent > >>> code out in the field. Nothing against redefining it (with new = encoding) > > = ^^^^^^^^^^^^^^^^^^^ > >> There is no encoding. It's 20 opaque bits (and always has been). = Please > >> read https://tools.ietf.org/html/rfc6437. > > > > Sorry, lame use of words. Meant to say "stronger definition of DO = and DONTs > > which may include new semantics". I never tried to analyze the state = of > > affairs on flow label as i did for router alert. Just taking it from = what > > i heard, last from Joel at the pechakucha. >=20 > Right. If we take Joel's findings, then it appears the conclusion is = that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too = high probability for failure. It would be very nice to have that fixed. = Until then, we're forcing routers to parse transport headers. >=20 > Ole, >=20 > I cannot find this presentation. I did find a presentation to nanog = about problems with flow labels, but that had more to do with the fact = that the flow label does not have to be persistent for the life of a = connection which breaks stateful firewalls that require consistent = routing for a flow. I didn't see how this is a problem for ECMP itself. = Is there a draft on this that details what the problems are? I believe Joel's presentation was for a load balancer application. Purely for ECMP it only has a consequence for reordering of packets. = Which may be bad enough. But sending packets of the same flow along different paths has problems = with any network function that requires state. NAT64, virtual reassembly = of fragments, ACLs and what not. Not that the network should do any of = those of course. Best regards, Ole --Apple-Mail=_3B39F044-6F45-4A2B-BBF4-75A4FB39D4AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnqPlMACgkQvtpYqJhC 33YhVw//cw7wT3bhV2dS+wLXUOtGkQfdzaqCtoIDHpMrhXK3lvclSFVHIS9f5l5m 6myBgaz33yqFKWGk+rGb6agqAIUYTuW4rOAOhEQUDLbcN4ZoEqdIlzCbua0fho7q MPVsYmnDfTscIJAHjEwVqIxJLJ7yam35HMYlFmhyHcwprzNm9iWtGraYgllpIqJa 8OYIhKdefA+IVVK/thwxJpAcmLjOct77N7knu12FXoGBbAE6QZGWqLbrw5BiTDkK 6cPJev71t1aRxqBbnt6prlcuYGx7pBveM9Ae1JYEqOODQO5nPLUp8DRjFhVmQI/T L+sr+bicg2uu7VmL+m7JwiKnKjIcBGXnD4hwkaYbE/7//4MPfOyrGPvQxoHqat/w vH8jKswY49ADPFo0DRV/zFotC6RT4RtOamxsJizJkOH4zE+PvR8Poi7xzRmiv2sB TBaq9ErI4P1NLpnYplxM/c1bOVF9N3JE7f40NhYBhk+SIWkvaoWAI6S98JUcAJZs 4f3MsYqGanw7xRjys6/8P68IyNWLZZcqKPPG0HowBZJRRkghNIb7lUSPBxZDjgHL 1Gl8f4/YFbL7uDSEMUmAA4o+RfqTkWSoYf40OaGAygD0X18k/zOICWGFKcpjgxdc 0U91T2zp9Y4ODOLXTQYV06xs4N8nx97K3Eeq5l8rd7gx+bMJFPI= =+McB -----END PGP SIGNATURE----- --Apple-Mail=_3B39F044-6F45-4A2B-BBF4-75A4FB39D4AF-- From nobody Fri Oct 20 11:36:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6621342FC for ; Fri, 20 Oct 2017 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X361NkQOZ9r for ; Fri, 20 Oct 2017 11:36:36 -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 2FA6713234B for ; Fri, 20 Oct 2017 11:36:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRA73170; Fri, 20 Oct 2017 18:36:34 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 20 Oct 2017 19:36:33 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 11:36:28 -0700 From: Lin Han To: "Manfredi, Albert E" , Brian E Carpenter CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdJXqSaZrOZDMkmbu8uyH2nDSw== Date: Fri, 20 Oct 2017 18:36:27 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010206.59EA4232.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a9594e3c0fa60c315aeab1c5e2f11ae Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:36:39 -0000 Hi, Albert -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E Sent: Thursday, October 19, 2017 5:51 PM To: Brian E Carpenter Cc: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport= -qos-00.txt] -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > If they want to use X they need to buy routers that support X. Absolutely, and that's the rub, isn't it? In-band QoS, no matter really whe= ther it's done using an IPv6 3-tuple, or IP-agnostic 5-tuple (without encry= ption), is ultimately practical only inside walled gardens. [LH] At this moment, yes. As I stated in the scope, the current solution is= for a single admin domain. The inter-domain needs more study. These discussions bring me back to ... ATM. Trying to re-create ATM with IP= . But ATM died, in large part, because of this. [LH] ATM is failed due to many reasons, scalability is one of it. This solution is not intended to replace completely the best-effort transpo= rt service. The solution is only for those application which really needs a= flow level QoS, such as AR/VR, tactile internet, etc. From this sense, it = does not sacrifice the scalability of IP. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Fri Oct 20 11:43:56 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4E2132EDA for ; Fri, 20 Oct 2017 11:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shUbrW0U66Nk for ; Fri, 20 Oct 2017 11:43:52 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 7C67B13234B for ; Fri, 20 Oct 2017 11:43:52 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 17so15429133qkq.8 for ; Fri, 20 Oct 2017 11:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oZhR/kouKgw+qyVdyfsiRWgxOGFUQGvjCcAF5CRUYQ4=; b=yqmmupdLzF+oxMyB7UCpQYs9qf9yTYQeT6LcitkJkPOWw/PJjufMmcw2eXHuCKGjM5 Vc4X83mqXuoK/JFMxPhzfAW9FTi9RAcQEnWXsvzC5nMpfFs9WIYNFY21AZFbo46nMmX5 w9DiPPsOy29dJBRwTIEhOZpVGNhEhs33vxSV4CuxqrUQ5kDNuRHedJtj8C4Boq9g/VBM LEEMU98aq4ZzbvZMGB26tUOG3ZgcSOeEIU0VOm0VuiRlRSfO6/lcAvhY7+WiUel/0y1g b19lmm9qK9UaF8HoWsvl+Antkbf2tDvmGuGQL1NweI9DQmXtWMw+mo2WUX1QvksYSm6R QBMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oZhR/kouKgw+qyVdyfsiRWgxOGFUQGvjCcAF5CRUYQ4=; b=T+oLYv+rdjCEh3b/HGvLrdqkGc5DIUsw8bFotRWtst9Z/jHjhp1Dtx1fjk42H6CNJM 9b7Imz33tennsCdZMH5c+2Vf4ln+GCs1wZenjW2TVXgCrJHNVdMHbYFuHCxgkdztcxUu DVIGBofgfwLjeq5qlEgmh5i5uhTLiW+duTMCHJiDu44jIANAC2RVABeSKY8CCiGlTqS+ AqiSGjW4tTjzaPOOwuNSnlABW60VeMCCDd0zUdVbiRnkdT+LUJ07HGzUyRiNec4Op72M nsKv+64wqvTOa5C+yaFxbTmknq3fr9eIokAeLQ72Fjkl3dIBMqevlhUv+TY/2MQ3txty ZYkg== X-Gm-Message-State: AMCzsaXHARP4/kfD6yy8TKY08qd3W/8M8mx0t29isXeuizD5HAxDD/vi i07+GKvg2jpFRwpSva0Pc4qfDl/8wJeW9WxLO01hoA== X-Google-Smtp-Source: ABhQp+REc9hhba3La8RwHZZLFJDAJSPceIn3fUCsBzRYaEOKbXCOooqyiLSjMIeMjQfhK0m6FUCsyMCwgp1f17Zv/MI= X-Received: by 10.55.106.132 with SMTP id f126mr8072393qkc.295.1508525031640; Fri, 20 Oct 2017 11:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Fri, 20 Oct 2017 11:43:51 -0700 (PDT) In-Reply-To: References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> From: Tom Herbert Date: Fri, 20 Oct 2017 11:43:51 -0700 Message-ID: Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Ole Troan Cc: Toerless Eckert , 6man WG Content-Type: multipart/alternative; boundary="001a11487b0aa56c02055bfeda71" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 18:43:54 -0000 --001a11487b0aa56c02055bfeda71 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 20, 2017 at 11:20 AM, Ole Troan wrote: > Hi Tom, > > > >>> Problem with flow label is same as with hop-by-hop option: burned > because > > >>> nobody should dare use it for something useful with all the > inconsistent > > >>> code out in the field. Nothing against redefining it (with new > encoding) > > > > ^^^^^^^^^^^^^^^^^^^ > > >> There is no encoding. It's 20 opaque bits (and always has been). > Please > > >> read https://tools.ietf.org/html/rfc6437. > > > > > > Sorry, lame use of words. Meant to say "stronger definition of DO and > DONTs > > > which may include new semantics". I never tried to analyze the state of > > > affairs on flow label as i did for router alert. Just taking it from > what > > > i heard, last from Joel at the pechakucha. > > > > Right. If we take Joel's findings, then it appears the conclusion is > that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too high > probability for failure. It would be very nice to have that fixed. Until > then, we're forcing routers to parse transport headers. > > > > Ole, > > > > I cannot find this presentation. I did find a presentation to nanog > about problems with flow labels, but that had more to do with the fact that > the flow label does not have to be persistent for the life of a connection > which breaks stateful firewalls that require consistent routing for a flow. > I didn't see how this is a problem for ECMP itself. Is there a draft on > this that details what the problems are? > > I believe Joel's presentation was for a load balancer application. > > Purely for ECMP it only has a consequence for reordering of packets. Which > may be bad enough. > But sending packets of the same flow along different paths has problems > with any network function that requires state. NAT64, virtual reassembly of > fragments, ACLs and what not. Not that the network should do any of those > of course. > > Ole, Right, but of course there's never been any requirement in IP that packets in a flow always follow the same path or are never received out of order. Even outside of using the flow label there are other ways that that for packets of a flow to take different paths or be OOO (fragmentation, UDP encapsulation, routing change, etc.). I don't see that there is a protocol problem with flow labels that would justify a general recommendation against their use. Maybe there should be a discussion in v6ops about this. Tom --001a11487b0aa56c02055bfeda71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 20, 2017 at 11:20 AM, Ole Troan <otroan@employees.org> wrote:
Hi Tom,

> >>> Problem with flow label is same as with hop-by-hop option= : burned because
> >>> nobody should dare use it for something useful with all t= he inconsistent
> >>> code out in the field.=C2=A0 Nothing against redefining i= t (with new encoding)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^= ^^^^^^^
> >> There is no encoding. It's 20 opaque bits (and always has= been). Please
> >> read https://tools.ietf.org/html/rfc6437.<= br> > >
> > Sorry, lame use of words. Meant to say "stronger definition = of DO and DONTs
> > which may include new semantics". I never tried to analyze t= he state of
> > affairs on flow label as i did for router alert. Just taking it f= rom what
> > i heard, last from Joel at the pechakucha.
>
> Right. If we take Joel's findings, then it appears the conclusion = is that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too hig= h probability for failure. It would be very nice to have that fixed. Until = then, we're forcing routers to parse transport headers.
>
> Ole,
>
> I cannot find this presentation. I did find a presentation to nanog ab= out problems with flow labels, but that had more to do with the fact that t= he flow label does not have to be persistent for the life of a connection w= hich breaks stateful firewalls that require consistent routing for a flow. = I didn't see how this is a problem for ECMP itself. Is there a draft on= this that details what the problems are?

I believe Joel's presentation was for a load balancer applicatio= n.

Purely for ECMP it only has a consequence for reordering of packets. Which = may be bad enough.
But sending packets of the same flow along different paths has problems wit= h any network function that requires state. NAT64, virtual reassembly of fr= agments, ACLs and what not. Not that the network should do any of those of = course.

Ole,

Right, but o= f course there's never been any requirement in IP that packets in a flo= w always follow the same path or are never received out of order. Even outs= ide of using the flow label there are other ways that that for packets of a= flow to take different paths or be OOO (fragmentation, UDP encapsulation, = routing change, etc.). I don't see that there is a protocol problem wit= h flow labels that would justify a general recommendation against their use= . Maybe there should be a discussion in v6ops about this.

Tom

--001a11487b0aa56c02055bfeda71-- From nobody Fri Oct 20 12:00:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A557134462 for ; Fri, 20 Oct 2017 12:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uoa8J7DtijL for ; Fri, 20 Oct 2017 12:00:31 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C925134479 for ; Fri, 20 Oct 2017 12:00:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9KJ0OkF020736; Fri, 20 Oct 2017 12:00:24 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9KJ0E7c020470 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 20 Oct 2017 12:00:14 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Oct 2017 12:00:13 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Fri, 20 Oct 2017 12:00:13 -0700 From: "Manfredi, Albert E" To: Lin Han , Brian E Carpenter CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdJXWQhFM45R6Eu7awJMeidiK6LtFbvw Date: Fri, 20 Oct 2017 19:00:13 +0000 Message-ID: <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:00:32 -0000 -----Original Message----- From: Lin Han [mailto:Lin.Han@huawei.com]=20 > ATM is failed due to many reasons, scalability is one of it. > This solution is not intended to replace completely the best-effort trans= port > service. The solution is only for those application which really needs a = flow > level QoS, such as AR/VR, tactile internet, etc. From this sense, it does= not > sacrifice the scalability of IP. Or at least, does not sacrifice it as much? ATM also had a UBR service. But my point was only that out in the wild, you have no guarantee that the = routers in the path will know what to do with your in-band QoS demands. Onl= y in situations where all the routers are in your control will you have tha= t guarantee. But sure, in walled gardens, these cool ideas can be made to w= ork. On the other hand, also in these controlled environments, another option, f= requently, is to "throw bandwidth at the problem." Give yourself plenty of = headroom. It's less elegant and less fun, but it works great. Bert From nobody Fri Oct 20 12:05:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E082134305 for ; Fri, 20 Oct 2017 12:05:02 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3L2jNFWG1YR for ; Fri, 20 Oct 2017 12:05:00 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FDB132320 for ; Fri, 20 Oct 2017 12:05:00 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id E557E2D50B7; Fri, 20 Oct 2017 19:04:59 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0F333200702D61; Fri, 20 Oct 2017 21:04:58 +0200 (CEST) From: Ole Troan Message-Id: <6D75068F-9B19-4ECA-878F-5AC22A48AB1A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_EEB0798F-6641-4507-9056-2BDD409ED7F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Date: Fri, 20 Oct 2017 21:04:57 +0200 In-Reply-To: Cc: Toerless Eckert , 6man WG To: Tom Herbert References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:05:02 -0000 --Apple-Mail=_EEB0798F-6641-4507-9056-2BDD409ED7F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, > > >>> Problem with flow label is same as with hop-by-hop option: = burned because > > >>> nobody should dare use it for something useful with all the = inconsistent > > >>> code out in the field. Nothing against redefining it (with new = encoding) > > > = ^^^^^^^^^^^^^^^^^^^ > > >> There is no encoding. It's 20 opaque bits (and always has been). = Please > > >> read https://tools.ietf.org/html/rfc6437. > > > > > > Sorry, lame use of words. Meant to say "stronger definition of DO = and DONTs > > > which may include new semantics". I never tried to analyze the = state of > > > affairs on flow label as i did for router alert. Just taking it = from what > > > i heard, last from Joel at the pechakucha. > > > > Right. If we take Joel's findings, then it appears the conclusion is = that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too = high probability for failure. It would be very nice to have that fixed. = Until then, we're forcing routers to parse transport headers. > > > > Ole, > > > > I cannot find this presentation. I did find a presentation to nanog = about problems with flow labels, but that had more to do with the fact = that the flow label does not have to be persistent for the life of a = connection which breaks stateful firewalls that require consistent = routing for a flow. I didn't see how this is a problem for ECMP itself. = Is there a draft on this that details what the problems are? >=20 > I believe Joel's presentation was for a load balancer application. >=20 > Purely for ECMP it only has a consequence for reordering of packets. = Which may be bad enough. > But sending packets of the same flow along different paths has = problems with any network function that requires state. NAT64, virtual = reassembly of fragments, ACLs and what not. Not that the network should = do any of those of course. >=20 > Ole, >=20 > Right, but of course there's never been any requirement in IP that = packets in a flow always follow the same path or are never received out = of order. Even outside of using the flow label there are other ways that = that for packets of a flow to take different paths or be OOO = (fragmentation, UDP encapsulation, routing change, etc.). I don't see = that there is a protocol problem with flow labels that would justify a = general recommendation against their use. Maybe there should be a = discussion in v6ops about this. Absolutely. There is no protocol problem with flow labels. Cheers, Ole --Apple-Mail=_EEB0798F-6641-4507-9056-2BDD409ED7F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnqSNkACgkQvtpYqJhC 33ZJ0BAAuVTk0i50lq4P2GBhCm79XuUf+T2w6cdwBF9TVc79TmXIlcBeiNsWf0Qs f+lnyHaR9LqWAVujnfuM2d87KTm+iS3dihytfJ4DCNLrP/AVW9BJ4kVKw8u7Fle3 WgyYBKstKe987NK9oxyVke/qa0kGvY7d1LSC1oNop4kq5bRGWmHdRy1XEWKueahs eqpyAKxKhCk+6uuethyflxlL8e5qn1C4vcACcIbqvwil/5ysLuVrEYSEJBDwcykm bN3hmCX0UBOlbtsjqdOJ9OW8Xr0VzsOWOlds1OvkXcNsZG3glvi6jSUA4EOqxoMB D491DBm+LBYKLrS012MgFzK+oXgAw6c27DDkad1vlAwQTas9CqowzRclvYcD3j4b kW7wHm6g6XYiE6RdnkirTLqJGfFBXSNTJcgnZoGcPYRtCTZLzffTu4bx+ZDllJel XeqB5NTCuromtdn+YVHpdAyW90Euo5MuLPkb3NKtW/4Z4vLp95lZlBTOgu2O74/L HthruS7ZIAWRc8cjjlWLuumWKK32aG45o1DlFsSa1Na4TuVjIwDeA3Fugf3u5UZG AKwf5YggMhS1JnrKHIYl8u08NpkQQceRNGhJ7Tb6659Es3lREfLJIwxQMiPZLJeB LdD35hKbsQQfklAMhwtY2R0AZUt1hLRIStad2GWlZRjtAyCK+ZA= =EZTH -----END PGP SIGNATURE----- --Apple-Mail=_EEB0798F-6641-4507-9056-2BDD409ED7F5-- From nobody Fri Oct 20 12:06:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB56E134317 for ; Fri, 20 Oct 2017 12:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AAYjKf7EMNe for ; Fri, 20 Oct 2017 12:06:42 -0700 (PDT) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FD8134308 for ; Fri, 20 Oct 2017 12:06:42 -0700 (PDT) X-AuditID: 60721c4c-3f3ff7000000a121-32-59ea4940d8ad Received: from VAADCEX45.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A1.F3.41249.0494AE95; Fri, 20 Oct 2017 15:06:40 -0400 (EDT) Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX45.cable.comcast.com (147.191.103.222) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 20 Oct 2017 15:06:39 -0400 Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1347.000; Fri, 20 Oct 2017 15:06:38 -0400 From: "Leddy, John" To: Tom Herbert , Ole Troan CC: 6man WG Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdAXWVOfoYBB40q7LpdFIl/VpKLtViyAgAAGXgA= Date: Fri, 20 Oct 2017 19:06:38 +0000 Message-ID: <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: multipart/alternative; boundary="_000_2C4B0FD6418E441F8B436C60451E3A51cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11UYUwTZxjmu7uWo/bbvh6WfpyAcoubWxzCQlglbiPKZkmImWZmKT8GFY62 oZSm1yrdNKKRNsMsDmVEiShkbBqmwRjNmNmIVrOMbkq2ictYjMqqCBgXzMzSyHD39a543Z/m ued53/d53reXY2nuoIFn3d6A6Pc6PILewNRJVdZXK6pm7MVHr2Hr9NW/KOuh8Em99ddfJukK 2nbp+zlg+6S3W2cbGEhQ79I1hnUNose9XfSvebPO4FqY2Op7KLb+ML++DXxc3wGyWIxK8f6f 5kEHMLAc+prCj/f06ZWHKMBt5+5SysMowHN7z1KkRY9W48PdN3QEL0Ub8Zftx/QE02gZnhiY StZkIzuOPJmklZoaPDzZzii4HA9emU1iBq3Ep0Z/TmKIKvH5yLhqdikTnz7wJDk0C23Gj8PX MwkGKAf/EztFKWYWPBE/Tik7IDzw7RitYDOe/nNBDseyZlSEI093KfRqfPW3OFBwMT7/xQhD SjBajud61YlOPDY+q1PimPDokTijlFvw5SvDuk9Bbo/GuEfT0qNp6ZGn0uhlPHRhjVJSiLv2 38lU8CrcfrRXxeV44o+YXlvTB9hBYFxbVlRSUlr0mrXo9bKzgPzl/rzqYfCo2xYFiAWCEc6t n7FzOsd2KdQcBU0sJZjh5tC0nXtuW0tDyOWQXLX+oEeUhKWwr1iuhIv0tqCnSeDhiY0ym73I esUdkkcMyO+YUAD5t+7bOcuiJgUln7ve3RKUaoN+j/xGsLQ8dt9aMrbBEfpQ9LcoZlGwjGUE C6xZuG7nkNMREJtE0Sf6U+oOlhUwXG6TG01+0Sm2Nro9gZQs9z0iOyGtkgybD6tIoBytoMlb CL+bumfneK38/8gUmxUFTtYo5+aIPZR8jmbJ7VSts6FnXr6dMcUmbXPhR+RGXIrUWObDrclE KSndLgY6AXvm95vzFDuS/I3fOPYvxTHeFq/IW+AomYpIqyvoXVyfz4EPCuQMz2sEEoPPg4ku mTdr+GdJ+BWw8r68fK5GTQ+T+l7MgHr5vcmG75P1jfLX5Nn2HIyQSEtUMrk8hmHCmVROs3se rCG7m1Ul3W1GPjIlHzmTlEAp4Ahoj/wGYY0pVj2yQEguRaYduUw5siqlO/Ft4L2LG4Zun9n5 2ciSob03fY228OcHn5bvGUG7XrrQ/3f8NNa3NvdP1WV0/biuM8zuqz+0qTY0ftl0q/b2zgzp gHswwh3/Rn9vw9AH18RYVydjvNVuSmT0Vr8Tm67O/+rhVKByheDjT5Z29M82vngkFHiQyK/o 37JlLJB4+84Ld3cX7C4UGMnlKHmF9kuO/wAgdUG0pQUAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 19:06:45 -0000 --_000_2C4B0FD6418E441F8B436C60451E3A51cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gb3JkZXIgcGFja2V0IGRlbGl2ZXJ5IHJlcXVpcmVtZW50cyBjb25zaWRlcmVkIGhhcm1mdWwg dG8gdGhlIEludGVybmV04oCmDQoNCknigJltIGFzc3VtaW5nIHJhbmRvbSBwZXIgcGFja2V0IGZs b3cgbGFiZWwgYXNzaWdubWVudHMgYXJlIHdpdGhpbiBzcGVjIGFzIGxvbmcgYXMgdGhleSBhcmUg c2V0IGJ5IHRoZSBzb3VyY2UuDQoNCkpvaG4NCg0KRnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb20+DQpE YXRlOiBGcmlkYXksIE9jdG9iZXIgMjAsIDIwMTcgYXQgMjo0NCBQTQ0KVG86IE9sZSBUcm9hbiA8 b3Ryb2FuQGVtcGxveWVlcy5vcmc+DQpDYzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBGbG93IGxhYmVsIFtub3QgZHJhZnQtaGFuLTZtYW4taW4tYmFuZC1zaWduYWxpbmct Zm9yLXRyYW5zcG9ydC1xb3MtMDAudHh0XQ0KDQoNCg0KT24gRnJpLCBPY3QgMjAsIDIwMTcgYXQg MTE6MjAgQU0sIE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBl bXBsb3llZXMub3JnPj4gd3JvdGU6DQpIaSBUb20sDQoNCj4gPj4+IFByb2JsZW0gd2l0aCBmbG93 IGxhYmVsIGlzIHNhbWUgYXMgd2l0aCBob3AtYnktaG9wIG9wdGlvbjogYnVybmVkIGJlY2F1c2UN Cj4gPj4+IG5vYm9keSBzaG91bGQgZGFyZSB1c2UgaXQgZm9yIHNvbWV0aGluZyB1c2VmdWwgd2l0 aCBhbGwgdGhlIGluY29uc2lzdGVudA0KPiA+Pj4gY29kZSBvdXQgaW4gdGhlIGZpZWxkLiAgTm90 aGluZyBhZ2FpbnN0IHJlZGVmaW5pbmcgaXQgKHdpdGggbmV3IGVuY29kaW5nKQ0KPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5e Xl5eXl5eXl5eXl5eXl4NCj4gPj4gVGhlcmUgaXMgbm8gZW5jb2RpbmcuIEl0J3MgMjAgb3BhcXVl IGJpdHMgKGFuZCBhbHdheXMgaGFzIGJlZW4pLiBQbGVhc2UNCj4gPj4gcmVhZCBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjQzNy4NCj4gPg0KPiA+IFNvcnJ5LCBsYW1lIHVzZSBvZiB3 b3Jkcy4gTWVhbnQgdG8gc2F5ICJzdHJvbmdlciBkZWZpbml0aW9uIG9mIERPIGFuZCBET05Ucw0K PiA+IHdoaWNoIG1heSBpbmNsdWRlIG5ldyBzZW1hbnRpY3MiLiBJIG5ldmVyIHRyaWVkIHRvIGFu YWx5emUgdGhlIHN0YXRlIG9mDQo+ID4gYWZmYWlycyBvbiBmbG93IGxhYmVsIGFzIGkgZGlkIGZv ciByb3V0ZXIgYWxlcnQuIEp1c3QgdGFraW5nIGl0IGZyb20gd2hhdA0KPiA+IGkgaGVhcmQsIGxh c3QgZnJvbSBKb2VsIGF0IHRoZSBwZWNoYWt1Y2hhLg0KPg0KPiBSaWdodC4gSWYgd2UgdGFrZSBK b2VsJ3MgZmluZGluZ3MsIHRoZW4gaXQgYXBwZWFycyB0aGUgY29uY2x1c2lvbiBpcyB0aGF0IHJp Z2h0IG5vdyB1c2luZyBhIDQgdHVwbGUgU0EsIERBLCBQcm90LCBGbG93IGZvciBFQ01QIGhhcyBh IHRvbyBoaWdoIHByb2JhYmlsaXR5IGZvciBmYWlsdXJlLiBJdCB3b3VsZCBiZSB2ZXJ5IG5pY2Ug dG8gaGF2ZSB0aGF0IGZpeGVkLiBVbnRpbCB0aGVuLCB3ZSdyZSBmb3JjaW5nIHJvdXRlcnMgdG8g cGFyc2UgdHJhbnNwb3J0IGhlYWRlcnMuDQo+DQo+IE9sZSwNCj4NCj4gSSBjYW5ub3QgZmluZCB0 aGlzIHByZXNlbnRhdGlvbi4gSSBkaWQgZmluZCBhIHByZXNlbnRhdGlvbiB0byBuYW5vZyBhYm91 dCBwcm9ibGVtcyB3aXRoIGZsb3cgbGFiZWxzLCBidXQgdGhhdCBoYWQgbW9yZSB0byBkbyB3aXRo IHRoZSBmYWN0IHRoYXQgdGhlIGZsb3cgbGFiZWwgZG9lcyBub3QgaGF2ZSB0byBiZSBwZXJzaXN0 ZW50IGZvciB0aGUgbGlmZSBvZiBhIGNvbm5lY3Rpb24gd2hpY2ggYnJlYWtzIHN0YXRlZnVsIGZp cmV3YWxscyB0aGF0IHJlcXVpcmUgY29uc2lzdGVudCByb3V0aW5nIGZvciBhIGZsb3cuIEkgZGlk bid0IHNlZSBob3cgdGhpcyBpcyBhIHByb2JsZW0gZm9yIEVDTVAgaXRzZWxmLiBJcyB0aGVyZSBh IGRyYWZ0IG9uIHRoaXMgdGhhdCBkZXRhaWxzIHdoYXQgdGhlIHByb2JsZW1zIGFyZT8NCg0KSSBi ZWxpZXZlIEpvZWwncyBwcmVzZW50YXRpb24gd2FzIGZvciBhIGxvYWQgYmFsYW5jZXIgYXBwbGlj YXRpb24uDQoNClB1cmVseSBmb3IgRUNNUCBpdCBvbmx5IGhhcyBhIGNvbnNlcXVlbmNlIGZvciBy ZW9yZGVyaW5nIG9mIHBhY2tldHMuIFdoaWNoIG1heSBiZSBiYWQgZW5vdWdoLg0KQnV0IHNlbmRp bmcgcGFja2V0cyBvZiB0aGUgc2FtZSBmbG93IGFsb25nIGRpZmZlcmVudCBwYXRocyBoYXMgcHJv YmxlbXMgd2l0aCBhbnkgbmV0d29yayBmdW5jdGlvbiB0aGF0IHJlcXVpcmVzIHN0YXRlLiBOQVQ2 NCwgdmlydHVhbCByZWFzc2VtYmx5IG9mIGZyYWdtZW50cywgQUNMcyBhbmQgd2hhdCBub3QuIE5v dCB0aGF0IHRoZSBuZXR3b3JrIHNob3VsZCBkbyBhbnkgb2YgdGhvc2Ugb2YgY291cnNlLg0KT2xl LA0KDQpSaWdodCwgYnV0IG9mIGNvdXJzZSB0aGVyZSdzIG5ldmVyIGJlZW4gYW55IHJlcXVpcmVt ZW50IGluIElQIHRoYXQgcGFja2V0cyBpbiBhIGZsb3cgYWx3YXlzIGZvbGxvdyB0aGUgc2FtZSBw YXRoIG9yIGFyZSBuZXZlciByZWNlaXZlZCBvdXQgb2Ygb3JkZXIuIEV2ZW4gb3V0c2lkZSBvZiB1 c2luZyB0aGUgZmxvdyBsYWJlbCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0aGF0IHRoYXQgZm9yIHBh Y2tldHMgb2YgYSBmbG93IHRvIHRha2UgZGlmZmVyZW50IHBhdGhzIG9yIGJlIE9PTyAoZnJhZ21l bnRhdGlvbiwgVURQIGVuY2Fwc3VsYXRpb24sIHJvdXRpbmcgY2hhbmdlLCBldGMuKS4gSSBkb24n dCBzZWUgdGhhdCB0aGVyZSBpcyBhIHByb3RvY29sIHByb2JsZW0gd2l0aCBmbG93IGxhYmVscyB0 aGF0IHdvdWxkIGp1c3RpZnkgYSBnZW5lcmFsIHJlY29tbWVuZGF0aW9uIGFnYWluc3QgdGhlaXIg dXNlLiBNYXliZSB0aGVyZSBzaG91bGQgYmUgYSBkaXNjdXNzaW9uIGluIHY2b3BzIGFib3V0IHRo aXMuDQoNClRvbQ0KDQo= --_000_2C4B0FD6418E441F8B436C60451E3A51cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5A1294B7D259F84A883BDC11D8880A1A@comcast.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciBwYWNrZXQgZGVsaXZlcnkg cmVxdWlyZW1lbnRzIGNvbnNpZGVyZWQgaGFybWZ1bCB0byB0aGUgSW50ZXJuZXTigKY8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gYXNzdW1pbmcgcmFuZG9tIHBlciBwYWNrZXQgZmxvdyBs YWJlbCBhc3NpZ25tZW50cyBhcmUgd2l0aGluIHNwZWMgYXMgbG9uZyBhcyB0aGV5IGFyZSBzZXQg YnkgdGhlIHNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9objxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+aXB2NiAmbHQ7aXB2Ni1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgVG9tIEhlcmJlcnQgJmx0O3RvbUBoZXJiZXJ0bGFuZC5jb20m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgT2N0b2JlciAyMCwgMjAxNyBhdCAyOjQ0IFBN PGJyPg0KPGI+VG86IDwvYj5PbGUgVHJvYW4gJmx0O290cm9hbkBlbXBsb3llZXMub3JnJmd0Ozxi cj4NCjxiPkNjOiA8L2I+Nm1hbiBXRyAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IEZsb3cgbGFiZWwgW25vdCBkcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25h bGluZy1mb3ItdHJhbnNwb3J0LXFvcy0wMC50eHRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAyMCwgMjAxNyBhdCAxMToyMCBBTSwg T2xlIFRyb2FuICZsdDs8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIHRhcmdl dD0iX2JsYW5rIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SGkgVG9tLDxicj4NCjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFByb2JsZW0g d2l0aCBmbG93IGxhYmVsIGlzIHNhbWUgYXMgd2l0aCBob3AtYnktaG9wIG9wdGlvbjogYnVybmVk IGJlY2F1c2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBub2JvZHkgc2hvdWxkIGRhcmUgdXNlIGl0 IGZvciBzb21ldGhpbmcgdXNlZnVsIHdpdGggYWxsIHRoZSBpbmNvbnNpc3RlbnQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBjb2RlIG91dCBpbiB0aGUgZmllbGQuJm5ic3A7IE5vdGhpbmcgYWdhaW5z dCByZWRlZmluaW5nIGl0ICh3aXRoIG5ldyBlbmNvZGluZyk8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IF5eXl5eXl5eXl5eXl5eXl5eXl48YnI+DQomZ3Q7ICZn dDsmZ3Q7IFRoZXJlIGlzIG5vIGVuY29kaW5nLiBJdCdzIDIwIG9wYXF1ZSBiaXRzIChhbmQgYWx3 YXlzIGhhcyBiZWVuKS4gUGxlYXNlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyByZWFkIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NDM3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY0Mzc8L2E+Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBTb3JyeSwgbGFtZSB1c2Ugb2Ygd29yZHMuIE1lYW50IHRvIHNheSAmcXVvdDtzdHJv bmdlciBkZWZpbml0aW9uIG9mIERPIGFuZCBET05Uczxicj4NCiZndDsgJmd0OyB3aGljaCBtYXkg aW5jbHVkZSBuZXcgc2VtYW50aWNzJnF1b3Q7LiBJIG5ldmVyIHRyaWVkIHRvIGFuYWx5emUgdGhl IHN0YXRlIG9mPGJyPg0KJmd0OyAmZ3Q7IGFmZmFpcnMgb24gZmxvdyBsYWJlbCBhcyBpIGRpZCBm b3Igcm91dGVyIGFsZXJ0LiBKdXN0IHRha2luZyBpdCBmcm9tIHdoYXQ8YnI+DQomZ3Q7ICZndDsg aSBoZWFyZCwgbGFzdCBmcm9tIEpvZWwgYXQgdGhlIHBlY2hha3VjaGEuPGJyPg0KJmd0Ozxicj4N CiZndDsgUmlnaHQuIElmIHdlIHRha2UgSm9lbCdzIGZpbmRpbmdzLCB0aGVuIGl0IGFwcGVhcnMg dGhlIGNvbmNsdXNpb24gaXMgdGhhdCByaWdodCBub3cgdXNpbmcgYSA0IHR1cGxlIFNBLCBEQSwg UHJvdCwgRmxvdyBmb3IgRUNNUCBoYXMgYSB0b28gaGlnaCBwcm9iYWJpbGl0eSBmb3IgZmFpbHVy ZS4gSXQgd291bGQgYmUgdmVyeSBuaWNlIHRvIGhhdmUgdGhhdCBmaXhlZC4gVW50aWwgdGhlbiwg d2UncmUgZm9yY2luZyByb3V0ZXJzIHRvIHBhcnNlIHRyYW5zcG9ydA0KIGhlYWRlcnMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgT2xlLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgY2Fubm90IGZpbmQgdGhp cyBwcmVzZW50YXRpb24uIEkgZGlkIGZpbmQgYSBwcmVzZW50YXRpb24gdG8gbmFub2cgYWJvdXQg cHJvYmxlbXMgd2l0aCBmbG93IGxhYmVscywgYnV0IHRoYXQgaGFkIG1vcmUgdG8gZG8gd2l0aCB0 aGUgZmFjdCB0aGF0IHRoZSBmbG93IGxhYmVsIGRvZXMgbm90IGhhdmUgdG8gYmUgcGVyc2lzdGVu dCBmb3IgdGhlIGxpZmUgb2YgYSBjb25uZWN0aW9uIHdoaWNoIGJyZWFrcyBzdGF0ZWZ1bCBmaXJl d2FsbHMgdGhhdA0KIHJlcXVpcmUgY29uc2lzdGVudCByb3V0aW5nIGZvciBhIGZsb3cuIEkgZGlk bid0IHNlZSBob3cgdGhpcyBpcyBhIHByb2JsZW0gZm9yIEVDTVAgaXRzZWxmLiBJcyB0aGVyZSBh IGRyYWZ0IG9uIHRoaXMgdGhhdCBkZXRhaWxzIHdoYXQgdGhlIHByb2JsZW1zIGFyZT88YnI+DQo8 YnI+DQpJIGJlbGlldmUgSm9lbCdzIHByZXNlbnRhdGlvbiB3YXMgZm9yIGEgbG9hZCBiYWxhbmNl ciBhcHBsaWNhdGlvbi48YnI+DQo8YnI+DQpQdXJlbHkgZm9yIEVDTVAgaXQgb25seSBoYXMgYSBj b25zZXF1ZW5jZSBmb3IgcmVvcmRlcmluZyBvZiBwYWNrZXRzLiBXaGljaCBtYXkgYmUgYmFkIGVu b3VnaC48YnI+DQpCdXQgc2VuZGluZyBwYWNrZXRzIG9mIHRoZSBzYW1lIGZsb3cgYWxvbmcgZGlm ZmVyZW50IHBhdGhzIGhhcyBwcm9ibGVtcyB3aXRoIGFueSBuZXR3b3JrIGZ1bmN0aW9uIHRoYXQg cmVxdWlyZXMgc3RhdGUuIE5BVDY0LCB2aXJ0dWFsIHJlYXNzZW1ibHkgb2YgZnJhZ21lbnRzLCBB Q0xzIGFuZCB3aGF0IG5vdC4gTm90IHRoYXQgdGhlIG5ldHdvcmsgc2hvdWxkIGRvIGFueSBvZiB0 aG9zZSBvZiBjb3Vyc2UuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T2xlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SaWdodCwgYnV0IG9mIGNvdXJzZSB0aGVyZSdzIG5ldmVyIGJl ZW4gYW55IHJlcXVpcmVtZW50IGluIElQIHRoYXQgcGFja2V0cyBpbiBhIGZsb3cgYWx3YXlzIGZv bGxvdyB0aGUgc2FtZSBwYXRoIG9yIGFyZSBuZXZlciByZWNlaXZlZCBvdXQgb2Ygb3JkZXIuIEV2 ZW4gb3V0c2lkZSBvZiB1c2luZyB0aGUgZmxvdyBsYWJlbCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0 aGF0IHRoYXQgZm9yIHBhY2tldHMgb2YgYSBmbG93DQogdG8gdGFrZSBkaWZmZXJlbnQgcGF0aHMg b3IgYmUgT09PIChmcmFnbWVudGF0aW9uLCBVRFAgZW5jYXBzdWxhdGlvbiwgcm91dGluZyBjaGFu Z2UsIGV0Yy4pLiBJIGRvbid0IHNlZSB0aGF0IHRoZXJlIGlzIGEgcHJvdG9jb2wgcHJvYmxlbSB3 aXRoIGZsb3cgbGFiZWxzIHRoYXQgd291bGQganVzdGlmeSBhIGdlbmVyYWwgcmVjb21tZW5kYXRp b24gYWdhaW5zdCB0aGVpciB1c2UuIE1heWJlIHRoZXJlIHNob3VsZCBiZSBhIGRpc2N1c3Npb24g aW4gdjZvcHMNCiBhYm91dCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2C4B0FD6418E441F8B436C60451E3A51cablecomcastcom_-- From nobody Fri Oct 20 13:09:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A93D132320 for ; Fri, 20 Oct 2017 13:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4DE4oYfh2v5 for ; Fri, 20 Oct 2017 13:08:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EFC13217D for ; Fri, 20 Oct 2017 13:08:56 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DB6B358C4B0; Fri, 20 Oct 2017 22:08:52 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id C1E45B0CF2E; Fri, 20 Oct 2017 22:08:52 +0200 (CEST) Date: Fri, 20 Oct 2017 22:08:52 +0200 From: Toerless Eckert To: "tom p." Cc: Michael Richardson , ipv6@ietf.org Subject: Re: Loopback interface terminology issue Message-ID: <20171020200852.GA11689@faui40p.informatik.uni-erlangen.de> References: <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> <97dc5487-231a-e12e-e6d9-86aba799251d@gmail.com> <2654.1508345528@obiwan.sandelman.ca> <00e201d349c3$581fb640$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e201d349c3$581fb640$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 20:08:59 -0000 If i followed BrianC's note correctly, then the loopback interface dates back to BSD Unix stack earlier than routers: The problem was how to allow the use of TCP/IP if you do not even have any external interface up and running. YOu didn't want to create/choose yet another socket type for that case. Would have made apps very complex. Are historic BSD 4.2 vs. 4.3 sources freely available now for some history check ? ;-)) On Fri, Oct 20, 2017 at 05:33:13PM +0100, tom p. wrote: > ----- Original Message ----- > From: "Michael Richardson" > To: > Sent: Wednesday, October 18, 2017 5:52 PM > > > Brian E Carpenter wrote: > > brian> Well yes; indeed this topic is touched on in many RFCs but > nowhere is > > brian> it defined as part of the basic architecture, which is my > main > > brian> point. Using a concept that has no principal definition is > generally > > brian> a source of confusion. > > > > joel> We tended not to define software interfaces for things which > are not > > joel> required for interoperability. How you describe an address > which is > > joel> not bound to a physical interface is entirely irrelevant > outside the > > joel> scope of your own operating system. > > > > brian> That's not our experience in trying to be precise in saying > what we > > brian> mean in draft-ietf-anima-autonomic-control-plane. > > > > to restate Brian's point slightly differently: > > > > The issue is not to tell people how to implement things in their > software, > > but rather to make it clear that we need a standard hook on which to > hang our > > addresses. > > > > We'd rather not use the term "loopback interface" at all here if we > had > > another name defined in an RFC somewhere. > > > > I think that there is some significant text that might need to be > written > > when defining this hook when in a strong-host model. > > > > But, let me also ask a different question: are there router operating > systems > > where there is a way to hang an address on something which is not a > > virtual/loopback interface? If so, what do they call it? > > When I first came to IP, I was surprised to find that L3 addresses were > assigned to interfaces, as opposed to nodes, the latter having been the > case with other networks I had used previously. I have always seen the > creation of a virtual interface as a quirk which overcomes this absence > of a node address, or node identifier in the IP namespace. > > I first encountered the term 'loopback interface' in Cisco > documentation, which talks of the ability to configure a 'virtual > interface, referred to as a loopback interface'. So for me, 'loopback > interface' has always been the Cisco term for a virtual interface but > why it should be loopback, as opposed to virtual, I have never found > out. > > Whatever the name is, it does provide an identifier for the node and > one, at least in some systems, that is always up and so provides a > stable identifiier for protocols that need one, such as a router-id in > BGP; and you can have more than one such identifier, separating > functions, perhaps by priority, to prevent DoS attacks.. > > Tom Petch > > > If there are differences in software interfaces in some place that we > would > > be respecting by abstracting this requirement? > > After 35+ years of router operating systems, has anyone actually > innovated in this way? > > > > -- > > 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 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Fri Oct 20 13:53:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42C133053 for ; Fri, 20 Oct 2017 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=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 SZcrCoANaKLf for ; Fri, 20 Oct 2017 13:53:55 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 A3047132F7C for ; Fri, 20 Oct 2017 13:53:55 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 8so20046345qtv.1 for ; Fri, 20 Oct 2017 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RhgwjoMlZ/amGDUCVWlaCWB74w4+djiJami2PKs/9w0=; b=BxiJ5XEQ90te8+ewxva2fWNYn9ztki8dzM9v6RcE0Sm1yYZ/7Vbr2gxq8Lsaa5CUnq z+E5RHO87g9fDAQpMKg1o4KiW1NmJSFKKp8YpefMytBnoSCTZbCW44bjYkbxN8hzFqLx 5kA8Y1GNtwXbFk8GyRPVhW5HoNVN35RAa0nz1bkJ9x6aUU1UmPeZgxscG/x7UeG9k/CB uY2k0adcPzd5Y57LWUk/U8Lapv6ySEtbPiIQlt4Tq2qvHRNqJEdJTbxql78Lr5rtx0xk ZBXM6ej4A+5wYP3j8+a2rtBgk+ep5WT80lk5B3GB5E7aZ2InPBGUQXw7XDO3KvzvGoG8 OAdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RhgwjoMlZ/amGDUCVWlaCWB74w4+djiJami2PKs/9w0=; b=e8y7HaH4E1QG9P3rpkoBHNL8gMcuNI4nef5lRzMJY7VgKl1qhugSWg86b0yJdqzw4f rU1UH+hKdloVwZPpI9GQQ61ulrhKDPY/HCuefegMl3qYnw9+gLC+56SlzOmH2k3HznkV /+Rf9Fd9aBIZIyiR/op0FZzOwqF50ursvArXL0zsL6AIUfw8cJxdZrDvZFRn6iGe82aC iTgIB7SenZU4QvL4UPH5gC4L8IfYK59yvIBY40d1AYoo5AYGYTVrvme75len0SPPMCFP ZiNhQ6e5kEoXhNlUkNqSswJ9ZRNpsdW+q9F0HFw7f/0Yw+ST8kFzjikbAdHlavLYQm9B LrqQ== X-Gm-Message-State: AMCzsaXG8k7GUuaqetXUBNfSHqeDet+ZzRfb6jyCPsIML/+rHLlWZOHp MoxZOS5ifR1866SOSpdVhK69Y+kwTjqwMErdyb80Dg== X-Google-Smtp-Source: ABhQp+SThgd2k3V+joDpRHzPLRwSuYk8Yc4VMp8rfOxUjs42NCrYixTI9xgQ7yDYJoOWOFZA+zhjltCJpHqSWm8oPGA= X-Received: by 10.200.55.101 with SMTP id p34mr9680535qtb.27.1508532834796; Fri, 20 Oct 2017 13:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Fri, 20 Oct 2017 13:53:54 -0700 (PDT) In-Reply-To: <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> From: Tom Herbert Date: Fri, 20 Oct 2017 13:53:54 -0700 Message-ID: Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: "Leddy, John" Cc: Ole Troan , 6man WG Content-Type: multipart/alternative; boundary="001a1145fa8cc0193f055c00ab65" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 20:53:57 -0000 --001a1145fa8cc0193f055c00ab65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John wrote: > In order packet delivery requirements considered harmful to the Internet= =E2=80=A6 > > > > I=E2=80=99m assuming random per packet flow label assignments are within = spec as > long as they are set by the source. > > > Yes, there is no requirement that the flow label be persistent at all in a flow. That gives some nice properties. For instance, at FB we implemented flowbender using the flow label so that when a host detects a poor quality path it can randomly try another flow label for the connection to hopefully find a better path (a type of source routing). Random Packet Spraying could use the flow label and randomly set it per packet to achieve perfect load balancing in a multi-path network. Tom --001a1145fa8cc0193f055c00ab65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John <John_Leddy@comcast= .com> wrote:

In order packet delivery requirements considered har= mful to the Internet=E2=80=A6

=C2=A0

I=E2=80=99m assuming random per packet flow label as= signments are within spec as long as they are set by the source.<= /u>

=C2=A0


<= /div>
Yes, there is no requirement that the flow label be persistent at= all in a flow. That gives some nice properties. For instance, at FB we imp= lemented flowbender using the flow label so that when a host detects a poor= quality path it can randomly try another flow label for the connection to = hopefully find a better path (a type of source routing). Random Packet Spra= ying could use the flow label and randomly set it per packet to achieve per= fect load balancing in a multi-path network.

Tom

--001a1145fa8cc0193f055c00ab65-- From nobody Fri Oct 20 14:35:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226C9133059 for ; Fri, 20 Oct 2017 14:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r96oUDbRruJN for ; Fri, 20 Oct 2017 14:35:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B421329B5 for ; Fri, 20 Oct 2017 14:35:00 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EC6A058C4B0; Fri, 20 Oct 2017 23:34:56 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D7663B0CF30; Fri, 20 Oct 2017 23:34:56 +0200 (CEST) Date: Fri, 20 Oct 2017 23:34:56 +0200 From: Toerless Eckert To: Tom Herbert Cc: "Leddy, John" , 6man WG Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Message-ID: <20171020213456.GA14112@faui40p.informatik.uni-erlangen.de> References: <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 21:35:03 -0000 On Fri, Oct 20, 2017 at 01:53:54PM -0700, Tom Herbert wrote: > Yes, there is no requirement that the flow label be persistent at all in a > flow. That gives some nice properties. For instance, at FB we implemented > flowbender using the flow label so that when a host detects a poor quality > path it can randomly try another flow label for the connection to hopefully > find a better path (a type of source routing). Random Packet Spraying could > use the flow label and randomly set it per packet to achieve perfect load > balancing in a multi-path network. Seems like that spraying example is a good reason why one would need to have maybe at least two flow labels: One thats permitted to create state, and one thats not (eg: used for load balancing). Toerless > > Tom > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Oct 20 14:41:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F4513431A for ; Fri, 20 Oct 2017 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtDAhnEP0RDZ for ; Fri, 20 Oct 2017 14:41:48 -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 019A61342E6 for ; Fri, 20 Oct 2017 14:41:47 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id t188so12800640pfd.10 for ; Fri, 20 Oct 2017 14:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OS4d3sAMbja6qloBCBNeYiO/o4Bew4NFrUY+0YsAWp8=; b=JawoCyDpufibqJmTcX1WGA4+/HLk9uwI7Pk5h/n48QWrA9cTXn2if7FgbOp1MeUGmQ TuTTNh6VvhueoVlgeZoTUeq/PRoGGJ7nBv7/IrEn8lwHeW+VkJJTnSbsjJY/CKFAQ+bl LPi/z5VRFnWUzS7tjsjFirAJkgRk0LxyTjueaxXyjp5pKP/19E5WCGqW85GjwbG+XBSW sqSwUI1tpurwppqO89jAxdU7vd/qe58O4YwKtw81Ej7UW1tGXmT1wdYG6NoyT9lBZDsb 7isvkaZADUuymJCOk3aDIdooP/i5YCy5jSbQvl4H8c4zoPRC0WTNIpoI3+PMb3W9v4sv PzBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OS4d3sAMbja6qloBCBNeYiO/o4Bew4NFrUY+0YsAWp8=; b=HyP65icV1UVm7WDUw5eD7KuPQ1BheYvYGGLV4tMzblncAxFq+PYOyHd93XR0mh4ssB IRSnohqxOvYI2Q3FZbmCvX57aGrHJpbz9rEUbDoFNrYyNLCSsjRz65UdBf79Sfn5ERtJ mWzn4XQAIomjHXoG+AZoOKZbf6vToYLmjWvug3Kc4A2RFPAZd5LNSM3C2CqX6BZKj79g M0t0xi1YicRInqKsYt560AXxDQw3uhbuiugZeUeEmZCCLCQEovO/Co0n3wbyeAeL7sgG Pjthbf+JttJWS/G1zklPDOzJpJecl9HImktVD6gCsRJ8BxMVTK2WC6XU9d3L70ne3yFq 2Xrg== X-Gm-Message-State: AMCzsaWk/fn8mhS5s955BtO1AR/r3QEM1ldbpwtrS6neKNvk8cezKYx/ 2Pmywy5DeV06EH6p9XQQQ0FxiA== X-Google-Smtp-Source: ABhQp+TLSddo5JYqhRVcbKqUe99JwwChATaSkitDcgnBdF5X6sTGGcmDXxeHftnmdzuEWMeJTlXxWg== X-Received: by 10.84.254.79 with SMTP id a15mr5290807pln.413.1508535707253; Fri, 20 Oct 2017 14:41:47 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r77sm3313119pfk.93.2017.10.20.14.41.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 14:41:46 -0700 (PDT) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: ipv6@ietf.org References: <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> Date: Sat, 21 Oct 2017 10:41:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 21:41:50 -0000 On 21/10/2017 09:53, Tom Herbert wrote: > On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John > wrote: >=20 >> In order packet delivery requirements considered harmful to the Intern= et=E2=80=A6 >> >> >> >> I=E2=80=99m assuming random per packet flow label assignments are with= in spec as >> long as they are set by the source. >> >> >> >=20 > Yes, there is no requirement that the flow label be persistent at all i= n a > flow.=20 http://mailman.postel.org/mailman/listinfo/internet-history says: To enable Flow-Label-based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. A typical definition of a flow for this purpose is any set of packets carrying the same 5-tuple {dest addr, source addr, protocol, dest port, source port}. It should be noted that a source node always has convenient and efficient access to this 5-tuple, which is not always the case for nodes that subsequently forward the packet. So, technically it's a recommendation, not a requirement. But for load balancing or ECMP to actually work, it's a requirement. > That gives some nice properties. For instance, at FB we implemented > flowbender using the flow label so that when a host detects a poor qual= ity > path it can randomly try another flow label for the connection to hopef= ully > find a better path (a type of source routing). Random Packet Spraying c= ould > use the flow label and randomly set it per packet to achieve perfect lo= ad > balancing in a multi-path network. I think the MPTCP people might have a word or two to say about that. Brian From nobody Fri Oct 20 14:45:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFDA1343C3 for ; Fri, 20 Oct 2017 14:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80D1KsCVnKfK for ; Fri, 20 Oct 2017 14:45:43 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B75C134451 for ; Fri, 20 Oct 2017 14:45:42 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e64so12806097pfk.9 for ; Fri, 20 Oct 2017 14:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EZcJt0PzdCpT0Mo+aogW/dJMZuiQvRwrdWrtAgrg7r8=; b=bb9FAD6m4ynPD6Bynu6xra9WqySfU6phGbM2/bO4fOnZpTC01RtndeRapeqKL5MJNj +sFc2/ZWYtJPsgsoJRTUj/0s3rGPxywrWSnzbBI6v66ci4yQ2vc1fA/OiKZx9zSWu0YG 6/ox7RqNZBaIcATpZrrINgXtugYloizJs3EKhMahn4bK08j3iK6YaanInBmLShM9SbcF 8j8hpTrNAakDQaydDq2gkIbuESgN6GeVYA4XoRjoveqNkUjOVeFPi0xLLqSIu35ADluB 8ch9LHN5L3WCqYJO/nvLFNzbZ/Ke7sn5014co06jZev2hBeY9K/mQlVVMmQplLZ9swcq WrzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=EZcJt0PzdCpT0Mo+aogW/dJMZuiQvRwrdWrtAgrg7r8=; b=b1p0t7Xt47ODsYURIb3c9WoeVN6peQmqBVrxeay2lN6ExItvgUyFLjNy2UViU28HKG RulBZZJJvp4Y2cYU5n8RLBkPyPkbKNNGbhlbIzKsWB6gPVzoWLqSNnXmNwfp0SGX/cnA x1nMccjQjavkCE/+tq5/W8Ss1pVN7f/06B68nlABm8yi5GL7Xmd/EdPfIkZX7Dfjj7zh 5KE/c5425cnnJFoZAlOey4mp9TyVXLNM1OW4BREF1dk6SS1H9txNCUIMN+RRvzsuI5e0 xd9x6pGU0cSbNutzQUcUAv5LN5vJi1UJgP8OSiMLJiql91fWAyY91fmCb5dt6dIKStoS In+Q== X-Gm-Message-State: AMCzsaWgQEiL+mxhwIKZVa14Cl+opdEj3SKqOOwDd1asXCti6pabUBV8 ayAirNfEcu3UFqv3ZNW2LTTJDg== X-Google-Smtp-Source: ABhQp+QQhfuBVlyScA5c+Q5dAnwmFXJ/+2cYyL4skBOrdeAYuP5Wk9FakVH+K8J+h3NosNCjdPyGGA== X-Received: by 10.99.126.81 with SMTP id o17mr5678365pgn.252.1508535941790; Fri, 20 Oct 2017 14:45:41 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 70sm3066119pfv.97.2017.10.20.14.45.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 14:45:40 -0700 (PDT) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Ole Troan , Tom Herbert Cc: 6man WG References: <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <6D75068F-9B19-4ECA-878F-5AC22A48AB1A@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6d108baf-ac61-f584-e3c1-6f41e0b71fcf@gmail.com> Date: Sat, 21 Oct 2017 10:45:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6D75068F-9B19-4ECA-878F-5AC22A48AB1A@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 21:45:45 -0000 On 21/10/2017 08:04, Ole Troan wrote: > Tom, > >>>>>> Problem with flow label is same as with hop-by-hop option: burned because >>>>>> nobody should dare use it for something useful with all the inconsistent >>>>>> code out in the field. Nothing against redefining it (with new encoding) >>>> ^^^^^^^^^^^^^^^^^^^ >>>>> There is no encoding. It's 20 opaque bits (and always has been). Please >>>>> read https://tools.ietf.org/html/rfc6437. >>>> >>>> Sorry, lame use of words. Meant to say "stronger definition of DO and DONTs >>>> which may include new semantics". I never tried to analyze the state of >>>> affairs on flow label as i did for router alert. Just taking it from what >>>> i heard, last from Joel at the pechakucha. >>> >>> Right. If we take Joel's findings, then it appears the conclusion is that right now using a 4 tuple SA, DA, Prot, Flow for ECMP has a too high probability for failure. It would be very nice to have that fixed. Until then, we're forcing routers to parse transport headers. >>> >>> Ole, >>> >>> I cannot find this presentation. I did find a presentation to nanog about problems with flow labels, but that had more to do with the fact that the flow label does not have to be persistent for the life of a connection which breaks stateful firewalls that require consistent routing for a flow. I didn't see how this is a problem for ECMP itself. Is there a draft on this that details what the problems are? >> >> I believe Joel's presentation was for a load balancer application. >> >> Purely for ECMP it only has a consequence for reordering of packets. Which may be bad enough. >> But sending packets of the same flow along different paths has problems with any network function that requires state. NAT64, virtual reassembly of fragments, ACLs and what not. Not that the network should do any of those of course. >> >> Ole, >> >> Right, but of course there's never been any requirement in IP that packets in a flow always follow the same path or are never received out of order. Even outside of using the flow label there are other ways that that for packets of a flow to take different paths or be OOO (fragmentation, UDP encapsulation, routing change, etc.). I don't see that there is a protocol problem with flow labels that would justify a general recommendation against their use. Maybe there should be a discussion in v6ops about this. > > Absolutely. There is no protocol problem with flow labels. When we did RFC6437, 6438 and 7098 we were perfectly aware of the deployment issues. Fixing them is a long term play. There's background discussion in https://tools.ietf.org/html/rfc6436 Brian From nobody Fri Oct 20 15:13:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0D1342E6 for ; Fri, 20 Oct 2017 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyZnUPRRWhBs for ; Fri, 20 Oct 2017 15:13:43 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D77132CE7 for ; Fri, 20 Oct 2017 15:13:43 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x82so16065148qkb.12 for ; Fri, 20 Oct 2017 15:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tiVfRVvCRVl6Ke0H6WcIcu3fnDRQSgqEZ5lmTAUdM7s=; b=WNoV9NcED2koXyaE3ipM/JsspAe//OZf7S6JyMzu7YS+TFFzqtMOfTlivk36h7l7CI itUmJMzY/EavIwxoKw/GKhuiFrAGMlaeb5+8ZdWIfGKQlFSE2kjNqfKvhpZ5/PTwj8R1 CZL/7xMbZNWNwoDdWjQdgrhS3da5abuo0DhI/+T5DhBYD1RJ3jILfxDm/EPB8GD4+Rab Zy6qfKz4WWuyq6tYWJp2+N7kHuQzXmDriDiyyjXwAsGNex3aFv+pUigkdHRt3hyFL4Mh MLEvqzv0F9R2/gEbDL7J87po1gqQBgV4oRqpRIdukWTMyDWXXnTmQARHFLL8AQiJvapg C0IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tiVfRVvCRVl6Ke0H6WcIcu3fnDRQSgqEZ5lmTAUdM7s=; b=owmhmSIYA9ydUFvWhkdmuVP2OoqerXl5LstCyBrMqAcbruaCRpp/0y3K6hsrVsiUpV FrN5djf3UlXcoPQLLQBM2yp6ecew/q4ht0Ifi621NWgV35CwKzBiIkVj4ADj5krSITBf lxdSGNtNN0tLKM/UbKMoLasVFRDjDx39OAR3gR5qIQXCgX9Im1oSnEa66D4dIj9EePxt YXc84KtO01lxL0n578Zw5mLp8CBkhcJGJ5hdBGDnqhngflyF2QZvdrW2bCy03Rd6VZOX 4jON+unZb5AWNJaqKh0mMc2TXu5xH0AymUSU1ANvCUAirsv9Wz9UDUxZzgGOcegJ03Ng 1OiA== X-Gm-Message-State: AMCzsaWzJ7qWovMjPdwqcpmwovCgbM6aeNf6wRnAszYiRQrSJqr5q/KM tSq0VV38ZDahB2zV/X5b2wZV/0ybWVQmJcLbjk58ow== X-Google-Smtp-Source: ABhQp+QNMXpm+AOtpqgqBvucfrAUY7//ybegz/H1ZRvhdYtWFeuXn8AdcgyEYGPuTp/E25+MCsQ7MIedrLWJAHDo5YI= X-Received: by 10.55.133.71 with SMTP id h68mr8830666qkd.17.1508537622306; Fri, 20 Oct 2017 15:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Fri, 20 Oct 2017 15:13:41 -0700 (PDT) In-Reply-To: <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> References: <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> From: Tom Herbert Date: Fri, 20 Oct 2017 15:13:41 -0700 Message-ID: Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Brian E Carpenter Cc: "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07d60e1bbd55055c01c90a" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 22:13:48 -0000 --94eb2c07d60e1bbd55055c01c90a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 21/10/2017 09:53, Tom Herbert wrote: > > On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John > > wrote: > > > >> In order packet delivery requirements considered harmful to the > Internet=E2=80=A6 > >> > >> > >> > >> I=E2=80=99m assuming random per packet flow label assignments are with= in spec as > >> long as they are set by the source. > >> > >> > >> > > > > Yes, there is no requirement that the flow label be persistent at all i= n > a > > flow. > > http://mailman.postel.org/mailman/listinfo/internet-history says: > > To enable Flow-Label-based classification, source nodes SHOULD assign > each unrelated transport connection and application data stream to a > new flow. A typical definition of a flow for this purpose is any set > of packets carrying the same 5-tuple {dest addr, source addr, > protocol, dest port, source port}. It should be noted that a source > node always has convenient and efficient access to this 5-tuple, > which is not always the case for nodes that subsequently forward the > packet. > > So, technically it's a recommendation, not a requirement. But for load > balancing or ECMP to actually work, it's a requirement. > Brian, I don't think that says anything that the flow label has to be persistent for the life of the connection. It is incorrect, though, if any nodes assume that the flow label is persistent. The soft state approach like in this QoS draft doesn't require the flow label to be persistent. Load balancing only fails when the destination address is being treated as an anycast and the address is being used as an endpoint of connections that are on different hosts. But such stateful load balancing becomes obsolete as the externally visible flow information is decoupled from the end-to-end identification of the flow like happens in QUIC, ESP, etc. ECMP works regardless of whether the flow label is persistent as long as flow labels have a fairly nice uniform distribution. But, even if a host were to flip out and the flow label to be the same value in every packet for every flow that still really doesn't break things, it just means that ECMP effectively falls back to a 2-tuple hash. > > That gives some nice properties. For instance, at FB we implemented > > flowbender using the flow label so that when a host detects a poor > quality > > path it can randomly try another flow label for the connection to > hopefully > > find a better path (a type of source routing). Random Packet Spraying > could > > use the flow label and randomly set it per packet to achieve perfect lo= ad > > balancing in a multi-path network. > > I think the MPTCP people might have a word or two to say about that. > > MPTCP might be better for TCP, but flow label works with _any_ transport protocol. However, now that you mention it, I wonder how MPTCP works through a load balancer. All the connections have different hashes but have to wind up on the same backend host. Maybe it's another instance of the externally visible flow information be decoupled from the end-to-end flow identification. Tom --94eb2c07d60e1bbd55055c01c90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 21/10/2017 09:53, Tom Herbert wrote:
> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John <John_Leddy@comcast.com>
> wrote:
>
>> In order packet delivery requirements considered harmful to the In= ternet=E2=80=A6
>>
>>
>>
>> I=E2=80=99m assuming random per packet flow label assignments are = within spec as
>> long as they are set by the source.
>>
>>
>>
>
> Yes, there is no requirement that the flow label be persistent at all = in a
> flow.

http://mailman.postel.org/mailman/listinfo/internet-history says:

=C2=A0 =C2=A0To enable Flow-Label-based classification, source nodes SHOULD= assign
=C2=A0 =C2=A0each unrelated transport connection and application data strea= m to a
=C2=A0 =C2=A0new flow.=C2=A0 A typical definition of a flow for this purpos= e is any set
=C2=A0 =C2=A0of packets carrying the same 5-tuple {dest addr, source addr,<= br> =C2=A0 =C2=A0protocol, dest port, source port}.=C2=A0 It should be noted th= at a source
=C2=A0 =C2=A0node always has convenient and efficient access to this 5-tupl= e,
=C2=A0 =C2=A0which is not always the case for nodes that subsequently forwa= rd the
=C2=A0 =C2=A0packet.

So, technically it's a recommendation, not a requirement. But for load<= br> balancing or ECMP to actually work, it's a requirement.

Brian,

I don't think that= says anything that the flow label has to be persistent for the life of the= connection. It is incorrect, though, if any nodes assume that the flow lab= el is persistent. The soft state approach like in this QoS draft doesn'= t require the flow label to be persistent.

Load ba= lancing only fails when the destination address is being treated as an anyc= ast and the address is being used as an endpoint of connections that are on= different hosts. But such stateful load balancing becomes obsolete as the = externally visible flow information is decoupled from the end-to-end identi= fication of the flow like happens in QUIC, ESP, etc.

ECMP works regardless of whether the flow label is persistent as long as= flow labels have a fairly nice uniform distribution. But, even if a host w= ere to flip out and the flow label to be the same value in every packet for= every flow that still really doesn't break things, it just means that = ECMP effectively falls back to a 2-tuple hash.

=C2= =A0
> That gives some nice properties. For instance, at FB we implemented > flowbender using the flow label so that when a host detects a poor qua= lity
> path it can randomly try another flow label for the connection to hope= fully
> find a better path (a type of source routing). Random Packet Spraying = could
> use the flow label and randomly set it per packet to achieve perfect l= oad
> balancing in a multi-path network.

I think the MPTCP people might have a word or two to say about that.=

MPTCP might be better for TCP, but flow label works with _any_ tr= ansport protocol. However, now that you mention it, I wonder how MPTCP work= s through a load balancer. All the connections have different hashes but ha= ve to wind up on the same backend host. Maybe it's another instance of = the externally visible flow information be decoupled from the end-to-end fl= ow identification.

Tom

--94eb2c07d60e1bbd55055c01c90a-- From nobody Fri Oct 20 16:27:52 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4916C13430F for ; Fri, 20 Oct 2017 16:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3qLU57n5vkA for ; Fri, 20 Oct 2017 16:27:49 -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 2F718132A1A for ; Fri, 20 Oct 2017 16:27:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYD97122; Fri, 20 Oct 2017 23:27:47 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 21 Oct 2017 00:27:46 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 16:27:42 -0700 From: Lin Han To: "Manfredi, Albert E" , Brian E Carpenter CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdJXqSaZrOZDMkmbu8uyH2nDS6LtjQWA//++ciA= Date: Fri, 20 Oct 2017 23:27:41 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59EA8673.0049, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: add233d5f4d454c7c40dbb4b4f375f9c Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 23:27:51 -0000 -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]=20 Sent: Friday, October 20, 2017 12:00 PM To: Lin Han ; Brian E Carpenter Cc: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport= -qos-00.txt] -----Original Message----- From: Lin Han [mailto:Lin.Han@huawei.com]=20 > ATM is failed due to many reasons, scalability is one of it. > This solution is not intended to replace completely the best-effort=20 > transport service. The solution is only for those application which=20 > really needs a flow level QoS, such as AR/VR, tactile internet, etc.=20 > From this sense, it does not sacrifice the scalability of IP. Or at least, does not sacrifice it as much? ATM also had a UBR service. [LH] Yeah, everything has cost. But it is still different, ATM UBR is conne= ction oriented, it needs setup and involves the control protocol such as PN= NI. In our case, the IP architecture is not touched at all. IP best effort = is as simple as before. The new solution does not impact the IP routing or = any other protocols. But my point was only that out in the wild, you have no guarantee that the = routers in the path will know what to do with your in-band QoS demands. Onl= y in situations where all the routers are in your control will you have tha= t guarantee. But sure, in walled gardens, these cool ideas can be made to w= ork. [LH] Agreed. But not that strict. As I said in the document, for optimizati= on, the HbH router is only needed for the point of the congestion or device= introducing a lot latency. It does not need all routers on the path to be = HbH aware. And if a router cannot guarantee the bandwidth, the application = can fall back to normal TCP, it does not completely disable the transport. The basic idea still works for multiple domain, I don't want to talk about = it since it may introduce more debating. Let see if there is any flaw for a= single domain. If it works, I'm sure technically we don't have problem to = apply to multiple domains.=20 One more infor for this domain issue. The network environment that an appli= cation may need this QoS (ultra-high bandwidth and ultra-low latency) may b= e flat, and very likely has a few domains (one or two). This is because of = the limit of propagation delay. For example, in the architecture of 5G that= is supposed to support the latency as low as single digit ms, the content = provider is supposed to connect to the SP's access network directly and in = the same metro. Only this deployment can provide the physical distance as s= hort as possible. On the other hand, also in these controlled environments, another option, f= requently, is to "throw bandwidth at the problem." Give yourself plenty of = headroom. It's less elegant and less fun, but it works great. [LH] not completely get what you mean=20 Bert From nobody Fri Oct 20 17:28:13 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8771344F8; Fri, 20 Oct 2017 17:24:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , <6man-chairs@ietf.org> Cc: ipv6@ietf.org, suresh@kaloom.com Subject: 6man - Requested session has been scheduled for IETF 100 X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854546196.20809.8825503941875959536.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:21 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:22 -0000 Dear Ole Troan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. 6man Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Collyer size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops mtgvenue Second Priority: spring dnssd tsvarea Third Priority: nfvrg anima People who must be present: Robert M. Hinden Ole Troan Suresh Krishnan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 20 17:42:36 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06227134474 for ; Fri, 20 Oct 2017 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO0qGue_yFml for ; Fri, 20 Oct 2017 17:42:33 -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 E2C67134465 for ; Fri, 20 Oct 2017 17:42:32 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id d28so13259177pfe.2 for ; Fri, 20 Oct 2017 17:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RfFf04wl7cuU/xG2MOGI6ksPvm1OmkxpDNs9NFZVQAE=; b=jX2p8Xm1naCxCzz9YHj7aQsE5ilf3JOvYJrKKf0BmCSXNYzyysdu66LTuVZNMLWxBV jzGbO9xyKs6Vrqa8nM4oLfuyMxCJlQRzX6+JLFgKswhrB9WW+vz2KJeKMcXr//cWQe+O 2UKMTu/aixg8blg8VKkhM8I98W34LHH6iyzlXSQpV21/rskf5hCkRot49Ts0P+uJwYMU G6FoOr/1ptuTgrPcLZkCoIvSpuZmuSv7HFIWZcQhT7KC6tDcUdJZVCRNWCLXFvJFFxHL 1bmFLKnPGtyoPdA7zdZjLJzDpeT6E5cGdAmzeYdo/yDgAbn5wdY958oCWIhwxt8xwwN0 jH+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RfFf04wl7cuU/xG2MOGI6ksPvm1OmkxpDNs9NFZVQAE=; b=YLqouqca1Dwh3dLy5v8lf2YKUBH/v4dbfcIUgt9artfJoWdHz4Onc/ZdhllZy+09rs 5HTVuEKuD+tAq7d6cN6LR0bwWgfmegFsSmnepeNjzaW7Do7/ET9qhDOdhC35gJLOTc5L hXqMfvSvrvV+Aq+/BCZK4UhIvc3Yty0WeD9E/v2Nbm00vRa4/gPZg7do1eRRVpDs3sa2 I38Jecp1iKEb3GPXP+/ZHa8WewD5Qqba+a5d5xzJbCYoxmaoivqnNslYntvYbeV2mzYg GWgHk+bQ8RkyhPmVQS3KfT3FjUTXtcT5Qp4+GExRRC04Z9snVrXbuetaSphhDllXrKiU W4UQ== X-Gm-Message-State: AMCzsaVETQcDsQm+gtD+8OpjP+sNAxs/XiuMx0bGym9SJIcUI148ToBE FvOKzmKSZafDP+n8DkcZUUUvEg== X-Google-Smtp-Source: ABhQp+SAaRdyHTUzWbxXDzgJ+q3pEu5ScoMZU5atX011dZGPcVxthE383tBrWnpXsT8IMrB/QKQX8g== X-Received: by 10.99.124.27 with SMTP id x27mr5899739pgc.304.1508546551847; Fri, 20 Oct 2017 17:42:31 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k2sm3086845pff.126.2017.10.20.17.42.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 17:42:30 -0700 (PDT) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Tom Herbert Cc: "ipv6@ietf.org" References: <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <631451d4-9c3f-7b2e-d7ea-14648c91f07c@gmail.com> Date: Sat, 21 Oct 2017 13:42:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:42:35 -0000 On 21/10/2017 11:13, Tom Herbert wrote: > On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 21/10/2017 09:53, Tom Herbert wrote: >>> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John >>> wrote: >>> >>>> In order packet delivery requirements considered harmful to the >> Internet=E2=80=A6 >>>> >>>> >>>> >>>> I=E2=80=99m assuming random per packet flow label assignments are wi= thin spec as >>>> long as they are set by the source. >>>> >>>> >>>> >>> >>> Yes, there is no requirement that the flow label be persistent at all= in >> a >>> flow. >> >> http://mailman.postel.org/mailman/listinfo/internet-history says: >> >> To enable Flow-Label-based classification, source nodes SHOULD assi= gn >> each unrelated transport connection and application data stream to = a >> new flow. A typical definition of a flow for this purpose is any s= et >> of packets carrying the same 5-tuple {dest addr, source addr, >> protocol, dest port, source port}. It should be noted that a sourc= e >> node always has convenient and efficient access to this 5-tuple, >> which is not always the case for nodes that subsequently forward th= e >> packet. >> >> So, technically it's a recommendation, not a requirement. But for load= >> balancing or ECMP to actually work, it's a requirement. >> >=20 > Brian, >=20 > I don't think that says anything that the flow label has to be persiste= nt > for the life of the connection. It is incorrect, though, if any nodes > assume that the flow label is persistent. The soft state approach like = in > this QoS draft doesn't require the flow label to be persistent. >=20 > Load balancing only fails when the destination address is being treated= as > an anycast and the address is being used as an endpoint of connections = that > are on different hosts. But such stateful load balancing becomes obsole= te > as the externally visible flow information is decoupled from the end-to= -end > identification of the flow like happens in QUIC, ESP, etc. That's not really true for server load balancing. Delivering all packets in the flow to the same *instance* of the host is essential to be able to complete transactions. Whoever unwraps the flow identification has to be able to select the required server instance, at line speed. https://tools.ietf.org/html/rfc7098 sort of hints at this and we tried to go further in https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing but that faded away. And there's https://tools.ietf.org/html/draft-wang-v6ops-flow-label-refelction Nothing seems to quite work. Brian Brian >=20 > ECMP works regardless of whether the flow label is persistent as long a= s > flow labels have a fairly nice uniform distribution. But, even if a hos= t > were to flip out and the flow label to be the same value in every packe= t > for every flow that still really doesn't break things, it just means th= at > ECMP effectively falls back to a 2-tuple hash. >=20 >=20 >=20 >>> That gives some nice properties. For instance, at FB we implemented >>> flowbender using the flow label so that when a host detects a poor >> quality >>> path it can randomly try another flow label for the connection to >> hopefully >>> find a better path (a type of source routing). Random Packet Spraying= >> could >>> use the flow label and randomly set it per packet to achieve perfect = load >>> balancing in a multi-path network. >> >> I think the MPTCP people might have a word or two to say about that. >> >> MPTCP might be better for TCP, but flow label works with _any_ transpo= rt > protocol. However, now that you mention it, I wonder how MPTCP works > through a load balancer. All the connections have different hashes but = have > to wind up on the same backend host. Maybe it's another instance of the= > externally visible flow information be decoupled from the end-to-end fl= ow > identification. >=20 > Tom >=20 From nobody Fri Oct 20 17:50:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6B134457 for ; Fri, 20 Oct 2017 17:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE3K7vn-cOwQ for ; Fri, 20 Oct 2017 17:50:25 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 EFFCF126B7E for ; Fri, 20 Oct 2017 17:50:24 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id s2so7835503pge.10 for ; Fri, 20 Oct 2017 17:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xa/WYvOopReyVtV42vI38y/7hf/MDm46bQ+vlH8A8Y4=; b=cm3ChwvqeLXJU+QFgDSLQ7v84Sub1FGeCurAXql9ytLx0/Gb/GXygpYbRfMx+98nE3 mHh4FnmMQpYmH8r7MmGyZAtvrO2H1vB459t534k82NPIySRhGvKN7oLVQIZdRKvaWg1I J+hDg/125cJKxRfZKJ+k9sGKAMPKl0v0o+6dS8/pLRZgRqLOD8ZUNVEogaUK2JKbu04w SKlyLeK//K0hILG5I7tRNa5PXN44c8kF4DMpAwmUmd5UJjbBWukTOdP8gB17cvqng91e UoeoHQ0050iXJWua4N39aMsRbcfdLW4VRdnnTxuc45o9Zuo9gZftBhyVJyRhOgivj2lU Iz4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xa/WYvOopReyVtV42vI38y/7hf/MDm46bQ+vlH8A8Y4=; b=ocakIN9l3iEPsD/RuwMp9DwGVa/IT97FYbeUdA+kpgmCANmRG/PQecLJrOwXEMTxm3 KX+MZCUqiXfm0DH7D3IIrv9xu1Bj1OddleNvOYkA+6rx1uAWasCRf6oQAfgbZCajXqHg JA494+WgV0QL2scyos4xpfM9pmbfQTNLZRNmcskoRhGXN5sxXS9UGnUbPZaOzBTJpK3O guR0b9Ywp7JHmh05xNPhUbpvrJFfh/1OolsaeOD3T4nEUNilvHrQnsO+YOU9Qkvw/B51 qCPk2w3BOyCTt0udXxyZE7LDvQl4W15IfVtzUEuvXAXhLSxbNE8w9eWIltSHejVblvvq pxKg== X-Gm-Message-State: AMCzsaVRmkBJAxLPgEYSf0+7nOsnNntFvDI81cyp8aVBBaMj7T40oP4e sqXZtWt0KDWq0Bt2T1qKnUrdbQ== X-Google-Smtp-Source: ABhQp+QppSlARvbim48+dX5qvZ1c6JyOVmwDEipAB9s6Oi6EWeJAtCBoLQ7SUbJt7vtz7SCbLx32fg== X-Received: by 10.99.111.67 with SMTP id k64mr5902251pgc.234.1508547023936; Fri, 20 Oct 2017 17:50:23 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c25sm2929617pgn.64.2017.10.20.17.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 17:50:23 -0700 (PDT) Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Lin Han , "Manfredi, Albert E" Cc: 6man WG References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5dc02378-28ff-e55a-6034-3faae396402f@gmail.com> Date: Sat, 21 Oct 2017 13:50:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:50:26 -0000 On 21/10/2017 12:27, Lin Han wrote: ... > On the other hand, also in these controlled environments, another option, frequently, is to "throw bandwidth at the problem." Give yourself plenty of headroom. It's less elegant and less fun, but it works great. > [LH] not completely get what you mean Keep your average network utilisation well below 10% and your QoS problems are solved. It's just queueing theory. Brian From nobody Fri Oct 20 18:15:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFF126B7E for ; Fri, 20 Oct 2017 18:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQ27rDtzP2iS for ; Fri, 20 Oct 2017 18:15:00 -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 D3579124B17 for ; Fri, 20 Oct 2017 18:14:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRB03720; Sat, 21 Oct 2017 01:14:58 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 21 Oct 2017 02:14:57 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 18:14:47 -0700 From: Lin Han To: Brian E Carpenter , "Manfredi, Albert E" CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdJXqSaZrOZDMkmbu8uyH2nDS6LtjQWA//++ciCAAKNsAP//jLNQ Date: Sat, 21 Oct 2017 01:14:47 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD76B4E@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> <5dc02378-28ff-e55a-6034-3faae396402f@gmail.com> In-Reply-To: <5dc02378-28ff-e55a-6034-3faae396402f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59EA9F92.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a9594e3c0fa60c315aeab1c5e2f11ae Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 01:15:02 -0000 PktlZXAgeW91ciBhdmVyYWdlIG5ldHdvcmsgdXRpbGlzYXRpb24gd2VsbCBiZWxvdyAxMCUgYW5k IHlvdXIgUW9TIHByb2JsZW1zIGFyZSBzb2x2ZWQuDQo+SXQncyBqdXN0IHF1ZXVlaW5nIHRoZW9y eS4NCg0KS2luZCBvZiBjb3JyZWN0LiBJZiBhbGwgbGlua3MgYXJlIG5ldmVyIGNvbmdlc3RlZCwg dGhlcmUgaXMgbm8gcHJvYmxlbSBhbmQgcmVxdWlyZW1lbnQgZm9yIFFvUyBlc3BlY2lhbGx5IGZv ciBiYW5kd2lkdGguIEJ1dCB0aGlzIGlzIG5vdCBwcmFjdGljYWwgZm9yIFNQLiBJbiByZWFsaXR5 LCB0aGVyZSBhcmUgYWx3YXlzIG92ZXJzdWJzY3JpcHRpb24gYXQgbmV0d29yayBhZ2dyZWdhdGlv biBkZXZpY2UsIHN1Y2ggYXMgVE9SLCBQR1csIEJSQVNTLCBldGMuIFRodXMgdGhlIGNvbmdlc3Rp b24gd2lsbCBuZXZlciBnbyBhd2F5LiBNb3N0IG9mIGFwcGxpY2F0aW9ucyBkb27igJl0IGZlZWwg cGFpbiBpZiBpdCBpcyBub3QgYmFuZHdpZHRoL2xhdGVuY3kgc2Vuc2l0aXZlLCBidXQgZm9yIHNv bWUgYXBwbGljYXRpb25zLCB0aGlzIG1heSBub3QgYmUgdHJ1ZSBhbnltb3JlLg0KRm9yIGxhdGVu Y3kgcmVxdWlyZW1lbnQsIGl0IGlzIG5vdCBnb25lIGV2ZW4gdGhlIG5ldHdvcmsgbG9hZCBpcyBi ZWxvdyBsaW5rIGNhcGFjaXR5LCBzbywgdGhlIFFvUyBpcyBzdGlsbCByZXF1aXJlZC4gDQoNCg0K TGluDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IEZyaWRheSwg T2N0b2JlciAyMCwgMjAxNyA1OjUxIFBNDQpUbzogTGluIEhhbiA8TGluLkhhbkBodWF3ZWkuY29t PjsgTWFuZnJlZGksIEFsYmVydCBFIDxhbGJlcnQuZS5tYW5mcmVkaUBib2VpbmcuY29tPg0KQ2M6 IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogSG9wLWJ5LWhvcCBbbm90IGRy YWZ0LWhhbi02bWFuLWluLWJhbmQtc2lnbmFsaW5nLWZvci10cmFuc3BvcnQtcW9zLTAwLnR4dF0N Cg0KT24gMjEvMTAvMjAxNyAxMjoyNywgTGluIEhhbiB3cm90ZToNCi4uLg0KPiBPbiB0aGUgb3Ro ZXIgaGFuZCwgYWxzbyBpbiB0aGVzZSBjb250cm9sbGVkIGVudmlyb25tZW50cywgYW5vdGhlciBv cHRpb24sIGZyZXF1ZW50bHksIGlzIHRvICJ0aHJvdyBiYW5kd2lkdGggYXQgdGhlIHByb2JsZW0u IiBHaXZlIHlvdXJzZWxmIHBsZW50eSBvZiBoZWFkcm9vbS4gSXQncyBsZXNzIGVsZWdhbnQgYW5k IGxlc3MgZnVuLCBidXQgaXQgd29ya3MgZ3JlYXQuDQo+IFtMSF0gbm90IGNvbXBsZXRlbHkgZ2V0 IHdoYXQgeW91IG1lYW4gDQoNCktlZXAgeW91ciBhdmVyYWdlIG5ldHdvcmsgdXRpbGlzYXRpb24g d2VsbCBiZWxvdyAxMCUgYW5kIHlvdXIgUW9TIHByb2JsZW1zIGFyZSBzb2x2ZWQuDQpJdCdzIGp1 c3QgcXVldWVpbmcgdGhlb3J5Lg0KDQogICBCcmlhbg0K From nobody Fri Oct 20 18:30:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3F6132C3F for ; Fri, 20 Oct 2017 18:30: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 z1_VlOv_PAp3 for ; Fri, 20 Oct 2017 18:30:11 -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 CA41B1320DC for ; Fri, 20 Oct 2017 18:30:10 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id m189so16352366qke.4 for ; Fri, 20 Oct 2017 18:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kDXRp61P+YvaeZeegdK4hpYtsjaBSxFl9Cxn58C0vEM=; b=teYzqX8SM+Z6DdLFehtAsiCGRIoeBvOAeyrAIOaBa3eWTLiI6GdDMTuQfIpeNjUzMV Y6C5e2JyNKpVSaenvUIxY0yKDkx6VuADlnLg+QWiKLtzcnG/pqFpN9IuvvTfSA5UK0fM ORWufayYKM9/972WkGV10fhIhjdZSnZ8TyHryl/FPZZ+uSdG1uMptsAYwqU10rxXERxu xeVL1Ub9J3KpbZIpcH1+UuXDUvwFX86r/XOQJGlupnkdFUFrh/44X22MouXABPfDG1uy hUzMG9c2lxAB5htGANRTW7+n33mNvQfv3BrhTb6+Ub7GoDt0vjsYF8HTL+Wt5GPxBmOp LFWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kDXRp61P+YvaeZeegdK4hpYtsjaBSxFl9Cxn58C0vEM=; b=Pi4PbHomL9JC36aR/nVIb9VkxmA5vLwQFg9uhcCp0akGTVPmepFlsD7kLAu1ZdnG1G d+KfaktSp2YZqi783styWSRRC/lOXE6pBUVV4jzRANnfWMcGwOSbyGKzgBYclzO7s6HT MgV6Wa5HQoQ332NJ+5cwWcyqiMlpRBw2y1e19SDRu+G1Nt4XLY0wWmTzWEyhO05RMG90 DdvVcWBU/cU+G0sb07kQtbbPu+z0ekh0jNIKDN1XHBKoIqzuSUyBRxxlMmdK3dn6rVN+ pAXeu3yQy7qhGD0Guu3EKVoVNfjcviPDbhkR0SSPTPoj2giTJua9ekcsVGLvEhBL+URN xhOw== X-Gm-Message-State: AMCzsaUgls4Xc9K4+s1XGy6wI23xBfeXdjvDad7lalWl5chKvi8CijoC BlzyxbrQkkwuUc4uuJwcQsN18hRxVTOxKLJC6IEyUg== X-Google-Smtp-Source: ABhQp+Qcpo5wCd38OgTRpFxufQWTJgr39wgM9jQ8yEFln6ErXrmLOGd2G5tVghvz/JXYA/959ssq2uBxdWtdExdISv0= X-Received: by 10.55.89.65 with SMTP id n62mr9072335qkb.51.1508549409778; Fri, 20 Oct 2017 18:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Fri, 20 Oct 2017 18:30:09 -0700 (PDT) In-Reply-To: <631451d4-9c3f-7b2e-d7ea-14648c91f07c@gmail.com> References: <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> <631451d4-9c3f-7b2e-d7ea-14648c91f07c@gmail.com> From: Tom Herbert Date: Fri, 20 Oct 2017 18:30:09 -0700 Message-ID: Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Brian E Carpenter Cc: "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 01:30:13 -0000 On Fri, Oct 20, 2017 at 5:42 PM, Brian E Carpenter wrote: > > On 21/10/2017 11:13, Tom Herbert wrote: > > On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 21/10/2017 09:53, Tom Herbert wrote: > >>> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John > >>> wrote: > >>> > >>>> In order packet delivery requirements considered harmful to the > >> Internet=E2=80=A6 > >>>> > >>>> > >>>> > >>>> I=E2=80=99m assuming random per packet flow label assignments are wi= thin spec as > >>>> long as they are set by the source. > >>>> > >>>> > >>>> > >>> > >>> Yes, there is no requirement that the flow label be persistent at all= in > >> a > >>> flow. > >> > >> http://mailman.postel.org/mailman/listinfo/internet-history says: > >> > >> To enable Flow-Label-based classification, source nodes SHOULD assi= gn > >> each unrelated transport connection and application data stream to = a > >> new flow. A typical definition of a flow for this purpose is any s= et > >> of packets carrying the same 5-tuple {dest addr, source addr, > >> protocol, dest port, source port}. It should be noted that a sourc= e > >> node always has convenient and efficient access to this 5-tuple, > >> which is not always the case for nodes that subsequently forward th= e > >> packet. > >> > >> So, technically it's a recommendation, not a requirement. But for load > >> balancing or ECMP to actually work, it's a requirement. > >> > > > > Brian, > > > > I don't think that says anything that the flow label has to be persiste= nt > > for the life of the connection. It is incorrect, though, if any nodes > > assume that the flow label is persistent. The soft state approach like = in > > this QoS draft doesn't require the flow label to be persistent. > > > > Load balancing only fails when the destination address is being treated= as > > an anycast and the address is being used as an endpoint of connections = that > > are on different hosts. But such stateful load balancing becomes obsole= te > > as the externally visible flow information is decoupled from the end-to= -end > > identification of the flow like happens in QUIC, ESP, etc. > > That's not really true for server load balancing. Delivering all packets > in the flow to the same *instance* of the host is essential to be > able to complete transactions. Whoever unwraps the flow identification > has to be able to select the required server instance, at line speed. Brian, The 5-tuple hashing for forwarding to VIPs only works to the extent that the 5-tuple hash identifies the transport flow and is readily visible. That may be true for plain TCP, but not necessarily other protocols. For instance, in QUIC the end points identify a connection by a connection ID that is separate from the 5-tuple. One of the goals is to be resilient to NAT so that even if the 5-tuple changes, like when the source address or port changes because NAT evicted a UDP binding, the QUIC connection is still viable (draft-ietf-quic-transport-07). So a load balancer just looking at UDP 5-tuples won't work for QUIC. There's a similar issue with MPTCP in that all of the sub-flows have different hashes but need to be delivered to the same server instance (draft-duchene-mptcp-load-balancing-00). > > https://tools.ietf.org/html/rfc7098 sort of hints at this and we > tried to go further in > https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing > but that faded away. And there's > https://tools.ietf.org/html/draft-wang-v6ops-flow-label-refelction > > Nothing seems to quite work. > For IPv6, I am wondering if each server instance could just be given a few million unique addresses and then replace load balancers with simple routing... In any case, I still don't see a protocol issue with flow labels. Maybe further discussion on this topic should be on tsvwg list? Tom From nobody Fri Oct 20 19:26:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7521320B5 for ; Fri, 20 Oct 2017 19:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Yn3q3VYpdMs for ; Fri, 20 Oct 2017 19:26:15 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 091C3126DD9 for ; Fri, 20 Oct 2017 19:26:15 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n89so13348990pfk.11 for ; Fri, 20 Oct 2017 19:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DiwITo8lSJh8m/KxENp9qYHFqmeoBECJ/g7XYMoQXmg=; b=MgG+FElce4xxhtNbUAwpWd6NljydGBM8LuqLXZbrzffoy0SG1LRjI/1M/sAL3Ssi5n NUKkku4xNYr3L/ZpB0DMl2z10ZNRRiZIvAGpzDOY01SIoFt6ZEtAd1XE3xZmwRAvA6+x ujkxnYD+Gi2X+nWsNdhbJ6OQxrbuugkFlju0Ny+Fn406u8JFtdrHpo4Bd7DaSbFI/JbG 8ZRu2Ca5WDWU08Z+aEsuVS5jT23oLyOu10Fncics5ndslvJPTng9Y+QAB3wC1fHHJwPs 6w16Wt1U20YyvIzTB88dZsBJI+6SfL8h/qlT7paXzWcHLyOMQgr25pRohtSMs2f0s2Es +ueA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=DiwITo8lSJh8m/KxENp9qYHFqmeoBECJ/g7XYMoQXmg=; b=N78F7SGWAoRbRhRLY8jbJ+Kz5gfTCWAK1KRXpX65kHA95IpYTbXliEYln2m/6Kyf5O fgidGdC3HKkVjSXUN5c1k0GsvAK/B7LvHN4852dckqvqhsJL5z2J6Ly4z8dII4jLi8zp pzXLTKkRkQnED0Q6goSou7zQ+xH90+QLiSSwhsjDCHvgkDPc8wOzO7SINuZwxf+tHLAP xvgnBM5DJWr+c2QIQTKHD+bTPHU6vc4xuLtjUIFINXSE03tbeBMwiWn0ocoeyO8CgWfb m4UUHqbC7UAe3CpZLLbBmhzRQFqsBlRHjsP0a0R+1Qu7ymxkBc90tSeagKSo0hKUxXH/ MSTA== X-Gm-Message-State: AMCzsaUbRlo+oyc3PcEYSqauyNhT/rk1Sily3A0q04MswvjU6j42W7Db F5j7rXjpWD6n8VV4C+qBacxYOg== X-Google-Smtp-Source: ABhQp+TUUisWFUKJ+EiuaTQ2dTjq3tOdBGwsP0/u9LHm4JGChKJQ82rIhU4ixsXeahHk7vgpHsj+eQ== X-Received: by 10.99.168.76 with SMTP id i12mr6097315pgp.427.1508552774012; Fri, 20 Oct 2017 19:26:14 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s83sm3806052pfg.104.2017.10.20.19.26.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 19:26:12 -0700 (PDT) Subject: Re: Flow label [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Tom Herbert Cc: "ipv6@ietf.org" References: <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> <20171019220935.GD878@faui40p.informatik.uni-erlangen.de> <33ff8930-d1af-ea54-7bb4-a6a9b289269e@gmail.com> <20171020144015.GA3093@faui40p.informatik.uni-erlangen.de> <8AE3421D-304B-42F9-B12A-361E21DFF069@employees.org> <2C4B0FD6-418E-441F-8B43-6C60451E3A51@cable.comcast.com> <67148eca-0764-3b32-69d6-3e198c5e610c@gmail.com> <631451d4-9c3f-7b2e-d7ea-14648c91f07c@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2b26a791-3fc0-5a10-2aa0-32a3e0e93d35@gmail.com> Date: Sat, 21 Oct 2017 15:26:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 02:26:17 -0000 On 21/10/2017 14:30, Tom Herbert wrote: > On Fri, Oct 20, 2017 at 5:42 PM, Brian E Carpenter > wrote: >> >> On 21/10/2017 11:13, Tom Herbert wrote: >>> On Fri, Oct 20, 2017 at 2:41 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> On 21/10/2017 09:53, Tom Herbert wrote: >>>>> On Fri, Oct 20, 2017 at 12:06 PM, Leddy, John >>>>> wrote: >>>>> >>>>>> In order packet delivery requirements considered harmful to the >>>> Internet=E2=80=A6 >>>>>> >>>>>> >>>>>> >>>>>> I=E2=80=99m assuming random per packet flow label assignments are = within spec as >>>>>> long as they are set by the source. >>>>>> >>>>>> >>>>>> >>>>> >>>>> Yes, there is no requirement that the flow label be persistent at a= ll in >>>> a >>>>> flow. >>>> >>>> http://mailman.postel.org/mailman/listinfo/internet-history says: >>>> >>>> To enable Flow-Label-based classification, source nodes SHOULD as= sign >>>> each unrelated transport connection and application data stream t= o a >>>> new flow. A typical definition of a flow for this purpose is any= set >>>> of packets carrying the same 5-tuple {dest addr, source addr, >>>> protocol, dest port, source port}. It should be noted that a sou= rce >>>> node always has convenient and efficient access to this 5-tuple, >>>> which is not always the case for nodes that subsequently forward = the >>>> packet. >>>> >>>> So, technically it's a recommendation, not a requirement. But for lo= ad >>>> balancing or ECMP to actually work, it's a requirement. >>>> >>> >>> Brian, >>> >>> I don't think that says anything that the flow label has to be persis= tent >>> for the life of the connection. It is incorrect, though, if any nodes= >>> assume that the flow label is persistent. The soft state approach lik= e in >>> this QoS draft doesn't require the flow label to be persistent. >>> >>> Load balancing only fails when the destination address is being treat= ed as >>> an anycast and the address is being used as an endpoint of connection= s that >>> are on different hosts. But such stateful load balancing becomes obso= lete >>> as the externally visible flow information is decoupled from the end-= to-end >>> identification of the flow like happens in QUIC, ESP, etc. >> >> That's not really true for server load balancing. Delivering all packe= ts >> in the flow to the same *instance* of the host is essential to be >> able to complete transactions. Whoever unwraps the flow identification= >> has to be able to select the required server instance, at line speed. >=20 > Brian, >=20 > The 5-tuple hashing for forwarding to VIPs only works to the extent > that the 5-tuple hash identifies the transport flow and is readily > visible. That may be true for plain TCP, but not necessarily other > protocols. For instance, in QUIC the end points identify a connection > by a connection ID that is separate from the 5-tuple. One of the goals > is to be resilient to NAT so that even if the 5-tuple changes, like > when the source address or port changes because NAT evicted a UDP > binding, the QUIC connection is still viable > (draft-ietf-quic-transport-07). So a load balancer just looking at UDP > 5-tuples won't work for QUIC. There's a similar issue with MPTCP in > that all of the sub-flows have different hashes but need to be > delivered to the same server instance > (draft-duchene-mptcp-load-balancing-00). Yes. Exactly the point of using the {source, destination, flow_label} 3-tuple in IPv6, but you know that. >> https://tools.ietf.org/html/rfc7098 sort of hints at this and we >> tried to go further in >> https://tools.ietf.org/html/draft-tarreau-extend-flow-label-balancing >> but that faded away. And there's >> https://tools.ietf.org/html/draft-wang-v6ops-flow-label-refelction >> >> Nothing seems to quite work. >> > For IPv6, I am wondering if each server instance could just be given a > few million unique addresses and then replace load balancers with > simple routing... Sure, but that means the client end would need to learn the address from the server end, as part of the first handshake. =20 > In any case, I still don't see a protocol issue with flow labels. I agree. > Maybe further discussion on this topic should be on tsvwg list? I'm not sure where server load balancing really belongs, but it's a pretty important topic. Brian From nobody Sun Oct 22 09:03:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5A0132CE7; Thu, 19 Oct 2017 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r81_NISAA82e; Thu, 19 Oct 2017 10:11:28 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFDE132320; Thu, 19 Oct 2017 10:11:28 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C64ED58C4CC; Thu, 19 Oct 2017 19:11:23 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id AB326B0CF0F; Thu, 19 Oct 2017 19:11:23 +0200 (CEST) Date: Thu, 19 Oct 2017 19:11:23 +0200 From: Toerless Eckert To: "Templin, Fred L" Cc: v6ops@ietf.org, Michael Richardson Subject: draft-templin-v6ops-pdhost-15 (was: Re: Loopback interface terminology issue) Message-ID: <20171019171123.GA878@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Sun, 22 Oct 2017 09:03:33 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 17:11:31 -0000 [moving to v6ops where the draft is, Bcc 6man] On Wed, Oct 18, 2017 at 04:57:37PM +0000, Templin, Fred L wrote: > Non-loopback addresses that would be assigned to a loopback interface would > have to come from a delegated IPv6 prefix. Please see 'draft-templin-v6ops-pdhost' > for procedures of how to assign addresses from a delegated prefix to a loopback > or other virtual interface: > > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > This document stems from my earlier works including RFC5558, RFC6179 > and 'draft-templin-aerolink' which talk about assigning delegated prefixes > to internal virtual interfaces such as loopbacks. But, the 'pdhost' draft is > still open for edits - should it be made standards-track? Nice draft. a) Wrt to standardization Q: The draft does not have any MUST/SHOULD/MAY, so i am a bit unsure what its asking to standardize. Eg: how would i verify if some implementation claiming to support it complies with it ? b) editorial: b.1) I would like to see only the terms "internal/external" interfaces being used instead of "virtual/physical" as the old IPv6 arch docs do. In the age of node virtualization "virtual" is meaningless, and "physical" is irritating. b.2) The introduction seems to be summarizing existing standards/practices in the first three paragraphs and then introduce the new work of this draft. I would suggest to consider restructuring to make this more explicit. Eg: first three paragraphs as "background", and then the following as the main part of the doc. Having them together in a single "introduction" is confusing. c) Logics: It would be nice to be more specific about what really constitutes an "internal application". For example in the 6man thread about the meaning of loopback addresses, i got the impression that folks would also understand a linux bridge with one side in the hypervisor and the other in a VM as internal interfaces, but IMHO thats just normal external interfaces: Aka: You could start outlining how you can convert the original design (downstream interface(s) with connected "hosts") into a "physcial internal" solution without changing anything in the approach: replace the downstream link with some e.g. virtual bridge and the hosts with VMs, and e-voila: internal applications/VMs). IMHO, this solution has no "internal" interfaces because the hypervisor and VMs are clearly different "nodes" in the IP architectuer. Then the next step is really thinking of the implications of more lightweight solutions. This unfortunately is where it gets tricky. Eg: Assume the hypervisor/VM changes to a linux host with containers, and the interfaces are veth pairs, which is popular in container-land. In the first place this does not look much different than the hypervisor/VM case, but in fact, there is a single TCP/IP stack/OS operating now the host and the containers, so the question is whether this is one IP node or multiple. I would argue that its still multiple nodes because the TCP/IP stack is virtualized into multiple virtual nodes in a lightweight fashion, and on the IP side the most easy recognition of this is that the interfaces used such as the veth pairs in linux still have two interfaces on them - one on the container, and one on the host. So, finally you get to even more lightweight application integration, which is where you'd use some form of loopback interfaces and for example create for every app an individual loopback interface and make it only use that interaface. Alas, linux does not even have a good model for this, aka: you can not really force a linux app to only use the address(es) of this one interface. So this IMHO ideal model is also implementation wise the most broken one in actual implementations. But it works if you have well-behaved apps that explicitly only bind sockets only to the address given to them. So, IMHO this is really what i would call "internal applications", because there is only one node = TCP/IP stack, we just manage the addresses at socket level, and even more so, the interfaces used, e.g.: loopback interfaces are not connected to links with multiple interfaces!!! In any case, its some form of definition like what i tried to say in the previous paragrph that IMHO is necessary to define what an "internal" application is. If folks have different opions wrt. to VMs, containers or "address" based applications being internal, then it would be good to see if we can even create a recommended terminology. Cheers Toerless > Thanks - Fred > > > -- > > 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 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Sun Oct 22 09:03:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2A4132355; Thu, 19 Oct 2017 15:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5wT95K2Gcmh; Thu, 19 Oct 2017 15:38:55 -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 BAB6E13308D; Thu, 19 Oct 2017 15:38:55 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id i5so8082145pfe.6; Thu, 19 Oct 2017 15:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2cKaTTr7XZ82Znp26cJPO34laTTBTd4Cd7jdceQM8PY=; b=YRbBClpE0L4ybJFqyYNnoA3tuoKf5pfE553Ap8arP55YxwZFLUnMTTpD4Kpfj7jKQ+ W3wgmqYZ75QgvCm2LMbhXCpRUkv9mHLcCmaEsBVTU7cLMlL+hM9+D+HwL622F4KJqy4i t5ik9v3wXLpiUPT0GLaVMSRDBB9qgj0+6YMXxWe0V18OoXHZlUL5ngpWb7rEHy7H4RdD IFLV1Qjthdi7AJwnAojkPXDOAD3xZ3xG5A0f2jYAA3xcyfR/gxq4qoiNFsoHQJvG1uIx gWTvIuXKq7xBuh/J3eFgF8OXle4Z6lXOmFb4iWy/zqqsiUgi84LdrA5IVjMSL10Nu3yR 9+Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2cKaTTr7XZ82Znp26cJPO34laTTBTd4Cd7jdceQM8PY=; b=LnzpAiMzlv/G8slBG/UgM9qbrxgcPfhF2a/SQ0AwXEzXLKJpHNtG2lXePDgS3+hvg4 qqh0l40uk7TFcdVc5Y5Ta+pUNJjPycCNnv1o+eRhEyuZ8bgBe6DPpGcWU2OGiC0KaCGG J92YqRVk5M5K3VKQZXXJ6P7veLUEbHQKKjIAobB5+0/rz2Oa0vEAvWSHfkpAKIaJ4L2W 58wfNrmOLm8eLMBtjcINWlQgQc3+Ds1PLyLkevu2rBo5FjbVD42/FkDgPnnq2GSMd2g2 GO0g2+wmdhQeTi9vsow7KjPOlJ0xX21me8gdVlvsbVcM9fF149mZ6sWwKotmkp6mqA0b uIgQ== X-Gm-Message-State: AMCzsaUjC9f3qpTEVjupCl8SHgb3IKrZvojdtA5t9JNeyKiSd5nu/RnB +yeTLLrdMS2VlmzirD5FQLzGBw== X-Google-Smtp-Source: ABhQp+RFtYJsLP6ZdpCbJC57QvaZ2Z3g9dbU1L2dqCxTXFVjcYMIgstZeKAWnXLVI542sEqgMKHErQ== X-Received: by 10.84.129.4 with SMTP id 4mr2564159plb.320.1508452734971; Thu, 19 Oct 2017 15:38:54 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p14sm25109982pgr.51.2017.10.19.15.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 15:38:53 -0700 (PDT) Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt To: tsvwg@ietf.org References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019211637.GB878@faui40p.informatik.uni-erlangen.de> <296dd642b31741cc8ec4aa4b52913037@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4845d544-7a54-4bba-9f6b-53f67c6e201b@gmail.com> Date: Fri, 20 Oct 2017 11:38:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 22 Oct 2017 09:03:33 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 22:38:57 -0000 Switching to tsvwg. 6man is Bcc'ed. Previous discussions followed on from https://mailarchive.ietf.org/arch/msg/ipv6/wb339ewBLP7Ijj2eCotCt-W_g8Y On 20/10/2017 11:00, Tom Herbert wrote: > On Thu, Oct 19, 2017 at 2:41 PM, Manfredi, Albert E < > albert.e.manfredi@boeing.com> wrote: > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert >> >>> Finally wrt. architectural cleanlyness: Per-flow service negotiation >>> IMHO is clearly a transport layer function, there is no concept of >>> 5-tuple flows at IP layer. >> >> I would agree I principle, although IPv6 does have that flow label that >> makes the 5-tuple less essential to identify an individual "flow," and it >> sits at layer 3. > > > Right. > > >> The problem remains, though: security mechanisms, which render the layer 4 >> QoS knobs unworkable. Everything outside the "security enclaves" at either >> end, and these security enclaves might just be inside the two end hosts >> themselves, will have to be delivered best effort. >> >> Bert, I don't follow. One of the big wins using the 3-tuple is that it can > still indicate a flow even if all the transport transport headers and > payload are encrypted. So this should allow specifying QoS without > revealing anything about the content except that the sender wants to group > certain packets together as a flow and apply QoS on them. Exactly. That's also why the flow label and traffic class are not covered by IPSec authentication, in case some mechanism changes them en route. Brian From nobody Sun Oct 22 12:48:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116A913ADB0 for ; Sun, 22 Oct 2017 12:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYme9FWtbcIN for ; Sun, 22 Oct 2017 12:48:09 -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 55F3413ADAF for ; Sun, 22 Oct 2017 12:48:09 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id n70so9983796vkf.11 for ; Sun, 22 Oct 2017 12:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B5KQAFVABX3t+vuDWGmN/MDqyXTDFxSJxkj0+vafBZA=; b=BGLS10Kb32b5Fe/17x5F33i+9kbMEvXiFoD2SrP+C18y68Xhvr/ycUIxwkfJ6XFBPI aeTrAvYVaIxKkj1FiSz+nCCVqdgThQUV3qo5iLhbBzUNmPjySJls/xf4S8kF0AJodM1t fYDVxoYUvJ/q2LaSwSqe3oedsHDe9dV3Zl2tDkJ7aV4rybZHEOtFwlPgS/bhl31uO+or qCxEseiw4ldr0Uyntn3RmYDatNWP4l1KmBaR5iLfcr1mYhrxnEceam+QnIk4G9uRxUEy FCEo9yKB07z0iiXj3/47u8OdzEVLZjG1z7Wcds85YH48e4GxQEWXegb7o7s3+CdG7Ybq tguQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B5KQAFVABX3t+vuDWGmN/MDqyXTDFxSJxkj0+vafBZA=; b=UdMIvBzW5kCssa+HG+f6NNlm8f2osD6TDy1bmayALFhDgHqVP7EGTWKA/T7YO/02VA ejtoXfjfiLEcxAr3VswyNf+jJqNC+pE2fbd8n0XHImAzfmpFUM91EoW5vG8+RS2A511f vAfFbXuJrruIAdb7u6GbxIptDbETo99ejh1IkEdPOPUEJIwx5U5WwS/tXmj9HQUy9pUp /DfPzGnBrv0gi1eHKbRN0xR9aNYwVOvne5AL4rkCSEJsTyBRvFtE5FMvj1VGd1UnmGKH Ahd/40ZrLrLfMGTIc1BAQxZSEP1CtcDPmYarijkTJHsUSouwj0w/5s8QKtIjcrxgzPqs krUg== X-Gm-Message-State: AMCzsaXsy01T+vmVK8/folTrfPIPR7Dw3n9OnTXVWxA5MclvDNBUfb5M UZk8LjjaREpBnIszOBpj0rasA2joz2O7qnUMigQ= X-Google-Smtp-Source: ABhQp+RkeZv/Ip1r+KyI+ZJ9xLkn5NC20y4flIMOeF3P7pMQcRXXjWlIwTplx/L/0Hh88SuFvuc2EtdcLgY3gENzeHM= X-Received: by 10.31.115.14 with SMTP id o14mr7505724vkc.79.1508701688293; Sun, 22 Oct 2017 12:48:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Sun, 22 Oct 2017 12:48:07 -0700 (PDT) Received: by 10.159.52.221 with HTTP; Sun, 22 Oct 2017 12:48:07 -0700 (PDT) In-Reply-To: <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> From: Mark Smith Date: Mon, 23 Oct 2017 06:48:07 +1100 Message-ID: Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] To: Lin Han Cc: "Manfredi, Albert E" , Brian E Carpenter , 6man WG Content-Type: multipart/alternative; boundary="94eb2c14c58633ef96055c27fce4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 19:48:12 -0000 --94eb2c14c58633ef96055c27fce4 Content-Type: text/plain; charset="UTF-8" On 21 Oct. 2017 10:28, "Lin Han" wrote: -----Original Message----- From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Sent: Friday, October 20, 2017 12:00 PM To: Lin Han ; Brian E Carpenter < brian.e.carpenter@gmail.com> Cc: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band- signaling-for-transport-qos-00.txt] -----Original Message----- From: Lin Han [mailto:Lin.Han@huawei.com] > ATM is failed due to many reasons, scalability is one of it. > This solution is not intended to replace completely the best-effort > transport service. The solution is only for those application which > really needs a flow level QoS, such as AR/VR, tactile internet, etc. > From this sense, it does not sacrifice the scalability of IP. Or at least, does not sacrifice it as much? ATM also had a UBR service. [LH] Yeah, everything has cost. But it is still different, ATM UBR is connection oriented, it needs setup and involves the control protocol such as PNNI. In our case, the IP architecture is not touched at all. IP best effort is as simple as before. Not at all. You're creating state in the forwarding plane. State created based on traffic characteristics is vulnerable to state exhaustion attacks. Even in closed domains this can be an issue, because "closed" domains attached to the Internet aren't guarateed to stay closed. Back in 2000 Nimbda caused a DoS on a router that I looked after in a closed domain that was creating dynamic ACL entries for basic stateful firewalling. RFC791 and RFC8200 forwarding is stateless. I'd even say traffic created state is worse than connection oriented state such as switched virtual circuits in ATM. In that model, hosts are requesting permission to send traffic on the network before they're able to - if the network can't set up a connection for a host, the host cannot contribute traffic load to the network. Stateless and stateful forwarding is the fundamental difference between packet and circuit switched networks. See 2.3 in RFC1958. Regards, Mark. The new solution does not impact the IP routing or any other protocols. But my point was only that out in the wild, you have no guarantee that the routers in the path will know what to do with your in-band QoS demands. Only in situations where all the routers are in your control will you have that guarantee. But sure, in walled gardens, these cool ideas can be made to work. [LH] Agreed. But not that strict. As I said in the document, for optimization, the HbH router is only needed for the point of the congestion or device introducing a lot latency. It does not need all routers on the path to be HbH aware. And if a router cannot guarantee the bandwidth, the application can fall back to normal TCP, it does not completely disable the transport. The basic idea still works for multiple domain, I don't want to talk about it since it may introduce more debating. Let see if there is any flaw for a single domain. If it works, I'm sure technically we don't have problem to apply to multiple domains. One more infor for this domain issue. The network environment that an application may need this QoS (ultra-high bandwidth and ultra-low latency) may be flat, and very likely has a few domains (one or two). This is because of the limit of propagation delay. For example, in the architecture of 5G that is supposed to support the latency as low as single digit ms, the content provider is supposed to connect to the SP's access network directly and in the same metro. Only this deployment can provide the physical distance as short as possible. On the other hand, also in these controlled environments, another option, frequently, is to "throw bandwidth at the problem." Give yourself plenty of headroom. It's less elegant and less fun, but it works great. [LH] not completely get what you mean Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --94eb2c14c58633ef96055c27fce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 21 Oct. 2017 10:28, "Lin Han" <Lin.Han@huawei.com> wrote:


-----Original Message-----
From: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com]
Sent: Friday, October 20, 2017 12:00 PM
To: Lin Han <Lin.Han@huawei.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-tran= sport-qos-00.txt]

-----Original Message-----
From: Lin Han [mailto:Lin.Han@huawei.= com]

> ATM is failed due to many reasons, scalability is one of it.
> This solution is not intended to replace completely the best-effort > transport service. The solution is only for those application which > really needs a flow level QoS, such as AR/VR, tactile internet, etc. > From this sense, it does not sacrifice the scalability of IP.

Or at least, does not sacrifice it as much? ATM also had a UBR service.

[LH] Yeah, everything has cost. But it is still different, ATM UBR is= connection oriented, it needs setup and involves the control protocol such= as PNNI. In our case, the IP architecture is not touched at all. IP best e= ffort is as simple as before.

Not at all.

You're creating state in the forwarding plane. State= created based on traffic characteristics=C2=A0 is vulnerable to state exha= ustion attacks.

Even in = closed domains this can be an issue, because "closed" domains att= ached to the Internet aren't guarateed to stay closed. Back in 2000 Nim= bda caused a DoS on a router that I looked after in a closed domain that wa= s creating dynamic ACL entries for basic stateful firewalling.

RFC791 and RFC8200 forwarding is sta= teless.

I'd even say= traffic created state is worse than connection oriented state such as swit= ched virtual circuits in ATM. In that model, hosts are requesting permissio= n to send traffic on the network before they're able to - if the networ= k can't set up a connection for a host, the host cannot contribute traf= fic load to the network.

Stateless and stateful forwarding is the fundamental difference between pa= cket and circuit switched networks.

See 2.3 in RFC1958.

Regards,
Mark.

=

The new solution d= oes not impact the IP routing or any other protocols.

But my point was only that out in the wild, you have no guarantee that the = routers in the path will know what to do with your in-band QoS demands. Onl= y in situations where all the routers are in your control will you have tha= t guarantee. But sure, in walled gardens, these cool ideas can be made to w= ork.
[LH] Agreed. But not that strict. As I said in the document, for opti= mization, the HbH router is only needed for the point of the congestion or = device introducing a lot latency. It does not need all routers on the path = to be HbH aware. And if a router cannot guarantee the bandwidth, the applic= ation can fall back to normal TCP, it does not completely disable the trans= port.
The basic idea still works for multiple domain, I don't want to talk ab= out it since it may introduce more debating. Let see if there is any flaw f= or a single domain. If it works, I'm sure technically we don't have= problem to apply to multiple domains.
One more infor for this domain issue. The network environment that an appli= cation may need this QoS (ultra-high bandwidth and ultra-low latency) may b= e flat, and very likely has a few domains (one or two). This is because of = the limit of propagation delay. For example, in the architecture of 5G that= is supposed to support the latency as low as single digit ms, the content = provider is supposed to connect to the SP's access network directly and= in the same metro. Only this deployment can provide the physical distance = as short as possible.

On the other hand, also in these controlled environments, another option, f= requently, is to "throw bandwidth at the problem." Give yourself = plenty of headroom. It's less elegant and less fun, but it works great.=
[LH] not completely get what you mean

Bert


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

--94eb2c14c58633ef96055c27fce4-- From nobody Sun Oct 22 16:07:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AE513BE0E for ; Sun, 22 Oct 2017 16:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahhd4v-JPMtj for ; Sun, 22 Oct 2017 16:07:34 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C4713BE0D for ; Sun, 22 Oct 2017 16:07:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9MN7WLH030122; Sun, 22 Oct 2017 16:07:32 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9MN7TJ6030102 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Sun, 22 Oct 2017 16:07:29 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 22 Oct 2017 16:07:28 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Sun, 22 Oct 2017 16:07:28 -0700 From: "Manfredi, Albert E" To: Mark Smith CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTS26zGgZ7QgKuvkSUCM+gj0wC9aLwdV7w Date: Sun, 22 Oct 2017 23:07:28 +0000 Message-ID: <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:07:36 -0000 RnJvbTogTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dIA0KDQo+IEZy b206IExpbiBIYW4gW21haWx0bzpMaW4uSGFuQGh1YXdlaS5jb21dDQoNCj4+IFtMSF0gWWVhaCwg ZXZlcnl0aGluZyBoYXMgY29zdC4gQnV0IGl0IGlzIHN0aWxsIGRpZmZlcmVudCwgQVRNIFVCUiBp cw0KPj4gY29ubmVjdGlvbiBvcmllbnRlZCwgaXQgbmVlZHMgc2V0dXAgYW5kIGludm9sdmVzIHRo ZSBjb250cm9sIHByb3RvY29sDQo+PiBzdWNoIGFzIFBOTkkuIEluIG91ciBjYXNlLCB0aGUgSVAg YXJjaGl0ZWN0dXJlIGlzIG5vdCB0b3VjaGVkIGF0IGFsbC4NCj4+IElQIGJlc3QgZWZmb3J0IGlz IGFzIHNpbXBsZSBhcyBiZWZvcmUuDQo+DQo+IE5vdCBhdCBhbGwuDQo+DQo+IFlvdSdyZSBjcmVh dGluZyBzdGF0ZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gU3RhdGUgY3JlYXRlZCBiYXNlZCBv bg0KPiB0cmFmZmljIGNoYXJhY3RlcmlzdGljc8KgIGlzIHZ1bG5lcmFibGUgdG8gc3RhdGUgZXho YXVzdGlvbiBhdHRhY2tzLg0KDQpJIHRoaW5rIHRoYXQgYWxsIExpbiB3YXMgc2F5aW5nIHdhcywg ImlmIHlvdSB1c2UgYmVzdCBlZmZvcnQsIHRoZW4geW91IGhhdmVu4oCZdCBzYWNyaWZpY2VkIHNj YWxhYmlsaXR5LiIgV2hpY2ggaXMgdHJ1ZSBlbm91Z2gsIEkgdGhpbmsuIFdoZXJlYXMsIHdpdGgg QVRNLCB5b3UgYXJlIHN0aWxsIGhhdmluZyB0byBzZXQgdXAgdGhhdCBWQyBhaGVhZCBvZiB0aW1l LCBldmVuIGlmLCB3aXRoIFVCUiBzZXJ2aWNlLCB5b3UgYXJlbid0IHNwZWNpZnlpbmcgYW55IFFv UyByZXF1aXJlbWVudHMgYWxvbmcgdGhhdCBwYXRoLg0KDQo+IEV2ZW4gaW4gY2xvc2VkIGRvbWFp bnMgdGhpcyBjYW4gYmUgYW4gaXNzdWUsIGJlY2F1c2UgImNsb3NlZCIgZG9tYWlucw0KPiBhdHRh Y2hlZCB0byB0aGUgSW50ZXJuZXQgYXJlbid0IGd1YXJhdGVlZCB0byBzdGF5IGNsb3NlZC4NCg0K WWVzLCBhbHRob3VnaCBJIHRoaW5rIExpbiB3YXMgc2F5aW5nLCBpZiB5b3UgZW5jb3VudGVyIHJv dXRlcnMgdGhhdCBkb27igJl0IGtub3cgZGlkZGx5IGFib3V0IGhpcyBpbi1iYW5kIHNpZ25hbGlu ZywgQU5EIHRoZXNlIHJvdXRlcnMgYXJlbid0IHBhcnRpY3VsYXJseSBjb25nZXN0ZWQsIHRoZW4g YWxsIHNob3VsZCBzdGlsbCB3b3JrIGZpbmUuIFRoaXMgdHJhZmZpYyB3b3VsZCBob3BlZnVsbHkg c2FpbCB0aHJvdWdoIHRoZXNlIGxpZ2h0bHkgbG9hZGVkIGludGVyLWNhcnJpZXIgcm91dGVycywg YW5kIHRoZW4gdGhlIFFvUyBrbm9icyB3b3VsZCBjb21lIGludG8gcGxheSBpbiBoaXMgb3duIElT UCBuZXR3b3JrLg0KDQo+IFJGQzc5MSBhbmQgUkZDODIwMCBmb3J3YXJkaW5nIGlzIHN0YXRlbGVz cy4NCj4NCj4gSSdkIGV2ZW4gc2F5IHRyYWZmaWMgY3JlYXRlZCBzdGF0ZSBpcyB3b3JzZSB0aGFu IGNvbm5lY3Rpb24gb3JpZW50ZWQgc3RhdGUNCj4gc3VjaCBhcyBzd2l0Y2hlZCB2aXJ0dWFsIGNp cmN1aXRzIGluIEFUTS4gSW4gdGhhdCBtb2RlbCwgaG9zdHMgYXJlDQo+IHJlcXVlc3RpbmcgcGVy bWlzc2lvbiB0byBzZW5kIHRyYWZmaWMgb24gdGhlIG5ldHdvcmsgYmVmb3JlIHRoZXkncmUgYWJs ZQ0KPiB0byAtIGlmIHRoZSBuZXR3b3JrIGNhbid0IHNldCB1cCBhIGNvbm5lY3Rpb24gZm9yIGEg aG9zdCwgdGhlIGhvc3QgY2Fubm90DQo+IGNvbnRyaWJ1dGUgdHJhZmZpYyBsb2FkIHRvIHRoZSBu ZXR3b3JrLg0KDQpUaGF0J3MgYmVlbiBteSByZWFjdGlvbiBoZXJlIHRvby4gSSB0aGluaywgYXQg YSBtb3N0IGZ1bmRhbWVudGFsIGxldmVsLCBJUCBpcyBhIHRlY2huaXF1ZSB0aGF0IGFsbG93cyBm b3IgcGxlbnR5IG9mICpjaGVhcCBiYW5kd2lkdGgqLCB3aGljaCBoYXMgbWFkZSBRb1MgZ3VhcmFu dGVlcyBtb3N0bHkgdW5uZWNlc3NhcnkuIENoZWFwIGJhbmR3aWR0aCBhbGxvd3MsIGV2ZW4gYmVn cyBmb3Igb3Zlci1wcm92aXNpb25pbmcgaW4gdGhlIG5ldHdvcmssIHdoaWNoIG1ha2VzIGNvbXBs aWNhdGVkIFFvUyBndWFyYW50ZWVzIHVubmVjZXNzYXJ5LiBBbmQgZnVydGhlcm1vcmUsIGFwcHMg dGhhdCBkbyByZXF1aXJlIGNlcnRhaW4gcXVhbGl0eSBsZXZlbHMgdGFrZSBpdCB1cG9uIHRoZW1z ZWx2ZXMgdG8gYWRqdXN0IHRvIHdoYXQncyBhdmFpbGFibGUsIHJhdGhlciB0aGFuIGdpdmluZyB0 aGF0IHJlc3BvbnNpYmlsaXR5IHRvIHRoZSBpbnRlcnZlbmluZyBuZXR3b3JrLiBJIHRoaW5rIHRo YXQgUlRQL1JUU1Agd2FzIHF1aXRlIHJldm9sdXRpb25hcnksIGluIHRoZSB0ZWxlY29tIHdvcmxk Lg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgc2NoZW1lcyBsaWtlIEFUTSBhc3N1bWUgKmV4cGVuc2l2 ZSBiYW5kd2lkdGgqLCBzbyB0aGV5IG1ha2UgYSBiaWcgZGVhbCBhYm91dCBkb2xpbmcgb3V0IGJh bmR3aWR0aCB3aXRoIGZpbmUgZ3JhbnVsYXJpdHkuIE9yLCBtb3JlIHJlYWxpc3RpY2FsbHksIHRo ZXkgb3B0aW1pc3RpY2FsbHkgY3JlYXRlZCB0aGUga25vYnMgZm9yIGRvaW5nIHNvLCB3aGljaCBw cm92ZWQgd2F5IHRvbyBjb21wbGljYXRlZCwgaW4gdGhlIGZhY2Ugb2YgdGhlICJjaGVhcCBiYW5k d2lkdGgiIGNvbm5lY3Rpb25sZXNzIElQIGNvbXBldGl0aW9uIG9mIHRoZSBkYXkuIEJ1dCB0aGVy ZSBoYXMgYmVlbiBhIHN1Y2Nlc3Npb24gb2YgZWZmb3J0cywgZnJvbSBlYXJseSBvbiBpbiBJUCwg dG8gYWRkIFFvUyBrbm9icy4NCg0KQmVydA0KDQo= From nobody Sun Oct 22 20:17:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50A13CF0E for ; Sun, 22 Oct 2017 20:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiU3RS7EmxZo for ; Sun, 22 Oct 2017 20:17:16 -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 B05BE13CF0B for ; Sun, 22 Oct 2017 20:17:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYG19119; Mon, 23 Oct 2017 03:17:14 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 04:17:13 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.36]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 23 Oct 2017 11:17:08 +0800 From: Tuboyan To: "Manfredi, Albert E" , Mark Smith CC: 6man WG Subject: =?utf-8?B?562U5aSNOiBIb3AtYnktaG9wIFtub3QgZHJhZnQtaGFuLTZtYW4taW4tYmFu?= =?utf-8?Q?d-signaling-for-transport-qos-00.txt]?= Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSTlPtaI95VpGm0KV6fdGmcn50aLrYoqAgAEplICAAAakgIAASruAgALnUYCAADeyAIAAyf1g Date: Mon, 23 Oct 2017 03:17:08 +0000 Message-ID: <9183E046F3015645850901915FF624927334CC80@nkgeml514-mbs.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.155.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.59ED5F3A.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ed51a0ab918d04e08cb12929afd71511 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 03:17:18 -0000 SGkgQmVydCwNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpcHY2IFttYWls dG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTWFuZnJlZGksIEFsYmVydCBFDQrlj5Hp gIHml7bpl7Q6IDIwMTflubQxMOaciDIz5pelIDc6MDcNCuaUtuS7tuS6ujogTWFyayBTbWl0aA0K 5oqE6YCBOiA2bWFuIFdHDQrkuLvpopg6IFJFOiBIb3AtYnktaG9wIFtub3QgZHJhZnQtaGFuLTZt YW4taW4tYmFuZC1zaWduYWxpbmctZm9yLXRyYW5zcG9ydC1xb3MtMDAudHh0XQ0KDQpGcm9tOiBN YXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0gDQoNCj4gRnJvbTogTGlu IEhhbiBbbWFpbHRvOkxpbi5IYW5AaHVhd2VpLmNvbV0NCg0KPj4gW0xIXSBZZWFoLCBldmVyeXRo aW5nIGhhcyBjb3N0LiBCdXQgaXQgaXMgc3RpbGwgZGlmZmVyZW50LCBBVE0gVUJSIGlzIA0KPj4g Y29ubmVjdGlvbiBvcmllbnRlZCwgaXQgbmVlZHMgc2V0dXAgYW5kIGludm9sdmVzIHRoZSBjb250 cm9sIHByb3RvY29sIA0KPj4gc3VjaCBhcyBQTk5JLiBJbiBvdXIgY2FzZSwgdGhlIElQIGFyY2hp dGVjdHVyZSBpcyBub3QgdG91Y2hlZCBhdCBhbGwuDQo+PiBJUCBiZXN0IGVmZm9ydCBpcyBhcyBz aW1wbGUgYXMgYmVmb3JlLg0KPg0KPiBOb3QgYXQgYWxsLg0KPg0KPiBZb3UncmUgY3JlYXRpbmcg c3RhdGUgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuIFN0YXRlIGNyZWF0ZWQgYmFzZWQgb24gDQo+ IHRyYWZmaWMgY2hhcmFjdGVyaXN0aWNzwqAgaXMgdnVsbmVyYWJsZSB0byBzdGF0ZSBleGhhdXN0 aW9uIGF0dGFja3MuDQoNCkkgdGhpbmsgdGhhdCBhbGwgTGluIHdhcyBzYXlpbmcgd2FzLCAiaWYg eW91IHVzZSBiZXN0IGVmZm9ydCwgdGhlbiB5b3UgaGF2ZW7igJl0IHNhY3JpZmljZWQgc2NhbGFi aWxpdHkuIiBXaGljaCBpcyB0cnVlIGVub3VnaCwgSSB0aGluay4gV2hlcmVhcywgd2l0aCBBVE0s IHlvdSBhcmUgc3RpbGwgaGF2aW5nIHRvIHNldCB1cCB0aGF0IFZDIGFoZWFkIG9mIHRpbWUsIGV2 ZW4gaWYsIHdpdGggVUJSIHNlcnZpY2UsIHlvdSBhcmVuJ3Qgc3BlY2lmeWluZyBhbnkgUW9TIHJl cXVpcmVtZW50cyBhbG9uZyB0aGF0IHBhdGguDQoNCj4gRXZlbiBpbiBjbG9zZWQgZG9tYWlucyB0 aGlzIGNhbiBiZSBhbiBpc3N1ZSwgYmVjYXVzZSAiY2xvc2VkIiBkb21haW5zIA0KPiBhdHRhY2hl ZCB0byB0aGUgSW50ZXJuZXQgYXJlbid0IGd1YXJhdGVlZCB0byBzdGF5IGNsb3NlZC4NCg0KWWVz LCBhbHRob3VnaCBJIHRoaW5rIExpbiB3YXMgc2F5aW5nLCBpZiB5b3UgZW5jb3VudGVyIHJvdXRl cnMgdGhhdCBkb27igJl0IGtub3cgZGlkZGx5IGFib3V0IGhpcyBpbi1iYW5kIHNpZ25hbGluZywg QU5EIHRoZXNlIHJvdXRlcnMgYXJlbid0IHBhcnRpY3VsYXJseSBjb25nZXN0ZWQsIHRoZW4gYWxs IHNob3VsZCBzdGlsbCB3b3JrIGZpbmUuIFRoaXMgdHJhZmZpYyB3b3VsZCBob3BlZnVsbHkgc2Fp bCB0aHJvdWdoIHRoZXNlIGxpZ2h0bHkgbG9hZGVkIGludGVyLWNhcnJpZXIgcm91dGVycywgYW5k IHRoZW4gdGhlIFFvUyBrbm9icyB3b3VsZCBjb21lIGludG8gcGxheSBpbiBoaXMgb3duIElTUCBu ZXR3b3JrLg0KDQo+IFJGQzc5MSBhbmQgUkZDODIwMCBmb3J3YXJkaW5nIGlzIHN0YXRlbGVzcy4N Cj4NCj4gSSdkIGV2ZW4gc2F5IHRyYWZmaWMgY3JlYXRlZCBzdGF0ZSBpcyB3b3JzZSB0aGFuIGNv bm5lY3Rpb24gb3JpZW50ZWQgDQo+IHN0YXRlIHN1Y2ggYXMgc3dpdGNoZWQgdmlydHVhbCBjaXJj dWl0cyBpbiBBVE0uIEluIHRoYXQgbW9kZWwsIGhvc3RzIA0KPiBhcmUgcmVxdWVzdGluZyBwZXJt aXNzaW9uIHRvIHNlbmQgdHJhZmZpYyBvbiB0aGUgbmV0d29yayBiZWZvcmUgDQo+IHRoZXkncmUg YWJsZSB0byAtIGlmIHRoZSBuZXR3b3JrIGNhbid0IHNldCB1cCBhIGNvbm5lY3Rpb24gZm9yIGEg aG9zdCwgDQo+IHRoZSBob3N0IGNhbm5vdCBjb250cmlidXRlIHRyYWZmaWMgbG9hZCB0byB0aGUg bmV0d29yay4NCg0KVGhhdCdzIGJlZW4gbXkgcmVhY3Rpb24gaGVyZSB0b28uIEkgdGhpbmssIGF0 IGEgbW9zdCBmdW5kYW1lbnRhbCBsZXZlbCwgSVAgaXMgYSB0ZWNobmlxdWUgdGhhdCBhbGxvd3Mg Zm9yIHBsZW50eSBvZiAqY2hlYXAgYmFuZHdpZHRoKiwgd2hpY2ggaGFzIG1hZGUgUW9TIGd1YXJh bnRlZXMgbW9zdGx5IHVubmVjZXNzYXJ5LiBDaGVhcCBiYW5kd2lkdGggYWxsb3dzLCBldmVuIGJl Z3MgZm9yIG92ZXItcHJvdmlzaW9uaW5nIGluIHRoZSBuZXR3b3JrLCB3aGljaCBtYWtlcyBjb21w bGljYXRlZCBRb1MgZ3VhcmFudGVlcyB1bm5lY2Vzc2FyeS4gQW5kIGZ1cnRoZXJtb3JlLCBhcHBz IHRoYXQgZG8gcmVxdWlyZSBjZXJ0YWluIHF1YWxpdHkgbGV2ZWxzIHRha2UgaXQgdXBvbiB0aGVt c2VsdmVzIHRvIGFkanVzdCB0byB3aGF0J3MgYXZhaWxhYmxlLCByYXRoZXIgdGhhbiBnaXZpbmcg dGhhdCByZXNwb25zaWJpbGl0eSB0byB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yay4gSSB0aGluayB0 aGF0IFJUUC9SVFNQIHdhcyBxdWl0ZSByZXZvbHV0aW9uYXJ5LCBpbiB0aGUgdGVsZWNvbSB3b3Js ZC4NCg0KW0JveWFuVHVdIFdpdGhvdXQgaGVscCBmcm9tIG5ldHdvcmssIGV2ZW4gYXBwIGluIGhv c3QgY2FuIGFkanVzdCB0byB3aGF0J3MgYXZhaWxhYmxlLCBidXQgYXBwIHN0aWxsIGNhbm5vdCBn ZXQgYmFuZHdpZHRoIGl0IG5lZWQgLHN1Y2ggYXMgVlIgc3RlYW0gc2VydmljZS4gDQoNCk9uIHRo ZSBvdGhlciBoYW5kLCBzY2hlbWVzIGxpa2UgQVRNIGFzc3VtZSAqZXhwZW5zaXZlIGJhbmR3aWR0 aCosIHNvIHRoZXkgbWFrZSBhIGJpZyBkZWFsIGFib3V0IGRvbGluZyBvdXQgYmFuZHdpZHRoIHdp dGggZmluZSBncmFudWxhcml0eS4gT3IsIG1vcmUgcmVhbGlzdGljYWxseSwgdGhleSBvcHRpbWlz dGljYWxseSBjcmVhdGVkIHRoZSBrbm9icyBmb3IgZG9pbmcgc28sIHdoaWNoIHByb3ZlZCB3YXkg dG9vIGNvbXBsaWNhdGVkLCBpbiB0aGUgZmFjZSBvZiB0aGUgImNoZWFwIGJhbmR3aWR0aCIgY29u bmVjdGlvbmxlc3MgSVAgY29tcGV0aXRpb24gb2YgdGhlIGRheS4gQnV0IHRoZXJlIGhhcyBiZWVu IGEgc3VjY2Vzc2lvbiBvZiBlZmZvcnRzLCBmcm9tIGVhcmx5IG9uIGluIElQLCB0byBhZGQgUW9T IGtub2JzLg0KDQpCZXJ0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmcNCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Mon Oct 23 09:21:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F644137ED6 for ; Mon, 23 Oct 2017 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNJJ3cbrSz_O for ; Mon, 23 Oct 2017 09:21:38 -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 88DB713954E for ; Mon, 23 Oct 2017 09:21:38 -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 v9NGLbr2053696; Mon, 23 Oct 2017 09:21:37 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9NGLUW1053659 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 23 Oct 2017 09:21:30 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 23 Oct 2017 09:21:29 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 23 Oct 2017 09:21:29 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: Loopback interface terminology issue Thread-Topic: Loopback interface terminology issue Thread-Index: AQHTRtByPxn1iJZL+kqA+Ph9pp2qTaLnGukAgAHL5YCACMBioA== Date: Mon, 23 Oct 2017 16:21:29 +0000 Message-ID: References: <4998af7c-700d-369d-f64f-a8f4ea585084@gmail.com> <20171015013639.GA20159@faui40p.informatik.uni-erlangen.de> <20171015015318.764838AF5D66@rock.dv.isc.org> <20171015024129.GB20159@faui40p.informatik.uni-erlangen.de> <20171016181442.GA27393@faui40p.informatik.uni-erlangen.de> <647a3d6d-98eb-7fa8-6986-bb3044394f0d@gmail.com> <00025f1910094081a96b24cfdcfaa694@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 16:21:40 -0000 SGkgQnJpYW4sDQoNCkkgc2VlIHRoZSBwb3NzaWJpbGl0eSBmb3IgYSBzdGFuZGFyZHMtdHJhY2sg ZHJhZnQgdGhhdCBzcGVjaWZpZXMgaG93IHRvIGFzc2lnbg0KSVB2NiBhZGRyZXNzZXMgYW5kIHBy ZWZpeGVzIHRvIGxvb3BiYWNrcyBhbmQgb3RoZXIgdmlydHVhbCBpbnRlcmZhY2VzIChlLmcuLA0K YW4gaW50ZXJuYWwgbmV0d29yayBvZiB2aXJ0dWFsIG1hY2hpbmVzKS4gV2UgYWxzbyBzYXcgY29t bWVudHMgZnJvbQ0KVG9lcmxlc3MgRWNrZXJ0IGFuZCBNaWNoYWVsIFJpY2hhcmRzb24gZXhwcmVz c2luZyBzaW1pbGFyIHNlbnRpbWVudHMuDQoNCkRvIHlvdSB0aGluayBpdCB3b3VsZCBiZSBhIGdv b2QgaWRlYSB0byBjdXQgYSBsaXR0bGUgNS02IHBhZ2UgZHJhZnQgb24NCnRoaXM/IElmIHNvLCB3 b3VsZCB5b3UgYmUgaW50ZXJlc3RlZCBpbiBjby1hdXRob3JpbmcsIGFuZCBwb3NzaWJseSBhbHNv DQppbmNsdWRpbmcgTWljaGFlbCBhbmQgVG9lcmxlc3M/DQoNClRoYW5rcyAtIEZyZWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFp bHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogVHVlc2RheSwgT2N0b2Jl ciAxNywgMjAxNyAxMjozOSBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPjsgaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogTG9vcGJhY2sgaW50 ZXJmYWNlIHRlcm1pbm9sb2d5IGlzc3VlDQo+IA0KPiBPbiAxNy8xMC8yMDE3IDEyOjE1LCBUZW1w bGluLCBGcmVkIEwgd3JvdGU6DQo+ID4gQnJpYW4sDQo+ID4NCj4gPiBIZXJlIGlzIHdoYXQgaXQg c2F5cyBpbiAnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnOg0KPiA+DQo+ID4gICAiVGhpcyBk b2N1bWVudCBhbHNvIGNvbnNpZGVycyB0aGUgY2FzZSB3aGVuICdSJyBkb2VzIG5vdCBoYXZlIGFu eQ0KPiA+ICAgIGRvd25zdHJlYW0gaW50ZXJmYWNlcywgYW5kIGNhbiB1c2UgJ1AnIHNvbGVseSBm b3IgaXRzIG93biBpbnRlcm5hbA0KPiA+ICAgIGFkZHJlc3NpbmcgcHVycG9zZXMuICBJbiB0aGF0 IGNhc2UsICdSJyBhc3NpZ25zICdQJyB0byBhIHZpcnR1YWwNCj4gPiAgICBpbnRlcmZhY2UgKGUu Zy4sIGEgbG9vcGJhY2spIHRoYXQgZmlsbHMgdGhlIHJvbGUgb2YgYSBkb3duc3RyZWFtDQo+ID4g ICAgaW50ZXJmYWNlLg0KPiA+DQo+ID4gICAgJ1InIGNhbiB0aGVuIGZ1bmN0aW9uIHVuZGVyIHRo ZSB3ZWFrIGVuZCBzeXN0ZW0gKGFrYSAid2VhayBob3N0IikNCj4gPiAgICBtb2RlbCBbUkZDMTEy Ml1bUkZDODAyOF0gYnkgYXNzaWduaW5nIGFkZHJlc3NlcyB0YWtlbiBmcm9tICdQJyB0byBhDQo+ ID4gICAgdmlydHVhbCBpbnRlcmZhY2UgYXMgc2hvd24gaW4gRmlndXJlIDI6Ig0KPiA+DQo+ID4g SW50ZXJuYWwgdmlydHVhbCBpbnRlcmZhY2VzIHdlcmUgYWxzbyBkaXNjdXNzZWQgaW4gUkZDNTU1 OC4NCj4gDQo+IFdlbGwgeWVzOyBpbmRlZWQgdGhpcyB0b3BpYyBpcyB0b3VjaGVkIG9uIGluIG1h bnkgUkZDcyBidXQNCj4gbm93aGVyZSBpcyBpdCBkZWZpbmVkIGFzIHBhcnQgb2YgdGhlIGJhc2lj IGFyY2hpdGVjdHVyZSwNCj4gd2hpY2ggaXMgbXkgbWFpbiBwb2ludC4gVXNpbmcgYSBjb25jZXB0 IHRoYXQgaGFzIG5vIHByaW5jaXBhbA0KPiBkZWZpbml0aW9uIGlzIGdlbmVyYWxseSBhIHNvdXJj ZSBvZiBjb25mdXNpb24uDQo+IA0KPiAgICAgQnJpYW4NCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBG cmVkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaXB2 NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIEUgQ2Fy cGVudGVyDQo+ID4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyAzOjQ1IFBNDQo+ID4+ IFRvOiBpcHY2QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBMb29wYmFjayBpbnRlcmZhY2Ug dGVybWlub2xvZ3kgaXNzdWUNCj4gPj4NCj4gPj4gT24gMTcvMTAvMjAxNyAwNzo0OSwg56We5piO 6YGU5ZOJIHdyb3RlOg0KPiA+Pj4gQXQgTW9uLCAxNiBPY3QgMjAxNyAyMDoxNDo0MiArMDIwMCwN Cj4gPj4+IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4gd3JvdGU6DQo+ID4+Pg0KPiA+ Pj4+PiBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGlzIG1lYW5zLCBidXQgaW4gYW55IGNhc2Ug SSBhZ3JlZSB3aXRoIE1hcmsNCj4gPj4+Pj4gdGhhdCBJTU8gdGhpcyBpcyBtb3JlIGFib3V0IHRo ZSB3ZWFrL3N0cm9uZyBob3N0IG1vZGVsIHRoYW4NCj4gPj4+Pj4gZm9yd2FyZGluZy9ub24tZm9y d2FyZGluZy4NCj4gPj4+Pg0KPiA+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAtLS1ldGhl ckItLS0NCj4gPj4+PiAgICAgICBob3N0IC0tZXRoZXJBLS0gcnRyDQo+ID4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLWV0aGVyQi0tLQ0KPiA+Pj4+ICAgICAgIHwgICBob3N0L3J0ciAg ICAgfA0KPiA+Pj4+DQo+ID4+Pj4gVGhpbmsgb2YgYSBob3N0IHdpdGggYW4gZXRoZXJBIGNvbm5l Y3RpbmcgdG8gYSByb3V0ZXIgdGhhdCBhbHNvIGhhcw0KPiA+Pj4+IGV0aGVyQiwgZXRoZXJDLiBO b3cgd2UganVzdCBpbnRlZ3JhdGUgdGhpcyByb3V0ZXIgaW50byB0aGUgaG9zdCBhbmQgZXRoZXJ0 aGVybmV0QQ0KPiA+Pj4+IGJlY29tZXMgYW4gaW50ZXJuYWwgaW50ZXJmYWNlLCBidXQgdGhlIGFw cHMgY2FuIHN0aWxsIHVzZSB0aGlzIGludGVyZmFjZSwNCj4gPj4+PiBhbmQgc28gaXQgaXMgcGVy bWlzc2libGUgZm9yIGJvdGggc3Ryb25nIGFuZCB3ZWFrIGhvc3QgbW9kZWxzIHRvIHVzZSB0aGUg SVANCj4gPj4+PiBhZGRyZXNzIG9uIGV0aGVyQSwgd2hhdGV2ZXIgZXhlcm5hbCBldGhlcm5ldEIv ZXRoZXJuZXRDIHRoZSBwYWNrZXRzIGFyZQ0KPiA+Pj4+IHNlbnQvcmVjZWl2ZWQgdGhyb3VnaC4N Cj4gPj4+Pg0KPiA+Pj4+IFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBpbnRlcm5hbCBl dGhlcm5ldCBhbmQgbG9vcGJhY2sgaW4gdGhpcyBtb2RlbGxpbmcNCj4gPj4+PiBpcyB0aGF0IHdo ZW4geW91IHNlbmQgaW50byBhIGxvb3BiYWNrIGludGVyZmFjZSwgaXQgZG9lcyBub3QgbmVlZCB0 byBydW4gTkQgdG8NCj4gPj4+PiBmaW5kIHRoZSBsaW5rLWxvY2FsIGFkZHJlc3Mgb2YgdGhlIHJv dXRlciBpbnRlcmZhY2UgYW5kIGZvcndhcmQgdGhlIHBhY2tldCB0byBpdCwNCj4gPj4+PiBidXQg aW5zdGVhZCB0aGUgcGFja2V0IGlzIGltbWVkaWF0ZWx5IHByb2Nlc3NlZCBieSB0aGUgcm91dGVy IGZvcndhcmRpbmcgY29kZS4NCj4gPj4+DQo+ID4+PiBPa2F5LCBJIHRoaW5rIEkgbm93IHVuZGVy c3RhbmQgd2hhdCB5b3UgbWVhbnQuICBTdWNoIGEgbW9kZWwgc2VlbXMgdG8NCj4gPj4+IGJlIHF1 aXRlIGEgc3RyZXRjaCBjb252b2x1dGVkIG9yIGV2ZW4gYXJ0aWZpY2lhbCB0byBtZSwgYnV0IEkg d291bGRuJ3QNCj4gPj4+IG5lY2Vzc2FyaWx5IGRlbnkgcG9zc2libGUgZXhpc3RlbmNlIG9mIHN1 Y2ggaW1wbGVtZW50YXRpb25zLiAgQnV0IGluDQo+ID4+PiBhbnkgZXZlbnQgdGhhdCBzZWVtcyB0 byBtZSBxdWl0ZSBhIHN0cmV0Y2ggZnJvbSB0aGUgc2l0dWF0aW9uIEJyaWFuDQo+ID4+PiBvcmln aW5hbGx5IHJhaXNlZC4gIEFuZCwgZm9yIHRoZXNlIHJlYXNvbnMsIEkgcGVyc29uYWxseSB3b3Vs ZG4ndA0KPiA+Pj4gc3VwcG9ydCBzYXlpbmcgc29tZXRoaW5nIGluIHRoZSBhZGRyZXNzaW5nIGFy Y2hpdGVjdHVyZSB0aGF0IHJlcXVpcmVzDQo+ID4+PiBhIHNwZWNpZmljIG1vZGVsIG9mIGludGVn cmF0ZWQgaG9zdC1yb3V0ZXIgYXJjaGl0ZWN0dXJlLiAgTW9yZQ0KPiA+Pj4gc3BlY2lmaWNhbGx5 IEkgZGlzYWdyZWUgd2l0aCBhZGRpbmcgdG8gdGhlIGFkZHJhcmNoIGRvYzoNCj4gPj4+DQo+ID4+ PiAgIElmIG90aGVyIGFkZHJlc3NlcyBiZXNpZGUgImxvb3BiYWNrIGFkZHJlc3NlcyIgYXJlIGFz c2lnbmVkIHRvIHN1Y2ggYSBsaW5rLA0KPiA+Pj4gICB0aGVuIHRoZSBpbnRlcmZhY2UgbmVlZHMg dG8gYmUgY29uZmlndXJlZCB0byBmb3J3YXJkIG5vbi1zZWxmLWRlc3RpbmVkDQo+ID4+PiAgIHBh Y2tldHMgb3JpZ2luYXRlZCBmcm9tIHRoZSBsb29wYmFjayBpbnRlcmZhY2UgKHNlZSByZmM4MjAw LCBzZWN0aW9uIDIpLg0KPiA+Pj4NCj4gPj4+IElmIGl0IGFsc28gbm90ZXMgdGhhdCBpdCdzIGZv ciBhIGhvc3QgdGhhdCBhZG9wdHMgdGhlIHN0cm9uZyBob3N0DQo+ID4+PiBtb2RlbCBvciB0aGUg bm9kZSBhZG9wdGluZyB0aGUgaHlicmlkIGFyY2hpdGVjdHVyZSB5b3UgbWVudGlvbmVkDQo+ID4+ PiBhYm92ZSwgSSBtaWdodCBsaXZlIHdpdGggaXQsIGFsdGhvdWdoIEkgcGVyc29uYWxseSB0aGlu ayBpdCdzIHRvbyBtdWNoDQo+ID4+PiBmb3IgdGhlIGJhc2ljIGFyY2hpdGVjdHVyZSBkb2N1bWVu dC4NCj4gPj4NCj4gPj4gWWVzLiBJIHRoaW5rIHRoZSBwb2ludCB0aGF0IGlzIGxhY2tpbmcgaW4g dGhlIGFyY2hpdGVjdHVyZSBpcw0KPiA+PiB0aGF0IHVuaWNhc3QgYWRkcmVzc2VzIHRoYXQgYXJl IG5vdCBhc3NpZ25lZCB0byBhbiBvcGVyYXRpb25hbA0KPiA+PiBwaHlzaWNhbCBvciB0dW5uZWwg aW50ZXJmYWNlIG1heSBiZSBhc3NpZ25lZCB0byBhIHZpcnR1YWwNCj4gPj4gaW50ZXJmYWNlLCB3 aGljaCBtYXkgYmUgYSBsb29wYmFjayBpbnRlcmZhY2UuDQo+ID4+DQo+ID4+IEFsbCB0aGUgcmVz dCBpcyBpbmRlZWQgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50Lg0KPiA+Pg0KPiA+PiAgICAgQnJp YW4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0DQo+ID4+IGlwdjZAaWV0Zi5vcmcNCj4gPj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCg0K From nobody Mon Oct 23 16:53:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA4813AC0D for ; Mon, 23 Oct 2017 16:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F65M-5bV6I10 for ; Mon, 23 Oct 2017 16:52:57 -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 7374D13A6D5 for ; Mon, 23 Oct 2017 16:52:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRE80233; Mon, 23 Oct 2017 23:52:54 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 24 Oct 2017 00:52:53 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Mon, 23 Oct 2017 16:52:50 -0700 From: Lin Han To: "Manfredi, Albert E" , Mark Smith CC: 6man WG Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt] Thread-Index: AQHTSdJXqSaZrOZDMkmbu8uyH2nDS6LtjQWA//++ciCAA3OagIAAN7IAgAEKNMA= Date: Mon, 23 Oct 2017 23:52:49 +0000 Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD7721E@sjceml521-mbx.china.huawei.com> References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59EE80D6.007A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a9594e3c0fa60c315aeab1c5e2f11ae Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 23:52:58 -0000 W3NuaXBdDQpUaGF0J3MgYmVlbiBteSByZWFjdGlvbiBoZXJlIHRvby4gSSB0aGluaywgYXQgYSBt b3N0IGZ1bmRhbWVudGFsIGxldmVsLCBJUCBpcyBhIHRlY2huaXF1ZSB0aGF0IGFsbG93cyBmb3Ig cGxlbnR5IG9mICpjaGVhcCBiYW5kd2lkdGgqLCB3aGljaCBoYXMgbWFkZSBRb1MgZ3VhcmFudGVl cyBtb3N0bHkgdW5uZWNlc3NhcnkuIENoZWFwIGJhbmR3aWR0aCBhbGxvd3MsIGV2ZW4gYmVncyBm b3Igb3Zlci1wcm92aXNpb25pbmcgaW4gdGhlIG5ldHdvcmssIHdoaWNoIG1ha2VzIGNvbXBsaWNh dGVkIFFvUyBndWFyYW50ZWVzIHVubmVjZXNzYXJ5LiBBbmQgZnVydGhlcm1vcmUsIGFwcHMgdGhh dCBkbyByZXF1aXJlIGNlcnRhaW4gcXVhbGl0eSBsZXZlbHMgdGFrZSBpdCB1cG9uIHRoZW1zZWx2 ZXMgdG8gYWRqdXN0IHRvIHdoYXQncyBhdmFpbGFibGUsIHJhdGhlciB0aGFuIGdpdmluZyB0aGF0 IHJlc3BvbnNpYmlsaXR5IHRvIHRoZSBpbnRlcnZlbmluZyBuZXR3b3JrLiBJIHRoaW5rIHRoYXQg UlRQL1JUU1Agd2FzIHF1aXRlIHJldm9sdXRpb25hcnksIGluIHRoZSB0ZWxlY29tIHdvcmxkLg0K DQpPbiB0aGUgb3RoZXIgaGFuZCwgc2NoZW1lcyBsaWtlIEFUTSBhc3N1bWUgKmV4cGVuc2l2ZSBi YW5kd2lkdGgqLCBzbyB0aGV5IG1ha2UgYSBiaWcgZGVhbCBhYm91dCBkb2xpbmcgb3V0IGJhbmR3 aWR0aCB3aXRoIGZpbmUgZ3JhbnVsYXJpdHkuIE9yLCBtb3JlIHJlYWxpc3RpY2FsbHksIHRoZXkg b3B0aW1pc3RpY2FsbHkgY3JlYXRlZCB0aGUga25vYnMgZm9yIGRvaW5nIHNvLCB3aGljaCBwcm92 ZWQgd2F5IHRvbyBjb21wbGljYXRlZCwgaW4gdGhlIGZhY2Ugb2YgdGhlICJjaGVhcCBiYW5kd2lk dGgiIGNvbm5lY3Rpb25sZXNzIElQIGNvbXBldGl0aW9uIG9mIHRoZSBkYXkuIEJ1dCB0aGVyZSBo YXMgYmVlbiBhIHN1Y2Nlc3Npb24gb2YgZWZmb3J0cywgZnJvbSBlYXJseSBvbiBpbiBJUCwgdG8g YWRkIFFvUyBrbm9icy4NCltzbmlwXQ0KDQpIaSwgQmVydA0KDQpUaGlzIHNvbHV0aW9uIHRyaWVz IHRvIHVzZSBhIHNpbXBsZXN0IHdheSB0byBwcm92aWRlIGEgZGVjZW50IFFvUywgYW5kIGtlZXAg dGhlIElQIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGFuZCBiZW5lZml0cyBvZiBiZXN0IGVmZm9ydCBz ZXJ2aWNlLiBBcyBJIGVtcGhhc2l6ZSBpbiB0aGUgZG9jdW1lbnQsIGl0IGFpbWVkIHRvIGJlIGEg c3VwcGxlbWVudGFyeSBmb3IgdGhlIGN1cnJlbnQgYmVzdC1lZmZvcnQgYmFzZWQgdHJhbnNwb3J0 IHNlcnZpY2UsIGFuZCBvbmx5IHVzZWQgZm9yIHRoZSBzZXJ2aWNlIHdoaWNoIHJlYWxseSBuZWVk cyBpdC4NCg0KImNoZWFwIGJhbmR3aWR0aCIgc29sdXRpb24gY2FuIGNlcnRhaW5seSBzb2x2ZSBh IGxvdCBRb1MgcHJvYmxlbSwgYXMgd2UgZXhwZXJpZW5jZWQgaW4gbGFzdCBkZWNhZGVzLiBCdXQg Y2FuIGl0IHNvbHZlIGFsbCBwcm9ibGVtcyBpbiBhbGwgdXNlIGNhc2U/IE9idmlvdXNseSBub3Qu IEZvciBleGFtcGxlLCBvdXIgY3VycmVudCBhY2Nlc3Mgc3BlZWQgZG9lcyBub3QgbWVhbiBFMkUg YmFuZHdpZHRoLiBXaHkgd2UgZG9u4oCZdCBjb21wbGFpbj8gc2luY2UgbW9zdCBvZiBhcHBsaWNh dGlvbnMgY2FuIHRvbGVyYXRlIHRoZSBpbnN1ZmZpY2llbnQgYmFuZHdpZHRoLiBCdXQgc29tZSBh cHBsaWNhdGlvbiBoYXMgYWxyZWFkeSBzaG93IGEgbG90IGNoYWxsZW5nZSB0byBuZXR3b3JrLiBJ ZiB5b3Ugd2FudCBhIDhLIHZpZGVvIG9yIEFSL1ZSIHNlcnZpY2Ugd2l0aCBkZWNlbnQgcXVhbGl0 eSBub3csIG5vIFNQIGNhbiBwcm92aWRlIGl0IGluIGEgc2hvcnQgdGltZS4gDQpPbiB0aGUgb3Ro ZXIgaGFuZCwgImNoZWFwIGJhbmR3aWR0aCIgc29tZXRpbWUgaXMgbm90IGNoZWFwLCBpdCBhY3R1 YWxseSBwdXNoZXMgdGhlIFNQIHRvIHVwZ3JhZGUgbmV0d29yayBkZXZpY2VzIHRvIG9idGFpbiBt b3JlIHJvb20gZm9yIGJhbmR3aWR0aC4gSWYgdGhpcyBpcyBwcmFjdGljYWwsIGl0IHdpbGwgYmUg ZWFzaWVyIHRvIGFzayBTUCB0byBkZXNpZ24gYSBuZXR3b3JrIHdpdGggbm8gb3ZlcnN1YnNjcmlw dGlvbiBhdCB0aGUgYmVnaW5uaW5nLiBBbGwgY29tZSB0byB0aGUgY29zdCBvZiBTUC4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5mcmVkaSwgQWxiZXJ0IEUNClNlbnQ6IFN1bmRheSwg T2N0b2JlciAyMiwgMjAxNyA0OjA3IFBNDQpUbzogTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdt YWlsLmNvbT4NCkNjOiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUkU6IEhvcC1i eS1ob3AgW25vdCBkcmFmdC1oYW4tNm1hbi1pbi1iYW5kLXNpZ25hbGluZy1mb3ItdHJhbnNwb3J0 LXFvcy0wMC50eHRdDQoNCkZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21h aWwuY29tXSANCg0KPiBGcm9tOiBMaW4gSGFuIFttYWlsdG86TGluLkhhbkBodWF3ZWkuY29tXQ0K DQo+PiBbTEhdIFllYWgsIGV2ZXJ5dGhpbmcgaGFzIGNvc3QuIEJ1dCBpdCBpcyBzdGlsbCBkaWZm ZXJlbnQsIEFUTSBVQlIgaXMgDQo+PiBjb25uZWN0aW9uIG9yaWVudGVkLCBpdCBuZWVkcyBzZXR1 cCBhbmQgaW52b2x2ZXMgdGhlIGNvbnRyb2wgcHJvdG9jb2wgDQo+PiBzdWNoIGFzIFBOTkkuIElu IG91ciBjYXNlLCB0aGUgSVAgYXJjaGl0ZWN0dXJlIGlzIG5vdCB0b3VjaGVkIGF0IGFsbC4NCj4+ IElQIGJlc3QgZWZmb3J0IGlzIGFzIHNpbXBsZSBhcyBiZWZvcmUuDQo+DQo+IE5vdCBhdCBhbGwu DQo+DQo+IFlvdSdyZSBjcmVhdGluZyBzdGF0ZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gU3Rh dGUgY3JlYXRlZCBiYXNlZCBvbiANCj4gdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3PCoCBpcyB2dWxu ZXJhYmxlIHRvIHN0YXRlIGV4aGF1c3Rpb24gYXR0YWNrcy4NCg0KSSB0aGluayB0aGF0IGFsbCBM aW4gd2FzIHNheWluZyB3YXMsICJpZiB5b3UgdXNlIGJlc3QgZWZmb3J0LCB0aGVuIHlvdSBoYXZl buKAmXQgc2FjcmlmaWNlZCBzY2FsYWJpbGl0eS4iIFdoaWNoIGlzIHRydWUgZW5vdWdoLCBJIHRo aW5rLiBXaGVyZWFzLCB3aXRoIEFUTSwgeW91IGFyZSBzdGlsbCBoYXZpbmcgdG8gc2V0IHVwIHRo YXQgVkMgYWhlYWQgb2YgdGltZSwgZXZlbiBpZiwgd2l0aCBVQlIgc2VydmljZSwgeW91IGFyZW4n dCBzcGVjaWZ5aW5nIGFueSBRb1MgcmVxdWlyZW1lbnRzIGFsb25nIHRoYXQgcGF0aC4NCg0KPiBF dmVuIGluIGNsb3NlZCBkb21haW5zIHRoaXMgY2FuIGJlIGFuIGlzc3VlLCBiZWNhdXNlICJjbG9z ZWQiIGRvbWFpbnMgDQo+IGF0dGFjaGVkIHRvIHRoZSBJbnRlcm5ldCBhcmVuJ3QgZ3VhcmF0ZWVk IHRvIHN0YXkgY2xvc2VkLg0KDQpZZXMsIGFsdGhvdWdoIEkgdGhpbmsgTGluIHdhcyBzYXlpbmcs IGlmIHlvdSBlbmNvdW50ZXIgcm91dGVycyB0aGF0IGRvbuKAmXQga25vdyBkaWRkbHkgYWJvdXQg aGlzIGluLWJhbmQgc2lnbmFsaW5nLCBBTkQgdGhlc2Ugcm91dGVycyBhcmVuJ3QgcGFydGljdWxh cmx5IGNvbmdlc3RlZCwgdGhlbiBhbGwgc2hvdWxkIHN0aWxsIHdvcmsgZmluZS4gVGhpcyB0cmFm ZmljIHdvdWxkIGhvcGVmdWxseSBzYWlsIHRocm91Z2ggdGhlc2UgbGlnaHRseSBsb2FkZWQgaW50 ZXItY2FycmllciByb3V0ZXJzLCBhbmQgdGhlbiB0aGUgUW9TIGtub2JzIHdvdWxkIGNvbWUgaW50 byBwbGF5IGluIGhpcyBvd24gSVNQIG5ldHdvcmsuDQoNCj4gUkZDNzkxIGFuZCBSRkM4MjAwIGZv cndhcmRpbmcgaXMgc3RhdGVsZXNzLg0KPg0KPiBJJ2QgZXZlbiBzYXkgdHJhZmZpYyBjcmVhdGVk IHN0YXRlIGlzIHdvcnNlIHRoYW4gY29ubmVjdGlvbiBvcmllbnRlZCANCj4gc3RhdGUgc3VjaCBh cyBzd2l0Y2hlZCB2aXJ0dWFsIGNpcmN1aXRzIGluIEFUTS4gSW4gdGhhdCBtb2RlbCwgaG9zdHMg DQo+IGFyZSByZXF1ZXN0aW5nIHBlcm1pc3Npb24gdG8gc2VuZCB0cmFmZmljIG9uIHRoZSBuZXR3 b3JrIGJlZm9yZSANCj4gdGhleSdyZSBhYmxlIHRvIC0gaWYgdGhlIG5ldHdvcmsgY2FuJ3Qgc2V0 IHVwIGEgY29ubmVjdGlvbiBmb3IgYSBob3N0LCANCj4gdGhlIGhvc3QgY2Fubm90IGNvbnRyaWJ1 dGUgdHJhZmZpYyBsb2FkIHRvIHRoZSBuZXR3b3JrLg0KDQpUaGF0J3MgYmVlbiBteSByZWFjdGlv biBoZXJlIHRvby4gSSB0aGluaywgYXQgYSBtb3N0IGZ1bmRhbWVudGFsIGxldmVsLCBJUCBpcyBh IHRlY2huaXF1ZSB0aGF0IGFsbG93cyBmb3IgcGxlbnR5IG9mICpjaGVhcCBiYW5kd2lkdGgqLCB3 aGljaCBoYXMgbWFkZSBRb1MgZ3VhcmFudGVlcyBtb3N0bHkgdW5uZWNlc3NhcnkuIENoZWFwIGJh bmR3aWR0aCBhbGxvd3MsIGV2ZW4gYmVncyBmb3Igb3Zlci1wcm92aXNpb25pbmcgaW4gdGhlIG5l dHdvcmssIHdoaWNoIG1ha2VzIGNvbXBsaWNhdGVkIFFvUyBndWFyYW50ZWVzIHVubmVjZXNzYXJ5 LiBBbmQgZnVydGhlcm1vcmUsIGFwcHMgdGhhdCBkbyByZXF1aXJlIGNlcnRhaW4gcXVhbGl0eSBs ZXZlbHMgdGFrZSBpdCB1cG9uIHRoZW1zZWx2ZXMgdG8gYWRqdXN0IHRvIHdoYXQncyBhdmFpbGFi bGUsIHJhdGhlciB0aGFuIGdpdmluZyB0aGF0IHJlc3BvbnNpYmlsaXR5IHRvIHRoZSBpbnRlcnZl bmluZyBuZXR3b3JrLiBJIHRoaW5rIHRoYXQgUlRQL1JUU1Agd2FzIHF1aXRlIHJldm9sdXRpb25h cnksIGluIHRoZSB0ZWxlY29tIHdvcmxkLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgc2NoZW1lcyBs aWtlIEFUTSBhc3N1bWUgKmV4cGVuc2l2ZSBiYW5kd2lkdGgqLCBzbyB0aGV5IG1ha2UgYSBiaWcg ZGVhbCBhYm91dCBkb2xpbmcgb3V0IGJhbmR3aWR0aCB3aXRoIGZpbmUgZ3JhbnVsYXJpdHkuIE9y LCBtb3JlIHJlYWxpc3RpY2FsbHksIHRoZXkgb3B0aW1pc3RpY2FsbHkgY3JlYXRlZCB0aGUga25v YnMgZm9yIGRvaW5nIHNvLCB3aGljaCBwcm92ZWQgd2F5IHRvbyBjb21wbGljYXRlZCwgaW4gdGhl IGZhY2Ugb2YgdGhlICJjaGVhcCBiYW5kd2lkdGgiIGNvbm5lY3Rpb25sZXNzIElQIGNvbXBldGl0 aW9uIG9mIHRoZSBkYXkuIEJ1dCB0aGVyZSBoYXMgYmVlbiBhIHN1Y2Nlc3Npb24gb2YgZWZmb3J0 cywgZnJvbSBlYXJseSBvbiBpbiBJUCwgdG8gYWRkIFFvUyBrbm9icy4NCg0KQmVydA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYu b3JnDQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Tue Oct 24 11:29:03 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 874731395F0; Tue, 24 Oct 2017 11:29:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org Subject: Warren Kumari's No Objection on draft-ietf-6man-maxra-03: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150886974150.25191.10273844392807308285.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 11:29:01 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 18:29:01 -0000 Warren Kumari has entered the following ballot position for draft-ietf-6man-maxra-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like what the document does, but it could really really do with a good editing pass; I've sent some nits / comments to Suresh off-list. Some bits I was unable to parse, but I trust Suresh to fix them. I'm a bit surprised it doesn't mention RFC7772 - it feels very related to me, but I may just be wrong! From nobody Tue Oct 24 16:03:13 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BC81383D0; Tue, 24 Oct 2017 16:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org Subject: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> Date: Tue, 24 Oct 2017 16:03:06 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 23:03:07 -0000 Adam Roach has entered the following ballot position for draft-ietf-6man-maxra-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm concerned that this normative statement is ambiguous (2nd paragraph of section 4), and that the ambiguity around allowed values may lead to interop issues: AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535. >From the text in section 3, I infer that MaxRtrAdvInterval is *not* an allowed value. >From the "no greater than 65535" language, I infer that 65535 *is* an allowed value. Please ensure that your normative statement here is very clear about whether "between" is intended to include its high and low limits as acceptable values. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 contains: As explained in Section 3, the relationship between MaxRtrAdvInterval and AdvDefaultLifetime must be chosen to take into account the probability of packet loss. The use of a non-normative "must" here indicates that you probably want to update your RFC2119 boilerplate to be RFC8174 boilerplate. From nobody Thu Oct 26 15:21:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE57113F605; Thu, 26 Oct 2017 15:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH1hMRN87fGW; Thu, 26 Oct 2017 15:21:56 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF56C13F61D; Thu, 26 Oct 2017 15:21:55 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id g90so4551103wrd.6; Thu, 26 Oct 2017 15:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=g3rKu0IDX0VcGh4EWQjOqienOrHAgbbYw5Ahhi5BcpY=; b=spzNNoZ8/kq1pgKxd1RsKzZLdvKPAFZHcnEsqHzhSS4gykdQqQ2i3jnYnWvMV803rC VXcISEunuHBpg8OZBYW4egML/q+hJ3RoqB5DsSmx5sA7b8PBFJIu9SsySlaFdg//xv3I ms3s5iVADPqukolRTWCLMik1omXI0FoyaKS+vsHpYo96e/XFieAMz7WXGHbGs8lDbD6a bdUnTaxh5uqLJDsFKoH26jRwj/83f57ex3UQaviuRDNFb9LyqgWR9ewVaMOw/nAFHuq0 9JewYfHG/HSHcLZVvXVuXC+3IvctZ+9E1LuhRaKKMvREwhSBqfKPPgSms+XAmwZ5i5tQ A7cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g3rKu0IDX0VcGh4EWQjOqienOrHAgbbYw5Ahhi5BcpY=; b=NoGdx8XFt08Gpyo2oMhuFNogAnl4jGp6nHOvYeKTMRafuS8HQGkXmllqHoABj1q871 hxA8KGkeX4CcX3XXFte37OXI0XaJN2W+hktY6ljKcxFLBIolxfMUnQKit9SD9DMaXyIE ArhtjdsK+vgrm3SvxybBqIAQBV0c7HA9YwmS79KVUk33fCGwV8heuTYXsj6S8KR2moT8 9bpPoOWlJGp0MnI2hwdunaqZMn6F2H9vonK1dDSNN1bM6s7Im2ukLfjqfCIcBP+G1lVM wBt5YxlyXw4nTR+SpSqQhv+RChc7deTQTrtYqCqQ5+++eBLARGX9ceTQCi9wyci0+mqZ QAQQ== X-Gm-Message-State: AMCzsaW2w2TBXFt7KsPtYpew3de0u7Fj2fM2r1siII3liiUjp3kDnZjq pevrwc2xx6pJUb4QvQ25+xQ= X-Google-Smtp-Source: ABhQp+QsjuljWJC7TT/ns3p0uIC4lw13iY37Bmf5veta7l3g3Ro3L8C8PqzxUuLkUQbELZFyFDwZrA== X-Received: by 10.223.186.20 with SMTP id o20mr7316838wrg.3.1509056514226; Thu, 26 Oct 2017 15:21:54 -0700 (PDT) Received: from [10.123.123.238] ([167.98.65.158]) by smtp.gmail.com with ESMTPSA id l130sm387911wmd.47.2017.10.26.15.21.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 15:21:53 -0700 (PDT) From: Bob Hinden Message-Id: <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F2E12452-4868-4009-847E-AA413B72BB12"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) Date: Thu, 26 Oct 2017 23:21:47 +0100 In-Reply-To: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> Cc: Bob Hinden , IESG , draft-ietf-6man-maxra@ietf.org, =?utf-8?Q?Ole_Tr=C3=B8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List To: Adam Roach References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 22:21:58 -0000 --Apple-Mail=_F2E12452-4868-4009-847E-AA413B72BB12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adam, With my Doc Shepard hat on. > On Oct 25, 2017, at 12:03 AM, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-6man-maxra-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm concerned that this normative statement is ambiguous (2nd = paragraph of > section 4), and that the ambiguity around allowed values may lead to = interop > issues: >=20 > AdvDefaultLifetime > MUST either be zero (the router is not to be used as a default > router) or be a value between MaxRtrAdvInterval and 65535. >=20 >> =46rom the text in section 3, I infer that MaxRtrAdvInterval is *not* = an allowed > value. >=20 >> =46rom the "no greater than 65535" language, I infer that 65535 *is* = an allowed > value. >=20 > Please ensure that your normative statement here is very clear about = whether > "between" is intended to include its high and low limits as acceptable = values. >=20 This doc is updating the text in RFC4681 which uses the same language: AdvDefaultLifetime MUST be either zero or between MaxRtrAdvInterval and 9000 seconds. I read this as saying it should be more than MaxRtrAdvInterval and less = than 9000. Hence it is =E2=80=9Cbetween=E2=80=9D the two values. I am not aware of interoperability problems caused by the RC4681 = =E2=80=9Cbetween=E2=80=9D language. Can you point to a problem? This = doc is changing the maximum allowed values to 65535 seconds to avoid the = effects of sending too few RAs on particular types of links. I think the text is clear. Please describe why you think it could cause = an interoperability problem. Thanks, Bob >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 4 contains: >=20 > As explained in Section 3, the relationship between = MaxRtrAdvInterval > and AdvDefaultLifetime must be chosen to take into account the > probability of packet loss. >=20 > The use of a non-normative "must" here indicates that you probably = want to > update your RFC2119 boilerplate to be RFC8174 boilerplate. >=20 >=20 --Apple-Mail=_F2E12452-4868-4009-847E-AA413B72BB12 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZ8l/7AAoJEK7rdBF357uoT90H/0vWUQtGHNvwHDHyFdH0ZzDO qdE1iXKFOgNxLlH80itrPd8rt/VkZWlY27VsAp+dFu5NkBOgqR2lVppenmd2xZwv 7kumWRYS8HyzqFUs/T/fA+i0oNccGH/jkDUn5vhFxrbJ2e44af7areJPkddxDvEK GjrsDYS0ldhL014rA+ToxBYtEhTTAxfOnKc0pEA2LJSmoWnDXo9AC307vpcqry3r N2a9yU6Ow5KcltrFHa5Uq3o58EQwuMf/BL3GvbUK3uL7fEMaTX5mVrRxj2x1wsQN JuLSkvRVnjv7pILxUSOlnglsM/vgwOXsiM1/LxJhStlk+3vz8dGbIwYB4+QQaJ4= =dVvz -----END PGP SIGNATURE----- --Apple-Mail=_F2E12452-4868-4009-847E-AA413B72BB12-- From nobody Thu Oct 26 17:30:34 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8643113F417; Thu, 26 Oct 2017 17:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSTH-v8IhjqX; Thu, 26 Oct 2017 17:30:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2952313B1A9; Thu, 26 Oct 2017 17:30:24 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9R0UKdx028262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 Oct 2017 19:30:21 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) To: Bob Hinden Cc: IESG , draft-ietf-6man-maxra@ietf.org, =?UTF-8?Q?Ole_Tr=c3=b8an?= , 6man Chairs <6man-chairs@ietf.org>, IPv6 List References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> From: Adam Roach Message-ID: Date: Thu, 26 Oct 2017 19:30:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 00:30:25 -0000 On 10/26/17 17:21, Bob Hinden wrote: > I am not aware of interoperability problems caused by the RC4681 > “between” language. Can you point to a problem? Rather than running the risk of getting caught up on the minutiae of any scenario I might describe, I'm going to narrow my DISCUSS to a much simpler assertion: Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535." Normative statements cannot be ambiguous. Please clarify whether this is an inclusive "between" or an exclusive "between." /a From nobody Thu Oct 26 21:43:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83C137C4A; Thu, 26 Oct 2017 21:43:44 -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 gq4_E-X876Y7; Thu, 26 Oct 2017 21:43:43 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8F3139438; Thu, 26 Oct 2017 21:43:43 -0700 (PDT) Received: from [172.20.4.49] (207-47-24-11.static-ip.telepacific.net [207.47.24.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id B520E2D50FE; Fri, 27 Oct 2017 04:43:42 +0000 (UTC) Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) From: Ole Troan X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Thu, 26 Oct 2017 21:43:42 -0700 Cc: Bob Hinden , IESG , draft-ietf-6man-maxra@ietf.org, 6man Chairs <6man-chairs@ietf.org>, IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> To: Adam Roach Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 04:43:45 -0000 Adam, It might be worth noting that if it is inclusive or exclusive has absolutely= zero consequence for the protocol. Ole > On 26 Oct 2017, at 17:30, Adam Roach wrote: >=20 >> On 10/26/17 17:21, Bob Hinden wrote: >> I am not aware of interoperability problems caused by the RC4681 =81gbetw= een=81h language. Can you point to a problem? >=20 > Rather than running the risk of getting caught up on the minutiae of any s= cenario I might describe, I'm going to narrow my DISCUSS to a much simpler a= ssertion: >=20 > Lacking a formal definition of "between," the following normative statemen= t is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not t= o be used as a default router) or be a value between MaxRtrAdvInterval and 6= 5535." >=20 > Normative statements cannot be ambiguous. >=20 > Please clarify whether this is an inclusive "between" or an exclusive "bet= ween." >=20 > /a From nobody Fri Oct 27 09:41:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5E13F3FF; Fri, 27 Oct 2017 09:41:08 -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 N1ZyX66295hr; Fri, 27 Oct 2017 09:41:07 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 1897513F3F3; Fri, 27 Oct 2017 09:41:07 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id m189so9044738qke.4; Fri, 27 Oct 2017 09:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AHw8rZpmDuALZpeLnSNqvfvYgmHzBug4655el5f+a0k=; b=flhrrTskxpReP6Lya+XAQDgclllVwu2n1EKh1RcwQvKGOCPtdMac9IHN1KStXxpVvq 4JhrCWUCn5wAOTJkS6IOlwvMlGm2HCvm/4ZEJvKY/BUhoNdjFcch2BmhGka0EYKfvGNg s5SrpohdC286rEWTi5o9hdQhltwhrJkIuTQKlsPnAt2hDFRmoftQiUBWfExQFEqTl8ro G4UrkU1FPflFKaqPrFUxJn+L9uqnGHSkZxM7p/XUGGozJ0En11/oj3I1eP6BfxNGsTXL nA18JC9KO4zd7eQH99ne996qgV1Sh+At+TQ8TnTqTBVaLJ+perkfdRhf1KevDH5HgLim ZrmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AHw8rZpmDuALZpeLnSNqvfvYgmHzBug4655el5f+a0k=; b=dBd0UQAN23L/+bV9HN7lYzgyIsF8nGKlakzk45pO7NKnA9kOXUqCrE0OkIqz4VWM2+ FruH/mcS8HoZS6TwH/CKehrDUYR+38msFyFBeu7V5djk6OJ29lSiboSs6bYCM1fhjpY+ sgogtycUmQWjzmaMDPtQ86gLj7v88hA3TYp818snnpEfcc5gjMQuMq7o6vk48rxV7vXE 9DcLH4QadvvT6GkPbqGqcRLW8NiRSqEmNeNd97TojzImmjYZg/dRIPXZiL6iwXwb9fhR 40TJ/ixFSBDCt1Bbzew+1RQMhpBi3oU2SFpkjHVv+M68DyVZDBKTrDPzUOqk/s47gIlQ Jd0A== X-Gm-Message-State: AMCzsaVWTfdALl2K+LNJKYqPa13MWLi/pvrK7F2//U5zQg6Apd9ui0z7 3BzXwKGdu0Ud8qvVdetpU5HdlnhwjR/ueFoedIk= X-Google-Smtp-Source: ABhQp+TZQybAzjbZsW3tCGSBDc+OyB3pScbDhLZnNfRrDAv1AstSnGfZCILYgcsbbn6sSDzw8v9LKRNPEUyX/iyxAaI= X-Received: by 10.55.160.135 with SMTP id j129mr1606648qke.274.1509122466032; Fri, 27 Oct 2017 09:41:06 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.137 with HTTP; Fri, 27 Oct 2017 09:41:05 -0700 (PDT) In-Reply-To: <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 27 Oct 2017 09:41:05 -0700 X-Google-Sender-Auth: hOYWk9qQc42w4lNO6-L4HFSVwz4 Message-ID: Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) To: Ole Troan Cc: Adam Roach , IPv6 List , 6man Chairs <6man-chairs@ietf.org>, Bob Hinden , IESG , draft-ietf-6man-maxra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:41:09 -0000 At Thu, 26 Oct 2017 21:43:42 -0700, Ole Troan wrote: > It might be worth noting that if it is inclusive or exclusive has > absolutely zero consequence for the protocol. FWFIW, an implementation that I know of adopts the "inclusive" version of "between" (it doesn't support 6man-maxra so it still only conforms to RFC4861): MAYHAVE(val, "rltime", rai->rai_maxinterval * 3); if ((uint16_t)val && ((uint16_t)val < rai->rai_maxinterval || (uint16_t)val > MAXROUTERLIFETIME)) { syslog(LOG_ERR, "<%s> router lifetime (%" PRIu32 ") on %s is invalid " "(must be 0 or between %d and %d)", __func__, val, ifi->ifi_ifname, rai->rai_maxinterval, MAXROUTERLIFETIME); goto getconfig_free_rai; } (https://github.com/freebsd/freebsd/blob/master/usr.sbin/rtadvd/config.c) But, more important, I agree with Bob and Ole in that "inclusive" vs "exclusive" shouldn't cause an interoperability problem since hosts are not supposed to reject an RA for a particular value of router lifetime: Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. [...] If anything, if we now "clarify" it to mean "exclusive", at least one implementation will now become technically non-compliant. So, while my primary suggestion is not to do anything about it, if we really need to say something, I'd suggest clarifying "whether this 'between' is inclusive or exclusive does not matter in terms interoperability and is left to implementations". -- JINMEI, Tatuya From nobody Fri Oct 27 10:03:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF5138F21; Fri, 27 Oct 2017 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGUkT1nVHOEt; Fri, 27 Oct 2017 10:03:31 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 3A02A138A38; Fri, 27 Oct 2017 10:03:31 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id k3so6281053ywk.8; Fri, 27 Oct 2017 10:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ra+kd9SofdQjGv0uIQnsyccTP2RjjaBmqVKG/LYgVj8=; b=ON8t9uvkPagwmi2etzky6p/o+BlaABctqWltA5BxR2xG++r43r6ksZ8jnI2TTXtvoO 1WSIQG+jka4wxST+fIcH9dvkQ+UxD1RFCnJle2A56bdVJt+RuzPtUYWIcCc05tWLOSYN XHbtwrzAuoVKhXXRq2bczyXt2md/vs4s8r7gkJC7s13Pzh+Y0F0Omtrff8/Nx+M7o39o iNK++MxnL4IqvB+uvJ4ZF1wjzyv0u5A2MplgpQWktuFg6844NhD1gPFqlUqNpqnM0k6E aIVksIGtp/2Po8BXmiwbdnPasYMs9XxJe9Wsa+LIguSpAM/sk2bDROjhv4463aH3oAUR hbFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ra+kd9SofdQjGv0uIQnsyccTP2RjjaBmqVKG/LYgVj8=; b=mfAGQsOniqTHjRd25jayhdlTXJBEWhvJv8xm/ZNhMOX8V7V+fFI/13gh1UFVdNWH/h C2WjSHpH//x5+a3ixJBSK4WUV4OJxza6w8nhr1HhzM6tMvFuj7BAdjZOWy5G+G/6nKnp fgbmNbfdkt0vM4B9YQMsh2fBrXGKzif9NXQvV4i7ZbtTVpqtwIBuGg/1a+H9tFQMpc7i DgoffFpJGlXANx58WfYltmzHp7opQvM5OUvJjBDYW1gpiy88aeoIXUPJHpstikWbQtwE 2s5ScCvqxE3sYXSFXrJpXTSNA3ENUn2HAArfHRnfexfcj/3Mrzj4Wnva9NiE/Vl0GPK5 3WWA== X-Gm-Message-State: AMCzsaVCUI7vCgtUfWLyL/bB7jGVaCj/fa2snS3odpGAsIIco8mKVTNL ftwEwnrNO9knweV/1N+aJ4ROVTpKRDgbRx56fg4= X-Google-Smtp-Source: ABhQp+TJkLo0fh9r3/ODA75zQb65trZaFIcm5BW3DHQJaOQ+YFtYoWvI0qflbTgvETNiJ20aov/lpQWawhv/Ir7M8mc= X-Received: by 10.37.252.28 with SMTP id v28mr812939ybd.518.1509123810136; Fri, 27 Oct 2017 10:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.87.131 with HTTP; Fri, 27 Oct 2017 10:03:29 -0700 (PDT) In-Reply-To: References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> From: Spencer Dawkins at IETF Date: Fri, 27 Oct 2017 12:03:29 -0500 Message-ID: Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Ole Troan , IPv6 List , Bob Hinden , draft-ietf-6man-maxra@ietf.org, IESG , Adam Roach , 6man Chairs <6man-chairs@ietf.org> Content-Type: multipart/alternative; boundary="f403045d98eaa01872055c8a4442" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:03:33 -0000 --f403045d98eaa01872055c8a4442 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This isn't my area of expertise, my actual area, or my ballot thread, but ... On Fri, Oct 27, 2017 at 11:41 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Thu, 26 Oct 2017 21:43:42 -0700, > Ole Troan wrote: > > > It might be worth noting that if it is inclusive or exclusive has > > absolutely zero consequence for the protocol. > > FWFIW, an implementation that I know of adopts the "inclusive" version > of "between" (it doesn't support 6man-maxra so it still only conforms > to RFC4861): > > MAYHAVE(val, "rltime", rai->rai_maxinterval * 3); > if ((uint16_t)val && ((uint16_t)val < rai->rai_maxinterval || > (uint16_t)val > MAXROUTERLIFETIME)) { > syslog(LOG_ERR, > "<%s> router lifetime (%" PRIu32 ") on %s is invalid " > "(must be 0 or between %d and %d)", > __func__, val, ifi->ifi_ifname, rai->rai_maxinterval, > MAXROUTERLIFETIME); > goto getconfig_free_rai; > } > (https://github.com/freebsd/freebsd/blob/master/usr.sbin/rtadvd/config.c) > > But, more important, I agree with Bob and Ole in that "inclusive" vs > "exclusive" shouldn't cause an interoperability problem since hosts > are not supposed to reject an RA for a particular value of router > lifetime: > > Router Lifetime > 16-bit unsigned integer. The lifetime associated > with the default router in units of seconds. The > field can contain values up to 65535 and receivers > should handle any value, while the sending rules in > Section 6 limit the lifetime to 9000 seconds. [...] > > If anything, if we now "clarify" it to mean "exclusive", at least one > implementation will now become technically non-compliant. So, while > my primary suggestion is not to do anything about it, if we really > need to say something, I'd suggest clarifying "whether this 'between' > is inclusive or exclusive does not matter in terms interoperability > and is left to implementations". > If the precise meaning of the boundaries set by a MUST requirement doesn't actually matter, I'm not understanding why this is a MUST ... Adam can speak for himself, but that's what *I* would be confused about. Spencer, who might or might not be Asking For A Friend > -- > JINMEI, Tatuya > > --f403045d98eaa01872055c8a4442 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This isn't my area of expertise, my actual area, or my= ballot thread, but ...=C2=A0

On Fri, Oct 27, 2017 at 11:41 AM, =E7=A5=9E=E6=98=8E=E9=81=94= =E5=93=89 <jinmei@wide.ad.jp> wrote:
At Thu, 26 Oct 2017 21:43:42 -0700,
Ole Troan <otro= an@employees.org> wrote:

> It might be worth noting that if it is inclusive or exclusive has
> absolutely zero consequence for the protocol.

FWFIW, an implementation that I know of adopts the "inclusive&q= uot; version
of "between" (it doesn't support 6man-maxra so it still only = conforms
to RFC4861):

=C2=A0 =C2=A0 MAYHAVE(val, "rltime", rai->rai_maxinterval * 3)= ;
=C2=A0 =C2=A0 if ((uint16_t)val && ((uint16_t)val < rai->rai_= maxinterval ||
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (uint16_t)val > MAXROUTERLIFETIME)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 syslog(LOG_ERR,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "<%s> router lifetime = (%" PRIu32 ") on %s is invalid "
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "(must be 0 or between %d an= d %d)",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 __func__, val, ifi->ifi_ifname= , rai->rai_maxinterval,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MAXROUTERLIFETIME);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 goto getconfig_free_rai;
=C2=A0 =C2=A0 }
(https://github.com/freebsd/<= wbr>freebsd/blob/master/usr.sbin/rtadvd/config.c)

But, more important, I agree with Bob and Ole in that "inclusive"= vs
"exclusive" shouldn't cause an interoperability problem since= hosts
are not supposed to reject an RA for a particular value of router
lifetime:

=C2=A0 =C2=A0 =C2=A0 Router Lifetime
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A016-bit unsigned integer.=C2=A0 The lifetime associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0with the default router in units of seconds.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0field can contain values up to 65535 and receivers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0should handle any value, while the sending rules in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Section 6 limit the lifetime to 9000 seconds.=C2=A0 [...]

If anything, if we now "clarify" it to mean "exclusive"= , at least one
implementation will now become technically non-compliant.=C2=A0 So, while my primary suggestion is not to do anything about it, if we really
need to say something, I'd suggest clarifying "whether this 'b= etween'
is inclusive or exclusive does not matter in terms interoperability
and is left to implementations".

I= f the precise meaning of the boundaries set by a MUST requirement doesn'= ;t actually matter, I'm not understanding why this is a MUST ...=C2=A0 = Adam can speak for himself, but that's what *I* would be confused about= .

Spencer, who might or might not be Asking For A = Friend
=C2=A0
--
JINMEI, Tatuya


--f403045d98eaa01872055c8a4442-- From nobody Fri Oct 27 10:33:50 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7698813F5A2; Fri, 27 Oct 2017 10:33: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 DtVkOTTkB4QY; Fri, 27 Oct 2017 10:33:47 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 421C113915C; Fri, 27 Oct 2017 10:33:47 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id q83so9246972qke.6; Fri, 27 Oct 2017 10:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sMDjKdq4d+1pnt0slB5wQJfJHKrxzH8Cxt9TdI79B2o=; b=Em3DPwqtNYnbu7UFtr+kVGqYKrZKzJIIW3U5Cf6JgegPj/iY3zZvWXVTbt/1In0BKa HlNlLPh7ZD1MWmkApBEM4j78WJ3HZ4H3/ClQANMswSzxVu5U1rCntNBJTqZRJ+v3cJoC vuasDl+DQJ3nZhLksF5qnIBavprKdOJhx9mB2CTw4xwKiwJnAYXMoExkHnFB9Uo7FoOi yECa7jkbanbBUMAzqVYFBTUJf28g3q5PPZs/SblAr2Ocwb8f8e/cUzWx/+msV6PjvzLk hZHBY5Be3woBy16yzBBSuxao4iptoLgG+F7ROHir4CDx+chCUpd4/yYLDyTsJPZdCsdY qG7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sMDjKdq4d+1pnt0slB5wQJfJHKrxzH8Cxt9TdI79B2o=; b=V5gwplx8HQA1U1kXE7lFqQDN40aNUZrkvV7fo6oI2YJjhctwTvyYtDod94HW5zIZug YI3zlGbmszNB/R7GzF7VcAwHePiYr9e0d6sdXyxB6710zi4Fr195kQ0yUQjhbYvnn8eB a/dmMBG916RgI1j4srlaQD80JB2zqJ69m3xo9jWPGNtgrwRDxBDDuN6oGmAZyQoYyyqS SRydj82jpujWkZukk2Bxdojpw6xRafzQPDwhmGs7dLa3PFRZLq9/ePwM1vM/jWDf+NZ5 z5VaZVIZv3KP+6ihhRZDH4rP5IBcFAtVnJ0w4Op77LirRXdevCP7zLKgaAv7k9tD4abJ hdPQ== X-Gm-Message-State: AMCzsaUiN+s8Jqx+56RHV17QIOl98zIpCEQreImM3f0r4yFGr2u01MZa EhZUaAG1Fqibnm4UjgfE8bBogU4nBnGHNnqK43PbcNhW X-Google-Smtp-Source: ABhQp+Sf66CMqpZrY3FcYC087V0d3xntoX1y2XCy/QcQWfBgBTAqn7CgiUGz9PdBJgjyf9JAG+pZsCh026hdyoDfjmE= X-Received: by 10.55.115.130 with SMTP id o124mr1908844qkc.83.1509125626269; Fri, 27 Oct 2017 10:33:46 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.137 with HTTP; Fri, 27 Oct 2017 10:33:45 -0700 (PDT) In-Reply-To: References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 27 Oct 2017 10:33:45 -0700 X-Google-Sender-Auth: LzJR8wz-Rn3L46im-LihNu1dP4M Message-ID: Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) To: Spencer Dawkins at IETF Cc: Adam Roach , Bob Hinden , draft-ietf-6man-maxra@ietf.org, IESG , IPv6 List , 6man Chairs <6man-chairs@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 17:33:48 -0000 At Fri, 27 Oct 2017 12:03:29 -0500, Spencer Dawkins at IETF wrote: > > If anything, if we now "clarify" it to mean "exclusive", at least one > > implementation will now become technically non-compliant. So, while > > my primary suggestion is not to do anything about it, if we really > > need to say something, I'd suggest clarifying "whether this 'between' > > is inclusive or exclusive does not matter in terms interoperability > > and is left to implementations". > > If the precise meaning of the boundaries set by a MUST requirement doesn't > actually matter, I'm not understanding why this is a MUST ... Adam can > speak for himself, but that's what *I* would be confused about. That's not my call either, and it's totally possible that an RFC2119 MUST was used too casually, but I guess the spirit of the MUST in this case is to specify a sensible *range* with some stronger requirement level so a deviant implementor or operator can't cause an extreme effect. But it's not important whether the exact boundary values are included. With this interpretation, this should read AdvDefaultLifetime MUST be one of the following: [lower, upper] (lower, upper) [lower, upper) (lower, upper] What 'lower' and 'upper' are is important (hence the MUST), but which one of the above four is implemented isn't. That makes sense to me. -- JINMEI, Tatuya From nobody Fri Oct 27 11:50:39 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5014C13F423; Fri, 27 Oct 2017 11:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_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=kaloom.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 uJtmJZsZfRmb; Fri, 27 Oct 2017 11:50:33 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0135.outbound.protection.outlook.com [104.47.34.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB91A13F41B; Fri, 27 Oct 2017 11:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R1U7lXcUc6V5IWM0xBo9exFjgOLwH0cCsli2UxtvcD0=; b=yOovY+X83XxrOMrJt4esRhPxx57kfrbhX6RxQfb8WEIXIgjPipNQqxgIOR1PUoUjHEvYgS4trWk+tyEKBo2WNi/SBjt6eKZtYh7zBFMe6ya43taSbgaFTNqxws+YOZvTvfEQ0yd+5qJUPVmmeMbJrXEYgFZse6Y/hZpA8NURvPQ= Received: from YQBPR0101MB0724.CANPRD01.PROD.OUTLOOK.COM (52.132.65.17) by YQBPR0101MB0724.CANPRD01.PROD.OUTLOOK.COM (52.132.65.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 27 Oct 2017 18:50:31 +0000 Received: from YQBPR0101MB0724.CANPRD01.PROD.OUTLOOK.COM ([fe80::406e:17d2:bb6b:345]) by YQBPR0101MB0724.CANPRD01.PROD.OUTLOOK.COM ([fe80::406e:17d2:bb6b:345%13]) with mapi id 15.20.0178.007; Fri, 27 Oct 2017 18:50:31 +0000 From: Suresh Krishnan To: Spencer Dawkins at IETF , Adam Roach CC: Bob Hinden , "draft-ietf-6man-maxra@ietf.org" , IESG , IPv6 List , 6man Chairs <6man-chairs@ietf.org>, =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) Thread-Topic: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) Thread-Index: AQHTTRxDPCA1NLrma0mte5/FWo1nhaL2t2aAgAAj5YCAAEbQAIAAyG+AgAAGQ4CAAAh0gIAAFXIA Date: Fri, 27 Oct 2017 18:50:31 +0000 Message-ID: References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Suresh@kaloom.com; x-originating-ip: [67.22.228.35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR0101MB0724; 6:2WPlQLG2CU+oiXERvF41dtRGwFWcyR7XDDwPGd4IWK7/A7g5hq7EvXs7ecVQ+gDRjXbnzNh3HamnmtgJ4hy3VlXyN1TV4/v0pQfDA/7OVDP0P5zHnOOJ3OYgWcezAuAKuGNAh9/+yH92I262Na74xmpl806fWr647Hp+WK7B/jN7XjVQ+5qoRkJX6hmBEJO9sf4/kZizc12M+XcTMNXeFJsXUv69zingZiuZjUi5/Gtz803MuEL4tMynK+ZpycUiobInD/YCvdNTZoeXNw247GmVitFB2HlH3gf6EyH8AwRxkAWCJGIUKX04Z+sa5NQ1gVUA02X/Dl118r1PLyQ6M6iDLeHrD/4ME1faQRM4l1s=; 5:1DrjkUV0o+e51uibQ6yPY6VID5rUq3qPQ5UGA6goJ6knELofom29q+npeZ9beLOuXWcED/KPrhZRb6U2SmJFaKMP/9g5osMOdoLYIFxsd9189ois1+G1wBZyh6w/9Ekjxb5aFlILJCuyTJ9xszYURlfKgLPf7kAfTPhjk+ikIyw=; 24:0ZKdg3/d0mJtcRpUpc+6umIyUFlJsTiav4yL0rVFEieh4+GUcj1U/E4rU1wWa+A/U3kKLm4eyZTELHlaw2NqTiycuQWJyhXfMzbnQmzpm+k=; 7:ql5MN2kuzdLKAIAeQ7+nyadOLlMytSyKDkg6bl6mZaL7bYH+BVd5o8dKrUBWFaZV0VGkUk0rniev+GmKgCxx7gSTylL9XvNdVZu7CPi7Q10iwy+ykrIoDrH/6WrJTNk6WObq3/l+SuX0Z49ivZv8Rpc6HYNf4+HTC7Q+31rhtID+nLU6njWxx8EgEETxnNqKH5DbZf8S8t2/HPG4keepaD74vaoQK6ml6oj7fHbpslVyrCNGscLMLoJ5NrDEspoO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c71b4583-0e4b-411b-0112-08d51d6b99ab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(2017052603199); SRVR:YQBPR0101MB0724; x-ms-traffictypediagnostic: YQBPR0101MB0724: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231020)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123558100)(20161123555025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YQBPR0101MB0724; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YQBPR0101MB0724; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39830400002)(376002)(346002)(189002)(24454002)(199003)(4326008)(14454004)(36756003)(6116002)(305945005)(102836003)(97736004)(3846002)(33656002)(8936002)(72206003)(50986999)(105586002)(25786009)(478600001)(54356999)(76176999)(101416001)(189998001)(106356001)(86362001)(8676002)(7736002)(81156014)(81166006)(5250100002)(68736007)(2900100001)(6436002)(316002)(6506006)(6486002)(6512007)(5660300001)(110136005)(3280700002)(93886005)(83716003)(54906003)(53936002)(229853002)(80792005)(39060400002)(2950100002)(2906002)(3660700001)(53546010)(66066001)(82746002)(6246003)(230783001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:YQBPR0101MB0724; H:YQBPR0101MB0724.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9A60C24C5557E844BDE9A5A87E0008C3@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-Network-Message-Id: c71b4583-0e4b-411b-0112-08d51d6b99ab X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 18:50:31.8682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB0724 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:50:35 -0000 SGkgQWRhbS9TcGVuY2VyLA0KPEFEIEhhdCBPZmY+DQogIFNwZWFraW5nIGFzIGFuIGF1dGhvciwg SSBoYXZlIGFsc28gcmVhZCB0aGlzIGFzIGFuIGluY2x1c2l2ZSBiZXR3ZWVuIGFuZCBJIGRvIG5v dCBzZWUgYW55IGludGVyb3BlcmFiaWxpdHkgY29uY2VybnMgd2hpY2hldmVyIHdheSBpdCBpcyBy ZWFkLCBhcyB0aGUgYWN0dWFsIHNlbGVjdGVkIHZhbHVlIGlzIHBsYWNlZCBpbiB0aGUgUm91dGVy IExpZmV0aW1lIHZhbHVlIG9mIHRoZSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCB0byBiZSBjb21tdW5p Y2F0ZWQgdG8gdGhlIGhvc3QuIChBcyBhIGRhdGEgcG9pbnQsIHRoZSDigJxiZXR3ZWVu4oCdIHRl eHQgaW4gcXVlc3Rpb24gaXMgbm90IG5ldyBhbmQgaGFzIGJlZW4gY2FycmllZCBvdmVyIGZyb20g UkZDNDg2MSB3aGljaCBoYXMgYmVlbiBjYXJyaWVkIG92ZXIgZnJvbSBSRkMyNDYxIHdoaWNoIGl0 c2VsZiB3YXMgY2FycmllZCBvdmVyIGZyb20gUkZDMTk3MCBjaXJjYS4gMTk5NikuIFRoYXQgYmVp bmcgc2FpZCwgSSBoYXZlIG5vIGlzc3VlcyBtZW50aW9uaW5nIHRoYXQgdGhpcyBpcyBhbiBpbmNs dXNpdmUgYmV0d2VlbiBhcyB0aGUgcmVjZWl2aW5nIGhvc3RzIGFyZSBhbHJlYWR5IHJlcXVpcmVk IHRvIGFjY2VwdCBhbnkgdmFsdWUgaW4gdGhlIFJvdXRlciBMaWZldGltZSDigJx1cCB0byA2NTUz NeKAnSBhY2NvcmRpbmcgdG8gc2VjdGlvbiA0LjIgb2YgUkZDNDg2MS4gDQoNClRoYW5rcw0KU3Vy ZXNoDQoNCj4gT24gT2N0IDI3LCAyMDE3LCBhdCAxOjMzIFBNLCDnpZ7mmI7pgZTlk4kgPGppbm1l aUB3aWRlLmFkLmpwPiB3cm90ZToNCj4gDQo+IEF0IEZyaSwgMjcgT2N0IDIwMTcgMTI6MDM6Mjkg LTA1MDAsDQo+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdt YWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4+IElmIGFueXRoaW5nLCBpZiB3ZSBub3cgImNsYXJpZnki IGl0IHRvIG1lYW4gImV4Y2x1c2l2ZSIsIGF0IGxlYXN0IG9uZQ0KPj4+IGltcGxlbWVudGF0aW9u IHdpbGwgbm93IGJlY29tZSB0ZWNobmljYWxseSBub24tY29tcGxpYW50LiAgU28sIHdoaWxlDQo+ Pj4gbXkgcHJpbWFyeSBzdWdnZXN0aW9uIGlzIG5vdCB0byBkbyBhbnl0aGluZyBhYm91dCBpdCwg aWYgd2UgcmVhbGx5DQo+Pj4gbmVlZCB0byBzYXkgc29tZXRoaW5nLCBJJ2Qgc3VnZ2VzdCBjbGFy aWZ5aW5nICJ3aGV0aGVyIHRoaXMgJ2JldHdlZW4nDQo+Pj4gaXMgaW5jbHVzaXZlIG9yIGV4Y2x1 c2l2ZSBkb2VzIG5vdCBtYXR0ZXIgaW4gdGVybXMgaW50ZXJvcGVyYWJpbGl0eQ0KPj4+IGFuZCBp cyBsZWZ0IHRvIGltcGxlbWVudGF0aW9ucyIuDQo+PiANCj4+IElmIHRoZSBwcmVjaXNlIG1lYW5p bmcgb2YgdGhlIGJvdW5kYXJpZXMgc2V0IGJ5IGEgTVVTVCByZXF1aXJlbWVudCBkb2Vzbid0DQo+ PiBhY3R1YWxseSBtYXR0ZXIsIEknbSBub3QgdW5kZXJzdGFuZGluZyB3aHkgdGhpcyBpcyBhIE1V U1QgLi4uICBBZGFtIGNhbg0KPj4gc3BlYWsgZm9yIGhpbXNlbGYsIGJ1dCB0aGF0J3Mgd2hhdCAq SSogd291bGQgYmUgY29uZnVzZWQgYWJvdXQuDQo+IA0KPiBUaGF0J3Mgbm90IG15IGNhbGwgZWl0 aGVyLCBhbmQgaXQncyB0b3RhbGx5IHBvc3NpYmxlIHRoYXQgYW4gUkZDMjExOQ0KPiBNVVNUIHdh cyB1c2VkIHRvbyBjYXN1YWxseSwgYnV0IEkgZ3Vlc3MgdGhlIHNwaXJpdCBvZiB0aGUgTVVTVCBp biB0aGlzDQo+IGNhc2UgaXMgdG8gc3BlY2lmeSBhIHNlbnNpYmxlICpyYW5nZSogd2l0aCBzb21l IHN0cm9uZ2VyIHJlcXVpcmVtZW50DQo+IGxldmVsIHNvIGEgZGV2aWFudCBpbXBsZW1lbnRvciBv ciBvcGVyYXRvciBjYW4ndCBjYXVzZSBhbiBleHRyZW1lDQo+IGVmZmVjdC4gIEJ1dCBpdCdzIG5v dCBpbXBvcnRhbnQgd2hldGhlciB0aGUgZXhhY3QgYm91bmRhcnkgdmFsdWVzIGFyZQ0KPiBpbmNs dWRlZC4gIFdpdGggdGhpcyBpbnRlcnByZXRhdGlvbiwgdGhpcyBzaG91bGQgcmVhZA0KPiBBZHZE ZWZhdWx0TGlmZXRpbWUgTVVTVCBiZSBvbmUgb2YgdGhlIGZvbGxvd2luZzoNCj4gW2xvd2VyLCB1 cHBlcl0NCj4gKGxvd2VyLCB1cHBlcikNCj4gW2xvd2VyLCB1cHBlcikNCj4gKGxvd2VyLCB1cHBl cl0NCj4gDQo+IFdoYXQgJ2xvd2VyJyBhbmQgJ3VwcGVyJyBhcmUgaXMgaW1wb3J0YW50IChoZW5j ZSB0aGUgTVVTVCksIGJ1dCB3aGljaA0KPiBvbmUgb2YgdGhlIGFib3ZlIGZvdXIgaXMgaW1wbGVt ZW50ZWQgaXNuJ3QuDQo+IA0KPiBUaGF0IG1ha2VzIHNlbnNlIHRvIG1lLg0KPiANCj4gLS0NCj4g SklOTUVJLCBUYXR1eWENCg0K From nobody Fri Oct 27 13:21:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED313F43D; Fri, 27 Oct 2017 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuMIsmEy6_WC; Fri, 27 Oct 2017 13:21:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CD813F5CE; Fri, 27 Oct 2017 13:21:39 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9RKLU8u032803 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 27 Oct 2017 15:21:31 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Ole Troan Cc: IPv6 List , 6man Chairs <6man-chairs@ietf.org>, Bob Hinden , IESG , draft-ietf-6man-maxra@ietf.org References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> From: Adam Roach Message-ID: Date: Fri, 27 Oct 2017 15:21:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DE1D3B4924FA7BE14513A34C" Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:21:41 -0000 This is a multi-part message in MIME format. --------------DE1D3B4924FA7BE14513A34C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/27/17 11:41, 神明達哉 wrote: > FWFIW, an implementation that I know of adopts the "inclusive" version > of "between" (it doesn't support 6man-maxra so it still only conforms > to RFC4861) Right. And I think "inclusive" is probably the right answer here. Let's examine the statement in question: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535." Let's first consider the low end of this interval. Section 3 says: "AdvDefaultLifetime MUST be set to a value greater than or equal to the selected MaxRtrAdvInterval." Assuming "or equal to" is not a very complicated misspelling, would seem to indicate that the range is inclusive on the lower end. [1] Now, let's consider the high end of this interval.  The normative statement "MaxRtrAdvInterval MUST be no greater than 65535" allows MaxRtrAdvInterval == 65535. In the case that MaxRtrAdvInterval == 65535, what would be the allowable values for AdvDefaultLifetime? If it must be less-than-and-never-equal-to 65535, and yet must be greater-than-or-equal-to MaxRtrAdvInterval, you're left in a bit of a pickle: "65535 <= x < 65535" cannot be solved for x. This then indicates that the range needs to be inclusive on the upper end. So while I believe the answer is probably self-evident if one does the analysis, the problem is that one has to chain together a lot of logical statements to arrive at this conclusion; and such a chain is sufficiently non-obvious that even the document shepherd/WG chair appears to have arrived at a different conclusion than what this logical analysis would lead us to understand. All I'm asking for is the insertion of a single word in the normative statement in question, so that it reads: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535, inclusive." I'm happy to keep discussing this; but for me to change my ballot position, you'll have to do one of the following: 1. Change the statement to be unambiguous. 2. Change the statement to be non-normative. 3. Make a compelling case that it is okay for normative statements to be ambiguous. /a ____ [1] This is complicated by the following language: "K=AdvDefaultLifetime/MaxRtrAdvInterval" and "on a theoretically perfect link with no losses, it would have been sufficient to have K just above 1" -- which implies that K=1 (that is, AdvDefaultLifetime == MaxRtrAdvInterval) is problematic even in a theoretically perfect case. However, since this text is non-normative, I think it has less weight than the normative statements cited above. --------------DE1D3B4924FA7BE14513A34C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/27/17 11:41, 神明達哉 wrote:
FWFIW, an implementation that I know of adopts the "inclusive" version of "between" (it doesn't support 6man-maxra so it still only conforms to RFC4861)

Right. And I think "inclusive" is probably the right answer here. Let's examine the statement in question: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535."

Let's first consider the low end of this interval. Section 3 says: "AdvDefaultLifetime MUST be set to a value greater than or equal to the selected MaxRtrAdvInterval." Assuming "or equal to" is not a very complicated misspelling, would seem to indicate that the range is inclusive on the lower end. [1]

Now, let's consider the high end of this interval.  The normative statement "MaxRtrAdvInterval MUST be no greater than 65535" allows MaxRtrAdvInterval == 65535. In the case that MaxRtrAdvInterval == 65535, what would be the allowable values for AdvDefaultLifetime? If it must be less-than-and-never-equal-to 65535, and yet must be greater-than-or-equal-to MaxRtrAdvInterval, you're left in a bit of a pickle: "65535 <= x < 65535" cannot be solved for x. This then indicates that the range needs to be inclusive on the upper end.

So while I believe the answer is probably self-evident if one does the analysis, the problem is that one has to chain together a lot of logical statements to arrive at this conclusion; and such a chain is sufficiently non-obvious that even the document shepherd/WG chair appears to have arrived at a different conclusion than what this logical analysis would lead us to understand.

All I'm asking for is the insertion of a single word in the normative statement in question, so that it reads: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535, inclusive."

I'm happy to keep discussing this; but for me to change my ballot position, you'll have to do one of the following:
  1. Change the statement to be unambiguous.
  2. Change the statement to be non-normative.
  3. Make a compelling case that it is okay for normative statements to be ambiguous.

/a

____
[1] This is complicated by the following language: "K=AdvDefaultLifetime/MaxRtrAdvInterval" and "on a theoretically perfect link with no losses, it would have been sufficient to have K just above 1" -- which implies that K=1 (that is, AdvDefaultLifetime == MaxRtrAdvInterval) is problematic even in a theoretically perfect case. However, since this text is non-normative, I think it has less weight than the normative statements cited above.

--------------DE1D3B4924FA7BE14513A34C-- From nobody Sat Oct 28 09:42:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7913FBC5; Sat, 28 Oct 2017 09:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDgC-cQeB2FL; Sat, 28 Oct 2017 09:41:57 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEA913FBC7; Sat, 28 Oct 2017 09:41:57 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id b189so8258204wmd.4; Sat, 28 Oct 2017 09:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zP7KI4RimN0q06DGvVA1uQwxeBQ3NNUuWImSGQ5q0eI=; b=qeZB83Zgj6d/PhTDc0HieJBU/kXGr6seU9F/rJeoeVkJSCf6aGbvneTPkEDR/YKcr0 fJMzMhv9zPOmCKmbNdzvcKDOClD1miOoIqslfgKPsT2AQbNFfz+CLGtrv9Yx6NXSxqlr tMxXLElAB82zisDN3qdA3uz9dbEzyAWreic2uR43MwgpsnJ81tKLVgMAkXkZ7z0utAZ1 9yR3pZ77vEt567/byJy9NJdI1tJX9d36UQAZ85HXw+af+l1gIP/2pE7fItECPTUIsT6h +U0xftn0EHdat2LnVweN8a8nskwbEimmTqSyIB2282l5YcjcoiN6auFXOir8YnlFDTYn SxKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zP7KI4RimN0q06DGvVA1uQwxeBQ3NNUuWImSGQ5q0eI=; b=CZ8NjqbkoocVNUmG3o3gPXUIuwT2E434J5zx25eLdkCzMK1GZtIO0qFwom68uvw2PR 7KyxSQoVAMtVQv9PxhBAuSLuTPDjI+deGgXLRk0qaRjGPZMugGIi4WyEOY+ahbXx5OLL oApaMD8+tDIFJDAxXgUFdDqFdLQnqbT5crN9qXNbaVbyrhViCvnt+Dmj81qIXEes87qr B/Kvo/8g/dOi8baOS2wnpuk2Qagn81MGZx8maCPUpqCxN4fv4N9x+FpLF2k0WG84Bk4X 64/+a7kgeyELi8VYtosHbDEx3K3y67pvEwFH9Xk/5k+G9WmBOyavdQG9b38DgoBVaUc2 VyEA== X-Gm-Message-State: AMCzsaX5oPxm9VV9MAcqdrJBBGPYsPnqEASNO+Dkbirs/Yuap+DVjnEf Nq+EcsYoGRMIedr+cp711cY= X-Google-Smtp-Source: ABhQp+QP7W0vD2H+XQ9Zq3woc4edbqKz6BnQxMNAmdgg5d7GjqZcvxByWR6xgXDxh37rtFX8+CNFlA== X-Received: by 10.80.230.1 with SMTP id y1mr5126042edm.211.1509208914302; Sat, 28 Oct 2017 09:41:54 -0700 (PDT) Received: from ?IPv6:2601:647:4d01:db10:b0ba:c068:e41:c555? ([2601:647:4d01:db10:b0ba:c068:e41:c555]) by smtp.gmail.com with ESMTPSA id t11sm7102911edh.63.2017.10.28.09.41.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Oct 2017 09:41:53 -0700 (PDT) From: Bob Hinden Message-Id: <0BFA58F4-267B-4B5F-A377-81D4F845AB2E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5BCC4DF2-A4C9-4F19-BB0B-84EBCB364534"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT) Date: Sat, 28 Oct 2017 09:41:48 -0700 In-Reply-To: Cc: Bob Hinden , =?utf-8?B?56We5piO6YGU5ZOJ?= , =?utf-8?Q?Ole_Tr=C3=B8an?= , IPv6 List , draft-ietf-6man-maxra@ietf.org, IESG , Adam Roach , 6man Chairs <6man-chairs@ietf.org> To: Spencer Dawkins at IETF References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com> <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 16:41:59 -0000 --Apple-Mail=_5BCC4DF2-A4C9-4F19-BB0B-84EBCB364534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Spencer, > On Oct 27, 2017, at 10:03 AM, Spencer Dawkins at IETF = wrote: >=20 > This isn't my area of expertise, my actual area, or my ballot thread, = but ... >=20 > On Fri, Oct 27, 2017 at 11:41 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > At Thu, 26 Oct 2017 21:43:42 -0700, > Ole Troan wrote: >=20 > > It might be worth noting that if it is inclusive or exclusive has > > absolutely zero consequence for the protocol. >=20 > FWFIW, an implementation that I know of adopts the "inclusive" version > of "between" (it doesn't support 6man-maxra so it still only conforms > to RFC4861): >=20 > MAYHAVE(val, "rltime", rai->rai_maxinterval * 3); > if ((uint16_t)val && ((uint16_t)val < rai->rai_maxinterval || > (uint16_t)val > MAXROUTERLIFETIME)) { > syslog(LOG_ERR, > "<%s> router lifetime (%" PRIu32 ") on %s is invalid " > "(must be 0 or between %d and %d)", > __func__, val, ifi->ifi_ifname, rai->rai_maxinterval, > MAXROUTERLIFETIME); > goto getconfig_free_rai; > } > = (https://github.com/freebsd/freebsd/blob/master/usr.sbin/rtadvd/config.c) >=20 > But, more important, I agree with Bob and Ole in that "inclusive" vs > "exclusive" shouldn't cause an interoperability problem since hosts > are not supposed to reject an RA for a particular value of router > lifetime: >=20 > Router Lifetime > 16-bit unsigned integer. The lifetime associated > with the default router in units of seconds. The > field can contain values up to 65535 and = receivers > should handle any value, while the sending rules = in > Section 6 limit the lifetime to 9000 seconds. = [...] >=20 > If anything, if we now "clarify" it to mean "exclusive", at least one > implementation will now become technically non-compliant. So, while > my primary suggestion is not to do anything about it, if we really > need to say something, I'd suggest clarifying "whether this 'between' > is inclusive or exclusive does not matter in terms interoperability > and is left to implementations". >=20 > If the precise meaning of the boundaries set by a MUST requirement = doesn't actually matter, I'm not understanding why this is a MUST ... = Adam can speak for himself, but that's what *I* would be confused about. Adam=E2=80=99s Discuss was for concern about an interoperability problem = if an implementation choose to pick 65534 or 65535 seconds for the = default router lifetime in the RA it sends. Both are legal values so = will be accepted by the hosts receiving the RA. The host receiving the = RA uses the lifetime to timeout the a default router entry. A one = second difference in 18.2 hours is inconsequential. The way this works is routers will send RAs well before the timeout = happens. RFC4861 specifies the max and min times when RAs should be = sent, and it doesn=E2=80=99t get close to the boundary. If our goal is to ensure interoperability, I don=E2=80=99t see an = interoperability issue here. I note that RFC4861 where this language = comes from is very widely implemented. Bob >=20 > Spencer, who might or might not be Asking For A Friend >=20 > -- > JINMEI, Tatuya >=20 >=20 --Apple-Mail=_5BCC4DF2-A4C9-4F19-BB0B-84EBCB364534 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZ9LNMAAoJEK7rdBF357uosIYIAI4Rhx9ticMbBcOXLoAYwAra 1+1wFPgbfD5UUPTP2ulvmD+5xEg8MRrf0taemyiWd2bW4Bw6u2cLJXxeyE//z0To g9wpd6Z713Vmn4IXojXyE3jfBP7uGU3fcZxl+Wl9ucTfnVyz8RV43iNLGlGeNyCl nnNpaAtcBH/FJz+wL37Y6Q5Y0dVYk7gu5mQ/FLKDACXcA1UJcQ57R8rZPLpM4nht NRuMjNwcoUrJ0LuDcHps12W0SGf2VGORuhBTVCmcwBw0Me4sqnK6EAx6PzF9XEta Urwj6rYac1cGFfx/L9vvhMo1s/0BEKmoFhfxJXU2/NnZSojcDTeTj5DX0jXTjCA= =jNrg -----END PGP SIGNATURE----- --Apple-Mail=_5BCC4DF2-A4C9-4F19-BB0B-84EBCB364534-- From nobody Sat Oct 28 16:17:31 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E6413FDC2 for ; Sat, 28 Oct 2017 16:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDp345_l20vq for ; Sat, 28 Oct 2017 16:17:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65F013FDBF for ; Sat, 28 Oct 2017 16:17:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BCBF1B8114C; Sat, 28 Oct 2017 16:17:22 -0700 (PDT) To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com Subject: [Technical Errata Reported] RFC8200 (5170) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171028231722.BCBF1B8114C@rfc-editor.org> Date: Sat, 28 Oct 2017 16:17:22 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 23:17:30 -0000 The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5170 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 4.5 Original Text ------------- A Fragment Offset containing the offset of the fragment, in 8-octet units, relative to the start of the Fragmentable Part of the original packet. The Fragment Offset of the first ("leftmost") fragment is 0. Corrected Text -------------- A Fragment Offset containing the offset of the fragment, in 8-octet units, relative to the start of the "Extension & Upper-Layer Headers" Part of the original packet. The Fragment Offset of the fragment containing the "Extension & Upper-Layer Headers" part is 0. Notes ----- Clearly, the first fragment will contain a Fragment Offset of 0. However, given the figure: ---- cut here ---- original packet: +-----------------+-----------------+--------+--------+-//-+--------+ | Per-Fragment |Ext & Upper-Layer| first | second | | last | | Headers | Headers |fragment|fragment|....|fragment| +-----------------+-----------------+--------+--------+-//-+--------+ fragment packets: +------------------+---------+-------------------+----------+ | Per-Fragment |Fragment | Ext & Upper-Layer | first | | Headers | Header | Headers | fragment | +------------------+---------+-------------------+----------+ +------------------+--------+-------------------------------+ | Per-Fragment |Fragment| second | | Headers | Header | fragment | +------------------+--------+-------------------------------+ o o o +------------------+--------+----------+ | Per-Fragment |Fragment| last | | Headers | Header | fragment | +------------------+--------+----------+ it is the part market as "Ext & Upper-Layer Headers" the one that will have a Fragment offset of 0, rather than the part marked as "first fragment". For example, one could envision this scenario: ---- cut here ---- original packet: +-----------------+-----------------+---------------+ | Per-Fragment |Ext & Upper-Layer| first & last | | Headers | Headers | fragment | +-----------------+-----------------+---------------+ fragment packets: +------------------+---------+-------------------+ | Per-Fragment |Fragment | Ext & Upper-Layer | | Headers | Header | Headers | +------------------+---------+-------------------+ +------------------+--------+---------------+ | Per-Fragment |Fragment| first & last | | Headers | Header | fragment | +------------------+--------+---------------+ ---- cut here ---- Where the first fragment just contains the entire IPv6 header chain, and then second fragment contains the chunk marked as "first fragment" (this "first fragment" part is the only "Fragmentable" part of the packet). Note: the text "The Fragment Offset of the first ("leftmost") fragment is 0." was re-phrased in the "corrected text", since it might confuse the reader regarding whether it refers to the actual first fragment (i.e. the first packet corresponding to the fragmented datagram), or the chunk marked as "first fragment" in the figure. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8200 (draft-ietf-6man-rfc2460bis-13) -------------------------------------- Title : Internet Protocol, Version 6 (IPv6) Specification Publication Date : July 2017 Author(s) : S. Deering, R. Hinden Category : INTERNET STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Sat Oct 28 22:20:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6913F63A for ; Sat, 28 Oct 2017 22:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkJzwP4M4PC0 for ; Sat, 28 Oct 2017 22:20:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A2D13F5ED for ; Sat, 28 Oct 2017 22:20:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8AB2BB80CF3; Sat, 28 Oct 2017 22:20:38 -0700 (PDT) To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com Subject: [Technical Errata Reported] RFC8200 (5171) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171029052038.8AB2BB80CF3@rfc-editor.org> Date: Sat, 28 Oct 2017 22:20:38 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 05:20:46 -0000 The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5171 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 4.5 Original Text ------------- The subsequent fragment packets are composed of: (1) The Per-Fragment headers of the original packet, with the Payload Length of the original IPv6 header changed to contain the length of this fragment packet only (excluding the length of the IPv6 header itself), and the Next Header field of the last header of the Per-Fragment headers changed to 44. (2) A Fragment header containing: The Next Header value that identifies the first header after the Per-Fragment headers of the original packet. A Fragment Offset containing the offset of the fragment, in 8-octet units, relative to the start of the Fragmentable Part of the original packet. Corrected Text -------------- The subsequent fragment packets are composed of: (1) The Per-Fragment headers of the original packet, with the Payload Length of the original IPv6 header changed to contain the length of this fragment packet only (excluding the length of the IPv6 header itself), and the Next Header field of the last header of the Per-Fragment headers changed to 44. (2) A Fragment header containing: The Next Header value that identifies the first header after the Per-Fragment headers of the original packet. A Fragment Offset containing the offset of the fragment, in 8-octet units, relative to the start of the "Extension & Upper-Layer Headers" part of the original packet. Notes ----- This complements this errata: Reported By: Fernando Gont Date Reported: 2017-10-28 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8200 (draft-ietf-6man-rfc2460bis-13) -------------------------------------- Title : Internet Protocol, Version 6 (IPv6) Specification Publication Date : July 2017 Author(s) : S. Deering, R. Hinden Category : INTERNET STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Sat Oct 28 23:57:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5793813F6BC for ; Sat, 28 Oct 2017 23:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EJdrw3zdzND for ; Sat, 28 Oct 2017 23:57:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C088113F6B4 for ; Sat, 28 Oct 2017 23:57:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 634DAB8179E; Sat, 28 Oct 2017 23:57:40 -0700 (PDT) To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com Subject: [Technical Errata Reported] RFC8200 (5172) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171029065740.634DAB8179E@rfc-editor.org> Date: Sat, 28 Oct 2017 23:57:40 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 06:57:48 -0000 The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5172 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 4.5 Original Text ------------- The Fragmentable Part of the reassembled packet is constructed from the fragments following the Fragment headers in each of the fragment packets. The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself; its relative position in Fragmentable Part is computed from its Fragment Offset value. Corrected Text -------------- The "Ext & Upper-Layer Headers" part and Fragmentable Part of the reassembled packet are constructed from the "chunks" following the Fragment headers in each of the fragment packets. The length of each chunk is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and chunk itself; the relative position of the chunk is computed from its Fragment Offset value. Notes ----- * The original text misses how to construct the "Ext & Upper-Layer Headers" of the packet, which in the figures is not considered to be part of the "Unfragmentable part" (it *was* considered part of it in RFC2460). * The original text does says: The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself Assuming "each fragment" refers to the pieces marked as "first fragment", "second fragment", etc., this does not apply for the computation of the length of the first fragment, since such computed length would otherwise include the length of the first fragment, plus the length of "Ext & Upper-Layer Headers". * The "corrected text" requires more work, and employs the (previously undefined) term "chunk" to refer to the content of a fragment (the chunk following a Fragment Header in a given packet). This is because for all fragments other than the first, "fragment" is what follows an FH, but for the first fragment (given the figures), "first fragment" is NOT everything that follows the FH (i.e., it does not include the "Ext & Upper-Layer Headers" part. * Note that in the corrected text, the phrase "its relative position in Fragmentable Part is computed from its Fragment Offset value", since the relative position is really from the "Ext & Upper-Layer Headers" part, rather than from the Unfragmentable part. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8200 (draft-ietf-6man-rfc2460bis-13) -------------------------------------- Title : Internet Protocol, Version 6 (IPv6) Specification Publication Date : July 2017 Author(s) : S. Deering, R. Hinden Category : INTERNET STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Sun Oct 29 00:06:04 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20C13F6D5 for ; Sun, 29 Oct 2017 00:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teaRA2UQ-zTz for ; Sun, 29 Oct 2017 00:06:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC6C13F6CF for ; Sun, 29 Oct 2017 00:06:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E52AFB8018D; Sun, 29 Oct 2017 00:05:54 -0700 (PDT) To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com Subject: [Technical Errata Reported] RFC8200 (5173) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171029070554.E52AFB8018D@rfc-editor.org> Date: Sun, 29 Oct 2017 00:05:54 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:06:03 -0000 The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5173 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 4.5 Original Text ------------- reassembled original packet: +---------------+-----------------+---------+--------+-//--+--------+ | Per-Fragment |Ext & Upper-Layer| first | second | | last | | Headers | Headers |frag data|fragment|.....|fragment| +---------------+-----------------+---------+--------+-//--+--------+ Corrected Text -------------- reassembled original packet: +---------------+-----------------+---------+--------+-//--+--------+ | Per-Fragment |Ext & Upper-Layer| first | second | | last | | Headers | Headers | fragment|fragment|.....|fragment| +---------------+-----------------+---------+--------+-//--+--------+ Notes ----- The figure in the "original text" is inconsistent with an earlier figure of the "original packet" (in page 18), where the "Ext & Upper-Layer Headers" part is followed by "first fragment" (rather than "first fragment data"). As an alternative to the "corrected text" above, one could modify such earlier figure (s/first fragment/first fragment data/), but this would beg a definition of "how is a fragment composed?" i.e., what's "fragment data" and what's not). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8200 (draft-ietf-6man-rfc2460bis-13) -------------------------------------- Title : Internet Protocol, Version 6 (IPv6) Specification Publication Date : July 2017 Author(s) : S. Deering, R. Hinden Category : INTERNET STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Mon Oct 30 05:14:13 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFF013AC0D for ; Mon, 30 Oct 2017 05:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.068 X-Spam-Level: X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 KrK2s5rkg24z for ; Mon, 30 Oct 2017 05:14:10 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 D869A13F7AC for ; Mon, 30 Oct 2017 05:14:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v9UCE7DW032804 for ; Mon, 30 Oct 2017 13:14:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF0AD20539E for ; Mon, 30 Oct 2017 13:14:07 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BAD37200B5C for ; Mon, 30 Oct 2017 13:14:07 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v9UCE7A1026550 for ; Mon, 30 Oct 2017 13:14:07 +0100 To: IPv6 From: Alexandre Petrescu Subject: Documentation prefix notation for a /56 Message-ID: Date: Mon, 30 Oct 2017 13:14:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B42F4648563DE223E7B010D9" Content-Language: fr Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 12:14:13 -0000 This is a multi-part message in MIME format. --------------B42F4648563DE223E7B010D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, What documentation prefix notation should I use when writing about a /56 prefix in an Internet Draft? Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long. Could I use 2001:db8:XYZU:TW::/56?  It does not seem correct to me. Alex --------------B42F4648563DE223E7B010D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

What documentation prefix notation should I use when writing about a /56 prefix in an Internet Draft?

Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long.

Could I use 2001:db8:XYZU:TW::/56?  It does not seem correct to me.

Alex

--------------B42F4648563DE223E7B010D9-- From nobody Mon Oct 30 06:36:45 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3913F4FB; Mon, 30 Oct 2017 06:36:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipv6@ietf.org Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150937060401.3306.16675157648974156910@ietfa.amsl.com> Date: Mon, 30 Oct 2017 06:36:44 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:36:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF. Title : IPv6 Node Requirements Authors : Tim Chown John Loughney Timothy Winters Filename : draft-ietf-6man-rfc6434-bis-02.txt Pages : 40 Date : 2017-10-30 Abstract: This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6434-bis-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 Mon Oct 30 06:43:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D327113F9EE for ; Mon, 30 Oct 2017 06:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpWHtSgLi1hV for ; Mon, 30 Oct 2017 06:43:06 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 277EA13F9EC for ; Mon, 30 Oct 2017 06:43:06 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id h4so16363019qtk.8 for ; Mon, 30 Oct 2017 06:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=CXR46KxWvRPl42BuFv9qzSRxU5T4q534aGYtVI7USyQ=; b=FnZtasA8yyqXVgwB67R3izkSDV+PMkCY+/5NEcWTF7ZY9i90EnYhuhdRbzBNMwYKvZ ZOFuPEIXtEYaXiy3JEnhUmoIvzAgUan3+bM3OESaLMrtEpnBVgW+0d7h5AaXEbRTaNqc o/Msh+qkXFmcs4ik9L763mxjdn4+AHkNMtn9Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CXR46KxWvRPl42BuFv9qzSRxU5T4q534aGYtVI7USyQ=; b=eBXFBqpmi0dGihWHGDhlvoW9ACVTOlTrlYXr9YwcnfCNtoQo/XFJIRHjY7AP6eFx+C vDgbQFoSNQhp26Fm8lkNSr9EC8FKQikaLL7DX4hxtC2aiMasR9aqRAeeK11gPlz5xigk ey3xziQ7ids4GU7PHdYvN5LBaRI7TUPfdycgjg0ctH4w8D83TccZGo0MlS5rPRem+FJ+ X8wjwhbzK/HqUERtWnXdGBC6eV0JsWOeOp86p7EzQurpIlcVTFZ5aShbZ07tFD7xsY5q 6H5/6eC0LL4ONeUm6/BKjV5xCjPaspzYbQkagaBOq/E1hhqc6SOeqppLDt5gpNL9UP3G XqDQ== X-Gm-Message-State: AMCzsaUHVi2xAg0+NLJxKcA4ANyh2yY/YESvaAOr7qT5Hsr9LaremCsz +2KaIiwNpY1dhEEWvW9C3COgr8Ov56FPVpO2Lx3FA7bO X-Google-Smtp-Source: ABhQp+SM07XlvZ7KvJfxloNggRJKLGk19wnBPGGjkisr4L1melv9yJmKGP6ITiq4Ci+/tX+kRgXD9M6eI3Nwekn6DdY= X-Received: by 10.237.34.201 with SMTP id q9mr14010530qtc.198.1509370984383; Mon, 30 Oct 2017 06:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.8 with HTTP; Mon, 30 Oct 2017 06:42:43 -0700 (PDT) From: Timothy Winters Date: Mon, 30 Oct 2017 09:42:43 -0400 Message-ID: Subject: Updates to RFC6434 To: 6man WG Content-Type: multipart/alternative; boundary="001a1137b67a5c0ae2055cc3d14d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:43:09 -0000 --001a1137b67a5c0ae2055cc3d14d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have posted an updated version of 6434bis, with the following changes since Prague: - Text on EH processing - Noted that RFC4191 is a MUST, but a SHOULD for Type C node - Updated RFC references (8200, 8201, 8221, 8247) - Added note on RFC 7772 for power consumption - Added =E2=80=98Why /64?=E2=80=99 reference; RFC 7421 - Removed jumbogram text - Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host - For 3GPP, added =E2=80=98snapshot=E2=80=99 comment on RFC7066 - Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724) - Removed ATM over IPv6 - Added reference to RFC8064 - Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs - Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic We'll be sending some additional questions to the list later this week to hopefully get this document ready for working group last call. ~Tim, Tim and John ---------- Forwarded message ---------- From: Date: Mon, Oct 30, 2017 at 9:36 AM Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt To: i-d-announce@ietf.org Cc: ipv6@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF. Title : IPv6 Node Requirements Authors : Tim Chown John Loughney Timothy Winters Filename : draft-ietf-6man-rfc6434-bis-02.txt Pages : 40 Date : 2017-10-30 Abstract: This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc6434-bis-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1137b67a5c0ae2055cc3d14d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have posted an updated version of 6434bis, with the fol= lowing changes since Prague:
  • Text on EH processing=C2=A0
  • Noted that RFC4191 is a MUST, but a SHOULD for Type C node
  • U= pdated RFC references (8200, 8201, 8221, 8247)
  • Added note on RFC 77= 72 for power consumption
  • Added =E2=80=98Why /64?=E2=80=99 reference= ; RFC 7421
  • Removed jumbogram text=C2=A0
  • Added reference to = draft-ietf-v6ops-unique-ipv6-prefix-per-host
  • For 3GPP, added =E2=80= =98snapshot=E2=80=99 comment on RFC7066
  • Added RFC8028 as a SHOULD (= for Section 5.5 from RFC 6724)
  • Removed ATM over IPv6
  • Added = reference to RFC8064
  • Added MUST for BCP 198, and ref to draft-ietf-= v6ops-ipv6rtr-reqs
  • Added text on avoiding 1280 MTU for UDP (inc. DN= S) traffic
We'll be sending some additional questio= ns to the list later this week to hopefully get this document ready for wor= king group last call.

~Tim, Tim and John



---------- Forwarde= d message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Oct 30, 2017 at 9:36 = AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: <= a href=3D"mailto:i-d-announce@ietf.org" target=3D"_blank">i-d-announce@ietf= .org
Cc: ipv6@iet= f.org



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Node Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tim = Chown
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Loughney
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Timothy Winters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6man-rfc6434-bis-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 40
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0This document defines requirements for IPv6 nodes.=C2=A0 It is= expected
=C2=A0 =C2=A0that IPv6 will be deployed in a wide range of devices and situ= ations.
=C2=A0 =C2=A0Specifying the requirements for IPv6 nodes allows IPv6 to func= tion
=C2=A0 =C2=A0well and interoperate in a large number of situations and
=C2=A0 =C2=A0deployments.

=C2=A0 =C2=A0This document obsoletes RFC 6434, and in turn RFC 4294.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-6man-rfc6434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-6man-rfc6434-bis-02
https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc6434-bis-02


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

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

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



--

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a1137b67a5c0ae2055cc3d14d-- From nobody Mon Oct 30 06:57:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B113F9FD for ; Mon, 30 Oct 2017 06:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_KxTWJLqXwN for ; Mon, 30 Oct 2017 06:57:13 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 AF26413F9FB for ; Mon, 30 Oct 2017 06:57:09 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 3907B565 for ; Mon, 30 Oct 2017 13:57:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xldS1jb_gDsf for ; Mon, 30 Oct 2017 08:57:09 -0500 (CDT) Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id DB7DA66E for ; Mon, 30 Oct 2017 08:57:08 -0500 (CDT) Received: by mail-lf0-f70.google.com with SMTP id r124so3982636lfr.13 for ; Mon, 30 Oct 2017 06:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q+cU5u0ui4lSEE3K2bfIrLVcDoJbYhSqoa5II/QHKmE=; b=YXxkP3GA45VeOD9DsFEvedIPBS2uFSg2GwFqFb9KAK5ClFsUfGzClvqvK3miK/zyD3 WkvxBETytcsMqbD7GQ01j6eIS+kKqCcbCMNe7sHM+I4kL14Vybbtw2GLWKAZtCzjB2Ts hYNuFi31O/YHF28ekh/iJi4bqkuHvuc2lrT+0xb+QTmol7NgAt/1vWxVQ139h3JKBoPg B39YLg9Lt/R5yqqxyBeRav6xR9rkiX3dxwi9Vfook2k2CQFBAFdWLKtL9tLVbkNuBiEU Vd2C9tBl4FD0YxKTlVne9BPQX4VHkRYJb4xDwP03BSHSXH6bSLHRb5qDZjk57Ist4ru+ +yBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q+cU5u0ui4lSEE3K2bfIrLVcDoJbYhSqoa5II/QHKmE=; b=BOiA5VkxAxHEwggc9yn0eeDi8AQMQmRzGK7CFmhDIXV8snzTKm4Hm+8jtmUVkW56O4 EFazlcLkoIIzG7SL/k+gIl+3FMRMWL10BZmfWqdScUizdkWzQUWA53j00fzf03TX9OP2 MOVluS7dVI32ygDzZ/aXfkbi3aloWdZzg+LDRn0QPs8FaJ2p6eHOLtLYq6kd72GhLahX kia2fvisrDtx9vB4pgHFkuOTH/4qAXblBKrSP+zyl790hchtbE6m8U/WgI8g1ORwPbQ6 229vQgqxorGhCPm2ZNTAy4Koe7LjzZaOXCaJvDWV9AbFQAI2zu2l6WVfKB8I4gQcW7DT IFqg== X-Gm-Message-State: AMCzsaWz0sj4ksHU/7uaCjv3ll2/7cHJ2KoTBdO9vOGI167ay2l4DSiT 1qA7Br+9LSUYe0FwPIdqg3VeVZdJ3WBekXKOfg3ub7OrpVlxqTaawLF1yLHfwVTqqHTEM3Ik9yX lXcsX9hJdyWe37MbkADCOKKxm X-Received: by 10.25.147.11 with SMTP id v11mr3622464lfd.32.1509371827501; Mon, 30 Oct 2017 06:57:07 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RUSCI8ZXpwSDtjiskYFq3KwEpYMfnw6CUpm5dyg2/ZmMGXLa6V7/znEROJFaczIirGhHSpmS5AjT+UnJFg4rU= X-Received: by 10.25.147.11 with SMTP id v11mr3622457lfd.32.1509371827275; Mon, 30 Oct 2017 06:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.29.198 with HTTP; Mon, 30 Oct 2017 06:57:06 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 30 Oct 2017 08:57:06 -0500 Message-ID: Subject: Re: Documentation prefix notation for a /56 To: Alexandre Petrescu Cc: IPv6 Content-Type: multipart/alternative; boundary="f403045c378699609b055cc4033f" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:57:16 -0000 --f403045c378699609b055cc4033f Content-Type: text/plain; charset="UTF-8" On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hello, > > What documentation prefix notation should I use when writing about a /56 > prefix in an Internet Draft? > > Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long. > > Could I use 2001:db8:XYZU:TW::/56? It does not seem correct to me. > 2001:db8:XYZU:TW00::/56 would be the normal way to denote such a prefix. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045c378699609b055cc4033f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:
=20 =20 =20

Hello,

What documentation prefix notation should I use when writing about a /56 prefix in an Internet Draft?

Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long.

Could I use 2001:db8:XYZU:TW::/56?=C2=A0 It does not seem correct to me.

2001:db8:XYZU:TW00::/56 would be the n= ormal way to denote such a prefix.=C2=A0

--
<= div class=3D"gmail_signature">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045c378699609b055cc4033f-- From nobody Mon Oct 30 06:58:58 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2245C13F9F9 for ; Mon, 30 Oct 2017 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.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 StLtHsux4G-s for ; Mon, 30 Oct 2017 06:58:54 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB09A13F9F2 for ; Mon, 30 Oct 2017 06:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LandisGyr.onmicrosoft.com; s=selector1-landisgyr-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3fTomQYMgvj/K3W1fjcWv7Mt7IKJ9bPhD2R/G728trs=; b=iZLtHZMcC0m0dNsZIGFE7OF9c9YxXrCThnC8ItiMP6DemNoV84pbiJwLdynFi6SmZaLrbetKa45nwS6mMIOWY/IMvhiE/dLzfL35TRsyBsCQLkouL3idMKPe6YcbYDDqFwS4inbXyBGfryg3/R1WpuMVCPAyFd7X1hbOkg0gfNA= Received: from AM0PR0102MB3298.eurprd01.prod.exchangelabs.com (52.133.44.27) by AM0PR0102MB3298.eurprd01.prod.exchangelabs.com (52.133.44.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 13:58:51 +0000 Received: from AM0PR0102MB3298.eurprd01.prod.exchangelabs.com ([fe80::5432:872d:8b4:6d21]) by AM0PR0102MB3298.eurprd01.prod.exchangelabs.com ([fe80::5432:872d:8b4:6d21%13]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 13:58:51 +0000 From: "Turner, Randy" To: 6man WG Subject: RE: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUKL9FGrjP+MUKlM6Xn21u7m6L8apdw Date: Mon, 30 Oct 2017 13:58:50 +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: spf=none (sender IP is ) smtp.mailfrom=Randy.Turner@landisgyr.com; x-originating-ip: [148.80.255.216] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR0102MB3298; 6:ThVAtjrDxIGwIYxevlNSrnebPGqEm0+Xx8EhwJJnDmiKavpQWNaVbmeb6+HF1yrGEEhNFCtV9sU5ZaXoNFtvyZ5EtjiBfWM1Jg9/6YZEx/Xb2r2R/JNMVSt6p68rzjzBQ6zIIxIZbl3gxj/aBdNf/V6DQioI6yM04h60vfKOhgwd1Sfy5D+8eJMiZ3RaHulPkyse/c2MvxmPUJ//xuIHAXZ1/CfB3TJFh9Mc2ZT5SjRMu7vVvRiqj4qlYXMK+fYSFBqigG/cHavmnh9DE551SAhkYbXWWD4O6Y326Up9cyAdjbQFgZuy1fsb1uQQvDCqAFfq1YZBw6MWMyEaD5/gMGpQUyuxdk32ZTvhzkM2I3c=; 5:eX64tcBAQ4c0m9vFbLBeQmL4mcpOSdknzMPHxDaZRdOUCDrdVhIgAuFZgUB1/CNPl4V36oEc/S/m30X38tGXVaaHKh14h091xz9qnAw3fSJn2yfW9TvzPGNgtSGt9H7re/BwWvuROdLC3qcnVZ+FA+HmnAigAy9TkmZcKK4GJoA=; 24:9kd8k3LEpo1CZhRDUf5ni8OARDYn+BL3GeBVcDDBxItemCvU4juju1069UtKxSSc0ulLLHiQwgyTSwn9yOetDHJpNDIZcbMtKrVBcLgIzMk=; 7:gj7jfKfWxS7hd+MbVCsh9rhY/Go0tXTyA1TwXWAW8LmsjLTGUmRGgqYf+7GUPBuN/pPJfEIhnX4fn2kpJr7sl9zjY8/pDwh65qjjSIjGzJchbiqH+YRSaHTIiCCcmw/vh7aI5K3U1wbmoA3jRx+W44eH8wYrdidPOZwQ8tgy8wZzvFaVZM5W7d9CjG/8IXjMV9DOrvAcHL6LgyQZn7KYlY2utbx7v4Lc6UDb72R9GOoPdV2pcSeCVmvhH58OyK/K x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2415e933-d724-446c-c31b-08d51f9e5988 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603199); SRVR:AM0PR0102MB3298; x-ms-traffictypediagnostic: AM0PR0102MB3298: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231020)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM0PR0102MB3298; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM0PR0102MB3298; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(22974007)(199003)(377424004)(189002)(7116003)(53936002)(2906002)(33656002)(86362001)(2420400007)(7736002)(8936002)(10710500007)(72206003)(53366004)(53376002)(101416001)(76176999)(55016002)(50986999)(53386004)(102836003)(74316002)(6246003)(8676002)(54356999)(3280700002)(478600001)(81156014)(81166006)(25786009)(3846002)(6116002)(966005)(68736007)(3660700001)(99286003)(6506006)(790700001)(6436002)(236005)(6916009)(2950100002)(7696004)(229853002)(53546010)(5250100002)(19609705001)(66066001)(9326002)(2900100001)(606006)(4001150100001)(7110500001)(15650500001)(14971765001)(189998001)(5660300001)(97736004)(9686003)(105586002)(54896002)(6306002)(316002)(14454004)(106356001)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0102MB3298; H:AM0PR0102MB3298.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: landisgyr.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR0102MB3298C9D72FE78B297A2264A280590AM0PR0102MB3298_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2415e933-d724-446c-c31b-08d51f9e5988 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 13:58:50.9128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0102MB3298 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 13:58:57 -0000 --_000_AM0PR0102MB3298C9D72FE78B297A2264A280590AM0PR0102MB3298_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3V5cywNCg0KICAgSG93IHNob3VsZCByZWFkZXJzIG9mIDY0MzRiaXMgcmVjb25jaWxlIHRo ZSBmb2xsb3dpbmcgdHdvIHN0YXRlbWVudHMgZnJvbSBzZWN0aW9uIDUuNCA/DQoNCiAgIE5laWdo Ym9yIERpc2NvdmVyeSBpcyBkZWZpbmVkIGluIFtSRkM0ODYxXTsgdGhlIGRlZmluaXRpb24gd2Fz DQogICB1cGRhdGVkIGJ5IFtSRkM1OTQyXS4gIE5laWdoYm9yIERpc2NvdmVyeSBTSE9VTEQgYmUg c3VwcG9ydGVkLg0KDQotLQ0KICAgQWxsIG5vZGVzIE1VU1Qgc3VwcG9ydCB0aGUgc2VuZGluZyBh bmQgcmVjZWl2aW5nIG9mIE5laWdoYm9yDQogICBTb2xpY2l0YXRpb24gKE5TKSBhbmQgTmVpZ2hi b3IgQWR2ZXJ0aXNlbWVudCAoTkEpIG1lc3NhZ2VzLiAgTlMgYW5kDQogICBOQSBtZXNzYWdlcyBh cmUgcmVxdWlyZWQgZm9yIER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbiAoREFEKS4NCg0KVGhh bmtzLA0KUmFuZHkNCg0KDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVGltb3RoeSBXaW50ZXJzDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzAs IDIwMTcgOTo0MyBBTQ0KVG86IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBVcGRh dGVzIHRvIFJGQzY0MzQNCg0KV2UgaGF2ZSBwb3N0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIDY0 MzRiaXMsIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHNpbmNlIFByYWd1ZToNCg0KICAqICAg VGV4dCBvbiBFSCBwcm9jZXNzaW5nDQogICogICBOb3RlZCB0aGF0IFJGQzQxOTEgaXMgYSBNVVNU LCBidXQgYSBTSE9VTEQgZm9yIFR5cGUgQyBub2RlDQogICogICBVcGRhdGVkIFJGQyByZWZlcmVu Y2VzICg4MjAwLCA4MjAxLCA4MjIxLCA4MjQ3KQ0KICAqICAgQWRkZWQgbm90ZSBvbiBSRkMgNzc3 MiBmb3IgcG93ZXIgY29uc3VtcHRpb24NCiAgKiAgIEFkZGVkIOKAmFdoeSAvNjQ/4oCZIHJlZmVy ZW5jZTsgUkZDIDc0MjENCiAgKiAgIFJlbW92ZWQganVtYm9ncmFtIHRleHQNCiAgKiAgIEFkZGVk IHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dA0KICAqICAgRm9yIDNHUFAsIGFkZGVkIOKAmHNuYXBzaG904oCZIGNvbW1lbnQgb24gUkZDNzA2 Ng0KICAqICAgQWRkZWQgUkZDODAyOCBhcyBhIFNIT1VMRCAoZm9yIFNlY3Rpb24gNS41IGZyb20g UkZDIDY3MjQpDQogICogICBSZW1vdmVkIEFUTSBvdmVyIElQdjYNCiAgKiAgIEFkZGVkIHJlZmVy ZW5jZSB0byBSRkM4MDY0DQogICogICBBZGRlZCBNVVNUIGZvciBCQ1AgMTk4LCBhbmQgcmVmIHRv IGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzDQogICogICBBZGRlZCB0ZXh0IG9uIGF2b2lk aW5nIDEyODAgTVRVIGZvciBVRFAgKGluYy4gRE5TKSB0cmFmZmljDQpXZSdsbCBiZSBzZW5kaW5n IHNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMgdG8gdGhlIGxpc3QgbGF0ZXIgdGhpcyB3ZWVrIHRv IGhvcGVmdWxseSBnZXQgdGhpcyBkb2N1bWVudCByZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0 IGNhbGwuDQoNCn5UaW0sIFRpbSBhbmQgSm9obg0KDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQg bWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBPY3QgMzAsIDIwMTcgYXQg OTozNiBBTQ0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlz LTAyLnR4dA0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGll dGYub3JnPg0KQ2M6IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQoNCg0KDQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJ UHY2IE1haW50ZW5hbmNlIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAg ICA6IElQdjYgTm9kZSBSZXF1aXJlbWVudHMNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogVGlt IENob3duDQogICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4gTG91Z2huZXkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgVGltb3RoeSBXaW50ZXJzDQogICAgICAgIEZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMi50eHQNCiAgICAgICAgUGFnZXMgICAg ICAgICAgIDogNDANCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMC0zMA0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9k ZXMuICBJdCBpcyBleHBlY3RlZA0KICAgdGhhdCBJUHY2IHdpbGwgYmUgZGVwbG95ZWQgaW4gYSB3 aWRlIHJhbmdlIG9mIGRldmljZXMgYW5kIHNpdHVhdGlvbnMuDQogICBTcGVjaWZ5aW5nIHRoZSBy ZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMgYWxsb3dzIElQdjYgdG8gZnVuY3Rpb24NCiAgIHdl bGwgYW5kIGludGVyb3BlcmF0ZSBpbiBhIGxhcmdlIG51bWJlciBvZiBzaXR1YXRpb25zIGFuZA0K ICAgZGVwbG95bWVudHMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA2NDM0LCBh bmQgaW4gdHVybiBSRkMgNDI5NC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDINCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9y Zz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLQ0KDQpOb3cgb2ZmZXJpbmcgdGVz dGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNETiBzd2l0 Y2ggdGVzdCBiZWQuIExlYXJuIG1vcmUgdG9kYXkgaHR0cDovL2JpdC5seS9TRE5fSU9MUFINCg== --_000_AM0PR0102MB3298C9D72FE78B297A2264A280590AM0PR0102MB3298_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJ cGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTYwNjExMTU3MzsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTc2MjUxNzA4NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5IaSBHdXlzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEhvdyBzaG91bGQgcmVhZGVycyBvZiA2NDM0YmlzIHJlY29u Y2lsZSB0aGUgZm9sbG93aW5nIHR3byBzdGF0ZW1lbnRzIGZyb20gc2VjdGlvbiA1LjQgPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IE5laWdo Ym9yIERpc2NvdmVyeSBpcyBkZWZpbmVkIGluIFtSRkM0ODYxXTsgdGhlIGRlZmluaXRpb24gd2Fz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB1cGRhdGVkIGJ5IFtSRkM1OTQyXS4mbmJz cDsgTmVpZ2hib3IgRGlzY292ZXJ5IFNIT1VMRCBiZSBzdXBwb3J0ZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgQWxsIG5vZGVzIE1VU1Qgc3VwcG9ydCB0aGUgc2VuZGluZyBhbmQgcmVjZWl2aW5nIG9m IE5laWdoYm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBTb2xpY2l0YXRpb24gKE5T KSBhbmQgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudCAoTkEpIG1lc3NhZ2VzLiZuYnNwOyBOUyBhbmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IE5BIG1lc3NhZ2VzIGFyZSByZXF1aXJlZCBm b3IgRHVwbGljYXRlIEFkZHJlc3MgRGV0ZWN0aW9uIChEQUQpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SYW5keTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGltb3RoeSBXaW50ZXJzPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyA5OjQzIEFNPGJyPg0KPGI+VG86PC9i PiA2bWFuIFdHICZsdDtpcHY2QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBVcGRh dGVzIHRvIFJGQzY0MzQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBo YXZlIHBvc3RlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgNjQzNGJpcywgd2l0aCB0aGUgZm9sbG93 aW5nIGNoYW5nZXMgc2luY2UgUHJhZ3VlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NClRleHQgb24gRUggcHJvY2Vzc2luZyZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCk5vdGVkIHRoYXQg UkZDNDE5MSBpcyBhIE1VU1QsIGJ1dCBhIFNIT1VMRCBmb3IgVHlwZSBDIG5vZGU8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpV cGRhdGVkIFJGQyByZWZlcmVuY2VzICg4MjAwLCA4MjAxLCA4MjIxLCA4MjQ3KTxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkFk ZGVkIG5vdGUgb24gUkZDIDc3NzIgZm9yIHBvd2VyIGNvbnN1bXB0aW9uPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQg 4oCYV2h5IC82ND/igJkgcmVmZXJlbmNlOyBSRkMgNzQyMTxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJlbW92ZWQganVtYm9n cmFtIHRleHQmbmJzcDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBZGRlZCByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi12Nm9w cy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Q8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpGb3IgM0dQUCwgYWRkZWQg4oCY c25hcHNob3TigJkgY29tbWVudCBvbiBSRkM3MDY2PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgUkZDODAyOCBhcyBh IFNIT1VMRCAoZm9yIFNlY3Rpb24gNS41IGZyb20gUkZDIDY3MjQpPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUmVtb3ZlZCBB VE0gb3ZlciBJUHY2PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgcmVmZXJlbmNlIHRvIFJGQzgwNjQ8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpB ZGRlZCBNVVNUIGZvciBCQ1AgMTk4LCBhbmQgcmVmIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0 ci1yZXFzPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KQWRkZWQgdGV4dCBvbiBhdm9pZGluZyAxMjgwIE1UVSBmb3IgVURQIChp bmMuIEROUykgdHJhZmZpYzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2UnbGwgYmUgc2VuZGluZyBzb21lIGFkZGl0aW9uYWwgcXVlc3Rp b25zIHRvIHRoZSBsaXN0IGxhdGVyIHRoaXMgd2VlayB0byBob3BlZnVsbHkgZ2V0IHRoaXMgZG9j dW1lbnQgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+VGltLCBUaW0gYW5kIEpvaG48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IE1vbiwgT2N0IDMwLCAyMDE3IGF0IDk6MzYgQU08 YnI+DQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIu dHh0PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1h aWx0bzppcHY2QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogSVB2NiBOb2RlIFJlcXVpcmVtZW50czxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogVGltIENob3duPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEpvaG4gTG91Z2huZXk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgVGltb3RoeSBXaW50ZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVu YW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQt YmlzLTAyLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA0MDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgOiAyMDE3LTEwLTMwPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1Ro aXMgZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMuJm5ic3A7IEl0 IGlzIGV4cGVjdGVkPGJyPg0KJm5ic3A7ICZuYnNwO3RoYXQgSVB2NiB3aWxsIGJlIGRlcGxveWVk IGluIGEgd2lkZSByYW5nZSBvZiBkZXZpY2VzIGFuZCBzaXR1YXRpb25zLjxicj4NCiZuYnNwOyAm bmJzcDtTcGVjaWZ5aW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMgYWxsb3dzIElQ djYgdG8gZnVuY3Rpb248YnI+DQombmJzcDsgJm5ic3A7d2VsbCBhbmQgaW50ZXJvcGVyYXRlIGlu IGEgbGFyZ2UgbnVtYmVyIG9mIHNpdHVhdGlvbnMgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO2RlcGxv eW1lbnRzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBS RkMgNjQzNCwgYW5kIGluIHR1cm4gUkZDIDQyOTQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQt YmlzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy88L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0 MzQtYmlzLTAyPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZj NjQzNC1iaXMtMDI8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLXJmYzY0 MzQtYmlzLTAyPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5v cmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvPC9hPjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSUVURiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2NjwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5Ob3cgb2ZmZXJp bmcgdGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNE TiBzd2l0Y2ggdGVzdCBiZWQuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPkxlYXJuIG1vcmUgdG9k YXkNCjxhIGhyZWY9Imh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL2JpdC5seS9TRE5fSU9MUFI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR0102MB3298C9D72FE78B297A2264A280590AM0PR0102MB3298_-- From nobody Mon Oct 30 07:06:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B379413F9F3 for ; Mon, 30 Oct 2017 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX16ipNrT_pl for ; Mon, 30 Oct 2017 07:06:38 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4589513F444 for ; Mon, 30 Oct 2017 07:06:38 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o187so16246078qke.7 for ; Mon, 30 Oct 2017 07:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xySWxliY1sxB9EAtDWwncRdCxapI1dZ82joIiHw8094=; b=EWjHv1fSk62ZZuJXtrommhy9gnELrZxGnRq1nHNxS6RxYBe3+TcgjEiSMZxSMD0xYH lSZpnhuusxrneu0mis+B2XDIVQEldxq6EDYCDJ/xT+obTt/iY6hgYZP7nhs9H0bih+Av BA+Xpo45rBERxG9A5ggNdDCokdCf9ATC5DhRU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xySWxliY1sxB9EAtDWwncRdCxapI1dZ82joIiHw8094=; b=ClZbiBWPVIeFgOpcLXsoc3Dkgz7T4NN3KihV9oUNZlhOzlStqjkkuvNzxElIMlwIZz 65W2ExP5cYP4pK4/zRNvut7v5xinQvUzxa/Gy/mD7RXmLe/FALMB2N7E8fjrKCgrTmuK HogOijfSBzfBLPlog7nbHR24ay29tFuOt+b0UnAsHhBgrzdNx4v2pDb4isxbH5iNAcGq ir0bALwNzbYpnv61c5AuwnoqRxWgIWU1RepUShI/eR8cwj8R/V+qyPVMG5oOep9Yb2qf NQBjdbVJeUguRwckkKTWTqkatWluEvaRyW16q1HsEubuDLictEcnu2ufb/Uirw4bwHSK SY0A== X-Gm-Message-State: AMCzsaWuV5A69QpbQpjnr5bfI20uAR/GZnUlL4TGbn9fQ2qLA1lFbfsU UssTyiys6KPTjwQwRjRl1b3YVg4ApfbYpkkMVShbEg== X-Google-Smtp-Source: ABhQp+TcxGcDwkul5a8Dy7hvjkftetQH3rpGzYx4voOB69kPiDX80Y7KPLTEzeSWY6Lfxg/1UQSwoRGf/gBibF7+UyQ= X-Received: by 10.55.60.129 with SMTP id j123mr14026923qka.121.1509372397297; Mon, 30 Oct 2017 07:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.8 with HTTP; Mon, 30 Oct 2017 07:06:16 -0700 (PDT) In-Reply-To: References: From: Timothy Winters Date: Mon, 30 Oct 2017 10:06:16 -0400 Message-ID: Subject: Re: Updates to RFC6434 To: "Turner, Randy" Cc: 6man WG Content-Type: multipart/alternative; boundary="001a114a207a934389055cc42578" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:06:40 -0000 --001a114a207a934389055cc42578 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Randy, The original RFC 6434 has this same text. In this case it's calling out for the purpose of DAD that you have to support sending NA and NS as defined in RFC 4861. The rest of the 4861 (Router Discovery, Address Resolution, etc...) are covered under the SHOULD at the top of the Section 5.4. ~Tim On Mon, Oct 30, 2017 at 9:58 AM, Turner, Randy wrote: > Hi Guys, > > > > How should readers of 6434bis reconcile the following two statements > from section 5.4 ? > > > > Neighbor Discovery is defined in [RFC4861]; the definition was > > updated by [RFC5942]. Neighbor Discovery SHOULD be supported. > > > > -- > > All nodes MUST support the sending and receiving of Neighbor > > Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and > > NA messages are required for Duplicate Address Detection (DAD). > > > > Thanks, > > Randy > > > > > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Timothy Winter= s > *Sent:* Monday, October 30, 2017 9:43 AM > *To:* 6man WG > *Subject:* Updates to RFC6434 > > > > We have posted an updated version of 6434bis, with the following changes > since Prague: > > - Text on EH processing > - Noted that RFC4191 is a MUST, but a SHOULD for Type C node > - Updated RFC references (8200, 8201, 8221, 8247) > - Added note on RFC 7772 for power consumption > - Added =E2=80=98Why /64?=E2=80=99 reference; RFC 7421 > - Removed jumbogram text > - Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host > - For 3GPP, added =E2=80=98snapshot=E2=80=99 comment on RFC7066 > - Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724) > - Removed ATM over IPv6 > - Added reference to RFC8064 > - Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs > - Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic > > We'll be sending some additional questions to the list later this week to > hopefully get this document ready for working group last call. > > > > ~Tim, Tim and John > > > > > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 30, 2017 at 9:36 AM > Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > Title : IPv6 Node Requirements > Authors : Tim Chown > John Loughney > Timothy Winters > Filename : draft-ietf-6man-rfc6434-bis-02.txt > Pages : 40 > Date : 2017-10-30 > > Abstract: > This document defines requirements for IPv6 nodes. It is expected > that IPv6 will be deployed in a wide range of devices and situations. > Specifying the requirements for IPv6 nodes allows IPv6 to function > well and interoperate in a large number of situations and > deployments. > > This document obsoletes RFC 6434, and in turn RFC 4294. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc6434-bis-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/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > > -- > > Now offering testing for SDN applications and controllers in our SDN > switch test bed. Learn more today http://bit.ly/SDN_IOLPR > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a114a207a934389055cc42578 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Randy,

The original RFC 6434 has thi= s same text. =C2=A0 In this case it's calling out for the purpose of DA= D that you have to support sending NA and NS as defined in RFC 4861. =C2=A0= The rest of the 4861 (Router Discovery, Address Resolution, etc...) are co= vered under the SHOULD at the top of the Section 5.4.

<= div>~Tim

On Mon, Oct 30, 2017 at 9:58 AM, Turner, Randy <Randy.Turner@l= andisgyr.com> wrote:

Hi Guys,

=C2=A0

=C2=A0=C2=A0 How should readers of 64= 34bis reconcile the following two statements from section 5.4 ?

=C2=A0

=C2=A0=C2=A0 Neighbor Discovery is de= fined in [RFC4861]; the definition was

=C2=A0=C2=A0 updated by [RFC5942].=C2= =A0 Neighbor Discovery SHOULD be supported.

=C2=A0

--

=C2=A0=C2=A0 All nodes MUST support t= he sending and receiving of Neighbor

=C2=A0=C2=A0 Solicitation (NS) and Ne= ighbor Advertisement (NA) messages.=C2=A0 NS and

=C2=A0=C2=A0 NA messages are required= for Duplicate Address Detection (DAD).

=C2=A0

Thanks,

Randy

=C2=A0

=C2=A0

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Timothy Winters
Sent: Monday, October 30, 2017 9:43 AM
To: 6man WG <i= pv6@ietf.org>
Subject: Updates to RFC6434

=C2=A0

We have posted an updated version of 6434bis, with t= he following changes since Prague:

  • Text on EH processing=C2=A0
  • Noted that RFC4191 is a MUST, but a SHOULD for Type C node
  • Updated RFC references (8200, 8201, 8221, 8247)
  • Added note on RFC 7772 for power consumption
  • Added =E2=80=98Why /64?=E2=80=99 reference; RFC 7421
  • Removed jumbogram text=C2=A0
  • Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host=
  • For 3GPP, added =E2=80=98snapshot=E2=80=99 comment on RFC7066=
  • Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724)
  • Removed ATM over IPv6
  • Added reference to RFC8064
  • Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs<= /u>
  • Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic

We'll be sending some additional questions to th= e list later this week to hopefully get this document ready for working gro= up last call.

=C2=A0

~Tim, Tim and John

=C2=A0

=C2=A0

=C2=A0

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: i-d-announce= @ietf.org
Cc: ipv6@ietf.org


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Node Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tim = Chown
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Loughney
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Timothy Winters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6man-rfc6434-bis-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 40
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0This document defines requirements for IPv6 nodes.=C2=A0 It is= expected
=C2=A0 =C2=A0that IPv6 will be deployed in a wide range of devices and situ= ations.
=C2=A0 =C2=A0Specifying the requirements for IPv6 nodes allows IPv6 to func= tion
=C2=A0 =C2=A0well and interoperate in a large number of situations and
=C2=A0 =C2=A0deployments.

=C2=A0 =C2=A0This document obsoletes RFC 6434, and in turn RFC 4294.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6= 434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-= 02
https://datatracker.ietf.org/doc/html/draft-ie= tf-6man-rfc6434-bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6= man-rfc6434-bis-02


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

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

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



=C2=A0

--

No= w offering testing for SDN applications and controllers in our SDN switch t= est bed.=C2=A0Learn more today http://bit.ly/SDN_IOL= PR


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




--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a114a207a934389055cc42578-- From nobody Mon Oct 30 07:37:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1651613F89B for ; Mon, 30 Oct 2017 07:37:14 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e2EGc59hU_j for ; Mon, 30 Oct 2017 07:37:12 -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 39C51139F18 for ; Mon, 30 Oct 2017 07:37:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BDA59200E3 for ; Mon, 30 Oct 2017 10:37:57 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2384781694 for ; Mon, 30 Oct 2017 10:37:11 -0400 (EDT) From: Michael Richardson To: IPv6 Subject: Re: Documentation prefix notation for a /56 In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 14:37:14 -0000 --=-=-= Content-Type: text/plain David Farmer wrote: > On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu > wrote: > Hello, > What documentation prefix notation should I use when writing about a /56 > prefix in an Internet Draft? > Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long. Of course, XYZU and TWQR could be zeros. so you can write 2001:db8::/56, but that might confuse some people. > Could I use 2001:db8:XYZU:TW::/56? It does not seem correct to me. > 2001:db8:XYZU:TW00::/56 would be the normal way to denote such a prefix. I for one, would like to have four or five more documentation prefixes in IPv6, with very different initial four digits to make to easier for the cases where we are talking networks under different administrative control. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln3ORYACgkQgItw+93Q 3WVWXwgAwxHUixMMPrn0p2StSZ42+I85kLXgHyG+Ijf0Fel3IRnRBkKsXu9J1u57 nIrSJL/MGrpPm4XZof6QQ113Zcde+on3DiUVncI3Ka54+gzYGqDO9qCXVyOQYDI4 zjmF7p4+GvsT7S3tvZ4/YAUV97NRSY4sNgs2SEpRI5It2eX1HxFP3a7QVFbROXMX MCwvCHPhGFE2Z2hX0wm8ZQcGZYdHBIx1f9myEMZ8pFqYWoLNNq13IP3IXsLk7OW3 DLVBSdXRr8TjnSUC5pTp1ZMLBrIH+JL3DpuI7a+hofF65mFcyfjnvR1PqqKerOl3 EhRMAl9RYcNz+B++Sc1TFi6p03pkdw== =q3dL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 30 08:28:46 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF5E13FE55 for ; Mon, 30 Oct 2017 08:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWiO3nHuVf4Z for ; Mon, 30 Oct 2017 08:28:38 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190C313FD7B for ; Mon, 30 Oct 2017 08:25:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v9UFPCdH078430; Mon, 30 Oct 2017 16:25:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3190A205714; Mon, 30 Oct 2017 16:25:12 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E4842056F1; Mon, 30 Oct 2017 16:25:12 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v9UFPBtN007598; Mon, 30 Oct 2017 16:25:11 +0100 Subject: Re: Documentation prefix notation for a /56 To: David Farmer Cc: IPv6 References: From: Alexandre Petrescu Message-ID: Date: Mon, 30 Oct 2017 16:25:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:28:45 -0000 Le 30/10/2017 à 14:57, David Farmer a écrit : > > > On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu > > wrote: > > Hello, > > What documentation prefix notation should I use when writing about a > /56 prefix in an Internet Draft? > > Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long. > > Could I use 2001:db8:XYZU:TW::/56?  It does not seem correct to me. > > 2001:db8:XYZU:TW00::/56 would be the normal way to denote such a prefix. Would 2001:db8:XYZU:TWFF::/56 also be normal? Alex > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE        Phone: 612-626-0815 > Minneapolis, MN 55414-3029   Cell: 612-812-9952 > =============================================== From nobody Mon Oct 30 11:02:06 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3608A98ED for ; Mon, 30 Oct 2017 11:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4dXlCVc_o8d for ; Mon, 30 Oct 2017 11:01:52 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 89CF898F2 for ; Mon, 30 Oct 2017 11:01:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id DC2F756F for ; Mon, 30 Oct 2017 18:01:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VkwAyoYIRbw for ; Mon, 30 Oct 2017 13:01:50 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 83E1C57C for ; Mon, 30 Oct 2017 13:01:50 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id 75so4179247lfx.15 for ; Mon, 30 Oct 2017 11:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c6mMDThETIt9jpdbCjvYWgBaXlS1SoM/mJ4kvM/zxcQ=; b=Sa1zSGSpsy+hgrs3g5nGHAKxrYXG+BF9XWEHWFOHgQAsL+dWATMaXMSseG/y8HXTx5 Z80+guIX0bCPMtqpqBMv68xU65FHTksMkuP8lAAhE5aoOQWW7+auqDCw9tYGLoQZQDzd 6e/3eVgvFbNiH2n0Aj4Rf0VR16j1gY/C70J4R1XUTXuOaAIKuYcg4W5VDaVawMRPngA2 OIZvidrkSB2uE6wiyOBwWJCQLLNwKzfEUhI7p/u5KLPtGeo/hk0Gx/FZv2dMKW3lDn8/ zT5eOCCSVV6IefNpbIUIpHpVMn6iT//efktbzwyXwtFeJYJWXFQMfRuyT7ztBmWetbr8 KUug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c6mMDThETIt9jpdbCjvYWgBaXlS1SoM/mJ4kvM/zxcQ=; b=ttzkVQcoseQ7aXc52VzblRl9VgSSmfnJxj+IAZyIUhBvQ0S6Rl5V+bF/mAqV0gKsqd +Up1vCC8AxehnOiPF8bqA2hSbhcSeUdtSDM/BfCTJu9kCFBtqxgBhz/VcyN/0D3Nspvo iPMjFgG6hgCGsNbOwRu10zVrD6oK2dOV/T6gGcACp/cmRaXvd30d2LXV6KdUjnJosZJb cKKiq0Npwnq+Dl3p+7mL0VXYJ7Gwr9GGzl5w4UgxScWyucYZ5tV4C+4xQmVlFLadk9Y4 GffLz9H9UOsK18yBrwRPlVkV1g5nvDDhhF18V0OI/UuJDe9YCN4ZHTczJ09GK88K4BBA zdgw== X-Gm-Message-State: AMCzsaUGqPunFQp/W11ZBZv569ZOD5BnyhWPqwq/AsKSpc5UZWI/LfnW Xo02QidA7qu7t+BxmecWGfMpmCLxBvCM8UK0uWoNGUwLe16iuaDiEHVw2n6TlLBN4lwneYFCI7j 3unMd5bq9z0R09RkgwSEel0sC X-Received: by 10.46.58.2 with SMTP id h2mr3861769lja.132.1509386509124; Mon, 30 Oct 2017 11:01:49 -0700 (PDT) X-Google-Smtp-Source: ABhQp+QMCt7mTYQCP4nL9uJAXxfCzBi5veaX+xHwoYPrfKOZDW1YDhddHvZiToENiwphysHYeapzr6opLoi5scCP5a8= X-Received: by 10.46.58.2 with SMTP id h2mr3861766lja.132.1509386508901; Mon, 30 Oct 2017 11:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.29.198 with HTTP; Mon, 30 Oct 2017 11:01:48 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Mon, 30 Oct 2017 13:01:48 -0500 Message-ID: Subject: Re: Documentation prefix notation for a /56 To: Alexandre Petrescu Cc: IPv6 Content-Type: multipart/alternative; boundary="089e082f45f4b13166055cc76e7d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 18:01:55 -0000 --089e082f45f4b13166055cc76e7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2017 at 10:25 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > Le 30/10/2017 =C3=A0 14:57, David Farmer a =C3=A9crit : > >> >> >> On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu < >> alexandre.petrescu@gmail.com > >> wrote: >> >> Hello, >> >> What documentation prefix notation should I use when writing about a >> /56 prefix in an Internet Draft? >> >> Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too long. >> >> Could I use 2001:db8:XYZU:TW::/56? It does not seem correct to me. >> >> 2001:db8:XYZU:TW00::/56 would be the normal way to denote such a prefix. >> > > Would 2001:db8:XYZU:TWFF::/56 also be normal? > That is not the normalized representation for a prefix, the normalized representation is to have zeros for all the bit right of the prefix boundary. --=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --089e082f45f4b13166055cc76e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 30, 2017 at 10:25 AM, Alexandre Petrescu = <alexa= ndre.petrescu@gmail.com> wrote:


Le 30/10/2017 =C3=A0 14:57, David Farmer a =C3=A9crit=C2=A0:


On Mon, Oct 30, 2017 at 7:14 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com= <mailto:alexandre.petrescu@gmail.com>> wrote:

=C2=A0 =C2=A0 Hello,

=C2=A0 =C2=A0 What documentation prefix notation should I use when writing = about a
=C2=A0 =C2=A0 /56 prefix in an Internet Draft?

=C2=A0 =C2=A0 Currently I use 2001:db8:XYZU:TWQR::/56, but it seems too lon= g.

=C2=A0 =C2=A0 Could I use 2001:db8:XYZU:TW::/56?=C2=A0 It does not seem cor= rect to me.

2001:db8:XYZU:TW00::/56 would be the normal way to denote such a prefix.

Would 2001:db8:XYZU:TWFF::/56 also be normal?

That is not the normalized representation for a prefix, the normaliz= ed representation is to have zeros for all the bit right of the prefix boun= dary.=C2=A0


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e082f45f4b13166055cc76e7d-- From nobody Mon Oct 30 11:14:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC8613F9EC for ; Mon, 30 Oct 2017 11:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HodAqb0glBlb for ; Mon, 30 Oct 2017 11:14:20 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::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 7DF4A13F5A8 for ; Mon, 30 Oct 2017 11:14:15 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id s75so12335943pgs.0 for ; Mon, 30 Oct 2017 11:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IjAmaEtol7wEBb3AaZLGefmHE81swXw/Bo+0GR0FRHE=; b=T3syQd4yW1LWXJUehkfu87iFDbuSl9HChqiGcDSV3MVYLQCiaC1OR0mg/7TJPaegLo prwDb2WU6hFsmMpTkwzUzTnwmDRw3TN19kyD7h4GpV9pu87zh6iSU6AhqKYpVM7IpGG1 yr5QbGcO7Mm350scI/9GQD5ycE8UZIg6JRkO/nbTCypoEAGEPNawtv4xBULw427iclQ3 VFj0l5aDpa5UrYZlFmBqvxBoe0VRMxInDUhnPfvnai3KWCXr7XswYsosZErOmKTdbaJm MhLq3YCgOQDOZLsAuClkzZrZJTwHRikobwSspoT7CpOOby68CeW6NmXx1ZyebMYDA7qM QA1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IjAmaEtol7wEBb3AaZLGefmHE81swXw/Bo+0GR0FRHE=; b=Jz3NA2SaHN6olTmpbqQw0eCbFl8FhRNBJMimhyuk/LIsg8WweQTG7uP0TrX0NSVI7r bFWCdlHGoOj30nbT+fFfKAzP7k0/xJ/vcAL6bQ9j7r5n+J7Mm2abtlShjciy9gKg7j37 nJrrw4W1yiBc5ROGewgPWtBlcn/zhhL0fBRho36rU/G6NDqpMt0v84q7b/J2UondubwL Z5563FSl6jRa3pC9cS/GfnKT+WfM3qbDuN+sV6po+Dx5aGpuD0IXaIEgiAL0J47nEjUG D3h932s+147yzXZtVVfcS1/NCLQ/zAfAHEmGAu4g2DopzHCGJcuhecdNrg18EAfBTwGl Q43A== X-Gm-Message-State: AMCzsaWFi09nXmHTLRxJ93OZKf/R/r0FT4wJXJre2TJDGn4viGf6/weI OJt/pUxIgOaH5gPx60to720= X-Google-Smtp-Source: ABhQp+SHuabEmHebSEh48ZWKIQTm9zL0eV0IwdXv4HHBHfVHwycv5cZffzTxPPCwZfdI2KmzCz/ndg== X-Received: by 10.101.81.198 with SMTP id i6mr8504079pgq.391.1509387255162; Mon, 30 Oct 2017 11:14:15 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id m1sm28526392pfk.54.2017.10.30.11.14.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 11:14:14 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_41896230-627E-437B-A45D-DFAB7BE6CA15"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Documentation prefix notation for a /56 Date: Mon, 30 Oct 2017 11:14:16 -0700 In-Reply-To: Cc: Bob Hinden , Alexandre Petrescu , IPv6 List To: David Farmer References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 18:14:21 -0000 --Apple-Mail=_41896230-627E-437B-A45D-DFAB7BE6CA15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >=20 >=20 > 2001:db8:XYZU:TW00::/56 would be the normal way to denote such a = prefix. >=20 > Would 2001:db8:XYZU:TWFF::/56 also be normal? >=20 > That is not the normalized representation for a prefix, the normalized = representation is to have zeros for all the bit right of the prefix = boundary. >=20 I agree, that would be good for an example for a /64. For /56 , as = noted above, something like: 2001:db8:XYZU:TW00::/56 (where XYZU TW are actual hex digits) Bob --Apple-Mail=_41896230-627E-437B-A45D-DFAB7BE6CA15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZ92v4AAoJEK7rdBF357uouQQH/1lt/3heyIdLwPay2A4TAxNC zJpGqQ6zv7opjTtUVB+TSL0KHMeD506OvoMJoVi8NcTOsFWkFiwSXhMjEvkDO3EO E4S+6Fu7epX6Ycbg7KLn2w5ioU95GUtjT6DClnUP8DEpC6kFL7ZJ9VmFy0M9a1TV +lpkicQTDHrbNrCUKALDh52d6Mm1o9h1Wr01jOQ/Z9UWxXKeZeZIzhmJk5hfNgpA RTr4ULAXSw8UEoBoNhMVoYngX152Y6wab7ir5YJt9qIsyIAn6DIq/xIkRkmOIq3U 9OdSqpHV/G9HTc05OHoPL1u4syk+fvfdlb9ffI4GC0h9wdNcV+8x/hojPkWoO/U= =moIE -----END PGP SIGNATURE----- --Apple-Mail=_41896230-627E-437B-A45D-DFAB7BE6CA15-- From nobody Mon Oct 30 12:29:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596A13F54A for ; Mon, 30 Oct 2017 12:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23a36qXgjaI8 for ; Mon, 30 Oct 2017 12:29:41 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E946D13836B for ; Mon, 30 Oct 2017 12:29:40 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id s75so12514044pgs.0 for ; Mon, 30 Oct 2017 12:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3jwrdH/lcEcepNHzvubQ7DdFl/xfLM4bfqZoFOdfJzI=; b=ZqkDn+dgAJu6PBb5UKtTJVFgw9GOMElmEXEeCH3TxZhFitltTioZQDN449e/4xIgBj 9Uk/blQldmagHo9B50Q/olOEH8tiR0tAYtv/EiOM8ogqpMg+X0THVBA13bod+/quWpV+ HFnSkqurXVoFsW8cT/CPggKq2KV8ZVk4cPR3IiKL+wjZV67fmVH+3QIB5Y1JVbZvn1uU s8wFFi/x2M4gllZSoc/p0n6OthTvgmPIrWLEAN/MaIReDNPPqaPYloI2qL+elDrJ+zDf ewDmomqCTABtraFDpNlEM5bbfM8+FGjaikrVUDAVoCTNSkH7iPafe9VZl8c8hviT4pGe 9k3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3jwrdH/lcEcepNHzvubQ7DdFl/xfLM4bfqZoFOdfJzI=; b=iZ41h22DAv3P3oHKyrOol7WlEPzhu/fBkCt+Vei4Rk/9i3UrGgbtFkQJ3Z5CnrnXNH 957DvMxfpNX0NUv8U4K9rSkTxfdjdTeBfyImFkyrtA+E5cmC2NjZYXwl9OBAwsJj+Jim fzCV6szuRgBtW2onMw5Jtxikx10Qlxutoe+R5hGLGZA5zpOqXFkbbzd9o5ydT7PAUc8r ooH6ZQcquVCVENjaiiyi9yflUWOv4dkJ5gOzky5xSwOjCIIwwYlWr2L/GAv4CV4LJ1B7 MR6v58MqVx4wfVEoKG4kbkQis8Uil6HZeneyAQL17LBKTxN74+FHMaGXQjc5521gR7qz NXRA== X-Gm-Message-State: AMCzsaXRe8p36eyUJVLhdtMan7jMWOMLAe/UE09Z5lPXgaD1V7Eh/241 IAZICZGm6FzSHLPcuWbwPkTLaw== X-Google-Smtp-Source: ABhQp+SG1itJkyDCTPylb2XQm7bE8vy44hJFcOA/hEQ0Uu/QQamFUwB7GfJnt0xWP7wcmPqAVdGZcw== X-Received: by 10.101.67.196 with SMTP id n4mr8406425pgp.395.1509391779904; Mon, 30 Oct 2017 12:29:39 -0700 (PDT) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o22sm30832781pfi.85.2017.10.30.12.29.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 12:29:38 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt To: 6man References: <150937060401.3306.16675157648974156910@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 31 Oct 2017 08:29:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150937060401.3306.16675157648974156910@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:29:42 -0000 Looks good. Three small points: > 5.3. Protecting a node from excessive EH options ... > A host MAY disallow unknown options in destination options or hob-by- > hop options. This should be configurable where the default is to > accept unknown options and process them per RFC2460. If a packet > with unknown options is received and the host is configured to > disallow them, then the packet should be silently discarded. Not sure why this still refers to 2460. > 5.9. Default Router Preferences and More-Specific Routes - RFC 4191 > > "Default Router Preferences and More-Specific Routes" [RFC4191] > provides support for nodes attached to multiple (different) networks, > each providing routers that advertise themselves as default routers > via Router Advertisements. In some scenarios, one router may provide > connectivity to destinations the other router does not, and choosing > the "wrong" default router can result in reachability failures. In > order to resolve this scenario IPv6 Nodes MUST implement [RFC4191] > and SHOULD implement Type C host role. I suggest that the last phrase should clarify that "Type C" is defined in RFC 4191, because as written that is not obvious. Are we sure that draft-ietf-v6ops-ipv6rtr-reqs is an Informative reference? Regards Brian From nobody Mon Oct 30 12:37:19 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389F113F954 for ; Mon, 30 Oct 2017 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ-6Ek3s9Hzt for ; Mon, 30 Oct 2017 12:37:14 -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 CBBFF13F639 for ; Mon, 30 Oct 2017 12:37:14 -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 v9UJbDGS017646; Mon, 30 Oct 2017 12:37:14 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9UJbCDA017635 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Oct 2017 12:37:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Oct 2017 12:37:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 30 Oct 2017 12:37:11 -0700 From: "Templin, Fred L" To: Timothy Winters , 6man WG Subject: RE: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUM7Yt7hhS0AUynTqYnnBzBvqL8yXlw Date: Mon, 30 Oct 2017 19:37:11 +0000 Message-ID: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_647efa67a24f4511ab1968ec6c9227acXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:37:17 -0000 --_000_647efa67a24f4511ab1968ec6c9227acXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgdGFsa2VkIGFib3V0IGFkZGluZyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDMTEy Mi4gQ2FuDQp5b3UgcGxlYXNlIGFkZCB0aGF0Pw0KDQpGcmVkDQoNCkZyb206IGlwdjYgW21haWx0 bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW1vdGh5IFdpbnRlcnMNClNl bnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyA2OjQzIEFNDQpUbzogNm1hbiBXRyA8aXB2NkBp ZXRmLm9yZz4NClN1YmplY3Q6IFVwZGF0ZXMgdG8gUkZDNjQzNA0KDQpXZSBoYXZlIHBvc3RlZCBh biB1cGRhdGVkIHZlcnNpb24gb2YgNjQzNGJpcywgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMg c2luY2UgUHJhZ3VlOg0KDQogICogICBUZXh0IG9uIEVIIHByb2Nlc3NpbmcNCiAgKiAgIE5vdGVk IHRoYXQgUkZDNDE5MSBpcyBhIE1VU1QsIGJ1dCBhIFNIT1VMRCBmb3IgVHlwZSBDIG5vZGUNCiAg KiAgIFVwZGF0ZWQgUkZDIHJlZmVyZW5jZXMgKDgyMDAsIDgyMDEsIDgyMjEsIDgyNDcpDQogICog ICBBZGRlZCBub3RlIG9uIFJGQyA3NzcyIGZvciBwb3dlciBjb25zdW1wdGlvbg0KICAqICAgQWRk ZWQg4oCYV2h5IC82ND/igJkgcmVmZXJlbmNlOyBSRkMgNzQyMQ0KICAqICAgUmVtb3ZlZCBqdW1i b2dyYW0gdGV4dA0KICAqICAgQWRkZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQogICogICBGb3IgM0dQUCwgYWRkZWQg4oCYc25hcHNo b3TigJkgY29tbWVudCBvbiBSRkM3MDY2DQogICogICBBZGRlZCBSRkM4MDI4IGFzIGEgU0hPVUxE IChmb3IgU2VjdGlvbiA1LjUgZnJvbSBSRkMgNjcyNCkNCiAgKiAgIFJlbW92ZWQgQVRNIG92ZXIg SVB2Ng0KICAqICAgQWRkZWQgcmVmZXJlbmNlIHRvIFJGQzgwNjQNCiAgKiAgIEFkZGVkIE1VU1Qg Zm9yIEJDUCAxOTgsIGFuZCByZWYgdG8gZHJhZnQtaWV0Zi12Nm9wcy1pcHY2cnRyLXJlcXMNCiAg KiAgIEFkZGVkIHRleHQgb24gYXZvaWRpbmcgMTI4MCBNVFUgZm9yIFVEUCAoaW5jLiBETlMpIHRy YWZmaWMNCldlJ2xsIGJlIHNlbmRpbmcgc29tZSBhZGRpdGlvbmFsIHF1ZXN0aW9ucyB0byB0aGUg bGlzdCBsYXRlciB0aGlzIHdlZWsgdG8gaG9wZWZ1bGx5IGdldCB0aGlzIGRvY3VtZW50IHJlYWR5 IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KflRpbSwgVGltIGFuZCBKb2huDQoNCg0K DQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206IDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQpEYXRl OiBNb24sIE9jdCAzMCwgMjAxNyBhdCA5OjM2IEFNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3Jn PG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYzogaXB2NkBpZXRmLm9yZzxtYWlsdG86 aXB2NkBpZXRmLm9yZz4NCg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuDQoN CiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBOb2RlIFJlcXVpcmVtZW50cw0KICAgICAg ICBBdXRob3JzICAgICAgICAgOiBUaW0gQ2hvd24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg Sm9obiBMb3VnaG5leQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1vdGh5IFdpbnRlcnMN CiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAy LnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiA0MA0KICAgICAgICBEYXRlICAgICAgICAg ICAgOiAyMDE3LTEwLTMwDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHJl cXVpcmVtZW50cyBmb3IgSVB2NiBub2Rlcy4gIEl0IGlzIGV4cGVjdGVkDQogICB0aGF0IElQdjYg d2lsbCBiZSBkZXBsb3llZCBpbiBhIHdpZGUgcmFuZ2Ugb2YgZGV2aWNlcyBhbmQgc2l0dWF0aW9u cy4NCiAgIFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBub2RlcyBhbGxvd3Mg SVB2NiB0byBmdW5jdGlvbg0KICAgd2VsbCBhbmQgaW50ZXJvcGVyYXRlIGluIGEgbGFyZ2UgbnVt YmVyIG9mIHNpdHVhdGlvbnMgYW5kDQogICBkZXBsb3ltZW50cy4NCg0KICAgVGhpcyBkb2N1bWVu dCBvYnNvbGV0ZXMgUkZDIDY0MzQsIGFuZCBpbiB0dXJuIFJGQyA0Mjk0Lg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLw0KDQpUaGVy ZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0w Mg0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQt YmlzLTAyDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMu aWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYu b3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN Ci0tDQoNCk5vdyBvZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4gYXBwbGljYXRpb25zIGFuZCBjb250 cm9sbGVycyBpbiBvdXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4gTGVhcm4gbW9yZSB0b2RheSBodHRw Oi8vYml0Lmx5L1NETl9JT0xQUg0K --_000_647efa67a24f4511ab1968ec6c9227acXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdlb3JnaWE7DQoJ cGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTMwMjAzNTk5MjsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTg4MTY3Nzc4Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5XZSB0YWxrZWQgYWJvdXQgYWRkaW5nIGFuIGluZm9ybWF0aXZlIHJlZmVy ZW5jZSB0byBSRkMxMTIyLiBDYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+eW91IHBsZWFzZSBhZGQgdGhh dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5UaW1vdGh5IFdpbnRlcnM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDMw LCAyMDE3IDY6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IDZtYW4gV0cgJmx0O2lwdjZAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFVwZGF0ZXMgdG8gUkZDNjQzNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIHBvc3RlZCBh biB1cGRhdGVkIHZlcnNpb24gb2YgNjQzNGJpcywgd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMg c2luY2UgUHJhZ3VlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRl eHQgb24gRUggcHJvY2Vzc2luZyZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCk5vdGVkIHRoYXQgUkZDNDE5MSBpcyBh IE1VU1QsIGJ1dCBhIFNIT1VMRCBmb3IgVHlwZSBDIG5vZGU8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpVcGRhdGVkIFJGQyBy ZWZlcmVuY2VzICg4MjAwLCA4MjAxLCA4MjIxLCA4MjQ3KTxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkFkZGVkIG5vdGUgb24g UkZDIDc3NzIgZm9yIHBvd2VyIGNvbnN1bXB0aW9uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQg4oCYV2h5IC82ND/i gJkgcmVmZXJlbmNlOyBSRkMgNzQyMTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJlbW92ZWQganVtYm9ncmFtIHRleHQmbmJz cDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQpBZGRlZCByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3Q8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpGb3IgM0dQUCwgYWRkZWQg4oCYc25hcHNob3TigJkg Y29tbWVudCBvbiBSRkM3MDY2PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgUkZDODAyOCBhcyBhIFNIT1VMRCAoZm9y IFNlY3Rpb24gNS41IGZyb20gUkZDIDY3MjQpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUmVtb3ZlZCBBVE0gb3ZlciBJUHY2 PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KQWRkZWQgcmVmZXJlbmNlIHRvIFJGQzgwNjQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBZGRlZCBNVVNUIGZv ciBCQ1AgMTk4LCBhbmQgcmVmIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KQWRkZWQgdGV4dCBvbiBhdm9pZGluZyAxMjgwIE1UVSBmb3IgVURQIChpbmMuIEROUykgdHJh ZmZpYzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UnbGwgYmUgc2VuZGluZyBzb21lIGFkZGl0aW9uYWwgcXVlc3Rpb25zIHRvIHRoZSBs aXN0IGxhdGVyIHRoaXMgd2VlayB0byBob3BlZnVsbHkgZ2V0IHRoaXMgZG9jdW1lbnQgcmVhZHkg Zm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+VGltLCBUaW0gYW5kIEpvaG48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCkRhdGU6IE1vbiwgT2N0IDMwLCAyMDE3IGF0IDk6MzYgQU08YnI+DQpTdWJqZWN0 OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIudHh0PGJyPg0KVG86 IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p LWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzppcHY2QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogSVB2NiBOb2RlIFJlcXVpcmVtZW50czxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzogVGltIENob3duPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEpvaG4g TG91Z2huZXk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGltb3RoeSBX aW50ZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyLnR4dDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA0MDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE3LTEw LTMwPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg ZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMuJm5ic3A7IEl0IGlzIGV4cGVjdGVk PGJyPg0KJm5ic3A7ICZuYnNwO3RoYXQgSVB2NiB3aWxsIGJlIGRlcGxveWVkIGluIGEgd2lkZSBy YW5nZSBvZiBkZXZpY2VzIGFuZCBzaXR1YXRpb25zLjxicj4NCiZuYnNwOyAmbmJzcDtTcGVjaWZ5 aW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMgYWxsb3dzIElQdjYgdG8gZnVuY3Rp b248YnI+DQombmJzcDsgJm5ic3A7d2VsbCBhbmQgaW50ZXJvcGVyYXRlIGluIGEgbGFyZ2UgbnVt YmVyIG9mIHNpdHVhdGlvbnMgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO2RlcGxveW1lbnRzLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgNjQzNCwgYW5k IGluIHR1cm4gUkZDIDQyOTQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1h bi1yZmM2NDM0LWJpcy88L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDI8 L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyPC9h Pjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4N Cjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIg dGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxi cj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmIj5Ob3cgb2ZmZXJpbmcgdGVzdGluZyBm b3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNETiBzd2l0Y2ggdGVz dCBiZWQuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPkxlYXJuIG1vcmUgdG9kYXkNCjxhIGhyZWY9 Imh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2JpdC5seS9T RE5fSU9MUFI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_647efa67a24f4511ab1968ec6c9227acXCH150608nwnosboeingcom_-- From nobody Mon Oct 30 12:46:45 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1413F988 for ; Mon, 30 Oct 2017 12:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgGBp4gyb1yQ for ; Mon, 30 Oct 2017 12:46:40 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD5013FAEB for ; Mon, 30 Oct 2017 12:46:28 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id q83so17659611qke.6 for ; Mon, 30 Oct 2017 12:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MaDfbuMwMidCdolofvFiO9zo9f0/09y7EK1BPDGk+Aw=; b=gkhNRMBlXXyW9Bn92kjeyZ2OLYLuUGbS0jcO/BBwza1vORyqr7s5e8OwzZ4juz1WD8 wuzS3ivNZQH20nqqKWTR/kuv1OZjB8xG1IcUmfkQLDdRzGGIsRVM4sbMUikelmu5BG7X JPmb2Qt0dYAC6Vmz5YplXz0AFVXmjpskoP6+0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MaDfbuMwMidCdolofvFiO9zo9f0/09y7EK1BPDGk+Aw=; b=LQyBWQSXWzCzNzOdPyu1ArX5s+V0iGkJuIaxbgofHbB65bGLOFNk56Ffa8qIdRG7bE DfWuBfqgN0FB4UAzWt6Ws5OgyW+g88wRRRJFL2GacR+ZhhGqn+sUr/ykAgZJEivCwG7x aN8pCD0k9Edsc49h55akDtRF9CGETldwG6REll1jWkchIIWv2V8TYY0H9K8nf0flV38p IJSeWmZgC4xGYBp2MCqich08jdWLf/OC3NbR9BzcDoTDDIHrZNH4W7LOH94T7fHPcrpW Mg/jDwUgfnkP/bcKtyhTOApm/Dw7VkEjI3pNBYqNqBb16Yj+GKAzCIGHjJKVIN+qdCLe qsMg== X-Gm-Message-State: AMCzsaWcoLbhzYd5OJuhQYSLcnm5hJO1Ifx0ftNmTsS7NXSsZOA34T9u X3Tby9EC/8Tk8/NQ7FpdbVKZhp9F1fF4t0tykhviqQ== X-Google-Smtp-Source: ABhQp+T5Xw+AX3AfUGX3+9JR5bA0YRT8A+JFm73Ko8FG1Y2ycEGR30EsCbhY68ZpYS9G3+8lYXv0Z/45QJWBeD8EvWE= X-Received: by 10.233.220.196 with SMTP id q187mr14840041qkf.344.1509392787878; Mon, 30 Oct 2017 12:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.8 with HTTP; Mon, 30 Oct 2017 12:46:06 -0700 (PDT) In-Reply-To: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> From: Timothy Winters Date: Mon, 30 Oct 2017 15:46:06 -0400 Message-ID: Subject: Re: Updates to RFC6434 To: "Templin, Fred L" Cc: 6man WG Content-Type: multipart/alternative; boundary="94eb2c044a6ef2d613055cc8e4b1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:46:43 -0000 --94eb2c044a6ef2d613055cc8e4b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fred, I thought we decided we didn't want to point to the historic IPv4 text in that. Can you remind me were you wanted that text? ~Tim On Mon, Oct 30, 2017 at 3:37 PM, Templin, Fred L wrote: > We talked about adding an informative reference to RFC1122. Can > > you please add that? > > > > Fred > > > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Timothy Winter= s > *Sent:* Monday, October 30, 2017 6:43 AM > *To:* 6man WG > *Subject:* Updates to RFC6434 > > > > We have posted an updated version of 6434bis, with the following changes > since Prague: > > - Text on EH processing > - Noted that RFC4191 is a MUST, but a SHOULD for Type C node > - Updated RFC references (8200, 8201, 8221, 8247) > - Added note on RFC 7772 for power consumption > - Added =E2=80=98Why /64?=E2=80=99 reference; RFC 7421 > - Removed jumbogram text > - Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host > - For 3GPP, added =E2=80=98snapshot=E2=80=99 comment on RFC7066 > - Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724) > - Removed ATM over IPv6 > - Added reference to RFC8064 > - Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs > - Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic > > We'll be sending some additional questions to the list later this week to > hopefully get this document ready for working group last call. > > > > ~Tim, Tim and John > > > > > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 30, 2017 at 9:36 AM > Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > Title : IPv6 Node Requirements > Authors : Tim Chown > John Loughney > Timothy Winters > Filename : draft-ietf-6man-rfc6434-bis-02.txt > Pages : 40 > Date : 2017-10-30 > > Abstract: > This document defines requirements for IPv6 nodes. It is expected > that IPv6 will be deployed in a wide range of devices and situations. > Specifying the requirements for IPv6 nodes allows IPv6 to function > well and interoperate in a large number of situations and > deployments. > > This document obsoletes RFC 6434, and in turn RFC 4294. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6434-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6434-bis-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc6434-bis-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/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > > -- > > Now offering testing for SDN applications and controllers in our SDN > switch test bed. Learn more today http://bit.ly/SDN_IOLPR > --=20 Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --94eb2c044a6ef2d613055cc8e4b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fred,

I thought we decided we didn&#= 39;t want to point to the historic IPv4 text in that.=C2=A0 Can you remind = me were you wanted that text?

~Tim

On Mon, Oct 30, 2017 = at 3:37 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

We talked about adding an informative= reference to RFC1122. Can

you please add that?

=C2=A0

Fred

=C2=A0

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Timothy Winters
Sent: Monday, October 30, 2017 6:43 AM
To: 6man WG <i= pv6@ietf.org>
Subject: Updates to RFC6434

=C2=A0

We have posted an updated version of 6434bis, with t= he following changes since Prague:

  • Text on EH processing=C2=A0
  • Noted that RFC4191 is a MUST, but a SHOULD for Type C node
  • Updated RFC references (8200, 8201, 8221, 8247)
  • Added note on RFC 7772 for power consumption
  • Added =E2=80=98Why /64?=E2=80=99 reference; RFC 7421
  • Removed jumbogram text=C2=A0
  • Added reference to draft-ietf-v6ops-unique-ipv6-prefix-per-host=
  • For 3GPP, added =E2=80=98snapshot=E2=80=99 comment on RFC7066=
  • Added RFC8028 as a SHOULD (for Section 5.5 from RFC 6724)
  • Removed ATM over IPv6
  • Added reference to RFC8064
  • Added MUST for BCP 198, and ref to draft-ietf-v6ops-ipv6rtr-reqs<= /u>
  • Added text on avoiding 1280 MTU for UDP (inc. DNS) traffic

We'll be sending some additional questions to th= e list later this week to hopefully get this document ready for working gro= up last call.

=C2=A0

~Tim, Tim and John

=C2=A0

=C2=A0

=C2=A0

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Oct 30, 2017 at 9:36 AM
Subject: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt
To: i-d-announce= @ietf.org
Cc: ipv6@ietf.org


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= IPv6 Node Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Tim = Chown
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Loughney
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Timothy Winters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6man-rfc6434-bis-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 40
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

Abstract:
=C2=A0 =C2=A0This document defines requirements for IPv6 nodes.=C2=A0 It is= expected
=C2=A0 =C2=A0that IPv6 will be deployed in a wide range of devices and situ= ations.
=C2=A0 =C2=A0Specifying the requirements for IPv6 nodes allows IPv6 to func= tion
=C2=A0 =C2=A0well and interoperate in a large number of situations and
=C2=A0 =C2=A0deployments.

=C2=A0 =C2=A0This document obsoletes RFC 6434, and in turn RFC 4294.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6= 434-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-= 02
https://datatracker.ietf.org/doc/html/draft-ie= tf-6man-rfc6434-bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6= man-rfc6434-bis-02


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

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

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



=C2=A0

--

No= w offering testing for SDN applications and controllers in our SDN switch t= est bed.=C2=A0Learn more today http://bit.ly/SDN_IOL= PR




--

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--94eb2c044a6ef2d613055cc8e4b1-- From nobody Mon Oct 30 12:49:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6931513F65D for ; Mon, 30 Oct 2017 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdBecixS8RM4 for ; Mon, 30 Oct 2017 12:49:11 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C664813F738 for ; Mon, 30 Oct 2017 12:49:01 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id n5so17661266qke.11 for ; Mon, 30 Oct 2017 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gvNAWlynOYt+yYtgS1+W5oprBrdPoHiMKSnaOn2OeWg=; b=Zv5Mritz/+bD/d110q18yd5BJ+sQyMcnVIVm+07Gndqwqv5k+KmhGmS1W/yOHAmU7y JIdsM/we+SmItmvp3CHz2OuaUaobrXB4Hej+/m6FO7VuSbRU/KeY1jiGYKik3mWfPZYN wMwH+obCgO2ghnSegKz2EJL00/Io1EZQeHo5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gvNAWlynOYt+yYtgS1+W5oprBrdPoHiMKSnaOn2OeWg=; b=QAlRoVESXZ55uikrlxg289/MUBJXx7/GJcIoYBsmziyIoX+pmcrwolb/U0XuSS+rnp ygwhQ+PJABPSF4SX7mPNMJQVkMl0VCDy2J8j5hvNSPotokvTajIXlH649eN1b9315sjl AGf14Qm724mi+cnDcHU361itfbnhfl6PnLTcojdO8iMx1LgkM/+3iOTUYI27+qGWOExH +ZHDV/wO/VOjyWh37sVDCuczMywD+B0A9GFSjXtN8ayNuRclnTHc3ILiPshymxO4b22v 4CuRqhfs/xdC16eXqa4r4l4SVhdPsoN7s1ZSHhVVJrwgOqX9lQRIakCNV4uhPCcCwBEA sY1w== X-Gm-Message-State: AMCzsaUQ4AM/Va9FxCTT3ThihWsL5ryNSmCtn1af+qBnXmfiPuWaLg9j OxVs8I36FmMc2lal/Oew/3Nc0iI/GyKTeBtF9xxc6w== X-Google-Smtp-Source: ABhQp+RKARYZPqg9ZF/ipC0ns3EXIlSDrPgkJmkzajA6cXutpi2R6Ml+D+eUB0URJWyYwA68bNUWXT4W+EBORW+1JeA= X-Received: by 10.55.192.90 with SMTP id o87mr15053106qki.235.1509392940857; Mon, 30 Oct 2017 12:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.8 with HTTP; Mon, 30 Oct 2017 12:48:39 -0700 (PDT) In-Reply-To: References: <150937060401.3306.16675157648974156910@ietfa.amsl.com> From: Timothy Winters Date: Mon, 30 Oct 2017 15:48:39 -0400 Message-ID: Subject: Re: I-D Action: draft-ietf-6man-rfc6434-bis-02.txt To: Brian E Carpenter Cc: 6man Content-Type: multipart/alternative; boundary="001a1149aa6a11171d055cc8eed7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 19:49:19 -0000 --001a1149aa6a11171d055cc8eed7 Content-Type: text/plain; charset="UTF-8" Hi Brian, On Mon, Oct 30, 2017 at 3:29 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Looks good. Three small points: > > > 5.3. Protecting a node from excessive EH options > ... > > A host MAY disallow unknown options in destination options or hob-by- > > hop options. This should be configurable where the default is to > > accept unknown options and process them per RFC2460. If a packet > > with unknown options is received and the host is configured to > > disallow them, then the packet should be silently discarded. > > Not sure why this still refers to 2460. > Will fix in the next version. > > > 5.9. Default Router Preferences and More-Specific Routes - RFC 4191 > > > > "Default Router Preferences and More-Specific Routes" [RFC4191] > > provides support for nodes attached to multiple (different) networks, > > each providing routers that advertise themselves as default routers > > via Router Advertisements. In some scenarios, one router may provide > > connectivity to destinations the other router does not, and choosing > > the "wrong" default router can result in reachability failures. In > > order to resolve this scenario IPv6 Nodes MUST implement [RFC4191] > > and SHOULD implement Type C host role. > > I suggest that the last phrase should clarify that "Type C" is defined > in RFC 4191, because as written that is not obvious. > We can clarify that in the next revision. > > Are we sure that draft-ietf-v6ops-ipv6rtr-reqs is an Informative reference? > At the moment we haven't had any normative text from that but it's something that might change going forward. > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1149aa6a11171d055cc8eed7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Mon, Oct 30, 2017 at 3:29 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Looks good. Three small points:

> 5.3.=C2=A0 Protecting a node from excessive EH options
...
> A host MAY disallow unknown options in destination options or hob-by-<= br> > hop options.=C2=A0 This should be configurable where the default is to=
> accept unknown options and process them per RFC2460.=C2=A0 If a packet=
> with unknown options is received and the host is configured to
> disallow them, then the packet should be silently discarded.

Not sure why this still refers to 2460.
Will fix in th= e next version.

> 5.9.=C2=A0 Default Router Preferences and More-Specific Routes - RFC 4= 191
>
>=C2=A0 =C2=A0 "Default Router Preferences and More-Specific Routes= " [RFC4191]
>=C2=A0 =C2=A0 provides support for nodes attached to multiple (differen= t) networks,
>=C2=A0 =C2=A0 each providing routers that advertise themselves as defau= lt routers
>=C2=A0 =C2=A0 via Router Advertisements.=C2=A0 In some scenarios, one r= outer may provide
>=C2=A0 =C2=A0 connectivity to destinations the other router does not, a= nd choosing
>=C2=A0 =C2=A0 the "wrong" default router can result in reacha= bility failures.=C2=A0 In
>=C2=A0 =C2=A0 order to resolve this scenario IPv6 Nodes MUST implement = [RFC4191]
>=C2=A0 =C2=A0 and SHOULD implement Type C host role.

I suggest that the last phrase should clarify that "Type C" is de= fined
in RFC 4191, because as written that is not obvious.
W= e can clarify that in the next revision.=C2=A0

Are we sure that draft-ietf-v6ops-ipv6rtr-reqs is an Informative reference?=
At the moment we haven't had any normative text f= rom that but it's something that might change going forward.=C2=A0

Regards
=C2=A0= =C2=A0Brian

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



--
=

Now offering testing for SDN ap= plications and controllers in our SDN switch test bed.=C2=A0Learn more today http://bit.ly/SDN_IOLPR=

--001a1149aa6a11171d055cc8eed7-- From nobody Mon Oct 30 13:06:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596E513FAE1 for ; Mon, 30 Oct 2017 13:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ESqqFTV0Gdx for ; Mon, 30 Oct 2017 13:06:36 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3B313F403 for ; Mon, 30 Oct 2017 13:06:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v9UK6YLn017667; Mon, 30 Oct 2017 13:06:35 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9UK6RIE017597 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Oct 2017 13:06:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Oct 2017 13:06:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 30 Oct 2017 13:06:26 -0700 From: "Templin, Fred L" To: Timothy Winters CC: 6man WG Subject: RE: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUM7Yt7hhS0AUynTqYnnBzBvqL8yXlwgAB4SQD//4/toA== Date: Mon, 30 Oct 2017 20:06:26 +0000 Message-ID: <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_27453115328b4e4f88c79bc3c989ad55XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:06:39 -0000 --_000_27453115328b4e4f88c79bc3c989ad55XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltLA0KDQpJIGFtIHJlZmVycmluZyB0byBUaW0gQ2hvd27igJlzIHByb3Bvc2VkIHJlc29s dXRpb24gdG8gbXkgb3JpZ2luYWwgY29tbWVudDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9pcHY2L2N1cnJlbnQvbXNnMjgzOTQuaHRtbA0KDQpUaW3igJlzIHByb3Bv c2FsIHdhcyB0byBjaXRlIFJGQzExMjIgaW4gdGhlIGludHJvLCB3aGljaCBJIGFncmVlIHdvdWxk IGJlDQphcHByb3ByaWF0ZS4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBUaW1vdGh5IFdpbnRl cnMgW21haWx0bzp0d2ludGVyc0Bpb2wudW5oLmVkdV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAz MCwgMjAxNyAxMjo0NiBQTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCkNjOiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFVwZGF0 ZXMgdG8gUkZDNjQzNA0KDQpIaSBGcmVkLA0KDQpJIHRob3VnaHQgd2UgZGVjaWRlZCB3ZSBkaWRu J3Qgd2FudCB0byBwb2ludCB0byB0aGUgaGlzdG9yaWMgSVB2NCB0ZXh0IGluIHRoYXQuICBDYW4g eW91IHJlbWluZCBtZSB3ZXJlIHlvdSB3YW50ZWQgdGhhdCB0ZXh0Pw0KDQp+VGltDQoNCk9uIE1v biwgT2N0IDMwLCAyMDE3IGF0IDM6MzcgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0K V2UgdGFsa2VkIGFib3V0IGFkZGluZyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDMTEy Mi4gQ2FuDQp5b3UgcGxlYXNlIGFkZCB0aGF0Pw0KDQpGcmVkDQoNCkZyb206IGlwdjYgW21haWx0 bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBUaW1vdGh5IFdpbnRlcnMNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAx NyA2OjQzIEFNDQpUbzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBVcGRhdGVzIHRvIFJGQzY0MzQNCg0KV2UgaGF2ZSBwb3N0ZWQgYW4gdXBk YXRlZCB2ZXJzaW9uIG9mIDY0MzRiaXMsIHdpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzIHNpbmNl IFByYWd1ZToNCg0KICAqICAgVGV4dCBvbiBFSCBwcm9jZXNzaW5nDQogICogICBOb3RlZCB0aGF0 IFJGQzQxOTEgaXMgYSBNVVNULCBidXQgYSBTSE9VTEQgZm9yIFR5cGUgQyBub2RlDQogICogICBV cGRhdGVkIFJGQyByZWZlcmVuY2VzICg4MjAwLCA4MjAxLCA4MjIxLCA4MjQ3KQ0KICAqICAgQWRk ZWQgbm90ZSBvbiBSRkMgNzc3MiBmb3IgcG93ZXIgY29uc3VtcHRpb24NCiAgKiAgIEFkZGVkIOKA mFdoeSAvNjQ/4oCZIHJlZmVyZW5jZTsgUkZDIDc0MjENCiAgKiAgIFJlbW92ZWQganVtYm9ncmFt IHRleHQNCiAgKiAgIEFkZGVkIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdA0KICAqICAgRm9yIDNHUFAsIGFkZGVkIOKAmHNuYXBzaG904oCZ IGNvbW1lbnQgb24gUkZDNzA2Ng0KICAqICAgQWRkZWQgUkZDODAyOCBhcyBhIFNIT1VMRCAoZm9y IFNlY3Rpb24gNS41IGZyb20gUkZDIDY3MjQpDQogICogICBSZW1vdmVkIEFUTSBvdmVyIElQdjYN CiAgKiAgIEFkZGVkIHJlZmVyZW5jZSB0byBSRkM4MDY0DQogICogICBBZGRlZCBNVVNUIGZvciBC Q1AgMTk4LCBhbmQgcmVmIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzDQogICogICBB ZGRlZCB0ZXh0IG9uIGF2b2lkaW5nIDEyODAgTVRVIGZvciBVRFAgKGluYy4gRE5TKSB0cmFmZmlj DQpXZSdsbCBiZSBzZW5kaW5nIHNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMgdG8gdGhlIGxpc3Qg bGF0ZXIgdGhpcyB3ZWVrIHRvIGhvcGVmdWxseSBnZXQgdGhpcyBkb2N1bWVudCByZWFkeSBmb3Ig d29ya2luZyBncm91cCBsYXN0IGNhbGwuDQoNCn5UaW0sIFRpbSBhbmQgSm9obg0KDQoNCg0KLS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9u LCBPY3QgMzAsIDIwMTcgYXQgOTozNiBBTQ0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi02bWFuLXJmYzY0MzQtYmlzLTAyLnR4dA0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWls dG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KQ2M6IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZA aWV0Zi5vcmc+DQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBJUHY2IE1haW50ZW5hbmNlIFdHIG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IElQdjYgTm9kZSBSZXF1aXJlbWVudHMNCiAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogVGltIENob3duDQogICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4g TG91Z2huZXkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgVGltb3RoeSBXaW50ZXJzDQogICAg ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMi50eHQN CiAgICAgICAgUGFnZXMgICAgICAgICAgIDogNDANCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDog MjAxNy0xMC0zMA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJl bWVudHMgZm9yIElQdjYgbm9kZXMuICBJdCBpcyBleHBlY3RlZA0KICAgdGhhdCBJUHY2IHdpbGwg YmUgZGVwbG95ZWQgaW4gYSB3aWRlIHJhbmdlIG9mIGRldmljZXMgYW5kIHNpdHVhdGlvbnMuDQog ICBTcGVjaWZ5aW5nIHRoZSByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMgYWxsb3dzIElQdjYg dG8gZnVuY3Rpb24NCiAgIHdlbGwgYW5kIGludGVyb3BlcmF0ZSBpbiBhIGxhcmdlIG51bWJlciBv ZiBzaXR1YXRpb25zIGFuZA0KICAgZGVwbG95bWVudHMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgb2Jz b2xldGVzIFJGQyA2NDM0LCBhbmQgaW4gdHVybiBSRkMgNDI5NC4NCg0KDQpUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy8NCg0KVGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDINCg0K QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0w Mg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYu b3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxt YWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQotLQ0K DQpOb3cgb2ZmZXJpbmcgdGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxl cnMgaW4gb3VyIFNETiBzd2l0Y2ggdGVzdCBiZWQuIExlYXJuIG1vcmUgdG9kYXkgaHR0cDovL2Jp dC5seS9TRE5fSU9MUFINCg0KDQoNCi0tDQoNCk5vdyBvZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4g YXBwbGljYXRpb25zIGFuZCBjb250cm9sbGVycyBpbiBvdXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4g TGVhcm4gbW9yZSB0b2RheSBodHRwOi8vYml0Lmx5L1NETl9JT0xQUg0K --_000_27453115328b4e4f88c79bc3c989ad55XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1 IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjM4NjA3NDI3MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 OTA0ODIwMzkyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBUaW0sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIHJlZmVycmluZyB0byBU aW0gQ2hvd27igJlzIHByb3Bvc2VkIHJlc29sdXRpb24gdG8gbXkgb3JpZ2luYWwgY29tbWVudDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzI4Mzk0Lmh0 bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21z ZzI4Mzk0Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaW3igJlzIHByb3Bvc2FsIHdhcyB0byBjaXRlIFJGQzExMjIgaW4gdGhlIGludHJvLCB3aGlj aCBJIGFncmVlIHdvdWxkIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFwcHJvcHJpYXRlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IFRpbW90aHkgV2ludGVycyBbbWFpbHRvOnR3aW50ZXJzQGlvbC51bmguZWR1XQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyAxMjo0NiBQTTxicj4NCjxiPlRv OjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gNm1hbiBXRyAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFVwZGF0ZXMgdG8gUkZDNjQzNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGcmVkLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IHdlIGRlY2lkZWQgd2UgZGlkbid0 IHdhbnQgdG8gcG9pbnQgdG8gdGhlIGhpc3RvcmljIElQdjQgdGV4dCBpbiB0aGF0LiZuYnNwOyBD YW4geW91IHJlbWluZCBtZSB3ZXJlIHlvdSB3YW50ZWQgdGhhdCB0ZXh0PzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+VGltPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDMw LCAyMDE3IGF0IDM6MzcgUE0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5XZSB0YWxrZWQgYWJvdXQgYWRkaW5nIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBSRkMxMTIyLiBDYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj55b3UgcGxlYXNlIGFkZCB0aGF0Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gaXB2NiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5UaW1vdGh5IFdpbnRlcnM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3Rv YmVyIDMwLCAyMDE3IDY6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IDZtYW4gV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzppcHY2QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFVwZGF0ZXMgdG8gUkZDNjQzNDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgaGF2ZSBwb3N0 ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIDY0MzRiaXMsIHdpdGggdGhlIGZvbGxvd2luZyBjaGFu Z2VzIHNpbmNlIFByYWd1ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NClRleHQgb24gRUggcHJvY2Vzc2luZyZuYnNwOzxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCk5vdGVk IHRoYXQgUkZDNDE5MSBpcyBhIE1VU1QsIGJ1dCBhIFNIT1VMRCBmb3IgVHlwZSBDIG5vZGU8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpVcGRhdGVkIFJGQyByZWZlcmVuY2VzICg4MjAwLCA4MjAxLCA4MjIxLCA4MjQ3KTxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCkFkZGVkIG5vdGUgb24gUkZDIDc3NzIgZm9yIHBvd2VyIGNvbnN1bXB0aW9uPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K QWRkZWQg4oCYV2h5IC82ND/igJkgcmVmZXJlbmNlOyBSRkMgNzQyMTxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJlbW92ZWQg anVtYm9ncmFtIHRleHQmbmJzcDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBZGRlZCByZWZlcmVuY2UgdG8gZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Q8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpGb3IgM0dQUCwgYWRk ZWQg4oCYc25hcHNob3TigJkgY29tbWVudCBvbiBSRkM3MDY2PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgUkZDODAy OCBhcyBhIFNIT1VMRCAoZm9yIFNlY3Rpb24gNS41IGZyb20gUkZDIDY3MjQpPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUmVt b3ZlZCBBVE0gb3ZlciBJUHY2PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgcmVmZXJlbmNlIHRvIFJGQzgwNjQ8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpBZGRlZCBNVVNUIGZvciBCQ1AgMTk4LCBhbmQgcmVmIHRvIGRyYWZ0LWlldGYtdjZvcHMt aXB2NnJ0ci1yZXFzPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWRkZWQgdGV4dCBvbiBhdm9pZGluZyAxMjgwIE1UVSBmb3Ig VURQIChpbmMuIEROUykgdHJhZmZpYzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSdsbCBiZSBzZW5kaW5nIHNvbWUgYWRkaXRpb25h bCBxdWVzdGlvbnMgdG8gdGhlIGxpc3QgbGF0ZXIgdGhpcyB3ZWVrIHRvIGhvcGVmdWxseSBnZXQg dGhpcyBkb2N1bWVudCByZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5+VGltLCBU aW0gYW5kIEpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogTW9uLCBPY3Qg MzAsIDIwMTcgYXQgOTozNiBBTTxicj4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Nm1hbi1yZmM2NDM0LWJpcy0wMi50eHQ8YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5v dW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48 YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p cHY2QGlldGYub3JnPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE1haW50ZW5h bmNlIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBJUHY2IE5v ZGUgUmVxdWlyZW1lbnRzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBUaW0gQ2hvd248YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSm9obiBMb3VnaG5leTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaW1vdGh5IFdpbnRlcnM8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFm dC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDQw PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTctMTAtMzA8YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHJlcXVpcmVtZW50cyBmb3Ig SVB2NiBub2Rlcy4mbmJzcDsgSXQgaXMgZXhwZWN0ZWQ8YnI+DQombmJzcDsgJm5ic3A7dGhhdCBJ UHY2IHdpbGwgYmUgZGVwbG95ZWQgaW4gYSB3aWRlIHJhbmdlIG9mIGRldmljZXMgYW5kIHNpdHVh dGlvbnMuPGJyPg0KJm5ic3A7ICZuYnNwO1NwZWNpZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3Ig SVB2NiBub2RlcyBhbGxvd3MgSVB2NiB0byBmdW5jdGlvbjxicj4NCiZuYnNwOyAmbmJzcDt3ZWxs IGFuZCBpbnRlcm9wZXJhdGUgaW4gYSBsYXJnZSBudW1iZXIgb2Ygc2l0dWF0aW9ucyBhbmQ8YnI+ DQombmJzcDsgJm5ic3A7ZGVwbG95bWVudHMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMg ZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA2NDM0LCBhbmQgaW4gdHVybiBSRkMgNDI5NC48YnI+DQo8 YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLzwvYT48YnI+DQo8 YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2 NDM0LWJpcy0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDI8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMt MDIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMjwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJp cy0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDI8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0K QWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwi Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHZW9y Z2lhJnF1b3Q7LHNlcmlmIj5Ob3cgb2ZmZXJpbmcgdGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9u cyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNETiBzd2l0Y2ggdGVzdCBiZWQuJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEm cXVvdDssc2VyaWYiPkxlYXJuIG1vcmUgdG9kYXkNCjxhIGhyZWY9Imh0dHA6Ly9iaXQubHkvU0RO X0lPTFBSIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2JpdC5seS9TRE5fSU9MUFI8L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWYiPk5vdyBv ZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4gYXBwbGljYXRpb25zIGFuZCBjb250cm9sbGVycyBpbiBv dXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+TGVhcm4gbW9y ZSB0b2RheQ0KPGEgaHJlZj0iaHR0cDovL2JpdC5seS9TRE5fSU9MUFIiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vYml0Lmx5L1NETl9JT0xQUjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_27453115328b4e4f88c79bc3c989ad55XCH150608nwnosboeingcom_-- From nobody Mon Oct 30 13:27:51 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8124013F5C8 for ; Mon, 30 Oct 2017 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayeLZjoNBFAC for ; Mon, 30 Oct 2017 13:27:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D28D13F5AC for ; Mon, 30 Oct 2017 13:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509395265; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=44g7VvQpWBZnZcKh1HyPK7NaVJcESTDC9+1IVUwrLXM=; b=BAOJpCfnxMYXSbywD+qKW7pYY6j1p5gVXJxK0mLue8G3hdHp/wUQu8V8Az3Bl7PzevxRVGbr7ucxYMMc9OmSISrf/R6RTdNdRbDVufk9jzegJNHul2M3XRclhDiVaZJzJUmMG9IvzVrjQ+2RuP9I7QnhP2m91taIFXyhe8ZPlgs= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-20-afgKiG18OFSXw6aUQ5d25Q-1; Mon, 30 Oct 2017 20:27:42 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Mon, 30 Oct 2017 20:27:40 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0197.011; Mon, 30 Oct 2017 20:27:40 +0000 From: Tim Chown To: "Templin, Fred L" CC: Timothy Winters , 6man WG Subject: Re: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUUiFTgLcDqT0uoRJU+iPmMB6L8yeuAgAACfgCAAAWuAIAABeuA Date: Mon, 30 Oct 2017 20:27:40 +0000 Message-ID: References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:718e:a4e1:1d41:6dad] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 20:+jrfnh8B6HAxYRFiBegDnJLg6HRm45P11myxb24OrZBQZQ9rSoX5oedfeeoRUFemYtP8s3/+k5/xKmgo8KnCqvuRtbJpo81M/J9c6WuPlz3IOU29MntB0561GbljKUOD+CQHFk7+jBXsYt2cXPhf0sdxu2iSrPFCyhmIcm9RJeI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fbe2e5c2-5c87-4ecd-4459-08d51fd4ab42 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603238); SRVR:AM3PR07MB1138; x-ms-traffictypediagnostic: AM3PR07MB1138: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(39337521807258); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(377424004)(189002)(24454002)(54906003)(72206003)(966005)(478600001)(4001150100001)(97736004)(25786009)(2906002)(10710500007)(316002)(786003)(14454004)(8666007)(53366004)(6306002)(53936002)(99286003)(1720100001)(4326008)(53546010)(53376002)(6246003)(57306001)(93886005)(102836003)(6116002)(6512007)(5660300001)(81156014)(81166006)(86362001)(101416001)(76176999)(8936002)(50986999)(50226002)(305945005)(6916009)(68736007)(83716003)(7116003)(561944003)(6506006)(3660700001)(105586002)(7736002)(82746002)(6486002)(6436002)(7110500001)(42882006)(189998001)(229853002)(74482002)(5250100002)(2420400007)(8676002)(2950100002)(2900100001)(33656002)(106356001)(15650500001)(3280700002)(36756003)(493534005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: fbe2e5c2-5c87-4ecd-4459-08d51fd4ab42 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 20:27:40.8786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 X-MC-Unique: afgKiG18OFSXw6aUQ5d25Q-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:27:50 -0000 VGhhdCB3YXMgYSDigJhjb3VsZOKAmTsgSSB0aGluayB3ZSBzdWJzZXF1ZW50bHkgYWdyZWVkIGl0 IHdhc27igJl0IG5lY2Vzc2FyeSwgZm9yIHRoZSByZWFzb24gVGltIG1lbnRpb25lZD8NCg0KVGlt DQoNCj4gT24gMzAgT2N0IDIwMTcsIGF0IDIwOjA2LCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiANCj4gSGkgVGltLA0KPiAgDQo+IEkgYW0gcmVm ZXJyaW5nIHRvIFRpbSBDaG93buKAmXMgcHJvcG9zZWQgcmVzb2x1dGlvbiB0byBteSBvcmlnaW5h bCBjb21tZW50Og0KPiAgDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv aXB2Ni9jdXJyZW50L21zZzI4Mzk0Lmh0bWwNCj4gIA0KPiBUaW3igJlzIHByb3Bvc2FsIHdhcyB0 byBjaXRlIFJGQzExMjIgaW4gdGhlIGludHJvLCB3aGljaCBJIGFncmVlIHdvdWxkIGJlDQo+IGFw cHJvcHJpYXRlLg0KPiAgDQo+IFRoYW5rcyAtIEZyZWQNCj4gIA0KPiBGcm9tOiBUaW1vdGh5IFdp bnRlcnMgW21haWx0bzp0d2ludGVyc0Bpb2wudW5oLmVkdV0gDQo+IFNlbnQ6IE1vbmRheSwgT2N0 b2JlciAzMCwgMjAxNyAxMjo0NiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiBDYzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFVwZGF0ZXMgdG8gUkZDNjQzNA0KPiAgDQo+IEhpIEZyZWQsDQo+ICANCj4gSSB0aG91 Z2h0IHdlIGRlY2lkZWQgd2UgZGlkbid0IHdhbnQgdG8gcG9pbnQgdG8gdGhlIGhpc3RvcmljIElQ djQgdGV4dCBpbiB0aGF0LiAgQ2FuIHlvdSByZW1pbmQgbWUgd2VyZSB5b3Ugd2FudGVkIHRoYXQg dGV4dD8NCj4gIA0KPiB+VGltDQo+ICANCj4gT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMzozNyBQ TSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4g V2UgdGFsa2VkIGFib3V0IGFkZGluZyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDMTEy Mi4gQ2FuDQo+IHlvdSBwbGVhc2UgYWRkIHRoYXQ/DQo+ICANCj4gRnJlZA0KPiAgDQo+IEZyb206 IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW1vdGh5 IFdpbnRlcnMNCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDY6NDMgQU0NCj4gVG86 IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFVwZGF0ZXMgdG8gUkZDNjQzNA0K PiAgDQo+IFdlIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiA2NDM0YmlzLCB3aXRo IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBQcmFndWU6DQo+IAnigKIgVGV4dCBvbiBFSCBw cm9jZXNzaW5nIA0KPiAJ4oCiIE5vdGVkIHRoYXQgUkZDNDE5MSBpcyBhIE1VU1QsIGJ1dCBhIFNI T1VMRCBmb3IgVHlwZSBDIG5vZGUNCj4gCeKAoiBVcGRhdGVkIFJGQyByZWZlcmVuY2VzICg4MjAw LCA4MjAxLCA4MjIxLCA4MjQ3KQ0KPiAJ4oCiIEFkZGVkIG5vdGUgb24gUkZDIDc3NzIgZm9yIHBv d2VyIGNvbnN1bXB0aW9uDQo+IAnigKIgQWRkZWQg4oCYV2h5IC82ND/igJkgcmVmZXJlbmNlOyBS RkMgNzQyMQ0KPiAJ4oCiIFJlbW92ZWQganVtYm9ncmFtIHRleHQgDQo+IAnigKIgQWRkZWQgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+ IAnigKIgRm9yIDNHUFAsIGFkZGVkIOKAmHNuYXBzaG904oCZIGNvbW1lbnQgb24gUkZDNzA2Ng0K PiAJ4oCiIEFkZGVkIFJGQzgwMjggYXMgYSBTSE9VTEQgKGZvciBTZWN0aW9uIDUuNSBmcm9tIFJG QyA2NzI0KQ0KPiAJ4oCiIFJlbW92ZWQgQVRNIG92ZXIgSVB2Ng0KPiAJ4oCiIEFkZGVkIHJlZmVy ZW5jZSB0byBSRkM4MDY0DQo+IAnigKIgQWRkZWQgTVVTVCBmb3IgQkNQIDE5OCwgYW5kIHJlZiB0 byBkcmFmdC1pZXRmLXY2b3BzLWlwdjZydHItcmVxcw0KPiAJ4oCiIEFkZGVkIHRleHQgb24gYXZv aWRpbmcgMTI4MCBNVFUgZm9yIFVEUCAoaW5jLiBETlMpIHRyYWZmaWMNCj4gV2UnbGwgYmUgc2Vu ZGluZyBzb21lIGFkZGl0aW9uYWwgcXVlc3Rpb25zIHRvIHRoZSBsaXN0IGxhdGVyIHRoaXMgd2Vl ayB0byBob3BlZnVsbHkgZ2V0IHRoaXMgZG9jdW1lbnQgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsLg0KPiAgDQo+IH5UaW0sIFRpbSBhbmQgSm9obg0KPiAgDQo+ICANCj4gIA0KPiAt LS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gRnJvbTogPGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4NCj4gRGF0ZTogTW9uLCBPY3QgMzAsIDIwMTcgYXQgOTozNiBBTQ0K PiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIudHh0 DQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gDQo+ IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBJUHY2IE1haW50ZW5hbmNlIFdHIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAg ICBUaXRsZSAgICAgICAgICAgOiBJUHY2IE5vZGUgUmVxdWlyZW1lbnRzDQo+ICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogVGltIENob3duDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9o biBMb3VnaG5leQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRpbW90aHkgV2ludGVycw0K PiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0w Mi50eHQNCj4gICAgICAgICBQYWdlcyAgICAgICAgICAgOiA0MA0KPiAgICAgICAgIERhdGUgICAg ICAgICAgICA6IDIwMTctMTAtMzANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciBJUHY2IG5vZGVzLiAgSXQgaXMgZXhwZWN0ZWQNCj4g ICAgdGhhdCBJUHY2IHdpbGwgYmUgZGVwbG95ZWQgaW4gYSB3aWRlIHJhbmdlIG9mIGRldmljZXMg YW5kIHNpdHVhdGlvbnMuDQo+ICAgIFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgSVB2 NiBub2RlcyBhbGxvd3MgSVB2NiB0byBmdW5jdGlvbg0KPiAgICB3ZWxsIGFuZCBpbnRlcm9wZXJh dGUgaW4gYSBsYXJnZSBudW1iZXIgb2Ygc2l0dWF0aW9ucyBhbmQNCj4gICAgZGVwbG95bWVudHMu DQo+IA0KPiAgICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgNjQzNCwgYW5kIGluIHR1cm4g UkZDIDQyOTQuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtNm1hbi1yZmM2NDM0LWJpcy8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KPiANCj4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyDQo+IA0K PiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+ICANCj4gLS0NCj4gTm93IG9mZmVyaW5nIHRl c3RpbmcgZm9yIFNETiBhcHBsaWNhdGlvbnMgYW5kIGNvbnRyb2xsZXJzIGluIG91ciBTRE4gc3dp dGNoIHRlc3QgYmVkLiBMZWFybiBtb3JlIHRvZGF5IGh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+ IA0KPiANCj4gDQo+ICANCj4gLS0gDQo+IE5vdyBvZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4gYXBw bGljYXRpb25zIGFuZCBjb250cm9sbGVycyBpbiBvdXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4gTGVh cm4gbW9yZSB0b2RheSBodHRwOi8vYml0Lmx5L1NETl9JT0xQUg0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcN Cj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Mon Oct 30 13:46:41 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD613FB69 for ; Mon, 30 Oct 2017 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CypvNnp1HOfg for ; Mon, 30 Oct 2017 13:46:36 -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 8DC3513F567 for ; Mon, 30 Oct 2017 13:46:36 -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 v9UKka5C064472; Mon, 30 Oct 2017 13:46:36 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9UKkW0v064080 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Oct 2017 13:46:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Oct 2017 13:46:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 30 Oct 2017 13:46:31 -0700 From: "Templin, Fred L" To: Tim Chown CC: Timothy Winters , 6man WG Subject: RE: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUM7Yt7hhS0AUynTqYnnBzBvqL8yXlwgAB4SQD//4/toIAAe7AA//+N8dA= Date: Mon, 30 Oct 2017 20:46:31 +0000 Message-ID: References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 20:46:39 -0000 SGkgVGltLA0KDQpJIGJlbGlldmUgaXQgc2hvdWxkIGJlIGNpdGVkIGluIHRoZSBpbnRyb2R1Y3Rp b24gaW4gdGhlIHNhbWUgd2F5IGFzDQpSRkM4MjAwIGNpdGVzIFJGQzc5MS4NCg0KRnJlZA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRpbSBDaG93biBbbWFpbHRvOlRp bS5DaG93bkBqaXNjLmFjLnVrXQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMToy OCBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K PiBDYzogVGltb3RoeSBXaW50ZXJzIDx0d2ludGVyc0Bpb2wudW5oLmVkdT47IDZtYW4gV0cgPGlw djZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBVcGRhdGVzIHRvIFJGQzY0MzQNCj4gDQo+IFRo YXQgd2FzIGEg4oCYY291bGTigJk7IEkgdGhpbmsgd2Ugc3Vic2VxdWVudGx5IGFncmVlZCBpdCB3 YXNu4oCZdCBuZWNlc3NhcnksIGZvciB0aGUgcmVhc29uIFRpbSBtZW50aW9uZWQ/DQo+IA0KPiBU aW0NCj4gDQo+ID4gT24gMzAgT2N0IDIwMTcsIGF0IDIwOjA2LCBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgVGltLA0KPiA+DQo+ ID4gSSBhbSByZWZlcnJpbmcgdG8gVGltIENob3du4oCZcyBwcm9wb3NlZCByZXNvbHV0aW9uIHRv IG15IG9yaWdpbmFsIGNvbW1lbnQ6DQo+ID4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9tc2cyODM5NC5odG1sDQo+ID4NCj4gPiBUaW3igJlz IHByb3Bvc2FsIHdhcyB0byBjaXRlIFJGQzExMjIgaW4gdGhlIGludHJvLCB3aGljaCBJIGFncmVl IHdvdWxkIGJlDQo+ID4gYXBwcm9wcmlhdGUuDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4N Cj4gPiBGcm9tOiBUaW1vdGh5IFdpbnRlcnMgW21haWx0bzp0d2ludGVyc0Bpb2wudW5oLmVkdV0N Cj4gPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMTI6NDYgUE0NCj4gPiBUbzogVGVt cGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+IENjOiA2bWFuIFdH IDxpcHY2QGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBVcGRhdGVzIHRvIFJGQzY0MzQNCj4g Pg0KPiA+IEhpIEZyZWQsDQo+ID4NCj4gPiBJIHRob3VnaHQgd2UgZGVjaWRlZCB3ZSBkaWRuJ3Qg d2FudCB0byBwb2ludCB0byB0aGUgaGlzdG9yaWMgSVB2NCB0ZXh0IGluIHRoYXQuICBDYW4geW91 IHJlbWluZCBtZSB3ZXJlIHlvdSB3YW50ZWQgdGhhdCB0ZXh0Pw0KPiA+DQo+ID4gflRpbQ0KPiA+ DQo+ID4gT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMzozNyBQTSwgVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPiBXZSB0YWxrZWQgYWJvdXQgYWRk aW5nIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMxMTIyLiBDYW4NCj4gPiB5b3UgcGxl YXNlIGFkZCB0aGF0Pw0KPiA+DQo+ID4gRnJlZA0KPiA+DQo+ID4gRnJvbTogaXB2NiBbbWFpbHRv OmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbW90aHkgV2ludGVycw0KPiA+ IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyA2OjQzIEFNDQo+ID4gVG86IDZtYW4gV0cg PGlwdjZAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogVXBkYXRlcyB0byBSRkM2NDM0DQo+ID4NCj4g PiBXZSBoYXZlIHBvc3RlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgNjQzNGJpcywgd2l0aCB0aGUg Zm9sbG93aW5nIGNoYW5nZXMgc2luY2UgUHJhZ3VlOg0KPiA+IAnigKIgVGV4dCBvbiBFSCBwcm9j ZXNzaW5nDQo+ID4gCeKAoiBOb3RlZCB0aGF0IFJGQzQxOTEgaXMgYSBNVVNULCBidXQgYSBTSE9V TEQgZm9yIFR5cGUgQyBub2RlDQo+ID4gCeKAoiBVcGRhdGVkIFJGQyByZWZlcmVuY2VzICg4MjAw LCA4MjAxLCA4MjIxLCA4MjQ3KQ0KPiA+IAnigKIgQWRkZWQgbm90ZSBvbiBSRkMgNzc3MiBmb3Ig cG93ZXIgY29uc3VtcHRpb24NCj4gPiAJ4oCiIEFkZGVkIOKAmFdoeSAvNjQ/4oCZIHJlZmVyZW5j ZTsgUkZDIDc0MjENCj4gPiAJ4oCiIFJlbW92ZWQganVtYm9ncmFtIHRleHQNCj4gPiAJ4oCiIEFk ZGVkIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXIt aG9zdA0KPiA+IAnigKIgRm9yIDNHUFAsIGFkZGVkIOKAmHNuYXBzaG904oCZIGNvbW1lbnQgb24g UkZDNzA2Ng0KPiA+IAnigKIgQWRkZWQgUkZDODAyOCBhcyBhIFNIT1VMRCAoZm9yIFNlY3Rpb24g NS41IGZyb20gUkZDIDY3MjQpDQo+ID4gCeKAoiBSZW1vdmVkIEFUTSBvdmVyIElQdjYNCj4gPiAJ 4oCiIEFkZGVkIHJlZmVyZW5jZSB0byBSRkM4MDY0DQo+ID4gCeKAoiBBZGRlZCBNVVNUIGZvciBC Q1AgMTk4LCBhbmQgcmVmIHRvIGRyYWZ0LWlldGYtdjZvcHMtaXB2NnJ0ci1yZXFzDQo+ID4gCeKA oiBBZGRlZCB0ZXh0IG9uIGF2b2lkaW5nIDEyODAgTVRVIGZvciBVRFAgKGluYy4gRE5TKSB0cmFm ZmljDQo+ID4gV2UnbGwgYmUgc2VuZGluZyBzb21lIGFkZGl0aW9uYWwgcXVlc3Rpb25zIHRvIHRo ZSBsaXN0IGxhdGVyIHRoaXMgd2VlayB0byBob3BlZnVsbHkgZ2V0IHRoaXMgZG9jdW1lbnQgcmVh ZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdA0KPiBjYWxsLg0KPiA+DQo+ID4gflRpbSwgVGltIGFu ZCBKb2huDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAt LS0tLS0tLS0tDQo+ID4gRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gPiBEYXRl OiBNb24sIE9jdCAzMCwgMjAxNyBhdCA5OjM2IEFNDQo+ID4gU3ViamVjdDogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyLnR4dA0KPiA+IFRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCj4gPiBDYzogaXB2NkBpZXRmLm9yZw0KPiA+DQo+ID4NCj4gPg0KPiA+IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJ UHY2IE1haW50ZW5hbmNlIFdHIG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBJUHY2IE5vZGUgUmVxdWlyZW1lbnRzDQo+ID4gICAgICAgICBBdXRob3JzICAg ICAgICAgOiBUaW0gQ2hvd24NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4gTG91 Z2huZXkNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFRpbW90aHkgV2ludGVycw0KPiA+ ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAy LnR4dA0KPiA+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogNDANCj4gPiAgICAgICAgIERhdGUg ICAgICAgICAgICA6IDIwMTctMTAtMzANCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIElQdjYgbm9kZXMuICBJdCBpcyBleHBl Y3RlZA0KPiA+ICAgIHRoYXQgSVB2NiB3aWxsIGJlIGRlcGxveWVkIGluIGEgd2lkZSByYW5nZSBv ZiBkZXZpY2VzIGFuZCBzaXR1YXRpb25zLg0KPiA+ICAgIFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVt ZW50cyBmb3IgSVB2NiBub2RlcyBhbGxvd3MgSVB2NiB0byBmdW5jdGlvbg0KPiA+ICAgIHdlbGwg YW5kIGludGVyb3BlcmF0ZSBpbiBhIGxhcmdlIG51bWJlciBvZiBzaXR1YXRpb25zIGFuZA0KPiA+ ICAgIGRlcGxveW1lbnRzLg0KPiA+DQo+ID4gICAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZD IDY0MzQsIGFuZCBpbiB0dXJuIFJGQyA0Mjk0Lg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMvDQo+ID4NCj4g PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0K PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi02bWFu LXJmYzY0MzQtYmlzLTAyDQo+ID4NCj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJRVRGIElQdjYg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPiBpcHY2QGlldGYub3JnDQo+ID4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBOb3cgb2Zm ZXJpbmcgdGVzdGluZyBmb3IgU0ROIGFwcGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3Vy IFNETiBzd2l0Y2ggdGVzdCBiZWQuIExlYXJuIG1vcmUgdG9kYXkgaHR0cDovL2JpdC5seS9TRE5f SU9MUFINCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gTm93IG9mZmVyaW5nIHRlc3Rp bmcgZm9yIFNETiBhcHBsaWNhdGlvbnMgYW5kIGNvbnRyb2xsZXJzIGluIG91ciBTRE4gc3dpdGNo IHRlc3QgYmVkLiBMZWFybiBtb3JlIHRvZGF5IGh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+ID4N Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dA0KPiA+IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Mon Oct 30 16:32:16 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E949CABC for ; Mon, 30 Oct 2017 16:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQH8nsIO99by for ; Mon, 30 Oct 2017 16:32:12 -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-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A83CABE for ; Mon, 30 Oct 2017 16:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509406330; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=CTTD4bGyY+mEdjB5fxJQQL63iQqGUVdyhVDZIVSfv2o=; b=cn1yb3GcTOsxE6zfdEFh7Xrqu2/s2JWkGVaBznXrsP4xZhUXeQDsNAQcarzRnYUc7jioMobkHtKgvTZYsbhpSrQFMVHRBGQ255Sq8DM+mvTmWdq1Suj5QvLCq71SH9DBks4DHXu38JGP2YDSiJrNArj7yXnuJctMyDXy+beQBs0= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-30-EhkfZUuROve8Ea5Hdm__OQ-1; Mon, 30 Oct 2017 23:32:04 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Mon, 30 Oct 2017 23:32:03 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0197.011; Mon, 30 Oct 2017 23:32:03 +0000 From: Tim Chown To: "Templin, Fred L" CC: Timothy Winters , 6man WG Subject: Re: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUUiFTgLcDqT0uoRJU+iPmMB6L8yeuAgAACfgCAAAWuAIAABeuAgAAFSICAAC46AA== Date: Mon, 30 Oct 2017 23:32:03 +0000 Message-ID: References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:718e:a4e1:1d41:6dad] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:Be+RywJUL/1I2Cg3Rw5R3IjRqgsCg542P0rtutKG5C+X2t81+IlrhuHYBOubVV442ab3jl7i7guTXPVBSHHxVf9R8Q7676sLK74EGPR3rqslxHRmcK4bl0/546EUhcWMzgHmJzadt09sGfu1oR//DwKw3ZfOtSBfrvze1JZGHgg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce43c8e3-183c-488a-9fd2-08d51fee6cde x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:AM3PR07MB1139; x-ms-traffictypediagnostic: AM3PR07MB1139: x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(120809045254105)(39337521807258); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(13464003)(377424004)(24454002)(189002)(6506006)(101416001)(6486002)(6246003)(6306002)(8936002)(6436002)(53936002)(7116003)(5660300001)(3280700002)(4326008)(5250100002)(53376002)(53366004)(53546010)(14454004)(10710500007)(4001150100001)(82746002)(83716003)(2906002)(1720100001)(6512007)(99286003)(2900100001)(54906003)(316002)(786003)(36756003)(189998001)(81156014)(8676002)(3660700001)(7110500001)(68736007)(86362001)(105586002)(74482002)(966005)(106356001)(33656002)(50226002)(72206003)(97736004)(81166006)(25786009)(478600001)(42882006)(2950100002)(93886005)(7736002)(6916009)(8666007)(229853002)(2420400007)(305945005)(15650500001)(50986999)(76176999)(102836003)(561944003)(57306001)(6116002)(493534005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <88EF926AA649B242A6E002147FF12A89@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ce43c8e3-183c-488a-9fd2-08d51fee6cde X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 23:32:03.1218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: EhkfZUuROve8Ea5Hdm__OQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:32:15 -0000 SGkgRnJlZCwNCg0KV2UgY2FuIGFkZCB0aGlzIHRvcGljIHRvIHRoZSBsaXN0IG9mIHRoaW5ncyB0 byBiZSByYWlzZWQgaW4gdGhlIFNpbmdhcG9yZSBtZWV0aW5nLg0KDQpJZiBhbnlvbmUgZWxzZSBo YXMgc3Ryb25nIHZpZXcgb24gdGhpcywgcGxlYXNlIGRvIHNob3V0IG5vdyB0aG91Z2guDQoNClRp bSANCg0KPiBPbiAzMCBPY3QgMjAxNywgYXQgMjA6NDYsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBUaW0sDQo+IA0KPiBJIGJlbGll dmUgaXQgc2hvdWxkIGJlIGNpdGVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gaW4gdGhlIHNhbWUgd2F5 IGFzDQo+IFJGQzgyMDAgY2l0ZXMgUkZDNzkxLg0KPiANCj4gRnJlZA0KPiANCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBUaW0gQ2hvd24gW21haWx0bzpUaW0uQ2hvd25A amlzYy5hYy51a10NCj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyAxOjI4IFBNDQo+ PiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPj4gQ2M6 IFRpbW90aHkgV2ludGVycyA8dHdpbnRlcnNAaW9sLnVuaC5lZHU+OyA2bWFuIFdHIDxpcHY2QGll dGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFVwZGF0ZXMgdG8gUkZDNjQzNA0KPj4gDQo+PiBUaGF0 IHdhcyBhIOKAmGNvdWxk4oCZOyBJIHRoaW5rIHdlIHN1YnNlcXVlbnRseSBhZ3JlZWQgaXQgd2Fz buKAmXQgbmVjZXNzYXJ5LCBmb3IgdGhlIHJlYXNvbiBUaW0gbWVudGlvbmVkPw0KPj4gDQo+PiBU aW0NCj4+IA0KPj4+IE9uIDMwIE9jdCAyMDE3LCBhdCAyMDowNiwgVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBUaW0sDQo+Pj4g DQo+Pj4gSSBhbSByZWZlcnJpbmcgdG8gVGltIENob3du4oCZcyBwcm9wb3NlZCByZXNvbHV0aW9u IHRvIG15IG9yaWdpbmFsIGNvbW1lbnQ6DQo+Pj4gDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9pcHY2L2N1cnJlbnQvbXNnMjgzOTQuaHRtbA0KPj4+IA0KPj4+IFRp beKAmXMgcHJvcG9zYWwgd2FzIHRvIGNpdGUgUkZDMTEyMiBpbiB0aGUgaW50cm8sIHdoaWNoIEkg YWdyZWUgd291bGQgYmUNCj4+PiBhcHByb3ByaWF0ZS4NCj4+PiANCj4+PiBUaGFua3MgLSBGcmVk DQo+Pj4gDQo+Pj4gRnJvbTogVGltb3RoeSBXaW50ZXJzIFttYWlsdG86dHdpbnRlcnNAaW9sLnVu aC5lZHVdDQo+Pj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDMwLCAyMDE3IDEyOjQ2IFBNDQo+Pj4g VG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4+PiBDYzog Nm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogVXBkYXRlcyB0byBSRkM2 NDM0DQo+Pj4gDQo+Pj4gSGkgRnJlZCwNCj4+PiANCj4+PiBJIHRob3VnaHQgd2UgZGVjaWRlZCB3 ZSBkaWRuJ3Qgd2FudCB0byBwb2ludCB0byB0aGUgaGlzdG9yaWMgSVB2NCB0ZXh0IGluIHRoYXQu ICBDYW4geW91IHJlbWluZCBtZSB3ZXJlIHlvdSB3YW50ZWQgdGhhdCB0ZXh0Pw0KPj4+IA0KPj4+ IH5UaW0NCj4+PiANCj4+PiBPbiBNb24sIE9jdCAzMCwgMjAxNyBhdCAzOjM3IFBNLCBUZW1wbGlu LCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPj4+IFdlIHRhbGtl ZCBhYm91dCBhZGRpbmcgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQzExMjIuIENhbg0K Pj4+IHlvdSBwbGVhc2UgYWRkIHRoYXQ/DQo+Pj4gDQo+Pj4gRnJlZA0KPj4+IA0KPj4+IEZyb206 IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW1vdGh5 IFdpbnRlcnMNCj4+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgNjo0MyBBTQ0KPj4+ IFRvOiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFVwZGF0ZXMgdG8gUkZD NjQzNA0KPj4+IA0KPj4+IFdlIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiA2NDM0 YmlzLCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBQcmFndWU6DQo+Pj4gCeKAoiBU ZXh0IG9uIEVIIHByb2Nlc3NpbmcNCj4+PiAJ4oCiIE5vdGVkIHRoYXQgUkZDNDE5MSBpcyBhIE1V U1QsIGJ1dCBhIFNIT1VMRCBmb3IgVHlwZSBDIG5vZGUNCj4+PiAJ4oCiIFVwZGF0ZWQgUkZDIHJl ZmVyZW5jZXMgKDgyMDAsIDgyMDEsIDgyMjEsIDgyNDcpDQo+Pj4gCeKAoiBBZGRlZCBub3RlIG9u IFJGQyA3NzcyIGZvciBwb3dlciBjb25zdW1wdGlvbg0KPj4+IAnigKIgQWRkZWQg4oCYV2h5IC82 ND/igJkgcmVmZXJlbmNlOyBSRkMgNzQyMQ0KPj4+IAnigKIgUmVtb3ZlZCBqdW1ib2dyYW0gdGV4 dA0KPj4+IAnigKIgQWRkZWQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0DQo+Pj4gCeKAoiBGb3IgM0dQUCwgYWRkZWQg4oCYc25hcHNob3Ti gJkgY29tbWVudCBvbiBSRkM3MDY2DQo+Pj4gCeKAoiBBZGRlZCBSRkM4MDI4IGFzIGEgU0hPVUxE IChmb3IgU2VjdGlvbiA1LjUgZnJvbSBSRkMgNjcyNCkNCj4+PiAJ4oCiIFJlbW92ZWQgQVRNIG92 ZXIgSVB2Ng0KPj4+IAnigKIgQWRkZWQgcmVmZXJlbmNlIHRvIFJGQzgwNjQNCj4+PiAJ4oCiIEFk ZGVkIE1VU1QgZm9yIEJDUCAxOTgsIGFuZCByZWYgdG8gZHJhZnQtaWV0Zi12Nm9wcy1pcHY2cnRy LXJlcXMNCj4+PiAJ4oCiIEFkZGVkIHRleHQgb24gYXZvaWRpbmcgMTI4MCBNVFUgZm9yIFVEUCAo aW5jLiBETlMpIHRyYWZmaWMNCj4+PiBXZSdsbCBiZSBzZW5kaW5nIHNvbWUgYWRkaXRpb25hbCBx dWVzdGlvbnMgdG8gdGhlIGxpc3QgbGF0ZXIgdGhpcyB3ZWVrIHRvIGhvcGVmdWxseSBnZXQgdGhp cyBkb2N1bWVudCByZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0DQo+PiBjYWxsLg0KPj4+IA0K Pj4+IH5UaW0sIFRpbSBhbmQgSm9obg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tLS0tLS0g Rm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KPj4+IEZyb206IDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+DQo+Pj4gRGF0ZTogTW9uLCBPY3QgMzAsIDIwMTcgYXQgOTozNiBBTQ0KPj4+IFN1 YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMi50eHQNCj4+ PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+Pj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4+PiAN Cj4+PiANCj4+PiANCj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBNYWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi4NCj4+ PiANCj4+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBOb2RlIFJlcXVpcmVtZW50cw0K Pj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaW0gQ2hvd24NCj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgSm9obiBMb3VnaG5leQ0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBU aW1vdGh5IFdpbnRlcnMNCj4+PiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02 bWFuLXJmYzY0MzQtYmlzLTAyLnR4dA0KPj4+ICAgICAgICBQYWdlcyAgICAgICAgICAgOiA0MA0K Pj4+ICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTEwLTMwDQo+Pj4gDQo+Pj4gQWJzdHJh Y3Q6DQo+Pj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciBJUHY2IG5v ZGVzLiAgSXQgaXMgZXhwZWN0ZWQNCj4+PiAgIHRoYXQgSVB2NiB3aWxsIGJlIGRlcGxveWVkIGlu IGEgd2lkZSByYW5nZSBvZiBkZXZpY2VzIGFuZCBzaXR1YXRpb25zLg0KPj4+ICAgU3BlY2lmeWlu ZyB0aGUgcmVxdWlyZW1lbnRzIGZvciBJUHY2IG5vZGVzIGFsbG93cyBJUHY2IHRvIGZ1bmN0aW9u DQo+Pj4gICB3ZWxsIGFuZCBpbnRlcm9wZXJhdGUgaW4gYSBsYXJnZSBudW1iZXIgb2Ygc2l0dWF0 aW9ucyBhbmQNCj4+PiAgIGRlcGxveW1lbnRzLg0KPj4+IA0KPj4+ICAgVGhpcyBkb2N1bWVudCBv YnNvbGV0ZXMgUkZDIDY0MzQsIGFuZCBpbiB0dXJuIFJGQyA0Mjk0Lg0KPj4+IA0KPj4+IA0KPj4+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0 LWJpcy8NCj4+PiANCj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1y ZmM2NDM0LWJpcy0wMg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyDQo+Pj4gDQo+Pj4gQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDINCj4+PiANCj4+ PiANCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+PiANCj4+PiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+PiANCj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+IGlwdjZA aWV0Zi5vcmcNCj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+PiANCj4+ PiANCj4+PiAtLQ0KPj4+IE5vdyBvZmZlcmluZyB0ZXN0aW5nIGZvciBTRE4gYXBwbGljYXRpb25z IGFuZCBjb250cm9sbGVycyBpbiBvdXIgU0ROIHN3aXRjaCB0ZXN0IGJlZC4gTGVhcm4gbW9yZSB0 b2RheSBodHRwOi8vYml0Lmx5L1NETl9JT0xQUg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IC0tDQo+Pj4gTm93IG9mZmVyaW5nIHRlc3RpbmcgZm9yIFNETiBhcHBsaWNhdGlvbnMgYW5kIGNv bnRyb2xsZXJzIGluIG91ciBTRE4gc3dpdGNoIHRlc3QgYmVkLiBMZWFybiBtb3JlIHRvZGF5IGh0 dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBJRVRGIElQ djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+PiBpcHY2QGlldGYub3JnDQo+Pj4gQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2Ng0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KDQo= From nobody Mon Oct 30 16:46:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7616613F58C for ; Mon, 30 Oct 2017 16:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2To5vJOdTAn for ; Mon, 30 Oct 2017 16:46:26 -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 0E80413F588 for ; Mon, 30 Oct 2017 16:46:26 -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 v9UNkPMQ052357; Mon, 30 Oct 2017 16:46:25 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v9UNkGB1051928 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Oct 2017 16:46:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 30 Oct 2017 16:46:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 30 Oct 2017 16:46:15 -0700 From: "Templin, Fred L" To: Tim Chown CC: Timothy Winters , 6man WG Subject: RE: Updates to RFC6434 Thread-Topic: Updates to RFC6434 Thread-Index: AQHTUYUM7Yt7hhS0AUynTqYnnBzBvqL8yXlwgAB4SQD//4/toIAAe7AA//+N8dCAAKWTgP//iwfQ Date: Mon, 30 Oct 2017 23:46:15 +0000 Message-ID: <93f56f72a9f04a0998fd6fc1a5d7170a@XCH15-06-08.nw.nos.boeing.com> References: <647efa67a24f4511ab1968ec6c9227ac@XCH15-06-08.nw.nos.boeing.com> <27453115328b4e4f88c79bc3c989ad55@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 23:46:28 -0000 VGltLA0KDQpDb25zaWRlciBhbHNvIGFzIGEgc2Vjb25kIGV4YW1wbGUgdGhhdCBSRkM0ODYxLCBz ZWN0aW9uIDMuMSBnaXZlcw0KYSAiQ29tcGFyaXNvbiB3aXRoIElQdjQiLCBpbmNsdWRpbmcgY2l0 YXRpb25zIG9mIFJGQzgyNiBhbmQgb3RoZXINCnJlbGV2YW50IElQdjQgUkZDcy4NCg0KV2hlcmVh cyBSRkM4MjAwIGFuZCBSRkM0ODYxIGhhdmUgbXVsdGlwbGUgcGFyYWdyYXBocywgaG93ZXZlciwN CkkgdGhpbmsgcmZjNjQzNChiaXMpIGNhbiBtYWtlIGRvIHdpdGggcyBzaW5nbGUgc2VudGVuY2Ug bmVhciB0aGUNCmJlZ2lubmluZyBhcyBmb3IgUkZDODIwMC4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRpbSBDaG93biBbbWFpbHRvOlRp bS5DaG93bkBqaXNjLmFjLnVrXQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgNDoz MiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K PiBDYzogVGltb3RoeSBXaW50ZXJzIDx0d2ludGVyc0Bpb2wudW5oLmVkdT47IDZtYW4gV0cgPGlw djZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBVcGRhdGVzIHRvIFJGQzY0MzQNCj4gDQo+IEhp IEZyZWQsDQo+IA0KPiBXZSBjYW4gYWRkIHRoaXMgdG9waWMgdG8gdGhlIGxpc3Qgb2YgdGhpbmdz IHRvIGJlIHJhaXNlZCBpbiB0aGUgU2luZ2Fwb3JlIG1lZXRpbmcuDQo+IA0KPiBJZiBhbnlvbmUg ZWxzZSBoYXMgc3Ryb25nIHZpZXcgb24gdGhpcywgcGxlYXNlIGRvIHNob3V0IG5vdyB0aG91Z2gu DQo+IA0KPiBUaW0NCj4gDQo+ID4gT24gMzAgT2N0IDIwMTcsIGF0IDIwOjQ2LCBUZW1wbGluLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgVGlt LA0KPiA+DQo+ID4gSSBiZWxpZXZlIGl0IHNob3VsZCBiZSBjaXRlZCBpbiB0aGUgaW50cm9kdWN0 aW9uIGluIHRoZSBzYW1lIHdheSBhcw0KPiA+IFJGQzgyMDAgY2l0ZXMgUkZDNzkxLg0KPiA+DQo+ ID4gRnJlZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206 IFRpbSBDaG93biBbbWFpbHRvOlRpbS5DaG93bkBqaXNjLmFjLnVrXQ0KPiA+PiBTZW50OiBNb25k YXksIE9jdG9iZXIgMzAsIDIwMTcgMToyOCBQTQ0KPiA+PiBUbzogVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+PiBDYzogVGltb3RoeSBXaW50ZXJzIDx0d2lu dGVyc0Bpb2wudW5oLmVkdT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6 IFJlOiBVcGRhdGVzIHRvIFJGQzY0MzQNCj4gPj4NCj4gPj4gVGhhdCB3YXMgYSDigJhjb3VsZOKA mTsgSSB0aGluayB3ZSBzdWJzZXF1ZW50bHkgYWdyZWVkIGl0IHdhc27igJl0IG5lY2Vzc2FyeSwg Zm9yIHRoZSByZWFzb24gVGltIG1lbnRpb25lZD8NCj4gPj4NCj4gPj4gVGltDQo+ID4+DQo+ID4+ PiBPbiAzMCBPY3QgMjAxNywgYXQgMjA6MDYsIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGkgVGltLA0KPiA+Pj4NCj4gPj4+ IEkgYW0gcmVmZXJyaW5nIHRvIFRpbSBDaG93buKAmXMgcHJvcG9zZWQgcmVzb2x1dGlvbiB0byBt eSBvcmlnaW5hbCBjb21tZW50Og0KPiA+Pj4NCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzI4Mzk0Lmh0bWwNCj4gPj4+DQo+ID4+PiBU aW3igJlzIHByb3Bvc2FsIHdhcyB0byBjaXRlIFJGQzExMjIgaW4gdGhlIGludHJvLCB3aGljaCBJ IGFncmVlIHdvdWxkIGJlDQo+ID4+PiBhcHByb3ByaWF0ZS4NCj4gPj4+DQo+ID4+PiBUaGFua3Mg LSBGcmVkDQo+ID4+Pg0KPiA+Pj4gRnJvbTogVGltb3RoeSBXaW50ZXJzIFttYWlsdG86dHdpbnRl cnNAaW9sLnVuaC5lZHVdDQo+ID4+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMTI6 NDYgUE0NCj4gPj4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+ID4+PiBDYzogNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NCj4gPj4+IFN1YmplY3Q6IFJl OiBVcGRhdGVzIHRvIFJGQzY0MzQNCj4gPj4+DQo+ID4+PiBIaSBGcmVkLA0KPiA+Pj4NCj4gPj4+ IEkgdGhvdWdodCB3ZSBkZWNpZGVkIHdlIGRpZG4ndCB3YW50IHRvIHBvaW50IHRvIHRoZSBoaXN0 b3JpYyBJUHY0IHRleHQgaW4gdGhhdC4gIENhbiB5b3UgcmVtaW5kIG1lIHdlcmUgeW91IHdhbnRl ZCB0aGF0IHRleHQ/DQo+ID4+Pg0KPiA+Pj4gflRpbQ0KPiA+Pj4NCj4gPj4+IE9uIE1vbiwgT2N0 IDMwLCAyMDE3IGF0IDM6MzcgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4gd3JvdGU6DQo+ID4+PiBXZSB0YWxrZWQgYWJvdXQgYWRkaW5nIGFuIGluZm9ybWF0 aXZlIHJlZmVyZW5jZSB0byBSRkMxMTIyLiBDYW4NCj4gPj4+IHlvdSBwbGVhc2UgYWRkIHRoYXQ/ DQo+ID4+Pg0KPiA+Pj4gRnJlZA0KPiA+Pj4NCj4gPj4+IEZyb206IGlwdjYgW21haWx0bzppcHY2 LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW1vdGh5IFdpbnRlcnMNCj4gPj4+IFNl bnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyA2OjQzIEFNDQo+ID4+PiBUbzogNm1hbiBXRyA8 aXB2NkBpZXRmLm9yZz4NCj4gPj4+IFN1YmplY3Q6IFVwZGF0ZXMgdG8gUkZDNjQzNA0KPiA+Pj4N Cj4gPj4+IFdlIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiA2NDM0YmlzLCB3aXRo IHRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBQcmFndWU6DQo+ID4+PiAJ4oCiIFRleHQgb24g RUggcHJvY2Vzc2luZw0KPiA+Pj4gCeKAoiBOb3RlZCB0aGF0IFJGQzQxOTEgaXMgYSBNVVNULCBi dXQgYSBTSE9VTEQgZm9yIFR5cGUgQyBub2RlDQo+ID4+PiAJ4oCiIFVwZGF0ZWQgUkZDIHJlZmVy ZW5jZXMgKDgyMDAsIDgyMDEsIDgyMjEsIDgyNDcpDQo+ID4+PiAJ4oCiIEFkZGVkIG5vdGUgb24g UkZDIDc3NzIgZm9yIHBvd2VyIGNvbnN1bXB0aW9uDQo+ID4+PiAJ4oCiIEFkZGVkIOKAmFdoeSAv NjQ/4oCZIHJlZmVyZW5jZTsgUkZDIDc0MjENCj4gPj4+IAnigKIgUmVtb3ZlZCBqdW1ib2dyYW0g dGV4dA0KPiA+Pj4gCeKAoiBBZGRlZCByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QNCj4gPj4+IAnigKIgRm9yIDNHUFAsIGFkZGVkIOKAmHNu YXBzaG904oCZIGNvbW1lbnQgb24gUkZDNzA2Ng0KPiA+Pj4gCeKAoiBBZGRlZCBSRkM4MDI4IGFz IGEgU0hPVUxEIChmb3IgU2VjdGlvbiA1LjUgZnJvbSBSRkMgNjcyNCkNCj4gPj4+IAnigKIgUmVt b3ZlZCBBVE0gb3ZlciBJUHY2DQo+ID4+PiAJ4oCiIEFkZGVkIHJlZmVyZW5jZSB0byBSRkM4MDY0 DQo+ID4+PiAJ4oCiIEFkZGVkIE1VU1QgZm9yIEJDUCAxOTgsIGFuZCByZWYgdG8gZHJhZnQtaWV0 Zi12Nm9wcy1pcHY2cnRyLXJlcXMNCj4gPj4+IAnigKIgQWRkZWQgdGV4dCBvbiBhdm9pZGluZyAx MjgwIE1UVSBmb3IgVURQIChpbmMuIEROUykgdHJhZmZpYw0KPiA+Pj4gV2UnbGwgYmUgc2VuZGlu ZyBzb21lIGFkZGl0aW9uYWwgcXVlc3Rpb25zIHRvIHRoZSBsaXN0IGxhdGVyIHRoaXMgd2VlayB0 byBob3BlZnVsbHkgZ2V0IHRoaXMgZG9jdW1lbnQgcmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFz dA0KPiA+PiBjYWxsLg0KPiA+Pj4NCj4gPj4+IH5UaW0sIFRpbSBhbmQgSm9obg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0t DQo+ID4+PiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+Pj4gRGF0ZTogTW9u LCBPY3QgMzAsIDIwMTcgYXQgOTozNiBBTQ0KPiA+Pj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyLnR4dA0KPiA+Pj4gVG86IGktZC1hbm5vdW5jZUBp ZXRmLm9yZw0KPiA+Pj4gQ2M6IGlwdjZAaWV0Zi5vcmcNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuDQo+ID4+Pg0KPiA+Pj4g ICAgICAgIFRpdGxlICAgICAgICAgICA6IElQdjYgTm9kZSBSZXF1aXJlbWVudHMNCj4gPj4+ICAg ICAgICBBdXRob3JzICAgICAgICAgOiBUaW0gQ2hvd24NCj4gPj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICBKb2huIExvdWdobmV5DQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgVGlt b3RoeSBXaW50ZXJzDQo+ID4+PiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02 bWFuLXJmYzY0MzQtYmlzLTAyLnR4dA0KPiA+Pj4gICAgICAgIFBhZ2VzICAgICAgICAgICA6IDQw DQo+ID4+PiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMC0zMA0KPiA+Pj4NCj4gPj4+ IEFic3RyYWN0Og0KPiA+Pj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZv ciBJUHY2IG5vZGVzLiAgSXQgaXMgZXhwZWN0ZWQNCj4gPj4+ICAgdGhhdCBJUHY2IHdpbGwgYmUg ZGVwbG95ZWQgaW4gYSB3aWRlIHJhbmdlIG9mIGRldmljZXMgYW5kIHNpdHVhdGlvbnMuDQo+ID4+ PiAgIFNwZWNpZnlpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgSVB2NiBub2RlcyBhbGxvd3MgSVB2 NiB0byBmdW5jdGlvbg0KPiA+Pj4gICB3ZWxsIGFuZCBpbnRlcm9wZXJhdGUgaW4gYSBsYXJnZSBu dW1iZXIgb2Ygc2l0dWF0aW9ucyBhbmQNCj4gPj4+ICAgZGVwbG95bWVudHMuDQo+ID4+Pg0KPiA+ Pj4gICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgNjQzNCwgYW5kIGluIHR1cm4gUkZDIDQy OTQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLw0KPiA+Pj4NCj4gPj4+IFRoZXJlIGFyZSBh bHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPj4+IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDINCj4gPj4+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQt YmlzLTAyDQo+ID4+Pg0KPiA+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQo+ID4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+Pj4NCj4gPj4+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+Pj4gaXB2NkBp ZXRmLm9yZw0KPiA+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBOb3cgb2ZmZXJpbmcgdGVzdGluZyBmb3IgU0ROIGFw cGxpY2F0aW9ucyBhbmQgY29udHJvbGxlcnMgaW4gb3VyIFNETiBzd2l0Y2ggdGVzdCBiZWQuIExl YXJuIG1vcmUgdG9kYXkgaHR0cDovL2JpdC5seS9TRE5fSU9MUFINCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gTm93IG9mZmVyaW5nIHRlc3RpbmcgZm9yIFNETiBh cHBsaWNhdGlvbnMgYW5kIGNvbnRyb2xsZXJzIGluIG91ciBTRE4gc3dpdGNoIHRlc3QgYmVkLiBM ZWFybiBtb3JlIHRvZGF5IGh0dHA6Ly9iaXQubHkvU0ROX0lPTFBSDQo+ID4+Pg0KPiA+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+ Pj4gaXB2NkBpZXRmLm9yZw0KPiA+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pg0KDQo= From nobody Mon Oct 30 17:02:14 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B7A13FC7C for ; Mon, 30 Oct 2017 17:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vvj2YDeklG8L for ; Mon, 30 Oct 2017 17:01:29 -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 C12A5CEDE for ; Mon, 30 Oct 2017 17:01:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 12D942025C for ; Mon, 30 Oct 2017 20:02:13 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1B0A680D54 for ; Mon, 30 Oct 2017 20:01:25 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 00:01:32 -0000 --=-=-= Content-Type: text/plain Tim, Tim and John, thanks again for taking on 6434bis. Let me open a can of worms, now that the draft deadline has just passed :-) We argued lots in producing RFC8200 that one solution for inserting headers mid-way was to add an IPIP header. If we really think that this is operationally possible(*), then I think we need to write text in 6434bis to make it true. For some uses of IPIP-based header insertion there can be clearly a node (a router probably) which could then remove the newly inserted header, and the IPIP header added can be addressed to that node (%). This is an IPIP tunnel. I believe that LISP does something like this, and many of us are familiar with IPsec tunnel mode as well. For many other uses, the only obvious target for the IPIP header is the same destination address as what was originally there, and so a packet like: IP{src:A, dst: B} ULP becomes IP{src:D, dst: B} IP{src:A, dst: B} ULP And I think that most host stacks discard such things unless configured to expect a tunnel from D. What to do? I'd like to make it clear that the above construct is valid and that hosts SHOULD process it to remove the first IPIP hader and then process the packet as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard) There are also implications for security devices, but in most respects I don't think that they are different than for extension headers. As an aside, it would also be nice if we could say that an IPsec AH header with an unknown SPI should be skipped as if it wasn't even there (including any subsequent IP header as above..) This is essentially a similar situation. I suspect that this statement is even more controversial. (*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo explains how to do it within the controlled environment of an LLN. I spent half the morning putting final touches to that... (%)- for the cases where an "exit" node is easy to identify, and the traffic is guarantee to get to, doing a non-IPIP header insertion is even easier to argue for. Any arguments that the packet might "escape" being un-molested are arguments for why 6434bis has to deal with IPIP headers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln3vVQACgkQgItw+93Q 3WUGwQf/UesalgBQdI1RaD1X649fPxc4Uw9zaGein7/cgxMRcXlRVPk6khtY/xxj wU3kBTaErXfwRdkkFddRBps/Sl5Ht/zGxJ+1JumPcGZ7DSC22IoTWabARuQQUyqv 7bR+8TlpVCzxgPNOghZosW2JK0bKsRTHbyQ8OxiYj/EkdsZlsIJtoKPISSZw/J3t /Cul2KcNavpAtvvEG+/lWL9j2r6lY0Np92eowyASEDEiMTtHZ24970kMGf8kSTWo wFHSFO7EpvYCK2Vgv03GvfGSiGjpF0w1C6uwViM7FSrLLS9HpDFJSnXLph96TFGv RCegp6lRzDIO371prhKmpUJJZc9pXw== =uOEk -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 30 18:08:22 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9013F9B9 for ; Mon, 30 Oct 2017 18:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpucbPbtmOgc for ; Mon, 30 Oct 2017 18:08:19 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCB813FB60 for ; Mon, 30 Oct 2017 18:08:19 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id g6so13188067pgn.6 for ; Mon, 30 Oct 2017 18:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6/lIXJWPJs1M52r8JXQHX2dPUdViKnKuarG8mO+6cYs=; b=HioffBd+4g+s+qQ5QmziT6aGgksk1QdBfBPbmd9St6ziWasHmsd/RrtiyDVc53rF0j 7ON073pirqzMPKq5wc+wFuECl4+H2DjbMxEpV68PTvGY4Z8IjHk+SYnIK8lXUK9l7tmq GqZWdFwaqcewVbNLNIzvxrV8zAd+YKi9nYv1vHwC64bHBYQuMEaw+76YTRh0BQVqGhjA SylLKPhjPMGS7R+Gu/9zFPjFmpL0PtAfiUPPSLoiJojIJM6HUjD+StJCY707VZhWFKeP YxDVJUK3XVBgA9iqGPAOJroUG4a1HYD/oW5+JUKMVeoIbItawbtK8aUaUcF/8B0V4LVc zfuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6/lIXJWPJs1M52r8JXQHX2dPUdViKnKuarG8mO+6cYs=; b=PmTHzdkpSzlhEF+DYs+cjO1sbhy1dHvbTbfT4zDlW63Ho/CHwxtp6TMgfq9RK2qADJ U+eRT57JENc3j/vtgFRGLlDZNNKGoz75Fh5TcFb7lgHoqkUK6yFafXOpR/761nJzusQ7 VSLbDfpYgW1beWCFRzjl7dG1crqIZ773tVIMUKl9h1MpY3372vcTznOsjx3ebUQFwce3 Zlo+mGyYMrjNFEb3nFHcO+LLb65tr0O4jQDsRVBhdmbnrwVDccPcLnzz4OOEZylNjJ88 /Cxv3V/mUTFuIAEvpyw7jOEPN83TisGtisfxiKEIWnP3ua5odGN2I7iUj1PNk83GT4ll wAlg== X-Gm-Message-State: AMCzsaW0h9W7pl/ctBnoVa3tG+RLsvqGG7l9sKos71bXGw/YNtwVbn5n 5LEZfOBsjMhoa3sjQ3VvCOidPw== X-Google-Smtp-Source: ABhQp+S3Ti3c0Z8bOr5E619K4Ghek6DUfXrowLEz3XtT004zqqpdiQwtccCJAgMEUFU4tctH5vi6NA== X-Received: by 10.84.133.227 with SMTP id f90mr226597plf.402.1509412097149; Mon, 30 Oct 2017 18:08:17 -0700 (PDT) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g16sm248506pfd.87.2017.10.30.18.08.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 18:08:16 -0700 (PDT) Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: Michael Richardson , 6man WG References: <6286.1509408085@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 31 Oct 2017 14:08:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6286.1509408085@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 01:08:21 -0000 Hi Michael, I think this is an interesting topic but I'd really rather seprate it from 6434bis, because we need 6434bis as soon as reasonably possible, and this will take a while. We've got ourselves into trouble at least twice with automatic tunnels. I'm referring to 6to4 (where I share the blame) and Teredo. They were both IPv6inIPv4 but I think some of the same risks will arise with IPv6inIPv6. There may be contexts where automatic decapsulation is safe and makes sense. There may be others where it generates either operational black holes or enticing security loopholes. So I think this needs to be worked as a separate topic, and I look forward to your draft... :-) Brian On 31/10/2017 13:01, Michael Richardson wrote: > > Tim, Tim and John, thanks again for taking on 6434bis. > > Let me open a can of worms, now that the draft deadline has just passed :-) > > We argued lots in producing RFC8200 that one solution for inserting headers > mid-way was to add an IPIP header. If we really think that this is > operationally possible(*), then I think we need to write text in 6434bis to make > it true. > > For some uses of IPIP-based header insertion there can be clearly a node (a > router probably) which could then remove the newly inserted header, and the > IPIP header added can be addressed to that node (%). This is an IPIP tunnel. I > believe that LISP does something like this, and many of us are familiar with > IPsec tunnel mode as well. > > For many other uses, the only obvious target for the IPIP header is the same > destination address as what was originally there, and so a packet like: > IP{src:A, dst: B} ULP > > becomes > IP{src:D, dst: B} IP{src:A, dst: B} ULP > > And I think that most host stacks discard such things unless configured to > expect a tunnel from D. > > What to do? > > I'd like to make it clear that the above construct is valid and that hosts > SHOULD process it to remove the first IPIP hader and then process the packet > as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard) > > There are also implications for security devices, but in most respects I > don't think that they are different than for extension headers. > > As an aside, it would also be nice if we could say that an IPsec AH header > with an unknown SPI should be skipped as if it wasn't even there (including > any subsequent IP header as above..) This is essentially a similar > situation. I suspect that this statement is even more controversial. > > (*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo > explains how to do it within the controlled environment of an LLN. > I spent half the morning putting final touches to that... > > (%)- for the cases where an "exit" node is easy to identify, and the traffic > is guarantee to get to, doing a non-IPIP header insertion is even easier > to argue for. Any arguments that the packet might "escape" being > un-molested are arguments for why 6434bis has to deal with IPIP headers. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Oct 30 18:23:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CF813F651 for ; Mon, 30 Oct 2017 18:23: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, 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 OXCmuMUtbLFV for ; Mon, 30 Oct 2017 18:23:29 -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 1804513F570 for ; Mon, 30 Oct 2017 18:23:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 49DD72025E; Mon, 30 Oct 2017 21:24:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 22C2380D54; Mon, 30 Oct 2017 21:23:28 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: <6286.1509408085@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 01:23:31 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I think this is an interesting topic but I'd really rather > seprate it from 6434bis, because we need 6434bis as soon > as reasonably possible, and this will take a while. Well, I tried to raise this while doing 8200, and was told that I should wait until we got to host requirements. I'm inclined to file an errata against 8200 if 6463bis proceeds without dealing with the issue. > We've got ourselves into trouble at least twice with > automatic tunnels. I'm referring to 6to4 (where I share the > blame) and Teredo. They were both IPv6inIPv4 but I think > some of the same risks will arise with IPv6inIPv6. There may > be contexts where automatic decapsulation is safe and makes > sense. There may be others where it generates either operational > black holes or enticing security loopholes. > So I think this needs to be worked as a separate topic, and > I look forward to your draft... :-) I can write a draft. I will write it to update 6463. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln30I8ACgkQgItw+93Q 3WUoyQgAweSAfFOATnHIjtGt/pGNjljjAXIpkIZR5cjWTgsePnuVpH4wG197SSc6 MGqi5I5/0DJnUPzvKgKRt2HlazE1zXSM6w8E2RL0AV1BU8VN+QLdpPhc/WMf7/fo H2hjxHjnKy209oDqGLW7rGJUCPUmszeWx0uyK5XrpXwXLVfAwVfwK9PQrYpBDgEO 0W5fEMDOCbOCjvJZp/qKZGxk2DiI7GUwzoVOMDDAezAkmh9KRWqTB2EOnYwpNnTE onpY4+y8vITU+T6ge2fDD1EvFeG27/WmHMedTJCojq3wwM4pF3gW3hp9x31A/OXE qN+6Tu0idNKp1bq83WyERr7cuWO+bA== =QTY9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 31 01:13:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7529F1398CA for ; Tue, 31 Oct 2017 01:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEronH9iiwMY for ; Tue, 31 Oct 2017 01:13:39 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 D94E9138A4C for ; Tue, 31 Oct 2017 01:13:38 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id g11so9760372vkd.13 for ; Tue, 31 Oct 2017 01:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4qkzu3iG9VxGk+gzJj8skJN6I+VlrEq9DokqDo9UnE=; b=Nbnv3ZiVYN567LCHIBj9VcqvbvLwWMSOz3jPbxkeqeFC5Dx+g6/zxeJaCqHK+gz1gy 1uSm+DenHjfr+a/dIz+RrscCfaEtt84HUxN3BUqmvBTv31OytuZRpr5tLya7jy3P8cVz +Xhpi9lDB3n40cckcBfYKpFRmVHCSZPDd4MRhuG3xk3MzMRhrubr0h7ij9kqfKUZBMVw pFErLKeAMjUhkRKxWyT6s/UTEbQVZ4HPVsnxw/wGjhQHsoKtqbtzELRPL4+nUR0m+9q8 v1CfxtaMSdhROHpxASj+zB7Eow5xfv+bF+f90mKFaSd3vM1vKDezIqglhmZpspqCZ/OH MWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I4qkzu3iG9VxGk+gzJj8skJN6I+VlrEq9DokqDo9UnE=; b=sgQAfh5JNHDDuguG8X4l+020Bf4JtwCM8mA2Bm0a92sV6rrPCMIqpByvVfatNfpmo/ vh2h57HspjZlCvj+WQ4bCdakJ5KFTq9hJMXRpw7JdmM3skIxybMPKKVUoH3OGH89QiUm 8Up53kAuQ1N3U9cLQrYOHhGUV6A22XnxjtdmiXG1vPpU/S2rHIR5R2iMioukTypSlUcy iDxwbXfCnNgF1Y/T35kDfEH0eDewrO8b+3Nd9K1QBAWFiFb5doATOn6KSoN28jva6dg8 y4MlT4Lrzg9LecUoY1LecIgn9AZz8ekDCYvus2ltzBKvYKYoHos3b2j3DEeNxWPwN3QG uplQ== X-Gm-Message-State: AMCzsaUVocmQI1BXD1ChLJbEyp2r8rnd2EejPUC4KXCrSCsWUKeTC+Jw 8uCr/4H+pe9dtKnDIB1geWSReXjw/Vnqj4ceA7Q= X-Google-Smtp-Source: ABhQp+SvxihNuvXuh3zKqpkoTTLg57+s29qZYcvfyxPOGHPcmy27UkkVqBz+yAteoEgEZMU4CqTw2/CWruURJB9N0Mo= X-Received: by 10.31.209.7 with SMTP id i7mr741381vkg.11.1509437617678; Tue, 31 Oct 2017 01:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Tue, 31 Oct 2017 01:13:36 -0700 (PDT) Received: by 10.159.52.221 with HTTP; Tue, 31 Oct 2017 01:13:36 -0700 (PDT) In-Reply-To: <6286.1509408085@obiwan.sandelman.ca> References: <6286.1509408085@obiwan.sandelman.ca> From: Mark Smith Date: Tue, 31 Oct 2017 19:13:36 +1100 Message-ID: Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: Michael Richardson Cc: 6man WG Content-Type: multipart/alternative; boundary="001a114e2da6032f0e055cd355a8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:13:41 -0000 --001a114e2da6032f0e055cd355a8 Content-Type: text/plain; charset="UTF-8" On 31 Oct. 2017 11:02, "Michael Richardson" wrote: Tim, Tim and John, thanks again for taking on 6434bis. Let me open a can of worms, now that the draft deadline has just passed :-) We argued lots in producing RFC8200 that one solution for inserting headers mid-way was to add an IPIP header. If we really think that this is operationally possible(*), then I think we need to write text in 6434bis to make it true. For some uses of IPIP-based header insertion there can be clearly a node (a router probably) which could then remove the newly inserted header, and the IPIP header added can be addressed to that node (%). This is an IPIP tunnel. I believe that LISP does something like this, and many of us are familiar with IPsec tunnel mode as well. For many other uses, the only obvious target for the IPIP header is the same destination address as what was originally there, and so a packet like: IP{src:A, dst: B} ULP becomes IP{src:D, dst: B} IP{src:A, dst: B} ULP And I think that most host stacks discard such things unless configured to expect a tunnel from D. What to do? I'd like to make it clear that the above construct is valid and that hosts SHOULD process it to remove the first IPIP hader and then process the packet as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard) I don't think this decapsulation is forwarding. Forwarding is really just what to do when receiving a packet with a DA that doesn't match the device's address(es). Hosts drop them, routers see what the forwarding table says to do with them. The processing you're describing is passing the payload, post decapsulation, to the payload processing module indicated by the payload type field in the previous header. In the case of IPinIP, the host supports the payload type of IPinIP or protocol 4, and knows that a payload of that type gets submitted to the IPv4 packet processing module. If the DA of the payload IP packet matches the host's, then it should be processed the same way as the former outer packet was. IPinIPinIP should be processed the same way as IPinIP. Regards, Mark. There are also implications for security devices, but in most respects I don't think that they are different than for extension headers. As an aside, it would also be nice if we could say that an IPsec AH header with an unknown SPI should be skipped as if it wasn't even there (including any subsequent IP header as above..) This is essentially a similar situation. I suspect that this statement is even more controversial. (*)- I think it's operationally possible, and draft-ietf-roll-useofrplinfo explains how to do it within the controlled environment of an LLN. I spent half the morning putting final touches to that... (%)- for the cases where an "exit" node is easy to identify, and the traffic is guarantee to get to, doing a non-IPIP header insertion is even easier to argue for. Any arguments that the packet might "escape" being un-molested are arguments for why 6434bis has to deal with IPIP headers. -- 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 -------------------------------------------------------------------- --001a114e2da6032f0e055cd355a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 31 Oct. 2017 11:02, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:

Tim, Tim and John, thanks again for taking on 6434bis.

Let me open a can of worms, now that the draft deadline has just passed :-)=

We argued lots in producing RFC8200 that one solution for inserting headers=
mid-way was to add an IPIP header.=C2=A0 =C2=A0If we really think that this= is
operationally possible(*), then I think we need to write text in 6434bis to= make
it true.

For some uses of IPIP-based header insertion there can be clearly a node (a=
router probably) which could then remove the newly inserted header, and the=
IPIP header added can be addressed to that node (%).=C2=A0 =C2=A0This is an= IPIP tunnel.=C2=A0 I
believe that LISP does something like this, and many of us are familiar wit= h
IPsec tunnel mode as well.

For many other uses, the only obvious target for the IPIP header is the sam= e
destination address as what was originally there, and so a packet like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP{src:A, dst: B} ULP

becomes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP{src:D, dst: B} IP{src:A, dst: = B} ULP

And I think that most host stacks discard such things unless configured to<= br> expect a tunnel from D.

What to do?

I'd like to make it clear that the above construct is valid and that ho= sts
SHOULD process it to remove the first IPIP hader and then process the packe= t
as normal, even if "forwarding" is off. (If inner dst: is *NOT* B= , then discard)

I don't think this decapsulation is forwarding. Fo= rwarding is really just what to do when receiving a packet with a DA that d= oesn't match the device's address(es). Hosts drop them, routers see= what the forwarding table says to do with them.
The processing you're describing is passing th= e payload, post decapsulation, to the payload processing module indicated b= y the payload type field in the previous header.
In the case of IPinIP, the host supports the paylo= ad type of IPinIP or protocol 4, and knows that a payload of that type gets= submitted to the IPv4 packet processing module. If the DA of the payload I= P packet matches the host's, then it should be processed the same way a= s the former outer packet was. IPinIPinIP should be processed the same way = as IPinIP.

Regards,
Mark.



There are also implications for security devices, but in most respects I don't think that they are different than for extension headers.

As an aside, it would also be nice if we could say that an IPsec AH header<= br> with an unknown SPI should be skipped as if it wasn't even there (inclu= ding
any subsequent IP header as above..)=C2=A0 This is essentially a similar situation.=C2=A0 I suspect that this statement is even more controversial.<= br>
(*)- I think it's operationally possible, and draft-ietf-roll-useofrpli= nfo
=C2=A0 =C2=A0 =C2=A0explains how to do it within the controlled environment= of an LLN.
=C2=A0 =C2=A0 =C2=A0I spent half the morning putting final touches to that.= ..

(%)- for the cases where an "exit" node is easy to identify, and = the traffic
=C2=A0 =C2=A0 =C2=A0is guarantee to get to, doing a non-IPIP header inserti= on is even easier
=C2=A0 =C2=A0 =C2=A0to argue for.=C2=A0 Any arguments that the packet might= "escape" being
=C2=A0 =C2=A0 =C2=A0un-molested are arguments for why 6434bis has to deal w= ith IPIP headers.

--
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
-----------------------------------------------------------------= ---


--001a114e2da6032f0e055cd355a8-- From nobody Tue Oct 31 01:30:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4F413F6B7 for ; Tue, 31 Oct 2017 01:30:08 -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 jJjurGn4nRnB for ; Tue, 31 Oct 2017 01:30:07 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D55913F6B9 for ; Tue, 31 Oct 2017 01:30:06 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 67FD82D50BC; Tue, 31 Oct 2017 08:30:06 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 96C67200823210; Tue, 31 Oct 2017 09:30:04 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DE934B9D-050A-4557-ADEC-A07C98978884"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP Date: Tue, 31 Oct 2017 09:30:03 +0100 In-Reply-To: <25055.1509413008@obiwan.sandelman.ca> Cc: Brian E Carpenter , 6man WG To: Michael Richardson References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 08:30:09 -0000 --Apple-Mail=_DE934B9D-050A-4557-ADEC-A07C98978884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, Without having thought very much about it... I do think requiring a host = to accept tunnelled packets to itself by default or not, requires = further considerations. I am aware of no implementation that would support this. I would also be = worried about this opening the door for "alternate" paths into the host = stack. I think you would have to write a draft. Another aspect of IP in IP is that with the recent troubles we have with = doing path MTU discovery and fragmentation at the Internet layer, that = might not be the optimal encapsulation for tunnelling anymore. Best regards, Ole > On 31 Oct 2017, at 02:23, Michael Richardson = wrote: >=20 >=20 > Brian E Carpenter wrote: >> I think this is an interesting topic but I'd really rather >> seprate it from 6434bis, because we need 6434bis as soon >> as reasonably possible, and this will take a while. >=20 > Well, I tried to raise this while doing 8200, and was told that I = should wait > until we got to host requirements. >=20 > I'm inclined to file an errata against 8200 if 6463bis proceeds = without > dealing with the issue. >=20 >> We've got ourselves into trouble at least twice with >> automatic tunnels. I'm referring to 6to4 (where I share the >> blame) and Teredo. They were both IPv6inIPv4 but I think >> some of the same risks will arise with IPv6inIPv6. There may >> be contexts where automatic decapsulation is safe and makes >> sense. There may be others where it generates either operational >> black holes or enticing security loopholes. >=20 >> So I think this needs to be worked as a separate topic, and >> I look forward to your draft... :-) >=20 > I can write a draft. > I will write it to update 6463. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_DE934B9D-050A-4557-ADEC-A07C98978884 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAln4NIsACgkQvtpYqJhC 33Y9VQ/+LZ5iGz+Wnp+giHqmZ8skH6VytHfZI+qJosJOY9IFT+7KEKe2oOWfqj52 FlwnAw6Fhn5/27s6CP3ROYCONQsyYfXKsaSJ64OPTg/tZHYDYRgjyk4MpF74vSqO lty/dIuO/KUPyfKvdJ47igsRC/R5Kyl2u4EiDTg1tcA6auso1uZ+c7UM7kaVyn8v vpX5UyWgibBigAo8gWM1wjk1XorguhZOhKuH16RpZEUz8KhBfVZcVqDc59b5qYLn 6bWmeox/VbVP6JDb/j3GsU5zxaUFpepS7WnKYBzO7z+rflq68RdUmLlj6wojzgTe othtVM5KVcgecEy25sApCZVdg7ITc49Xya1FJ6H/fDao0Nb4hAoTKga514pfJzlD ThsGGsFnuafFlpkHBqO70wo0px+0fWx1HP/krekIl/hgntNES+OL8u1voa6C7Id6 yWXal/yKwSi6IGHH01nCC2wi7X7aZHxS30E4kIkQ7iWvCj8jXYDrKy/ivbBwQ1Wz fGBwxdUymlkwTcHMr+ZSxQZMxR9F17t9VfT9Dbcr0TpfXrJFj3VjKPyt7dCljrOi 5itXIPeq86lS9SpQInV6iwJKER2d2OOTfnqGFaVWrTy2P5EJqmgTNWALkwTcouCr jzXCTMO1cozAQaWNswFyGxTq4PiOPPAb8H9/ZDNPK5Wf/S+Ldfo= =X2p+ -----END PGP SIGNATURE----- --Apple-Mail=_DE934B9D-050A-4557-ADEC-A07C98978884-- From nobody Tue Oct 31 02:15:29 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9013F5D7 for ; Tue, 31 Oct 2017 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 h0I99bUzqAWS for ; Tue, 31 Oct 2017 02:15:25 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209C413F621 for ; Tue, 31 Oct 2017 02:15:25 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l32so14088493ywh.13 for ; Tue, 31 Oct 2017 02:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nOXyC+7/gBssmWGF+tzFl4pQuPTDqZdJ4f78RO2Zvto=; b=kSt8fcgDIKUvoK7FQnR1IgMT82LbNhA3KgO75cCdiCME2tPzmnf5mKffi3C/6s76OS q+IMgz0ROPmiFt58oAbpv4epl7mAsHG3MKGkU0Dh9gYVXflTOb1iu8j/76RPlji6Pv4S nk8ObScUrzKQhoHyieAG4xqTUWjGtKLTmWc5HT2/PzpGbRFsEBuvT1rkhosyvtCaZwYL JIk9HGr2MPSSc7hYFv053bdDt8oblS9Uqr4G4PBua0VzPWsklgUAHGcySdb3RrOT2O3g n5L4wRaTQNvqtXbxaMFklgwUgEUId5W1NFj7pWWPV8WiQOK3Ha7r8THNXi876YrdFLMW FJ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nOXyC+7/gBssmWGF+tzFl4pQuPTDqZdJ4f78RO2Zvto=; b=DSlJfUb0hjgIuYQJbDKFdWt/ujste6qtcrmjBGC36yyhm5flETNfEwNrK4AOHojb6j exD12Lht6hNE1Jr9A0nu3iU0oP6nsQZ3QyJqlyeiiY4o0iU2a5kQSIGBwmcwO3+M3wIr vTtz+Z4bW0grVIgak/LgTzWXDGfReKjOfYkA+8q4zGQQTPFWrnIHhwH7Di2st54rQA6U ulzQeGU59/H1JBf2UXu5b3dFiCKZVpU3P/+czh+36a8hjWNB13PaZrAalhiZMQZGxPvA TaavV/XM7it4z1UwmAl49VryCf5T/KsNbFKjEKoYTRncGhgImhu7xZKRem/CZi/qd8aT NW+A== X-Gm-Message-State: AMCzsaWz+uekgMS1gcSLrf7bgjFJuzmcl0+vh1lctXWlo1qfL8wf/rKc QljtCJhVqwfj1oejVRuWcMOWTY8VRRKGTOO97QNMwA== X-Google-Smtp-Source: ABhQp+Qux0MZ5SaRbuQSNJAqBBbKleJIQ+yqMi7I08N5CTGCChMqrTXZ7AEe7VpcaRUxEWHEyyUPl84xa1NnMWLyueU= X-Received: by 10.37.186.203 with SMTP id a11mr704187ybk.460.1509441323913; Tue, 31 Oct 2017 02:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.14.196 with HTTP; Tue, 31 Oct 2017 02:15:03 -0700 (PDT) In-Reply-To: References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> From: Erik Kline Date: Tue, 31 Oct 2017 18:15:03 +0900 Message-ID: Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: Ole Troan Cc: Michael Richardson , 6man WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043deec8f5d2df055cd431fe" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 09:15:28 -0000 --f403043deec8f5d2df055cd431fe Content-Type: text/plain; charset="UTF-8" This would certainly complicate tracking ingress interface and applying rules that require ingress interface information to apply correctly. Blech. On 31 October 2017 at 17:30, Ole Troan wrote: > Michael, > > Without having thought very much about it... I do think requiring a host to accept tunnelled packets to itself by default or not, requires further considerations. > > I am aware of no implementation that would support this. I would also be worried about this opening the door for "alternate" paths into the host stack. > I think you would have to write a draft. > > Another aspect of IP in IP is that with the recent troubles we have with doing path MTU discovery and fragmentation at the Internet layer, that might not be the optimal encapsulation for tunnelling anymore. > > Best regards, > Ole > >> On 31 Oct 2017, at 02:23, Michael Richardson wrote: >> >> >> Brian E Carpenter wrote: >>> I think this is an interesting topic but I'd really rather >>> seprate it from 6434bis, because we need 6434bis as soon >>> as reasonably possible, and this will take a while. >> >> Well, I tried to raise this while doing 8200, and was told that I should wait >> until we got to host requirements. >> >> I'm inclined to file an errata against 8200 if 6463bis proceeds without >> dealing with the issue. >> >>> We've got ourselves into trouble at least twice with >>> automatic tunnels. I'm referring to 6to4 (where I share the >>> blame) and Teredo. They were both IPv6inIPv4 but I think >>> some of the same risks will arise with IPv6inIPv6. There may >>> be contexts where automatic decapsulation is safe and makes >>> sense. There may be others where it generates either operational >>> black holes or enticing security loopholes. >> >>> So I think this needs to be worked as a separate topic, and >>> I look forward to your draft... :-) >> >> I can write a draft. >> I will write it to update 6463. >> >> -- >> 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 > -------------------------------------------------------------------- > --f403043deec8f5d2df055cd431fe Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgKGX58s77/Z03tDFzL2I3Wj+U5MvupJuu EwkE2l4U8FswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDMx MDkxNTI0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADwN/nhaCf9a6AwJlPhmbeacobesdGwMw2MNqfyKzpO9Z8CXbrR7 BJ9NzAEXJlwrM4CJrBFD5xa0LE+DxkRye1zAg0Kis8KnAs7CnIXPAYc+ttBhe0PJ1IDLHquiaXg9 8Adw2UHwQRlpuXiHNxIVZhmjydynZNg/De74aY48TmocbeiUasVUmKtJiN0ryjrcfHulySkJv8Cc j0WGg+IMEHBpPOWPzELyoemOss+RsU3ZvsA/Atyxa/f2cIe3kHfWrQcPox+DWB4iDbEzQeY4BSem QAmr45dFZHEG9hjcosaFsUNZOvTNONOyvxMguhlQQq4gXwmxu2CxywVGWbjuEFo= --f403043deec8f5d2df055cd431fe-- From nobody Tue Oct 31 12:03:28 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9557A138FA0 for ; Tue, 31 Oct 2017 12:03:26 -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 mGDJnd9SDh27 for ; Tue, 31 Oct 2017 12:03:16 -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 600D113F686 for ; Tue, 31 Oct 2017 12:02:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4DCBE2024A for ; Tue, 31 Oct 2017 15:03:30 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 996D681694 for ; Tue, 31 Oct 2017 15:02:39 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 19:03:26 -0000 --=-=-= Content-Type: text/plain Ole Troan wrote: > Without having thought very much about it... I do think requiring a > host to accept tunnelled packets to itself by default or not, requires > further considerations. I agree: it requires further consideration. > I am aware of no implementation that would support this. I would also > be worried about this opening the door for "alternate" paths into the > host stack. I agree. Nobody does it this way. Yet 8200 (and 2460 before it) says that this is the way to insert headers. One of 6463 or 2460/8200 must be wrong. Essentially 8200 says to do something that doesn't work. Should we be at all surprised that there is was much push to do it a different way? If we don't fix 6434 to make it work, then our hard fought compromise in 8200 is moot. ps: I'm not advocating for changing 8200. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln4yM8ACgkQgItw+93Q 3WXcVgf/TVJi9znFkqCV8J8zDuRGwefnRs3FxXU0rL+r/ebgEHxAtqfAKdRixJob BwxG5OPBlZPGNTNTA2XvmI9qYNnFtzfToh9v8d3bcj1dj1q0NyTrfSiyhufnjj+b 7VT3wJSDKOxJgz2ffluqtMjcwBKyGh4cx7Yq+LGbcR7AiwcoNioYmZfdtfPx0Uyq LcvUggAq91a5w87Ijp8yDfCa2cooc7cuCXFAGsL3qVrfEGzZpIUol9xFgkfUJKKU pg6GmMJgWKB1NltrqtGSHs4Bp2NpTlU8EKVDxo9nFeGDIYzzPNx9E7Vf5QHOmueo y4yyS4G7/EzH+7lZZmMc9NakVJuzpQ== =DYWR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 31 18:29:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525513F5B9 for ; Tue, 31 Oct 2017 18:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f74RirXNIwhT for ; Tue, 31 Oct 2017 18:29:24 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E665713F586 for ; Tue, 31 Oct 2017 18:29:23 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id n22so565299uaj.13 for ; Tue, 31 Oct 2017 18:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SRkML/hOu68kbcCnFYlG3tK/muE/7i6MtDqqgmqak/c=; b=n34S4jDI5fPPA9EpHfPyNYvNC6RoiXTQLRto5/+Zp9JEHLncQsPa25nR+8+CNasLaC G/h5G0zYUUA8BLQ1ZUBF7jee/WJOpVz3GFYRthB++cJHoO4sEMqkLvAnNl3hBVGg1uQ5 00cfbDJ+AXYu2FSRegk40IdFDLkhlkgM1d+88+R5bpNdNWNjK1iBwyQPmzbP1ZAx3oO9 ImS18YiDiDMPPnLCyBFW2kLKRKm2LtADNbMMkD4PPoWjTQVH2OT14X7F7USKTl28Vf+k 58IWBjPRJXv3pGhb2JURUDInjXyMgH15hsYJJzH+2EHoM9gr2EW9qwoDFIXYLEmSlzii CG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SRkML/hOu68kbcCnFYlG3tK/muE/7i6MtDqqgmqak/c=; b=MtKnhaPMOiE6Km0vkESLP9eaD1Jzu7JvhxY26PrY0WlWJbjJaqRcGxXCiG8TP8SlJ2 X0PtY6hp75qOpX/2wHBgJRGmRV/iw4HTMWtQWVVALXFxNFkHYHmD3PX67RLeEX7Vvt5J TY8vpQgoOQ9+GlFBE4zmFfB5sFE9Uxu0XFhYqs3JLwp/yhMJ5ywYVEzfeFy9nzhNAUp5 3GvFDm82DceKjsXb1yNUQQRubFUTJU8qKO9VFpsGepSmfUnLAlw3a6O95Tks5dli0Pa5 ACo+iE8WdjAFWCBhtdtP7r6vEvdBsa/yw6nd4EMx68ql8FXLN8GoIiPRxoh+JoTj81hp XI6w== X-Gm-Message-State: AMCzsaUH0m/W7KypWAMMBWvq2U5anGba3FzTN8oXxpdOO/mRWuHkYecc eQkiQvl4AvuK1+z6kBf07LmAFkMGE2Tr0/61h7g= X-Google-Smtp-Source: ABhQp+TpmyDbrAzER9XPJHJiUanHlCKAwQbyHHH/xE0Kiyab9H1wcBcgFwySMXXCnb1W/bhv3cBJrELwcUC5F60NYf8= X-Received: by 10.176.74.15 with SMTP id q15mr3257653uae.120.1509499762840; Tue, 31 Oct 2017 18:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Tue, 31 Oct 2017 18:29:22 -0700 (PDT) Received: by 10.159.52.221 with HTTP; Tue, 31 Oct 2017 18:29:22 -0700 (PDT) In-Reply-To: <19111.1509476559@obiwan.sandelman.ca> References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> <19111.1509476559@obiwan.sandelman.ca> From: Mark Smith Date: Wed, 1 Nov 2017 12:29:22 +1100 Message-ID: Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: Michael Richardson Cc: 6man WG Content-Type: multipart/alternative; boundary="f403045f6d2c271848055ce1cd4d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 01:29:26 -0000 --f403045f6d2c271848055ce1cd4d Content-Type: text/plain; charset="UTF-8" On 1 Nov. 2017 06:03, "Michael Richardson" wrote: Ole Troan wrote: > Without having thought very much about it... I do think requiring a > host to accept tunnelled packets to itself by default or not, requires > further considerations. I agree: it requires further consideration. > I am aware of no implementation that would support this. I would also > be worried about this opening the door for "alternate" paths into the > host stack. I agree. Nobody does it this way. Yet 8200 (and 2460 before it) says that this is the way to insert headers. I think we need to be clear about what is "inserting" is. To me, the word "inserting" means inserting to into something that already exists and has previously been created - cut apart, insert, glue back together. IPinIP in the network is not doing insertion. It is adding by encapsulating with a new IP header. That's the way we add information at all other layers of the stack. IPinIP in a host is, for some reason or other, not encoding all of the information in the first IP header, so it adds another one to carry it. IPsec tunnel mode would be an example. IPsec transport mode isn't "inserting" either. The host sending the IPsec transport mode packet builds the entire thing, and adds the AH/ESP header at the appropriate time during the encapsulation process as the IPsec packet is built before being put on the wire. So truly "inserting" (cut, insert, glue) into an existing packet is not something that has been part of any IETF protocol as far as I'm aware. Regards, Mark. One of 6463 or 2460/8200 must be wrong. Essentially 8200 says to do something that doesn't work. Should we be at all surprised that there is was much push to do it a different way? If we don't fix 6434 to make it work, then our hard fought compromise in 8200 is moot. ps: I'm not advocating for changing 8200. -- 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 -------------------------------------------------------------------- --f403045f6d2c271848055ce1cd4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 1 Nov. 2017 06:03, "Michael Richardson" <mcr+ietf@sandelman.ca= > wrote:

Ole Troan <otr= oan@employees.org> wrote:
=C2=A0 =C2=A0 > Without having thought very much about it... I do think = requiring a
=C2=A0 =C2=A0 > host to accept tunnelled packets to itself by default or= not, requires
=C2=A0 =C2=A0 > further considerations.

I agree: it requires further consideration.

=C2=A0 =C2=A0 > I am aware of no implementation that would support this.= I would also
=C2=A0 =C2=A0 > be worried about this opening the door for "alterna= te" paths into the
=C2=A0 =C2=A0 > host stack.

I agree. Nobody does it this way.
Yet 8200 (and 2460 before it) says that this is the way to insert headers.<= br>


I think we need to be clear about what is = "inserting" is. To me, the word "inserting" means inser= ting to into something that already exists and has previously been created = - cut apart, insert, glue back together.

<= div dir=3D"auto">IPinIP in the network is not doing insertion. It is adding= by encapsulating with a new IP header. That's the way we add informati= on at all other layers of the stack.

IPinIP in a host is, for some reason or other, not encoding al= l of the information in the first IP header, so it adds another one to carr= y it. IPsec tunnel mode would be an example.

IPsec transport mode isn't "inserting" e= ither. The host sending the IPsec transport mode packet builds the entire t= hing, and adds the AH/ESP header at the appropriate time during the encapsu= lation process as the IPsec packet is built before being put on the wire.

So truly "inserting&= quot; (cut, insert, glue) into an existing packet is not something that has= been part of any IETF protocol as far as I'm aware.

Regards,
Mark.

<= div class=3D"gmail_quote">

One of 6463 or 2460/8200 must be wrong.

Essentially 8200 says to do something that doesn't work.
Should we be at all surprised that there is was much push to do it a differ= ent way?

If we don't fix 6434 to make it work, then our hard fought compromise i= n 8200
is moot.


ps: I'm not advocating for changing 8200.



--
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
-----------------------------------------------------------------= ---
--f403045f6d2c271848055ce1cd4d--