From nobody Sun Jan 1 17:23: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 F3DB2129474; Sun, 1 Jan 2017 17:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpumoQOpejTl; Sun, 1 Jan 2017 17:23:21 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E4312940C; Sun, 1 Jan 2017 17:23:21 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id i88so23892634pfk.2; Sun, 01 Jan 2017 17:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kr64GpwmT9pqUf690fGTcinD85CLeMRdcFOI9xTxkmU=; b=Cc/15BE/l1h5fT1NF4kUT2/yWR0LnDHaw04k1xcspss9kB3U/AQuNT5LyOsNf76jtp pLn9gL2QjMMuOToA5YvoX90UipoRjQ9UZbBh3vqpDAjug+68NNwy9AggDpH4103KIml7 Lce4VlZTA2upJm6y6vk51jKXXFDnAtb9DFhavlew3T2Iw/p0Q6cseE6IoDTHRu+XEVY6 iSo0+zxvNBflUaUXoYhTSsWbOoKIUvhRcWGPAdbNXdjSwJu80CJgaeQJD6WP+a7WUFvp ohgiM9w905kQyMtcLoDfN18Yz9TFlgw5f/XTKRRrZdD/8lGXzFbNZPpm7jtd/cXQIDCW emVA== 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=kr64GpwmT9pqUf690fGTcinD85CLeMRdcFOI9xTxkmU=; b=TeujvUvv/qPnsBet1i2fvTuDD6xW62y54Qb5vwNOngCIcM/IZsx98i3O5fu5NgjcLJ 9ClHQI7k4aqrhLIEyoDgYAoZHYMKFB4HJJ4vxQZivFBzG8AD0V8Ft4AX0YAi92p+TyS9 UhtfxaxrY9228uYpIoMbpHTAX9i3jVR3zPw2w4j/04+E+NbUX9YNspxrlzajSU4rFgh8 OBxwnL+TYewZ5wnyLjhLpb6Wrh74rqOpoUfCHmoShGTZ+DgPayzcfBrcwbzB5qD17vQ3 xusvavaRVPsGaUQsN2n3rqaWu3x2p5Al667Im2Xb1xwYssKVPNYviGomas8X+aqwwQR/ MG7g== X-Gm-Message-State: AIkVDXK4KwW+z0JWA4RTxOMX81PvDw5f8/yxNhsIqncMkj4/8Ix9MQYUyfCxJWabQ4cmgw== X-Received: by 10.98.69.133 with SMTP id n5mr52651984pfi.160.1483320200691; Sun, 01 Jan 2017 17:23:20 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id d186sm84926832pfd.5.2017.01.01.17.23.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 17:23:19 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 From: Fred Baker In-Reply-To: <027a01d262e7$f30b30d0$d9219270$@riw.us> Date: Sun, 1 Jan 2017 17:23:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> To: Russ White X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, Mohammad Moghaddas , v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 01:23:22 -0000 > On Dec 30, 2016, at 1:59 PM, Russ White wrote: >=20 >=20 >> It is indeed an individual draft, and to my knowledge no given = working > group >> has been asked for opinions. That said, we welcome any and all = review. >> Specifically, I have copied v6ops and 6man on this note. >=20 > We would like to present it to a WG as a work item--which WG would be = best > for this one? There are some sections that need to be filled before we > present it, I think. >=20 > :-) >=20 > Russ Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about the = operation of an IPv6 network. I=E2=80=99d suggest v6ops. From nobody Sun Jan 1 17:26: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 2A57C1279EB; Sun, 1 Jan 2017 17:26:20 -0800 (PST) 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 QcJ1-l5Lhwfr; Sun, 1 Jan 2017 17:26:18 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D132C126BF6; Sun, 1 Jan 2017 17:26:18 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id g1so28975138pgn.0; Sun, 01 Jan 2017 17:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WvtMCtstMEjxlDTHke0VQgkGfioAEeyn76W/qgEH+Z0=; b=kfZ8xXmA0cMk9vxpTlQW7YjAOfDKnKWEtbKxO7nthED07J78AcsWSKeKpJJY4oJqnd Qv+TmLcuhU/XMnUzVAZ16zte7Ph4xIz8m45CRfGNb7Gt3+KHAZSPkbZ1bJSJIX1mKkGV SCTvd8voXxjYDOPRkiwLhMxeaufLDjDdi9GbEqqlV6oVtSq5pQZj4tOwKpcdM87wOdct vqLGDbnivLZPzjXwJrY08IG/V9H8USlKgLfRAB5hAgVMukUy+yxxSGi+YK+7Ruc7gY7j hh2harMz4zRWlPc9txE5wH5IzaKcCi+kj892mgpxxzByvlS5c3+Z/AXCFMdIFURcV1Vu CFxA== 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=WvtMCtstMEjxlDTHke0VQgkGfioAEeyn76W/qgEH+Z0=; b=ZIeT+ZAjY/xyjeEV10+eiSrx+YH61V0IFa0Etu68p++7w4gGQoT3VxX+EBHM309bmq 3V7wdok7CZJDDh6eiGdtDlbybtxLloS7k9k9xs6sjmJQaN//Rj4ebnd49NV6Wt594+rm OqrLAV+WZoMeI1AF0bInRixfZ6+Lf4vjCgOZphRVmLz5MaJfNXEZZiV9eC6gp5QBZ84K HRvTL9NVjrZdxHDak6Oh2BgIIyt4SWW0fxL3gyTTQSwF8/UHITvSA1DvJ3JdjEf/surr ueEknRFYvFFxIYOVoWfMPDwI0PGOITcm1jZkeZLnhMgh+2q/TW6hZFpkGNji8ge4XD1z 0FtA== X-Gm-Message-State: AIkVDXJEn1qM5mPWLzk1vXpjoKt/JgVf0Cn6oCHLFEqWf/ZAsl2VnspfdtuS6WBQD2+6xg== X-Received: by 10.84.216.2 with SMTP id m2mr115506737pli.31.1483320378208; Sun, 01 Jan 2017 17:26:18 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id k192sm108474364pgc.3.2017.01.01.17.26.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jan 2017 17:26:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 From: Fred Baker In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Date: Sun, 1 Jan 2017 17:26:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> To: Russ White X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ali-ipv6rtr-reqs@tools.ietf.org, Mohammad Moghaddas , v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 01:26:20 -0000 > On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >=20 >=20 >> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>=20 >>=20 >>> It is indeed an individual draft, and to my knowledge no given = working >> group >>> has been asked for opinions. That said, we welcome any and all = review. >>> Specifically, I have copied v6ops and 6man on this note. >>=20 >> We would like to present it to a WG as a work item--which WG would be = best >> for this one? There are some sections that need to be filled before = we >> present it, I think. >>=20 >> :-) >>=20 >> Russ >=20 > Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. Note that I=E2=80=99m not precluding 6man input. I=E2=80=99m asking what = change or clarification in IPv6 implementations (e.g., IPv6 Maintenance) = is called for. I don=E2=80=99t think there are any. I think it comments = on how IPv6 is used operationally, and by extension, what an operator = might expect to find in IPv6 implementations he deploys. From nobody Tue Jan 3 08:07: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 5DAAF129A56 for ; Tue, 3 Jan 2017 08:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBc27ZvW1hKL for ; Tue, 3 Jan 2017 08:07:17 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540AC129A51 for ; Tue, 3 Jan 2017 08:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YNK00hY3ZOBhRWZNCRRTCgYm1JjbXV9xp8+E2k4JwPg=; b=VDJB3LuTtbGvX2rCtV4lwYCKgH/laPgUiGao8qkfOyhF0ZRmHHuWHcErVqmMIKax4hc9ClNvnAbLXf58TSlrYh1XtUUlQx+DEY7D8jXGjU+5d9D8+mtp5/GTpzK/OszpVu24Y9eNgkKqyuvLXNKoarnkDoFEnVR7SKOJWEC2mzw= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0177.outbound.protection.outlook.com [213.199.154.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-7-p7cvkOG0Oo2AFTVT03O_TA-1; Tue, 03 Jan 2017 16:07:10 +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_P384) id 15.1.829.4; Tue, 3 Jan 2017 16:07:07 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.003; Tue, 3 Jan 2017 16:07:07 +0000 From: Tim Chown To: Fred Baker Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Index: AQHSYUSKP4RyXDRcfEW58qB9cBducaEd5l2AgAMk2QCAAAIlgIADXd2AgAKJGgA= Date: Tue, 3 Jan 2017 16:07:07 +0000 Message-ID: <26DE8EFE-ABA9-4754-BBD1-B9651797DDC0@jisc.ac.uk> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:486a:8527:1c03:59ba] x-ms-office365-filtering-correlation-id: 707e7db3-4a05-42b1-b857-08d433f2913a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:k76gt5Eyprps22ds9vHuTKt1nWsyRuxZ2uThJuTQPUy9Jp7VKFYHr6Y8sTNpKdayd41t3er904b4tMM2NeVMtCOcmCO9DCLPe/ugSjiAZGLu5soQe+7RDLH6vd+GfC/wvuXtoaaRvCDjemI+EK5lMb9JPOesSVD+PWnRb6z30uOhrwdAQbi8/iNgG08dEeRRyvyjAQN3ayHYt+sofUbGCTSUeqZIxnj8H2qT5gaeNfIypoY0ClqTOfLY93lO9jWB/D0OLHgG+KBzkPIeQzCbzzRg9BbTpknmNpaJmSJ/D6Y1MWylyj0HgIet4W2zOYJEY668gQ+SoaDM6h6OKClFFosa9WpOxQylAtkDRs2ePQv10Em3ReXou7qZgCc91tTW/GTOlSazdD69owW4pr1gsCFL59un+dQrvax3MWX9uYnbghv5gi+e04K7tBSinqga/+KzOLQFJLtsm3VDPGzf+g==; 20:xOSdz/xL36ZNclcfAQ/SNnNiXrf0lLgbHZeV1jsY8kTdCTSIdqpOeE8Nos0tuVHhebHdSTZGUc48fM7HRIs0ag29TuOM9UmZLZyZwtj1/n5gb5KexeY1qk1V4WHjoxKn/j8ZRvxnz2dAuQNyypqVrmGIIHlycN5wRt8JOeFLnZU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(24454002)(377454003)(199003)(2950100002)(6486002)(189998001)(81156014)(81166006)(6916009)(50226002)(42882006)(39060400001)(5250100002)(8676002)(6506006)(6512006)(8936002)(93886004)(6116002)(102836003)(86362001)(74482002)(38730400001)(229853002)(230783001)(106356001)(106116001)(82746002)(97736004)(110136003)(7736002)(83716003)(105586002)(6436002)(99286003)(68736007)(76176999)(101416001)(57306001)(36756003)(5660300001)(4326007)(2900100001)(92566002)(50986999)(33656002)(3280700002)(2906002)(3660700001)(54906002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 16:07:07.5597 (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: p7cvkOG0Oo2AFTVT03O_TA-1 Content-Type: multipart/alternative; boundary="_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_" Archived-At: Cc: Russ White , Mohammad Moghaddas , "draft-ali-ipv6rtr-reqs@tools.ietf.org" , 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:07:19 -0000 --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDIgSmFuIDIwMTcsIGF0IDAxOjIzLCBGcmVkIEJha2VyIDxGcmVkQmFrZXIuSUVU RkBnbWFpbC5jb208bWFpbHRvOkZyZWRCYWtlci5JRVRGQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpP biBEZWMgMzAsIDIwMTYsIGF0IDE6NTkgUE0sIFJ1c3MgV2hpdGUgPHJ1c3NAcml3LnVzPG1haWx0 bzpydXNzQHJpdy51cz4+IHdyb3RlOg0KDQpJdCBpcyBpbmRlZWQgYW4gaW5kaXZpZHVhbCBkcmFm dCwgYW5kIHRvIG15IGtub3dsZWRnZSBubyBnaXZlbiB3b3JraW5nDQpncm91cA0KaGFzIGJlZW4g YXNrZWQgZm9yIG9waW5pb25zLiBUaGF0IHNhaWQsIHdlIHdlbGNvbWUgYW55IGFuZCBhbGwgcmV2 aWV3Lg0KU3BlY2lmaWNhbGx5LCBJIGhhdmUgY29waWVkIHY2b3BzIGFuZCA2bWFuIG9uIHRoaXMg bm90ZS4NCg0KV2Ugd291bGQgbGlrZSB0byBwcmVzZW50IGl0IHRvIGEgV0cgYXMgYSB3b3JrIGl0 ZW0tLXdoaWNoIFdHIHdvdWxkIGJlIGJlc3QNCmZvciB0aGlzIG9uZT8gVGhlcmUgYXJlIHNvbWUg c2VjdGlvbnMgdGhhdCBuZWVkIHRvIGJlIGZpbGxlZCBiZWZvcmUgd2UNCnByZXNlbnQgaXQsIEkg dGhpbmsuDQoNCjotKQ0KDQpSdXNzDQoNClBlcnNvbmFseSBvcGluaW9uOiB0aGlzIGlzbuKAmXQg YWJvdXQgSVB2NiBwZXIgc2UsIGl0IGlzIGFib3V0IHRoZSBvcGVyYXRpb24gb2YgYW4gSVB2NiBu ZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3BzLg0KDQpJIGxvb2tlZCB0aHJvdWdoIHRoaXMgZHJh ZnQgcXVpY2tseSBhcyBpdCBzZWVtZWQgdG8gYmUgcmVsZXZhbnQgdG8gdGhlIG9uZ29pbmcgNm1h biB3b3JrIG9uIHVwZGF0aW5nIFJGQyA2NDM0LCBJUHY2IE5vZGUgUmVxdWlyZW1lbnRzLg0KDQpJ IGxpa2UgdGhlIHN0eWxlIGl04oCZcyB3cml0dGVuIGluLCBhbmQgdGhlIGJsZW5kIG9mIGFkdmlj ZSBiZWluZyBnaXZlbi4gSXQgcmVhZHMgbmljZWx5Lg0KDQpJIHRoaW5rIHRoaXMgZHJhZnQgdHJl YWRzIG1vcmUgaGVhdmlseSBpbnRvIG9wZXJhdGlvbmFsIGFuZCBkZXNpZ24gcmVxdWlyZW1lbnRz LCByYXRoZXIgdGhhbiBqdXN0IGJlaW5nIGEgbGlzdCBvZiBwcm90b2NvbCByZXF1aXJlbWVudHMs IHNvIEnigJlkIGFsc28gc2F5IGl0IGxvb2tzIG1vcmUgbGlrZSBhIHY2b3BzIGRvY3VtZW50LCBh bmQgaXQgY291bGQgcHJvYmFibHkgYmUgcmVuYW1lZCB0byBtYXRjaCB0aGF0IGVtcGhhc2lzLg0K DQpUaW0NCg== --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <7B04B94C04A8CA4DB4629B10F21A976C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gMiBKYW4gMjAxNywgYXQgMDE6MjMsIEZyZWQgQmFrZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpGcmVkQmFrZXIuSUVURkBnbWFpbC5jb20iIGNsYXNzPSIiPkZyZWRCYWtlci5J RVRGQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCk9uIERlYyAzMCwgMjAxNiwgYXQgMTo1OSBQTSwgUnVzcyBXaGl0ZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJ1c3NAcml3LnVzIiBjbGFzcz0iIj5ydXNzQHJpdy51czwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPkl0IGlzIGluZGVlZCBhbiBpbmRpdmlkdWFsIGRyYWZ0LCBhbmQgdG8gbXkga25vd2xlZGdl IG5vIGdpdmVuIHdvcmtpbmc8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpncm91cDxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPmhhcyBiZWVuIGFza2Vk IGZvciBvcGluaW9ucy4gVGhhdCBzYWlkLCB3ZSB3ZWxjb21lIGFueSBhbmQgYWxsIHJldmlldy48 YnIgY2xhc3M9IiI+DQpTcGVjaWZpY2FsbHksIEkgaGF2ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4g b24gdGhpcyBub3RlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4N CldlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBpdCB0byBhIFdHIGFzIGEgd29yayBpdGVtLS13aGlj aCBXRyB3b3VsZCBiZSBiZXN0PGJyIGNsYXNzPSIiPg0KZm9yIHRoaXMgb25lPyBUaGVyZSBhcmUg c29tZSBzZWN0aW9ucyB0aGF0IG5lZWQgdG8gYmUgZmlsbGVkIGJlZm9yZSB3ZTxiciBjbGFzcz0i Ij4NCnByZXNlbnQgaXQsIEkgdGhpbmsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KOi0p PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUnVzczxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5QZXJz b25hbHkNCiBvcGluaW9uOiB0aGlzIGlzbuKAmXQgYWJvdXQgSVB2NiBwZXIgc2UsIGl0IGlzIGFi b3V0IHRoZSBvcGVyYXRpb24gb2YgYW4gSVB2NiBuZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3Bz Ljwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGxvb2tl ZCB0aHJvdWdoIHRoaXMgZHJhZnQgcXVpY2tseSBhcyBpdCBzZWVtZWQgdG8gYmUgcmVsZXZhbnQg dG8gdGhlIG9uZ29pbmcgNm1hbiB3b3JrIG9uIHVwZGF0aW5nIFJGQyA2NDM0LCBJUHY2IE5vZGUg UmVxdWlyZW1lbnRzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBsaWtlIHRoZSBzdHlsZSBpdOKAmXMgd3JpdHRlbiBpbiwg YW5kIHRoZSBibGVuZCBvZiBhZHZpY2UgYmVpbmcgZ2l2ZW4uIEl0IHJlYWRzIG5pY2VseS48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkg dGhpbmsgdGhpcyBkcmFmdCB0cmVhZHMgbW9yZSBoZWF2aWx5IGludG8gb3BlcmF0aW9uYWwgYW5k IGRlc2lnbiByZXF1aXJlbWVudHMsIHJhdGhlciB0aGFuIGp1c3QgYmVpbmcgYSBsaXN0IG9mIHBy b3RvY29sIHJlcXVpcmVtZW50cywgc28gSeKAmWQgYWxzbyBzYXkgaXQgbG9va3MgbW9yZSBsaWtl IGEgdjZvcHMgZG9jdW1lbnQsIGFuZCBpdCBjb3VsZCBwcm9iYWJseSBiZSByZW5hbWVkIHRvIG1h dGNoIHRoYXQgZW1waGFzaXMuDQogJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaW08L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_26DE8EFEABA94754BBD1B9651797DDC0jiscacuk_-- From nobody Tue Jan 3 08:19: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 4258B129579 for ; Tue, 3 Jan 2017 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7mcaSOiEZS3 for ; Tue, 3 Jan 2017 08:19:18 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C90512966C for ; Tue, 3 Jan 2017 08:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WxORAgi0sZ+PKMFMQmUtRWPHu8vYaLMpRMwoF/DlZik=; b=STjEIfINoxsxLaWYx+0QpVxTE050GZhTrrpYf7y6e4Jz98rtc5n6hN5tw1LAql/oDZkjujqRO5n+eD7Ik3JddwPqmW29PalfhRtsRyapg3XLyqzIdnSROElq/9QB6kTyUIrm89O7qrUBu1wy2ZhvHAacmGLN5QSDBm4Hi0Ykwts= 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-62-DrLyyX33MVGkWnweWNkuxA-1; Tue, 03 Jan 2017 16:19:12 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.3; Tue, 3 Jan 2017 16:19:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.003; Tue, 3 Jan 2017 16:19:10 +0000 From: Tim Chown To: Brian E Carpenter , "Stefano Previdi (sprevidi)" Subject: Re: draft-ietf-6man-segment-routing-header-02 Thread-Topic: draft-ietf-6man-segment-routing-header-02 Thread-Index: AQHSWaS/Df21E9Hfb0uZk/Sk233zxaEQ4UKAgABYFwCAFc2WgA== Date: Tue, 3 Jan 2017 16:19:10 +0000 Message-ID: <864A82BA-0880-44B8-B59B-097AD74F9E2A@jisc.ac.uk> References: <6203a836-feb0-40a9-77ec-a16635ac5c36@gmail.com> <86c4aa67-52f5-4b61-5695-43ae516fc8a8@gmail.com> In-Reply-To: <86c4aa67-52f5-4b61-5695-43ae516fc8a8@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:486a:8527:1c03:59ba] x-ms-office365-filtering-correlation-id: 2917e1fc-7a76-49aa-da0b-08d433f44019 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:ujWrhQKriRea15yZKsMNjAJZR8JcIyxAeA1PBz0g81qKUGLwZE8RNQrucKbWcFmd6K1NtZOpp3Vqtc3NZsmzCvIGK4X4/9eOMfTZuiJ0It8SVHehGfJnMhSRAzMuTl5SM5gny0kG0wqLGGAB6401fVAICTU3cER2T9rNg5g/QdqemARgFQgD/6xn6TuViOT/du4EQWb/SPhzNm8Iv45p3nvygHHdd10k9b7Sywhfshl0QMPYGdcDbJDYGS2XH5HlwT8t5fESDtjIYtiugxXz4k4HyMzBZt0SKnAkR/Ku2U5Y3FsFWUsWzZafIeRciVYYK35a1BL9PtUVpG9gPlSNitoAZJ7qIAZ6dLJuqN6soqOgT+X5f9FJzyC5l2vNnyJQmaE/PPLioTXOeVdZ37gyQMo2JEk6HzkdmjIK+RAMRT3sfB+Di99WSzhYR5OEZ+G9WA2jIlRZXHrWoIjkXvlj1Q==; 20:CrgP2IWzymwev50MshZabqeVZFA6i6cRD80o5brfuHm6ky4moj+/5h0TV6e6mwFj1f966EUh2ieUd84SUtB0P+4Pwnqm3P5PK4b/hI/Z/27iV7aVqAJfAI7W6FsjH27RrppgI7xtrrQpc3FXdvskepLsu25BEr0t18ohoBFovgM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(24454002)(199003)(106116001)(106356001)(105586002)(68736007)(6116002)(2900100001)(92566002)(230783001)(2906002)(38730400001)(102836003)(99286003)(5250100002)(5001770100001)(82746002)(57306001)(97736004)(5660300001)(36756003)(4326007)(2950100002)(50986999)(76176999)(189998001)(83716003)(229853002)(305945005)(74482002)(33656002)(3660700001)(86362001)(7736002)(8936002)(39060400001)(3280700002)(6512006)(6506006)(6486002)(101416001)(6436002)(50226002)(8676002)(81156014)(81166006)(42882006)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 16:19:10.5604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: DrLyyX33MVGkWnweWNkuxA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:19:20 -0000 SGksDQoNCj4gT24gMjAgRGVjIDIwMTYsIGF0IDE5OjIxLCBCcmlhbiBFIENhcnBlbnRlciA8YnJp YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFN0ZWZhbm8sIEkgdGhpbmsg eW91IGFyZSBtaXNzaW5nIG15IHBvaW50Lg0KPiANCj4gVGhlIGN1cnJlbnQgdGV4dCBpbiB5b3Vy IGRyYWZ0IGlzIGNvbnRlbnRpb3VzLiBNYW55IG9mIHVzIGJlbGlldmUgdGhhdA0KPiB0aGUgd29y ZGluZyAoYW5kIHRoZSBpbnRlbnRpb24pIG9mIFJGQyAyNDYwIGlzIGNsZWFyIHRoYXQgaGVhZGVy IGluc2VydGlvbg0KPiBlbiByb3V0ZSBpcyBmb3JiaWRkZW4uIEluIHRoYXQgdmlldywgdGhlIHNl bnRlbmNlIEkgcXVvdGVkIGlzIHNpbXBseSBmYWxzZS4NCj4gTXkgcHJvcG9zZWQgc2VudGVuY2Ug c2ltcGx5IHJlbW92ZXMgdGhhdCBjb250ZW50aW91cyBwb2ludCBjb21wbGV0ZWx5IGZyb20NCj4g eW91ciBkcmFmdDoNCj4gDQo+ICJJdCBpcyBhc3N1bWVkIGluIHRoaXMgZG9jdW1lbnQgdGhhdCB0 aGUgU1JIIGlzIGluc2VydGVkIGluIHRoZSBwYWNrZXQgYnkNCj4gaXRzIHNvdXJjZSwgY29uc2lz dGVudGx5IHdpdGggdGhlIHNvdXJjZSByb3V0aW5nIG1vZGVsIGRlZmluZWQgaW4gW1JGQzI0NjBd LiINCj4gDQo+IElmIHlvdSBjaGFuZ2UgdGhhdCByZWZlcmVuY2UgbGF0ZXIgdG8gMjQ2MGJpcywg eW91IHdvdWxkbid0IG5lZWQgdG8gY2hhbmdlDQo+IHRoZSB0ZXh0IGF0IGFsbC4NCg0KSSBhZ3Jl ZSB3aXRoIEJyaWFu4oCZcyBjaGFuZ2UuDQoNClRoZSDigJxGb3IgZXhhbXBsZTrigJ0gaW4gMi4y IGNvdWxkIGFsc28gYmUgcmVwbGFjZWQgYnkg4oCcVGh1cyB0aGUgU1JIIGlzIGluc2VydGVkIGVp dGhlcjrigJ0gdG8gbWFrZSBpdCBjbGVhciBpdOKAmXMgZWl0aGVyIGFkZGVkIGJ5IHRoZSBvcmln aW5hdGluZyBob3N0LCBvciBpcyBhZGRlZCB0aHJvdWdoIGVuY2Fwc3VsYXRpb24gKG5vdCBkaXJl Y3QgaW5zZXJ0aW9uKSBvbiBlbnRyeSB0byB0aGUgU1IgZG9tYWluLiBBbmQgbm90aGluZyBlbHNl Lg0KDQpQZXJoYXBzIOKAnGFkZOKAnSBpcyBhIGJldHRlciB3b3JkIHRoYW4g4oCcaW5zZXJ04oCd IGFueXdheT8gIA0KDQpUaW0NCg0KPiBSZWdhcmRzDQo+ICAgQnJpYW4NCj4gDQo+IE9uIDIxLzEy LzIwMTYgMDM6MDYsIFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIHdyb3RlOg0KPj4gSGkgQnJp YW4sDQo+PiANCj4+IA0KPj4+IE9uIERlYyAxOSwgMjAxNiwgYXQgNDowNSBBTSwgQnJpYW4gRSBD YXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4g SGksDQo+Pj4gDQo+Pj4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVu dC1yb3V0aW5nLWhlYWRlci0wMiBzdGlsbCBzYXlzOg0KPj4+IA0KPj4+PiAgV2hpbGUgdGhlIHNv dXJjZSByb3V0aW5nIG1vZGVsIGRlZmluZWQgaW4gW1JGQzI0NjBdIGRvZXNuJ3QgbWFuZGF0ZQ0K Pj4+PiAgd2hpY2ggbm9kZSBpcyBhbGxvd2VkIHRvIGluc2VydCAob3IgbW9kaWZ5KSB0aGUgU1JI LCBpdCBpcyBhc3N1bWVkIGluDQo+Pj4+ICB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFNSSCBpcyBp bnNlcnRlZCBpbiB0aGUgcGFja2V0IGJ5IGl0cyBzb3VyY2UuDQo+Pj4gDQo+Pj4gV2UgbWlnaHQg aGF2ZSBsZXNzIGRpc3NlbnNpb24gaWYgdGhpcyB3YXMgcGhyYXNlZCBzb21ldGhpbmcgbGlrZToN Cj4+IA0KPj4gDQo+PiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlci0wMiBy ZWZlcnMgdG8gUkZDMjQ2MCB3aGVyZSBpdCBpcyBpbmRlZWQgdW5zcGVjaWZpZWQgd2hvIGlzIGFs bG93ZWQgKG9yIG5vdCBhbGxvd2VkKSB0byBpbnNlcnQgYSBoZWFkZXIuDQo+PiANCj4+IFdoZW4g UkZDMjQ2MGJpcyB3aWxsIGJlIHB1Ymxpc2hlZCwgd2Ugd2lsbCB1cGRhdGUgdGhlIGRyYWZ0IGFj Y29yZGluZ2x5Lg0KPj4gDQo+PiBzLg0KPj4gDQo+PiANCj4+PiANCj4+PiBJdCBpcyBhc3N1bWVk IGluIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgU1JIIGlzIGluc2VydGVkIGluIHRoZSBwYWNrZXQg YnkNCj4+PiBpdHMgc291cmNlLCBjb25zaXN0ZW50bHkgd2l0aCB0aGUgc291cmNlIHJvdXRpbmcg bW9kZWwgZGVmaW5lZCBpbiBbUkZDMjQ2MF0uDQo+Pj4gDQo+Pj4gICBCcmlhbg0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQo+Pj4gaXB2NkBpZXRmLm9yZw0KPj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gDQo+PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQoNCg== From nobody Tue Jan 3 09:56:04 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D89129A8D; Tue, 3 Jan 2017 09:56:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Subject: IPR Disclosure Huawei Technologies Co., Ltd 's Statement about IPR related to RFC 6788 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148346616306.27950.13117117565742399330.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 09:56:03 -0800 Archived-At: Cc: ipv6@ietf.org, ipr-announce@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:56:03 -0000 Dear Suresh Krishnan, Alan Kavanagh, Balazs Varga, Sven Ooghe, Erik Nordmark: An IPR disclosure that pertains to your RFC entitled "The Line-Identification Option" (RFC6788) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2927/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd 's Statement about IPR related to RFC 6788" Thank you IETF Secretariat From nobody Tue Jan 3 12:13: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 ED37C129B70; Tue, 3 Jan 2017 12:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxwRFdu8wsHK; Tue, 3 Jan 2017 12:13:02 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F868129B4B; Tue, 3 Jan 2017 12:13:02 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id u25so51316007qki.2; Tue, 03 Jan 2017 12:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ftJxlfpXa51Y0RON3WGo9YWQmzSzpfhFQllJ16aCcOs=; b=ZgfnkYlEEw95Dk504ye4omQWpewN6Ye2ftJMDS1MWPrnlezcZPtBbg8/5iAV01rAeL H52CXAcbdjbHHgsxiT0r258X+wxtchwnSv2ZyKAI6ODdAUZt0pdsrmgr352Yz+CGZ3mo u0ApUT0nc3MgS1epgHJ7AkLOjJqzPd9i9y7mH/tgppfUqm9wzodIcoKFRb238WxSGnQF dgKUh2BVY29kA5vkBeQG6yPGIYhdrY1O/23PbmUYemfL23J/+WN/O8MeuhNwrv1cLYnI p05xVQyFoeAWkYgxZFA8tSqeMDa/qcN2XEYjdqL7Ra/s0iOu+fHM/mvqh7w6R8l4RNwt 8AEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ftJxlfpXa51Y0RON3WGo9YWQmzSzpfhFQllJ16aCcOs=; b=RfgSWLr1wCeV38s5I9FdG9WwYY9T1my9rhXaSIRbTI5u+3VuMKntB5+8uohDH/Csdo oRxu7s3EqIOFnzqbQzVVDtD/M/uDYQ376RpLlFSWA7xAk3b/Euq/WuzcK57AYUukDHnQ Msk3ZrduWWYfUo0i7vWmC3Mq8diOKhEzH5i0CrC6O8ixy6CVkDrR1IAQ8hkMMfHCOfWg WRuKcSLMFcZL3RE0c/5rZHS8UJb8GnCEzIF62DXFUFTfVEgEQkABNKAZeW0aTiByUpEu BTPaw0RZ8viUoWqIKYfYtEgejcUA5wG6Tdq5ClepgyYYFFrNu7d5T3kp2ZlbdxsRBoGz ZVuQ== X-Gm-Message-State: AIkVDXKd7bxrYXnzZKHjC6cAuAwuGoy7FdyfPgU7xtWEJTJnWU0IZZ3RISw6ntvkb9Qmuw== X-Received: by 10.55.169.21 with SMTP id s21mr62407957qke.246.1483474381479; Tue, 03 Jan 2017 12:13:01 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a81sm44353713qkg.28.2017.01.03.12.12.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 12:13:00 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 From: Bob Hinden In-Reply-To: <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> Date: Tue, 3 Jan 2017 12:12:57 -0800 Message-Id: <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list , IPv6 List , Russ White , Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:13:04 -0000 --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fred. > On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >=20 >=20 >> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>=20 >>=20 >>> It is indeed an individual draft, and to my knowledge no given = working >> group >>> has been asked for opinions. That said, we welcome any and all = review. >>> Specifically, I have copied v6ops and 6man on this note. >>=20 >> We would like to present it to a WG as a work item--which WG would be = best >> for this one? There are some sections that need to be filled before = we >> present it, I think. >>=20 >> :-) >>=20 >> Russ >=20 > Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. Probably good to keep both w.g.=E2=80=99s involved. I was thinking this = was similar to IPv6 Node Requirements which in in 6MAN. Also, 6MAN has started on an Node Requirements bis document, good to = keep this coordinated with that. Bob >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYbAXKAAoJEK7rdBF357uoDqIH/jWnPRNDX1JIYJJLMCITi7Qa TvajR0uJAj0h7yfj1+GBNTImQhMM0t6IlwnX41gkJas1nko3Y1Zduibi4RRxveun 1vKChJETnUorNWrSUU4pxg7DJeNXYvm9P44+1bn2h8TH7XLbWD2AbNtjN7fSyqjY N1wG5AoqZmXZPYvkBUdiqC2JgwzTfi8EL7ZF3+p3LU+p50ODgA5oHVkQMQatusil sM0n/CMaV77TaD3QKThXvKCjxZE31yYssNHFnkIzrt2Te8kg6eush7odzYFk8N6G Kmugw5lcMai0OEv5EcBOumrgD0yoWcNbJKivClW/K9S+WYNWrTO8DFRYAE6/WL0= =8+Eb -----END PGP SIGNATURE----- --Apple-Mail=_92DA8041-F632-487F-A88B-CC6D95AD36D1-- From nobody Tue Jan 3 12:51: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 D8D941296E7; Tue, 3 Jan 2017 12:51:48 -0800 (PST) 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 E1WemiL8O4hK; Tue, 3 Jan 2017 12:51:46 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC854129690; Tue, 3 Jan 2017 12:51:46 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id b1so34591022pgc.1; Tue, 03 Jan 2017 12:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hu85ECO8IQfHvEvy48R3wesZOVBnaOJefRgafTCPdaI=; b=Psv6/uTzAr19mcFa+3TbRWuDnuwGaYc/G0gS0Tbe10on9NWgpGABLBWnLg27Ur09uw BTLwqY+TmTdoE4OiGyHjVEiAc0X/pPT5xWigELei1m++RoMfOVFGQsRTV54QpNNPAPsY gDzZSl/80yC4L57n2RLsS9v0uyhfxvJHcFxjDyKvCXmjK4s6k3pR4SVqynEt5cC6rMbr FpETAs5+G5550uFpRlcPWYGQgUYiHJXFGzlbjS1mgTQMrEnVT6pnVa8cVuxNHEX6E9bF 4NxCtHQiyHR6rtE+FwyEAKy7nDkUu6RKJnlORJCaRI/15pm4Hk+HALNLht+Pi2JWp/zB Gnkg== 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=hu85ECO8IQfHvEvy48R3wesZOVBnaOJefRgafTCPdaI=; b=g8OMvM6qhc0dEVFGEC7E2jlJ5WMFuSH97Sd27ieTlwPF9q5uCDjam2biAN2+6OxGFL bU98tlqj8j04kRtwsDhbpwuRFKRvyn6aQiAbu8ONzlepB8L1KY2tmnsEKeKGcZktrih2 WkvHzOP4haDy7mtVk0Z0JjzolAg7X4TEziflFfy2iUlDhSK7TgqGAxjxy8VJqPWP57Q+ r1RgESN9WhARxuEzxfoH8e1bztQY45CHt26MfvPB6xFUBtPz+K5Q08+58m//SmVCOMPF 9Dj5zHfM4gTULI47+055mrQoeRWuovzfvAwO08MAy+aus+2vIfLuC+LGoyFUXY1mvRJG gOqw== X-Gm-Message-State: AIkVDXJ+u9lEM8rVz9PXUq3Vq0Wf00srNuq4VYLTIl2xVQsAzkM5KCqH6RiOZHX3aykvLQ== X-Received: by 10.99.153.26 with SMTP id d26mr120073598pge.44.1483476706462; Tue, 03 Jan 2017 12:51:46 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p14sm141931351pfl.74.2017.01.03.12.51.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 12:51:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 From: Fred Baker In-Reply-To: <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> Date: Tue, 3 Jan 2017 12:51:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB761D0-9073-4FCE-A504-AD7941606A0E@gmail.com> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <4EC5F276-BD8D-4169-82AB-F0E0225A04AE@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Russ White , Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, IPv6 List , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:51:49 -0000 No argument, and BTW I tend to think most documents in both working = groups benefit from cross-pollination :-) > On Jan 3, 2017, at 12:12 PM, Bob Hinden wrote: >=20 > Fred. >=20 >> On Jan 1, 2017, at 5:23 PM, Fred Baker = wrote: >>=20 >>=20 >>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>>=20 >>>=20 >>>> It is indeed an individual draft, and to my knowledge no given = working >>> group >>>> has been asked for opinions. That said, we welcome any and all = review. >>>> Specifically, I have copied v6ops and 6man on this note. >>>=20 >>> We would like to present it to a WG as a work item--which WG would = be best >>> for this one? There are some sections that need to be filled before = we >>> present it, I think. >>>=20 >>> :-) >>>=20 >>> Russ >>=20 >> Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the operation of an IPv6 network. I=E2=80=99d suggest v6ops. >=20 > Probably good to keep both w.g.=E2=80=99s involved. I was thinking = this was similar to IPv6 Node Requirements which in in 6MAN. >=20 > Also, 6MAN has started on an Node Requirements bis document, good to = keep this coordinated with that. >=20 > Bob >=20 >=20 >=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Tue Jan 3 20:57: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 392E5129536; Tue, 3 Jan 2017 20:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfILVOFbFMJU; Tue, 3 Jan 2017 20:57:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8789C12952E; Tue, 3 Jan 2017 20:57:35 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3B249838DB; Wed, 4 Jan 2017 05:57:26 +0100 (CET) Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 To: Fred Baker , Russ White References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> Date: Tue, 3 Jan 2017 03:07:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:57:37 -0000 On 01/01/2017 10:26 PM, Fred Baker wrote: > >> On Jan 1, 2017, at 5:23 PM, Fred Baker >> wrote: >> >> >>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>> >>> >>>> It is indeed an individual draft, and to my knowledge no given >>>> working >>> group >>>> has been asked for opinions. That said, we welcome any and all >>>> review. Specifically, I have copied v6ops and 6man on this >>>> note. >>> >>> We would like to present it to a WG as a work item--which WG >>> would be best for this one? There are some sections that need to >>> be filled before we present it, I think. >>> >>> :-) >>> >>> Russ >> >> Personaly opinion: this isn’t about IPv6 per se, it is about the >> operation of an IPv6 network. I’d suggest v6ops. > > Note that I’m not precluding 6man input. I’m asking what change or > clarification in IPv6 implementations (e.g., IPv6 Maintenance) is > called for. I don’t think there are any. I think it comments on how > IPv6 is used operationally, and by extension, what an operator might > expect to find in IPv6 implementations he deploys. I somewhat agree, but: wasn't the Node Requirements RFC produced by 6man? -- this one should be similar in nature... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 4 00:07: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 3B81D12940E; Wed, 4 Jan 2017 00:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] 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 NSexkrOMapVR; Wed, 4 Jan 2017 00:07:16 -0800 (PST) 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 B0876128E19; Wed, 4 Jan 2017 00:07:16 -0800 (PST) Received: from mbp-4.local ([IPv6:2607:fb90:80a2:cb36:fcfd:2be3:e77e:6987]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v0487CHo076522 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 4 Jan 2017 08:07:13 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2607:fb90:80a2:cb36:fcfd:2be3:e77e:6987] claimed to be mbp-4.local Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 To: Fernando Gont , Fred Baker , Russ White References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> From: joel jaeggli Message-ID: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Date: Wed, 4 Jan 2017 00:07:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB" Archived-At: Cc: Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB Content-Type: multipart/mixed; boundary="CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl"; protected-headers="v1" From: joel jaeggli To: Fernando Gont , Fred Baker , Russ White Cc: Mohammad Moghaddas , draft-ali-ipv6rtr-reqs@tools.ietf.org, 6man WG , v6ops list Message-ID: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> In-Reply-To: <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> --CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 1/2/17 10:07 PM, Fernando Gont wrote: > On 01/01/2017 10:26 PM, Fred Baker wrote: >>> On Jan 1, 2017, at 5:23 PM, Fred Baker >>> wrote: >>> >>> >>>> On Dec 30, 2016, at 1:59 PM, Russ White wrote: >>>> >>>> >>>>> It is indeed an individual draft, and to my knowledge no given >>>>> working >>>> group >>>>> has been asked for opinions. That said, we welcome any and all >>>>> review. Specifically, I have copied v6ops and 6man on this >>>>> note. >>>> We would like to present it to a WG as a work item--which WG >>>> would be best for this one? There are some sections that need to >>>> be filled before we present it, I think. >>>> >>>> :-) >>>> >>>> Russ >>> Personaly opinion: this isn=E2=80=99t about IPv6 per se, it is about = the >>> operation of an IPv6 network. I=E2=80=99d suggest v6ops. >> Note that I=E2=80=99m not precluding 6man input. I=E2=80=99m asking wh= at change or >> clarification in IPv6 implementations (e.g., IPv6 Maintenance) is >> called for. I don=E2=80=99t think there are any. I think it comments o= n how >> IPv6 is used operationally, and by extension, what an operator might >> expect to find in IPv6 implementations he deploys. > I somewhat agree, but: wasn't the Node Requirements RFC produced by > 6man? -- this one should be similar in nature... and 6204 / 7084 / 7849 were done in v6ops, it's not that unusual a style of document generally speaking. > > Thanks, --CAC0OwNDRPS8K3S8Me8rm5S7O50w96QJl-- --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB 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 iEYEARECAAYFAlhsrTAACgkQ8AA1q7Z/VrIm+ACfa/duZuCzc7HyDEWoCYV/6BFM h2AAoID6D1OU0gWzNBaI0dNjGPkZmCH3 =9/5y -----END PGP SIGNATURE----- --RvBCQNpG5R7SAsBHpsm2Mj7lCxqO5PaDB-- From nobody Wed Jan 4 00:47: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 0680F1294A4 for ; Wed, 4 Jan 2017 00:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLSSMURXx9TB for ; Wed, 4 Jan 2017 00:47:43 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E121129B96 for ; Wed, 4 Jan 2017 00:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dcKlJuifF7zlAkqCsqSRfaO/AkMz+BTalbcx0wozzzk=; b=ThnXSqct4bkbNZn10j92fHo1o5ZjPtGeI/pMYyOT0iAOLiENxwfur+KaM6mcucDfLCevEx8R6sw93h3e/jrgRezf8nHY7SW4O4RrjOh1l5xjq277pf8d4s3E6hnASHz/uuFCbr+hLBVvcYtE5IyKbwWyQ/j8unGWzgYweTnSN5o= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0120.outbound.protection.outlook.com [213.199.154.120]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-_xUCUYLMNoi_wjdk4oCXFA-1; Wed, 04 Jan 2017 08:47:35 +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_P384) id 15.1.829.4; Wed, 4 Jan 2017 08:47:34 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.003; Wed, 4 Jan 2017 08:47:34 +0000 From: Tim Chown To: joel jaeggli Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Topic: [v6ops] Comments on draft-ali-ipv6rtr-reqs-01 Thread-Index: AQHSYUSKP4RyXDRcfEW58qB9cBducaEd5l2AgAMk2QCAAAIlgIADXd2AgAAA0wCAAeDKAIABs7uAgAALSQA= Date: Wed, 4 Jan 2017 08:47:34 +0000 Message-ID: <280F2FFC-E778-4A0C-B4A7-7AF215588A8A@jisc.ac.uk> References: <027a01d262e7$f30b30d0$d9219270$@riw.us> <9A4806E3-70B8-46E7-921D-4BA0817B16C7@gmail.com> <88D7C907-1BD2-40E7-9DEA-5BAF42688046@gmail.com> <245a034f-1e15-2556-c39e-f950bea5263f@si6networks.com> <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> In-Reply-To: <43943ea7-6ae2-91f0-9518-a3c61fcb0a22@bogus.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: a256b3a3-df59-4661-c8ff-08d4347e53da x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1139; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 7:XuvV/0uR3mZNv+mY7cG/ALOevcbqO2/LbCBJFqxLYZlQcwgjbyt3neR8RNADmdi0IrqqkPceGzZN27CF/uPCba9QzQJeT7bywgQxKFB29CsF3Xs5eQtw5MUesBdSGzCwZsYLJBMY63SEfeac7RuL8gQVt5t0pPT6poaOWKjKks5qV9UwxXV6taYeEIyHN3/Gb34d5fVWEigEn6R9yQN237KmRiksbf25c/P68UaJacGs/WQSfq4CfhJ5J0lOnL+9J6wdtAcvb9gVG7tREiJBeZDMnpFrs1iDMkfuaRonr/nd8FWEKQG9Deta62wyKimlfxmhcsAeRNLPZLaoNlLcraebA4qcA3Wcl87fdqDCvT81GFOgCm8A0uzSRI1AIEi93WP48IzzEmoncv9jSRMwty1cnZZS3ldcvh2KwiFHq7S4QvbKLZObBQQh/1Mwl3115FLg4bBL4teq3jm6c4laZw==; 20:hK0eATqh6znZyWqCqKX0u2Wi3f0lpWLV6NgBEkc/1iSdaF9EDjIpKNN2PQtX8G/rjNpv7F5KwiV4Fk4HS6ZjFpGtxAsU7pbLUzHoRaz1JLmvq7sTFYH8VntcSe31xazRHn1B4ks/xstV3jZ0XGR8+7SLUTVMMFYM6dLWCIa6KCY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1139; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(24454002)(199003)(377454003)(189002)(92566002)(38730400001)(6512006)(6506006)(39060400001)(6436002)(68736007)(189998001)(5660300001)(36756003)(3280700002)(229853002)(97736004)(57306001)(42882006)(6916009)(110136003)(2950100002)(4326007)(83716003)(99286003)(5250100002)(2906002)(66066001)(106356001)(106116001)(82746002)(54906002)(74482002)(230783001)(8936002)(7736002)(8676002)(102836003)(81156014)(81166006)(93886004)(105586002)(6116002)(50986999)(86362001)(76176999)(33656002)(3660700001)(101416001)(2900100001)(6486002)(3846002)(50226002)(104396002); 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 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 08:47:34.2232 (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: _xUCUYLMNoi_wjdk4oCXFA-1 Content-Type: multipart/alternative; boundary="_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_" Archived-At: Cc: v6ops list , 6man WG , Russ White , Mohammad Moghaddas , "draft-ali-ipv6rtr-reqs@tools.ietf.org" , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:47:46 -0000 --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gNCBKYW4gMjAxNywgYXQgMDg6MDcsIGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxt YWlsdG86am9lbGphQGJvZ3VzLmNvbT4+IHdyb3RlOg0KDQpPbiAxLzIvMTcgMTA6MDcgUE0sIEZl cm5hbmRvIEdvbnQgd3JvdGU6DQpPbiAwMS8wMS8yMDE3IDEwOjI2IFBNLCBGcmVkIEJha2VyIHdy b3RlOg0KT24gSmFuIDEsIDIwMTcsIGF0IDU6MjMgUE0sIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4NCndyb3RlOg0K DQoNCk9uIERlYyAzMCwgMjAxNiwgYXQgMTo1OSBQTSwgUnVzcyBXaGl0ZSA8cnVzc0ByaXcudXM8 bWFpbHRvOnJ1c3NAcml3LnVzPj4gd3JvdGU6DQoNCg0KSXQgaXMgaW5kZWVkIGFuIGluZGl2aWR1 YWwgZHJhZnQsIGFuZCB0byBteSBrbm93bGVkZ2Ugbm8gZ2l2ZW4NCndvcmtpbmcNCmdyb3VwDQpo YXMgYmVlbiBhc2tlZCBmb3Igb3BpbmlvbnMuIFRoYXQgc2FpZCwgd2Ugd2VsY29tZSBhbnkgYW5k IGFsbA0KcmV2aWV3LiBTcGVjaWZpY2FsbHksIEkgaGF2ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4g b24gdGhpcw0Kbm90ZS4NCldlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBpdCB0byBhIFdHIGFzIGEg d29yayBpdGVtLS13aGljaCBXRw0Kd291bGQgYmUgYmVzdCBmb3IgdGhpcyBvbmU/IFRoZXJlIGFy ZSBzb21lIHNlY3Rpb25zIHRoYXQgbmVlZCB0bw0KYmUgZmlsbGVkIGJlZm9yZSB3ZSBwcmVzZW50 IGl0LCBJIHRoaW5rLg0KDQo6LSkNCg0KUnVzcw0KUGVyc29uYWx5IG9waW5pb246IHRoaXMgaXNu 4oCZdCBhYm91dCBJUHY2IHBlciBzZSwgaXQgaXMgYWJvdXQgdGhlDQpvcGVyYXRpb24gb2YgYW4g SVB2NiBuZXR3b3JrLiBJ4oCZZCBzdWdnZXN0IHY2b3BzLg0KTm90ZSB0aGF0IEnigJltIG5vdCBw cmVjbHVkaW5nIDZtYW4gaW5wdXQuIEnigJltIGFza2luZyB3aGF0IGNoYW5nZSBvcg0KY2xhcmlm aWNhdGlvbiBpbiBJUHY2IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgSVB2NiBNYWludGVuYW5jZSkg aXMNCmNhbGxlZCBmb3IuIEkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55LiBJIHRoaW5rIGl0 IGNvbW1lbnRzIG9uIGhvdw0KSVB2NiBpcyB1c2VkIG9wZXJhdGlvbmFsbHksIGFuZCBieSBleHRl bnNpb24sIHdoYXQgYW4gb3BlcmF0b3IgbWlnaHQNCmV4cGVjdCB0byBmaW5kIGluIElQdjYgaW1w bGVtZW50YXRpb25zIGhlIGRlcGxveXMuDQpJIHNvbWV3aGF0IGFncmVlLCBidXQ6IHdhc24ndCB0 aGUgTm9kZSBSZXF1aXJlbWVudHMgUkZDIHByb2R1Y2VkIGJ5DQo2bWFuPyAtLSB0aGlzIG9uZSBz aG91bGQgYmUgc2ltaWxhciBpbiBuYXR1cmUuLi4NCmFuZCA2MjA0IC8gNzA4NCAvIDc4NDkgd2Vy ZSBkb25lIGluIHY2b3BzLCBpdCdzIG5vdCB0aGF0IHVudXN1YWwgYSBzdHlsZQ0Kb2YgZG9jdW1l bnQgZ2VuZXJhbGx5IHNwZWFraW5nLg0KDQpUaGlzIGRyYWZ0IGlzIGEgbGl0dGxlIGRpZmZlcmVu dCB0byBSRkM2NDM0OyB0aGVyZeKAmXMgbW9yZSBvcGVyYXRpb25hbC9kZXNpZ24gdGV4dCBpbiB0 aGVyZS4NCg0KVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0LCBnaXZlbiBpdCBsb29rcyBsaWtl IHJlYWxseSBuaWNlIHdvcmssIGl0IGdldHMgYWRvcHRlZCBzb21ld2hlcmUgOikNCg0KVGltDQo= --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <9A47AC54E3C3084191FC74C2B4097D0B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA0IEphbiAyMDE3LCBhdCAwODow Nywgam9lbCBqYWVnZ2xpICZsdDs8YSBocmVmPSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSIgY2xh c3M9IiI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ T24NCiAxLzIvMTcgMTA6MDcgUE0sIEZlcm5hbmRvIEdvbnQgd3JvdGU6PC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCk9uIDAxLzAx LzIwMTcgMTA6MjYgUE0sIEZyZWQgQmFrZXIgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij5PbiBKYW4gMSwgMjAxNywgYXQgNToyMyBQTSwgRnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+ZnJlZGJha2VyLmlldGZAZ21h aWwuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQp3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5P biBEZWMgMzAsIDIwMTYsIGF0IDE6NTkgUE0sIFJ1c3MgV2hpdGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpydXNzQHJpdy51cyIgY2xhc3M9IiI+cnVzc0ByaXcudXM8L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj5JdCBpcyBpbmRlZWQgYW4gaW5kaXZpZHVhbCBkcmFmdCwgYW5kIHRvIG15 IGtub3dsZWRnZSBubyBnaXZlbjxiciBjbGFzcz0iIj4NCndvcmtpbmc8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQpncm91cDxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPmhhcyBiZWVuIGFza2VkIGZvciBvcGluaW9ucy4gVGhhdCBzYWlkLCB3ZSB3ZWxj b21lIGFueSBhbmQgYWxsPGJyIGNsYXNzPSIiPg0KcmV2aWV3LiBTcGVjaWZpY2FsbHksIEkgaGF2 ZSBjb3BpZWQgdjZvcHMgYW5kIDZtYW4gb24gdGhpczxiciBjbGFzcz0iIj4NCm5vdGUuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KV2Ugd291bGQgbGlrZSB0byBwcmVzZW50IGl0IHRvIGEg V0cgYXMgYSB3b3JrIGl0ZW0tLXdoaWNoIFdHPGJyIGNsYXNzPSIiPg0Kd291bGQgYmUgYmVzdCBm b3IgdGhpcyBvbmU/IFRoZXJlIGFyZSBzb21lIHNlY3Rpb25zIHRoYXQgbmVlZCB0bzxiciBjbGFz cz0iIj4NCmJlIGZpbGxlZCBiZWZvcmUgd2UgcHJlc2VudCBpdCwgSSB0aGluay48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo6LSk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSdXNz PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KUGVyc29uYWx5IG9waW5pb246IHRoaXMgaXNu 4oCZdCBhYm91dCBJUHY2IHBlciBzZSwgaXQgaXMgYWJvdXQgdGhlPGJyIGNsYXNzPSIiPg0Kb3Bl cmF0aW9uIG9mIGFuIElQdjYgbmV0d29yay4gSeKAmWQgc3VnZ2VzdCB2Nm9wcy48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQpOb3RlIHRoYXQgSeKAmW0gbm90IHByZWNsdWRpbmcgNm1hbiBp bnB1dC4gSeKAmW0gYXNraW5nIHdoYXQgY2hhbmdlIG9yPGJyIGNsYXNzPSIiPg0KY2xhcmlmaWNh dGlvbiBpbiBJUHY2IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgSVB2NiBNYWludGVuYW5jZSkgaXM8 YnIgY2xhc3M9IiI+DQpjYWxsZWQgZm9yLiBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgYXJlIGFueS4g SSB0aGluayBpdCBjb21tZW50cyBvbiBob3c8YnIgY2xhc3M9IiI+DQpJUHY2IGlzIHVzZWQgb3Bl cmF0aW9uYWxseSwgYW5kIGJ5IGV4dGVuc2lvbiwgd2hhdCBhbiBvcGVyYXRvciBtaWdodDxiciBj bGFzcz0iIj4NCmV4cGVjdCB0byBmaW5kIGluIElQdjYgaW1wbGVtZW50YXRpb25zIGhlIGRlcGxv eXMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KSSBzb21ld2hhdCBhZ3JlZSwgYnV0OiB3 YXNuJ3QgdGhlIE5vZGUgUmVxdWlyZW1lbnRzIFJGQyBwcm9kdWNlZCBieTxiciBjbGFzcz0iIj4N CjZtYW4/IC0tIHRoaXMgb25lIHNob3VsZCBiZSBzaW1pbGFyIGluIG5hdHVyZS4uLjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFuZA0KIDYyMDQgLyA3MDg0IC8g Nzg0OSB3ZXJlIGRvbmUgaW4gdjZvcHMsIGl0J3Mgbm90IHRoYXQgdW51c3VhbCBhIHN0eWxlPC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5vZg0KIGRv Y3VtZW50IGdlbmVyYWxseSBzcGVha2luZy48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPlRoaXMgZHJhZnQgaXMgYSBsaXR0bGUgZGlmZmVyZW50IHRvIFJGQzY0MzQ7IHRo ZXJl4oCZcyBtb3JlIG9wZXJhdGlvbmFsL2Rlc2lnbiB0ZXh0IGluIHRoZXJlLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGltcG9y dGFudCB0aGluZyBpcyB0aGF0LCBnaXZlbiBpdCBsb29rcyBsaWtlIHJlYWxseSBuaWNlIHdvcmss IGl0IGdldHMgYWRvcHRlZCBzb21ld2hlcmUgOik8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRpbTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_280F2FFCE7784A0CB4A77AF215588A8Ajiscacuk_-- From nobody Wed Jan 4 08:39: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 276B71299A4 for ; Wed, 4 Jan 2017 08:39:41 -0800 (PST) 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 jJqQUM_l1uU1 for ; Wed, 4 Jan 2017 08:39:39 -0800 (PST) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::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 17E1B12968A for ; Wed, 4 Jan 2017 08:39:39 -0800 (PST) Received: by mail-wj0-x22a.google.com with SMTP id tq7so236520715wjb.0 for ; Wed, 04 Jan 2017 08:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:references:cc:to; bh=WwUsgD59Udh92tBEHdgNs0eUNi5JibNmC+NGmj8jcQs=; b=oTmlvTZPzpWMEP0v1h8uagZFuLwGEob9kJ80VT4i+Rxc8mlvF04rRWjRYKYiaAmsWx 5/v+rOZsirlZHlWbdUOpyyTCaW1/J2YP3V7w3ZoR6HnMAq6jt6+ohaWUjzzM8yKAQMVl fEZLtSQFb5zXuM/4K/QSAPepO5DW7noGXr7Ata1RzRhFrQXOfiMouTHIm4mDfGSe1lEj YAAngj6hm0X2O/i6comcqjJDgr7XHMcAFqZS/zEuZ34zClVdsPnD7oamVEmgwPKifLaD dp6f3rgSZEV+ZykORwH6nbDNnSV4alkX4MqgiB5hs3LeSI0/8DnusmV36oSZcZBU1oOP s8Mg== 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 :references:cc:to; bh=WwUsgD59Udh92tBEHdgNs0eUNi5JibNmC+NGmj8jcQs=; b=BIDQu9x/YJmou/gPEuBFU6ZlMEv1N/nJQyEEOZul04IDW/QBKoWnF/pHUkln8uC8zl kfpJrD3UayPEvbQAsuL1eVhEvTfCPh51MlaFQTdmhEXYcBtBCZNG3yMiwg4EgKPu1ZsC lxNg6Is32XEdedn3PBVJ1bt6xyKuaitaqo6cKPwUPrIxbiM0yiC9FnJtzHYvACJHL5xK cFBU7ncObbwcN2abAaTPO7tyQN6JY16vSCyEzzg2MtMoubOyeRONcGx5xU+vdE8gCy29 tCWfRdD6aRKr4NCN4PRWsvuIj0Iy+dyxeXmIXPKaja0CvVua0rrKCeCZpW+tANTeXieC xoeQ== X-Gm-Message-State: AIkVDXKoUMowaLDzVDZPtndbrhhlQGayK4rtRgjMbVSxlhnK9UP/WhQtJnFPhTz8VeH+cg== X-Received: by 10.194.142.243 with SMTP id rz19mr56993864wjb.132.1483547977484; Wed, 04 Jan 2017 08:39:37 -0800 (PST) Received: from [10.0.0.21] (c-71-202-18-198.hsd1.ca.comcast.net. [71.202.18.198]) by smtp.gmail.com with ESMTPSA id g197sm95745896wmd.15.2017.01.04.08.39.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 08:39:36 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_B05E05EF-AE04-40B7-943F-5A38573785D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: REMINDER: 6man w.g. last call for Date: Wed, 4 Jan 2017 08:39:34 -0800 References: To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:39:41 -0000 --Apple-Mail=_B05E05EF-AE04-40B7-943F-5A38573785D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI > Begin forwarded message: >=20 > From: Bob Hinden > Subject: 6man w.g. last call for > Date: December 21, 2016 at 7:15:23 AM PST > To: IPv6 List > Cc: Bob Hinden , Ole Tr=C3=B8an = >=20 > This message starts a two week 6MAN Working Group Last Call on = advancing: >=20 > Title : Support for adjustable maximum router lifetimes = per-link > Authors : S. Krishnan > J. Korhonen > S. Chakrabarti > E. Nordmark > A. Yourtchenko > Filename : draft-ietf-6man-maxra-01 > Pages : 6 > Date : July 8, 2016 >=20 > https://tools.ietf.org/html/draft-ietf-6man-maxra-01 >=20 >=20 > as a Proposed Standard. Substantive comments and statements of = support > for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on 11 January 2017. >=20 > We also need two people to volunteer to do a detailed reviews, and a > volunteer to be the document Shepard. >=20 > Thanks, > Bob & Ole >=20 >=20 --Apple-Mail=_B05E05EF-AE04-40B7-943F-5A38573785D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYbSVHAAoJEK7rdBF357uoinUH/ju630ul3IEMlM0zTNvjFH5Q CmCvL6aW/IxFzTcEc8U8wY3OBcq/yf/6BNuoeNXbPXT4XFGc9rngtPtXFDi9Cszv NC6IcuefmTW/IFcsO4XOA/YFJtSINQd1lZU6Fr7ZaY3/tHQhSCv8bLolbVdcSXiY rQz+Sx7oyCWLQ9HJE1TLFnxkb+LB+QJRbXVTpAp+W+dEx+aWnwijmoVBgifXSodx FE8iH8COIAAoOr3Zm8KCaoSK5tvBPtKJs+9ZC94LyOpFs7RQu2RGQm0mfKz7PPjX RNsnAdHCsM2lg/z/E+MPnxLOvbCxUQ+In7Z0slsh/XYbIEYBZThN1/PPScxBZc0= =oRxS -----END PGP SIGNATURE----- --Apple-Mail=_B05E05EF-AE04-40B7-943F-5A38573785D3-- From nobody Wed Jan 4 22:02: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 AD823129ABC for ; Wed, 4 Jan 2017 22:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 w9ThgSfp6EVf for ; Wed, 4 Jan 2017 22:02:21 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 AD84812970F for ; Wed, 4 Jan 2017 22:02:21 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id 137so296841187vkl.0 for ; Wed, 04 Jan 2017 22:02:21 -0800 (PST) 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=eZseRQtIN+XsBxLoerASUJEG9WCCPDLhanuCwJ7UEUc=; b=DIceXavZjeJc/e3P3ybeIgEbNcHbJsfp5ZY22Bq0BDWWTBK9e0J9IS5KH6x1oSqaYA 1ngTCR4mzw2Bao9zNPPqdkq5Tn423L6KlR8YUCBQJzAa8xZ4cR4cCOBgoRkgKFkyqHoI RHimriuDB5N3NGamm159PtUM3zLaG4atgjl0rrzL9FLVskXg3/rYpdEVLR9AUP45vZUX JeSuxKK+byD9FeHDhlbOJlcysUNLf8mrcEhWkO5neIRNXb0Lf0rNhEQ58WjZDkWUIa1O p5jFo7R+ZCCcIbJmI6Z0gU7em4uhSyj9r7/IhAY/990uaqJJQJsyhQqHYgXKXuxyvobS XjtA== 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=eZseRQtIN+XsBxLoerASUJEG9WCCPDLhanuCwJ7UEUc=; b=YEIQsebE/6buOTvuf0L2mTyNy5eRlZQq/rqR4bNy1q4Z7dddfLrBn+cemsyAARGgRU mM6EuNl8N5llCIvvUyhvl+n7QntGBOB2gOVg3gx5Vh9uqjII2GQ+/gRvGgvQviMwXbfk v1miD2s2j56aqx0oovarIZ+0gIgC3JJMshV1A91BQ+b0W9c82/Tuq/yDTkxMX0924hRF M25zKS5Lowp7LuxNYrhVTEYVyGyz6bXlDZE8M1peaHIg9Ixa/7tu6lg2z/RtNkRWk/os Mvry6PioqTIMFszQksOHof3nPs8u4zSmYlStbfBygcBJkOd4Zio+spycJBdrSjjrZtAW Whdw== X-Gm-Message-State: AIkVDXJNkhcFLgaPNLWn09T4kqN5I4SZgZMA0qbNn19HprInWbzUryVi5OfIwIO9SsFjWkCJ6LKhdxuaFGPcsd+q X-Received: by 10.31.72.69 with SMTP id v66mr24780342vka.156.1483596140530; Wed, 04 Jan 2017 22:02:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Wed, 4 Jan 2017 22:02:00 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 5 Jan 2017 15:02:00 +0900 Message-ID: Subject: Re: REMINDER: 6man w.g. last call for To: Bob Hinden Content-Type: multipart/alternative; boundary=001a114d9c6ef29b19054552a467 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 06:02:23 -0000 --001a114d9c6ef29b19054552a467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I find section 3 (which provides guidance on how packet loss impacts reliability, and how much redundancy to use) very useful. Section 4 (which is the actual standards update) needs to be worded in more detail. For example, it should ensure that 0 values continue to be valid and have the same meaning as before the update. (At least to me, a literal reading of the current text suggests that 0 is no longer a valid value for AdvDefaultLifetime.) Perhaps a better approach would be to simply say that the 1800 and 9000 values specified in section 6.2.1 or RFC4861 are hereby replaced by 65535 Given that the text allows MaxRtrAdvInterval to be up to 65535, should the MaxRtrAdvInterval be bounded to 65534 (not 65535) to ensure that the RA arrives before the timer expires? On Thu, Jan 5, 2017 at 1:39 AM, Bob Hinden wrote: > FYI > > > Begin forwarded message: > > > > From: Bob Hinden > > Subject: 6man w.g. last call for > > Date: December 21, 2016 at 7:15:23 AM PST > > To: IPv6 List > > Cc: Bob Hinden , Ole Tr=C3=B8an > > > > This message starts a two week 6MAN Working Group Last Call on advancin= g: > > > > Title : Support for adjustable maximum router lifetimes > per-link > > Authors : S. Krishnan > > J. Korhonen > > S. Chakrabarti > > E. Nordmark > > A. Yourtchenko > > Filename : draft-ietf-6man-maxra-01 > > Pages : 6 > > Date : July 8, 2016 > > > > https://tools.ietf.org/html/draft-ietf-6man-maxra-01 > > > > > > as a Proposed Standard. Substantive comments and statements of support > > for publishing this document should be directed to the mailing list. > > Editorial suggestions can be sent to the authors. This last call will > > end on 11 January 2017. > > > > We also need two people to volunteer to do a detailed reviews, and a > > volunteer to be the document Shepard. > > > > Thanks, > > Bob & Ole > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a114d9c6ef29b19054552a467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I find section 3 (which provides guidance on how packet lo= ss impacts reliability, and how much redundancy to use) very useful.
Section 4 (which is the actual standards update) needs to be w= orded in more detail. For example, it should ensure that 0 values continue = to be valid and have the same meaning as before the update. (At least to me= , a literal reading of the current text suggests that 0 is no longer a vali= d value for=C2=A0AdvDefaultLifetime.) Perhaps a better approach would be to= simply say that the 1800 and 9000 values specified in section 6.2.1 or RFC= 4861 are hereby replaced by 65535=C2=A0

Given that= the text allows=C2=A0MaxRtrAdvInterval to be up to 65535, should the=C2=A0= MaxRtrAdvInterval be bounded to 65534 (not 65535) to ensure that the RA arr= ives before the timer expires?

On Thu, Jan 5, 2017 at 1:39 AM, Bob Hinden <bo= b.hinden@gmail.com> wrote:
= FYI

> Begin forwarded message:
>
> From: Bob Hinden <bob.hinde= n@gmail.com>
> Subject: 6man w.g. last call for <draft-ietf-6man-maxra-01>
> Date: December 21, 2016 at 7:15:23 AM PST
> To: IPv6 List <ipv6@ietf.org&g= t;
> Cc: Bob Hinden <bob.hinden@= gmail.com>, Ole Tr=C3=B8an <otroan@employees.org>
>
> This message starts a two week 6MAN Working Group Last Call on advanci= ng:
>
>=C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Sup= port for adjustable maximum router lifetimes per-link
>=C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Krish= nan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0J. Korhonen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0S. Chakrabarti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0E. Nordmark
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0A. Yourtchenko
>=C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-6m= an-maxra-01
>=C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 6 >=C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Jul= y 8, 2016
>
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/h= tml/draft-ietf-6man-maxra-01
>
>
> as a Proposed Standard.=C2=A0 Substantive comments and statements of s= upport
> for publishing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors.=C2=A0 This last call= will
> end on 11 January 2017.
>
> We also need two people to volunteer to do a detailed reviews, and a > volunteer to be the document Shepard.
>
> Thanks,
> Bob & Ole
>
>


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


--001a114d9c6ef29b19054552a467-- From nobody Thu Jan 5 00:43: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 93FA512940D; Thu, 5 Jan 2017 00:43:40 -0800 (PST) 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 i6SIm0HvPPLE; Thu, 5 Jan 2017 00:43:39 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C9C1294B1; Thu, 5 Jan 2017 00:43:39 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t125so336558503ywc.1; Thu, 05 Jan 2017 00:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EfwLPs1hptSc0tZGdbwjVA0/weOG8EQ7QZKC4UTtb8Y=; b=FoCGX+Jh3UDwxkkutwYvS6JZC73e/2zI92/gTtFiKun1Cx3bo2z8C/w5MajohkOl2Q CO92w2eFxt8Hfeu73FlPn5l3xeh2z0jQPcDVe1pes/6YQ0dsK4aWuPK2GUBPV2dAb+tB 6gMhK9W2KTMxyCAUbk7zGBUvFctCnRvEO9614OyOg6WtZmudp+ewZO0A1ZLw7PhcE8KU e2IwvgaoaDAmlp869PDPOviq6X4Ce3qxxhVOQMfQ3JXn0gvlzHCswU18vOZYJoYKorVH 2SDi5Gkz+NCYj4zCIWk0+CfMvznRHXftq3TopdArKpiuQFxdWjQYT8w8hhU246qIDD3A lBtA== 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=EfwLPs1hptSc0tZGdbwjVA0/weOG8EQ7QZKC4UTtb8Y=; b=ABsR5vbXuaUEheJc/9k9/6lW5fdOb9QK19FVOrrTtCPrsQC9HjzDJeWcuJlW6fB5yY XMiUwgWwx83mCJxOsotG5bVCfTFO0rj064PRAg7iAXL8NLfCJWnSt+KGh4LiWAoBPdcH 0c3qOudQHioP3gGN5L1FtMHatzcfxKHcPP9didakuBugmObF4wbVfWS2rPo9oYDqVhF7 qB9ccAa/VvA42g+CvWI8xgMzWsUct1380IVw1nEA6gvf+2GQnvsqKpq/nokBihL2XzRH 6B2Lre4cBgMbByu8esT2N3xFDMz1/EIXWekmuA+0gay1ahx9u6c8u7sJS9eeXGPPP/tC 4PHA== X-Gm-Message-State: AIkVDXLCCJlS/v4tAzdPIPr4OAihrMXZAkQeKgewINIcvuvVbi3vFqFhiSMM0TXnBFITO63/1MzbGsNEAMMrOw== X-Received: by 10.129.119.7 with SMTP id s7mr73527774ywc.57.1483605818505; Thu, 05 Jan 2017 00:43:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 00:43:18 -0800 (PST) From: Naveen Kottapalli Date: Thu, 5 Jan 2017 14:13:18 +0530 Message-ID: Subject: Why is 0 UDP checksum not valid for IPv6? To: 6man WG , v6ops list Content-Type: multipart/alternative; boundary=001a1149008ccc8547054554e580 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 08:43:40 -0000 --001a1149008ccc8547054554e580 Content-Type: text/plain; charset=UTF-8 Hello, Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it is valid for IPv4? Yours, Naveen. --001a1149008ccc8547054554e580 Content-Type: text/html; charset=UTF-8
Hello,

Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it is valid for IPv4?

Yours,
Naveen.
--001a1149008ccc8547054554e580-- From nobody Thu Jan 5 01:33: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 688C2128E19; Thu, 5 Jan 2017 01:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnZRY0-ejHa3; Thu, 5 Jan 2017 01:33:00 -0800 (PST) Received: from inbound03.kjsl.com (inbound03.kjsl.com [IPv6:2001:1868:a100:131::62]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6A7129519; Thu, 5 Jan 2017 01:32:58 -0800 (PST) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport03.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 09:32:57 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5DD999CC7D; Thu, 5 Jan 2017 01:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=HnTzq2DikmtQkoZW+ndKW5bDTTY=; b=rkQu2w5j9e8JWTGBz8 ryj8Vi0GgecIhgif8NnLoAgY03kIGKEVzUAB5w08omcF823v6tyW3BrZ9Z/PiJpV FlCglccR7baK6V6xLfGkR85MLryjpbZB4KFD0QHfRmeyQzthZxjtXFEt1RPYxT3f lQghYxEbnqLGfwBQTmyeuDRIE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=SkVwzl7bUPu2WtauM0oRvUfPU1fleAmFzstuELjNUfjeU/lTy85 IIMTAFEbJkdwzQ710ANG6eVFGRFBcg8OJxGtnf3fNxlU4ppot0AGzzOHipkLTuD8 KPLjV5Qo8rYqFCj6thYEV+QqxauXXhS64tIdQ2K9VWZe0oleWxBuD0yc= Received: from h.hanazo.no (2.150.57.252.tmi.telenormobil.no [2.150.57.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A05369CC51; Thu, 5 Jan 2017 01:32:55 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5B9C5704D6ED; Thu, 5 Jan 2017 10:32:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Why is 0 UDP checksum not valid for IPv6? From: otroan@employees.org In-Reply-To: Date: Thu, 5 Jan 2017 10:32:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> References: To: Naveen Kottapalli X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:33:01 -0000 Naveen, > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it = is valid for IPv4? RFC6935 RFC6936 Cheers, Ole From nobody Thu Jan 5 02:08: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 AA74A129429; Thu, 5 Jan 2017 02:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 z8WblgC5wSJ6; Thu, 5 Jan 2017 02:08:16 -0800 (PST) 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 903CE129423; Thu, 5 Jan 2017 02:08:16 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id r204so338574735ywb.0; Thu, 05 Jan 2017 02:08:16 -0800 (PST) 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=clpn3jSXfYLol3iOVlVP0VboV6FwYdJVBAsk23RZosM=; b=iwU4WwvCHJ4pCxZMLFZbipnYcyBXQd4xhh9B8Z+83IDzmoXNc6m/BO+1e7v3gs7amO t94fGNxxMR+vPcR3HenJcoEaXz+fDkQE0n6Xfm3w+MGVM5yI4GsujdoxS16DYIWUSCl5 Ms/wLf2AdzUiLwxMEG3KByAuh4lwOAXO8Unh60PUlZzgBWzpvgorxfwydW7dvHUj9gRp +tABvD2tE/hR/2ckQnr7SSUK5p76EBTrlp5bMxB6pd2lXBj5tVlt61jZaMJ64CiO5Dfw 9Amlg+kuPffSiUxeokOMKz3MFMDkMFAtN89I1LARpRtIlLwDFzoEJUAWL+nCYBKYgZ+Q TH/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; bh=clpn3jSXfYLol3iOVlVP0VboV6FwYdJVBAsk23RZosM=; b=bvAuEVIOUOMLnC68ejWc57fuysB++el+yxuOH08TnMXRottb/ortWjvUXNY6VT+mLQ spvQouffy9WGgwXfN/GMODG6DGYsMo1wjPnSvpKCi1cgszfadCZgWMyx4oGomdkkb4wu DC7qGcpVL7/yNeP58Bldz+5P73V7fMsTWBUbgX33ST4uwOBiJTTv0T8lBctfPAFgtGSH AGPAwiQUIg15XadMp9dJuxZokJnMt5k7u1QBkdKQOcb2tl80LncbI9yLKr6z8DaWmdPr 2JWqJhc3V0I0w4VICie0XXn9Pyf/PzKpqLvTcHQWl9TqzlASyNnjknvhmh1FdV+eZi/U pkIw== X-Gm-Message-State: AIkVDXJB1NrYeAQCFkucyTxQZaijsZDtuvCy7R7frp1gL/MpnmoIALBszCwen83CEKL3662avrIFmrjLho7nTg== X-Received: by 10.13.202.73 with SMTP id m70mr61127957ywd.251.1483610895845; Thu, 05 Jan 2017 02:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 02:07:55 -0800 (PST) In-Reply-To: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> From: Naveen Kottapalli Date: Thu, 5 Jan 2017 15:37:55 +0530 Message-ID: Subject: Re: Why is 0 UDP checksum not valid for IPv6? To: otroan@employees.org Content-Type: multipart/alternative; boundary=001a114816606e912d05455614b4 Archived-At: Cc: v6ops list , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:08:18 -0000 --001a114816606e912d05455614b4 Content-Type: text/plain; charset=UTF-8 I see those two RFCs talk mainly about the usage of UDP in tunneled protocols, but couldn't find why it is mandated for a normal plain IPv6 packet carrying a UDP payload with a DNS query or a response. In general am trying to find the reason why it is mandated in IPv6 base specification (RFC2460) itself. Can you please clarify on the above? Yours, Naveen. On 5 January 2017 at 15:02, wrote: > Naveen, > > > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas it > is valid for IPv4? > > RFC6935 > RFC6936 > > Cheers, > Ole > > --001a114816606e912d05455614b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see those two RFCs talk mainly about the usage of UDP in= tunneled protocols, but couldn't find why it is mandated for a normal = plain IPv6 packet carrying a UDP payload with a DNS query or a response.
In general am trying to find the reason why it is mandated= in IPv6 base specification (RFC2460) itself.

Can = you please clarify on the above?

Yours,
Naveen.

On 5 January 2017 at 15:02, <otroan@emp= loyees.org> wrote:
Naveen,<= br>
> Can anyone tell why is 0 UDP checksum isn't valid for IPv6, wherea= s it is valid for IPv4?

RFC6935
RFC6936

Cheers,
Ole


--001a114816606e912d05455614b4-- From nobody Thu Jan 5 02:11: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 31BBA1294C0; Thu, 5 Jan 2017 02:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 FPLLt6foOCjS; Thu, 5 Jan 2017 02:11:05 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:eeb1:d7ff:fe59:fbaa]) by ietfa.amsl.com (Postfix) with ESMTP id 5702812949D; Thu, 5 Jan 2017 02:11:05 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 15B2C43E9CB; Thu, 5 Jan 2017 11:11:03 +0100 (CET) Date: Thu, 05 Jan 2017 11:11:02 +0100 (CET) Message-Id: <20170105.111102.1073811603989045784.he@uninett.no> To: naveen.sarma@gmail.com Subject: Re: Why is 0 UDP checksum not valid for IPv6? From: Havard Eidnes In-Reply-To: References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ipv6@ietf.org, v6ops@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:11:07 -0000 >> > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, wherea= s it >> > is valid for IPv4? >> >> RFC6935 >> RFC6936 > > I see those two RFCs talk mainly about the usage of UDP in tunneled > protocols, but couldn't find why it is mandated for a normal plain IP= v6 > packet carrying a UDP payload with a DNS query or a response. > = > In general am trying to find the reason why it is mandated in IPv6 ba= se > specification (RFC2460) itself. > = > Can you please clarify on the above? 6936 says: The key difference between UDP usage with IPv4 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, i.e., a non-zero value, due to the lack of an IPv6 header checksum. Regards, - H=E5vard From nobody Thu Jan 5 02:20: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 10B1F12950D; Thu, 5 Jan 2017 02:20:04 -0800 (PST) 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 4pifa5jHZuV8; Thu, 5 Jan 2017 02:20:02 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9940612949A; Thu, 5 Jan 2017 02:20:02 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id t125so338237468ywc.1; Thu, 05 Jan 2017 02:20:02 -0800 (PST) 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=rK0hnxT2HTycomBNYV1YCM/KU/e29NdefzC+pIpUV9c=; b=WGHITqq0SJE2VewczuH0ycOqjzebs83zfPeyemlVhvNLdYOvtrGqvd6BGY0gRYi3V0 26GqoEZX7CFoK9PTwJx3rEN+nsq/y/xH8kA0FuzOsGJCiVa44c3DIX/lWQ24kStBcN5L LNiOu5WTsuszcXzOMUkDtlBug4Qi5D0gicmF0TK+A34USc9iNQ1zbr9c1IFgBkCvYZGf BqmGXQGAJpfH0kwk1Jct2+BXevT9PtLZmAAx5is2jpFTnIXEHmCTWSb3AZ4oHLnxlqpK 00Qs1Z/KpB9j3T3HM5vRHBL684OqvXbDpR9b6C95uiakIJqh6ooNsBadiyZRKy15NBAX ZzhQ== 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=rK0hnxT2HTycomBNYV1YCM/KU/e29NdefzC+pIpUV9c=; b=DNyi8a2VxI/rimfK15lzGrEkxWLJ4tUyZeziOfMDDYpJVFLbTMYYlD9cM35o8UlD8s wxAuAYCxcGCb3Zfl5nvIkgpmabzdM0CLGqs7ubQBtZKWolOYEUfl54GAxCc9PyiT4Tud QdVJ0qcaXZKCGqPaBRinzZNwR8LPK5JEaR9DlCwoBXMS9ewCtIXuRNmNkju7C6pEfcEI j6YpMSLJzfBkrjWOI3VVOaD1fY/rQOLFkIEk6w5DfLpkN8iDYF2l2SXeW8doME9KE8wZ gtiR5J0m9CIQ15qerwy+h16zcnavaudzoNnH8klhIGDY/1uB+ccECXFRN0MzRakF8f// NtAQ== X-Gm-Message-State: AIkVDXKVpj8e7EwXrGFivkBwK6aT9H9mTpfp5XQvnSLglqrdpx2ETzaR7SX6e3gLN2Ab7B0q9tlVBxUsRCe+/A== X-Received: by 10.129.152.133 with SMTP id p127mr72895388ywg.281.1483611601949; Thu, 05 Jan 2017 02:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.172.94 with HTTP; Thu, 5 Jan 2017 02:19:41 -0800 (PST) In-Reply-To: <20170105.111102.1073811603989045784.he@uninett.no> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> <20170105.111102.1073811603989045784.he@uninett.no> From: Naveen Kottapalli Date: Thu, 5 Jan 2017 15:49:41 +0530 Message-ID: Subject: Re: Why is 0 UDP checksum not valid for IPv6? To: Havard Eidnes Content-Type: multipart/alternative; boundary=94eb2c0bc3e284deb60545563e41 Archived-At: Cc: 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 10:20:04 -0000 --94eb2c0bc3e284deb60545563e41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks a lot. Yours, Naveen. On 5 January 2017 at 15:41, Havard Eidnes wrote: > >> > Can anyone tell why is 0 UDP checksum isn't valid for IPv6, whereas = it > >> > is valid for IPv4? > >> > >> RFC6935 > >> RFC6936 > > > > I see those two RFCs talk mainly about the usage of UDP in tunneled > > protocols, but couldn't find why it is mandated for a normal plain IPv6 > > packet carrying a UDP payload with a DNS query or a response. > > > > In general am trying to find the reason why it is mandated in IPv6 base > > specification (RFC2460) itself. > > > > Can you please clarify on the above? > > 6936 says: > > The key difference between UDP usage with IPv4 and IPv6 is that RFC > 2460 mandates use of a calculated UDP checksum, i.e., a non-zero > value, due to the lack of an IPv6 header checksum. > > Regards, > > - H=C3=A5vard > --94eb2c0bc3e284deb60545563e41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks a lot.

Yours,
Naveen.

On 5 January 2017 at 15:41, Havard Eidnes <he@u= ninett.no> wrote:
>> > Can anyone tell why is 0 UDP checksum isn't vali= d for IPv6, whereas it
>> > is valid for IPv4?
>>
>> RFC6935
>> RFC6936
>
> I see those two RFCs talk mainly about the usa= ge of UDP in tunneled
> protocols, but couldn't find why it is mandated for a normal plain= IPv6
> packet carrying a UDP payload with a DNS query or a response.
>
> In general am trying to find the reason why it is mandated in IPv6 bas= e
> specification (RFC2460) itself.
>
> Can you please clarify on the above?

6936 says:

=C2=A0 =C2=A0The key difference between UDP usage with IPv4 and IPv6 is tha= t RFC
=C2=A0 =C2=A02460 mandates use of a calculated UDP checksum, i.e., a non-ze= ro
=C2=A0 =C2=A0value, due to the lack of an IPv6 header checksum.

Regards,

- H=C3=A5vard

--94eb2c0bc3e284deb60545563e41-- From nobody Thu Jan 5 03:54: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 AD5C4129B0B for ; Thu, 5 Jan 2017 03:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxtOtQx4fywo for ; Thu, 5 Jan 2017 03:54:19 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAD4129B08 for ; Thu, 5 Jan 2017 03:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GwTyZ5DYOAMwI5EFaKDtfgZNW/xHPfEkDpcm/EY1llQ=; b=Fkp5z8vVeOdCWUTHAgSEhapKyVNCRgCdgdWTyXbp3z/libPCD9/iJ0WVtETL9StSvkLFLDa3o51TBNn4YUgX8dsEmI96g1yusn4gqCXcQRmX8bHIjnIs5RMEkHzbtjzfKNEH4K7AoY9j8rewRsD55pLUgyohipB5SLgRcV84bAI= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0183.outbound.protection.outlook.com [213.199.154.183]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-75-2rXLouYtP4iSxIuKzNk0Gw-1; Thu, 05 Jan 2017 11:54:14 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Thu, 5 Jan 2017 11:54:12 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::292e:d46e:7c2b:75c6%15]) with mapi id 15.01.0829.007; Thu, 5 Jan 2017 11:54:12 +0000 From: Tim Chown To: Bob Hinden Subject: Re: REMINDER: 6man w.g. last call for Thread-Topic: REMINDER: 6man w.g. last call for Thread-Index: AQHSZqlXGgDs5ZsIcE6rBm2OmC5Zr6Epx4iA Date: Thu, 5 Jan 2017 11:54:12 +0000 Message-ID: <3B76B8CC-8F1F-4FF0-ADAB-656B1819B453@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a82d:9a3d:e97d:de47] x-ms-office365-filtering-correlation-id: 23d97306-75c9-40ad-e778-08d4356190f1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:5sc2FbAxQy4hoNmtI0YwYoEqFbDi4BcUXauT2tWi/FK+PZDXDTrhx6ZuK6WFbJgBmUNhBqBLB9fiJ6fZtvKlM+rrMC6gbGA95iN4nWpEaktoF6MM6QjxOLEZ0BiLlh/+eWI5WEYl9kZJyHe4gRfjh+mIaNrt9/eNeE8x7dqzVA4dO8ZA1fbAUVDqOAPMDHIWvJzvG5eHmO+qiWuh1Ik3BcWSW6TYPIUqgnFWRdCgyPdBiT/xrdLqJoxH3eY1Okxbbsbys1n1qsEvUeV7mxxa+4M7r6KOCBjZ+NQhXFGLO4WfUBOo/uDsJfkQ+e1tzED4KFFQBpKxzrD8ML0YhCfhsra3I35FanFwnnReJ5BQkx4hdEJbtqsaN3mQDx2NNMHyGkmJSnTDfMWd+2CKuvQwHEToHrA10o0y4/2HbRKKCLXtMGPB5LKkyiTTXJDxnUoLS3DpqB7Yy0LRBaKIPgpvAQ==; 20:tmP06m5JHUQTcUiCsO6vX3XypH/ZNdFaEtCMjc5lDQWkJ1/niPRWE2Srr1E+/GxjCFGQTKY0qGG8h1JbJEiKAspgLy71/F7Pl9EYdTyT8ldWnm6wEpMafNPu91zIhH6yMox0IuGGWuE95ooTtbYj/021I4qHZMpu/pCJ0U+jxlk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(12213003)(189002)(69234005)(377454003)(199003)(24454002)(57306001)(2906002)(86362001)(4326007)(92566002)(33656002)(8676002)(3280700002)(101416001)(5660300001)(99286003)(36756003)(50986999)(76176999)(42882006)(2950100002)(6916009)(305945005)(2900100001)(230783001)(50226002)(110136003)(39060400001)(38730400001)(83716003)(229853002)(3660700001)(8936002)(6306002)(6512006)(106116001)(82746002)(81156014)(105586002)(102836003)(6116002)(106356001)(6506006)(81166006)(7736002)(6486002)(74482002)(6436002)(97736004)(68736007)(5250100002)(189998001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <11982E02FD29F14080F2F985C791A8E4@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 11:54:12.3682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: 2rXLouYtP4iSxIuKzNk0Gw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:54:22 -0000 SGksDQoNCkp1c3QgYSBicmllZiBjb21tZW50IG9uIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cy4NCg0KVGhpcyBkcmFmdCBjb3VsZCBtZW50aW9uIFJGQzYxMDU7IGN1cnJlbnRseSBpdCBvbmx5 IHNheXMgdGhhdCByb2d1ZSBSQXMgY2FuIOKAnGVhc2lseeKAnSBiZSBwcmV2ZW50ZWQgdGhyb3Vn aCB1c2Ugb2YgU2VORCwgYnV0IGluIHByYWN0aWNlIFJBIEd1YXJkIGFwcHJvYWNoZXMgYXJlIHRo ZSBjb21tb24gbWl0aWdhdGlvbi4gIEnigJltIGFsc28gbm90IHN1cmUgdGhlIOKAnGF0dGFjayB3 aW5kb3figJ0gY2hhbmdlczsgdGhlcmUgaXMgZWl0aGVyIGEgcm9ndWUgUkEgb3IgdGhlcmUgaXNu 4oCZdCwgcmVnYXJkbGVzcyBvZiB0aGUgdHJ1ZSBSQSBpbnRlcnZhbC4NCg0KVGltIA0KDQo+IE9u IDQgSmFuIDIwMTcsIGF0IDE2OjM5LCBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4g d3JvdGU6DQo+IA0KPiBGWUkNCj4gDQo+PiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4+IA0K Pj4gRnJvbTogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+DQo+PiBTdWJqZWN0OiA2 bWFuIHcuZy4gbGFzdCBjYWxsIGZvciA8ZHJhZnQtaWV0Zi02bWFuLW1heHJhLTAxPg0KPj4gRGF0 ZTogRGVjZW1iZXIgMjEsIDIwMTYgYXQgNzoxNToyMyBBTSBQU1QNCj4+IFRvOiBJUHY2IExpc3Qg PGlwdjZAaWV0Zi5vcmc+DQo+PiBDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+ LCBPbGUgVHLDuGFuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4NCj4+IA0KPj4gVGhpcyBtZXNzYWdl IHN0YXJ0cyBhIHR3byB3ZWVrIDZNQU4gV29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gYWR2YW5j aW5nOg0KPj4gDQo+PiAgICBUaXRsZSAgICAgICAgICAgOiBTdXBwb3J0IGZvciBhZGp1c3RhYmxl IG1heGltdW0gcm91dGVyIGxpZmV0aW1lcyBwZXItbGluaw0KPj4gICAgQXV0aG9ycyAgICAgICAg IDogUy4gS3Jpc2huYW4NCj4+ICAgICAgICAgICAgICAgICAgICAgIEouIEtvcmhvbmVuDQo+PiAg ICAgICAgICAgICAgICAgICAgICBTLiBDaGFrcmFiYXJ0aQ0KPj4gICAgICAgICAgICAgICAgICAg ICAgRS4gTm9yZG1hcmsNCj4+ICAgICAgICAgICAgICAgICAgICAgIEEuIFlvdXJ0Y2hlbmtvDQo+ PiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLTZtYW4tbWF4cmEtMDENCj4+ICAgIFBh Z2VzICAgICAgICAgICA6IDYNCj4+ICAgIERhdGUgICAgICAgICAgICA6IEp1bHkgOCwgMjAxNg0K Pj4gDQo+PiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLW1h eHJhLTAxDQo+PiANCj4+IA0KPj4gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZC4gIFN1YnN0YW50aXZl IGNvbW1lbnRzIGFuZCBzdGF0ZW1lbnRzIG9mIHN1cHBvcnQNCj4+IGZvciBwdWJsaXNoaW5nIHRo aXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRpcmVjdGVkIHRvIHRoZSBtYWlsaW5nIGxpc3QuDQo+PiBF ZGl0b3JpYWwgc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQgdG8gdGhlIGF1dGhvcnMuICBUaGlzIGxh c3QgY2FsbCB3aWxsDQo+PiBlbmQgb24gMTEgSmFudWFyeSAyMDE3Lg0KPj4gDQo+PiBXZSBhbHNv IG5lZWQgdHdvIHBlb3BsZSB0byB2b2x1bnRlZXIgdG8gZG8gYSBkZXRhaWxlZCByZXZpZXdzLCBh bmQgYQ0KPj4gdm9sdW50ZWVyIHRvIGJlIHRoZSBkb2N1bWVudCBTaGVwYXJkLg0KPj4gDQo+PiBU aGFua3MsDQo+PiBCb2IgJiBPbGUNCj4+IA0KPj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Thu Jan 5 08:10: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 5111712958C; Thu, 5 Jan 2017 08:10:14 -0800 (PST) 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 pK9YJgL6DZXU; Thu, 5 Jan 2017 08:10:12 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C333D129577; Thu, 5 Jan 2017 08:10:12 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id i5so41134395pgh.2; Thu, 05 Jan 2017 08:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ehXc6bbh8xuClBOUUUA7gOry+qmJhr7hqpOaUxQ/KX0=; b=PBtYaD7OgL87IfQzgWzmFOZeJALU2PoFAARs2pNM2Iy/Wno9yDMyK5yiL8pRMB2M8U DkriFTXyT4y1MdwUiRACy4WMRky3VXC62Xzo8hLwVUaJeE0QIANhPFhG4F8R6Z+c03nu BLnOkNX1JVHh9z6XeHs3NJ5HvTcvYnoM+WeLQg6xgIYXNZm8zkZaIC13qQVk+MB2r2l/ O3fe0TU5BBJotEL2wu+X9lnPd3ZhJVGb1wAe6bLG5T7rvWdVNgaZSFqbrcphDFmTDKT1 5RvzuS/LUGGFe9wjMXQO/7DNXAe3AJjkxKM4saji37Yf/StNF8dgGeI8ykeQrUFjgBNr 27iA== 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=ehXc6bbh8xuClBOUUUA7gOry+qmJhr7hqpOaUxQ/KX0=; b=UJKZ6EqQja94eUjT6MEIZGZaUlKt1xHbACju36gab5717IHKk9Hijr9L42VN6zMaks oPtBejoTwSTihR24YGgAORoCQnX4V8d4y5NvP/uaH1YemS/inufHcVa4R05YfGljksDf 1JzCfqQwNUDop3KdQiDruepqE7OCeP1LWQ6n0DgWixPc2DaYiNRIOuqbMEll8ZCSkz1i QSutJLSCRKARYW86zXjzU1XLqM/7hHL47kQjKnsN39vWzJHowsOhUia/60IXBNNPemB3 e72CfwGlxZB7hBx4v0sGyG9hHh3Nyq+thPSRUGWYQZ0cZw6sAJcahtqLBK2qWZWCFsHO mo8g== X-Gm-Message-State: AIkVDXLvw16/QxRUvCe9QRjdm9r83h5IEw2UzASDPewfNrhhK29HSKspGzPU7R4SD3TPJg== X-Received: by 10.99.218.85 with SMTP id l21mr134577182pgj.102.1483632612379; Thu, 05 Jan 2017 08:10:12 -0800 (PST) Received: from [192.168.1.2] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id 186sm154659470pfv.61.2017.01.05.08.10.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 08:10:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Why is 0 UDP checksum not valid for IPv6? From: Fred Baker In-Reply-To: Date: Thu, 5 Jan 2017 08:10:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0E543D67-DF12-4736-A874-C4C52E6D91CA@gmail.com> References: <48EECE17-E5F3-452A-88A3-DF1891466AEE@employees.org> To: Naveen Kottapalli X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , v6ops list X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:10:14 -0000 > On Jan 5, 2017, at 2:07 AM, Naveen Kottapalli = wrote: >=20 > I see those two RFCs talk mainly about the usage of UDP in tunneled = protocols, but couldn't find why it is mandated for a normal plain IPv6 = packet carrying a UDP payload with a DNS query or a response. The primary difference that triggered this is that whereas IPv4 has a = header checksum, IPv6 does not, and there have been anecdotal reports of = checksum errors being found in IPv4 packets in the wild. The IPv6 = designers, mid-1990's, felt that not having a checksum AT ALL left room = for concern, and leaving it to the application was too loose a rule.=20= From nobody Thu Jan 5 20:01: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 5EF04129415 for ; Thu, 5 Jan 2017 20:01:49 -0800 (PST) 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 xboAQCq6M7XJ for ; Thu, 5 Jan 2017 20:01:48 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA0F12896F for ; Thu, 5 Jan 2017 20:01:47 -0800 (PST) X-AuditID: c6180641-e73ff70000000a0b-43-586ec23ebac1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id B8.2D.02571.E32CE685; Thu, 5 Jan 2017 23:01:36 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 23:01:43 -0500 From: Suresh Krishnan To: Lorenzo Colitti , Bob Hinden Subject: Re: REMINDER: 6man w.g. last call for Thread-Topic: REMINDER: 6man w.g. last call for Thread-Index: AQHSW50X2LnjnTgUGkSWKZE0Ax0x4g== Date: Fri, 6 Jan 2017 04:01:23 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn67DobwIg8NfjC22vt/HZvHy7Hsm i/Wn3zE6MHvsnHWX3WPBplKPJUt+MgUwR3HZpKTmZJalFunbJXBlLJi/jrWgVaDi2aPqBsa/ PF2MnBwSAiYSk49OZexi5OIQEljPKLHhxkFWCGcZo8SUXeeZQarYgKo27PzMBGKLCHhLvNjR BxTn4GAWkJW4NikSJCws4Cnxf+UOVogSL4lphz9D2XoSX1fNZgexWQRUJFZcvswGYvMK+Ep0 9F1igdi1jVFi5uTfLCAJRgExie+n1oDtYhYQl7j1ZD4TxKUCEkv2QNwjISAq8fLxP1YIW0li zutrzBD1OhILdn9ig7C1JZYtfM0MsUxQ4uTMJywTGEVmIRk7C0nLLCQts5C0LGBkWcXIUVpc kJObbmS4iREYB8ck2Bx3MO7t9TzEKMDBqMTDa6CeFyHEmlhWXJl7iFGCg1lJhFdfJD9CiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO/1kPvhQgLpiSWp2ampBalFMFkmDk6pBsYq85Wrb1/OP6T8 t/xv5dStrZa9MTz3fm8L8Z39bMLczUrHm08+sVHP++GVIeNQl3X40AM5nuiyk6bxN706m1st Tz6p8fAMFk/oCZZamHdO8c+jpFlNtww8VtWZdZoXyC888uRM1fLaTXWNcbf3nTn3Pq7wzgJJ Dh2ejPWbV7/M2F/xMtPhsbwSS3FGoqEWc1FxIgAFrZRKfwIAAA== Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 04:01:49 -0000 Hi Lorenzo,=0A= =0A= On 01/05/2017 01:02 AM, Lorenzo Colitti wrote:=0A= > I find section 3 (which provides guidance on how packet loss impacts=0A= > reliability, and how much redundancy to use) very useful.=0A= >=0A= > Section 4 (which is the actual standards update) needs to be worded in mo= re=0A= > detail. For example, it should ensure that 0 values continue to be valid = and=0A= > have the same meaning as before the update. (At least to me, a literal=0A= > reading of the current text suggests that 0 is no longer a valid value=0A= > for AdvDefaultLifetime.)=0A= =0A= =0A= Yes. I do now see that reading as possible as well. Suggest the following c= hange=0A= =0A= OLD:=0A= =0A= MaxRtrAdvInterval MUST be no greater than 65535. AdvDefaultLifetime MUST b= e =0A= between MaxRtrAdvInterval and 65535.=0A= =0A= NEW:=0A= =0A= MaxRtrAdvInterval MUST be no greater than 65535. AdvDefaultLifetime MUST = =0A= either be zero (the router is not to be used as a default router) or be a = =0A= value between MaxRtrAdvInterval and 65535.=0A= =0A= Does that work?=0A= =0A= "=0A= Perhaps a better approach would be to simply say=0A= > that the 1800 and 9000 values specified in section 6.2.1 or RFC4861 are= =0A= > hereby replaced by 65535=0A= =0A= See above. Either change works for me.=0A= =0A= >=0A= > Given that the text allows MaxRtrAdvInterval to be up to 65535, should=0A= > the MaxRtrAdvInterval be bounded to 65534 (not 65535) to ensure that the = RA=0A= > arrives before the timer expires?=0A= =0A= Hmm. Not sure about this. According to Section 6.2.4. of RFC4861 the =0A= multicast RA is sent on a "timer that is set to a uniformly distributed =0A= random value between MinRtrAdvInterval and MaxRtrAdvInterval". That should= =0A= take care of it automatically*, right?=0A= =0A= Thanks=0A= Suresh=0A= =0A= *: Not sure about other implementations but I interpreted this range as =0A= excluding the MinRtrAdvInterval and MaxRtrAdvInterval (but this might be = =0A= worth checking).=0A= From nobody Thu Jan 5 20:11:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8A129886 for ; Thu, 5 Jan 2017 20:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uhOxhmUTU4h for ; Thu, 5 Jan 2017 20:11:06 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA46512987B for ; Thu, 5 Jan 2017 20:11:05 -0800 (PST) X-AuditID: c618062d-e8e5698000007359-ea-586f1f16545e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id B6.05.29529.61F1F685; Fri, 6 Jan 2017 05:37:42 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 23:11:01 -0500 From: Suresh Krishnan To: Tim Chown , Bob Hinden Subject: Re: REMINDER: 6man w.g. last call for Thread-Topic: REMINDER: 6man w.g. last call for Thread-Index: AQHSW50X2LnjnTgUGkSWKZE0Ax0x4g== Date: Fri, 6 Jan 2017 04:11:01 +0000 Message-ID: References: <3B76B8CC-8F1F-4FF0-ADAB-656B1819B453@jisc.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPgq6YfH6Ewe3zchZb3+9js3h59j2T Rd/Px2wOzB47Z91l91iy5CeTx8rfV9gCmKO4bFJSczLLUov07RK4Mg49f8tacIytYnb3e8YG xkWsXYwcHBICJhI3Xwp0MXJxCAmsZ5RoWbqbFcJZxihxZeNPIIeTgw2oaMPOz0wgtoiAu8S0 K7+ZQJqZBWQlrk2KBAkLC3hK/F+5gxWixEti2uHPULaexNdVs9lBbBYBFYlvqy8ygti8Ar4S F5beYQGxhQQWM0os7osDsRkFxCS+n1oDtopZQFzi1pP5YLaEgIDEkj3nmSFsUYmXj/+xQthK Eh9/z2eHqDeQeH9uPjOErS2xbOFrZohdghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRo7S 4oKc3HQjg02MwDg4JsGmu4Px/nTPQ4wCHIxKPLwF8XkRQqyJZcWVuYcYJTiYlUR49UXyI4R4 UxIrq1KL8uOLSnNSiw8xSnOwKInzxq2+Hy4kkJ5YkpqdmlqQWgSTZeLglGpgVC8/c7JX3z10 O+svsXtnCi30rjOee391pfmrmfPZSg69/jTbhvHTB9lrb5uqBE9KLJd971X/t/1grNiNLK7n 61cs3D+5Izbk2eusiYe/vYg6XnG1KHOnuATnyvcHk4sfuPWV+Dy4EX75seqGhczb4m0t85KM mQXYLTIT9tyw+vZYfUH+iqUXupVYijMSDbWYi4oTAQJY+Xx/AgAA Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 04:11:07 -0000 Hi Tim,=0A= =0A= On 01/05/2017 06:54 AM, Tim Chown wrote:=0A= > Hi,=0A= >=0A= > Just a brief comment on the Security Considerations.=0A= >=0A= > This draft could mention RFC6105; currently it only says that rogue RAs c= an =93easily=94 be prevented through use of SeND, but in practice RA Guard = approaches are the common mitigation. I=92m also not sure the =93attack wi= ndow=94 changes; there is either a rogue RA or there isn=92t, regardless of= the true RA interval.=0A= =0A= Adding a reference to RA guard sounds like a good idea. Will do. The attack= =0A= window is larger because the damage from the rogue RA can persist longer = =0A= before getting overridden by a legitimate RA. I don't have strong feelings = =0A= about keeping the "attack window" wording though.=0A= =0A= Thanks=0A= Suresh=0A= =0A= From nobody Thu Jan 5 21:06: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 2E41F1298C1 for ; Thu, 5 Jan 2017 21:06:38 -0800 (PST) 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 AM8ScM7SH3U4 for ; Thu, 5 Jan 2017 21:06:36 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB021298A8 for ; Thu, 5 Jan 2017 21:06:35 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D5D8483770; Fri, 6 Jan 2017 06:06:18 +0100 (CET) Subject: Re: REMINDER: 6man w.g. last call for To: Suresh Krishnan , Tim Chown , Bob Hinden References: <3B76B8CC-8F1F-4FF0-ADAB-656B1819B453@jisc.ac.uk> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 6 Jan 2017 01:23:26 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 05:06:38 -0000 On 01/06/2017 01:11 AM, Suresh Krishnan wrote: > Hi Tim, > > On 01/05/2017 06:54 AM, Tim Chown wrote: >> Hi, >> >> Just a brief comment on the Security Considerations. >> >> This draft could mention RFC6105; currently it only says that rogue RAs can easily be prevented through use of SeND, but in practice RA Guard approaches are the common mitigation. Im also not sure the attack window changes; there is either a rogue RA or there isnt, regardless of the true RA interval. > > Adding a reference to RA guard sounds like a good idea. Will do. The attack > window is larger because the damage from the rogue RA can persist longer > before getting overridden by a legitimate RA. I don't have strong feelings > about keeping the "attack window" wording though. My interpretation of "attack window" is along the lines of "amount of time the attacker has to do his thing". In this respect the attack window does not change. What changes is the persistence of the effects of the attack (for *some* RA-based attacks). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 6 06:42:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365421294FF for ; Fri, 6 Jan 2017 06:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 6C_yB-q-bgsA for ; Fri, 6 Jan 2017 06:42:06 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 127AA1294EB for ; Fri, 6 Jan 2017 06:42:06 -0800 (PST) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 939C67400E4; Fri, 6 Jan 2017 14:42:05 +0000 (UTC) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.235.68]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0319.002; Fri, 6 Jan 2017 06:42:06 -0800 From: Bob Halley To: "ipv6@ietf.org" Subject: Review of draft-ietf-6man-rfc2460bis-08 Thread-Topic: Review of draft-ietf-6man-rfc2460bis-08 Thread-Index: AQHSaCsM6hSAZnz6NUub58Bqk44k7Q== Date: Fri, 6 Jan 2017 14:42:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170104 x-originating-ip: [64.89.232.234] Content-Type: text/plain; charset="utf-8" Content-ID: <6147CACCC89BAA44B3D62C5E795CF325@nominum.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "bob.hinden@gmail.com" , "suresh.krishnan@ericsson.com" , "terry.manderson@icann.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 14:42:07 -0000 SSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIGRyYWZ0LWlldGYt Nm1hbi1yZmMyNDYwYmlzLTA4LiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLiBEb2N1bWVu dCBlZGl0b3JzIGFuZCBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVz dCBsaWtlIHRoZXkgd291bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250 cmlidXRvcnMgYW5kIHJlc29sdmUgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFpbHMgb24gdGhl IElOVCBEaXJlY3RvcmF0ZSwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0 ZS5odG1sLg0KDQpJIHJldmlld2VkIHRoZSBkcmFmdCwgaW5jbHVkaW5nIGEgZGV0YWlsZWQgY29t cGFyaXNvbiB3aXRoIFJGQyAyNDYwLiAgSSBmb3VuZCBubyBpc3N1ZXMgd2l0aCB0aGUgZHJhZnQs IGFuZCBJIHRoaW5rIGl04oCZcyBhbiBleGNlbGxlbnQgdXBkYXRlIHRvIHRoZSBvcmlnaW5hbC4N Cg0KL0JvYg0KDQoNCg== From nobody Fri Jan 6 13:03: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 3A065129EDC; Fri, 6 Jan 2017 13:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w36OAc41Xv-8; Fri, 6 Jan 2017 13:03:41 -0800 (PST) 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 97E66129EE8; Fri, 6 Jan 2017 13:03:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 909D0B80103; Fri, 6 Jan 2017 13:03:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 8021 on Generation of IPv6 Atomic Fragments Considered Harmful X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170106210341.909D0B80103@rfc-editor.org> Date: Fri, 6 Jan 2017 13:03:41 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:03:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8021 Title: Generation of IPv6 Atomic Fragments Considered Harmful Author: F. Gont, W. Liu, T. Anderson Status: Informational Stream: IETF Date: January 2017 Mailbox: fgont@si6networks.com, liushucheng@huawei.com, tore@redpill-linpro.com Pages: 12 Characters: 25686 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-deprecate-atomfrag-generation-08.txt URL: https://www.rfc-editor.org/info/rfc8021 DOI: 10.17487/RFC8021 This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460). This document is a product of the IPv6 Maintenance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From crawdad@fnal.gov Fri Jan 6 14:38: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 D4FE91295FB for ; Fri, 6 Jan 2017 14:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fermicloud.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 hKXFFFgZo7Ut for ; Fri, 6 Jan 2017 14:38:32 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0098.outbound.protection.outlook.com [23.103.200.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0341295DB for ; Fri, 6 Jan 2017 14:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fermicloud.onmicrosoft.com; s=selector1-fnal-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8/PK86rR+Qqke4tsAknpzfTFrYGZdcGBeZ0F4NCTYVc=; b=Qa5bL5UCe8d56sVYfBW+uiH10LJaRnZyTRL49I730t7lDTBHJHKzLsog0UxtNGzK3Z73oZnHpAtCVYkvr+wAlig9feXFQTgiyFDvV13tDuVDMEGu+FYA4nwgFbVeZ4F5+TKew99N64GGTes94lX1Lpiww45mmM3Q7wA+w7LJ9X8= Received: from DM2PR09MB0269.namprd09.prod.outlook.com (10.160.93.155) by DM2PR09MB0272.namprd09.prod.outlook.com (10.160.96.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.817.10; Fri, 6 Jan 2017 22:38:30 +0000 Received: from DM2PR09MB0269.namprd09.prod.outlook.com ([10.160.93.155]) by DM2PR09MB0269.namprd09.prod.outlook.com ([10.160.93.155]) with mapi id 15.01.0817.009; Fri, 6 Jan 2017 22:38:30 +0000 From: Matt Crawford To: "ipv6@ietf.org" Subject: Re: Thread-Topic: Thread-Index: AQHSaG2a0Xi96x/9SkKCXmp4d/PIjA== Date: Fri, 6 Jan 2017 22:38:29 +0000 Message-ID: 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=crawdad@fnal.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2620:6a:0:87:202c:55a0:dcc3:6527] x-ms-office365-filtering-correlation-id: c50d3a12-efc4-45f9-f69e-08d43684bcfd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0272; x-microsoft-exchange-diagnostics: 1; DM2PR09MB0272; 7:O5FtrNSmkAQwaYD4XtTdJ1m0csKXg96REgltty1MU92yiEr/YXBQC/m+hGlQ0zRp1bDqUdbVGuXWmu9+Xdg63YZ/ArZEXwAHa5DEMLyy50ZJJUNCD7q13mEiq2UC+HeZNl/Jjiyi+uPzg911kVO7f/9OrgILuRaQ8Mnpsps6GRxU9fJ9Sqy3FzZtESfXmXalTQD4zFS59crfXhPTFt9UbAPkl9lMDgJzvBaiJcySIpRnPfoLEfktxE2Iu89gIttfogTXyp1sXbQuBWkX5DbJKPwkRbyf8h3xQjABy4RkDLVXCXZT/N3uD+dBbrCyCxgEKWf7lTxV/yaS2xlT6jtPRkWTQdhPRJGV+8DK6mJJU/S+9r8cULNESFtgK9a7IT4ExUZ6+ss9zOIysf2LI/sU2RaHhPzznvQA1vPggSGNSDZDCes20OZJdQlZwCiGPZfJjEXib1zR0nqs97RrfGjQsA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(243157700288050)(40475595445134); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR09MB0272; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0272; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(199003)(189002)(83716003)(2501003)(81156014)(81166006)(8676002)(6306002)(36756003)(82746002)(6506006)(2906002)(8936002)(229853002)(92566002)(33656002)(6486002)(77096006)(68736007)(99286003)(86362001)(105586002)(107886002)(5660300001)(106356001)(2900100001)(5640700003)(38730400001)(450100001)(106116001)(305945005)(7736002)(2351001)(122556002)(110136003)(6916009)(230783001)(50986999)(101416001)(97736004)(3660700001)(54356999)(25786008)(189998001)(6436002)(3280700002)(6512007)(6116002)(102836003)(104396002)(18886065003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0272; H:DM2PR09MB0269.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fnal.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <08A7DC3B7881DF489CDA511AFC043A4F@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fnal.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 22:38:29.7373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d5f83d3-d338-4fd3-b1c9-b7d94d70255a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0272 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 22:41:36 -0000 PiBJIGNyZWF0ZWQgYSBiYXNlbGluZSBkcmFmdCBmb3IgZG9pbmcgYW4gUkZDMjQ2NGJpcyBmb3Ig SW50ZXJuZXQgU3RhbmRhcmQuICBUaGlzIHNlZW0gdG8gbWUgbGlrZSBhIGdvb2Qgb25lIHRvIHN0 YXJ0IHdvcmtpbmcgb24gc2luY2UgdGhlIG90aGVyIGNvcmUgSVB2NiBkcmFmdHMgaGF2ZSBiZWVu IHN1Ym1pdHRlZCB0byB0aGUgSUVTRy4NCj4gW+KApl0gDQo+IA0KPiBUaGUgcGxhbiBpcyB0byBk byBhIHNtYWxsIHNlcmllcyBvZiBuZXcgdmVyc2lvbnMsIGVhY2ggYWRkcmVzc2luZyBhIHNpbmds ZSB1cGRhdGUgdG8gYWxsb3cgdGhlIGNoYW5nZXMgdG8gYmUgdHJhY2tlZCB2ZXJ5IGNhcmVmdWxs eS4gUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHZlcmlmeSB0aGVyZSBhcmUgbm8gY29udGVu dCBjaGFuZ2VzLg0KDQpJIGhhdmUgY2FyZWZ1bGx5IGNvbXBhcmVkIHlvdXIgLTAwIGRyYWZ0IHRv IFJGQyAyNDY0IGFuZCBmaW5kIG5vIHN1YnN0YW50aXZlIGRpZmZlcmVuY2VzIGV4Y2VwdCB0aGUg YWRkaXRpb24gb2YgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbmQgdXBkYXRpbmcg c29tZSBvZiB0aGUgcmVmZXJlbmNlcy4NCg0KDQpNYXR0IENyYXdmb3JkIA0KUHJvamVjdCBNYW5h Z2VyDQoNCk9mZmljZSBvZiB0aGUgQ0lPDQpGZXJtaSBOYXRpb25hbCBBY2NlbGVyYXRvciBMYWJv cmF0b3J5DQpodHRwOi8vd3d3LmZuYWwuZ292Lw0KDQo= From nobody Sat Jan 7 21:30: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 9F0101294A9 for ; Sat, 7 Jan 2017 21:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXOfDujvRRfi for ; Sat, 7 Jan 2017 21:30:35 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 7022E129415 for ; Sat, 7 Jan 2017 21:30:35 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id y9so108539493uae.2 for ; Sat, 07 Jan 2017 21:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+Yh8UHvZ7KriKyHcmjb9R1ZS7dayCozEV7/EBo91U+Y=; b=E4UPvIMEZ6c4c2/kZTdegkp1u1wHShXGH+XZV03ae9fLDcf6quc50c7JsMfPnf8XrQ Km7Vz48NP2T7uvSs2/RtjhVd+QrB94x/RQ4zIYZtmQcdbKBzlHswxypQQue4OsCzeaJr 1yKqDprl5YjiBw2dLFeaSMNDv5c9D9DeIOjdIqm6OKFVeZGQ7eFgtyv22eBoJY/nZIkZ a6zGLzbHXhtSwrfKoVF6V5R8vfrBFyU1eK8nyXc/RgC/Fx1Yovut+oNncJIAHjfK4FCc DN2qqRQBhl7fnnONgR/qT5GxKrKzmu9F+3uogOfYlp3jAJL1cyZSqvGQOKkGPWYCsSxg AXdQ== 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=+Yh8UHvZ7KriKyHcmjb9R1ZS7dayCozEV7/EBo91U+Y=; b=QVQRt/X+R6gZ7blG8PjkKwE73N7Qoz9rXi2zg7wJezmDLJCb4L5LSzfq7GcKklR2bu igS6sbM1tiOlI+DU0V4acH8m0Ej9px9Kjke4TKaZK/jDuFK1rKw+sH6n+P8YrQjomg51 kvhAmXDU3CwUpWeM9SucqXvGeNIFzsWuSQO0V9bfVsLY+gXJVB8IT4aJCbARwDkwenQK oZ35EwKucqJQU+zpBH/pVIsbjcgnBtNGccels8dY+evy2WUP3jQiQi47jzcKDfLUYPgL kPXFkRSouFaGHzAFrCpTY0PnfYMK7Q1NgEjt31EoziNN/t3MuTBk8iA1xRD3Y7etF0JR HBGA== X-Gm-Message-State: AIkVDXL4WOa36aXsoFHiLCvexMVZm60BVXcnYeh+tz3mjtpPsAvzV7+nKYblIHu/BTMrRd/7ulfZjt2NLGkCWg== X-Received: by 10.159.36.73 with SMTP id 67mr14084522uaq.124.1483853434435; Sat, 07 Jan 2017 21:30:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.8.217 with HTTP; Sat, 7 Jan 2017 21:30:04 -0800 (PST) From: Mark Smith Date: Sun, 8 Jan 2017 16:30:04 +1100 Message-ID: Subject: Errata for RFC4862 To: 6man WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 05:30:36 -0000 Hi, I've struggled with the Errata tool complaining about not having line breaks at 72 characters for the last 15 or so minutes, and after making number of failed attempts to fix that, that's enough! Section: 5.5.3 RouterAdvertisement Processing Original Text: 1. If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime. 2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. 3. Otherwise, reset the valid lifetime of the corresponding address to 2 hours. Corrected Text: 1. If the Router Advertisement is not authenticated (e.g., via Secure Neighbor Discovery [RFC3971]), and if the received Valid Lifetime is greater than 2 hours, set the valid lifetime of the corresponding address to the advertised Valid Lifetime. 2. If the Router Advertisement has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]), the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option (regardless of whether it is greater than 2 hours or not). 3. Otherwise, reset the valid lifetime of the corresponding address to 2 hours. In other words, unless an RA is authenticated, Valid Lifetimes in RA PIOs MUST be greater than 2 hours. Notes: For unauthenticated RAs, throughout the text there are numerous checks to prevent a possible DoS attack described in the subsequent paragraph: "The above rules address a specific denial-of-service attack in which a bogus advertisement could contain prefixes with very small Valid Lifetimes." Check 1 above would seem to allow a Valid Lifetime in an RA PIO that is much less than 2 hours, as long as the value is greater than the RemainingLifetime. For example, if a host's RemainingLifetime for an address is 60 seconds, an RA PIO ValidLifetime of 61 seconds would be acceptable. This would seem to contradict the DoS protection goal. Check 2 does check to ensure that RemainingLifetime is greater than 2 hours, however Check 1 has already accepted the RA PIO VL <2 hours (if greater than RemainingLifetime) and set the address's Valid Lifetime to a value possibly much less than 2 hours. An attacker could take advantage of this by doing the following: 1. Send an initial RA with a ValidLifetime of 2 hours, which would pass Check 1. 2. Wait until around 1 hour and 59.5 minutes, and then send an RA with a ValidLifetime of 61 seconds. 3. Send RAs every 30 or so seconds with a ValidLifetime of 61 seconds, holding all of the victim hosts' ValidLifetimes at a low value. These RAs would also pass Check 1 as long as the VL in the RA was greater than the hosts' current VL for the addresses. 4. When it could cause the most significant denial of service, stop sending the RAs, causing the hosts' address VLs and therefore the addresses to expire within 60 seconds or so. Regards, Mark. From nobody Mon Jan 9 00:53: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 065B8129BDE for ; Mon, 9 Jan 2017 00:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAcGc7Lwv8jh for ; Mon, 9 Jan 2017 00:53:31 -0800 (PST) Received: from inbound03.kjsl.com (inbound03.kjsl.com [IPv6:2001:1868:a100:131::62]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0728129BDD for ; Mon, 9 Jan 2017 00:53:31 -0800 (PST) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport03.kjsl.com with ESMTP; 09 Jan 2017 08:53:19 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 94D159CC80; Mon, 9 Jan 2017 00:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=acPVI0IHLq9CY9Uq1m2zva5ub0w=; b=o2mCCtz/ZIMx6w9981 pLlJKobs+W2j7roaVljQo0LE9jz7IVCu2L6v2eBxlpwCl+H5IAuHPsbsK15hMaOC MP5z+IQ/JFSxbJL6buaTz5snjCDYdxfgAySYExZ+TLTSZj5jAHArn3aEyd/ommxt SGRfogOmNjk8bexeWSFxRo7TA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Leiw5mPf/t1MHpTJqRxCnS4JGNqzhWL5GFCKTyBNQhRH5GFJsWa 3YbRJ/OwSYRb/m6MOeBI0QcWQSQAWYRl9JVSk1nr1EzVii4qsVD6Ugh33foYhm7a L2bc8PBnM9NAystiE7/BAIpFrapYF9y/IkLHlFdGy005Zkh5uXjhkq4Y= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 104039CC7E; Mon, 9 Jan 2017 00:53:10 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8B3E6725431C; Mon, 9 Jan 2017 09:53:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Errata for RFC4862 From: otroan@employees.org In-Reply-To: Date: Mon, 9 Jan 2017 09:53:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 08:53:33 -0000 Mark, The current text is crafted both to allow renumbering and to support = scenarios where the RA lifetimes are short. I.e. under two hours. Your proposed changes appear to lock the lifetimes to no less than two = hours. Is that correctly understood? Btw, this might not be appropriate for an erratum, but I do also think = we should revisit this behaviour. For the IPv6 core specifications to = Internet standards work, I think the tentative conclusion was that we = needed to do 4861/4862bis documents in-place before considering an = advancement. O. > On 8 Jan 2017, at 06:30, Mark Smith wrote: >=20 > Hi, >=20 > I've struggled with the Errata tool complaining about not having line > breaks at 72 characters for the last 15 or so minutes, and after > making number of failed attempts to fix that, that's enough! >=20 > Section: >=20 > 5.5.3 RouterAdvertisement Processing >=20 >=20 > Original Text: >=20 > 1. If the received Valid Lifetime is greater than 2 hours or > greater than RemainingLifetime, set the valid lifetime of the > corresponding address to the advertised Valid Lifetime. >=20 > 2. If RemainingLifetime is less than or equal to 2 hours, ignore > the Prefix Information option with regards to the valid > lifetime, unless the Router Advertisement from which this > option was obtained has been authenticated (e.g., via Secure > Neighbor Discovery [RFC3971]). If the Router Advertisement > was authenticated, the valid lifetime of the corresponding > address should be set to the Valid Lifetime in the received > option. >=20 > 3. Otherwise, reset the valid lifetime of the corresponding > address to 2 hours. >=20 >=20 > Corrected Text: >=20 > 1. If the Router Advertisement is not authenticated (e.g., via Secure > Neighbor Discovery [RFC3971]), and if the received Valid Lifetime is = greater > than 2 hours, set the valid lifetime of the corresponding address to = the > advertised Valid Lifetime. >=20 > 2. If the Router Advertisement has been authenticated (e.g., via = Secure > Neighbor Discovery [RFC3971]), the valid lifetime of the corresponding > address should be set to the Valid Lifetime in the received option > (regardless of whether it is greater than 2 hours or not). >=20 > 3. Otherwise, reset the valid lifetime of the corresponding address = to 2 > hours. >=20 > In other words, unless an RA is authenticated, Valid Lifetimes in RA = PIOs > MUST be greater than 2 hours. >=20 >=20 > Notes: >=20 > For unauthenticated RAs, throughout the text there are numerous checks > to prevent a possible DoS attack described in the subsequent > paragraph: >=20 > "The above rules address a specific denial-of-service attack in > which a bogus advertisement could contain prefixes with very = small > Valid Lifetimes." >=20 > Check 1 above would seem to allow a Valid Lifetime in an RA PIO that > is much less than 2 hours, as long as the value is greater than the > RemainingLifetime. For example, if a host's RemainingLifetime for an > address is 60 seconds, an RA PIO ValidLifetime of 61 seconds would be > acceptable. This would seem to contradict the DoS protection goal. >=20 > Check 2 does check to ensure that RemainingLifetime is greater than 2 > hours, however Check 1 has > already accepted the RA PIO VL <2 hours (if greater than > RemainingLifetime) and set the address's Valid > Lifetime to a value possibly much less than 2 hours. >=20 > An attacker could take advantage of this by doing the following: >=20 > 1. Send an initial RA with a ValidLifetime of 2 hours, which would = pass Check 1. > 2. Wait until around 1 hour and 59.5 minutes, and then send an RA with > a ValidLifetime of 61 seconds. > 3. Send RAs every 30 or so seconds with a ValidLifetime of 61 seconds, > holding all of the victim hosts' > ValidLifetimes at a low value. These RAs would also pass Check 1 as > long as the VL in the RA was > greater than the hosts' current VL for the addresses. > 4. When it could cause the most significant denial of service, stop > sending the RAs, causing the hosts' > address VLs and therefore the addresses to expire within 60 seconds or = so. >=20 >=20 > Regards, > Mark. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Jan 9 03:37: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 99D7E129443 for ; Mon, 9 Jan 2017 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 bWoMVdJ-Uahm for ; Mon, 9 Jan 2017 03:37:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF13B12940D for ; Mon, 9 Jan 2017 03:37:18 -0800 (PST) Received: from [192.168.4.9] (unknown [179.40.138.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6446C836F7; Mon, 9 Jan 2017 12:37:11 +0100 (CET) Subject: Re: Errata for RFC4862 To: otroan@employees.org, Mark Smith References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7294d455-f526-6832-be62-b5a2d1473b7e@si6networks.com> Date: Mon, 9 Jan 2017 08:36:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 11:37:20 -0000 On 01/09/2017 05:53 AM, otroan@employees.org wrote: > > The current text is crafted both to allow renumbering and to support > scenarios where the RA lifetimes are short. I.e. under two hours. > Your proposed changes appear to lock the lifetimes to no less than > two hours. Is that correctly understood? > > Btw, this might not be appropriate for an erratum, but I do also > think we should revisit this behaviour. +1. Note, however, that there are other values to be sanity-checked in a similar way. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 9 04:52: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 5AF2B129C7A for ; Mon, 9 Jan 2017 04:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sx-XtXXOAuK for ; Mon, 9 Jan 2017 04:52:18 -0800 (PST) Received: from inbound03.kjsl.com (inbound03.kjsl.com [IPv6:2001:1868:a100:131::62]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844A4129C5C for ; Mon, 9 Jan 2017 04:52:18 -0800 (PST) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport03.kjsl.com with ESMTP; 09 Jan 2017 12:51:57 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BFAB29CC81; Mon, 9 Jan 2017 04:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=gi9XshheLmuzEU5CXvr2I8i+5pk=; b=p6Fit06keINPLEjNC9 SNAZrsqIzGqMMLK6Ydju24dABAN+3MPHxIINtE30dS1EvcUfaecbqWPpxcxhGsyO nLugVeTu1TC772iI5WzuBncfguT3WAv3ECDoCj3dlumwqdzhocT3T6YYDGNIGaUE /9SoTcQyRbEjb9kyKO7xfwEso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=K0ZTXYX+eM65VpeVeKdsrQuNaU8La43W6TqKWtVOuWCzYinSdFs mQUctvv33g37H/NlPTQizRZelzBIVir8LAYsJU9+UjvSPjChCia2YZ/ieBDsfow9 YzHPzQbsrgofi91Mi+L3kucxx9h0y7adopxO1GgfsdN/ZSUJD/o9cIx4= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8B8E79CC80; Mon, 9 Jan 2017 04:51:56 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D926D7287CE1; Mon, 9 Jan 2017 13:51:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Errata for RFC4862 From: otroan@employees.org In-Reply-To: <7294d455-f526-6832-be62-b5a2d1473b7e@si6networks.com> Date: Mon, 9 Jan 2017 13:51:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7294d455-f526-6832-be62-b5a2d1473b7e@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:52:19 -0000 Fernando, >> The current text is crafted both to allow renumbering and to support >> scenarios where the RA lifetimes are short. I.e. under two hours.=20 >> Your proposed changes appear to lock the lifetimes to no less than >> two hours. Is that correctly understood? >>=20 >> Btw, this might not be appropriate for an erratum, but I do also >> think we should revisit this behaviour.=20 >=20 > +1. >=20 > Note, however, that there are other values to be sanity-checked in a > similar way. Quite possibly. For this particular one it is arguable of its value = though. If the attacker is controlling a node on a BMA link you have a problem = regardless. O. From nobody Mon Jan 9 07:51:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230B3129652 for ; Mon, 9 Jan 2017 07:51:38 -0800 (PST) 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 bL98BAsuj9NR for ; Mon, 9 Jan 2017 07:51:36 -0800 (PST) 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 6B04312964B for ; Mon, 9 Jan 2017 07:51:20 -0800 (PST) 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 v09FpJc5059176; Mon, 9 Jan 2017 08:51:19 -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 v09FpCFM059053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 9 Jan 2017 08:51:12 -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.1178.4; Mon, 9 Jan 2017 07:51:11 -0800 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.1178.000; Mon, 9 Jan 2017 07:51:11 -0800 From: "Templin, Fred L" To: 6man WG Subject: Route Information Options in Redirect Messages Thread-Topic: Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETog== Date: Mon, 9 Jan 2017 15:51:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:51:38 -0000 See below for a new draft that proposes to update RFC4861 and RFC4191 to permit the inclusion of Route Information Options in Redirect Messages. This represents a backward-compatible extension to the IPv6 ND Redirect function. Please review and comment on the list. Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, January 06, 2017 1:52 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Route Information Options in Redirect Messages Author : Fred L. Templin Filename : draft-templin-intarea-rio-redirect-00.txt Pages : 5 Date : 2017-01-06 Abstract: The IPv6 Neighbor Discovery protocol provides a Redirect function allowing routers to inform hosts of a better next hop on the link toward the destination. This document specifies a backward- compatible extension to the Redirect function to allow routers to include forwarding information that the source can associate with the next hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-intarea-rio-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-templin-intarea-rio-redirect-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jan 9 09:33:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932B6129562; Mon, 9 Jan 2017 09:33:15 -0800 (PST) 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 hK6MgTcjsglu; Mon, 9 Jan 2017 09:33:14 -0800 (PST) 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 09E4812955B; Mon, 9 Jan 2017 09:33:14 -0800 (PST) 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 v09HXDW4043603; Mon, 9 Jan 2017 10:33:13 -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 v09HXBuH043576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2017 10:33:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 9 Jan 2017 09:33:10 -0800 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.1178.000; Mon, 9 Jan 2017 09:33:10 -0800 From: "Templin, Fred L" To: "int-area@ietf.org" , 6man WG Subject: FW: Route Information Options in Redirect Messages Thread-Topic: Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogADoL4g Date: Mon, 9 Jan 2017 17:33:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:33:15 -0000 Cross-posting onto "int-area" where discussions motivated this work. -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Monday, January 09, 2017 7:51 AM To: 6man WG Subject: Route Information Options in Redirect Messages See below for a new draft that proposes to update RFC4861 and RFC4191 to permit the inclusion of Route Information Options in Redirect Messages. This represents a backward-compatible extension to the IPv6 ND Redirect function. Please review and comment on the list. Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, January 06, 2017 1:52 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Route Information Options in Redirect Messages Author : Fred L. Templin Filename : draft-templin-intarea-rio-redirect-00.txt Pages : 5 Date : 2017-01-06 Abstract: The IPv6 Neighbor Discovery protocol provides a Redirect function allowing routers to inform hosts of a better next hop on the link toward the destination. This document specifies a backward- compatible extension to the Redirect function to allow routers to include forwarding information that the source can associate with the next hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-intarea-rio-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-templin-intarea-rio-redirect-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Mon Jan 9 09:39: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 4EC97129443 for ; Mon, 9 Jan 2017 09:39:13 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 z16f236s9f42 for ; Mon, 9 Jan 2017 09:39:12 -0800 (PST) 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 C4FB7129445 for ; Mon, 9 Jan 2017 09:39:11 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id l7so93490990qtd.1 for ; Mon, 09 Jan 2017 09:39:11 -0800 (PST) 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=1bKrcSyrLDBZLPVp2p2g92ocRfJDH2snixqvn6Laxnw=; b=lTFTlJwDcaiY0RxxRKBUr5mzsjkhRsggm1X3vkg8DBXHUF7Z7qC3T5WMenbBtugJQv BXVte6A9eM0u4REILUMZ2yenZectwA+NCWSCEkWbHoV5pc2aitnnNNVu8E7DLXWJIhzK Skzh94oTgKpKnatbFUsYVS1vjalrT9/oDFM8Y73huL89puEomitY+2T7ecKq1K9WK5hH ojVu/Os8oIp2oZk8WUMSU2y+ixcf1FeycKt+A3Kr3lOgqw/s7/yQXszdrNmDM5/5Zxg0 ihO2+8p0lcCdFX6Z3C+Tqsakaa+H7SLZj67lV25kWbEnwwh0B9mFEiEI1NuPgAw914Nt fbjw== 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=1bKrcSyrLDBZLPVp2p2g92ocRfJDH2snixqvn6Laxnw=; b=IT5sdiP34bF+GB8c7scP3a26/F+T8yxHHSX7z3awmMUuzFXkr6I9x0eO4a5GIGbwHl GW7BkoRjUfMjCz10DfMD1V3J3j4b9WAjBJQhYc2rLEJyAwRvKMayQ9qjAaVS/fcuu0bx LdLELp/URWVjSMjB6wpPNJ/UJOIiJcf0C25LJyqKSeHbbWdtwGf5/hUYfRCWOMSievXX TE5Cuyt2kyzwNjptC0Jzc642R3/P3FcjRM9SqE0XsBvdMVe6NYSfmaAW9ZHUe5+1SkmV Ap/lIMYXIQMpxYoWBM+hLVm7iRCH81dDVlki+eEUE4oIcGZJyxpbPxgN+Kqsquc2zyYF nnyw== X-Gm-Message-State: AIkVDXIv6jCGs9yGeXhVpvwKQRpNBKhBkiLEdmUbgm4srqh58EU7hSL5DZ1BkC/t55SeXm2qNZFxW72xJ5d0dA== X-Received: by 10.200.42.93 with SMTP id l29mr94710662qtl.289.1483983550822; Mon, 09 Jan 2017 09:39:10 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 9 Jan 2017 09:39:10 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 9 Jan 2017 09:39:10 -0800 X-Google-Sender-Auth: DGcEHk_cyKF6-vEk9c3eRUbfVls Message-ID: Subject: Re: Errata for RFC4862 To: Mark Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:39:13 -0000 At Sun, 8 Jan 2017 16:30:04 +1100, Mark Smith wrote: > An attacker could take advantage of this by doing the following: > > 1. Send an initial RA with a ValidLifetime of 2 hours, which would pass Check 1. > 2. Wait until around 1 hour and 59.5 minutes, and then send an RA with > a ValidLifetime of 61 seconds. I guess the unstated assumption behind this defense of RFC4862 is that at least some legitimate RA containing a PIO with a sufficiently long valid lifetime updates the lifetime during this 1-hour-and-59.5-minute period. Of course, we cannot always assume this, but as I believe everyone understands, this defense is supposed to be quite basic and weak anyway, and does not intend to prevent all kinds of DoS attempt by most sophisticated attackers under all possible circumstances. In that sense the current text of RFC4862 actually does what it intended to do with originally perceived limitations, so I don't see the need for the proposed update. At the very least I don't think this is an editorial error. If we now agree that the currently described defense is too weak, it should be addressed as a protocol update to the RFC. -- JINMEI, Tatuya From nobody Mon Jan 9 11:02: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 B8CED129859 for ; Mon, 9 Jan 2017 11:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S3aIPDwf5Aw for ; Mon, 9 Jan 2017 11:02:13 -0800 (PST) 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 69ABB129860 for ; Mon, 9 Jan 2017 11:02:13 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id f188so277137022pgc.3 for ; Mon, 09 Jan 2017 11:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ceXtHf+1btoHHPvjhE4NNpfDRtidolNf7OcA8+i0Tn4=; b=VX6/SLELaksQ5Ut0+sAk5QBVJgRYbKrUk6xIgtwNVLAjZW2p5jsGZ5exiQ2z5mR/M+ zA6SsKtMLhzlL/u8xiIRZKNcHgomH7viviqPStJu/KU3qzKviltSqoayuopJhuJUmnK4 g5CJdK8hGrd8e+u+ML4EUupJebdHj3I9vO/++dwYYxMMP+/zSCyk5G5BRr4YhNRVZ976 j1Cm6Zii8q7OfiHgUTqtzPDni8rs8RAPuvfMWF5fGeEAVr05No3ZgbRww7tl/sRvgrTG uLGu0CjeXl7jBqGyldpCJP0P6FbTdEOrzDBl0l3P/lR/6V6xAfPqbpfyycy77aeAJxzr vHbQ== 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 :content-transfer-encoding:message-id:references:to; bh=ceXtHf+1btoHHPvjhE4NNpfDRtidolNf7OcA8+i0Tn4=; b=HusBltF/C5FSiYTGVFmNoOap2PGyOh5DIT3niQIZ8XUjGwOCD9MnSu3XHha4M6YRN+ POj+5xw6WxBLfeF3Fvr82nGybjBQEc+0OXvEJGS2uhVJCMUGGIf1Anc8Bxpd33IRNPHq eXDujmyQtFrLex+o/cinzSzrnhq1uOAzdXrkxnfgvkCDo8Zrtq9trY4xf5qCF3OxF+MR UJjf25EuaWIlvnUhxAL8k4boTYNxMWDf50TaiGUWLGsei37IW0vy2isUJ+dj7bHfS2rH 0MASJn73Vj1MaH1VRuVb1ElUDkXCfbher8dGYP12WanUvan/GzjZA802FwaGeoQFsv2V XN5Q== X-Gm-Message-State: AIkVDXLBQIFAxF8NhI10WODHcil4rrKXdltA7hwAnGemuut2Hz0uPdND/DdDR+AVGt1IrIgm X-Received: by 10.98.149.93 with SMTP id p90mr9337232pfd.72.1483988532636; Mon, 09 Jan 2017 11:02:12 -0800 (PST) Received: from ?IPv6:2620::10e7:10:4039:b03a:e0a4:1f2e? ([2620:0:10e7:10:4039:b03a:e0a4:1f2e]) by smtp.gmail.com with ESMTPSA id k78sm15345154pfb.93.2017.01.09.11.02.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 11:02:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Route Information Options in Redirect Messages From: james woodyatt In-Reply-To: Date: Mon, 9 Jan 2017 11:02:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: 6man WG , INT Area X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:02:14 -0000 On Jan 9, 2017, at 07:51, Templin, Fred L = wrote: >=20 > See below for a new draft that proposes to update RFC4861 and RFC4191 = to > permit the inclusion of Route Information Options in Redirect = Messages. > This represents a backward-compatible extension to the IPv6 ND = Redirect > function. Please review and comment on the list. >=20 > p1. I=E2=80=99m interested to see what V6OPS will think of this. p2. Section 3.3, Host Specification says this: >> In light of these considerations, a "Type C" host that receives a >> Redirect message containing RIOs adopts the combined behaviors of >> both of these specifications. Namely, the host updates its = neighbor >> cache entry for the Target and updates its routing table per the >> included RIOs. If the Destination address is not the unspecified >> address, the host further updates its destination cache. >>=20 >> Note that "Type A'" and "Type B" hosts ignore any RIOs and process >> the Redirect message according to Section 8.3 of [RFC4861]. And I wonder if you have considered the possibility of a =E2=80=9CType = D=E2=80=9D host, which in my conception would be capable of *only* = processing RIO options that appear in ND Redirect messages and *not* in = RA messages. I=E2=80=99m not sure that=E2=80=99s a type of host we want = to encourage, but the idea of its possibility was one of the first = things that sprang to mind when I contemplated the reasons why so few = Type C hosts are currently deployed in the wild after more than a decade = since RFC 4191 was published. --james woodyatt From nobody Mon Jan 9 11:14: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 79F7512944C for ; Mon, 9 Jan 2017 11:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49ul4By9rdAX for ; Mon, 9 Jan 2017 11:14:23 -0800 (PST) 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 1944312986C for ; Mon, 9 Jan 2017 11:14:17 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 35so36133664uak.1 for ; Mon, 09 Jan 2017 11:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7M9AWMfGojqpcoU9BiM+TIoFVIKc5NOmEcq+td3gCyc=; b=tPR2SbRrecgRnt4cvQUjkG00ALTGhjRQcWbdIDuxTGaBuHRGkB81ZMrEoE7WBihqie 7nTOuyAOz2UQh9/033fZlSZYIGUPJKFG9upfTjvkpcGWepq+gMuBsBebDBRnN0DXOeye ZVXIMKAM4YHDgV2Ht7FS76P9Y6rMmnb5Wztl9Kzo0NFC7MSsId4Bi0eoACXLG8zy9XZ6 Dgytj2Sty/YUXhjcVBD+1nSXCdUWAzfhl481l04GZ1UIrDNB2sVU/TxU0uac/kK5mhy2 /NKclQlN0Sa1kfqr3F9miuuZC2upX2yx4RLHJtPB/PY/XodEh65gt/Vy65zp0a34AQdC 7qnA== 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=7M9AWMfGojqpcoU9BiM+TIoFVIKc5NOmEcq+td3gCyc=; b=Yn2cUKpzmcbAWlZZJ7iU/0N6ZQiRNL6RLS89c/kivSOViRJf8YxrX+MfvxVRMoqX38 8dlUO06d6FoTAgQArRjUKE0vIPHUKxJZK++fuMJ3HWalD3JEuRWRkB3YULpm3merh7uR +6CxivsDlv2chNz9WDAfOtb+cmf689Xtjg2xwpBX8Ga5QGgoHFoY0PePcIcaSH/eDciS kTbx1aNU7d43Pd8E/Lxm25+qTwN6aDrdPQFtpJrVfdg/LxZugTre+h8zcJFlJwXRlfxP apdOJ2f1CALet4al7n199AoUAn8dvBAM7Su2Np5cw32HdFnQKREPrOW8xxCRMFrh/mKP TSkw== X-Gm-Message-State: AIkVDXKxXyEZc5FTPH6jY1SXnYMknnnRr2WCH4xYJNMARs5vqpDGc7aat983b6ljs412dND3+soUKvaK9/uiKw== X-Received: by 10.159.35.143 with SMTP id 15mr8499478uao.28.1483989256059; Mon, 09 Jan 2017 11:14:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Mon, 9 Jan 2017 11:13:45 -0800 (PST) In-Reply-To: References: From: Mark Smith Date: Tue, 10 Jan 2017 06:13:45 +1100 Message-ID: Subject: Re: Errata for RFC4862 To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:14:24 -0000 Hi Ole, On 9 January 2017 at 19:53, wrote: > Mark, > > The current text is crafted both to allow renumbering and to support scen= arios where the RA lifetimes are short. I.e. under two hours. Check/Rule 2 seems to be the only check/rule specifically permitting less than 2 hours, but it is only doing so if the RA is authenticated. So non-authenticated RAs with a Valid Lifetime of 2 hours should be ignored. The text seems to be stating and enforcing this 2 hour minimum a number of times: 1. If the received Valid Lifetime is greater than 2 hours, ... set the valid lifetime of the corresponding address to the advertised Valid Lifetime. 2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated ... 3. Otherwise, reset the valid lifetime of the corresponding address to 2 h= ours. Perhaps in the the first check/rule, it should have been an 'and' rather than an 'or': 1. If the received Valid Lifetime is greater than 2 hours and greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime. Flipping the perspective around, if less than 2 hour Valid Lifetimes are acceptable from non-authenticated RAs, then this set of 3 checks/rules could be much simpler and a single statement: "If the received Valid Lifetime is greater than the RemainingLifetime, reset the valid lifetime to the received Valid Lifetime." However, I don't think that would protect against the DoS described. > Your proposed changes appear to lock the lifetimes to no less than two ho= urs. Is that correctly understood? > For unauthenticated RAs, yes. That would seem to be the solution to the DoS attack mentioned. "The above rules address a specific denial-of-service attack in which a bogus advertisement could contain prefixes with very small Valid Lifetimes." where small seems to be viewed as < 2 hours by the previous check/rule text= . I've mentioned it because I believed where was a minimum VL in an RA PIO of 2 hours for unauthenticated RAs, and have recently heard of an ISP sending VLs of 1 hours. Those RAs should be failing the very first > 2 hour check (the very first part of check/rule 1), however they're not, and the receiving implementation is not using the VL correctly (so there look to be two problems). Regards, Mark. > Btw, this might not be appropriate for an erratum, but I do also think we= should revisit this behaviour. For the IPv6 core specifications to Interne= t standards work, I think the tentative conclusion was that we needed to do= 4861/4862bis documents in-place before considering an advancement. > > O. > >> On 8 Jan 2017, at 06:30, Mark Smith wrote: >> >> Hi, >> >> I've struggled with the Errata tool complaining about not having line >> breaks at 72 characters for the last 15 or so minutes, and after >> making number of failed attempts to fix that, that's enough! >> >> Section: >> >> 5.5.3 RouterAdvertisement Processing >> >> >> Original Text: >> >> 1. If the received Valid Lifetime is greater than 2 hours or >> greater than RemainingLifetime, set the valid lifetime of the >> corresponding address to the advertised Valid Lifetime. >> >> 2. If RemainingLifetime is less than or equal to 2 hours, ignore >> the Prefix Information option with regards to the valid >> lifetime, unless the Router Advertisement from which this >> option was obtained has been authenticated (e.g., via Secure >> Neighbor Discovery [RFC3971]). If the Router Advertisement >> was authenticated, the valid lifetime of the corresponding >> address should be set to the Valid Lifetime in the received >> option. >> >> 3. Otherwise, reset the valid lifetime of the corresponding >> address to 2 hours. >> >> >> Corrected Text: >> >> 1. If the Router Advertisement is not authenticated (e.g., via Secure >> Neighbor Discovery [RFC3971]), and if the received Valid Lifetime is gre= ater >> than 2 hours, set the valid lifetime of the corresponding address to the >> advertised Valid Lifetime. >> >> 2. If the Router Advertisement has been authenticated (e.g., via Secure >> Neighbor Discovery [RFC3971]), the valid lifetime of the corresponding >> address should be set to the Valid Lifetime in the received option >> (regardless of whether it is greater than 2 hours or not). >> >> 3. Otherwise, reset the valid lifetime of the corresponding address to = 2 >> hours. >> >> In other words, unless an RA is authenticated, Valid Lifetimes in RA PIO= s >> MUST be greater than 2 hours. >> >> >> Notes: >> >> For unauthenticated RAs, throughout the text there are numerous checks >> to prevent a possible DoS attack described in the subsequent >> paragraph: >> >> "The above rules address a specific denial-of-service attack in >> which a bogus advertisement could contain prefixes with very small >> Valid Lifetimes." >> >> Check 1 above would seem to allow a Valid Lifetime in an RA PIO that >> is much less than 2 hours, as long as the value is greater than the >> RemainingLifetime. For example, if a host's RemainingLifetime for an >> address is 60 seconds, an RA PIO ValidLifetime of 61 seconds would be >> acceptable. This would seem to contradict the DoS protection goal. >> >> Check 2 does check to ensure that RemainingLifetime is greater than 2 >> hours, however Check 1 has >> already accepted the RA PIO VL <2 hours (if greater than >> RemainingLifetime) and set the address's Valid >> Lifetime to a value possibly much less than 2 hours. >> >> An attacker could take advantage of this by doing the following: >> >> 1. Send an initial RA with a ValidLifetime of 2 hours, which would pass = Check 1. >> 2. Wait until around 1 hour and 59.5 minutes, and then send an RA with >> a ValidLifetime of 61 seconds. >> 3. Send RAs every 30 or so seconds with a ValidLifetime of 61 seconds, >> holding all of the victim hosts' >> ValidLifetimes at a low value. These RAs would also pass Check 1 as >> long as the VL in the RA was >> greater than the hosts' current VL for the addresses. >> 4. When it could cause the most significant denial of service, stop >> sending the RAs, causing the hosts' >> address VLs and therefore the addresses to expire within 60 seconds or s= o. >> >> >> Regards, >> Mark. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Mon Jan 9 11: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 7A602129598; Mon, 9 Jan 2017 11:53:47 -0800 (PST) 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 itZJZ_TFXwEK; Mon, 9 Jan 2017 11:53:45 -0800 (PST) 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 573E2129596; Mon, 9 Jan 2017 11:53:45 -0800 (PST) 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 v09Jrif2026873; Mon, 9 Jan 2017 12:53:45 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v09JrbP7026804 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2017 12:53:37 -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.1178.4; Mon, 9 Jan 2017 11:53:36 -0800 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.1178.000; Mon, 9 Jan 2017 11:53:36 -0800 From: "Templin, Fred L" To: james woodyatt , 6man WG , INT Area Subject: RE: [Int-area] Route Information Options in Redirect Messages Thread-Topic: [Int-area] Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAXiyiAAA9u9DA= Date: Mon, 9 Jan 2017 19:53:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 19:53:47 -0000 SGkgSmFtZXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSW50LWFy ZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgamFtZXMg d29vZHlhdHQNCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDA5LCAyMDE3IDExOjAyIEFNDQo+IFRv OiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgSU5UIEFyZWEgPGludC1hcmVhQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBSb3V0ZSBJbmZvcm1hdGlvbiBPcHRpb25zIGluIFJl ZGlyZWN0IE1lc3NhZ2VzDQo+IA0KPiBPbiBKYW4gOSwgMjAxNywgYXQgMDc6NTEsIFRlbXBsaW4s IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBTZWUg YmVsb3cgZm9yIGEgbmV3IGRyYWZ0IHRoYXQgcHJvcG9zZXMgdG8gdXBkYXRlIFJGQzQ4NjEgYW5k IFJGQzQxOTEgdG8NCj4gPiBwZXJtaXQgdGhlIGluY2x1c2lvbiBvZiBSb3V0ZSBJbmZvcm1hdGlv biBPcHRpb25zIGluIFJlZGlyZWN0IE1lc3NhZ2VzLg0KPiA+IFRoaXMgcmVwcmVzZW50cyBhIGJh Y2t3YXJkLWNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBJUHY2IE5EIFJlZGlyZWN0DQo+ID4g ZnVuY3Rpb24uIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gdGhlIGxpc3QuDQo+ID4NCj4g PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRlbXBsaW4taW50YXJlYS1yaW8t cmVkaXJlY3Q+DQo+IA0KPiBwMS4gSeKAmW0gaW50ZXJlc3RlZCB0byBzZWUgd2hhdCBWNk9QUyB3 aWxsIHRoaW5rIG9mIHRoaXMuDQoNCklmIHRoZSBjb25jZXJuIGlzIGZvciBiYWNrd2FyZHMgY29t cGF0aWJpbGl0eSB3aXRoIGxlZ2FjeSBkZXBsb3ltZW50cywgIHRoZQ0KcHJvcG9zYWwgaG9ub3Jz IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHBlciBSRkM0ODYxLiBXaGF0IGRvIHlvdSB0aGluaz8N Cg0KPiBwMi4gU2VjdGlvbiAzLjMsIEhvc3QgU3BlY2lmaWNhdGlvbiBzYXlzIHRoaXM6DQo+IA0K PiA+PiAgICBJbiBsaWdodCBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucywgYSAiVHlwZSBDIiBob3N0 IHRoYXQgcmVjZWl2ZXMgYQ0KPiA+PiAgICBSZWRpcmVjdCBtZXNzYWdlIGNvbnRhaW5pbmcgUklP cyBhZG9wdHMgdGhlIGNvbWJpbmVkIGJlaGF2aW9ycyBvZg0KPiA+PiAgICBib3RoIG9mIHRoZXNl IHNwZWNpZmljYXRpb25zLiAgTmFtZWx5LCB0aGUgaG9zdCB1cGRhdGVzIGl0cyBuZWlnaGJvcg0K PiA+PiAgICBjYWNoZSBlbnRyeSBmb3IgdGhlIFRhcmdldCBhbmQgdXBkYXRlcyBpdHMgcm91dGlu ZyB0YWJsZSBwZXIgdGhlDQo+ID4+ICAgIGluY2x1ZGVkIFJJT3MuICBJZiB0aGUgRGVzdGluYXRp b24gYWRkcmVzcyBpcyBub3QgdGhlIHVuc3BlY2lmaWVkDQo+ID4+ICAgIGFkZHJlc3MsIHRoZSBo b3N0IGZ1cnRoZXIgdXBkYXRlcyBpdHMgZGVzdGluYXRpb24gY2FjaGUuDQo+ID4+DQo+ID4+ICAg IE5vdGUgdGhhdCAiVHlwZSBBJyIgYW5kICJUeXBlIEIiIGhvc3RzIGlnbm9yZSBhbnkgUklPcyBh bmQgcHJvY2Vzcw0KPiA+PiAgICB0aGUgUmVkaXJlY3QgbWVzc2FnZSBhY2NvcmRpbmcgdG8gU2Vj dGlvbiA4LjMgb2YgW1JGQzQ4NjFdLg0KPiANCj4gQW5kIEkgd29uZGVyIGlmIHlvdSBoYXZlIGNv bnNpZGVyZWQgdGhlIHBvc3NpYmlsaXR5IG9mIGEg4oCcVHlwZSBE4oCdIGhvc3QsIHdoaWNoIGlu IG15IGNvbmNlcHRpb24gd291bGQgYmUgY2FwYWJsZSBvZiAqb25seSogcHJvY2Vzc2luZw0KPiBS SU8gb3B0aW9ucyB0aGF0IGFwcGVhciBpbiBORCBSZWRpcmVjdCBtZXNzYWdlcyBhbmQgKm5vdCog aW4gUkEgbWVzc2FnZXMuDQoNCkhhZCBub3QgY29uc2lkZXJlZCB0aGF0LCBidXQgSSBkb24ndCBz ZWUgYSBwcm9ibGVtIHdpdGggaXQuIEZXSVcsIHRoZQ0KJ1R5cGUgQS9CL0MnIGNvbWVzIGZyb20g UkZDNDE5MSBpbiBjYXNlIG90aGVycyBhcmUgd29uZGVyaW5nLg0KDQo+IEnigJltIG5vdCBzdXJl IHRoYXTigJlzIGEgdHlwZSBvZiBob3N0IHdlIHdhbnQgdG8gZW5jb3VyYWdlLA0KPiBidXQgdGhl IGlkZWEgb2YgaXRzIHBvc3NpYmlsaXR5IHdhcyBvbmUgb2YgdGhlIGZpcnN0IHRoaW5ncyB0aGF0 IHNwcmFuZyB0byBtaW5kIHdoZW4gSSBjb250ZW1wbGF0ZWQgdGhlIHJlYXNvbnMgd2h5IHNvIGZl dyBUeXBlIEMgaG9zdHMNCj4gYXJlIGN1cnJlbnRseSBkZXBsb3llZCBpbiB0aGUgd2lsZCBhZnRl ciBtb3JlIHRoYW4gYSBkZWNhZGUgc2luY2UgUkZDIDQxOTEgd2FzIHB1Ymxpc2hlZC4NCg0KSSBh bSBpbnRlcmVzdGVkIGluIHVzYWdlIGluc2lkZSBvZiBhIG1hbmFnZWQgbmV0d29yaywgYW5kIG5v dCBzbyBtdWNoIGFib3V0DQpkZXBsb3ltZW50IGluIHRoZSB3aWxkLiBJbnNpZGUgb2YgYSBtYW5h Z2VkIG5ldHdvcmssIHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3JzDQpjb3VsZCBlbmFibGUgdGhp cyBmdW5jdGlvbiBhbW9uZyB0aGUgZGVwbG95ZWQgaG9zdHMgdG8gcHJvdmlkZSB0aGUgbmV0d29y ayB3aXRoDQphIG1lYW5zIHRvIG1hbmFnZSByb3V0aW5nIGluZm9ybWF0aW9uIGZvciBtb3JlLXNw ZWNpZmljIHJvdXRlcy4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNv bQ0KDQo+IC0tamFtZXMgd29vZHlhdHQgPGpod0Bnb29nbGUuY29tPg0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJbnQtYXJl YSBtYWlsaW5nIGxpc3QNCj4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0K From nobody Mon Jan 9 12:25: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 D99EA129631 for ; Mon, 9 Jan 2017 12:25:05 -0800 (PST) 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 stOB18HCCz8T for ; Mon, 9 Jan 2017 12:25:04 -0800 (PST) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::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 AC83A1295CF for ; Mon, 9 Jan 2017 12:25:03 -0800 (PST) Received: by mail-wj0-x229.google.com with SMTP id i20so71211469wjn.2 for ; Mon, 09 Jan 2017 12:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=l+D1yWrGKCNRs1uAA9K67bQGIKXh5Ec7KQQ5Eu7Qbrs=; b=vg5DPkIfOz2GY491cAI8bvrbcOez34KEybD5aY8f7rPQ8XIw2dz5zWSRbZX4UDXWtj zPwTTC8xL1uehKuqZkQX1t0e3vxnoxJgLV2GVAiMtdzFXDj0d29oIdD1lFQgZDXI/LTT BAiN+3Hk++3ua2iuuxw8cDWs57FYq11cmDqZXRHBTeJqbYd7chgkLlnXM54yBt0umxDh TWUlw7QH3Ziwp/+wegyIz0ax89kLG/Q86FHEyR/De9gfppN1RGhvw2UL8rTO+Uui2Gn8 cpSu3YqXx67RLY5JKkHPpKtwab9hoVex1oyX2X/T6xSdP2LzddlaSnSGlMjuc7vDSqWO XuIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=l+D1yWrGKCNRs1uAA9K67bQGIKXh5Ec7KQQ5Eu7Qbrs=; b=jNNyebUc9ROGdtL2aTlLZhQ+3Wng5PVWVAQejIBeew1ekbJyZfswFA5P25uIFuy8wo mE+P1neBnW65hpEN6CfkudO00O/RDB4esfaiI45eZ6F0VQmfaHhLNpJ4zqgzvdsougwQ jabFlNqJKqNBbfg7f77OIiuB/nncAhWbob9S6XWtLfQwwRAazxxRCnJR97RPRGmtXqbM tlWOmNSWkjQTRJV10Qfd0JjGE8IHNQoBDux2d8P1mOJp74kknw4OvsD1wCxU4Au889xl 05epeFZSryYEOXU37o9twDuidQwNRMgg2Lh1vFgDyodO/FyJKYVW4a8YajZVwUB/nA7H EDqw== X-Gm-Message-State: AIkVDXJ8TYlOC3kw2HgVWJWXM52EzuG0z3tYiPQM2/42ae1h/wFY/EI3Ex94OnOrlWZdpg== X-Received: by 10.194.126.1 with SMTP id mu1mr1199708wjb.194.1483993502134; Mon, 09 Jan 2017 12:25:02 -0800 (PST) Received: from [192.168.161.14] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id i10sm125744882wjd.15.2017.01.09.12.25.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 12:25:01 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_8F8F7E37-87C1-4300-8727-92F03727981D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Date: Mon, 9 Jan 2017 12:24:55 -0800 Message-Id: <7370FF51-5B19-49BB-A849-435B11F9A2CC@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:25:06 -0000 --Apple-Mail=_8F8F7E37-87C1-4300-8727-92F03727981D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new version of rfc2464bis = . Links below. This draft brings in the two updates and errata. The changes include: Incorporate update from draft-ietf-6man-default-iids (currently in RFC Editor queue). Revised Section 4 to say IIDs should be formed based on RFC7217 and that it not recommended to use hardware based IIDs. Incorporate update from RFC6085. Added to Section 7 that an IPv6 multicast packet may be mapped to a unicast Ethernet Link layer address and that nodes receiving packets with this address mapping should not drop these packets. Updates to resolve the open Errata on RFC2464. These are: Errata ID: 430: Correct reference to EUI-64. Note, the corrected URL specified in the Errata isn't working, the reference now points to one that does work. Errata ID: 4855: This errata is not correct, and will be marked as rejected. No change is required. Also, the text that this Errata proposed to change was removed when the update from draft-ietf-6man-default-iids was incorporated. Editorial changes. A diff from the previous version can be found at: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-hinden-6man-rfc2464bis-01.txt I plan to send separate emails on each update, explaining the changes = and asking a few questions. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob >=20 > A new version of I-D, draft-hinden-6man-rfc2464bis-01.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-hinden-6man-rfc2464bis > Revision: 01 > Title: Transmission of IPv6 Packets over Ethernet = Networks > Document date: 2017-01-09 > Group: Individual Submission > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-hinden-6man-rfc2464bis-01.txt > Status: = https://datatracker.ietf.org/doc/draft-hinden-6man-rfc2464bis/ > Htmlized: = https://tools.ietf.org/html/draft-hinden-6man-rfc2464bis-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hinden-6man-rfc2464bis-01 >=20 > Abstract: > This document specifies the frame format for transmission of IPv6 > packets and the method of forming IPv6 link-local addresses and > statelessly autoconfigured addresses on Ethernet networks. It also > specifies the content of the Source/Target Link-layer Address option > used in Router Solicitation, Router Advertisement, Neighbor > Solicitation, Neighbor Advertisement and Redirect messages when = those > messages are transmitted on an Ethernet. >=20 > This document replaces RFC 2464 "Transmission of IPv6 Packets over > Ethernet Networks", which will become historic. >=20 >=20 --Apple-Mail=_8F8F7E37-87C1-4300-8727-92F03727981D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYc/GYAAoJEK7rdBF357uouJwH/ifJyaiu1VfhHGTItDi37CKi mfoxVvX5nxwzUuI9j/3wXbfYAGnSEVl2+KwtjAhwWIAOM0pP+bvy2UM40bxENLnY soW0ENuJtuIprtB4ywbul1F5XnlleN7+VfuQTkdDD75x72AfzUbuhJdrMszi0SmS VeU9kgHcQ4G762iRb0m9qRJaJPE2eqLdvdq2MjHFgqyJvwvT5cATikGLexsLbiuO cAJ5LVhILbW11/I4ED/ZhGr5ZY3KkfjfUY0IIKxJIRqE0WIjh/0TRbawKVU1d4VA 8OHOQYSP2hkeHVMvaVOGV6xy//4hngrZp3VBmsH367SWydmZF3kUUnMdS9iNfU8= =CZ9n -----END PGP SIGNATURE----- --Apple-Mail=_8F8F7E37-87C1-4300-8727-92F03727981D-- From nobody Mon Jan 9 12:41: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 E2FC21294D6 for ; Mon, 9 Jan 2017 12:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BhFJbF0lJLr for ; Mon, 9 Jan 2017 12:41:03 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c: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 347481294B6 for ; Mon, 9 Jan 2017 12:41:03 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id a197so109775930wmd.0 for ; Mon, 09 Jan 2017 12:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=foYJlV467db28rjJuw7jfjpUS+ggQ5X7mZuNfe2X5gY=; b=Zqt+KL0AtEkX57D5pvehwNz7D2g8hiaVDdgzv3HwIsYUHfi2koPnxq6ezub6jbjXdB KgMv0Tz+B6L70liDljy4/kTL9Y/MCXxjKGSo9nT/RVDPncBs8fc6MFRr1zq0DGWt3XUr oeCHSZtn1rDI7mpkP9zYDpgUjkwZkJADCIhDf24EXfQnx6BjilhCg5XDdPEjPzXgv9QR mNkIa1pSBtkscoVu5yBuPiyR3iqVDP68CxtGpcP0I08zeeY/Jb96hGl4ta8YjphC8xGe kwXP9s077pIpq9QhpTAJ6+QvV+XRWhzDZcNvcQa4fSmkrYNzGnf7xpQFiNYnFDqd25su Aw3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=foYJlV467db28rjJuw7jfjpUS+ggQ5X7mZuNfe2X5gY=; b=TKE+CrQfpqVZV6YQcF1qTC0GRxhXmsFstTS/M1I2m3s2LJ0AFMaGFz4/vTUOpQsa6d J5gM1Eko5FrmYfEJ0+iKwgzwwc0QoSMU4zFPUUotrIzewWta3sxJH9s3jHACvTXMd3Bx uqIn+BJLG/WQ0L8xGIZMqW2oVlZ3mB5kwapyBRfhdpet1LW8fF35pBQpSglj0u5pFKxg UhoaWv+YKe0v+AnG1GQ5TjzyaG9/gbJAaeemrlIsGly3cgeDMxaRlZWjTBlh4HmO0O24 s0Q3Ql1h35BiX8+cYaVKCjIe3bOQf78IEibMt6eKt7AxqIJAapkbu4kI30Vl9BxaZ6Y5 jjdA== X-Gm-Message-State: AIkVDXKXMu/pAoYJrBLOBecuDWMvW0F4rop1wkv3hOU0R8hjvYBgmaZkum/mUsP6BEL+pg== X-Received: by 10.28.178.142 with SMTP id b136mr51999wmf.69.1483994461693; Mon, 09 Jan 2017 12:41:01 -0800 (PST) Received: from [192.168.161.14] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id 204sm20753813wmj.7.2017.01.09.12.41.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 12:41:00 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_D851435E-2D50-4833-B485-FE3D83DA68F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: update to rfc2464bis Date: Mon, 9 Jan 2017 12:40:55 -0800 Message-Id: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:41:05 -0000 --Apple-Mail=_D851435E-2D50-4833-B485-FE3D83DA68F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Based on update from draft-ietf-6man-default-iids (currently in RFC = Editor queue) I changed the first two paragraphs of Section 4 of = to: 4. Stateless Autoconfiguration The default approach to create stable Interface Identifiers [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet interface should be based on [RFC7217]. It is not recommended that Interface Identifiers for an Ethernet interface be based on IEEE MAC-layer addresses. Earlier versions of this document described a method of forming interface identifiers derived from IEEE MAC-layer addresses called Modified EUI-64 format. This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is no longer recommended. Instead of having it pointing to , the new = text points to RFC7271. I thought this was better as Section 3 of = says the RFC2464 should now follow = RFC7271 (including should use RFC7217 and should not use stable = link-layer address). Avoids a extra hope so to speak. I think the intent of is captured in the = text in the new -01 version. Comments? Thanks, Bob --Apple-Mail=_D851435E-2D50-4833-B485-FE3D83DA68F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYc/VYAAoJEK7rdBF357uoh38H/jsKNULGp5wO2YFmelnS63Es Bvv0H8Gwn4blepeRO/nXRoV6D0+S0qnZe8osWVqA3hiF9n41ibUkhJN6qM0rNOQ/ MqoPAwKvvTZnfX16NFEIVO4l90FGx4LxJ6aHTxXmHufW/TbBD5IHPq9MQ4MnXXFF +UywMbVIvIq2KRZOjuTYY+1d3XCEHVWuXcem3uM+S7P1KuTVqmt7nXVnIobA2mLl yPlKU6x7kMADADMsVj9/wanVjpQYx/PILl/c9CU93zd3IGtWOUfELIHR9To3ueAV WGtiuEMSAS8bheUlkKTe9rzKg/1ybtxOlIsY7+pvI1J7lMrN1YbvGEs41Aig8kk= =J7JW -----END PGP SIGNATURE----- --Apple-Mail=_D851435E-2D50-4833-B485-FE3D83DA68F9-- From nobody Mon Jan 9 13:54: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 29217129878 for ; Mon, 9 Jan 2017 13:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx02k4fxqnob for ; Mon, 9 Jan 2017 13:54:02 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 5880712986E for ; Mon, 9 Jan 2017 13:54:02 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id k184so137779794wme.1 for ; Mon, 09 Jan 2017 13:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:message-id:cc:to:mime-version; bh=/lw/OnkD6uWlqZeJtardB4463nXnCORSQ5x+ZzStVOE=; b=AZxKwCnoYqq6sN4nqowHft9ZMAykMHnhls84R4ZfMeUn28tRTK4tVcgGAMAxS2KPjh aedsUTrG1E6TVzRIr+Ej99MsQd/PK6f4gnm+fL0M59cJi7iKVzUP6e9J/MxHg95qnZxf 1a3bGr72QprotbGYCq8ZnGyh1GO+zAfLrEqjRtFqZmULAoM5xZD9+IxnXiClA4nCpXzz gmrNzmGWVFrHbza8MQoeWluXhuZm86xseDxNiKSS+38+0EJDCv7BcHo18y/P87qmVXkW +iuLGiKjYkR8JLYqRww/g82CJkZ6kUpsrRXvtyj1gfmWTlvOFusy40Ff1/UJG7l42qn2 JJ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=/lw/OnkD6uWlqZeJtardB4463nXnCORSQ5x+ZzStVOE=; b=sXepGECj7AnhoENyCYFCwt/tlaNdemBk7jW4pTqVcSTxgN+No7mOj143EBoJ6sQYYV eYsBhK9u450Zw6Jf7Kkvz0Kj4JlrqBb4IeFdwNYk67fe/dfUx3Pfeduf0X+LVKxfwrk8 Rhk9++YoM1n/wOpaIjYhrzKkrUO5BuyErkSyVOBdQK5AB7i+PX5CDAv8/bUJCwZ7BqZ4 bcBor3euDAxM9r+/i6mIxqDrRWbybYA7EGyzcPzBBG5sh58XEC6q7OqoDGuP7+CkuHM2 Qidt0Te8RvRG4gWrlr95Y6YZ+pFuQmEKu6KQhCbEn4ED6ZZAsOmiEKJt9iXbNxz5iiM5 47QA== X-Gm-Message-State: AIkVDXJK0BGab2Ncfjp0E6KuIKuXY77jvyICmhGO2Q/op3gfg+SRuWZKwvmo77srmJgDaw== X-Received: by 10.28.19.205 with SMTP id 196mr5408776wmt.111.1483998840730; Mon, 09 Jan 2017 13:54:00 -0800 (PST) Received: from [192.168.161.14] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id m78sm251940wmd.8.2017.01.09.13.53.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 13:53:59 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_7133BE40-F380-4562-A600-D5E4828AA75A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: RFC6085 update to rfc2464bis Date: Mon, 9 Jan 2017 13:53:54 -0800 Message-Id: To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:54:04 -0000 --Apple-Mail=_7133BE40-F380-4562-A600-D5E4828AA75A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Based on update from RFC6085 I added two paragraphs to Section 7 of = . These are: > 7. Address Mapping -- Multicast >=20 > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > Ethernet multicast address whose first two octets are the value = 3333 > hexadecimal and whose last four octets are the last four octets of > DST. >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DST[13] | DST[14] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DST[15] | DST[16] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An IPv6 multicast packet may also be mapped to a unicast Ethernet Link layer address as defined in Section 6. An IPv6 node receiving an IPv6 packet with a multicast destination address and an Ethernet link-layer unicast address must not drop the packet as a result using of this form of address mapping. While RFC6085 isn=E2=80=99t exactly clear about the change it wants in = RFC2464, I think this is about right. Comments? Thanks, Bob --Apple-Mail=_7133BE40-F380-4562-A600-D5E4828AA75A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYdAZzAAoJEK7rdBF357uoL7UH/ip4BUvgQRYBTka8aYaTF+Dp qPijFkbeUfTLedLOePsdUALadGroTdzi7enJIPR03ndGvkNFC/FhWQPyqpaiuBId hyODMoUVtdE0RP42+8+Gv7sfCkUdqDmwzZaPEHuwg6sLIo9UWnjpyKrk+kJyXefJ 8W0gO1G90mhgorWezm43l8tFn6bbon+PBsOeA6hYmpnJNV7R17tCIWN+9PEePviU pqL+affGYPisGRu5ycxiQx/LYMhLPgBA981m2YvSCiL2teHrTyobWoUwHWpqiSCQ hUSpBL92/uMfZ5Uy/OjQdxseMGXeMk/DI/UWzKdaQeV05uv5PuuiKtObtMSST7E= =L6pS -----END PGP SIGNATURE----- --Apple-Mail=_7133BE40-F380-4562-A600-D5E4828AA75A-- From nobody Mon Jan 9 14:08: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 1EDF31295F7 for ; Mon, 9 Jan 2017 14:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vayQFcpocc_g for ; Mon, 9 Jan 2017 14:08:23 -0800 (PST) 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 49813127ABE for ; Mon, 9 Jan 2017 14:08:23 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id y143so13448990pfb.0 for ; Mon, 09 Jan 2017 14:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=i/7kwKN0bBdMVFZERWXBuk4qXCRztiVfxPSR4d2WyVg=; b=A2nSBVghi4ctb2tgzYFQ3tOeb8nls/mg2m17YsRkMNo/OP4s945kugL/Nd1dvbVUZw tprXxebB9bDggI/wqH8oWnmB9hikOxUpRm63Nz19FNqz5LQBdBxq3H7hO46koxbkzj3r 0cws6obfEDAO22H678ga/a9WfG3zJvaiiTZbYNuU+qSz6JtHAo+kFmkBk/sVU28oSf+E 6PE8EWEda0ZJdOxRVCYkU97BqRdLmpf4e5YIWuwTuDRvilPUTGVeT5bQia/Y0RDMr2bB jizqJsq1BOfmIH41QSFOOxkQbkxk2ICBRDOssFXM5dOE07fq/bg5DcBKBz1uUb+m7kdV nqOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=i/7kwKN0bBdMVFZERWXBuk4qXCRztiVfxPSR4d2WyVg=; b=T+Nu5TvVXNNxvP5eYk8B3dMBr+URXURBXr4aBtmKxIygY3Fl5p5PCDUPdTBHMUo9Yh WbosbhhmrDVcGicQSeHe8CFprT/HagPrun9FUI2IOzs+PocPARs3jald3P5OKVX09/+j qbTkWZweCqgKU/naKFOIIoJJX4o8nWOqW6Xpsy3Q/lurhVJRt89ala4WSYSVhQuPGSlY pS/nMCmrWbFz1rMeQrfmV7u6BoRi7wdzEKEosepskMzrgYiT06f2CimHZ1hN3z0qj0pX 7HG8+hR9xLtmz0ixcucmYp8fLjOT8FqPxJBgbyh7cN3y452IJsEIWdeCZynhoUObyM/S Hjtg== X-Gm-Message-State: AIkVDXKuwhv835yaHnP5udB1qbf/iI+jANAk3OW5W9Wo0r5kQ4AwtvO1KdrI8kL8S05Oew== X-Received: by 10.98.62.153 with SMTP id y25mr74997703pfj.162.1483999702537; Mon, 09 Jan 2017 14:08:22 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id v1sm183262737pgv.33.2017.01.09.14.08.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 14:08:21 -0800 (PST) Subject: Re: Route Information Options in Redirect Messages To: "Templin, Fred L" , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> Date: Tue, 10 Jan 2017 11:08:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:08:25 -0000 Fred, Can you check that there would be no adverse interaction with RFC8028, especially https://tools.ietf.org/html/rfc8028#section-3.4 Regards Brian On 10/01/2017 04:51, Templin, Fred L wrote: > See below for a new draft that proposes to update RFC4861 and RFC4191 to > permit the inclusion of Route Information Options in Redirect Messages. > This represents a backward-compatible extension to the IPv6 ND Redirect > function. Please review and comment on the list. > > Fred > fred.l.templin@boeing.com > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, January 06, 2017 1:52 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Route Information Options in Redirect Messages > Author : Fred L. Templin > Filename : draft-templin-intarea-rio-redirect-00.txt > Pages : 5 > Date : 2017-01-06 > > Abstract: > The IPv6 Neighbor Discovery protocol provides a Redirect function > allowing routers to inform hosts of a better next hop on the link > toward the destination. This document specifies a backward- > compatible extension to the Redirect function to allow routers to > include forwarding information that the source can associate with the > next hop. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-intarea-rio-redirect/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-templin-intarea-rio-redirect-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 > -------------------------------------------------------------------- > . > From nobody Tue Jan 10 03:00: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 2749B1299FA for ; Tue, 10 Jan 2017 03:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFAJY9owSKDM for ; Tue, 10 Jan 2017 03:00:06 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A8E1293D6 for ; Tue, 10 Jan 2017 03:00:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id EF6774A; Tue, 10 Jan 2017 12:00:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1484046001; bh=xg2/iRRi2JWvqrdcbPhdS2jDTP77 sZfhv26T17FqZ3o=; b=cXYGHmTHRavfRIRKZr9yD1pG6ioMTEZ7Y6WSgIEZhE4s zhzpa6s9ga69xKtIMXL0fIbIaSZc2NAZI3n9TYAna8/oip6GLRUdncj0etY7INMq +rm2XedheD54g1mLLDSBujVzDc3gxtDDNE2uHNLm32Pod3Sq8hSdDTz387lVzQ4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qOHVyFM0dgOZ; Tue, 10 Jan 2017 12:00:01 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:7069:1aa0:acef:5051] (unknown [IPv6:2a02:a213:a300:9300:7069:1aa0:acef:5051]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 1A63648; Tue, 10 Jan 2017 12:00:01 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D1F050AF-3D88-4B03-8A3B-F52F73148716"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: RFC6085 update to rfc2464bis X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Tue, 10 Jan 2017 11:59:50 +0100 Message-Id: References: To: Bob Hinden X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:00:08 -0000 --Apple-Mail=_D1F050AF-3D88-4B03-8A3B-F52F73148716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > Based on update from RFC6085 I added two paragraphs to Section 7 of = . These are: >=20 >> 7. Address Mapping -- Multicast >>=20 >> An IPv6 packet with a multicast destination address DST, consisting >> of the sixteen octets DST[1] through DST[16], is transmitted to the >> Ethernet multicast address whose first two octets are the value = 3333 >> hexadecimal and whose last four octets are the last four octets of >> DST. >>=20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DST[13] | DST[14] | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DST[15] | DST[16] | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. >=20 > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. >=20 > While RFC6085 isn=E2=80=99t exactly clear about the change it wants in = RFC2464, I think this is about right. >=20 > Comments? Looks good. Sander --Apple-Mail=_D1F050AF-3D88-4B03-8A3B-F52F73148716 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYdL6mAAoJEKAtA7D+JBO5MbAH/it/17MXL/GVLb7WzRM9YEMo /xRg7LcEigUo1lzZp3eWEUQGVgf69hf7YuKVP9+t04Hw3NjrEmcXyN+TWExJaZdf UeTetgOC/r2agpgQXwaq19zoHWgAex+2LSWGXPuLtkrJD+Gb0DqFwxlq+V0WG537 Fw7gudL7HnybQSJH9KmgqTgLw58XAef81T+/88E3FHf52gKueRJrM24L1t2lAIEO kA/r09Dr7XibMp5JI9+JfpP1Sr7h+Hj73vei57nhyTd8Yp1K7SHkkLzbYma//n6E zK5AMsZH3AqNAgw1gR4gnC23HGzlxd8vg5OywORVz/dcexgfXj2Dwh/bIq9lUiU= =oNtH -----END PGP SIGNATURE----- --Apple-Mail=_D1F050AF-3D88-4B03-8A3B-F52F73148716-- From nobody Tue Jan 10 03:20: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 04E8712996B for ; Tue, 10 Jan 2017 03:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVpoHwRudtjU for ; Tue, 10 Jan 2017 03:20:01 -0800 (PST) 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 EB96D127A91 for ; Tue, 10 Jan 2017 03:20:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CC314B810D7; Tue, 10 Jan 2017 03:20:00 -0800 (PST) To: kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, bob.hinden@gmail.com, otroan@employees.org Subject: [Editorial Errata Reported] RFC5952 (4900) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170110112000.CC314B810D7@rfc-editor.org> Date: Tue, 10 Jan 2017 03:20:00 -0800 (PST) Archived-At: Cc: michael.krzyzaniak@gmx.de, ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:20:02 -0000 The following errata report has been submitted for RFC5952, "A Recommendation for IPv6 Address Text Representation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4900 -------------------------------------- Type: Editorial Reported by: Michael Krzyzaniak Section: 4.2.2. Original Text ------------- Handling One 16-Bit 0 Field The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. Corrected Text -------------- But Section 2.2. Zero Compression says: 'A special syntax is available to compress the zeros. The use of "::" indicates one or more groups of 16 bits of zeros.' It is possible to select whether or not to omit just one 16-bit 0 field. 2001:db8:aaaa:bbbb:cccc:dddd::1 2001:db8:aaaa:bbbb:cccc:dddd:0:1 Notes ----- In 2.2 :: for only one 16-bit 0 filed :: is used 4.2.2 says MUST NOT -RFC 2119 says 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5952 (draft-ietf-6man-text-addr-representation-07) -------------------------------------- Title : A Recommendation for IPv6 Address Text Representation Publication Date : August 2010 Author(s) : S. Kawamura, M. Kawashima Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Jan 10 03:33: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 4C420129BB7 for ; Tue, 10 Jan 2017 03:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 i1m3CGJtOXny for ; Tue, 10 Jan 2017 03:33:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB37129BBA for ; Tue, 10 Jan 2017 03:33:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 872C86C0; Tue, 10 Jan 2017 12:33:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FKrnl7MnNWrJ; Tue, 10 Jan 2017 12:33:14 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Jan 2017 12:33:16 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3CB22008D; Tue, 10 Jan 2017 12:33:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mYPkIegGsvMx; Tue, 10 Jan 2017 12:33:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2CF32008C; Tue, 10 Jan 2017 12:33:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F16483E0805A; Tue, 10 Jan 2017 12:33:14 +0100 (CET) Date: Tue, 10 Jan 2017 12:33:14 +0100 From: Juergen Schoenwaelder To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC5952 (4900) Message-ID: <20170110113314.GA16712@elstar.local> Mail-Followup-To: RFC Errata System , kawamucho@mesh.ad.jp, kawashimam@vx.jp.nec.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, bob.hinden@gmail.com, otroan@employees.org, michael.krzyzaniak@gmx.de, ipv6@ietf.org References: <20170110112000.CC314B810D7@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170110112000.CC314B810D7@rfc-editor.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: michael.krzyzaniak@gmx.de, ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, kawamucho@mesh.ad.jp, terry.manderson@icann.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 11:33:20 -0000 Michael, section 2 of RFC 5952 explains how the textual representation was originally defined, section 3 explains why tighter rules are desirable, and section 4 finally defines tight rules that lead to predictable textual representations. It is thus not a bug that the texts in the different sections are different and hence I think this errata should be rejected. /js On Tue, Jan 10, 2017 at 03:20:00AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC5952, > "A Recommendation for IPv6 Address Text Representation". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5952&eid=4900 > > -------------------------------------- > Type: Editorial > Reported by: Michael Krzyzaniak > > Section: 4.2.2. > > Original Text > ------------- > Handling One 16-Bit 0 Field > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > 2001:db8::1:1:1:1:1 is not correct. > > Corrected Text > -------------- > But Section 2.2. Zero Compression > says: > > 'A special syntax is available to compress the zeros. The use of > "::" indicates one or more groups of 16 bits of zeros.' > > It is possible to select whether or not to omit just one 16-bit 0 > field. > > 2001:db8:aaaa:bbbb:cccc:dddd::1 > > 2001:db8:aaaa:bbbb:cccc:dddd:0:1 > > Notes > ----- > In 2.2 :: for only one 16-bit 0 filed :: is used > 4.2.2 says MUST NOT -RFC 2119 says > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5952 (draft-ietf-6man-text-addr-representation-07) > -------------------------------------- > Title : A Recommendation for IPv6 Address Text Representation > Publication Date : August 2010 > Author(s) : S. Kawamura, M. Kawashima > Category : PROPOSED STANDARD > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 10 04:45: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 7C1AA129F8E for ; Tue, 10 Jan 2017 04:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60CVPijyxR9J for ; Tue, 10 Jan 2017 04:45:35 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3354F129E83 for ; Tue, 10 Jan 2017 04:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GEiMbZgDvCBaofQWYXIm7MrxtT8xYGDUqsZlLrH07Q8=; b=O96vF64e2xyZ3SPHtjs5u1whG2Y805UoLp4oX2JGK1vDd5+AKq559YRgVdF9EWmiNPI1A0YF06nt2MTSG3Upw/l8PzsEojZjyJv4rHR7ccyg588TjLs4LY3onzQG0gIujtnKX2DQxxhSZsvySn4IXMuOGzO3w54QGfngg508/sw= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0239.outbound.protection.outlook.com [213.199.154.239]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-88-VGEZQpwCOfK07fhoS28BMQ-1; Tue, 10 Jan 2017 12:45:29 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 12:45:28 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2%14]) with mapi id 15.01.0845.012; Tue, 10 Jan 2017 12:45:28 +0000 From: Tim Chown To: "otroan@employees.org" Subject: Re: Errata for RFC4862 Thread-Topic: Errata for RFC4862 Thread-Index: AQHSaXBn5ebqxyUYbEyFjv7/ZjHe0aEv2MYAgAHTMAA= Date: Tue, 10 Jan 2017 12:45:27 +0000 Message-ID: <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.12.168.164] x-ms-office365-filtering-correlation-id: fb186b98-e537-4249-e27f-08d439568e22 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:DwpIStPMkkGbcrUUgY1/cVuetTD70BgiUkA392XJa8E2kCzE3uUnJYXftJBQpUAzq83eUjaTed1mLVz0IUKKps1giKwXlPGvbRk5POwkVa0pTJLkQ/zqCB8rmQILaHRslc4127RV1ejWzHCOoPSVG5xYje0fdvoUA+m14AaqXh3izL+wd9bXx/N+QR8/KBgFAzbkb26YCpYbUIzkn/Zf3bIMDQWM+vsz1C+yhxZ+LUqdy6LbP5xWonrAm2HEadU5EKqQqHLRVQbcYCxcmZ0yGgamqZMHyTTqOKg97OkBKBLqd89KwjjWIhU+umd1ZRjHO2rDYyCTxG8rlVoXjTGEF/v65Xj/qlrYBmQTnoQqeDwZsFaKv1Aiqy57qBtMm/8DXMY4ciVnLqmyvRJYApiXs7LZb/rqT5c14X1+F+fnD6dGFt65SlyM3J3U8nuwrIE6TwaOOF275yLK2OaGFkBgyw==; 20:8j2Y6+P5AMMkOYX5QBbJtA03jhNkXuSVMruFFxUzJfFLGmmlfghIaDBQDjoxoVQCKfSzB+h3SIi42iq7790599WHyv/8tMet6MnAdIxmBYuCiHL7/fd2Mj5VPI9eqUNlqCsb/tj8+4lrulHRiXN/qrY4bSaRNoL4SZUNPWPIRhs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(85644002)(24454002)(86362001)(102836003)(6116002)(229853002)(57306001)(6436002)(39060400001)(3846002)(76176999)(50986999)(101416001)(6486002)(3660700001)(38730400001)(6512007)(6306002)(105586002)(106116001)(68736007)(106356001)(36756003)(74482002)(66066001)(3280700002)(4326007)(2351001)(97736004)(33656002)(5640700003)(2900100001)(189998001)(82746002)(50226002)(54906002)(7736002)(83716003)(92566002)(99286003)(8676002)(2950100002)(42882006)(6916009)(1730700003)(81156014)(305945005)(5250100002)(2906002)(7116003)(110136003)(2501003)(5660300001)(6506006)(81166006)(8936002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <635DBE432CA11F4BAA4B41E212817721@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 12:45:27.9392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: VGEZQpwCOfK07fhoS28BMQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 12:45:38 -0000 PiBPbiA5IEphbiAyMDE3LCBhdCAwODo1Mywgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3JvdGU6DQo+ IA0KPiBNYXJrLA0KPiANCj4gVGhlIGN1cnJlbnQgdGV4dCBpcyBjcmFmdGVkIGJvdGggdG8gYWxs b3cgcmVudW1iZXJpbmcgYW5kIHRvIHN1cHBvcnQgc2NlbmFyaW9zIHdoZXJlIHRoZSBSQSBsaWZl dGltZXMgYXJlIHNob3J0LiBJLmUuIHVuZGVyIHR3byBob3Vycy4NCj4gWW91ciBwcm9wb3NlZCBj aGFuZ2VzIGFwcGVhciB0byBsb2NrIHRoZSBsaWZldGltZXMgdG8gbm8gbGVzcyB0aGFuIHR3byBo b3Vycy4gSXMgdGhhdCBjb3JyZWN0bHkgdW5kZXJzdG9vZD8NCg0KRG8geW91IG1lYW4gUHJlZmVy cmVkIG9yIFZhbGlkIExpZmV0aW1lcz8NCg0KTXkgcmVjb2xsZWN0aW9uIG9mIHJ1bm5pbmcgcmVu dW1iZXJpbmcgZXhwZXJpbWVudHMgaXMgdGhhdCBpdOKAmXMgdGhlIFByZWZlcnJlZCBMaWZldGlt ZSB0aGF0IG1hdHRlcnMsIGkuZS4gd2hlbiB0aGF0IGlzIHNldCB0byB6ZXJvIGZvciBhIHByZWZp eCwgdGhlIHByZWZpeCBpcyBtYXJrZWQgYXMgZGVwcmVjYXRlZC4gIFNvIHdoZW4gcmVudW1iZXJp bmcsIHlvdSBydW4gd2l0aCB0d28gcHJlZml4ZXMgYWR2ZXJ0aXNlZCwgb2xkIGFuZCBuZXcsIHNl dHRpbmcgdGhlIFByZWZlcnJlZCBMaWZldGltZSB0byAwIG9uIHRoZSBvbGQgcHJlZml4IChldmVu IHRob3VnaCB0aGUgVmFsaWQgTGlmZXRpbWUgaXMgc2V0IHRvIDIrIGhvdXJzKSwgc28gdGhhdCB0 aGUgYWRkcmVzcyB3aXRoIHRoZSBuZXcgcHJlZml4IGlzIHVzZWQgZm9yIG5ld2x5IGluaXRpYXRl ZCBjb21tdW5pY2F0aW9ucyAoYXMgcGVyIFJGQyA2NzI0LCBSdWxlIDMpLg0KDQpUaW0NCg0KPiBC dHcsIHRoaXMgbWlnaHQgbm90IGJlIGFwcHJvcHJpYXRlIGZvciBhbiBlcnJhdHVtLCBidXQgSSBk byBhbHNvIHRoaW5rIHdlIHNob3VsZCByZXZpc2l0IHRoaXMgYmVoYXZpb3VyLiBGb3IgdGhlIElQ djYgY29yZSBzcGVjaWZpY2F0aW9ucyB0byBJbnRlcm5ldCBzdGFuZGFyZHMgd29yaywgSSB0aGlu ayB0aGUgdGVudGF0aXZlIGNvbmNsdXNpb24gd2FzIHRoYXQgd2UgbmVlZGVkIHRvIGRvIDQ4NjEv NDg2MmJpcyBkb2N1bWVudHMgaW4tcGxhY2UgYmVmb3JlIGNvbnNpZGVyaW5nIGFuIGFkdmFuY2Vt ZW50Lg0KPiANCj4gTy4NCj4gDQo+PiBPbiA4IEphbiAyMDE3LCBhdCAwNjozMCwgTWFyayBTbWl0 aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpLA0KPj4gDQo+PiBJ J3ZlIHN0cnVnZ2xlZCB3aXRoIHRoZSBFcnJhdGEgdG9vbCBjb21wbGFpbmluZyBhYm91dCBub3Qg aGF2aW5nIGxpbmUNCj4+IGJyZWFrcyBhdCA3MiBjaGFyYWN0ZXJzIGZvciB0aGUgbGFzdCAxNSBv ciBzbyBtaW51dGVzLCBhbmQgYWZ0ZXINCj4+IG1ha2luZyBudW1iZXIgb2YgZmFpbGVkIGF0dGVt cHRzIHRvIGZpeCB0aGF0LCB0aGF0J3MgZW5vdWdoIQ0KPj4gDQo+PiBTZWN0aW9uOg0KPj4gDQo+ PiA1LjUuMyBSb3V0ZXJBZHZlcnRpc2VtZW50IFByb2Nlc3NpbmcNCj4+IA0KPj4gDQo+PiBPcmln aW5hbCBUZXh0Og0KPj4gDQo+PiAgICAgMS4gIElmIHRoZSByZWNlaXZlZCBWYWxpZCBMaWZldGlt ZSBpcyBncmVhdGVyIHRoYW4gMiBob3VycyBvcg0KPj4gICAgICAgICBncmVhdGVyIHRoYW4gUmVt YWluaW5nTGlmZXRpbWUsIHNldCB0aGUgdmFsaWQgbGlmZXRpbWUgb2YgdGhlDQo+PiAgICAgICAg IGNvcnJlc3BvbmRpbmcgYWRkcmVzcyB0byB0aGUgYWR2ZXJ0aXNlZCBWYWxpZCBMaWZldGltZS4N Cj4+IA0KPj4gICAgIDIuICBJZiBSZW1haW5pbmdMaWZldGltZSBpcyBsZXNzIHRoYW4gb3IgZXF1 YWwgdG8gMiBob3VycywgaWdub3JlDQo+PiAgICAgICAgIHRoZSBQcmVmaXggSW5mb3JtYXRpb24g b3B0aW9uIHdpdGggcmVnYXJkcyB0byB0aGUgdmFsaWQNCj4+ICAgICAgICAgbGlmZXRpbWUsIHVu bGVzcyB0aGUgUm91dGVyIEFkdmVydGlzZW1lbnQgZnJvbSB3aGljaCB0aGlzDQo+PiAgICAgICAg IG9wdGlvbiB3YXMgb2J0YWluZWQgaGFzIGJlZW4gYXV0aGVudGljYXRlZCAoZS5nLiwgdmlhIFNl Y3VyZQ0KPj4gICAgICAgICBOZWlnaGJvciBEaXNjb3ZlcnkgW1JGQzM5NzFdKS4gIElmIHRoZSBS b3V0ZXIgQWR2ZXJ0aXNlbWVudA0KPj4gICAgICAgICB3YXMgYXV0aGVudGljYXRlZCwgdGhlIHZh bGlkIGxpZmV0aW1lIG9mIHRoZSBjb3JyZXNwb25kaW5nDQo+PiAgICAgICAgIGFkZHJlc3Mgc2hv dWxkIGJlIHNldCB0byB0aGUgVmFsaWQgTGlmZXRpbWUgaW4gdGhlIHJlY2VpdmVkDQo+PiAgICAg ICAgIG9wdGlvbi4NCj4+IA0KPj4gICAgIDMuICBPdGhlcndpc2UsIHJlc2V0IHRoZSB2YWxpZCBs aWZldGltZSBvZiB0aGUgY29ycmVzcG9uZGluZw0KPj4gICAgICAgICBhZGRyZXNzIHRvIDIgaG91 cnMuDQo+PiANCj4+IA0KPj4gQ29ycmVjdGVkIFRleHQ6DQo+PiANCj4+IDEuIElmIHRoZSBSb3V0 ZXIgQWR2ZXJ0aXNlbWVudCBpcyBub3QgYXV0aGVudGljYXRlZCAoZS5nLiwgdmlhIFNlY3VyZQ0K Pj4gTmVpZ2hib3IgRGlzY292ZXJ5IFtSRkMzOTcxXSksIGFuZCBpZiB0aGUgcmVjZWl2ZWQgVmFs aWQgTGlmZXRpbWUgaXMgZ3JlYXRlcg0KPj4gdGhhbiAyIGhvdXJzLCBzZXQgdGhlIHZhbGlkIGxp ZmV0aW1lIG9mIHRoZSBjb3JyZXNwb25kaW5nIGFkZHJlc3MgdG8gdGhlDQo+PiBhZHZlcnRpc2Vk IFZhbGlkIExpZmV0aW1lLg0KPj4gDQo+PiAyLiBJZiB0aGUgUm91dGVyIEFkdmVydGlzZW1lbnQg aGFzIGJlZW4gYXV0aGVudGljYXRlZCAoZS5nLiwgdmlhIFNlY3VyZQ0KPj4gTmVpZ2hib3IgRGlz Y292ZXJ5IFtSRkMzOTcxXSksIHRoZSB2YWxpZCBsaWZldGltZSBvZiB0aGUgY29ycmVzcG9uZGlu Zw0KPj4gYWRkcmVzcyBzaG91bGQgYmUgc2V0IHRvIHRoZSBWYWxpZCBMaWZldGltZSBpbiB0aGUg cmVjZWl2ZWQgb3B0aW9uDQo+PiAocmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGlzIGdyZWF0ZXIg dGhhbiAyIGhvdXJzIG9yIG5vdCkuDQo+PiANCj4+IDMuICBPdGhlcndpc2UsIHJlc2V0IHRoZSB2 YWxpZCBsaWZldGltZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhZGRyZXNzIHRvIDINCj4+IGhvdXJz Lg0KPj4gDQo+PiBJbiBvdGhlciB3b3JkcywgdW5sZXNzIGFuIFJBIGlzIGF1dGhlbnRpY2F0ZWQs IFZhbGlkIExpZmV0aW1lcyBpbiBSQSBQSU9zDQo+PiBNVVNUIGJlIGdyZWF0ZXIgdGhhbiAyIGhv dXJzLg0KPj4gDQo+PiANCj4+IE5vdGVzOg0KPj4gDQo+PiBGb3IgdW5hdXRoZW50aWNhdGVkIFJB cywgdGhyb3VnaG91dCB0aGUgdGV4dCB0aGVyZSBhcmUgbnVtZXJvdXMgY2hlY2tzDQo+PiB0byBw cmV2ZW50IGEgcG9zc2libGUgRG9TIGF0dGFjayBkZXNjcmliZWQgaW4gdGhlIHN1YnNlcXVlbnQN Cj4+IHBhcmFncmFwaDoNCj4+IA0KPj4gIlRoZSBhYm92ZSBydWxlcyBhZGRyZXNzIGEgc3BlY2lm aWMgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGluDQo+PiAgICAgd2hpY2ggYSBib2d1cyBhZHZl cnRpc2VtZW50IGNvdWxkIGNvbnRhaW4gcHJlZml4ZXMgd2l0aCB2ZXJ5IHNtYWxsDQo+PiAgICAg VmFsaWQgTGlmZXRpbWVzLiINCj4+IA0KPj4gQ2hlY2sgMSBhYm92ZSB3b3VsZCBzZWVtIHRvIGFs bG93IGEgVmFsaWQgTGlmZXRpbWUgaW4gYW4gUkEgUElPIHRoYXQNCj4+IGlzIG11Y2ggbGVzcyB0 aGFuIDIgaG91cnMsIGFzIGxvbmcgYXMgdGhlIHZhbHVlIGlzIGdyZWF0ZXIgdGhhbiB0aGUNCj4+ IFJlbWFpbmluZ0xpZmV0aW1lLiBGb3IgZXhhbXBsZSwgaWYgYSBob3N0J3MgUmVtYWluaW5nTGlm ZXRpbWUgZm9yIGFuDQo+PiBhZGRyZXNzIGlzIDYwIHNlY29uZHMsIGFuIFJBIFBJTyBWYWxpZExp ZmV0aW1lIG9mIDYxIHNlY29uZHMgd291bGQgYmUNCj4+IGFjY2VwdGFibGUuIFRoaXMgd291bGQg c2VlbSB0byBjb250cmFkaWN0IHRoZSBEb1MgcHJvdGVjdGlvbiBnb2FsLg0KPj4gDQo+PiBDaGVj ayAyIGRvZXMgY2hlY2sgdG8gZW5zdXJlIHRoYXQgUmVtYWluaW5nTGlmZXRpbWUgaXMgZ3JlYXRl ciB0aGFuIDINCj4+IGhvdXJzLCBob3dldmVyIENoZWNrIDEgaGFzDQo+PiBhbHJlYWR5IGFjY2Vw dGVkIHRoZSBSQSBQSU8gVkwgPDIgaG91cnMgKGlmIGdyZWF0ZXIgdGhhbg0KPj4gUmVtYWluaW5n TGlmZXRpbWUpIGFuZCBzZXQgdGhlIGFkZHJlc3MncyBWYWxpZA0KPj4gTGlmZXRpbWUgdG8gYSB2 YWx1ZSBwb3NzaWJseSBtdWNoIGxlc3MgdGhhbiAyIGhvdXJzLg0KPj4gDQo+PiBBbiBhdHRhY2tl ciBjb3VsZCB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGJ5IGRvaW5nIHRoZSBmb2xsb3dpbmc6DQo+ PiANCj4+IDEuIFNlbmQgYW4gaW5pdGlhbCBSQSB3aXRoIGEgVmFsaWRMaWZldGltZSBvZiAyIGhv dXJzLCB3aGljaCB3b3VsZCBwYXNzIENoZWNrIDEuDQo+PiAyLiBXYWl0IHVudGlsIGFyb3VuZCAx IGhvdXIgYW5kIDU5LjUgbWludXRlcywgYW5kIHRoZW4gc2VuZCBhbiBSQSB3aXRoDQo+PiBhIFZh bGlkTGlmZXRpbWUgb2YgNjEgc2Vjb25kcy4NCj4+IDMuIFNlbmQgUkFzIGV2ZXJ5IDMwIG9yIHNv IHNlY29uZHMgd2l0aCBhIFZhbGlkTGlmZXRpbWUgb2YgNjEgc2Vjb25kcywNCj4+IGhvbGRpbmcg YWxsIG9mIHRoZSB2aWN0aW0gaG9zdHMnDQo+PiBWYWxpZExpZmV0aW1lcyBhdCBhIGxvdyB2YWx1 ZS4gVGhlc2UgUkFzIHdvdWxkIGFsc28gcGFzcyBDaGVjayAxIGFzDQo+PiBsb25nIGFzIHRoZSBW TCBpbiB0aGUgUkEgd2FzDQo+PiBncmVhdGVyIHRoYW4gdGhlIGhvc3RzJyBjdXJyZW50IFZMIGZv ciB0aGUgYWRkcmVzc2VzLg0KPj4gNC4gV2hlbiBpdCBjb3VsZCBjYXVzZSB0aGUgbW9zdCBzaWdu aWZpY2FudCBkZW5pYWwgb2Ygc2VydmljZSwgc3RvcA0KPj4gc2VuZGluZyB0aGUgUkFzLCBjYXVz aW5nIHRoZSBob3N0cycNCj4+IGFkZHJlc3MgVkxzIGFuZCB0aGVyZWZvcmUgdGhlIGFkZHJlc3Nl cyB0byBleHBpcmUgd2l0aGluIDYwIHNlY29uZHMgb3Igc28uDQo+PiANCj4+IA0KPj4gUmVnYXJk cywNCj4+IE1hcmsuDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KDQo= From nobody Tue Jan 10 08:32:19 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 E7E33129D1E; Tue, 10 Jan 2017 08:32:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Haberman To: Subject: Review of draft-ietf-6man-rfc4291bis-06 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 08:32:10 -0800 Archived-At: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:32:11 -0000 Reviewer: Brian Haberman Review result: Ready with Nits I just have a few comments/questions on this draft. Overall, it is in pretty good shape... 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but I don't see a reference to 5952. Is the intent to deprecate 5952 since its content is now contained within 4291bis? 2. Section 2.6.1 captures some information about reserved IPv6 multicast addresses, but not all of them. I think it would be beneficial to point to the IPv6 Multicast Address Allocation registry maintained by IANA, much like the way Section 2.3 points to the IANA registries. 3. Also in Section 2.6.1, the names of reserved addresses, like "All Nodes Addresses", were made all lowercase. Was that intentional? Given that IANA refers to them with capitalization, it would seem that we need to be consistent. So, I would either retain the capitalization in this document or ensure that Section 3 directs IANA to update the names in the registries. From nobody Tue Jan 10 09:26: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 8FF091294E3 for ; Tue, 10 Jan 2017 09:26:25 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 ugy6gcBpWQez for ; Tue, 10 Jan 2017 09:26:24 -0800 (PST) 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 196C712947F for ; Tue, 10 Jan 2017 09:26:24 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id u25so565698824qki.2 for ; Tue, 10 Jan 2017 09:26:24 -0800 (PST) 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=W6XZu9OZBPTf1p9VsEvTI4UGtCwm2vtOjuynvugLIdo=; b=rfGgkGOv0k+D+sT01B2P4zrpOqxT3lc7BmwfkvXPuXAzfzCDorjMCZ4MpoasmCc/nC bO1oOdn0kNZYl8quqmmJuhJoqyl4wu2N4bTeEEnikQat0b38285tNy0hQJLQzGGpq7x+ RSIo/yBLasINJXUAmnLL+7GR6U60Fl43S/Zyk9EBt62goEfIQkJyrYyEdubDoG9b54ZA 1goLVwuWI6eXXAKJ7/PMrM+JNsQCpoJNYzqlV3ydyeinGh5sNs2YBXLff2nIcq9yIstZ 6GA3Cvyq5osLnI94MukilhwzV7+sqyyeDnYsG0rILlwxVtT0lRXJphqOKpy1oSS15Hrx Kmbw== 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=W6XZu9OZBPTf1p9VsEvTI4UGtCwm2vtOjuynvugLIdo=; b=uTFfgHd+VfNnCEGFGvY+xJj+TwWg9Q0aWceDRlYszZDSfLF6tTJUMgIMqy7edOSF0Q P2hgLarplvxR0PhPL0HDD1B3TRB3JXTiroJGTIdTneKVhC18mb0GQYtjqTHc9+1JjEj9 LR5aHH7APY7MNQi8eiU5wVhc8NMdtgOB0lpezdeIy1wZrtAxPtaBdLvRLbssGkQ9If4B xxavKiqSrideW0/cHQgg/+5VwUiOahRwDH1Na29UI2rRYaea0xbiDyWmYCita153zeBx C0WD8OrPPhmMTtr+nXosHtsJUTG/PU92y3awOgtjOIwlsTiSb9tsX8bcgRk2BXag/1RM qzPA== X-Gm-Message-State: AIkVDXLxKpFvjL7f1S1KQaIKlPo+uQzSBa7J+X21nt0Ly5s5bhP7TlrVYop2joLNQ4Wsh4MC6lO0YdoECdPksw== X-Received: by 10.55.45.129 with SMTP id t123mr3669732qkh.311.1484069183106; Tue, 10 Jan 2017 09:26:23 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 10 Jan 2017 09:26:22 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 10 Jan 2017 09:26:22 -0800 X-Google-Sender-Auth: pgBOELoQhs6WK2mZXwMtgMLPY-E Message-ID: Subject: Re: RFC6085 update to rfc2464bis To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:26:25 -0000 At Mon, 9 Jan 2017 13:53:54 -0800, Bob Hinden wrote: > > 7. Address Mapping -- Multicast > > > > An IPv6 packet with a multicast destination address DST, consisting > > of the sixteen octets DST[1] through DST[16], is transmitted to the > > Ethernet multicast address whose first two octets are the value 3333 > > hexadecimal and whose last four octets are the last four octets of > > DST. > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | DST[13] | DST[14] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | DST[15] | DST[16] | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. I think it's more helpful to refer to RFC6085 explicitly here. Otherwise the proposed text looks good to me. > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. -- JINMEI, Tatuya From nobody Tue Jan 10 09:55: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 741D5129D70; Tue, 10 Jan 2017 09:55:21 -0800 (PST) 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 lcUxjXAnfsjo; Tue, 10 Jan 2017 09:55:19 -0800 (PST) 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 46726129D5D; Tue, 10 Jan 2017 09:55:14 -0800 (PST) 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 v0AHtDbW033800; Tue, 10 Jan 2017 10:55:13 -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 v0AHtCRk033401 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2017 10:55:12 -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.1178.4; Tue, 10 Jan 2017 09:55:11 -0800 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.1178.000; Tue, 10 Jan 2017 09:55:10 -0800 From: "Templin, Fred L" To: Brian E Carpenter , 6man WG , INT Area Subject: RE: Route Information Options in Redirect Messages Thread-Topic: Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAeC3cAABhBxNA= Date: Tue, 10 Jan 2017 17:55:10 +0000 Message-ID: <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> In-Reply-To: <32fbea25-01c9-aa32-e70f-3e1282f56294@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:55:21 -0000 SGkgQnJpYW4sDQoNCkkgYW0gbG9va2luZyBhdCB0aGUgc2VjdGlvbiB0aGF0IHNheXM6DQoNCiIz LjQuICBSZWRpcmVjdHMNCiAgIFRoZXJlIGlzIHBvdGVudGlhbCBmb3IgYWR2ZXJzZSBpbnRlcmFj dGlvbiB3aXRoIGFueSBvZmYtbGluayBSZWRpcmVjdA0KICAgKFJlZGlyZWN0IGZvciBhIGRlc3Rp bmF0aW9uIHRoYXQgaXMgbm90IG9uLWxpbmspIG1lc3NhZ2Ugc2VudCBieSBhDQogICByb3V0ZXIg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gOCBvZiBbUkZDNDg2MV0uICBIb3N0cyBTSE9VTEQg YXBwbHkNCiAgIG9mZi1saW5rIHJlZGlyZWN0cyBvbmx5IGZvciB0aGUgc3BlY2lmaWMgcGFpciBv ZiBzb3VyY2UgYW5kDQogICBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgY29uY2VybmVkLCBzbyB0aGUg aG9zdCdzIERlc3RpbmF0aW9uIENhY2hlDQogICBtaWdodCBuZWVkIHRvIGNvbnRhaW4gYXBwcm9w cmlhdGUgc291cmNlLXNwZWNpZmljIGVudHJpZXMuICBUaGlzDQogICBleHRlbmRzIHRoZSB2YWxp ZGl0eSBjaGVjayBzcGVjaWZpZWQgaW4gU2VjdGlvbiA4LjEgb2YgW1JGQzQ4NjFdLiINCg0KV2hh dCBpcyBiZWluZyBwcm9wb3NlZCBpbiB0aGUgZG9jdW1lbnQgSSBzdWJtaXR0ZWQgaXMgdGhlIGlu Y2x1c2lvbiBvZg0KUklPcyBpbiBSZWRpcmVjdCBtZXNzYWdlcyBmb3IgYSAqcHJlZml4KiB0aGF0 IGlzIG5vdCBvbi1saW5rLCBhcyBvcHBvc2VkDQp0byBhIHNpbmdsZXRvbiBkZXN0aW5hdGlvbi4g U28sIHRoZSBzYW1lIFNIT1VMRCBpbiB0aGUgcGFyYWdyYXBoIGFib3ZlDQp3b3VsZCBzZWVtIHRv IGFwcGx5IGFsc28gdG8gcHJlZml4IHJlZGlyZWN0aW9uIHRoZSBzYW1lIGFzIGZvciBvcmRpbmFy eQ0KZGVzdGluYXRpb24gcmVkaXJlY3Rpb24uDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1w bGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBC cmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4g U2VudDogTW9uZGF5LCBKYW51YXJ5IDA5LCAyMDE3IDI6MDggUE0NCj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6IFJlOiBSb3V0ZSBJbmZvcm1hdGlvbiBPcHRpb25zIGluIFJlZGlyZWN0IE1l c3NhZ2VzDQo+IA0KPiBGcmVkLA0KPiANCj4gQ2FuIHlvdSBjaGVjayB0aGF0IHRoZXJlIHdvdWxk IGJlIG5vIGFkdmVyc2UgaW50ZXJhY3Rpb24gd2l0aCBSRkM4MDI4LA0KPiBlc3BlY2lhbGx5IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDI4I3NlY3Rpb24tMy40DQo+IA0KPiBSZWdh cmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAxMC8wMS8yMDE3IDA0OjUxLCBUZW1wbGluLCBGcmVk IEwgd3JvdGU6DQo+ID4gU2VlIGJlbG93IGZvciBhIG5ldyBkcmFmdCB0aGF0IHByb3Bvc2VzIHRv IHVwZGF0ZSBSRkM0ODYxIGFuZCBSRkM0MTkxIHRvDQo+ID4gcGVybWl0IHRoZSBpbmNsdXNpb24g b2YgUm91dGUgSW5mb3JtYXRpb24gT3B0aW9ucyBpbiBSZWRpcmVjdCBNZXNzYWdlcy4NCj4gPiBU aGlzIHJlcHJlc2VudHMgYSBiYWNrd2FyZC1jb21wYXRpYmxlIGV4dGVuc2lvbiB0byB0aGUgSVB2 NiBORCBSZWRpcmVjdA0KPiA+IGZ1bmN0aW9uLiBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9u IHRoZSBsaXN0Lg0KPiA+DQo+ID4gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20N Cj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSS1ELUFubm91 bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMDYsIDIw MTcgMTo1MiBQTQ0KPiA+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBJ LUQgQWN0aW9uOiBkcmFmdC10ZW1wbGluLWludGFyZWEtcmlvLXJlZGlyZWN0LTAwLnR4dA0KPiA+ DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ID4NCj4gPg0KPiA+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogUm91dGUgSW5mb3JtYXRpb24gT3B0aW9ucyBpbiBSZWRpcmVjdCBN ZXNzYWdlcw0KPiA+ICAgICAgICAgQXV0aG9yICAgICAgICAgIDogRnJlZCBMLiBUZW1wbGluDQo+ ID4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXRlbXBsaW4taW50YXJlYS1yaW8tcmVkaXJlY3Qt MDAudHh0DQo+ID4gCVBhZ2VzICAgICAgICAgICA6IDUNCj4gPiAJRGF0ZSAgICAgICAgICAgIDog MjAxNy0wMS0wNg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgVGhlIElQdjYgTmVpZ2hib3Ig RGlzY292ZXJ5IHByb3RvY29sIHByb3ZpZGVzIGEgUmVkaXJlY3QgZnVuY3Rpb24NCj4gPiAgICBh bGxvd2luZyByb3V0ZXJzIHRvIGluZm9ybSBob3N0cyBvZiBhIGJldHRlciBuZXh0IGhvcCBvbiB0 aGUgbGluaw0KPiA+ICAgIHRvd2FyZCB0aGUgZGVzdGluYXRpb24uICBUaGlzIGRvY3VtZW50IHNw ZWNpZmllcyBhIGJhY2t3YXJkLQ0KPiA+ICAgIGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBS ZWRpcmVjdCBmdW5jdGlvbiB0byBhbGxvdyByb3V0ZXJzIHRvDQo+ID4gICAgaW5jbHVkZSBmb3J3 YXJkaW5nIGluZm9ybWF0aW9uIHRoYXQgdGhlIHNvdXJjZSBjYW4gYXNzb2NpYXRlIHdpdGggdGhl DQo+ID4gICAgbmV4dCBob3AuDQo+ID4NCj4gPg0KPiA+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4taW50YXJlYS1yaW8tcmVkaXJlY3QvDQo+ID4NCj4gPiBU aGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi1pbnRhcmVhLXJpby1yZWRpcmVjdC0w MA0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4g Pg0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj4gPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJLUQt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ID4gSS1ELUFubm91bmNlQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gPiBJbnRl cm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0K PiA+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo+ID4NCj4g Pg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+IC4NCj4gPg0KDQo= From nobody Tue Jan 10 10:12: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 54307129D78 for ; Tue, 10 Jan 2017 10:12:12 -0800 (PST) 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 gqbbzJ1rZczU for ; Tue, 10 Jan 2017 10:12:10 -0800 (PST) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::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 5EFA2129D77 for ; Tue, 10 Jan 2017 10:12:10 -0800 (PST) Received: by mail-wj0-x22a.google.com with SMTP id kq3so41601422wjc.0 for ; Tue, 10 Jan 2017 10:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=c6g/2QY/3uJp7PD4UhwMPAs5zzqzj4l8jq4sFDSjkxE=; b=TZcJQpuxxkrT5dCfG+84Bp8vdSeF62KFmjPYAOPXddYUEnXSr4dFKy+RMc9CtKaVji LMiK0GLyuWfjQszSEwER3h4eOI3vOd8ptLyGPMyWPwj9nAVc2hIK1NkGCgD276Z4lRHP cvpa2nxZu4mb1oYFQBWpR76+ew5wN4Hv8dqDt5KHUbNyS36YbH6gW3mi8TV+GV2hSv97 01IeKvox9v0nCyRSin50wyBMx/lknG7HQxqkFEhEYRLYuigVq50bLQIuHmlrVMQbUBSs /Srk/KxKt7DyOEYTne+A9W3FsPzXy+Mg4jeQP5Ugv2PyZeveg8oSbEEotbem8446LiDI WgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=c6g/2QY/3uJp7PD4UhwMPAs5zzqzj4l8jq4sFDSjkxE=; b=jiBsIhxL/bw7YuPnqf77bMbo54ZgLlHdSb3WlvNBRvWpL1XCGWWrbchXfO4/ILoIde Vc2S3RP24+TBedoJNtrodPW72SP9kNtv7SmE5mRxGrk060LM2JDAa0FppsXPntGVaqx+ TjdQ6Wm+e4R+pkQmec5kyUdN282tOe/6Sw95bS7BnIj+NkIQo8gydcUiTJuzY7/UxOpC 2EVAAa35FXS83mduNx4CvxbCPA0+sPqrqRR2sKgolmfhzDbwBPScHNQmaTmYL7IqWGJI bSAdVKMr1P5dYagbELvAhX489exDjJRFveqN5poFDtohOB4vbi7vhtIichbrA4V7Ks9r GdtQ== X-Gm-Message-State: AIkVDXIt/UUIaYbO7X5U3Rp30tDLLjf7qJMDQ6MEH9rozlF0O2Bx1psjUvF7mItuqqBzGA== X-Received: by 10.194.0.97 with SMTP id 1mr1892191wjd.223.1484071928798; Tue, 10 Jan 2017 10:12:08 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:9484:498c:2a79:f755? ([2601:647:4d01:db10:9484:498c:2a79:f755]) by smtp.gmail.com with ESMTPSA id js10sm4494357wjb.19.2017.01.10.10.12.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 10:12:07 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B7CD6F82-7B96-4079-B49E-834AC9066468"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: RFC6085 update to rfc2464bis From: Bob Hinden In-Reply-To: Date: Tue, 10 Jan 2017 10:12:01 -0800 Message-Id: <76C7F51B-4025-4741-BAFC-E98BF6AEEAC7@gmail.com> References: To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:12:12 -0000 --Apple-Mail=_B7CD6F82-7B96-4079-B49E-834AC9066468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei-san, > On Jan 10, 2017, at 9:26 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Mon, 9 Jan 2017 13:53:54 -0800, > Bob Hinden wrote: >=20 >>> 7. Address Mapping -- Multicast >>>=20 >>> An IPv6 packet with a multicast destination address DST, = consisting >>> of the sixteen octets DST[1] through DST[16], is transmitted to = the >>> Ethernet multicast address whose first two octets are the value = 3333 >>> hexadecimal and whose last four octets are the last four octets of >>> DST. >>>=20 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | DST[13] | DST[14] | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | DST[15] | DST[16] | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> An IPv6 multicast packet may also be mapped to a unicast Ethernet >> Link layer address as defined in Section 6. >=20 > I think it's more helpful to refer to RFC6085 explicitly here. > Otherwise the proposed text looks good to me. RFC6085 doesn=E2=80=99t actually say very much. The only real content = in Section 3: 3. Receiving IPv6 Multicast Packets An IPv6 node receiving an IPv6 packet with a multicast destination address and an Ethernet link-layer unicast address MUST NOT drop the packet as a result of the use of this form of address mapping. There is some text in the Introduction that says more: This document extends this mapping to explicitly allow for a mapping of an IPv6 packet with a multicast destination address into an Ethernet link- layer unicast address, when it is clear that only one address is relevant. Unfortunately, there isn=E2=80=99t anything like that in the main part = of the document. I will add an informational reference to RFC6085, but I don=E2=80=99t = think it helps very much. Thanks, Bob >=20 >> An IPv6 node receiving an IPv6 packet with a multicast destination >> address and an Ethernet link-layer unicast address must not drop = the >> packet as a result using of this form of address mapping. >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_B7CD6F82-7B96-4079-B49E-834AC9066468 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYdSPyAAoJEK7rdBF357uoYPIH/1N+PPrnmWG+8HACd5799E9j ougjpQSCTK+K4ePMm1pM9KQlRjLE7eDHqz/0f/DTZVCEhNiQ/RfufBIfVg1IWlV2 uKfB1uAwyIODN3SyXBibSX3Z9E4oVaiVCdpIzajuTGjY3PmLbuepaKUL6sMC6V7N 91xXCp1Hyky8hbhGqH1+t7+m+F7Pokz6pbprQySDKgnFtd2bff90wG61p6mievA6 NJgavOZkRhTg8XJ1aM3M9hZW79XImj7HluXa59RgraJB8Y7SWgwWbYhr7R5YTuev J8Uf8L9FwPhQGV4h8F/vDOl7+sr+Rzq+xKjfm4rHtGn0eUOnfaeYCIvkNA6BBb4= =ZPnY -----END PGP SIGNATURE----- --Apple-Mail=_B7CD6F82-7B96-4079-B49E-834AC9066468-- From nobody Tue Jan 10 11:22: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 330B612956E for ; Tue, 10 Jan 2017 11:22:55 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 rLWzds6Q-7vF for ; Tue, 10 Jan 2017 11:22:53 -0800 (PST) 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 5FABE12952C for ; Tue, 10 Jan 2017 11:22:53 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id 11so86800736qkl.3 for ; Tue, 10 Jan 2017 11:22:53 -0800 (PST) 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=ehz/ES9osGB+HxelEGm8p8iL4P2P5LdNbl++/oOT5cI=; b=iz4ZrFaOAUiRyKpuaD7dNhWT3myT4aCGg6JoLjElZug1YiP3gk/JN5y2EZlA9m13vN cFCPRwfV2nnUBWPyLdiSE25TzuSZbm+TiiW1MRGNNR8UkLG2aMmzO8J68AgUFmAJL98c Hpj3yEAREil5lDkYYKil73uDzNykj+EHeJu3g4RO6KF89FoWGvO+RqjhVTGrv5MKNGZC jip00Iotrgh7Is/HHCplZT6gdJQvMQes2jpYuqH8AW6KZSLn2mVmRG7B8QgsovbaEm0X Rjp0JbQG4Jc0jbmMYG+F19z2OaE+7iwz3zf1hfz4uI2EjmUudpRNKo7Jx/WO/9ONXcae OsOw== 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=ehz/ES9osGB+HxelEGm8p8iL4P2P5LdNbl++/oOT5cI=; b=uU9xRgmMncwB9EKlDncKu7Dc2Y+cuuDsmpGhHNxKsYRiq39iNcSPAbIwX3V1MVjc29 dfGfpV/lBYp0k9W60GQe/0qN5D9xfwNFeNI+nyz375U4Ee6MB03J70tjFh+xxA2Z7zYz xfWZbr9PYxThTZo8Bd+6NxuypanIew/yP9beW9rHD81tS8d1Avqh5rpwfEndO+ylgpCf fll4F5QclYbu9wC4zcX+KGohHYcmz51dKPpZ9PMQ1ALzHrY0URUs0HcbzZ83VZkB29e2 Mp1XsLIU6CnzZgUXIIR1d0BkcDZdckXgdvqo9TCIRb8RdixNSzIUnYtEtlbaPLk8e2xA LjLQ== X-Gm-Message-State: AIkVDXLu4eVaBkFJR1gvCJ7hmThLecM8WbfzkFAmWT5hH2jZKsg5ppOwcT5iTDyyaHUPMeMALXXGrit5iBYqMA== X-Received: by 10.55.161.11 with SMTP id k11mr4467449qke.149.1484076172484; Tue, 10 Jan 2017 11:22:52 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 10 Jan 2017 11:22:52 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 10 Jan 2017 11:22:52 -0800 X-Google-Sender-Auth: XuB1J_e5QFfQn7lALM7jbZNfP90 Message-ID: Subject: Re: RFC6085 update to rfc2464bis To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:22:55 -0000 On Tue, Jan 10, 2017 at 9:26 AM wrote: >> An IPv6 multicast packet may also be mapped to a unicast Ethernet >> Link layer address as defined in Section 6. > > I think it's more helpful to refer to RFC6085 explicitly here. > Otherwise the proposed text looks good to me. On re-reading it more closely, I wonder whether "as defined in Section 6" may not be very appropriate. RFC6085 intentionally left the mapping open: [...] The determination of the unicast Ethernet link-layer address and the construction of the outgoing IPv6 packet are out of scope for this document. but I suspect it doesn't really intend to perform link-layer address resolution using ND (which is in my understanding what "Section 6" talks about) to determine the unicast Ethernet address. In fact, the address resolution itself uses a multicast IPv6 address, which is derived from the target unicast IPv6 address. So it would be a kind of circular definition. So it's probably even better to just refer to the RFC instead of Section 6: An IPv6 multicast packet may also be mapped to a unicast Ethernet Link layer address as noted in [RFC6085]. And, for that matter, this text of Section 6 of rfc2464bis-01 now looks a bit awkward to me: The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [DISC]. On reading both Sections 6 and 7, this "the procedure for mapping" could read some static mapping whereas it should actually refer to dynamic link-layer address resolution. I suggest revising the first paragraph from: The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Ethernet. to: When the link layer is Ethernet, the Ethernet address for an IPv6 unicast address is resolved using the address resolution protocol as defined in [DISC]. The Source/Target Link-layer Address option used in that protocol has the following form. -- JINMEI, Tatuya From nobody Tue Jan 10 11:31: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 23B7C12984A for ; Tue, 10 Jan 2017 11:31:48 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 lkOFggAkmTZ5 for ; Tue, 10 Jan 2017 11:31:46 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C821297D0 for ; Tue, 10 Jan 2017 11:31:46 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u25so569606965qki.2 for ; Tue, 10 Jan 2017 11:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=xxRnMUEiKL7SJo9q4NShaXusHT/+tohqoqYPFn0JY/A=; b=Jx3l+U1piMNObD9FiI8dq2DfkkxlPgjclh9uzSxov2LYSEY6MK9KkSNR1CU5WJPtaF hCl62SqHHXnOUCPp2koCp/DiAff/UiUo+w9Ee6fXQQ0WtAgADMBP7McoPEgWLKXYKRJc wmiJlJkGinhSR3LW8YxGclNjMwOsZv3JEUyJ0N20IHk5iUsXA+EOZC8ZtV0+uR1LunsI HAYpbT/a5z7VYxwunKKe99LFGmyXfiGcWeRymAn3ZuI+WWHTzXBGbMus6ihs3xPgiL43 xJwThtiq1/Mcmytn355HVM+lJ1Ti+jSMvNbQgtDURIMZi/7zPq+MnUCbDZoqySoj00Q/ kDLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=xxRnMUEiKL7SJo9q4NShaXusHT/+tohqoqYPFn0JY/A=; b=B/wrkSiJSDXfBtV75PCWHn2lX2h0h+mCDhDnQlcLAif0tfljjCF3yotQrSPN0D+RY4 LOrEiWp2oHhG62s6J3/U9q0u51sDQ42Cci/46S08kNzF+nADM+fEqRj0K06p6cFtXkRT gIR+mk3zDOmEVs29shfr0DvnE195KiauJx2C7FurM9dQIDkAUm2UJqaWSc03NxzzdSDS VdgXun1/H6rDNulu/Ib4JAkErtSgcGArWgU4Lz8B+9EmiCOXCCikqUeIpob7LJIF4N84 XW32GKBtbUeNGIqkRopvpbvBfxqnF6/qTRPiwweXgMzOhSWJKChTwwiHQ9C3lCDFIn0y Sa2A== X-Gm-Message-State: AIkVDXJOGJ3/YP/xXfPsvDREP61M3zQZFexBfDPAXGCCg5qR7FqUjiPlnGi4ZkWHu5pxIoO48RG9iI66nMB75w== X-Received: by 10.55.161.11 with SMTP id k11mr4507545qke.149.1484076705727; Tue, 10 Jan 2017 11:31:45 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Tue, 10 Jan 2017 11:31:45 -0800 (PST) In-Reply-To: <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> References: <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 10 Jan 2017 11:31:45 -0800 X-Google-Sender-Auth: UZ_FKO1L-HgGQ8Mc0cIePpxxHu8 Message-ID: Subject: Re: Errata for RFC4862 To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:31:48 -0000 At Tue, 10 Jan 2017 12:45:27 +0000, Tim Chown wrote: > My recollection of running renumbering experiments is that it=E2=80=99s t= he > Preferred Lifetime that matters, i.e. when that is set to zero for a > prefix, the prefix is marked as deprecated. So when renumbering, > you run with two prefixes advertised, old and new, setting the > Preferred Lifetime to 0 on the old prefix (even though the Valid > Lifetime is set to 2+ hours), so that the address with the new > prefix is used for newly initiated communications (as per RFC 6724, > Rule 3). Yes, but I guess what Ole tried to point out (which I agree with) is that the valid lifetime will also have to decrease to 0 eventually, and this original text of RFC4862 allows such decrease operation without requiring explicit authentication if done by gradually: > >> 1. If the received Valid Lifetime is greater than 2 hours or > >> greater than RemainingLifetime, set the valid lifetime of the > >> corresponding address to the advertised Valid Lifetime. -- JINMEI, Tatuya From nobody Tue Jan 10 11:34:23 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548E51297F7 for ; Tue, 10 Jan 2017 11:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 5d2fNgY7rQiP for ; Tue, 10 Jan 2017 11:34:20 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 B3420129810 for ; Tue, 10 Jan 2017 11:34:20 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cR2BW-0007B1-Td for ipv6@ietf.org; Tue, 10 Jan 2017 20:34:20 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cR2BV-0006tL-Ju for ipv6@ietf.org; Tue, 10 Jan 2017 14:34:18 -0500 Received: (qmail 17091 invoked from network); 10 Jan 2017 19:34:16 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.38.224]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2017 19:34:15 -0000 From: "Christian Huitema" To: "'Templin, Fred L'" , "'Brian E Carpenter'" , "'6man WG'" , "'INT Area'" References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> Date: Tue, 10 Jan 2017 11:34:13 -0800 Message-ID: <016f01d26b78$870895a0$9519c0e0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKeae7mTqXBJ6n75yoSm6nUsujvkwJ1WP8UAkBARrSfdG2IUA== Content-Language: en-us Subject: RE: [Int-area] Route Information Options in Redirect Messages X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrc3vlP8pRiJgjg3CVCjOFCRcOb18WfxGyg6Om6u4YYm3qZJQMepvPPpzcv WDN4JaM5hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpFxQRCdMNhge1Unb77YyuZq4bWWffs2Yib4Zd08Wtmt5fRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYBZFdS8D5uDWm/DZ32iizeAeYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8t3mZf Rol6mHiNmEqclWWZ59BqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:34:22 -0000 On Tuesday, January 10, 2017 9:55 AM, Fred Templin wrote: > ... > What is being proposed in the document I submitted is the inclusion of > RIOs in Redirect messages for a *prefix* that is not on-link, as opposed > to a singleton destination. So, the same SHOULD in the paragraph above > would seem to apply also to prefix redirection the same as for ordinary > destination redirection. Fred, I am reading the security section of your draft. I think it needs a bit more work. Currently, the RIO are only expected in router advertisements. RA are somewhat special, and there is often specific code in switches to check RA and prevent RA spoofing -- e.g., RA-Guard. Allowing the option in Redirect messages could very well bypass the RA specific checks. Doesn't that open the path for new attacks? Should you not say something about that in the security section? How about specific mitigations, such as sanity checks when processing redirect messages? -- Christian Huitema From nobody Tue Jan 10 13:45: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 9D76B1295BE for ; Tue, 10 Jan 2017 13:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G45RJ3SUwl3 for ; Tue, 10 Jan 2017 13:45:50 -0800 (PST) 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 D7F1E129DAB for ; Tue, 10 Jan 2017 13:45:49 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so44194174vke.2 for ; Tue, 10 Jan 2017 13:45:49 -0800 (PST) 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=hghfPEPVEqegBRZVAh6DRPjxVWYGEyTJn0r2VEkhO8I=; b=WOWWqGxAx+K3KME2We5KHeBLcjyVTADGSS8SveRaDrtyANZ3DaCxX3nDbt03TVnU9q Iz4J9E2e4NuV2J1OHi+HH1fzy71mHRU93973H/jGxL+pZiqJeXqpGaQoIXz52Et8ROnM Zg3cGNMKfj+Bmw+FGOE5ss0Ycns1HJCJlBPa8IrN5Ng0GczTWWiTg+4mggrpnVWT0oiC U2iuX8J+Vb7n5kxgtCFu6N8WIqyPLMC2HOWvti5mvSNsm7JJYt76HTSomUw+2L/ZZ6Kj hMPKcGY8QJBDnYQuO0JK6lG5DZ7G5di5Tma6w+zvDk7fXegpOYOTII/vwGXI/U04j7V+ /BkA== 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=hghfPEPVEqegBRZVAh6DRPjxVWYGEyTJn0r2VEkhO8I=; b=bbVkO0l6wAO1uNI4xXi67D0rKffBnmyN0doEYpVuXv5XNvwYQ0I2e9M8tO2UsEYjU6 pwGa6vTn9PMBGTBLCaAtLaa0ldvdN6uzQ6WwpJVm+XwfpMNLGSekMT7QoCneBHdbmcgF iV0XZwkyKgzPV99lQNcAK4yHLmh89gUdl8dftv2ejzeGpeOyrbOsRL6Ph5j3BiWIvLHN yZZL5Fbor+WKaMvP6CCeg8wErw7dA7D29BSFI3bD4hU9TjljJKSvwx2KCv+xrrUa9O1I lOqlLCimJzrevSL4mMrzj/W6errVIme+z8jLLbrAcFSezQ/0mfCWF8osarswCKyTYF9H toHg== X-Gm-Message-State: AIkVDXJUkLdIijB8aUBUztKacsuEwMNxXebHdyqXbqyqrbHBGbQ2+L1nv2LNNPd8GVCB5pHcVRRLpidyZTtlxg== X-Received: by 10.31.238.6 with SMTP id m6mr2186472vkh.28.1484084748909; Tue, 10 Jan 2017 13:45:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Tue, 10 Jan 2017 13:45:48 -0800 (PST) Received: by 10.176.2.235 with HTTP; Tue, 10 Jan 2017 13:45:48 -0800 (PST) In-Reply-To: References: <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> From: Mark Smith Date: Wed, 11 Jan 2017 08:45:48 +1100 Message-ID: Subject: Re: Errata for RFC4862 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c14971446b8480545c468b7 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:45:51 -0000 --94eb2c14971446b8480545c468b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 Jan. 2017 6:32 am, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: At Tue, 10 Jan 2017 12:45:27 +0000, Tim Chown wrote: > My recollection of running renumbering experiments is that it=E2=80=99s t= he > Preferred Lifetime that matters, i.e. when that is set to zero for a > prefix, the prefix is marked as deprecated. So when renumbering, > you run with two prefixes advertised, old and new, setting the > Preferred Lifetime to 0 on the old prefix (even though the Valid > Lifetime is set to 2+ hours), so that the address with the new > prefix is used for newly initiated communications (as per RFC 6724, > Rule 3). Yes, but I guess what Ole tried to point out (which I agree with) is that the valid lifetime will also have to decrease to 0 eventually, and this original text of RFC4862 allows such decrease operation without requiring explicit authentication if done by gradually: If that is the case (and I don't think it is, it creates the DoS opportunity that all other >2 hr checks attempt to defeat), then I think it needs to be far better and more explicitly explained, including the sequence of events. What is the use case that can't be achieved by setting the preferred lifetime to zero, immediately deprecating the addresses (and a VL of 2 hours to cause them to disappear shortly). If it is to remove addresses immediately from a host by setting the RA PIO VL to zero - actually that's not going to work, because seeing VL to zero will fail the greater than remaining time check. It would be very laborious to try to remove an address by only being able to send a VL greater than the address's remaining time. Letting the address age out/expire naturally by itself by stopping sending the RA PIO for the prefix wolf be easier and I think quicker. Regards, Mark. > >> 1. If the received Valid Lifetime is greater than 2 hours or > >> greater than RemainingLifetime, set the valid lifetime of the > >> corresponding address to the advertised Valid Lifetime. -- JINMEI, Tatuya -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --94eb2c14971446b8480545c468b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 11 Jan. 2017 6:32 am, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89" <jinmei@wide.ad.jp>= ; wrote:
At Tue, 10 Jan 20= 17 12:45:27 +0000,
Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> My recollection of running renumbering experiments is that it=E2=80=99= s the
> Preferred Lifetime that matters, i.e. when that is set to zero for a > prefix, the prefix is marked as deprecated.=C2=A0 So when renumbering,=
> you run with two prefixes advertised, old and new, setting the
> Preferred Lifetime to 0 on the old prefix (even though the Valid
> Lifetime is set to 2+ hours), so that the address with the new
> prefix is used for newly initiated communications (as per RFC 6724, > Rule 3).

Yes, but I guess what Ole tried to point out (which I agree with) is<= br> that the valid lifetime will also have to decrease to 0 eventually,
and this original text of RFC4862 allows such decrease operation
without requiring explicit authentication if done by gradually:

If that is the case (and I don't thi= nk it is, it creates the DoS opportunity that all other >2 hr checks att= empt to defeat), then I think it needs to be far better and more explicitly= explained, including the sequence of events.

What is the use case that can't be achieved by se= tting the preferred lifetime to zero, immediately deprecating the addresses= (and a VL of 2 hours to cause them to disappear shortly).

If it is to remove addresses immediately= from a host by setting the RA PIO VL to zero - actually that's not goi= ng to work, because seeing VL to zero will fail the greater than remaining = time check.

It would be = very laborious to try to remove an address by only being able to send a VL = greater than the address's remaining time. Letting the address age out/= expire naturally by itself by stopping sending the RA PIO for the prefix wo= lf be easier and I think quicker.=C2=A0

Regards,=C2=A0
Mark.


> >>=C2=A0 =C2=A0 =C2=A01.=C2=A0 If the received Valid Lifetime is= greater than 2 hours or
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0greater than RemainingLifeti= me, set the valid lifetime of the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0corresponding address to the= advertised Valid Lifetime.


--
JINMEI, Tatuya

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

--94eb2c14971446b8480545c468b7-- From nobody Tue Jan 10 13:53:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5D129DD1; Tue, 10 Jan 2017 13:53:08 -0800 (PST) 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 83tiZodYdhKj; Tue, 10 Jan 2017 13:53:07 -0800 (PST) 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 93948129554; Tue, 10 Jan 2017 13:53:07 -0800 (PST) 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 v0ALr7ug002311; Tue, 10 Jan 2017 14:53:07 -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 v0ALqvn7002129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2017 14:52:57 -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.1178.4; Tue, 10 Jan 2017 13:52:56 -0800 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.1178.000; Tue, 10 Jan 2017 13:52:56 -0800 From: "Templin, Fred L" To: Christian Huitema , "'Brian E Carpenter'" , "'6man WG'" , "'INT Area'" Subject: RE: [Int-area] Route Information Options in Redirect Messages Thread-Topic: [Int-area] Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAeC3cAABhBxNAAFKbugAAMs3RQ Date: Tue, 10 Jan 2017 21:52:56 +0000 Message-ID: <6d21dd17f0b94a39a71600944878ec39@XCH15-06-08.nw.nos.boeing.com> References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> <016f01d26b78$870895a0$9519c0e0$@huitema.net> In-Reply-To: <016f01d26b78$870895a0$9519c0e0$@huitema.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:53:09 -0000 Hi Christian, > -----Original Message----- > From: Christian Huitema [mailto:huitema@huitema.net] > Sent: Tuesday, January 10, 2017 11:34 AM > To: Templin, Fred L ; 'Brian E Carpenter' ; '6man WG' ; > 'INT Area' > Subject: RE: [Int-area] Route Information Options in Redirect Messages >=20 > On Tuesday, January 10, 2017 9:55 AM, Fred Templin wrote: > > ... > > What is being proposed in the document I submitted is the inclusion of > > RIOs in Redirect messages for a *prefix* that is not on-link, as oppose= d > > to a singleton destination. So, the same SHOULD in the paragraph above > > would seem to apply also to prefix redirection the same as for ordinary > > destination redirection. >=20 > Fred, I am reading the security section of your draft. I think it needs a > bit more work. >=20 > Currently, the RIO are only expected in router advertisements. RA are > somewhat special, and there is often specific code in switches to check R= A > and prevent RA spoofing -- e.g., RA-Guard. Allowing the option in Redirec= t > messages could very well bypass the RA specific checks. Doesn't that open > the path for new attacks? Should you not say something about that in the > security section? How about specific mitigations, such as sanity checks w= hen > processing redirect messages? Since IP will still operate correctly if transmission of Redirect messages = is somehow suppressed (i.e., denial of Redirect service), the more serious threat to be considered is spoofing. Here is what currently appears under Security Considerations: "Security considerations for Redirect messages that include RIOs are the same as for any IPv6 ND messages as specified in Section 11 of [RFC4861]. Namely, the protocol must take measures to secure IPv6 ND messages on links where spoofing attacks are possible. A spoofed Redirect message containing no RIOs could cause corruption in the host's destination cache while a spoofed Redirect message containing RIOs could corrupt the host's routing tables. While the latter would seem to be a more onerous result, the possibility for corruption is unacceptable in either case." So, from the first paragraph, we can see that the protocol must take measures to secure IPv6 ND messages on links where spoofing attacks are possible. The second paragraph then analyzes the consequences of what could happen if a spoofing attack were successful and we see that there are unacceptable negative consequences for both traditional Redirects and Redirects that include RIOs. The text stops short of saying that "no Redirects of any kind should be used on links where spoofing attacks are possible". Would adding a statement such as this address the concern? Thanks - Fred fred.l.templin@boeing.com From nobody Tue Jan 10 16:05: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 714B61295F6 for ; Tue, 10 Jan 2017 16:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5CDvBZ9Knmw for ; Tue, 10 Jan 2017 16:05:43 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE11129426 for ; Tue, 10 Jan 2017 16:05:42 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id c7so52868313itd.1 for ; Tue, 10 Jan 2017 16:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gBUUPet53bXB/CzGw6jZcSYGsFibVg8VEbgv6xTYXKI=; b=Yh4ZxrurEa+xUh/mvYXOiaxdTdfceOFIQ0SvJ7TNzHgem3bthAn4wvO6ZeDYhZLg4P dGg0tvUaKlFPYHw7PqdutFiSoFnDez0rQQMX9ZnHiRJRAqbQ4rTUrAbLvkwvausYv6ox 6dxGEkw2CW5Kr5u1z5F5T0HSsPRC8DFBcVFXPZ23XGCfd7ZJkRPnnZgtQDSsjbhCOMjW D84JrCIqfOtomeDnv/lAjkgPsKd/RHzYTEfxZsb7TwShXXla0IiuiLUy8x7uAlm7Sd65 okQc1jM3aXlGhDa41gZcbfMZy0z2Eu5eYAEI8E8/2LRuSV2uVPW791PHfKRvtUAtAgP5 C5Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gBUUPet53bXB/CzGw6jZcSYGsFibVg8VEbgv6xTYXKI=; b=V82JvXQDh9f/Up9g0upHrpZaMAhjNwd+bxf9iK8AM3PLZT7zpWOiPiHNDUOblcMye5 Fi7owEsUmfJKtKklwAOoT42ZlEOFzJskq8BAGH+U4afRtblp/mqxNcZmkHQpiDH2XiRt o53dOj4SuzEvuns0BhEts6r2oyZNRF3MPQEKKAqxVBo0Rpf3473dbWtwwQ01MutGRQMq tShvpAA039fdJJiILo61i8RN3Etpjb4eoff7jMV20sLqc7fVDP9lUzkDo/JbOdK6d8a+ wE4eR8K4iWRU8rG+emaBJ3mZVGWznHcmeje504sTqE+PasJt0XOlsvoYcD/vYBhY73u7 qcqw== X-Gm-Message-State: AIkVDXLxVmpyN0jNy/Xp6OiXzK/yZAudv1R8OObmMP2jjbJcEDcuBp3t8lYYQZGHoPFPVQ== X-Received: by 10.36.175.23 with SMTP id t23mr2579040ite.18.1484093141989; Tue, 10 Jan 2017 16:05:41 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g190sm2146933ioe.30.2017.01.10.16.05.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 16:05:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_7E7C779C-EBDA-4D7F-BB05-67600931CA52"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: RFC6085 update to rfc2464bis From: Bob Hinden In-Reply-To: Date: Tue, 10 Jan 2017 16:05:39 -0800 Message-Id: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> References: To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:05:44 -0000 --Apple-Mail=_7E7C779C-EBDA-4D7F-BB05-67600931CA52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei-san, > On Jan 10, 2017, at 11:22 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > On Tue, Jan 10, 2017 at 9:26 AM wrote: >=20 >>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>> Link layer address as defined in Section 6. >>=20 >> I think it's more helpful to refer to RFC6085 explicitly here. >> Otherwise the proposed text looks good to me. >=20 > On re-reading it more closely, I wonder whether "as defined in Section > 6" may not be very appropriate. RFC6085 intentionally left the > mapping open: >=20 > [...] The determination of the unicast Ethernet link-layer > address and the construction of the outgoing IPv6 packet are out of > scope for this document. >=20 > but I suspect it doesn't really intend to perform link-layer address > resolution using ND (which is in my understanding what "Section 6" > talks about) to determine the unicast Ethernet address. In fact, the > address resolution itself uses a multicast IPv6 address, which is > derived from the target unicast IPv6 address. So it would be a kind > of circular definition. >=20 > So it's probably even better to just refer to the RFC instead of > Section 6: >=20 > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as noted in [RFC6085]. I think the problem remains that RFC6085 isn=E2=80=99t very clear how to = do that. Pointing to RFC6085 is that it doesn=E2=80=99t say what to do = :-( It would be good to hear from the authors of RFC6085. Also, what is = current practice. >=20 > And, for that matter, this text of Section 6 of rfc2464bis-01 now > looks a bit awkward to me: >=20 > The procedure for mapping IPv6 unicast addresses into Ethernet link- > layer addresses is described in [DISC]. That is original text from RFC2464. I tried to avoid changing anything = that wasn=E2=80=99t part of an update or errata. >=20 > On reading both Sections 6 and 7, this "the procedure for mapping" > could read some static mapping whereas it should actually refer to > dynamic link-layer address resolution. >=20 > I suggest revising the first paragraph from: >=20 > The procedure for mapping IPv6 unicast addresses into Ethernet link- > layer addresses is described in [DISC]. The Source/Target = Link-layer > Address option has the following form when the link layer is > Ethernet. >=20 > to: >=20 > When the link layer is Ethernet, the Ethernet address for an IPv6 > unicast address is resolved using the address resolution protocol > as defined in [DISC]. The Source/Target Link-layer Address option > used in that protocol has the following form. I find that an improvement (maybe without the =E2=80=9CWhen=E2=80=9D = text), but I am not sure a change is needed. Thanks, Bob >=20 > -- > JINMEI, Tatuya --Apple-Mail=_7E7C779C-EBDA-4D7F-BB05-67600931CA52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEbBAEBCgAGBQJYdXbTAAoJEK7rdBF357uokNgH+L/4oeNPF3DMjLup7+J4zxk4 iJFv538L999/BhiWvJmprUWNLNPPGkfaLZyRWEawJxw8R6GYQGX5No/OSjB7o3RY 6/ChWYrqhjqTSb949SqHYRaOkX1au7IrYCjL/gyp+b0e3d/wftNo81TDbwc6/Osj KxzBHJBjXzEAWk5Cpr8SlcsygqXsGtij/UfGS9kzF7yc56OPL+ubWWB845Z6dZHR VdMmq/saj35UoHhihAVzYAq/xHZsd4nAJYAx3WtAZTR0u3D1LEgSTg8b8rIe9SWg I2ctkhUx9PZ0sFB6Mvgtt6hTrXtzOfqy3QuwjdwRiJXrYKnSNR7MBKDj1XuL1A== =AdV9 -----END PGP SIGNATURE----- --Apple-Mail=_7E7C779C-EBDA-4D7F-BB05-67600931CA52-- From nobody Tue Jan 10 16:48: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 C1C251296A0; Tue, 10 Jan 2017 16:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28sb3QfnPVK3; Tue, 10 Jan 2017 16:48:22 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952DF129642; Tue, 10 Jan 2017 16:48:19 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id q186so14600112itb.1; Tue, 10 Jan 2017 16:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5hSK+HWimDLvWja1Ndt7Aj85zsyCrx0ugM/z8GhdpZ4=; b=iHBo8vXXWVPzIgerCrKt6/GUpFMNx8jXFThtGd4yT0dXW9Gr1dlrlyNjmCa9b/XWl9 SqND/mqH0AWkZDlkR7HdiNL+/rMReqldbxDD2b4nhxFrYfi1uU1GBWG/SHoHBQF/YGX0 YqgijPQHu4w08jkBBNLq9UQcZZ9IZT9agj98ir8kgKmxUPnoAEzFzzhTeYtcJOvUmYS2 0ajNB80hUgab8dj26ZtNRR9hDTf3TfA29lN6JX4PFdEHCoSEGj07Mo/yDtz2mbm+twIq Xk4fR8SwdAcPzuvxxYHwqmNvYIMuysAuukAWd6jxWtOL1AngJaQNDAdoTh6D54Sx7xgs ysUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5hSK+HWimDLvWja1Ndt7Aj85zsyCrx0ugM/z8GhdpZ4=; b=n3dz/vw7UgWDbm+43NCkQFNqWhaVQ2+MGq4gEbc6cXWC4Bp0YL56hnK8xDNASRMYkB v57ICzBhjKaNLOn6m48O1DrwIncZFeFAmGRjLPHIQc4forz7KtDKCpNPxbF+9QCpYaCm W9JL5mRjJ4OZjBw/9moqUsP/AtmcCkjAVcJNKxECK/OIrvs8L+3llSeUJ/MIGJuAv5az 4Kp0q4YxuZWc8dT1txNemkmh9iR9D4CQG8oFYtVNJH0NZ03cUJ0aJ5qkL/L+g4cOb1eH 3vuAQatLWJDLlymxegmL2ZsgYGilCKFR2Pxm8Yz4SPMEs8oyZzpa2kHyGeAfHRF+C6MV pr3Q== X-Gm-Message-State: AIkVDXJ4upYsBBa2j3Ck2bhmpQFr6kMarYC1xjLOVHoxuo0mLCUoomd/vI0qbrWVHDtbmg== X-Received: by 10.36.216.70 with SMTP id b67mr5971921itg.5.1484095698855; Tue, 10 Jan 2017 16:48:18 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a23sm9082324itb.11.2017.01.10.16.48.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 16:48:17 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 From: Bob Hinden In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 16:48:15 -0800 Message-Id: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> To: Brian Haberman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , Bob Hinden , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:48:23 -0000 --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, Thanks for the review! > On Jan 10, 2017, at 8:32 AM, Brian Haberman = wrote: >=20 > Reviewer: Brian Haberman > Review result: Ready with Nits >=20 > I just have a few comments/questions on this draft. Overall, it is in > pretty good shape... >=20 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? I didn=E2=80=99t include a direct reference in the Section as = incorporates the changes, but it is included in Appendix B describing = the changes. No current intent to deprecate RFC5952 as it updates RFC4291. I don=E2=80= =99t see very much value in deprecating (Historic?) the updating RFCs. >=20 > 2. Section 2.6.1 captures some information about reserved IPv6 > multicast addresses, but not all of them. I think it would be > beneficial to point to the IPv6 Multicast Address Allocation registry > maintained by IANA, much like the way Section 2.3 points to the IANA > registries. That makes sense. Something like a new paragraph at the end of the = section like: Additional defined multicast address can be found in the IANA IPv6 = Multicast Address Allocation registry [XXX] XXX: = http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-ad= dresses.xhtml. >=20 > 3. Also in Section 2.6.1, the names of reserved addresses, like "All > Nodes Addresses", were made all lowercase. Was that intentional? Given > that IANA refers to them with capitalization, it would seem that we > need to be consistent. So, I would either retain the capitalization in > this document or ensure that Section 3 directs IANA to update the > names in the registries. It was capitalized in RFC4291. It looks like the change was introduced = in draft-hinden-6man-rfc4291bis-01. I think may have been accidentally = part of changing the text addresses to lower case as part of the RFC5952 = update. I agree it should be the way it was in RFC4291. Will change. Thanks, Bob --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYdYDQAAoJEK7rdBF357uoxNUH/0X0TiQzDX+Okc+KqDA193zx CRE1i6Did5E8nxJBxYpneCTPMz4gAFuqJGrIxileo9ULr/9utnqCWAOjzNM9ROeh 6FcshV+z5DazDroTEY+OsxTxLkvPOYzV3jSpky+FrA85OeS1eniWtRXbiAh5POTU y8oh/Q/Uo5UhaeQjKSwUYegM822rTEI+wqD+DVzjEjEbj4uf4ZFbxaGnfyxnv199 RQ906BAQCt08ZJas7K7TRlSyMHpw1iIaxukmR+iq2n4pi7byZlm3ObuYQq2FtnDW qNCINzt1KILpSmXVKiGGgZN2V1SmyZJrWRgQWXPjW1tvnbTjhrPrftQKigL0nvs= =io8B -----END PGP SIGNATURE----- --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F-- From nobody Tue Jan 10 17: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 E328D12963D; Tue, 10 Jan 2017 17:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 xEM-MP8rTVC4; Tue, 10 Jan 2017 17:52:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F931295A3; Tue, 10 Jan 2017 17:52:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cR85q-00039A-OG; Wed, 11 Jan 2017 01:52:51 +0000 Date: Wed, 11 Jan 2017 10:52:48 +0900 Message-ID: From: Randy Bush To: Brian Haberman Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, ipv6@ietf.org, ietf@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 01:52:53 -0000 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? 5952 has much more very useful detail for those of us who write software to parse, compare, ... textual representations of ipv6 addresses, see section 4 of 5952. so i suggest the replacement of 2.2 with a reference to 5952. it is very cheering to see section 2.4.0, "96 more bits no magic" [credit gaurab]. but i am having a hard time reconciling 2.4.4's insistence on a mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc 6141, widespread operational practice, ... clue bat please. randy From nobody Tue Jan 10 18:24: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 9F62712944A; Tue, 10 Jan 2017 18:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ-LIR1OGM6x; Tue, 10 Jan 2017 18:23:57 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFDA1293DF; Tue, 10 Jan 2017 18:23:57 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 127so56836054pfg.1; Tue, 10 Jan 2017 18:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hXLqjo1IsBo1IkWd5hi/4SyXhHErN+k6tH907hdOVzg=; b=o9I8CXmgPnQDjA8qo0deIEssdT2S1aOwbM8y+3A1dqDHrJsF3nF+tdtUYyLAZKF8Hh zRlskyQ02GiwB/ii8zl+WQvHvNeeHosqlZwZEoDz0LunRL/X/B9uhbCl8FBX6MdnMeDK xMFy9k1pwbHsx2i8EShCzclQsHvBPIGa971t8+6XDEl00LlSuEF78N0A2e6Bs5lj1zHq jQLWkLMW5uu0GYMykelleAl/isxe1G60KolEkXKsDi6VXe9KJvTf+5cOJZdaEAle9Dxm 3bi+Ok5W1HyLZg1a4zMlWgBmx9pzBxJyvhyE/ulJuZTeIOHORZHJlHbE2BpNWXSnD6tq FRZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hXLqjo1IsBo1IkWd5hi/4SyXhHErN+k6tH907hdOVzg=; b=U38W+ajFvHcmswCVCip802VrrMoGoZA4zi5U8GiSuvQHTQjQVIGIe/CPucoWMFIVrj VuYLNgxTkXil7+NNJnD6tyHdyYmztDZtqd29ulaOuh/uIsH6cE5p03DoZCCBcZt2lqcn V9jdTHEwHdx3pPjSgFjVqmbBObRXN/eWHfsPGMl5/Y4kU6+Rx985x2ZWh7UXP1mPrPGK A5QEu8yzwXcC4e+BGB+/kHR6+Zgd/W5AcYnRLy067Bt9A/px0QfAH9vDQXH2zVDQGlAZ KbTRnBm3eBnvE1hGag64Avq/qtZ8MAJT4B/fCv9Ho7PnUATkrz7+lTkF1+IdTqyUNurU TPYQ== X-Gm-Message-State: AIkVDXIFIdZy1qUdqQw7/5cmbTWGSzrnwh5Kw0xyU3Dyxoi0qUU75CwtZOIdzvfcTGJWrA== X-Received: by 10.98.91.130 with SMTP id p124mr7299544pfb.173.1484101436729; Tue, 10 Jan 2017 18:23:56 -0800 (PST) Received: from ?IPv6:2406:e007:575f:1:28cc:dc4c:9703:6781? ([2406:e007:575f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e127sm8682300pfh.89.2017.01.10.18.23.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 18:23:56 -0800 (PST) Subject: Re: Route Information Options in Redirect Messages To: "Templin, Fred L" , 6man WG , INT Area References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 11 Jan 2017 15:23:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 02:23:58 -0000 On 11/01/2017 06:55, Templin, Fred L wrote: > Hi Brian, > > I am looking at the section that says: > > "3.4. Redirects > There is potential for adverse interaction with any off-link Redirect > (Redirect for a destination that is not on-link) message sent by a > router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply > off-link redirects only for the specific pair of source and > destination addresses concerned, so the host's Destination Cache > might need to contain appropriate source-specific entries. This > extends the validity check specified in Section 8.1 of [RFC4861]." > > What is being proposed in the document I submitted is the inclusion of > RIOs in Redirect messages for a *prefix* that is not on-link, as opposed > to a singleton destination. So, the same SHOULD in the paragraph above > would seem to apply also to prefix redirection the same as for ordinary > destination redirection. I didn't want to bias your reading, but that was my conclusion too. If correct, maybe your draft needs to cite RFC8028 and augment it accordingly. Regards Brian > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, January 09, 2017 2:08 PM >> To: Templin, Fred L ; 6man WG >> Subject: Re: Route Information Options in Redirect Messages >> >> Fred, >> >> Can you check that there would be no adverse interaction with RFC8028, >> especially https://tools.ietf.org/html/rfc8028#section-3.4 >> >> Regards >> Brian >> >> On 10/01/2017 04:51, Templin, Fred L wrote: >>> See below for a new draft that proposes to update RFC4861 and RFC4191 to >>> permit the inclusion of Route Information Options in Redirect Messages. >>> This represents a backward-compatible extension to the IPv6 ND Redirect >>> function. Please review and comment on the list. >>> >>> Fred >>> fred.l.templin@boeing.com >>> >>> -----Original Message----- >>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>> Sent: Friday, January 06, 2017 1:52 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-templin-intarea-rio-redirect-00.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> >>> Title : Route Information Options in Redirect Messages >>> Author : Fred L. Templin >>> Filename : draft-templin-intarea-rio-redirect-00.txt >>> Pages : 5 >>> Date : 2017-01-06 >>> >>> Abstract: >>> The IPv6 Neighbor Discovery protocol provides a Redirect function >>> allowing routers to inform hosts of a better next hop on the link >>> toward the destination. This document specifies a backward- >>> compatible extension to the Redirect function to allow routers to >>> include forwarding information that the source can associate with the >>> next hop. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-templin-intarea-rio-redirect/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-templin-intarea-rio-redirect-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 >>> -------------------------------------------------------------------- >>> . >>> > From nobody Wed Jan 11 01:48: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 CF232129AE7 for ; Wed, 11 Jan 2017 01:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k60sjyPlTYNk for ; Wed, 11 Jan 2017 01:48:50 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 97B06129AE9 for ; Wed, 11 Jan 2017 01:48:47 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 11 Jan 2017 09:48:47 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BC4A29CC7E; Wed, 11 Jan 2017 01:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=eIvOGulJLhOI/lhJKo5QhKa5QvI=; b=OTzA5ce03D9Kd2Kps/ gYeNkV6aH650JQR5W9VX7hiBrcW89x2TWaymJXTfBh5CAoP29rQxBdmfP19+XECQ 6qIEArDZ6NAhHU8FCVNZ2+9Wxzl21Jr1vK8VoGrDWgknN1c83xUuiJ0XOHuIvn2g s9H6Cn/YfZR5IvJAjnqJd9CvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=lC3+ZVR9TxiXbDPr6/J811ZACZjiwYEifB8KHeg+hruU7yBc3+J jXWUzAyv5LMgjRVSHWNX+k3IL0RvCW0HizsUrfFomorwGwLWMQJWWIOk4Quovy/g b5QNhNj5BmS6obxjNkPhKoiCnAkKLD1RmFGogGl8xAZwCzyewyZ5mbLk= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5BFE59CC7C; Wed, 11 Jan 2017 01:48:46 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A24FA7450CE7; Wed, 11 Jan 2017 10:48:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC6085 update to rfc2464bis From: otroan@employees.org In-Reply-To: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> Date: Wed, 11 Jan 2017 10:48:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:48:52 -0000 Bob, Jinmei, As one of the authors of RFC6085 let me try to clarify how it would = typically be used. Scenario: Wireless AP that already knows the L2 unicast address of all = stations on a link. Some APs try to improve on IPv6 multicast on wireless by sending the RAs = as L2 unicast to each individual station. The AP then runs through it's list of L2 unicast addresses and sends the = multicast RA with the given L2 unicast mapping. 2464bis says: An IPv6 multicast packet may also be mapped to a unicast Ethernet Link layer address as defined in Section 6. An IPv6 node receiving an IPv6 packet with a multicast destination address and an Ethernet link-layer unicast address must not drop the packet as a result using of this form of address mapping. As Jinmei also says, referring to section 6 is then wrong. That implies = that the 6085 address mapping uses address resolution. Which is not the = case. 6085 is indeed very underspecified in stating how the mapping is done, = from 6085: The determination of the unicast Ethernet link-layer address and the construction of the outgoing IPv6 packet are out of scope for this document. Either do (Jinmei):=20 An IPv6 multicast packet may also be mapped to a unicast Ethernet Link layer address as described in RFC6085. Or something like: An IPv6 packet with a multicast destination address may also be mapped = to an=20 Ethernet link-layer unicast address [RFC6085]. E.g. when it is clear that only one address is relevant on the link = and that the mapping between an IPv6 multicast destination address and an Ethernet = link-layer unicast address is already known. Cheers, Ole > On 11 Jan 2017, at 01:05, Bob Hinden wrote: >=20 > Jinmei-san, >=20 >> On Jan 10, 2017, at 11:22 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >>=20 >> On Tue, Jan 10, 2017 at 9:26 AM wrote: >>=20 >>>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>>> Link layer address as defined in Section 6. >>>=20 >>> I think it's more helpful to refer to RFC6085 explicitly here. >>> Otherwise the proposed text looks good to me. >>=20 >> On re-reading it more closely, I wonder whether "as defined in = Section >> 6" may not be very appropriate. RFC6085 intentionally left the >> mapping open: >>=20 >> [...] The determination of the unicast Ethernet link-layer >> address and the construction of the outgoing IPv6 packet are out of >> scope for this document. >>=20 >> but I suspect it doesn't really intend to perform link-layer address >> resolution using ND (which is in my understanding what "Section 6" >> talks about) to determine the unicast Ethernet address. In fact, the >> address resolution itself uses a multicast IPv6 address, which is >> derived from the target unicast IPv6 address. So it would be a kind >> of circular definition. >>=20 >> So it's probably even better to just refer to the RFC instead of >> Section 6: >>=20 >> An IPv6 multicast packet may also be mapped to a unicast Ethernet >> Link layer address as noted in [RFC6085]. >=20 > I think the problem remains that RFC6085 isn=E2=80=99t very clear how = to do that. Pointing to RFC6085 is that it doesn=E2=80=99t say what to = do :-( >=20 > It would be good to hear from the authors of RFC6085. Also, what is = current practice. >=20 >>=20 >> And, for that matter, this text of Section 6 of rfc2464bis-01 now >> looks a bit awkward to me: >>=20 >> The procedure for mapping IPv6 unicast addresses into Ethernet link- >> layer addresses is described in [DISC]. >=20 > That is original text from RFC2464. I tried to avoid changing = anything that wasn=E2=80=99t part of an update or errata. >=20 >>=20 >> On reading both Sections 6 and 7, this "the procedure for mapping" >> could read some static mapping whereas it should actually refer to >> dynamic link-layer address resolution. >>=20 >> I suggest revising the first paragraph from: >>=20 >> The procedure for mapping IPv6 unicast addresses into Ethernet link- >> layer addresses is described in [DISC]. The Source/Target = Link-layer >> Address option has the following form when the link layer is >> Ethernet. >>=20 >> to: >>=20 >> When the link layer is Ethernet, the Ethernet address for an IPv6 >> unicast address is resolved using the address resolution protocol >> as defined in [DISC]. The Source/Target Link-layer Address option >> used in that protocol has the following form. >=20 > I find that an improvement (maybe without the =E2=80=9CWhen=E2=80=9D = text), but I am not sure a change is needed. >=20 > Thanks, > Bob >=20 >=20 >>=20 >> -- >> JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jan 11 06:26: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 34B41129482 for ; Wed, 11 Jan 2017 06:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsvAGZIwsnvU for ; Wed, 11 Jan 2017 06:26:11 -0800 (PST) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B94D129ED6 for ; Wed, 11 Jan 2017 06:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1484144767; bh=AuIV8wUwqZyvgQhhhvgTy/YATXvuD5sYW7HsKXCOUAE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dYGPCzsdnSPRqzWNzXqtSH3teFRKgIzvGXGizw0p0bWg7CMB/7MP4UlganZoCbqhisi6CokhMrbgFxf4VRucka+ySgz9IGQTf9hnl0UW0ZamuYwqDV4W4sBD4utR97LFfqlazkMg/QKwDygKet2j1KUfGb68yJ11JT8M8+GscbUOoaxb+ok5iRV3NTs4tA7iMu9HNPIhEpRNjFLv1Q9eeVXtlgEngozJPDyO+UR9GOMtAnBAxsnCrVRa2sAoJIbZCsnEExzSlQHueLOJgTOYY3wkZyq7uWIaVEzjlaMOHkrlWNtBxM8d1HYu7TQXEA9+mQEj0LoyQk33HY4ScsHBKg== Received: from [66.196.81.172] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 Received: from [98.139.212.196] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 430819.38444.bm@omp1005.mail.bf1.yahoo.com X-YMail-OSG: ftQlEeAVM1nKlahdpEuPGdrLc7d8S02fF_77IG.fWmADHe5G.2wvwnjRMWGU4SR Jn3xO6VkTDN3tyxctUB0_VfMDc2u_qaF_eJmMkpl0w_wwVX5jdNfMPQFiIqpFJVzoRQsadf3LsLO iEfUZ4vH7x3ZIeqnjXf8m6rLWLBPGL9ymC.RP3r7nN0M9XWzCZn_5elKkvCAhJprxucaHZbGS6.c nCkoA6.fTKZIz7ggdryFDYCrzdpwT9wVcztnjq4NiqtRWk90dlZ4tOlB_y4fd6eJUkGzKNhv2r8R oby6jtrWdICDjW2dFqCHrGIvhVTxmf1bBPmv5y9LBVp_ZMnay0jGaOHH0RFZFW.fqaXIVIuz9bJ5 JxwXkF5VeGblSt1bT2pluF6bUchFIHVoB_OjyuhvPXY8Se26swKPMb4rxUv0rf6VyToalWRseM2l M9Pv8G6rVyWmUeG7vMG.tirJN._7llhYCdKen0qlZDuOqcGFsOxSccD3R5ypx5.tQea2V4b75Y3j er7wHurqg0BQ8DEQXMLa_ Received: from jws400085.mail.bf2.yahoo.com by sendmailws151.mail.bf1.yahoo.com; Wed, 11 Jan 2017 14:26:07 +0000; 1484144767.031 Date: Wed, 11 Jan 2017 14:24:34 +0000 (UTC) From: Punana Lebo To: Brian Haberman , "int-dir@ietf.org" Message-ID: <1817689823.74706.1484144674522@mail.yahoo.com> In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_74705_1375753992.1484144674520" Archived-At: Cc: "ipv6@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc4291bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Punana Lebo List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:26:12 -0000 ------=_Part_74705_1375753992.1484144674520 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello=C2=A0I am new to this and I hope my comment is appropriate=C2=A0The e= xamples in recommendation 7 and 8 in section 2.2.3 have been swapped. In ot= her words, an example given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 = should be shown as ::ffff:192.0.2.1) must be=C2=A0 for recommendation 8 (20= 01:0db8:0000:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd3= 0::/60) and vise versa.=C2=A0Regards=C2=A0Keolebogile=C2=A0=C2=A0=20 On Tuesday, January 10, 2017 6:32 PM, Brian Haberman wrote: =20 Reviewer: Brian Haberman Review result: Ready with Nits I just have a few comments/questions on this draft. Overall, it is in pretty good shape... 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but I don't see a reference to 5952. Is the intent to deprecate 5952 since its content is now contained within 4291bis? 2. Section 2.6.1 captures some information about reserved IPv6 multicast addresses, but not all of them. I think it would be beneficial to point to the IPv6 Multicast Address Allocation registry maintained by IANA, much like the way Section 2.3 points to the IANA registries. 3. Also in Section 2.6.1, the names of reserved addresses, like "All Nodes Addresses", were made all lowercase. Was that intentional? Given that IANA refers to them with capitalization, it would seem that we need to be consistent. So, I would either retain the capitalization in this document or ensure that Section 3 directs IANA to update the names in the registries. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ------=_Part_74705_1375753992.1484144674520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello
 
I am new to this and I ho= pe my comment is appropriate
 
The examples in recommend=
ation 7 and 8 in section 2.2.3 have been swapped. In other words, an exampl=
e given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 should be shown as :=
:ffff:192.0.2.1) must be  for recommendation 8 (2001:0db8:00=
00:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd30::/60) an=
d vise versa.
 =

Regards
 
Keolebogile
 =
 


On Tuesday, January 10, 2017 6:32 PM, Brian Haberman <= brian@innovationslab.net> wrote:


Reviewer: Brian Haberman
Review result: Ready with = Nits

I just have a few comments/questions on this draft. Overall, it= is in
pretty good shape...

1. Section 2.2.3 looks like a complet= e re-production of RFC 5952, but
I don't see a reference to 5952. Is the= intent to deprecate 5952 since
its content is now contained within 4291= bis?

2. Section 2.6.1 captures some information about reserved IPv6<= br>multicast addresses, but not all of them. I think it would be
benefic= ial to point to the IPv6 Multicast Address Allocation registry
maintaine= d by IANA, much like the way Section 2.3 points to the IANA
registries.<= br>
3. Also in Section 2.6.1, the names of reserved addresses, like "All=
Nodes Addresses", were made all lowercase. Was that intentional? Given<= br>that IANA refers to them with capitalization, it would seem that we
n= eed to be consistent. So, I would either retain the capitalization in
th= is document or ensure that Section 3 directs IANA to update the
names in= the registries.

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

------=_Part_74705_1375753992.1484144674520-- From nobody Wed Jan 11 07:32: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 DB1711294EC; Wed, 11 Jan 2017 07:32:25 -0800 (PST) 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] 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 O9YQ6YRtGqvV; Wed, 11 Jan 2017 07:32:24 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC73F1294C5; Wed, 11 Jan 2017 07:32:24 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D679388124; Wed, 11 Jan 2017 07:32:24 -0800 (PST) Received: from clemson.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2768C3280AE3; Wed, 11 Jan 2017 07:32:24 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Bob Hinden References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> From: Brian Haberman Message-ID: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Date: Wed, 11 Jan 2017 10:32:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF" Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:32:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF Content-Type: multipart/mixed; boundary="KRSBGSPanMVkVfqXogoCt06H25rjrgRPc"; protected-headers="v1" From: Brian Haberman To: Bob Hinden Cc: int-dir@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc4291bis.all@ietf.org Message-ID: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> In-Reply-To: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> --KRSBGSPanMVkVfqXogoCt06H25rjrgRPc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 1/10/17 7:48 PM, Bob Hinden wrote: > Brian, >=20 > Thanks for the review! >=20 >> On Jan 10, 2017, at 8:32 AM, Brian Haberman >> wrote: >>=20 >> Reviewer: Brian Haberman Review result: Ready with Nits >>=20 >> I just have a few comments/questions on this draft. Overall, it is >> in pretty good shape... >>=20 >> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, >> but I don't see a reference to 5952. Is the intent to deprecate >> 5952 since its content is now contained within 4291bis? >=20 > I didn=E2=80=99t include a direct reference in the Section as incorpora= tes > the changes, but it is included in Appendix B describing the > changes. >=20 > No current intent to deprecate RFC5952 as it updates RFC4291. I > don=E2=80=99t see very much value in deprecating (Historic?) the updati= ng > RFCs. I will agree with Randy that there is useful info in 5952 that people need to see. Adding a reference to 5952 here would point people in the right direction. Regards, Brian --KRSBGSPanMVkVfqXogoCt06H25rjrgRPc-- --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYdlAHAAoJEBOZRqCi7goqHvoH/2R+eAfKkMxsRLgYCtJtmQmo dd7fTJuLbtUyXzdnut3AfYEt4NvfIap3WCYcjQh0qjnJZ8x+HudeFVZgCQEnR8Be EQ2pa7pIPBYPKykc/2hv+SRC91eCjjiWIX/RY0qm1s6JLHS1ozQMm4KfPYHPo1Cn 6NLMSymAw3WOhzqsSVMmpzE2hGOg9i312TqjdFX+PK4c9KAnWqxM2EvAP98KK0aB 2MI+bWnr+bBHFr/Gg+zByYxziT8v8yTAi39jOjfzgo3Sge4lNqJOPpC7djj2Yg7Z ygyNQRXdqC9P4ubHOy5ZwkUqtIBn+iRGP/rL8y6fFg8CVV45RbMOm44lM/QrqvQ= =oQ0c -----END PGP SIGNATURE----- --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF-- From nobody Wed Jan 11 09:14: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 28DD2129D0C; Wed, 11 Jan 2017 09:14:38 -0800 (PST) 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 pf2fNEZotCcW; Wed, 11 Jan 2017 09:14:35 -0800 (PST) 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 F3C07129666; Wed, 11 Jan 2017 09:14:34 -0800 (PST) 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 v0BHEXXf024657; Wed, 11 Jan 2017 10:14:34 -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 v0BHEUsD024626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2017 10:14:30 -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.1178.4; Wed, 11 Jan 2017 09:14:29 -0800 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.1178.000; Wed, 11 Jan 2017 09:14:29 -0800 From: "Templin, Fred L" To: Brian E Carpenter , 6man WG , INT Area Subject: RE: Route Information Options in Redirect Messages Thread-Topic: Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAeC3cAABhBxNAAIvXvgAAOSDPg Date: Wed, 11 Jan 2017 17:14:28 +0000 Message-ID: <3f70ffee241f4413892a2b691235fbcd@XCH15-06-08.nw.nos.boeing.com> References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:14:38 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTcgNjoyNCBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IElO VCBBcmVhIDxpbnQtYXJlYUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFJvdXRlIEluZm9ybWF0 aW9uIE9wdGlvbnMgaW4gUmVkaXJlY3QgTWVzc2FnZXMNCj4gDQo+IE9uIDExLzAxLzIwMTcgMDY6 NTUsIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToNCj4gPiBIaSBCcmlhbiwNCj4gPg0KPiA+IEkgYW0g bG9va2luZyBhdCB0aGUgc2VjdGlvbiB0aGF0IHNheXM6DQo+ID4NCj4gPiAiMy40LiAgUmVkaXJl Y3RzDQo+ID4gICAgVGhlcmUgaXMgcG90ZW50aWFsIGZvciBhZHZlcnNlIGludGVyYWN0aW9uIHdp dGggYW55IG9mZi1saW5rIFJlZGlyZWN0DQo+ID4gICAgKFJlZGlyZWN0IGZvciBhIGRlc3RpbmF0 aW9uIHRoYXQgaXMgbm90IG9uLWxpbmspIG1lc3NhZ2Ugc2VudCBieSBhDQo+ID4gICAgcm91dGVy IGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDggb2YgW1JGQzQ4NjFdLiAgSG9zdHMgU0hPVUxE IGFwcGx5DQo+ID4gICAgb2ZmLWxpbmsgcmVkaXJlY3RzIG9ubHkgZm9yIHRoZSBzcGVjaWZpYyBw YWlyIG9mIHNvdXJjZSBhbmQNCj4gPiAgICBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgY29uY2VybmVk LCBzbyB0aGUgaG9zdCdzIERlc3RpbmF0aW9uIENhY2hlDQo+ID4gICAgbWlnaHQgbmVlZCB0byBj b250YWluIGFwcHJvcHJpYXRlIHNvdXJjZS1zcGVjaWZpYyBlbnRyaWVzLiAgVGhpcw0KPiA+ICAg IGV4dGVuZHMgdGhlIHZhbGlkaXR5IGNoZWNrIHNwZWNpZmllZCBpbiBTZWN0aW9uIDguMSBvZiBb UkZDNDg2MV0uIg0KPiA+DQo+ID4gV2hhdCBpcyBiZWluZyBwcm9wb3NlZCBpbiB0aGUgZG9jdW1l bnQgSSBzdWJtaXR0ZWQgaXMgdGhlIGluY2x1c2lvbiBvZg0KPiA+IFJJT3MgaW4gUmVkaXJlY3Qg bWVzc2FnZXMgZm9yIGEgKnByZWZpeCogdGhhdCBpcyBub3Qgb24tbGluaywgYXMgb3Bwb3NlZA0K PiA+IHRvIGEgc2luZ2xldG9uIGRlc3RpbmF0aW9uLiBTbywgdGhlIHNhbWUgU0hPVUxEIGluIHRo ZSBwYXJhZ3JhcGggYWJvdmUNCj4gPiB3b3VsZCBzZWVtIHRvIGFwcGx5IGFsc28gdG8gcHJlZml4 IHJlZGlyZWN0aW9uIHRoZSBzYW1lIGFzIGZvciBvcmRpbmFyeQ0KPiA+IGRlc3RpbmF0aW9uIHJl ZGlyZWN0aW9uLg0KPiANCj4gSSBkaWRuJ3Qgd2FudCB0byBiaWFzIHlvdXIgcmVhZGluZywgYnV0 IHRoYXQgd2FzIG15IGNvbmNsdXNpb24gdG9vLiBJZg0KPiBjb3JyZWN0LCBtYXliZSB5b3VyIGRy YWZ0IG5lZWRzIHRvIGNpdGUgUkZDODAyOCBhbmQgYXVnbWVudCBpdCBhY2NvcmRpbmdseS4NCg0K WWVzLCBjZXJ0YWlubHkgaXQgbWFrZXMgc2Vuc2UgdG8gY2l0ZSBSRkM4MDI4LCBhbmQgdGhlIG5l eHQgZG9jdW1lbnQgdmVyc2lvbg0Kd2lsbCBkbyB0aGF0LiBUaGFua3MgdmVyeSBtdWNoIGZvciBw b2ludGluZyB0aGlzIG91dC4NCg0KRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+ IFJlZ2FyZHMNCj4gICAgIEJyaWFuDQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZy ZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVu dGVyQGdtYWlsLmNvbV0NCj4gPj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDA5LCAyMDE3IDI6MDgg UE0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47 IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBSb3V0ZSBJbmZvcm1h dGlvbiBPcHRpb25zIGluIFJlZGlyZWN0IE1lc3NhZ2VzDQo+ID4+DQo+ID4+IEZyZWQsDQo+ID4+ DQo+ID4+IENhbiB5b3UgY2hlY2sgdGhhdCB0aGVyZSB3b3VsZCBiZSBubyBhZHZlcnNlIGludGVy YWN0aW9uIHdpdGggUkZDODAyOCwNCj4gPj4gZXNwZWNpYWxseSBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODAyOCNzZWN0aW9uLTMuNA0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ICAg IEJyaWFuDQo+ID4+DQo+ID4+IE9uIDEwLzAxLzIwMTcgMDQ6NTEsIFRlbXBsaW4sIEZyZWQgTCB3 cm90ZToNCj4gPj4+IFNlZSBiZWxvdyBmb3IgYSBuZXcgZHJhZnQgdGhhdCBwcm9wb3NlcyB0byB1 cGRhdGUgUkZDNDg2MSBhbmQgUkZDNDE5MSB0bw0KPiA+Pj4gcGVybWl0IHRoZSBpbmNsdXNpb24g b2YgUm91dGUgSW5mb3JtYXRpb24gT3B0aW9ucyBpbiBSZWRpcmVjdCBNZXNzYWdlcy4NCj4gPj4+ IFRoaXMgcmVwcmVzZW50cyBhIGJhY2t3YXJkLWNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBJ UHY2IE5EIFJlZGlyZWN0DQo+ID4+PiBmdW5jdGlvbi4gUGxlYXNlIHJldmlldyBhbmQgY29tbWVu dCBvbiB0aGUgbGlzdC4NCj4gPj4+DQo+ID4+PiBGcmVkDQo+ID4+PiBmcmVkLmwudGVtcGxpbkBi b2VpbmcuY29tDQo+ID4+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ IEZyb206IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+PiBTZW50OiBGcmlk YXksIEphbnVhcnkgMDYsIDIwMTcgMTo1MiBQTQ0KPiA+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRm Lm9yZw0KPiA+Pj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtdGVtcGxpbi1pbnRhcmVhLXJp by1yZWRpcmVjdC0wMC50eHQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJvdXRl IEluZm9ybWF0aW9uIE9wdGlvbnMgaW4gUmVkaXJlY3QgTWVzc2FnZXMNCj4gPj4+ICAgICAgICAg QXV0aG9yICAgICAgICAgIDogRnJlZCBMLiBUZW1wbGluDQo+ID4+PiAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtdGVtcGxpbi1pbnRhcmVhLXJpby1yZWRpcmVjdC0wMC50eHQNCj4gPj4+IAlQYWdl cyAgICAgICAgICAgOiA1DQo+ID4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wMS0wNg0KPiA+ Pj4NCj4gPj4+IEFic3RyYWN0Og0KPiA+Pj4gICAgVGhlIElQdjYgTmVpZ2hib3IgRGlzY292ZXJ5 IHByb3RvY29sIHByb3ZpZGVzIGEgUmVkaXJlY3QgZnVuY3Rpb24NCj4gPj4+ICAgIGFsbG93aW5n IHJvdXRlcnMgdG8gaW5mb3JtIGhvc3RzIG9mIGEgYmV0dGVyIG5leHQgaG9wIG9uIHRoZSBsaW5r DQo+ID4+PiAgICB0b3dhcmQgdGhlIGRlc3RpbmF0aW9uLiAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgYSBiYWNrd2FyZC0NCj4gPj4+ICAgIGNvbXBhdGlibGUgZXh0ZW5zaW9uIHRvIHRoZSBSZWRp cmVjdCBmdW5jdGlvbiB0byBhbGxvdyByb3V0ZXJzIHRvDQo+ID4+PiAgICBpbmNsdWRlIGZvcndh cmRpbmcgaW5mb3JtYXRpb24gdGhhdCB0aGUgc291cmNlIGNhbiBhc3NvY2lhdGUgd2l0aCB0aGUN Cj4gPj4+ICAgIG5leHQgaG9wLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4taW50YXJlYS1yaW8tcmVkaXJlY3QvDQo+ ID4+Pg0KPiA+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQo+ID4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi1pbnRhcmVh LXJpby1yZWRpcmVjdC0wMA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQo+ID4+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPiA+Pj4NCj4gPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QN Cj4gPj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gPj4+IEludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQo+ID4+PiBvciBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ ID4+PiBpcHY2QGlldGYub3JnDQo+ID4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+Pj4gLg0KPiA+Pj4NCj4gPg0KDQo= From nobody Wed Jan 11 10:58:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E78A129D62 for ; Wed, 11 Jan 2017 10:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q9dCrTMu4wuF for ; Wed, 11 Jan 2017 10:57:59 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16696129D53 for ; Wed, 11 Jan 2017 10:57:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v0BIvtWE009234 for ; Wed, 11 Jan 2017 19:57:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E4D2620CE68 for ; Wed, 11 Jan 2017 19:57:55 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DEEE120CD68 for ; Wed, 11 Jan 2017 19:57:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v0BIvtNu016495 for ; Wed, 11 Jan 2017 19:57:55 +0100 Subject: Re: RFC6085 update to rfc2464bis To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <13c5524c-bcc4-dfe1-867b-2580316f09a7@gmail.com> Date: Wed, 11 Jan 2017 19:57:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 18:58:01 -0000 Has one witnessed a packet dump of IPv6-over-wired-Ethernet (not WiFi) featuring a dst _IP multicast_ address with the dst _MAC unicast_ address? Alex Le 09/01/2017 22:53, Bob Hinden a crit : > Hi, > > Based on update from RFC6085 I added two paragraphs to Section 7 of . These are: > >> 7. Address Mapping -- Multicast >> >> An IPv6 packet with a multicast destination address DST, consisting >> of the sixteen octets DST[1] through DST[16], is transmitted to the >> Ethernet multicast address whose first two octets are the value 3333 >> hexadecimal and whose last four octets are the last four octets of >> DST. >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DST[13] | DST[14] | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DST[15] | DST[16] | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. > > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. > > While RFC6085 isnt exactly clear about the change it wants in RFC2464, I think this is about right. > > Comments? > > Thanks, > Bob > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jan 11 11:00: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 BDEF2129D77 for ; Wed, 11 Jan 2017 11:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cipikJSQ7_CU for ; Wed, 11 Jan 2017 11:00:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75C81296FD for ; Wed, 11 Jan 2017 11:00:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v0BJ02kM009621 for ; Wed, 11 Jan 2017 20:00:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A26A20CEBB for ; Wed, 11 Jan 2017 20:00:02 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F2F220CE88 for ; Wed, 11 Jan 2017 20:00:02 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v0BJ01Oq017563 for ; Wed, 11 Jan 2017 20:00:02 +0100 Subject: Re: RFC6085 update to rfc2464bis - Ethernet or WiFi? To: ipv6@ietf.org References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> From: Alexandre Petrescu Message-ID: <9a42adb5-92ea-d1f8-66f8-7da7b101cf0b@gmail.com> Date: Wed, 11 Jan 2017 20:00:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:00:05 -0000 Le 11/01/2017 à 10:48, otroan@employees.org a écrit : > Bob, Jinmei, > > As one of the authors of RFC6085 let me try to clarify how it would typically be used. > Scenario: Wireless AP This is WiFi, it is not Ethernet. It is not the same. An IPv6-over-WiFi document remains to be written. This multicast aspect is the tip of the iceberg of differences between the two. Alex > that already knows the L2 unicast address of all stations on a link. > Some APs try to improve on IPv6 multicast on wireless by sending the RAs as L2 unicast to each individual station. > The AP then runs through it's list of L2 unicast addresses and sends the multicast RA with the given L2 unicast mapping. > > 2464bis says: > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. > > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. > > > As Jinmei also says, referring to section 6 is then wrong. That implies that the 6085 address mapping uses address resolution. Which is not the case. > > 6085 is indeed very underspecified in stating how the mapping is done, from 6085: > The determination of the unicast Ethernet link-layer > address and the construction of the outgoing IPv6 packet are out of > scope for this document. > > > Either do (Jinmei): > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as described in RFC6085. > > Or something like: > An IPv6 packet with a multicast destination address may also be mapped to an > Ethernet link-layer unicast address [RFC6085]. > E.g. when it is clear that only one address is relevant on the link and that the > mapping between an IPv6 multicast destination address and an Ethernet link-layer > unicast address is already known. > > Cheers, > Ole > > > >> On 11 Jan 2017, at 01:05, Bob Hinden wrote: >> >> Jinmei-san, >> >>> On Jan 10, 2017, at 11:22 AM, 神明達哉 wrote: >>> >>> On Tue, Jan 10, 2017 at 9:26 AM wrote: >>> >>>>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>>>> Link layer address as defined in Section 6. >>>> >>>> I think it's more helpful to refer to RFC6085 explicitly here. >>>> Otherwise the proposed text looks good to me. >>> >>> On re-reading it more closely, I wonder whether "as defined in Section >>> 6" may not be very appropriate. RFC6085 intentionally left the >>> mapping open: >>> >>> [...] The determination of the unicast Ethernet link-layer >>> address and the construction of the outgoing IPv6 packet are out of >>> scope for this document. >>> >>> but I suspect it doesn't really intend to perform link-layer address >>> resolution using ND (which is in my understanding what "Section 6" >>> talks about) to determine the unicast Ethernet address. In fact, the >>> address resolution itself uses a multicast IPv6 address, which is >>> derived from the target unicast IPv6 address. So it would be a kind >>> of circular definition. >>> >>> So it's probably even better to just refer to the RFC instead of >>> Section 6: >>> >>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>> Link layer address as noted in [RFC6085]. >> >> I think the problem remains that RFC6085 isn’t very clear how to do that. Pointing to RFC6085 is that it doesn’t say what to do :-( >> >> It would be good to hear from the authors of RFC6085. Also, what is current practice. >> >>> >>> And, for that matter, this text of Section 6 of rfc2464bis-01 now >>> looks a bit awkward to me: >>> >>> The procedure for mapping IPv6 unicast addresses into Ethernet link- >>> layer addresses is described in [DISC]. >> >> That is original text from RFC2464. I tried to avoid changing anything that wasn’t part of an update or errata. >> >>> >>> On reading both Sections 6 and 7, this "the procedure for mapping" >>> could read some static mapping whereas it should actually refer to >>> dynamic link-layer address resolution. >>> >>> I suggest revising the first paragraph from: >>> >>> The procedure for mapping IPv6 unicast addresses into Ethernet link- >>> layer addresses is described in [DISC]. The Source/Target Link-layer >>> Address option has the following form when the link layer is >>> Ethernet. >>> >>> to: >>> >>> When the link layer is Ethernet, the Ethernet address for an IPv6 >>> unicast address is resolved using the address resolution protocol >>> as defined in [DISC]. The Source/Target Link-layer Address option >>> used in that protocol has the following form. >> >> I find that an improvement (maybe without the “When” text), but I am not sure a change is needed. >> >> Thanks, >> Bob >> >> >>> >>> -- >>> JINMEI, Tatuya >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jan 11 11:07: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 9E08F129F4F for ; Wed, 11 Jan 2017 11:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-sthcFDYewb for ; Wed, 11 Jan 2017 11:07:44 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 CBDBF129F45 for ; Wed, 11 Jan 2017 11:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v0BJ7ePK022754; Wed, 11 Jan 2017 20:07:40 +0100 (CET) Received: from [192.168.217.124] (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tzJLN3gTkz3Znq; Wed, 11 Jan 2017 20:07:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC6085 update to rfc2464bis - Ethernet or WiFi? From: Carsten Bormann In-Reply-To: <9a42adb5-92ea-d1f8-66f8-7da7b101cf0b@gmail.com> Date: Wed, 11 Jan 2017 20:07:39 +0100 X-Mao-Original-Outgoing-Id: 505854459.883777-7204b1e19472d5c2838d00afa229adf4 Content-Transfer-Encoding: quoted-printable Message-Id: <3525D98F-E092-44F2-B3CC-03F4D621B69D@tzi.org> References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> <9a42adb5-92ea-d1f8-66f8-7da7b101cf0b@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:07:46 -0000 On 11 Jan 2017, at 20:00, Alexandre Petrescu = wrote: >=20 > This is WiFi, it is not Ethernet. It is not the same. An = IPv6-over-WiFi document remains to be written. That=E2=80=99s actually not true in real life. =E2=80=9CIPv6 over Ethernet=E2=80=9D in reality is a shorthand for = =E2=80=9CIPv6 over 802.1 bridged links that collectively try to look = like Ethernet but don=E2=80=99t always succeed very well=E2=80=9D. WiFi = is part of that world. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 11 11:11: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 EB4F1129F4D for ; Wed, 11 Jan 2017 11:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2BlaVCQNXFH for ; Wed, 11 Jan 2017 11:11:15 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94749129F4B for ; Wed, 11 Jan 2017 11:11:15 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id t8so53589368vke.3 for ; Wed, 11 Jan 2017 11:11:15 -0800 (PST) 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=o6C+445prl18oWjv/sLpv24CskeCC/A2gGv5Q3KKhjM=; b=Sg5Ubk2R73Nakdqt6t6ZszuZbSyAmxUFpju16gkg+dnMKQvkUoJk3jY+Zx1DH91pyI Y/zScg4QS+7S+n8rHaj/4yulNr3/ylg8xtPKN9X4IOjtc8i3JuWxu8gJ1b3McSVDCT+I vnyCFkONVgi0Jm5sCU6xzoAxskb64ff6bvNzlGUZQQ+Tee0uHY1PqP90iHsVn2of4M80 sXSnwTSdHanxKSXWx0fj8hzvKZmetXTXVyHCoM1VQdfPhB3/bQhx9H2H187Kd33jSH6S VGoE91Bra4AXT+wVOdhDklIc79/7vTiFa+4SItUpeG4i7XfkpA0XrGJomrCXS6oLwp9R RQzw== 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=o6C+445prl18oWjv/sLpv24CskeCC/A2gGv5Q3KKhjM=; b=aXfhIS+/FwA1jTRl95C5Ot+xD2xgDGhgpUjRp3EByPhEALOVL6qdYd/we0HxzBDtvK QCUdSFW3sIoH3kKf2Ap4DtHSSGIpIdOWAf2x8VAltnL9aT6H8TzeNkOd0F/++Wx/OxDE Aln3Q8AuduYpZ8eNOnBl01Ja8d/VFb+6/9KZZEPur7xvcsspL75PZf1AtgHU32thc8zy 79MErYKEsG5icoCykq7kl4ca1E6C+nk+on2pFqHOdB5pCEUOF7+iSyDvUtXLAKItx6DF v9D0Svcqd6vTPRT85V1P8W9hdoxGLk8MxJnUVxKhhnEUNmuvVMDK1avQzJ9GDZKjDo4Q ieZg== X-Gm-Message-State: AIkVDXLn3JZSUlyF+LQbikcIBzj6tkUBi0If1uHfEa5oI7O67LOaZ2BQEsM81gouyJhCqqIZbxHmv94lpyaM2g== X-Received: by 10.31.220.134 with SMTP id t128mr5016209vkg.143.1484161874475; Wed, 11 Jan 2017 11:11:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Wed, 11 Jan 2017 11:11:13 -0800 (PST) Received: by 10.176.2.235 with HTTP; Wed, 11 Jan 2017 11:11:13 -0800 (PST) In-Reply-To: References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> From: Mark Smith Date: Thu, 12 Jan 2017 06:11:13 +1100 Message-ID: Subject: Re: RFC6085 update to rfc2464bis To: Ole Troan Content-Type: multipart/alternative; boundary=94eb2c07ca8851417b0545d65df4 Archived-At: Cc: 6man WG , Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:11:18 -0000 --94eb2c07ca8851417b0545d65df4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I also wrote up a draft a few years back as to how MLDv2 in combination with Neighbor Discovery could use link layer unicast for multicast IPv6 traffic. MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6 https://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 I also saw this Linux bridge patch a few days ago which sounds like it does the same sort of thing and has apparently been enabled in OpenWRT on Wifi AP interfaces. https://patchwork.ozlabs.org/patch/710249/ Regards, Mark. On 11 January 2017 at 20:48, wrote: > Bob, Jinmei, > > As one of the authors of RFC6085 let me try to clarify how it would typically be used. > Scenario: Wireless AP that already knows the L2 unicast address of all stations on a link. > Some APs try to improve on IPv6 multicast on wireless by sending the RAs as L2 unicast to each individual station. > The AP then runs through it's list of L2 unicast addresses and sends the multicast RA with the given L2 unicast mapping. > > 2464bis says: > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. > > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. > > > As Jinmei also says, referring to section 6 is then wrong. That implies that the 6085 address mapping uses address resolution. Which is not the case. > > 6085 is indeed very underspecified in stating how the mapping is done, from 6085: > The determination of the unicast Ethernet link-layer > address and the construction of the outgoing IPv6 packet are out of > scope for this document. > > > Either do (Jinmei): > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as described in RFC6085. > > Or something like: > An IPv6 packet with a multicast destination address may also be mapped to an > Ethernet link-layer unicast address [RFC6085]. > E.g. when it is clear that only one address is relevant on the link and that the > mapping between an IPv6 multicast destination address and an Ethernet link-layer > unicast address is already known. > > Cheers, > Ole > > > >> On 11 Jan 2017, at 01:05, Bob Hinden wrote: >> >> Jinmei-san, >> >>> On Jan 10, 2017, at 11:22 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >>> >>> On Tue, Jan 10, 2017 at 9:26 AM wrote: >>> >>>>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>>>> Link layer address as defined in Section 6. >>>> >>>> I think it's more helpful to refer to RFC6085 explicitly here. >>>> Otherwise the proposed text looks good to me. >>> >>> On re-reading it more closely, I wonder whether "as defined in Section >>> 6" may not be very appropriate. RFC6085 intentionally left the >>> mapping open: >>> >>> [...] The determination of the unicast Ethernet link-layer >>> address and the construction of the outgoing IPv6 packet are out of >>> scope for this document. >>> >>> but I suspect it doesn't really intend to perform link-layer address >>> resolution using ND (which is in my understanding what "Section 6" >>> talks about) to determine the unicast Ethernet address. In fact, the >>> address resolution itself uses a multicast IPv6 address, which is >>> derived from the target unicast IPv6 address. So it would be a kind >>> of circular definition. >>> >>> So it's probably even better to just refer to the RFC instead of >>> Section 6: >>> >>> An IPv6 multicast packet may also be mapped to a unicast Ethernet >>> Link layer address as noted in [RFC6085]. >> >> I think the problem remains that RFC6085 isn=E2=80=99t very clear how to= do that. Pointing to RFC6085 is that it doesn=E2=80=99t say what to do :-( >> >> It would be good to hear from the authors of RFC6085. Also, what is current practice. >> >>> >>> And, for that matter, this text of Section 6 of rfc2464bis-01 now >>> looks a bit awkward to me: >>> >>> The procedure for mapping IPv6 unicast addresses into Ethernet link- >>> layer addresses is described in [DISC]. >> >> That is original text from RFC2464. I tried to avoid changing anything that wasn=E2=80=99t part of an update or errata. >> >>> >>> On reading both Sections 6 and 7, this "the procedure for mapping" >>> could read some static mapping whereas it should actually refer to >>> dynamic link-layer address resolution. >>> >>> I suggest revising the first paragraph from: >>> >>> The procedure for mapping IPv6 unicast addresses into Ethernet link- >>> layer addresses is described in [DISC]. The Source/Target Link-layer >>> Address option has the following form when the link layer is >>> Ethernet. >>> >>> to: >>> >>> When the link layer is Ethernet, the Ethernet address for an IPv6 >>> unicast address is resolved using the address resolution protocol >>> as defined in [DISC]. The Source/Target Link-layer Address option >>> used in that protocol has the following form. >> >> I find that an improvement (maybe without the =E2=80=9CWhen=E2=80=9D tex= t), but I am not sure a change is needed. >> >> Thanks, >> Bob >> >> >>> >>> -- >>> JINMEI, Tatuya >> >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- --94eb2c07ca8851417b0545d65df4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I also wrote up a draft a few years back as to= how MLDv2 in combination with Neighbor Discovery could use link layer unic= ast for multicast IPv6 traffic.

MLDv2 Procedures for Link-Layer Unic= ast Delivery of Multicast IPv6
https://tools.ietf.org/html/draft-smith-ml= dv2-link-unicast-00


I also saw this Linux bridge patch a few= days ago which sounds like it does the same sort of thing and has apparent= ly been enabled in OpenWRT on Wifi AP interfaces.


https://patchwork.ozlabs.org/patch= /710249/

Regards,
Mark.

On 11 January 2017 at 20:48, <otroan@employees.org> wrote:
> Bob,= Jinmei,
>
> As one of the authors of RFC6085 let me try to cla= rify how it would typically be used.
> Scenario: Wireless AP that alr= eady knows the L2 unicast address of all stations on a link.
> Some A= Ps try to improve on IPv6 multicast on wireless by sending the RAs as L2 un= icast to each individual station.
> The AP then runs through it's= list of L2 unicast addresses and sends the multicast RA with the given L2 = unicast mapping.
>
> 2464bis says:
> An IPv6 multicast= packet may also be mapped to a unicast Ethernet
> Link layer addr= ess as defined in Section 6.
>
> An IPv6 node receiving an I= Pv6 packet with a multicast destination
> address and an Ethernet = link-layer unicast address must not drop the
> packet as a result = using of this form of address mapping.
>
>
> As Jinmei al= so says, referring to section 6 is then wrong. That implies that the 6085 a= ddress mapping uses address resolution. Which is not the case.
>
&= gt; 6085 is indeed very underspecified in stating how the mapping is done, = from 6085:
> The determination of the unicast Ethernet link-layer<= br>> address and the construction of the outgoing IPv6 packet are out= of
> scope for this document.
>
>
> Either do (= Jinmei):
> An IPv6 multicast packet may also be mapped to a unicas= t Ethernet
> Link layer address as described in RFC6085.
>> Or something like:
> An IPv6 packet with a multicast destina= tion address may also be mapped to an
> Ethernet link-layer unicast= address [RFC6085].
> E.g. when it is clear that only one address i= s relevant on the link and that the
> mapping between an IPv6 multi= cast destination address and an Ethernet link-layer
> unicast addre= ss is already known.
>
> Cheers,
> Ole
>
>>
>> On 11 Jan 2017, at 01:05, Bob Hinden <bob.hinden@gmail.com> wrote:
>>
= >> Jinmei-san,
>>
>>> On Jan 10, 2017, at 11:22 = AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp> wrote:
>>>
>>> On = Tue, Jan 10, 2017 at 9:26 AM <jinme= i@wide.ad.jp> wrote:
>>>
>>>>> An IPv= 6 multicast packet may also be mapped to a unicast Ethernet
>>>= >> Link layer address as defined in Section 6.
>>>>>>>> I think it's more helpful to refer to RFC6085 explic= itly here.
>>>> Otherwise the proposed text looks good to me= .
>>>
>>> On re-reading it more closely, I wonder w= hether "as defined in Section
>>> 6" may not be very = appropriate. RFC6085 intentionally left the
>>> mapping open:<= br>>>>
>>> [...] The determination of the unicast Et= hernet link-layer
>>> address and the construction of the outg= oing IPv6 packet are out of
>>> scope for this document.
&g= t;>>
>>> but I suspect it doesn't really intend to pe= rform link-layer address
>>> resolution using ND (which is in m= y understanding what "Section 6"
>>> talks about) to = determine the unicast Ethernet address. In fact, the
>>> addre= ss resolution itself uses a multicast IPv6 address, which is
>>>= ; derived from the target unicast IPv6 address. So it would be a kind
&= gt;>> of circular definition.
>>>
>>> So it&#= 39;s probably even better to just refer to the RFC instead of
>>&g= t; Section 6:
>>>
>>> An IPv6 multicast packet ma= y also be mapped to a unicast Ethernet
>>> Link layer address= as noted in [RFC6085].
>>
>> I think the problem remains= that RFC6085 isn=E2=80=99t very clear how to do that. Pointing to RFC6085= is that it doesn=E2=80=99t say what to do :-(
>>
>> It w= ould be good to hear from the authors of RFC6085. Also, what is current pr= actice.
>>
>>>
>>> And, for that matter, t= his text of Section 6 of rfc2464bis-01 now
>>> looks a bit awkw= ard to me:
>>>
>>> The procedure for mapping IPv6 = unicast addresses into Ethernet link-
>>> layer addresses is d= escribed in [DISC].
>>
>> That is original text from RFC2= 464. I tried to avoid changing anything that wasn=E2=80=99t part of an upd= ate or errata.
>>
>>>
>>> On reading both = Sections 6 and 7, this "the procedure for mapping"
>>>= ; could read some static mapping whereas it should actually refer to
>= ;>> dynamic link-layer address resolution.
>>>
>>= ;> I suggest revising the first paragraph from:
>>>
>&= gt;> The procedure for mapping IPv6 unicast addresses into Ethernet lin= k-
>>> layer addresses is described in [DISC]. The Source/Tar= get Link-layer
>>> Address option has the following form when = the link layer is
>>> Ethernet.
>>>
>>>= ; to:
>>>
>>> When the link layer is Ethernet, the= Ethernet address for an IPv6
>>> unicast address is resolved = using the address resolution protocol
>>> as defined in [DISC]= . The Source/Target Link-layer Address option
>>> used in tha= t protocol has the following form.
>>
>> I find that an i= mprovement (maybe without the =E2=80=9CWhen=E2=80=9D text), but I am not su= re a change is needed.
>>
>> Thanks,
>> Bob
&= gt;>
>>
>>>
>>> --
>>> JINM= EI, Tatuya
>>
>> ----------------------------------------= ----------------------------
>> IETF IPv6 working group mailing li= st
>> ipv6@ietf.org
>&g= t; Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------= ------------------------------------------------------------
>
>= ; --------------------------------------------------------------------
&= gt; IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo= /ipv6
> ---------------------------------------------------------= -----------
--94eb2c07ca8851417b0545d65df4-- From nobody Wed Jan 11 12:10:00 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1500512954D for ; Wed, 11 Jan 2017 12:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG97IroiyfWf for ; Wed, 11 Jan 2017 12:09:57 -0800 (PST) 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 AE1FA12956F for ; Wed, 11 Jan 2017 12:09:57 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 127so64525504pfg.1 for ; Wed, 11 Jan 2017 12:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fK3ABu1pPFyBloSNmRcXQTivEHFv5u3HfyCLfDj1twM=; b=WHoxvEuxrHm5urFKL64MOXrP7L49bMjdGapLcaYO6Wrae/MnNCRlAYfF59d/VraD5I WC2vJAn8FUC7ffrN61mQCOEXDDF8E2+ffuRQGttLc60z9GzpjxNlHn3siS0eDOykUpB0 JtSyV23m0JBm4PGXBp2mh21MQ2RQ59BZMeRo/Y1O+SnW0ComaK3hdtPX+YGzDABHjnFT aEHuVYrNdyR6Im1z/yZnp1868ySYkoWcx8RLXSnIZLbXbT41Yt58UO8E8Zl0j/+cv0Nb OdWtvqGrM2V07TGnzcYmLgwBuaYgOGqYcxt7aBg80nCCw/FGTBYbCpvqgLEEIzmGEgG7 jjOw== 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=fK3ABu1pPFyBloSNmRcXQTivEHFv5u3HfyCLfDj1twM=; b=jcAUFAglK/2g7l2FotywKh+59ndtFJp2m58ES5oT7nuDjDhLN2x2/DMGW6EY9vR98L y+LjeM5sibRWNnrETkdU/MJusGqzz8u30JxFbQNSnBOBh0l83bSRJpnQLcbtxRUNnV6S 46LPWPxWrCfPejJSOE5dteyecM2Moh9q05KS5V+o5qts3/FIT5l7NILfjlYDu3YANiQ9 k1NmvCToVaZ/vYX3SUtY89p2z7+WHH1VXPrDsfhkf0TCA6EGKtuFNVsSTb2MNJ1R5zRU Oji8SEpIsHHYyzpfuDOclzOaI8hbrTqKaPtuM/IjCdvoPsSmHGgioNQMM+T3MQor2oyg Q57g== X-Gm-Message-State: AIkVDXILyGPZZTuiJtEM+MwIX3hFekvKGAUqpf9IDDYm488XakOnADspKg2YEbbZSx0wUQ== X-Received: by 10.98.220.139 with SMTP id c11mr12253410pfl.96.1484165397283; Wed, 11 Jan 2017 12:09:57 -0800 (PST) Received: from [192.168.1.20] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id p25sm15814719pfd.0.2017.01.11.12.09.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:09:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC6085 update to rfc2464bis - Ethernet or WiFi? From: Fred Baker In-Reply-To: <3525D98F-E092-44F2-B3CC-03F4D621B69D@tzi.org> Date: Wed, 11 Jan 2017 12:09:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <69C36856-F0C7-4E3A-87B7-0D3F0A9B4448@gmail.com> References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> <9a42adb5-92ea-d1f8-66f8-7da7b101cf0b@gmail.com> <3525D98F-E092-44F2-B3CC-03F4D621B69D@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Alexandre Petrescu , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:09:59 -0000 On Jan 11, 2017, at 11:07 AM, Carsten Bormann wrote: > =E2=80=9CIPv6 over Ethernet=E2=80=9D in reality is a shorthand for = =E2=80=9CIPv6 over 802.1 bridged links that collectively try to look = like Ethernet but don=E2=80=99t always succeed very well=E2=80=9D. WiFi = is part of that world. I would agree with that statement. "Ethernet", these days, includes the = IEEE 802.3 series of specifications at various speeds and using various = PHY interfaces, the IEEE 802.11 series, and lambdas and other "serial" = media in the backbone. The point, as you you note, is the use of the = Ethernet frame format (1518 bytes, including the 802.3 header and the = CRC trailer, and the bit I care about in between). There is an obvious = extension at 1 GBPS and faster, to a 9K byte message, but the exact = value of "9K" varies, and there are funny issues like "is that a single = frame, or a burst of 1500 byte frames?" By way of example, in my house I have both wired (1 GBPS) Ethernet and = 802.11 Wifi. The latter is attached to the former, and is in any useful = sense indistinguishable from it including sharing the IP prefixes. A = message might originate on WiFi using one access point, ride a wire to = and from a switch, and come out to a printer on the other access point. = It's one "Ethernet", and it is what it is.= From nobody Wed Jan 11 12:13: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 D4904129847 for ; Wed, 11 Jan 2017 12:13:57 -0800 (PST) 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 ch4jSr5e4GOc for ; Wed, 11 Jan 2017 12:13:56 -0800 (PST) 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 C78E71297F0 for ; Wed, 11 Jan 2017 12:13:55 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 194so23519976pgd.2 for ; Wed, 11 Jan 2017 12:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Hj9Q42oA2ZZdAmVkRxqPPO5jBXbjYfiKEiby1VIurSM=; b=ONEAVslHHWCOe18qT6ZJUauFZtUWwX8AyawoFmeZTZcqWA1qI+bS3ivWjll+yGPd5o UL/VG3mV/bYQZgUXlSyMUCQmyqc+smF0oatLuG8Y/9avE1K91XjA+iLr1ehCKHiJV76n RL1n5noadvUKT5zAJ0Gj17d28ROcBNoChOf3kUfrsyyaF4soo5LIu5C665+TXuxmnsi9 B2nDTyTV3R1RDp6qC8QCMKqB9N0sF38LUqpExQduWNSviTSBBywdDtCUHPOUXG93Ur1/ VSlvT9Auzh8St9A2m6/2aSHYj6N7DpaOrmPIqf5gDxEA0CZBQfm2hzf5YYPR3lvxcAjP aj+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Hj9Q42oA2ZZdAmVkRxqPPO5jBXbjYfiKEiby1VIurSM=; b=Vo7YBU4XIxxvgO/CPPessx5Wm7VZnbMgfLCYrsRunAjLhmLQuMcW2XO4EQyiAOkuvS cLrMPkZU637DbWnoeS2DikeMq5+8qm97cqBlnYUmc6+ny7IK96t6Wh6dCiAw/mbSJt5l x7YZ73fractzajadxVVsjSGhGb+0ELo1tpTaC3B10r0kS8Slh8gY+fMbPmcRIYjd2lgU Y+FMjPzJoWe16EA7tU96gJVQ473pjaJHCWNDBWxP8vOGcnNT+R2fEP0SWYbNeBhBAnq8 CoHA+1+S8R/fzcSLPlnqU6z7ByA5efv9NGwzGQmxmysKNcMFAPldexs5Gy/a8ZqqaTOz yxog== X-Gm-Message-State: AIkVDXK6lfwLTktsvq941KweY5CEQ/fY/D2ScL1P7iOgtUfGAs+VJ+U216BRu+zhgk4ifQ== X-Received: by 10.99.60.76 with SMTP id i12mr13065139pgn.170.1484165635446; Wed, 11 Jan 2017 12:13:55 -0800 (PST) Received: from ?IPv6:2406:e007:45c2:1:28cc:dc4c:9703:6781? ([2406:e007:45c2:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s5sm15860813pgj.19.2017.01.11.12.13.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:13:54 -0800 (PST) Subject: Re: RFC6085 update to rfc2464bis - Ethernet or WiFi? To: Carsten Bormann , Alexandre Petrescu References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> <9a42adb5-92ea-d1f8-66f8-7da7b101cf0b@gmail.com> <3525D98F-E092-44F2-B3CC-03F4D621B69D@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 12 Jan 2017 09:13:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <3525D98F-E092-44F2-B3CC-03F4D621B69D@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:13:58 -0000 On 12/01/2017 08:07, Carsten Bormann wrote: > On 11 Jan 2017, at 20:00, Alexandre Petrescu wrote: >> >> This is WiFi, it is not Ethernet. It is not the same. An IPv6-over-W= iFi document remains to be written. >=20 > That=E2=80=99s actually not true in real life. >=20 > =E2=80=9CIPv6 over Ethernet=E2=80=9D in reality is a shorthand for =E2=80= =9CIPv6 over 802.1 bridged links that collectively try to look like Ether= net but don=E2=80=99t always succeed very well=E2=80=9D. WiFi is part of= that world. Indeed. I don't care how it works under the covers: code that runs over E= thernet runs identically over WiFi. OK, maybe some spectrum is wasted, but for most pe= ople most of the time that simply doesn't matter. Brian From nobody Wed Jan 11 12:19:08 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 2264F128B38; Wed, 11 Jan 2017 12:19:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: 6man - Update to a Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148416594611.8139.5823695881659834105.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 12:19:06 -0800 Archived-At: Cc: ot@cisco.com, ipv6@ietf.org, suresh.krishnan@ericsson.com, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:19:06 -0000 An update to a meeting session request has just been submitted by Ole Troan, a Chair of the 6man working group. --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops softwire spring Second Priority: mtgvenue Special Requests: --------------------------------------------------------- From nobody Wed Jan 11 13:47:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A92C1295A7; Wed, 11 Jan 2017 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z1dszB3MIV8; Wed, 11 Jan 2017 13:47:52 -0800 (PST) Received: from mail-wj0-x244.google.com (mail-wj0-x244.google.com [IPv6:2a00:1450:400c:c01::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6DD12950E; Wed, 11 Jan 2017 13:47:52 -0800 (PST) Received: by mail-wj0-x244.google.com with SMTP id dh1so83890wjb.3; Wed, 11 Jan 2017 13:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=SSRZkOzCTlMUwft72yrOysL8kCRvX4I3INUEuwcRd4o=; b=siNW+83qRz4/OQh6FIAm/c6NmrrkAuw75yMBGIX7JX4pqON6uwOtZyEphvg2FS4C8V rr1+enfDWuF0oS9TYhlGzJ2VYe4huXqjoaUo5hhOBaI8D0sVxFZB5FVK7XNNip43PhX3 Y8E74KS8qK72CVFZmrK8zlG+5hc9cnhpEbSZAowA1q4CCtW4YWidAyijNV8kNtMxfzOL n5Bc+xF8TT4CMobnY1EVM3EQeAHqopJqzFIaOXo1z3qNwHBo7VMvAv1mbXlKEL0ID6Cm vi+D5CCxN/3jQsWf9fhvTqu6yvWvxOBqNVyKIHlqVWKwoS8VLN9gLoDETZ3mi32EaP8u bb5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SSRZkOzCTlMUwft72yrOysL8kCRvX4I3INUEuwcRd4o=; b=ley669ezerED6Io1GVJhPaHnpMHCzu+rEFwtW8VXk5nKUWY2kVoY3PqtA0Yku78oti /a4vTieSu83ko5JCdCd2frQzQksX2MG98bBAzNtOkUhfzV0anry1+/u4cvh7WCsaSLdf jkTeYLVPy4FpFSXQFxH06uvpzyf8yqCxJAu6AR8v2846xf6E30AjCV9hi95UDSZXQjGe zcrRPQson1u/bUTbdGj9jNN75sz+hsM/7cUZxXmZ2lSk6UKaj0DMR/sGoP9w8rGuVctA Hn8hVaonm5SwFYDlNEAvO4BBqB1ghLMcS2YkN6W5R6MiKvzQqwJh5SZaFT6MgULjpnk/ sQAw== X-Gm-Message-State: AIkVDXIf5uhEFyFJBZdrhpHBQkREVRHGaCH6iFVrwM+S49RLEuEZNO+yfxauIzqUP7EVBA== X-Received: by 10.194.109.168 with SMTP id ht8mr6680198wjb.36.1484171270677; Wed, 11 Jan 2017 13:47:50 -0800 (PST) Received: from [192.168.1.2] ([41.225.64.83]) by smtp.gmail.com with ESMTPSA id k11sm10893900wmb.18.2017.01.11.13.47.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 13:47:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_03BAFB09-429E-4614-BCDE-0F6311BE5072" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [Int-area] Route Information Options in Redirect Messages From: Zied Bouziri In-Reply-To: <6d21dd17f0b94a39a71600944878ec39@XCH15-06-08.nw.nos.boeing.com> Date: Wed, 11 Jan 2017 22:47:46 +0100 Message-Id: References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> <016f01d26b78$870895a0$9519c0e0$@huitema.net> <6d21dd17f0b94a39a71600944878ec39@XCH15-06-08.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: 6man WG , INT Area , Christian Huitema X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 21:47:55 -0000 --Apple-Mail=_03BAFB09-429E-4614-BCDE-0F6311BE5072 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fred In section 6 : "Namely, the protocol must take measures to secure IPv6 ND messages on = links where spoofing attacks are possible =C2=BB By reading this passage, I have the impression that there are links = where attack spoofing is possible and others not ! How can we know if this attack is possible or not in a specified link ? Thank you=20 Zied > Le 10 janv. 2017 =C3=A0 22:52, Templin, Fred L = a =C3=A9crit : >=20 > Hi Christian, >=20 >> -----Original Message----- >> From: Christian Huitema [mailto:huitema@huitema.net] >> Sent: Tuesday, January 10, 2017 11:34 AM >> To: Templin, Fred L ; 'Brian E Carpenter' = ; '6man WG' ; >> 'INT Area' >> Subject: RE: [Int-area] Route Information Options in Redirect = Messages >>=20 >> On Tuesday, January 10, 2017 9:55 AM, Fred Templin wrote: >>> ... >>> What is being proposed in the document I submitted is the inclusion = of >>> RIOs in Redirect messages for a *prefix* that is not on-link, as = opposed >>> to a singleton destination. So, the same SHOULD in the paragraph = above >>> would seem to apply also to prefix redirection the same as for = ordinary >>> destination redirection. >>=20 >> Fred, I am reading the security section of your draft. I think it = needs a >> bit more work. >>=20 >> Currently, the RIO are only expected in router advertisements. RA are >> somewhat special, and there is often specific code in switches to = check RA >> and prevent RA spoofing -- e.g., RA-Guard. Allowing the option in = Redirect >> messages could very well bypass the RA specific checks. Doesn't that = open >> the path for new attacks? Should you not say something about that in = the >> security section? How about specific mitigations, such as sanity = checks when >> processing redirect messages? >=20 > Since IP will still operate correctly if transmission of Redirect = messages is > somehow suppressed (i.e., denial of Redirect service), the more = serious > threat to be considered is spoofing. Here is what currently appears = under > Security Considerations: >=20 > "Security considerations for Redirect messages that include RIOs are > the same as for any IPv6 ND messages as specified in Section 11 of > [RFC4861]. Namely, the protocol must take measures to secure IPv6 = ND > messages on links where spoofing attacks are possible. >=20 > A spoofed Redirect message containing no RIOs could cause corruption > in the host's destination cache while a spoofed Redirect message > containing RIOs could corrupt the host's routing tables. While the > latter would seem to be a more onerous result, the possibility for > corruption is unacceptable in either case." >=20 > So, from the first paragraph, we can see that the protocol must take > measures to secure IPv6 ND messages on links where spoofing attacks > are possible. The second paragraph then analyzes the consequences of > what could happen if a spoofing attack were successful and we see that > there are unacceptable negative consequences for both traditional > Redirects and Redirects that include RIOs. >=20 > The text stops short of saying that "no Redirects of any kind should = be > used on links where spoofing attacks are possible". Would adding a > statement such as this address the concern? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- Best Regards, =D9=85=D8=B9 =D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A Zied BOUZIRI=D8=8C =D8=B2=D9=8A=D8=A7=D8=AF =D8=A8=D9=88=D8=B2=D9=8A=D8=B1= =D9=8A ISET Charguia, Tunisie www.bouziri.tn --Apple-Mail=_03BAFB09-429E-4614-BCDE-0F6311BE5072 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Fred
In section 6 :
"Namely, the protocol must take measures to secure IPv6 = ND messages on links where spoofing attacks are = possible =C2=BB
By reading this passage, I have = the impression that there are links where attack spoofing is possible and others not = !
How can we = know if this attack is possible or not in a specified link = ?
Thank = you 
Zied

Le 10 janv. 2017 =C3=A0 22:52, = Templin, Fred L <Fred.L.Templin@boeing.com> a =C3=A9crit :

Hi Christian,

-----Original Message-----
From: Christian = Huitema [mailto:huitema@huitema.net]
Sent: Tuesday, = January 10, 2017 11:34 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; 'Brian E Carpenter' <brian.e.carpenter@gmail.com>; '6man WG' <ipv6@ietf.org>;
'INT Area' <int-area@ietf.org>
Subject: RE: = [Int-area] Route Information Options in Redirect Messages

On Tuesday, January 10, 2017 9:55 AM, Fred = Templin wrote:
...
What is being proposed in the document I submitted is the = inclusion of
RIOs in Redirect messages for a *prefix* that = is not on-link, as opposed
to a singleton destination. So, = the same SHOULD in the paragraph above
would seem to apply = also to prefix redirection the same as for ordinary
destination redirection.

Fred, I am reading the security section of your draft. I = think it needs a
bit more work.

Currently, the RIO are only expected in router = advertisements. RA are
somewhat special, and there is = often specific code in switches to check RA
and prevent RA = spoofing -- e.g., RA-Guard. Allowing the option in Redirect
messages could very well bypass the RA specific checks. = Doesn't that open
the path for new attacks? Should you not = say something about that in the
security section? How = about specific mitigations, such as sanity checks when
processing redirect messages?

Since IP will still operate correctly if transmission of = Redirect messages is
somehow suppressed (i.e., denial of = Redirect service), the more serious
threat to be = considered is spoofing. Here is what currently appears under
Security Considerations:

=   "Security considerations for Redirect messages that include = RIOs are
  the same as for any IPv6 ND messages = as specified in Section 11 of
  [RFC4861]. =  Namely, the protocol must take measures to secure IPv6 ND
  messages on links where spoofing attacks are = possible.

  A spoofed Redirect = message containing no RIOs could cause corruption
=   in the host's destination cache while a spoofed Redirect = message
  containing RIOs could corrupt the = host's routing tables.  While the
  latter = would seem to be a more onerous result, the possibility for
=   corruption is unacceptable in either case."
So, from the first paragraph, we can see that the protocol = must take
measures to secure IPv6 ND messages on links = where spoofing attacks
are possible. The second paragraph = then analyzes the consequences of
what could happen if a = spoofing attack were successful and we see that
there are = unacceptable negative consequences for both traditional
Redirects and Redirects that include RIOs.

The text stops short of saying that "no Redirects of any kind = should be
used on links where spoofing attacks are = possible". Would adding a
statement such as this address = the concern?

Thanks - Fred
fred.l.templin@boeing.com

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

Best Regards, =D9=85=D8=B9 = =D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A
Zied = BOUZIRI=D8=8C =D8=B2=D9=8A=D8=A7=D8=AF =D8=A8=D9=88=D8=B2=D9=8A=D8=B1=D9=8A
ISET Charguia, Tunisie
www.bouziri.tn

= --Apple-Mail=_03BAFB09-429E-4614-BCDE-0F6311BE5072-- From nobody Wed Jan 11 14:22: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 E16EB1295A5; Wed, 11 Jan 2017 14:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_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 bfRw4ybD3ZRn; Wed, 11 Jan 2017 14:22:36 -0800 (PST) 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 1ACE0129439; Wed, 11 Jan 2017 14:22:35 -0800 (PST) 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 v0BMMZDC062637; Wed, 11 Jan 2017 15:22: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 v0BMMOQM062026 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2017 15:22:24 -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.1178.4; Wed, 11 Jan 2017 14:22:23 -0800 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.1178.000; Wed, 11 Jan 2017 14:22:23 -0800 From: "Templin, Fred L" To: Zied Bouziri Subject: RE: [Int-area] Route Information Options in Redirect Messages Thread-Topic: [Int-area] Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAeC3cAABhBxNAAFKbugAAMs3RQACpBLgAAD+D48A== Date: Wed, 11 Jan 2017 22:22:23 +0000 Message-ID: References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> <016f01d26b78$870895a0$9519c0e0$@huitema.net> <6d21dd17f0b94a39a71600944878ec39@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_c8baed16b3dc46d2a667614310f0334dXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: 6man WG , INT Area , Christian Huitema X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:22:38 -0000 --_000_c8baed16b3dc46d2a667614310f0334dXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWmllZCwNCg0KVGhpcyBpcyBkaXNjdXNzZWQgaW4g4oCcSVB2NiBORCBUcnVzdCBNb2RlbHMg YW5kIFRocmVhdHMgW1JGQzM3NTZd4oCdLiBVbmRlciBTZWN0aW9uIDQuMi40DQppdCBzYXlzOiDi gJxUaGlzIGF0dGFjayBpcyBub3QgYSBjb25jZXJuIGlmIGFjY2VzcyB0byB0aGUgbGluayBpcyBy ZXN0cmljdGVkIHRvIHRydXN0ZWQgbm9kZXPigJ0uDQpTRU5EIFtSRkMzOTcxXSBwcm92aWRlcyBv bmUgcG9zc2libGUgbWl0aWdhdGlvbiBpbiBvdGhlciBjYXNlcy4NCg0KVGhhbmtzIC0gRnJlZA0K DQpGcm9tOiBaaWVkIEJvdXppcmkgW21haWx0bzp6aWVkLmJvdXppcmlAZ21haWwuY29tXQ0KU2Vu dDogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IDE6NDggUE0NClRvOiBUZW1wbGluLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogQ2hyaXN0aWFuIEh1aXRlbWEgPGh1 aXRlbWFAaHVpdGVtYS5uZXQ+OyBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IElOVCBBcmVhIDxpbnQtYXJlYUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIFJvdXRlIEluZm9ybWF0aW9uIE9wdGlv bnMgaW4gUmVkaXJlY3QgTWVzc2FnZXMNCg0KSGkgRnJlZA0KSW4gc2VjdGlvbiA2IDoNCiJOYW1l bHksIHRoZSBwcm90b2NvbCBtdXN0IHRha2UgbWVhc3VyZXMgdG8gc2VjdXJlIElQdjYgTkQgbWVz c2FnZXMgb24gbGlua3Mgd2hlcmUgc3Bvb2ZpbmcgYXR0YWNrcyBhcmUgcG9zc2libGUgwrsNCkJ5 IHJlYWRpbmcgdGhpcyBwYXNzYWdlLCBJIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGVyZSBh cmUgbGlua3Mgd2hlcmUgYXR0YWNrIHNwb29maW5nIGlzIHBvc3NpYmxlIGFuZCBvdGhlcnMgbm90 ICENCkhvdyBjYW4gd2Uga25vdyBpZiB0aGlzIGF0dGFjayBpcyBwb3NzaWJsZSBvciBub3QgaW4g YSBzcGVjaWZpZWQgbGluayA/DQpUaGFuayB5b3UNClppZWQNCg0KTGUgMTAgamFudi4gMjAxNyDD oCAyMjo1MiwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0 bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gYSDDqWNyaXQgOg0KDQpIaSBDaHJpc3RpYW4s DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdGlhbiBIdWl0ZW1h IFttYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldF0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAs IDIwMTcgMTE6MzQgQU0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PjsgJ0JyaWFuIEUgQ2FycGVu dGVyJyA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb20+PjsgJzZtYW4gV0cnIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPj47DQonSU5UIEFyZWEnIDxpbnQtYXJlYUBpZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtJbnQtYXJlYV0gUm91dGUgSW5mb3JtYXRpb24gT3B0aW9u cyBpbiBSZWRpcmVjdCBNZXNzYWdlcw0KDQpPbiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDE3IDk6 NTUgQU0sIEZyZWQgVGVtcGxpbiB3cm90ZToNCg0KLi4uDQpXaGF0IGlzIGJlaW5nIHByb3Bvc2Vk IGluIHRoZSBkb2N1bWVudCBJIHN1Ym1pdHRlZCBpcyB0aGUgaW5jbHVzaW9uIG9mDQpSSU9zIGlu IFJlZGlyZWN0IG1lc3NhZ2VzIGZvciBhICpwcmVmaXgqIHRoYXQgaXMgbm90IG9uLWxpbmssIGFz IG9wcG9zZWQNCnRvIGEgc2luZ2xldG9uIGRlc3RpbmF0aW9uLiBTbywgdGhlIHNhbWUgU0hPVUxE IGluIHRoZSBwYXJhZ3JhcGggYWJvdmUNCndvdWxkIHNlZW0gdG8gYXBwbHkgYWxzbyB0byBwcmVm aXggcmVkaXJlY3Rpb24gdGhlIHNhbWUgYXMgZm9yIG9yZGluYXJ5DQpkZXN0aW5hdGlvbiByZWRp cmVjdGlvbi4NCg0KRnJlZCwgSSBhbSByZWFkaW5nIHRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIHlv dXIgZHJhZnQuIEkgdGhpbmsgaXQgbmVlZHMgYQ0KYml0IG1vcmUgd29yay4NCg0KQ3VycmVudGx5 LCB0aGUgUklPIGFyZSBvbmx5IGV4cGVjdGVkIGluIHJvdXRlciBhZHZlcnRpc2VtZW50cy4gUkEg YXJlDQpzb21ld2hhdCBzcGVjaWFsLCBhbmQgdGhlcmUgaXMgb2Z0ZW4gc3BlY2lmaWMgY29kZSBp biBzd2l0Y2hlcyB0byBjaGVjayBSQQ0KYW5kIHByZXZlbnQgUkEgc3Bvb2ZpbmcgLS0gZS5nLiwg UkEtR3VhcmQuIEFsbG93aW5nIHRoZSBvcHRpb24gaW4gUmVkaXJlY3QNCm1lc3NhZ2VzIGNvdWxk IHZlcnkgd2VsbCBieXBhc3MgdGhlIFJBIHNwZWNpZmljIGNoZWNrcy4gRG9lc24ndCB0aGF0IG9w ZW4NCnRoZSBwYXRoIGZvciBuZXcgYXR0YWNrcz8gU2hvdWxkIHlvdSBub3Qgc2F5IHNvbWV0aGlu ZyBhYm91dCB0aGF0IGluIHRoZQ0Kc2VjdXJpdHkgc2VjdGlvbj8gSG93IGFib3V0IHNwZWNpZmlj IG1pdGlnYXRpb25zLCBzdWNoIGFzIHNhbml0eSBjaGVja3Mgd2hlbg0KcHJvY2Vzc2luZyByZWRp cmVjdCBtZXNzYWdlcz8NCg0KU2luY2UgSVAgd2lsbCBzdGlsbCBvcGVyYXRlIGNvcnJlY3RseSBp ZiB0cmFuc21pc3Npb24gb2YgUmVkaXJlY3QgbWVzc2FnZXMgaXMNCnNvbWVob3cgc3VwcHJlc3Nl ZCAoaS5lLiwgZGVuaWFsIG9mIFJlZGlyZWN0IHNlcnZpY2UpLCB0aGUgbW9yZSBzZXJpb3VzDQp0 aHJlYXQgdG8gYmUgY29uc2lkZXJlZCBpcyBzcG9vZmluZy4gSGVyZSBpcyB3aGF0IGN1cnJlbnRs eSBhcHBlYXJzIHVuZGVyDQpTZWN1cml0eSBDb25zaWRlcmF0aW9uczoNCg0KICAiU2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgZm9yIFJlZGlyZWN0IG1lc3NhZ2VzIHRoYXQgaW5jbHVkZSBSSU9zIGFy ZQ0KICB0aGUgc2FtZSBhcyBmb3IgYW55IElQdjYgTkQgbWVzc2FnZXMgYXMgc3BlY2lmaWVkIGlu IFNlY3Rpb24gMTEgb2YNCiAgW1JGQzQ4NjFdLiAgTmFtZWx5LCB0aGUgcHJvdG9jb2wgbXVzdCB0 YWtlIG1lYXN1cmVzIHRvIHNlY3VyZSBJUHY2IE5EDQogIG1lc3NhZ2VzIG9uIGxpbmtzIHdoZXJl IHNwb29maW5nIGF0dGFja3MgYXJlIHBvc3NpYmxlLg0KDQogIEEgc3Bvb2ZlZCBSZWRpcmVjdCBt ZXNzYWdlIGNvbnRhaW5pbmcgbm8gUklPcyBjb3VsZCBjYXVzZSBjb3JydXB0aW9uDQogIGluIHRo ZSBob3N0J3MgZGVzdGluYXRpb24gY2FjaGUgd2hpbGUgYSBzcG9vZmVkIFJlZGlyZWN0IG1lc3Nh Z2UNCiAgY29udGFpbmluZyBSSU9zIGNvdWxkIGNvcnJ1cHQgdGhlIGhvc3QncyByb3V0aW5nIHRh Ymxlcy4gIFdoaWxlIHRoZQ0KICBsYXR0ZXIgd291bGQgc2VlbSB0byBiZSBhIG1vcmUgb25lcm91 cyByZXN1bHQsIHRoZSBwb3NzaWJpbGl0eSBmb3INCiAgY29ycnVwdGlvbiBpcyB1bmFjY2VwdGFi bGUgaW4gZWl0aGVyIGNhc2UuIg0KDQpTbywgZnJvbSB0aGUgZmlyc3QgcGFyYWdyYXBoLCB3ZSBj YW4gc2VlIHRoYXQgdGhlIHByb3RvY29sIG11c3QgdGFrZQ0KbWVhc3VyZXMgdG8gc2VjdXJlIElQ djYgTkQgbWVzc2FnZXMgb24gbGlua3Mgd2hlcmUgc3Bvb2ZpbmcgYXR0YWNrcw0KYXJlIHBvc3Np YmxlLiBUaGUgc2Vjb25kIHBhcmFncmFwaCB0aGVuIGFuYWx5emVzIHRoZSBjb25zZXF1ZW5jZXMg b2YNCndoYXQgY291bGQgaGFwcGVuIGlmIGEgc3Bvb2ZpbmcgYXR0YWNrIHdlcmUgc3VjY2Vzc2Z1 bCBhbmQgd2Ugc2VlIHRoYXQNCnRoZXJlIGFyZSB1bmFjY2VwdGFibGUgbmVnYXRpdmUgY29uc2Vx dWVuY2VzIGZvciBib3RoIHRyYWRpdGlvbmFsDQpSZWRpcmVjdHMgYW5kIFJlZGlyZWN0cyB0aGF0 IGluY2x1ZGUgUklPcy4NCg0KVGhlIHRleHQgc3RvcHMgc2hvcnQgb2Ygc2F5aW5nIHRoYXQgIm5v IFJlZGlyZWN0cyBvZiBhbnkga2luZCBzaG91bGQgYmUNCnVzZWQgb24gbGlua3Mgd2hlcmUgc3Bv b2ZpbmcgYXR0YWNrcyBhcmUgcG9zc2libGUiLiBXb3VsZCBhZGRpbmcgYQ0Kc3RhdGVtZW50IHN1 Y2ggYXMgdGhpcyBhZGRyZXNzIHRoZSBjb25jZXJuPw0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwu dGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGll dGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K QmVzdCBSZWdhcmRzLCDZhdi5INiq2K3Zitin2KrZig0KWmllZCBCT1VaSVJJ2Iwg2LLZitin2K8g 2KjZiNiy2YrYsdmKDQpJU0VUIENoYXJndWlhLCBUdW5pc2llDQp3d3cuYm91emlyaS50bjxodHRw Oi8vd3d3LmJvdXppcmkudG4vPg0KDQo= --_000_c8baed16b3dc46d2a667614310f0334dXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGkgWmllZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoaXMgaXMgZGlzY3Vzc2VkIGluIOKAnElQdjYgTkQgVHJ1c3QgTW9kZWxzIGFu ZCBUaHJlYXRzIFtSRkMzNzU2XeKAnS4gVW5kZXIgU2VjdGlvbiA0LjIuNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5pdCBzYXlzOiDigJxUaGlzIGF0dGFjayBpcyBub3QgYSBjb25jZXJuIGlmIGFjY2VzcyB0 byB0aGUgbGluayBpcyByZXN0cmljdGVkIHRvIHRydXN0ZWQgbm9kZXPigJ0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNFTkQgW1JGQzM5NzFdIHByb3ZpZGVzIG9uZSBwb3NzaWJsZSBtaXRpZ2F0aW9uIGlu IG90aGVyIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFppZWQgQm91emlyaSBbbWFpbHRvOnppZWQuYm91emly aUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAy MDE3IDE6NDggUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTCAmbHQ7RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGlhbiBIdWl0ZW1hICZs dDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgQnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbSZndDs7IDZtYW4gV0cgJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7OyBJ TlQgQXJlYSAmbHQ7aW50LWFyZWFAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbSW50LWFyZWFdIFJvdXRlIEluZm9ybWF0aW9uIE9wdGlvbnMgaW4gUmVkaXJlY3QgTWVzc2Fn ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGcmVk PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc2VjdGlvbiA2 IDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZx dW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5OYW1lbHksIHRoZSBwcm90b2NvbCBt dXN0IHRha2UgbWVhc3VyZXMgdG8gc2VjdXJlIElQdjYgTkQmbmJzcDttZXNzYWdlcyBvbiBsaW5r cyB3aGVyZSBzcG9vZmluZyBhdHRhY2tzIGFyZSBwb3NzaWJsZSZuYnNwO8K7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJ5IHJlYWRpbmcgdGhpcyBwYXNzYWdlLCBJIGhhdmUgdGhl IGltcHJlc3Npb24gdGhhdCB0aGVyZSBhcmUgbGlua3Mgd2hlcmUgYXR0YWNrJm5ic3A7c3Bvb2Zp bmc8L3NwYW4+Jm5ic3A7aXMgcG9zc2libGUgYW5kIG90aGVycyBub3QgITxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPkhvdyBjYW4gd2Uga25vdyBpZiB0aGlzIGF0dGFjayBpcyBwb3NzaWJsZSBv ciBub3QgaW4gYSBzcGVjaWZpZWQgbGluayA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPlRoYW5rIHlvdSZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5aaWVk PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5MZSAxMCBqYW52LiAyMDE3IMOgIDIyOjUyLCBUZW1wbGluLCBGcmVkIEwg Jmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPC9hPiZndDsgYSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBDaHJpc3RpYW4sPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgWzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0Ij5tYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT5dPGJyPg0KU2VudDogVHVl c2RheSwgSmFudWFyeSAxMCwgMjAxNyAxMTozNCBBTTxicj4NClRvOiBUZW1wbGluLCBGcmVkIEwg Jmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPC9hPiZndDs7ICdCcmlhbiBFIENhcnBlbnRlcicgJmx0OzxhIGhyZWY9 Im1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20iPmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbTwvYT4mZ3Q7OyAnNm1hbiBXRycgJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYu b3JnIj5pcHY2QGlldGYub3JnPC9hPiZndDs7PGJyPg0KJ0lOVCBBcmVhJyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmludC1hcmVhQGlldGYub3JnIj5pbnQtYXJlYUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K U3ViamVjdDogUkU6IFtJbnQtYXJlYV0gUm91dGUgSW5mb3JtYXRpb24gT3B0aW9ucyBpbiBSZWRp cmVjdCBNZXNzYWdlczxicj4NCjxicj4NCk9uIFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTcgOTo1 NSBBTSwgRnJlZCBUZW1wbGluIHdyb3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4uLi48YnI+DQpXaGF0IGlzIGJlaW5nIHByb3Bvc2VkIGluIHRo ZSBkb2N1bWVudCBJIHN1Ym1pdHRlZCBpcyB0aGUgaW5jbHVzaW9uIG9mPGJyPg0KUklPcyBpbiBS ZWRpcmVjdCBtZXNzYWdlcyBmb3IgYSAqcHJlZml4KiB0aGF0IGlzIG5vdCBvbi1saW5rLCBhcyBv cHBvc2VkPGJyPg0KdG8gYSBzaW5nbGV0b24gZGVzdGluYXRpb24uIFNvLCB0aGUgc2FtZSBTSE9V TEQgaW4gdGhlIHBhcmFncmFwaCBhYm92ZTxicj4NCndvdWxkIHNlZW0gdG8gYXBwbHkgYWxzbyB0 byBwcmVmaXggcmVkaXJlY3Rpb24gdGhlIHNhbWUgYXMgZm9yIG9yZGluYXJ5PGJyPg0KZGVzdGlu YXRpb24gcmVkaXJlY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpGcmVkLCBJIGFtIHJlYWRpbmcgdGhlIHNlY3VyaXR5IHNlY3Rp b24gb2YgeW91ciBkcmFmdC4gSSB0aGluayBpdCBuZWVkcyBhPGJyPg0KYml0IG1vcmUgd29yay48 YnI+DQo8YnI+DQpDdXJyZW50bHksIHRoZSBSSU8gYXJlIG9ubHkgZXhwZWN0ZWQgaW4gcm91dGVy IGFkdmVydGlzZW1lbnRzLiBSQSBhcmU8YnI+DQpzb21ld2hhdCBzcGVjaWFsLCBhbmQgdGhlcmUg aXMgb2Z0ZW4gc3BlY2lmaWMgY29kZSBpbiBzd2l0Y2hlcyB0byBjaGVjayBSQTxicj4NCmFuZCBw cmV2ZW50IFJBIHNwb29maW5nIC0tIGUuZy4sIFJBLUd1YXJkLiBBbGxvd2luZyB0aGUgb3B0aW9u IGluIFJlZGlyZWN0PGJyPg0KbWVzc2FnZXMgY291bGQgdmVyeSB3ZWxsIGJ5cGFzcyB0aGUgUkEg c3BlY2lmaWMgY2hlY2tzLiBEb2Vzbid0IHRoYXQgb3Blbjxicj4NCnRoZSBwYXRoIGZvciBuZXcg YXR0YWNrcz8gU2hvdWxkIHlvdSBub3Qgc2F5IHNvbWV0aGluZyBhYm91dCB0aGF0IGluIHRoZTxi cj4NCnNlY3VyaXR5IHNlY3Rpb24/IEhvdyBhYm91dCBzcGVjaWZpYyBtaXRpZ2F0aW9ucywgc3Vj aCBhcyBzYW5pdHkgY2hlY2tzIHdoZW48YnI+DQpwcm9jZXNzaW5nIHJlZGlyZWN0IG1lc3NhZ2Vz PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KU2luY2UgSVAgd2lsbCBzdGlsbCBvcGVyYXRlIGNvcnJlY3RseSBpZiB0cmFuc21pc3Npb24g b2YgUmVkaXJlY3QgbWVzc2FnZXMgaXM8YnI+DQpzb21laG93IHN1cHByZXNzZWQgKGkuZS4sIGRl bmlhbCBvZiBSZWRpcmVjdCBzZXJ2aWNlKSwgdGhlIG1vcmUgc2VyaW91czxicj4NCnRocmVhdCB0 byBiZSBjb25zaWRlcmVkIGlzIHNwb29maW5nLiBIZXJlIGlzIHdoYXQgY3VycmVudGx5IGFwcGVh cnMgdW5kZXI8YnI+DQpTZWN1cml0eSBDb25zaWRlcmF0aW9uczo8YnI+DQo8YnI+DQombmJzcDsm bmJzcDsmcXVvdDtTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgUmVkaXJlY3QgbWVzc2FnZXMg dGhhdCBpbmNsdWRlIFJJT3MgYXJlPGJyPg0KJm5ic3A7Jm5ic3A7dGhlIHNhbWUgYXMgZm9yIGFu eSBJUHY2IE5EIG1lc3NhZ2VzIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDExIG9mPGJyPg0KJm5i c3A7Jm5ic3A7W1JGQzQ4NjFdLiAmbmJzcDtOYW1lbHksIHRoZSBwcm90b2NvbCBtdXN0IHRha2Ug bWVhc3VyZXMgdG8gc2VjdXJlIElQdjYgTkQ8YnI+DQombmJzcDsmbmJzcDttZXNzYWdlcyBvbiBs aW5rcyB3aGVyZSBzcG9vZmluZyBhdHRhY2tzIGFyZSBwb3NzaWJsZS48YnI+DQo8YnI+DQombmJz cDsmbmJzcDtBIHNwb29mZWQgUmVkaXJlY3QgbWVzc2FnZSBjb250YWluaW5nIG5vIFJJT3MgY291 bGQgY2F1c2UgY29ycnVwdGlvbjxicj4NCiZuYnNwOyZuYnNwO2luIHRoZSBob3N0J3MgZGVzdGlu YXRpb24gY2FjaGUgd2hpbGUgYSBzcG9vZmVkIFJlZGlyZWN0IG1lc3NhZ2U8YnI+DQombmJzcDsm bmJzcDtjb250YWluaW5nIFJJT3MgY291bGQgY29ycnVwdCB0aGUgaG9zdCdzIHJvdXRpbmcgdGFi bGVzLiAmbmJzcDtXaGlsZSB0aGU8YnI+DQombmJzcDsmbmJzcDtsYXR0ZXIgd291bGQgc2VlbSB0 byBiZSBhIG1vcmUgb25lcm91cyByZXN1bHQsIHRoZSBwb3NzaWJpbGl0eSBmb3I8YnI+DQombmJz cDsmbmJzcDtjb3JydXB0aW9uIGlzIHVuYWNjZXB0YWJsZSBpbiBlaXRoZXIgY2FzZS4mcXVvdDs8 YnI+DQo8YnI+DQpTbywgZnJvbSB0aGUgZmlyc3QgcGFyYWdyYXBoLCB3ZSBjYW4gc2VlIHRoYXQg dGhlIHByb3RvY29sIG11c3QgdGFrZTxicj4NCm1lYXN1cmVzIHRvIHNlY3VyZSBJUHY2IE5EIG1l c3NhZ2VzIG9uIGxpbmtzIHdoZXJlIHNwb29maW5nIGF0dGFja3M8YnI+DQphcmUgcG9zc2libGUu IFRoZSBzZWNvbmQgcGFyYWdyYXBoIHRoZW4gYW5hbHl6ZXMgdGhlIGNvbnNlcXVlbmNlcyBvZjxi cj4NCndoYXQgY291bGQgaGFwcGVuIGlmIGEgc3Bvb2ZpbmcgYXR0YWNrIHdlcmUgc3VjY2Vzc2Z1 bCBhbmQgd2Ugc2VlIHRoYXQ8YnI+DQp0aGVyZSBhcmUgdW5hY2NlcHRhYmxlIG5lZ2F0aXZlIGNv bnNlcXVlbmNlcyBmb3IgYm90aCB0cmFkaXRpb25hbDxicj4NClJlZGlyZWN0cyBhbmQgUmVkaXJl Y3RzIHRoYXQgaW5jbHVkZSBSSU9zLjxicj4NCjxicj4NClRoZSB0ZXh0IHN0b3BzIHNob3J0IG9m IHNheWluZyB0aGF0ICZxdW90O25vIFJlZGlyZWN0cyBvZiBhbnkga2luZCBzaG91bGQgYmU8YnI+ DQp1c2VkIG9uIGxpbmtzIHdoZXJlIHNwb29maW5nIGF0dGFja3MgYXJlIHBvc3NpYmxlJnF1b3Q7 LiBXb3VsZCBhZGRpbmcgYTxicj4NCnN0YXRlbWVudCBzdWNoIGFzIHRoaXMgYWRkcmVzcyB0aGUg Y29uY2Vybj88YnI+DQo8YnI+DQpUaGFua3MgLSBGcmVkPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmZy ZWQubC50ZW1wbGluQGJvZWluZy5jb20iPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208L2E+PGJy Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwv YT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+QmVzdCBSZWdhcmRzPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMjIyMjIyIj4sJm5ic3A7PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwMDAiPtmF2LkNCiDY qtit2YrYp9iq2Yo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibHVlIj5aaWVkIEJPVVpJUkk8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPtiMJm5i c3A7PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM5OTAwMDAiPtiy2YrYp9ivDQog2KjZiNiy2YrYsdmKPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+SVNF VCBDaGFyZ3VpYSwgVHVuaXNpZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIy Ij48YSBocmVmPSJodHRwOi8vd3d3LmJvdXppcmkudG4vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxMTU1Q0MiPnd3dy5ib3V6aXJpLnRuPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_c8baed16b3dc46d2a667614310f0334dXCH150608nwnosboeingcom_-- From nobody Wed Jan 11 21:03: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 A6A4C129456 for ; Wed, 11 Jan 2017 21:03:28 -0800 (PST) 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 SIsUvOHYkaO1 for ; Wed, 11 Jan 2017 21:03:26 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE15812941E for ; Wed, 11 Jan 2017 21:03:26 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4BB4380144; Thu, 12 Jan 2017 06:03:16 +0100 (CET) Subject: Re: update to rfc2464bis To: Bob Hinden , IPv6 List References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <54156254-4bfd-d27f-a37d-7efa45cad218@si6networks.com> Date: Thu, 12 Jan 2017 01:59:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:03:28 -0000 Hi, Bob, I agree with your view. Some further comments below: On 01/09/2017 05:40 PM, Bob Hinden wrote: > Hi, > > Based on update from draft-ietf-6man-default-iids (currently in RFC > Editor queue) I changed the first two paragraphs of Section 4 of > to: > > 4. Stateless Autoconfiguration > > The default approach to create stable Interface Identifiers > [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet > interface should be based on [RFC7217]. maybe s/should be based on/is spaciefied in/ ? > It is not recommended that Interface Identifiers for an Ethernet > interface be based on IEEE MAC-layer addresses. Maybe s/It is not recommended/Nodes should not/ ? Maybe a reference to default-iids could be useful here (in addition to the text). > Earlier versions of > this document described a method of forming interface identifiers > derived from IEEE MAC-layer addresses called Modified EUI-64 format. > This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is > no longer recommended. > > Instead of having it pointing to , the > new text points to RFC7271. I thought this was better as Section 3 > of says the RFC2464 should now follow > RFC7271 (including should use RFC7217 and should not use stable > link-layer address). Avoids a extra hope so to speak. Agreed. > I think the intent of is captured in > the text in the new -01 version. > > Comments? Looks fine, but please check the small suggestions above. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 11 21:21: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 7B2EF12946C for ; Wed, 11 Jan 2017 21:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Jl7BWurnL6XM for ; Wed, 11 Jan 2017 21:21:47 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C4A12945D for ; Wed, 11 Jan 2017 21:21:47 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id t8so5800519vke.3 for ; Wed, 11 Jan 2017 21:21:47 -0800 (PST) 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=RZg5mI3Hvl7mfcMkRi//NS5in3gJWh6iITO//TLIu5E=; b=CtRoxHiC6OpxHV+IKzXlPzdn5QQvWzFXEIFNPVzhrb+5G4GhW19tN2Rtl2aldu8g06 /aXPCGLZUUqZkjlzCk/b3IMA+OM/nnagBUCMj/ObFDORpGGVPg0py0TRIa1a94oJidGx NRVYqf9nAhQslj8X+tyJXX3luv9Sl6cCpKx+e2hBceNAG+FWhb+uZPaK32qi97He6h5x gOx5tPSC1c48tqIY/XSh3tc9huU9pPiJ+jGbyPWtpRT/fmhlkP7HveiUA0rtUe3OQp0r a3cMUUzEtFG1b6ILp5uUc9SAc6PLzlji84at/rV9FsGH/RGb49z/IpFv3mfWbMVPhVf7 4AKQ== 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=RZg5mI3Hvl7mfcMkRi//NS5in3gJWh6iITO//TLIu5E=; b=jBtfRPtkQdYXNPKvNDXKmYdvv3S4OikBS82nspi+Ddhezw0DFAFA1pofmHpVP+zHaj 8sTiQgbtyVaogZmyuq9u6Ec5jl7vUdbpuAl2zzLAdx9IC8oxgy3LrsfXPO5RkRV9sy4O tyzOFaZsU1sjwUr97SlwRd1HrUo/ItiaBcMOmW1wicxV57xnWg4b6XYwTi7vkcfqLcAS Okam64ep7J5N3+/sE7u2N+HdGLzcXM+AbsXllWqkdSo1pxTFsFbDZSwlFb2grH2b5kYh p7nBJDhov825NsFhZX72+XFH5Ypstmbypd8HKWhbwmJ2B7Fo9XzIvaENVSs+q/xQupvg YIfg== X-Gm-Message-State: AIkVDXLJ2rHVgeI4TRs639kgbvzv3A0xVGk7Miq71Joocyuq9m89tWkiwnccC3NVTWmKaIYeAg3LHdLlf+x5Gl6g X-Received: by 10.31.137.68 with SMTP id l65mr5933564vkd.155.1484198506146; Wed, 11 Jan 2017 21:21:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Wed, 11 Jan 2017 21:21:25 -0800 (PST) In-Reply-To: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 14:21:25 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Bob Hinden Content-Type: multipart/alternative; boundary=001a11441656bc83e50545dee47a Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:21:48 -0000 --001a11441656bc83e50545dee47a Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 5:40 AM, Bob Hinden wrote: > It is not recommended that Interface Identifiers for an Ethernet > interface be based on IEEE MAC-layer addresses. Please include the word "stable" in this sentence. (See below.) > Earlier versions of > this document described a method of forming interface identifiers > derived from IEEE MAC-layer addresses called Modified EUI-64 format. > This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is > no longer recommended. > Based on my reading of draft-ietf-6man-default-iids-16 , it's not correct to say that this approach is "not recommended". This approach is not recommended for use with stable MAC addresses, but there is no recommendation against using it for non-stable MAC addresses. We do recommended that nodes use RFC7217 addresses by default, but only if the node wishes to create stable addresses, and there is no requirement that a node do so. --001a11441656bc83e50545dee47a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 10, 2017 at 5:40 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
=C2=A0 = =C2=A0It is not recommended that Interface Identifiers for an Ethernet
=C2=A0 =C2=A0interface be based on IEEE MAC-layer addresses.

Please include the word "stable" in this senten= ce. (See below.)
=C2=A0
=C2=A0 =C2=A0Earlier versions of
=C2=A0 =C2=A0this document described a method of forming interface identifi= ers
=C2=A0 =C2=A0derived from IEEE MAC-layer addresses called Modified EUI-64 f= ormat.
=C2=A0 =C2=A0This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] = and is
=C2=A0 =C2=A0no longer recommended.

Bas= ed on my reading of draft-ietf-6man-default-iids-16 , it's not correct = to say that this approach is "not recommended". This approach is = not recommended for use with stable MAC addresses, but there is no recommen= dation against using it for non-stable MAC addresses. We do recommended tha= t nodes use RFC7217 addresses by default, but only if the node wishes to cr= eate stable addresses, and there is no requirement that a node do so.
=
--001a11441656bc83e50545dee47a-- From nobody Wed Jan 11 23:28: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 5E3B5129474; Wed, 11 Jan 2017 23:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1REjHD6a70o; Wed, 11 Jan 2017 23:28:31 -0800 (PST) Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.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 104321270B4; Wed, 11 Jan 2017 23:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding: Message-Id:References:To;i=tsahara@iij.ad.jp;s=omgo2;t=1484206107;x= 1485415707; bh=MmYVYqnvZDJviW/WJUhjbswD7vFi3Aq6gCU103/g0yE=; b=Vv2O7/vVTSXQLMMW 5kr+73bJ4IIb2Xi8z6VymBDcUj3eI12HAtOqq+zcnJNsplLcud/n6Zh/2s5OJSPcRJh5EemA5jo8n AGVC8GAvh0Kud92V9I/HsMaX2vY8xfwrWvkl2i52KaK4ZwoKVXRUUqVub8heY4DDw8sEd4175Qcl0 5NhZZT4FNya8dfgp+BSGLK4rMSFehK80D3435fiNBLk5PhHVH7DyuHio1Av9s6CEc6qwMxI701pr3 c98PUuyQzLTzaD6Hl8gqfQ9yZ4Qmfz7W6IQM+MpnUAecqbzI4r0WMt2SVuP//3nIRbdEHvMz7tVwS Z+Gt5wBa2bJ/OhyRyA==; Received: by omgo.iij.ad.jp (mo900) id v0C7SRps012210; Thu, 12 Jan 2017 16:28:27 +0900 X-MXL-Hash: 5877301a50347d82-0feda34deffb7ae393f185bb3107c5c694651757 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [Int-area] Route Information Options in Redirect Messages From: Tomoyuki Sahara In-Reply-To: Date: Thu, 12 Jan 2017 16:28:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <113477DD-778C-4C0E-899C-A75C8D04A878@iij.ad.jp> References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: INT Area , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:28:36 -0000 Hi, Fred > If the concern is for backwards compatibility with legacy deployments, = the > proposal honors backwards compatibility per RFC4861. What do you = think? =46rom the section 3. of the draft: "The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; " RIO options in Redirect Message are not "unrecognized" options but are "not specified to be used with Redirect memssages". The next pragraph in RFC4861 is better text to be quoted: The contents of any defined options that are not specified to be used with Redirect messages MUST be ignored and the packet processed as normal. The only defined options that may appear are the Target Link-Layer Address option and the Redirected Header option. ( https://tools.ietf.org/html/rfc4861#page-74 ) Once the draft is published as a RFC, it shall update the second = sentence. Thanks, Tomoyuki From nobody Wed Jan 11 23:37: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 732391294B4 for ; Wed, 11 Jan 2017 23:37:25 -0800 (PST) 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 8hWcMS6cvnRL for ; Wed, 11 Jan 2017 23:37:23 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4644E129474 for ; Wed, 11 Jan 2017 23:37:23 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1B2B282C2B; Thu, 12 Jan 2017 08:37:18 +0100 (CET) Subject: Re: update to rfc2464bis To: Lorenzo Colitti , Bob Hinden References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> Date: Thu, 12 Jan 2017 04:20:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:37:25 -0000 Lorenzo, On 01/12/2017 02:21 AM, Lorenzo Colitti wrote: > On Tue, Jan 10, 2017 at 5:40 AM, Bob Hinden > wrote: > > It is not recommended that Interface Identifiers for an Ethernet > interface be based on IEEE MAC-layer addresses. > > > Please include the word "stable" in this sentence. (See below.) > > > Earlier versions of > this document described a method of forming interface identifiers > derived from IEEE MAC-layer addresses called Modified EUI-64 format. > This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is > no longer recommended. > > > Based on my reading of draft-ietf-6man-default-iids-16 , it's not > correct to say that this approach is "not recommended". This approach is > not recommended for use with stable MAC addresses, but there is no > recommendation against using it for non-stable MAC addresses. I agree this part of your comment. > We do > recommended that nodes use RFC7217 addresses by default, but only if the > node wishes to create stable addresses, and there is no requirement that > a node do so. So far, the current specs essentially require that. RFC4941 (the only spec we have for non-temporary addresses) require that the be generated along with the traditional (stable) addresses. FWIW, I do think there are scenarios in which you might want to do temporary-only, but we certainly need an update to the current specs in that regard (and guidance regarding where to use each). That aside, in the context of temp-only addresses, doing Modified-EUI64 based on a randomized MAC address is still a bad idea: 1) It wastes 18 bits of entropy (0xfffe, plus g/l and u/m) 2) Unnecessarily leaks what you're doing in layer-2, at layer 3. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 00:24: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 4EC071294C2 for ; Thu, 12 Jan 2017 00:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 vY9OFppZDE5A for ; Thu, 12 Jan 2017 00:24:42 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA48512944F for ; Thu, 12 Jan 2017 00:24:42 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id x75so7879436vke.2 for ; Thu, 12 Jan 2017 00:24:42 -0800 (PST) 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=BOxHdZ5drzn0KJk8Uj/8dofTEPdJRASF7mUwjDPN9y4=; b=sB241Y4XXfeOV9EwHB0VsyeTRXuGzBG5sOfQxqsgRchYZd9wojcgSbCBGz6M6wS6DP 4KuAfAWTv3iBwb5+ONSdj1rD1qpPuzJrt+a+pEDdVsT1+QQ+erNl9/o02zfZNgoSqr3A JB8ol8Yk8qQBrKkCojmTa+F1FIKx5+LIZiD+NyaCfAy+/n0AgiHUFBhKHr1lpSFG5L52 HbbUUMj42zbW2EF17IlQFcvt6Xue7Pi1gzZ/kceFWeyrhTeLiUu5oPLWpI1hVfmlgvDi t37nSxhu4+iGhrx/GyNOzAqrmtPWGk0nWKORcgqjJimvUBQYdY1I561h44jm2vnDPvX4 5KxA== 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=BOxHdZ5drzn0KJk8Uj/8dofTEPdJRASF7mUwjDPN9y4=; b=i5Lm+Qd/dM2FcnrBVxVwnfanNaLOq0tofZ7HZ7nUbAuzjyxB8Js3+/5v3iO7XHb64R KZHbdRey6mgpibF5/PaFZauMjafkcY6s4vCbp2BycZsDx2coP3dD++jScnHFWnt1QdeN snIL5XUif8suf/aB99cYvM9zfEND2sSm3VFN4Xol+GBfoCrReq/rqkel3MPDMLA/Wnvj 1RsfQ6G9ozLfRBUhNpIcCoxhr6fF1VbtQu4oOKraGCUBLzvyBMGYGTF1LLoRHqw2o0hl 1HHMEkCkVAqlxt49Ui9efKfPQQLUKSDCjp72SUpIoh4eA7jBXdPeyG4WVqp3KPlWMF54 un4A== X-Gm-Message-State: AIkVDXKVqt28VYQzv5zhmEEab8Ok/4B0yijXXSEgzlvzZYUe/FdCt7JchganSG55UqomqVRJIbcvBsV5oAY5MtDj X-Received: by 10.31.72.69 with SMTP id v66mr6247910vka.156.1484209481717; Thu, 12 Jan 2017 00:24:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 00:24:21 -0800 (PST) In-Reply-To: <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 17:24:21 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114d9c6eee87ee0545e1724f Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 08:24:45 -0000 --001a114d9c6eee87ee0545e1724f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 4:20 PM, Fernando Gont wrote: > > We do > > recommended that nodes use RFC7217 addresses by default, but only if the > > node wishes to create stable addresses, and there is no requirement that > > a node do so. > > So far, the current specs essentially require that. RFC4941 (the only > spec we have for non-temporary addresses) require that the be generated > along with the traditional (stable) addresses. > I don't see what RFC 4941 has to do with this discussion. RFC4941 is a method of generating temporary addresses. It is not required to be used, and it is not the only way of forming IP addresses that can change over time. FWIW, I do think there are scenarios in which you might want to do > temporary-only, but we certainly need an update to the current specs in > that regard (and guidance regarding where to use each). > There are lots of ways of forming interface identifiers. We should absolutely not rule out the ability to form IIDs from non-stable MAC addresses (IIRC the text in default-iids was carefully modified to ensure that that would still be possible, based on substantial discussions in the WG), and we should *absolutely* not say that the only possible form of interface identifiers on an Ethernet interface are RFC7217 and RFC4941. > That aside, in the context of temp-only addresses, doing Modified-EUI64 > based on a randomized MAC address is still a bad idea: > I am not going to rehash that argument here. Everything we had to say about that is in the archives. --001a114d9c6eee87ee0545e1724f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 12, 2017 at 4:20 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> We do
> recommended that nodes use RFC7217 addresses by default, but only if t= he
> node wishes to create stable addresses, and there is no requirement th= at
> a node do so.

So far, the current specs essentially require that. RFC4941 (the onl= y
spec we have for non-temporary addresses) require that the be generated
along with the traditional (stable) addresses.

I don't see what RFC 4941 has to do with this discussion. RFC49= 41 is a method of generating temporary addresses. It is not required to be = used, and it is not the only way of forming IP addresses that can change ov= er time.

FWIW, I do think there are scenarios in which you might want to do
temporary-only, but we certainly need an update to the current specs in
that regard (and guidance regarding where to use each).

There are lots of ways of forming interface identifiers. W= e should absolutely not rule out the ability to form IIDs from non-stable M= AC addresses (IIRC the text in default-iids was carefully modified to ensur= e that that would still be possible, based on substantial discussions in th= e WG), and we should *absolutely* not say that the only possible form of in= terface identifiers on an Ethernet interface are RFC7217 and RFC4941.
=
=C2=A0
That asi= de, in the context of temp-only addresses, doing Modified-EUI64
based on a randomized MAC address is still a bad idea:

I am not going to rehash that argument here. Everything we = had to say about that is in the archives.
--001a114d9c6eee87ee0545e1724f-- From nobody Thu Jan 12 01:21: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 412F51294CE for ; Thu, 12 Jan 2017 01:21:44 -0800 (PST) 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 p1-9N-uaNW8S for ; Thu, 12 Jan 2017 01:21:42 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CCD126CD8 for ; Thu, 12 Jan 2017 01:21:42 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 476D782AB8; Thu, 12 Jan 2017 10:21:35 +0100 (CET) Subject: Re: update to rfc2464bis To: Lorenzo Colitti References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> Date: Thu, 12 Jan 2017 06:21:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:21:44 -0000 On 01/12/2017 05:24 AM, Lorenzo Colitti wrote: > On Thu, Jan 12, 2017 at 4:20 PM, Fernando Gont > wrote: > > > We do > > recommended that nodes use RFC7217 addresses by default, but only if the > > node wishes to create stable addresses, and there is no requirement that > > a node do so. > > So far, the current specs essentially require that. RFC4941 (the only > spec we have for non-temporary addresses) require that the be generated > along with the traditional (stable) addresses. > > > I don't see what RFC 4941 has to do with this discussion. RFC4941 is a > method of generating temporary addresses. It is not required to be used, > and it is not the only way of forming IP addresses that can change over > time. If you use temp-only, that means the inability to have e.g. long-lived SSH sessions. I don't think that's the current operating "model", even less for IPv6. > FWIW, I do think there are scenarios in which you might want to do > temporary-only, but we certainly need an update to the current specs in > that regard (and guidance regarding where to use each). > > > There are lots of ways of forming interface identifiers. We should > absolutely not rule out the ability to form IIDs from non-stable MAC > addresses (IIRC the text in default-iids was carefully modified to > ensure that that would still be possible, based on substantial > discussions in the WG), and we should *absolutely* not say that the only > possible form of interface identifiers on an Ethernet interface are > RFC7217 and RFC4941. Clearly, default-iids talks about stable-iids, and the default algorithm for such iids. And nobody said otherwise. So far, the only two standardized algorithms for generating IIDs with SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64). Clearly, you can hack your code and commit it. Being that this is standardization body, I would expect that we're agree on standardizing reasonable approaches, and calling bad approaches as such. Better to have us discuss approaches and std'ize them, that have each vendor come up with their own (possibly flawed) approach. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 01:58: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 F14C7120725 for ; Thu, 12 Jan 2017 01:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 b2AdGVQrcTpE for ; Thu, 12 Jan 2017 01:58:02 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 DF6351294C8 for ; Thu, 12 Jan 2017 01:58:01 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id y9so10511933uae.2 for ; Thu, 12 Jan 2017 01:58:01 -0800 (PST) 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=I3DesrN3NWv8Mbaw+R/XreCU9+UuRnaOmiYCdxBbkFg=; b=pNA5U6pLiyJENuw/+nI0RMTz4xzWqkbUiVh38RM7jKnIM3KhnrNgHBXDdeu143fbzp +eQu+mbiR+7WZMKZFtSya6UrDGupHf35QWEI9RtJwSWPlNkJApJ9nZn65HKh7RmJuIzk 0Hysl1BMknrIvvC7UcxzCP62VEo6G2jRtwB/4A8JJPeG6F24HvmWK11ldJAFikmETGbH s4SJElyUW5Kg6a1qNK7deNEwzU+tkHv/pS8SRFwksAX6/TADQ8pNga08xydugwBCTrN+ 7d7tg4IRtkxB5n5Ogn3y6L+72vjky3PPL2EqXiMNKkrq1HBE1nrp3ld4UFm9y8+n03eQ 8itw== 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=I3DesrN3NWv8Mbaw+R/XreCU9+UuRnaOmiYCdxBbkFg=; b=O047hlNry8uh10Ntg5+yHMv02Tw1L+2ElWmsHIX47qZvQgsxYKtLy3Ty5lXNxxs1XO MSOC99mfTUGn619sNTDTt0xnqemBcXobrstr028tk3v9CWQIMml5boLKPuOs22v4lE14 crGgJxNU9pO1VEl6mImRnJnKY4oW6p0vujAa+J294Sqjsdw/2SIubTyriwE/WYzOmwQU 9pvdKPDRzbuUnZzSwe8sGVpTYpIpO28fQ0Sf+y96Qdz5Y2jS2hvMYZlZBy8p4uRp5ZaZ /fWUCeUmgdNjv9IGwd8m5F5AazkYYvziaBqGqdtKAsujGWCp6dptnViZBdXGTskUM1Su TW6g== X-Gm-Message-State: AIkVDXIXMSZ80hGUhjPJ/c8ukk2slQQo+OLn9pp4ilWJeG6W30tnZJIAJG+xzgrGyti2ADPk5oMHFcAaT7YnTDRi X-Received: by 10.176.5.138 with SMTP id e10mr5708741uae.109.1484215080826; Thu, 12 Jan 2017 01:58:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 01:57:40 -0800 (PST) In-Reply-To: <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 18:57:40 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c124794aa06dd0545e2c012 Archived-At: Cc: IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:58:07 -0000 --94eb2c124794aa06dd0545e2c012 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 6:21 PM, Fernando Gont wrote: > > I don't see what RFC 4941 has to do with this discussion. RFC4941 is a > > method of generating temporary addresses. It is not required to be used, > > and it is not the only way of forming IP addresses that can change over > > time. > > If you use temp-only, that means the inability to have e.g. long-lived > SSH sessions. I don't think that's the current operating "model", even > less for IPv6. > I don't see why we should forbid this. It's a legitimate implementation choice, and has excellent privacy properties :-) > So far, the only two standardized algorithms for generating IIDs with > SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64). > Clearly, you can hack your code and commit it. Being that this is > standardization body, I would expect that we're agree on standardizing > reasonable approaches, and calling bad approaches as such. > Sure. If you can find rough consensus to say all other methods of generating IIDs are bad and should not be used, the IETF will publish a document saying that. My bet is that you won't. To get back to the original point: in the current state of the documents that we have published or are about to publish (e.g., the default-iids draft), as reflecting the consensus call sin th it's not true that modified EUI-64 is not recommended. It's only not recommended if you use stable link-layer addresses. Bob, Ole, Suresh: can we also amend or remove this text in 4291bis before we publish it? I think it's an oversight because there was clear consensus in 6man (Fernando being in the rough) that it was OK to use modified EUI-64 with non-stable MAC addresses: Earlier versions of this document described a method of forming interface identifiers derived from IEEE MAC-layer addresses call Modified EUI-64 format. These are described in Appendix A and are no longer recommended. --94eb2c124794aa06dd0545e2c012 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 12, 2017 at 6:21 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> I don't see what RFC 4941 = has to do with this discussion. RFC4941 is a
> method of generating temporary addresses. It is not required to be use= d,
> and it is not the only way of forming IP addresses that can change ove= r
> time.

If you use temp-only, that means the inability to have e.g. long-liv= ed
SSH sessions. I don't think that's the current operating "mode= l", even
less for IPv6.

I don't see why we s= hould forbid this. It's a legitimate implementation choice, and has exc= ellent privacy properties :-)
=C2=A0
So far, the only two standardized algorithms for= generating IIDs with
SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64).
Clearly, you can hack your code and commit it. Being that this is
standardization body, I would expect that we're agree on standardizing<= br> reasonable approaches, and calling bad approaches as such.
=

Sure. If you can find rough consensus to say all other = methods of generating IIDs are bad and should not be used, the IETF will pu= blish a document saying that. My bet is that you won't.

<= /div>
To get back to the original point: in the current state of the do= cuments that we have published or are about to publish (e.g., the default-i= ids draft), as reflecting the consensus call sin th it's not true that = modified EUI-64 is not recommended. It's only not recommended if you us= e stable link-layer addresses.

Bob, Ole, Suresh: c= an we also amend or remove this text in 4291bis before we publish it? I thi= nk it's an oversight because there was clear consensus in 6man (Fernand= o being in the rough) that it was OK to use modified EUI-64 with non-stable= MAC addresses:

=C2=A0 =C2=A0Earlier versions= of this document described a method of forming
=C2=A0 =C2=A0inte= rface identifiers derived from IEEE MAC-layer addresses call
=C2= =A0 =C2=A0Modified EUI-64 format.=C2=A0 These are described in Appendix A a= nd are no
=C2=A0 =C2=A0longer recommended.
--94eb2c124794aa06dd0545e2c012-- From nobody Thu Jan 12 02:25: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 6B6BC129525 for ; Thu, 12 Jan 2017 02:25:39 -0800 (PST) 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 9JiCspDVDbx4 for ; Thu, 12 Jan 2017 02:25:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85B21294C2 for ; Thu, 12 Jan 2017 02:25:36 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E6337836DC; Thu, 12 Jan 2017 11:25:31 +0100 (CET) Subject: Re: update to rfc2464bis To: Lorenzo Colitti References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 12 Jan 2017 07:25:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:25:39 -0000 On 01/12/2017 06:57 AM, Lorenzo Colitti wrote: > On Thu, Jan 12, 2017 at 6:21 PM, Fernando Gont > wrote: > > > I don't see what RFC 4941 has to do with this discussion. RFC4941 is a > > method of generating temporary addresses. It is not required to be used, > > and it is not the only way of forming IP addresses that can change over > > time. > > If you use temp-only, that means the inability to have e.g. long-lived > SSH sessions. I don't think that's the current operating "model", even > less for IPv6. > > > I don't see why we should forbid this. It's a legitimate implementation > choice, and has excellent privacy properties :-) I'm not saying we should forbid this -- actually, there are scenarios where it should probably be the recommended approach. But that's not the operating model we have right now -- that's the point. > So far, the only two standardized algorithms for generating IIDs with > SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64). > Clearly, you can hack your code and commit it. Being that this is > standardization body, I would expect that we're agree on standardizing > reasonable approaches, and calling bad approaches as such. > > Sure. If you can find rough consensus to say all other methods of > generating IIDs are bad and should not be used, the IETF will publish a > document saying that. My bet is that you won't. I'm not saying that. For instance, if you want temp addresses, and you decide to send the 64 bits with a PRNG of your choice, that's fine. If your goal is privacy and you decide to waste 18 bits 'cause you want to stick to modified-eui64, you're doing a lousy job. Essentially, it all boils down to "use as many bits as you're given for your unpredictable id, and do not reuse identifiers from other layers". Me, i don't care what you use as long as you stick to that. > To get back to the original point: in the current state of the documents > that we have published or are about to publish (e.g., the default-iids > draft), as reflecting the consensus call sin th it's not true that > modified EUI-64 is not recommended. It's only not recommended if you use > stable link-layer addresses. > > Bob, Ole, Suresh: can we also amend or remove this text in 4291bis > before we publish it? I think it's an oversight because there was clear > consensus in 6man (Fernando being in the rough) that it was OK to use > modified EUI-64 with non-stable MAC addresses: > > Earlier versions of this document described a method of forming > interface identifiers derived from IEEE MAC-layer addresses call > Modified EUI-64 format. These are described in Appendix A and are no > longer recommended. All these documents are about generating stable addresses, not temporary addresses. So I'm not sure why the text should be removed. The text in all this documents ae about stable addresses. IETF-wise, the only doc that is about temporary addresses is RFC4941. Hence the text seems correct to me. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 03:09:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9676D1293F8 for ; Thu, 12 Jan 2017 03:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 o8D2ZfbJMibI for ; Thu, 12 Jan 2017 03:08:59 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFFD120725 for ; Thu, 12 Jan 2017 03:08:58 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 35so11621809uak.1 for ; Thu, 12 Jan 2017 03:08:58 -0800 (PST) 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=mHsHD+c9E3dEbjGQdN1qPbgWOrQbTvgkuQ2mgZ6mHwA=; b=EzKZbPOmgpV9J5vjaVLxo76EPo9B0711c2MNjSTz0xX+lN97eR+6ZrRkkpM7chcqVV ZXz63FALY18yAEX6/Fj1CLLRhDiGN1msuno3+wgR+rrbpNxE9tDKs0bHSGGSwNgxE9hG jcgoidB8FMEVkxrZ4+Cg51VKJpv8AXGK+K0a3VspmIf35cnnlEOee8g4sclYFpHY+Sye k05S8gNB6SBYvCwYIrUlOYI2ncq1gN21KoOO+fvjQrKKtrWdkRyrgDccGypRt8fXfvQm P14qdCBtbQNjtyzM28lUpU0MhQpIa1Rc4h6JVtWqRU0xly9C8LOA5HBKs5mt+23NTN+y r9kA== 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=mHsHD+c9E3dEbjGQdN1qPbgWOrQbTvgkuQ2mgZ6mHwA=; b=cvOahwY+MVbu7qv4ILztZ1M4XsFmadLRH8Si1e5WUCMae8oTXcV6sCS4Nizf/qBtxN JatEHLcuWEf0Ob9b9O0JD5ckDuP2zcuOLqynyA5FPvXn9bt0xSArB4N6w6Z6NUyJWlr8 TiUe4XwSyhvloLK+2aT7KzgynQwJQiR63TFu2c2nruSD7iHHP/NjHVHUgBpmEmj4lRSX ijaUE1NsguhLKoqAfdMFaaN80oSGO79sd1jtrf8OKSP2z2fXGSjfhTZYQksreAt6I9wV 8zJ8OVNvVUYoOOeifrLFrZoB0Giup78vknVKnsWmXuGBDNgi2GbXQB4s8miKP6Z4f6Et i+Lw== X-Gm-Message-State: AIkVDXLM44S3vCgBFqyXHb+Ee7ILVUT3rw3ur09FN7fuER3uGod9stsMcwzLRaU59eBjbADhiFWSbdNuZnwcFnc2 X-Received: by 10.159.49.27 with SMTP id m27mr7241804uab.72.1484219337706; Thu, 12 Jan 2017 03:08:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 03:08:37 -0800 (PST) In-Reply-To: References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 20:08:37 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Fernando Gont Content-Type: multipart/alternative; boundary=f403045ddf7464dad80545e3be02 Archived-At: Cc: IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 11:09:00 -0000 --f403045ddf7464dad80545e3be02 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont wrote: > > I don't see why we should forbid this. It's a legitimate implementation > > choice, and has excellent privacy properties :-) > > I'm not saying we should forbid this -- actually, there are scenarios > where it should probably be the recommended approach. > > But that's not the operating model we have right now -- that's the point. > The point I am making is that according to current and about-to-be-published specs, a node is free to create addresses that change over time, since nothing forbids it. > > Sure. If you can find rough consensus to say all other methods of > > generating IIDs are bad and should not be used, the IETF will publish a > > document saying that. My bet is that you won't. > > I'm not saying that. For instance, if you want temp addresses, and you > decide to send the 64 bits with a PRNG of your choice, that's fine. If > your goal is privacy and you decide to waste 18 bits 'cause you want to > stick to modified-eui64, you're doing a lousy job. > Good, then we agree that a node is free to create addresses that change over time using schemes that are not described in RFC 7217, RFC 4941, or any other document. > > To get back to the original point: in the current state of the documents > > that we have published or are about to publish (e.g., the default-iids > > draft), as reflecting the consensus call sin th it's not true that > > modified EUI-64 is not recommended. It's only not recommended if you use > > stable link-layer addresses. > > > > Bob, Ole, Suresh: can we also amend or remove this text in 4291bis > > before we publish it? I think it's an oversight because there was clear > > consensus in 6man (Fernando being in the rough) that it was OK to use > > modified EUI-64 with non-stable MAC addresses: > > > > Earlier versions of this document described a method of forming > > interface identifiers derived from IEEE MAC-layer addresses call > > Modified EUI-64 format. These are described in Appendix A and are no > > longer recommended. > > All these documents are about generating stable addresses, not temporary > addresses. So I'm not sure why the text should be removed. The text in > all this documents ae about stable addresses. IETF-wise, the only doc > that is about temporary addresses is RFC4941. Hence the text seems > correct to me. If instead of removing that text we can clarify that it only applies to stable addresses, that works for me. Suggestion: change "These are described in Appendix A and are no longer recommended." to ""These are described in Appendix A and are no longer recommended for stable addresses." The reason the text needs to be changed is because during the discussion of default-iids there was substantial discussion of the use case of using EUI-64 with randomized MAC addresses. There was consensus that this is a use case we want to support, and as a result, the working group concluded that we should change every occurrence of the phrase "based on a link-layer address" to "based on a stable link-layer address" in the default-iids draft. We should make the same distinction in 4291bis and 2464bis: EUI-64 is not recommended for use with stable link-layer addresses, but it can be used with non-stable link-layer addresses. You're certainly entitled to your opinion that using EUI-64 with random MAC addresses is not a good idea, but IETF documents are not based on the opinion of one participants, they are based on rough consensus. --f403045ddf7464dad80545e3be02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 12, 2017 at 7:25 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> I don't see why we s= hould forbid this. It's a legitimate implementation
> choice, and has excellent privacy properties :-)

I'm not saying we should forbid this -- actually, there are scen= arios
where it should probably be the recommended approach.

But that's not the operating model we have right now -- that's the = point.

The point I am making is that ac= cording to current and about-to-be-published specs, a node is free to creat= e addresses that change over time, since nothing forbids it.
=C2= =A0
> Sure. If you can find rough consensu= s to say all other methods of
> generating IIDs are bad and should not be used, the IETF will publish = a
> document saying that. My bet is that you won't.

I'm not saying that. For instance, if you want temp addresses, a= nd you
decide to send the 64 bits with a PRNG of your choice, that's fine. If<= br> your goal is privacy and you decide to waste 18 bits 'cause you want to=
stick to modified-eui64, you're doing a lousy job.

Good, then we agree that a node is free to create addresses= that change over time using schemes that are not described in RFC 7217, RF= C 4941, or any other document.
=C2=A0
> To get back to the original point: in the current state of the docu= ments
> that we have published or are about to publish (e.g., the default-iids=
> draft), as reflecting the consensus call sin th it's not true that=
> modified EUI-64 is not recommended. It's only not recommended if y= ou use
> stable link-layer addresses.
>
> Bob, Ole, Suresh: can we also amend or remove this text in 4291bis
> before we publish it? I think it's an oversight because there was = clear
> consensus in 6man (Fernando being in the rough) that it was OK to use<= br> > modified EUI-64 with non-stable MAC addresses:
>
>=C2=A0 =C2=A0 Earlier versions of this document described a method of f= orming
>=C2=A0 =C2=A0 interface identifiers derived from IEEE MAC-layer address= es call
>=C2=A0 =C2=A0 Modified EUI-64 format.=C2=A0 These are described in Appe= ndix A and are no
>=C2=A0 =C2=A0 longer recommended.

All these documents are about generating stable addresses, not tempo= rary
addresses. So I'm not sure why the text should be removed. The text in<= br> all this documents ae about stable addresses. IETF-wise, the only doc
that is about temporary addresses is RFC4941. Hence the text seems
correct to me.

If instead of removing that = text we can clarify that it only applies to stable addresses, that works fo= r me. Suggestion: change "These are described in Appendix A and are no= longer recommended." to ""These are described in Appendix A= and are no longer recommended for stable addresses."

The reason the text needs to be changed is because during the disc= ussion of default-iids there was substantial discussion of the use case of = using EUI-64 with randomized MAC addresses. There was consensus that this i= s a use case we want to support, and as a result, the working group conclud= ed that we should change every occurrence of the phrase "based on a li= nk-layer address" to "based on a stable link-layer address" = in the default-iids draft. We should make the same distinction in 4291bis a= nd 2464bis: EUI-64 is not recommended for use with stable link-layer addres= ses, but it can be used with non-stable link-layer addresses.
You're certainly entitled to your opinion that using EUI-64= with random MAC addresses is not a good idea, but IETF documents are not b= ased on the opinion of one participants, they are based on rough consensus.=
--f403045ddf7464dad80545e3be02-- From nobody Thu Jan 12 03:31: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 7A8011295B9 for ; Thu, 12 Jan 2017 03:31:36 -0800 (PST) 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 uwYKmyWs9L9M for ; Thu, 12 Jan 2017 03:31:34 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E312B1295A6 for ; Thu, 12 Jan 2017 03:31:33 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 86833836ED; Thu, 12 Jan 2017 12:31:08 +0100 (CET) Subject: Re: update to rfc2464bis To: Lorenzo Colitti References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> Date: Thu, 12 Jan 2017 08:29:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 11:31:36 -0000 On 01/12/2017 08:08 AM, Lorenzo Colitti wrote: > On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont > wrote: > > > I don't see why we should forbid this. It's a legitimate implementation > > choice, and has excellent privacy properties :-) > > I'm not saying we should forbid this -- actually, there are scenarios > where it should probably be the recommended approach. > > But that's not the operating model we have right now -- that's the > point. > > The point I am making is that according to current and > about-to-be-published specs, a node is free to create addresses that > change over time, since nothing forbids it. I guess you're allowed. That does change the operating assumptions, and I wouldn't be surprised to see breakage. > > Sure. If you can find rough consensus to say all other methods of > > generating IIDs are bad and should not be used, the IETF will publish a > > document saying that. My bet is that you won't. > > I'm not saying that. For instance, if you want temp addresses, and you > decide to send the 64 bits with a PRNG of your choice, that's fine. If > your goal is privacy and you decide to waste 18 bits 'cause you want to > stick to modified-eui64, you're doing a lousy job. > > Good, then we agree that a node is free to create addresses that change > over time using schemes that are not described in RFC 7217, RFC 4941, or > any other document. Yes, you're "free" to do your own proprietary thing, which does not follow any IETF stds, I guess. > > To get back to the original point: in the current state of the documents > > that we have published or are about to publish (e.g., the default-iids > > draft), as reflecting the consensus call sin th it's not true that > > modified EUI-64 is not recommended. It's only not recommended if you use > > stable link-layer addresses. > > > > Bob, Ole, Suresh: can we also amend or remove this text in 4291bis > > before we publish it? I think it's an oversight because there was clear > > consensus in 6man (Fernando being in the rough) that it was OK to use > > modified EUI-64 with non-stable MAC addresses: > > > > Earlier versions of this document described a method of forming > > interface identifiers derived from IEEE MAC-layer addresses call > > Modified EUI-64 format. These are described in Appendix A and are no > > longer recommended. > > All these documents are about generating stable addresses, not temporary > addresses. So I'm not sure why the text should be removed. The text in > all this documents ae about stable addresses. IETF-wise, the only doc > that is about temporary addresses is RFC4941. Hence the text seems > correct to me. > > > If instead of removing that text we can clarify that it only applies to > stable addresses, that works for me. Suggestion: change "These are > described in Appendix A and are no longer recommended." to ""These are > described in Appendix A and are no longer recommended for stable addresses." Fine. Isn't the assumption in all these RFCs that the addresses are stable, and that the MAC addresses are unique? > The reason the text needs to be changed is because during the discussion > of default-iids there was substantial discussion of the use case of > using EUI-64 with randomized MAC addresses. There was consensus that > this is a use case we want to support, and as a result, the working > group concluded that we should change every occurrence of the phrase > "based on a link-layer address" to "based on a stable link-layer > address" in the default-iids draft. My read of the discussion is that you didn't want default-iids to ban this case (and maybe there was not more than one or two voices in this direction), and we simply decided to have default-iids fous on stable addresses to be able to do progress on something. Claiming that doing temp adderesses by doing MOdified-EUI64 is streching that outcome quite a bit, IMO. > We should make the same distinction > in 4291bis and 2464bis: EUI-64 is not recommended for use with stable > link-layer addresses, but it can be used with non-stable link-layer > addresses. All this documents talk about stable addresses. Discussing temp addresses in them is actually talking about stuff that simply wasn't there, with operating conditions different from those assummed so far. Again, I sympathize with temp only in scenarios where they make sense. But things like that don't seem within what has been specified so far (i.e., there's work to be done, including analyzing what might break). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 04:19: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 E0A561295C4 for ; Thu, 12 Jan 2017 04:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 PuLi12JVU4sk for ; Thu, 12 Jan 2017 04:19:34 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 0FCBB1295C0 for ; Thu, 12 Jan 2017 04:19:33 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id y9so12755891uae.2 for ; Thu, 12 Jan 2017 04:19:33 -0800 (PST) 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=Xt3+RJgHlqZ3RxdsjtK0h3fHHz8GMjtLjJtlabTwik8=; b=kz8GqvpY/TIaq8Xzo8FsD4HFQ1W0nbL7/NgG0GESo5oOEvNiIiKViWbickUFy1VxES 3j3BvkXDkhSvvyqPt01ispY0CwDcxenEbz86/wLFqSIPDDBytVpeXjsPbD69XMiBPeNX FVGkLkXC65KEO25sA1G8h7Ei3V2xmQhQZhwiY88h+l1hhrU+/f+lGtNR4bEij6ROxG7R vu/dF17kOKVM79DGBMB94XvGGCrXyJLealoSLSYQQpofCv3Swi57n27H211S4fW/Qua/ BGwevyQUU0Srwaybq+9yAhnojbyTgw956IckmqHvl89fhdK6aljpbBZjjaw/xd14chSd 4yEA== 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=Xt3+RJgHlqZ3RxdsjtK0h3fHHz8GMjtLjJtlabTwik8=; b=Tdb1aO/WdX10rvZ/52KljeZV1E7pFdT08qD1M64ZLDE2xM8NNUA0oUGhc+0mzONuf0 YhAFdJhvWkviJCPKYy6JhUAaaUDuAY8rgHPFEpijlNWOtFLc5ROB7outNNSFcIqwWchX 5eMYfDL/qyc+BMePrj67bzctA1zGFfpA8jwWzmmVLkpkbxdvTvFUAlDaC1CjkajLIZwK 9U4OBUP7VxbeI/0+4OIsuTfG6eZMk5wNssoD8xs9O0sqERphoJXwKyHC9nwdmrmJH/Ty OQMqcDGBgN46I4qTFfEOt81KoloPJCzRd+L8Ck80JUMcV2U3TyUIVslAJxkhE4pf0A4w tjmA== X-Gm-Message-State: AIkVDXKRToM4418Yx+h0x7FFNGZCO5fWYcqtYc1eim8Iyho8HFeQfffgliiV/LbIKxJBJC/ziPAQ75sF5cxxqHP6 X-Received: by 10.159.49.27 with SMTP id m27mr7374025uab.72.1484223572884; Thu, 12 Jan 2017 04:19:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 04:19:12 -0800 (PST) In-Reply-To: <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> From: Lorenzo Colitti Date: Thu, 12 Jan 2017 21:19:12 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Fernando Gont Content-Type: multipart/alternative; boundary=f403045ddf74d4a0740545e4ba38 Archived-At: Cc: IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:19:36 -0000 --f403045ddf74d4a0740545e4ba38 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont wrote: > > All these documents are about generating stable addresses, not > temporary > > addresses. So I'm not sure why the text should be removed. The text > in > > all this documents ae about stable addresses. IETF-wise, the only doc > > that is about temporary addresses is RFC4941. Hence the text seems > > correct to me. > > > > If instead of removing that text we can clarify that it only applies to > > stable addresses, that works for me. Suggestion: change "These are > > described in Appendix A and are no longer recommended." to ""These are > > described in Appendix A and are no longer recommended for stable > addresses." > > Fine. Isn't the assumption in all these RFCs that the addresses are > stable, and that the MAC addresses are unique? > Yes, those documents were written when randomized MAC addresses did not yet exist, yes. But those assumptions are not valid today; randomized MAC addresses are not only in use, there are standards track documents that assume their use (e.g., RFC7844). Since we're now republishing these documents, we need to make them reflect the state of the world as it is today, and the revised documents must not assume that MAC addresses are unique and static. > > The reason the text needs to be changed is because during the discussion > > of default-iids there was substantial discussion of the use case of > > using EUI-64 with randomized MAC addresses. There was consensus that > > this is a use case we want to support, and as a result, the working > > group concluded that we should change every occurrence of the phrase > > "based on a link-layer address" to "based on a stable link-layer > > address" in the default-iids draft. > > My read of the discussion is that you didn't want default-iids to ban > this case (and maybe there was not more than one or two voices in this > direction), and we simply decided to have default-iids fous on stable > addresses to be able to do progress on something. Claiming that doing > temp adderesses by doing MOdified-EUI64 is streching that outcome quite > a bit, IMO. > Funny... my read of the discussion is that everyone wanted to support this case and only you didn't (and maybe there was not more than one or two voices in this direction". :-P But seriously: regardless of which of the two interpretations above is correct (likely neither), the fact of the matter is that the text in default-iids says "stable" and that did not happen by chance, but through explicit working group discussion. We have to respect that here. All this documents talk about stable addresses. Discussing temp > addresses in them is actually talking about stuff that simply wasn't > there, with operating conditions different from those assummed so far. > Again: we are republish these documents and we have to do so taking into account things as they are today. Today, the fact of the matter today is that MAC addresses are in use and the documents have to reflect that. --f403045ddf74d4a0740545e4ba38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 12, 2017 at 8:29 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
>=C2=A0 =C2=A0 =C2=A0All these documents are about ge= nerating stable addresses, not temporary
>=C2=A0 =C2=A0 =C2=A0addresses. So I'm not sure why the text should = be removed. The text in
>=C2=A0 =C2=A0 =C2=A0all this documents ae about stable addresses. IETF-= wise, the only doc
>=C2=A0 =C2=A0 =C2=A0that is about temporary addresses is RFC4941. Hence= the text seems
>=C2=A0 =C2=A0 =C2=A0correct to me.
>
> If instead of removing that text we can clarify that it only applies t= o
> stable addresses, that works for me. Suggestion: change "These ar= e
> described in Appendix A and are no longer recommended." to "= "These are
> described in Appendix A and are no longer recommended for stable addre= sses."

Fine. Isn't the assumption in all these RFCs that the addresses = are
stable, and that the MAC addresses are unique?

Yes, those documents were written when randomized MAC addresses did= not yet exist, yes. But those assumptions are not valid today; randomized = MAC addresses are not only in use, there are standards track documents that= assume their use (e.g., RFC7844). Since we're now republishing these d= ocuments, we need to make them reflect the state of the world as it is toda= y, and the revised documents must not assume that MAC addresses are unique = and static.
=C2=A0
> The reason the text needs to be chan= ged is because during the discussion
> of default-iids there was substantial discussion of the use case of > using EUI-64 with randomized MAC addresses. There was consensus that > this is a use case we want to support, and as a result, the working > group concluded that we should change every occurrence of the phrase > "based on a link-layer address" to "based on a stable l= ink-layer
> address" in the default-iids draft.

My read of the discussion is that you didn't want default-iids t= o ban
this case (and maybe there was not more than one or two voices in this
direction), and we simply decided to have default-iids fous on stable
addresses to be able to do progress on something. Claiming that doing
temp adderesses by doing MOdified-EUI64 is streching that outcome quite
a bit, IMO.

Funny... my read of the dis= cussion is that everyone wanted to support this case and only you didn'= t (and maybe there was not more than one or two voices in this direction&qu= ot;. :-P

But seriously: regardless of which of the= two interpretations above is correct (likely neither), the fact of the mat= ter is that the text in default-iids says "stable" and that did n= ot happen by chance, but through explicit working group discussion. We have= to respect that here.

All this documents talk about stable addresses. Discussin= g temp
addresses in them is actually talking about stuff that simply wasn't there, with operating conditions different from those assummed so far.
<= /blockquote>

Again: we are republish these documents and= we have to do so taking into account things as they are today. Today, the = fact of the matter today is that MAC addresses are in use and the documents= have to reflect that.
--f403045ddf74d4a0740545e4ba38-- From nobody Thu Jan 12 04:25: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 B8A181295CB for ; Thu, 12 Jan 2017 04:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abUcmuf9IuyP for ; Thu, 12 Jan 2017 04:25:30 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09C261295C5 for ; Thu, 12 Jan 2017 04:25:29 -0800 (PST) Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cReRb-0000HKC; Thu, 12 Jan 2017 13:25:27 +0100 Message-Id: To: ipv6@ietf.org Subject: Re: update to rfc2464bis From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> In-reply-to: Your message of "Thu, 12 Jan 2017 13:18:56 +0100 ." Date: Thu, 12 Jan 2017 13:25:27 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:25:32 -0000 [Somehow I managed to send this v6ops first :-(] >> So far, the only two standardized algorithms for generating IIDs with >> SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64). >> Clearly, you can hack your code and commit it. Being that this is >> standardization body, I would expect that we're agree on standardizing >> reasonable approaches, and calling bad approaches as such. >> > >Sure. If you can find rough consensus to say all other methods of >generating IIDs are bad and should not be used, the IETF will publish a >document saying that. My bet is that you won't. Personally I'd say "Modified EUI-64 SHOULD NOT be used on new installations. Modified EUI-64 SHOULD be implemented" I think modified EUI-64 with stable MAC addresses has lots of interesting use cases. And it is upto the admin to determine what is the right thing to do. From nobody Thu Jan 12 05:10: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 D7428129615 for ; Thu, 12 Jan 2017 05:10:38 -0800 (PST) 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 qKeWvWeGc00Z for ; Thu, 12 Jan 2017 05:10:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F414129614 for ; Thu, 12 Jan 2017 05:10:35 -0800 (PST) Received: from [192.168.3.88] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 52FC782C25; Thu, 12 Jan 2017 14:10:24 +0100 (CET) Subject: Re: update to rfc2464bis To: Lorenzo Colitti References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <23b2c5c1-955a-8c4f-94ce-4ced83442a57@si6networks.com> Date: Thu, 12 Jan 2017 09:40:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IPv6 List , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:10:39 -0000 On 01/12/2017 09:19 AM, Lorenzo Colitti wrote: > On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont > wrote: > > > All these documents are about generating stable addresses, not temporary > > addresses. So I'm not sure why the text should be removed. The text in > > all this documents ae about stable addresses. IETF-wise, the only doc > > that is about temporary addresses is RFC4941. Hence the text seems > > correct to me. > > > > If instead of removing that text we can clarify that it only applies to > > stable addresses, that works for me. Suggestion: change "These are > > described in Appendix A and are no longer recommended." to ""These are > > described in Appendix A and are no longer recommended for stable addresses." > > Fine. Isn't the assumption in all these RFCs that the addresses are > stable, and that the MAC addresses are unique? > > Yes, those documents were written when randomized MAC addresses did not > yet exist, yes. But those assumptions are not valid today; randomized > MAC addresses are not only in use, there are standards track documents > that assume their use (e.g., RFC7844). Since we're now republishing > these documents, we need to make them reflect the state of the world as > it is today, and the revised documents must not assume that MAC > addresses are unique and static. Traditional slaac is based on such assumption. I'm not saying we should keep that. I'm just saying that the documents we're revising have that assumption in place. And if we want to change such assumption, there's probably more to do than just "generate the iid with this other algorithm, instead". That is, that'd be a change that goes further than what we're doing here. > > The reason the text needs to be changed is because during the discussion > > of default-iids there was substantial discussion of the use case of > > using EUI-64 with randomized MAC addresses. There was consensus that > > this is a use case we want to support, and as a result, the working > > group concluded that we should change every occurrence of the phrase > > "based on a link-layer address" to "based on a stable link-layer > > address" in the default-iids draft. > > My read of the discussion is that you didn't want default-iids to ban > this case (and maybe there was not more than one or two voices in this > direction), and we simply decided to have default-iids fous on stable > addresses to be able to do progress on something. Claiming that doing > temp adderesses by doing MOdified-EUI64 is streching that outcome quite > a bit, IMO. > > Funny... my read of the discussion is that everyone wanted to support > this case and only you didn't (and maybe there was not more than one or > two voices in this direction". :-P > > But seriously: regardless of which of the two interpretations above is > correct (likely neither), the fact of the matter is that the text in > default-iids says "stable" and that did not happen by chance, but > through explicit working group discussion. We have to respect that here. As noted, I'm fine with thes docs xplicitly noting that they talk about stable addresses. That seems to make you have too, so.... (talking about what with temporary MAC addresses would be a different thing, and seems to be "out of scope" of the *current* effort on these bis documents. If you want such work to be expanded, such that these documents also cover temp MACs, I certainly wouldn't oppose... but that doesn't seem the direction in which these documents are going). P.S.: I do thing that we need advice on what to do when... stable+temp? stable only? temp only? there are certainly use cases for each of these combinations... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 12 05:38: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 DCA61127077 for ; Thu, 12 Jan 2017 05:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyQQdnhmSgU8 for ; Thu, 12 Jan 2017 05:38:44 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6513F129636 for ; Thu, 12 Jan 2017 05:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T/XEePnFAe8CUHq/BFomRMlEiR/X3wqFmYyT+ekjh9M=; b=Bv1VRlOiXjZnKpvNkXwzadf1X6JDhFRNksCLtVI6f1Uke7jQwwE/PoLERP4gPTOZMjDEgulhx3P+yEKoNFYZ2NGMFmUD10H7+PeuSiIGttbHzqjgEytV1C/ygTRpC4+njlvDN1dTzKL++D00u2ENIESfB3+x7BGs3/x+6cC1n4c= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-66-wben-1kqMFaau1I73YpD6w-1; Thu, 12 Jan 2017 13:38:33 +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_P384) id 15.1.845.6; Thu, 12 Jan 2017 13:38:31 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2%14]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 13:38:31 +0000 From: Tim Chown To: Lorenzo Colitti Subject: Re: update to rfc2464bis Thread-Topic: update to rfc2464bis Thread-Index: AQHSari/YDPll7o19EGKcdCJAtd5oKE0Uf6AgAAhY4CAABG5gIAAV8eA Date: Thu, 12 Jan 2017 13:38:31 +0000 Message-ID: <0D24BC9F-26DD-4ABF-965A-84C5708B900D@jisc.ac.uk> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 09d30f81-bb1e-4262-d79e-08d43af04cad x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:VcK1ltJy51XKD4wkdGlCjVAtNVZP7zdrzyb6YgnqGvaN/ShdTPYWSoFAFkFl+5Aj10TNmZiIpZbCPR56uUczgO0QHmyWwBHJNf7lUD8FoJyxI2FG34VhijS7FWPlP69fixSS17lNXjTfj+PpLT08yJm6WRRRx48V2vupgrSg5vePF6lkWjmAaNpohlSInIim1yIPlsOBAY094mtMF01rB8kQOdERYRNsl3W0+VHjzKvv/JwFu610pXuE2rNtlAXbGABpGPFvmCAsMpAgmCVjamRqX+W0lMC4sPOOHIZ5yRqSkGzKXcGNBwyl6CIvY5O+abdsiThwBmKPk3Z9YuQ3fa8CH+XW9oclkkLYbiYI6eEBc0EMDVTxP6FnVLDeXC0jZXnlHmghvzM4O8JnKzWPILMgblt5s6sCNs30F6jqcKzn2ZLbniqyuBotABV0c1Z92LXB6TEbuTtqoU717r3C3Q==; 20:lAyXD64HuNbKyPxGwWMMe2fOhZhOwLStNW1uoI5jqzJbIYEVZbAdCIIoj8BtbpgN9STPp5Wzm4yvN7n0LwTpQE+l3j60Dgt3YwizIApi/YgmfsUzXAZqhpxadrsMYtzg81kZDdbTprOl9vqbDGO7ywfPQ+VctYKUoMStCfoBK/s= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(7916002)(39450400003)(199003)(377454003)(24454002)(189002)(8676002)(97736004)(81166006)(3280700002)(8936002)(50226002)(3660700001)(15650500001)(33656002)(101416001)(6512007)(54896002)(5250100002)(81156014)(76176999)(2900100001)(50986999)(106356001)(105586002)(106116001)(36756003)(86362001)(102836003)(6116002)(92566002)(93886004)(230783001)(68736007)(74482002)(3846002)(4326007)(38730400001)(229853002)(54906002)(2906002)(57306001)(39060400001)(7736002)(82746002)(66066001)(42882006)(6486002)(6506006)(83716003)(189998001)(5660300001)(6916009)(236005)(99286003)(2950100002)(6436002)(110136003)(104396002)(969003)(989001)(999001)(1009001)(1019001); 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 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 13:38:31.7814 (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: wben-1kqMFaau1I73YpD6w-1 Content-Type: multipart/alternative; boundary="_000_0D24BC9F26DD4ABF965A84C5708B900Djiscacuk_" Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:38:48 -0000 --_000_0D24BC9F26DD4ABF965A84C5708B900Djiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDEyIEphbiAyMDE3LCBhdCAwODoyNCwgTG9yZW56byBDb2xpdHRpIDxsb3Jlbnpv QGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpPbiBUaHUs IEphbiAxMiwgMjAxNyBhdCA0OjIwIFBNLCBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jr cy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtzLmNvbT4+IHdyb3RlOg0KPiBXZSBkbw0KPiBy ZWNvbW1lbmRlZCB0aGF0IG5vZGVzIHVzZSBSRkM3MjE3IGFkZHJlc3NlcyBieSBkZWZhdWx0LCBi dXQgb25seSBpZiB0aGUNCj4gbm9kZSB3aXNoZXMgdG8gY3JlYXRlIHN0YWJsZSBhZGRyZXNzZXMs IGFuZCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCB0aGF0DQo+IGEgbm9kZSBkbyBzby4NCg0KU28g ZmFyLCB0aGUgY3VycmVudCBzcGVjcyBlc3NlbnRpYWxseSByZXF1aXJlIHRoYXQuIFJGQzQ5NDEg KHRoZSBvbmx5DQpzcGVjIHdlIGhhdmUgZm9yIG5vbi10ZW1wb3JhcnkgYWRkcmVzc2VzKSByZXF1 aXJlIHRoYXQgdGhlIGJlIGdlbmVyYXRlZA0KYWxvbmcgd2l0aCB0aGUgdHJhZGl0aW9uYWwgKHN0 YWJsZSkgYWRkcmVzc2VzLg0KDQpJIGRvbid0IHNlZSB3aGF0IFJGQyA0OTQxIGhhcyB0byBkbyB3 aXRoIHRoaXMgZGlzY3Vzc2lvbi4gUkZDNDk0MSBpcyBhIG1ldGhvZCBvZiBnZW5lcmF0aW5nIHRl bXBvcmFyeSBhZGRyZXNzZXMuIEl0IGlzIG5vdCByZXF1aXJlZCB0byBiZSB1c2VkLCBhbmQgaXQg aXMgbm90IHRoZSBvbmx5IHdheSBvZiBmb3JtaW5nIElQIGFkZHJlc3NlcyB0aGF0IGNhbiBjaGFu Z2Ugb3ZlciB0aW1lLg0KDQpJbmRlZWQsIGl04oCZcyBvcnRob2dvbmFsIHRvIHRoaXMgZGlzY3Vz c2lvbi4NCg0KRldJVywgSSBkbyB0aGluayB0aGVyZSBhcmUgc2NlbmFyaW9zIGluIHdoaWNoIHlv dSBtaWdodCB3YW50IHRvIGRvDQp0ZW1wb3Jhcnktb25seSwgYnV0IHdlIGNlcnRhaW5seSBuZWVk IGFuIHVwZGF0ZSB0byB0aGUgY3VycmVudCBzcGVjcyBpbg0KdGhhdCByZWdhcmQgKGFuZCBndWlk YW5jZSByZWdhcmRpbmcgd2hlcmUgdG8gdXNlIGVhY2gpLg0KDQpUaGVyZSBhcmUgbG90cyBvZiB3 YXlzIG9mIGZvcm1pbmcgaW50ZXJmYWNlIGlkZW50aWZpZXJzLiBXZSBzaG91bGQgYWJzb2x1dGVs eSBub3QgcnVsZSBvdXQgdGhlIGFiaWxpdHkgdG8gZm9ybSBJSURzIGZyb20gbm9uLXN0YWJsZSBN QUMgYWRkcmVzc2VzIChJSVJDIHRoZSB0ZXh0IGluIGRlZmF1bHQtaWlkcyB3YXMgY2FyZWZ1bGx5 IG1vZGlmaWVkIHRvIGVuc3VyZSB0aGF0IHRoYXQgd291bGQgc3RpbGwgYmUgcG9zc2libGUsIGJh c2VkIG9uIHN1YnN0YW50aWFsIGRpc2N1c3Npb25zIGluIHRoZSBXRyksIGFuZCB3ZSBzaG91bGQg KmFic29sdXRlbHkqIG5vdCBzYXkgdGhhdCB0aGUgb25seSBwb3NzaWJsZSBmb3JtIG9mIGludGVy ZmFjZSBpZGVudGlmaWVycyBvbiBhbiBFdGhlcm5ldCBpbnRlcmZhY2UgYXJlIFJGQzcyMTcgYW5k IFJGQzQ5NDEuDQoNCkluZGVlZCwgSSB3YXMgYXQgQ0VSTiB5ZXN0ZXJkYXkgYW5kIG15IGFkZHJl c3MgKGFuZCB0aHVzIElJRCkgdGhlcmUgd2FzIGFzc2lnbmVkIHZpYSBESENQdjYsIHdoaWNoIGlz IHRoZSBvbmx5IHdheSB5b3UgY2FuIGdldCBJUHY2IGFkZHJlc3NlcyB0aGVyZS4gIFJGQzI0NjQg cHJlLWRhdGVzIERIQ1B2Njsgc2hvdWxkIHJlZmVyZW5jZSB0byBpdCBiZSBpbmNsdWRlZCBpbiB0 aGUgLWJpcz8NCg0KVGhhdCBhc2lkZSwgaW4gdGhlIGNvbnRleHQgb2YgdGVtcC1vbmx5IGFkZHJl c3NlcywgZG9pbmcgTW9kaWZpZWQtRVVJNjQNCmJhc2VkIG9uIGEgcmFuZG9taXplZCBNQUMgYWRk cmVzcyBpcyBzdGlsbCBhIGJhZCBpZGVhOg0KDQpJIGFtIG5vdCBnb2luZyB0byByZWhhc2ggdGhh dCBhcmd1bWVudCBoZXJlLiBFdmVyeXRoaW5nIHdlIGhhZCB0byBzYXkgYWJvdXQgdGhhdCBpcyBp biB0aGUgYXJjaGl2ZXMuDQoNCkkgc3VwcG9ydCBMb3Jlbnpv4oCZcyBzdWdnZXN0aW9uIHRvIGNo YW5nZSB0aGUgdGV4dCBpbiB0aGUgLWJpcyB1cGRhdGUgdG8gZW1waGFzaXNlIHRoZSByZWNvbW1l bmRhdGlvbiBpcyBmb3IgKnN0YWJsZSogaWRlbnRpZmllcnMuDQoNClRoaXMgcmVmbGVjdHMgd2hh dCB0aGUgZGVmYXVsdC1paWRzIGRyYWZ0IGNsZWFybHkgc3RhdGVzOg0KDQoiVGhpcyBkb2N1bWVu dCBjaGFuZ2VzIHRoZSByZWNvbW1lbmRlZCBkZWZhdWx0IElJRCBnZW5lcmF0aW9uIHNjaGVtZQ0K ICAgZm9yIGNhc2VzIHdoZXJlIFNMQUFDIGlzIHVzZWQgdG8gZ2VuZXJhdGUgYSBzdGFibGUgSVB2 NiBhZGRyZXNzLiAgSXQNCiAgIHJlY29tbWVuZHMgdXNpbmcgdGhlIG1lY2hhbmlzbSBzcGVjaWZp ZWQgaW4gUkZDNzIxNyBpbiBzdWNoIGNhc2VzLA0KICAgYW5kIHJlY29tbWVuZHMgYWdhaW5zdCBl bWJlZGRpbmcgc3RhYmxlIGxpbmstbGF5ZXIgYWRkcmVzc2VzIGluIElQdjYNCiAgIEludGVyZmFj ZSBJZGVudGlmaWVycy7igJ0NCg0KQW5kIGl04oCZcyBvbmx5IGEgcmVjb21tZW5kYXRpb24uIFRo ZSB0ZXh0IGRvZXMgbm90IHByZWNsdWRlIHVzZSBvZiBlbWJlZGRlZCBzdGFibGUgTUFDIGFkZHJl c3NlcyBpZiBzb21lb25lIHJlYWxseSB3YW50cyB0byBkbyB0aGF0LiAgTm9yIGRvZXMgaXQgc2F5 IGFueXRoaW5nIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgdG8gdGVtcG9yYXJ5IChub24tc3RhYmxl KSBhZGRyZXNzZXMuDQoNClRpbQ0K --_000_0D24BC9F26DD4ABF965A84C5708B900Djiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <799C2F27E16B5243A6ACF25287E14AA5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gMTIgSmFuIDIwMTcsIGF0IDA4OjI0LCBMb3JlbnpvIENvbGl0dGkgJmx0 OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIGNsYXNzPSIiPmxvcmVuem9AZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUs IEphbiAxMiwgMjAxNyBhdCA0OjIwIFBNLCBGZXJuYW5kbyBHb250IDxzcGFuIGRpcj0ibHRyIiBj bGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPiZndDs8L3NwYW4+ IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsg V2UgZG88YnIgY2xhc3M9IiI+DQomZ3Q7IHJlY29tbWVuZGVkIHRoYXQgbm9kZXMgdXNlIFJGQzcy MTcgYWRkcmVzc2VzIGJ5IGRlZmF1bHQsIGJ1dCBvbmx5IGlmIHRoZTxiciBjbGFzcz0iIj4NCiZn dDsgbm9kZSB3aXNoZXMgdG8gY3JlYXRlIHN0YWJsZSBhZGRyZXNzZXMsIGFuZCB0aGVyZSBpcyBu byByZXF1aXJlbWVudCB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyBhIG5vZGUgZG8gc28uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9zcGFuPlNvIGZhciwgdGhlIGN1cnJlbnQgc3BlY3Mg ZXNzZW50aWFsbHkgcmVxdWlyZSB0aGF0LiBSRkM0OTQxICh0aGUgb25seTxiciBjbGFzcz0iIj4N CnNwZWMgd2UgaGF2ZSBmb3Igbm9uLXRlbXBvcmFyeSBhZGRyZXNzZXMpIHJlcXVpcmUgdGhhdCB0 aGUgYmUgZ2VuZXJhdGVkPGJyIGNsYXNzPSIiPg0KYWxvbmcgd2l0aCB0aGUgdHJhZGl0aW9uYWwg KHN0YWJsZSkgYWRkcmVzc2VzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZG9uJ3Qgc2VlIHdo YXQgUkZDIDQ5NDEgaGFzIHRvIGRvIHdpdGggdGhpcyBkaXNjdXNzaW9uLiBSRkM0OTQxIGlzIGEg bWV0aG9kIG9mIGdlbmVyYXRpbmcgdGVtcG9yYXJ5IGFkZHJlc3Nlcy4gSXQgaXMgbm90IHJlcXVp cmVkIHRvIGJlIHVzZWQsIGFuZCBpdCBpcyBub3QgdGhlIG9ubHkgd2F5IG9mIGZvcm1pbmcgSVAg YWRkcmVzc2VzIHRoYXQgY2FuIGNoYW5nZSBvdmVyIHRpbWUuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQpJbmRlZWQsIGl04oCZcyBvcnRob2dvbmFsIHRvIHRoaXMgZGlzY3Vzc2lvbi48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpGV0lXLCBJIGRv IHRoaW5rIHRoZXJlIGFyZSBzY2VuYXJpb3MgaW4gd2hpY2ggeW91IG1pZ2h0IHdhbnQgdG8gZG88 YnIgY2xhc3M9IiI+DQp0ZW1wb3Jhcnktb25seSwgYnV0IHdlIGNlcnRhaW5seSBuZWVkIGFuIHVw ZGF0ZSB0byB0aGUgY3VycmVudCBzcGVjcyBpbjxiciBjbGFzcz0iIj4NCnRoYXQgcmVnYXJkIChh bmQgZ3VpZGFuY2UgcmVnYXJkaW5nIHdoZXJlIHRvIHVzZSBlYWNoKS48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGVyZSBhcmUgbG90cyBvZiB3YXlzIG9mIGZvcm1pbmcgaW50ZXJmYWNlIGlkZW50 aWZpZXJzLiBXZSBzaG91bGQgYWJzb2x1dGVseSBub3QgcnVsZSBvdXQgdGhlIGFiaWxpdHkgdG8g Zm9ybSBJSURzIGZyb20gbm9uLXN0YWJsZSBNQUMgYWRkcmVzc2VzIChJSVJDIHRoZSB0ZXh0IGlu IGRlZmF1bHQtaWlkcyB3YXMgY2FyZWZ1bGx5IG1vZGlmaWVkIHRvIGVuc3VyZSB0aGF0IHRoYXQg d291bGQgc3RpbGwgYmUgcG9zc2libGUsDQogYmFzZWQgb24gc3Vic3RhbnRpYWwgZGlzY3Vzc2lv bnMgaW4gdGhlIFdHKSwgYW5kIHdlIHNob3VsZCAqYWJzb2x1dGVseSogbm90IHNheSB0aGF0IHRo ZSBvbmx5IHBvc3NpYmxlIGZvcm0gb2YgaW50ZXJmYWNlIGlkZW50aWZpZXJzIG9uIGFuIEV0aGVy bmV0IGludGVyZmFjZSBhcmUgUkZDNzIxNyBhbmQgUkZDNDk0MS48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCkluZGVlZCwgSSB3YXMgYXQgQ0VSTiB5ZXN0ZXJkYXkgYW5kIG15IGFkZHJlc3MgKGFu ZCB0aHVzIElJRCkgdGhlcmUgd2FzIGFzc2lnbmVkIHZpYSBESENQdjYsIHdoaWNoIGlzIHRoZSBv bmx5IHdheSB5b3UgY2FuIGdldCBJUHY2IGFkZHJlc3NlcyB0aGVyZS4gJm5ic3A7UkZDMjQ2NCBw cmUtZGF0ZXMgREhDUHY2OyBzaG91bGQgcmVmZXJlbmNlIHRvIGl0IGJlIGluY2x1ZGVkIGluIHRo ZSAtYmlzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpUaGF0IGFzaWRl LCBpbiB0aGUgY29udGV4dCBvZiB0ZW1wLW9ubHkgYWRkcmVzc2VzLCBkb2luZyBNb2RpZmllZC1F VUk2NDxiciBjbGFzcz0iIj4NCmJhc2VkIG9uIGEgcmFuZG9taXplZCBNQUMgYWRkcmVzcyBpcyBz dGlsbCBhIGJhZCBpZGVhOjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYW0gbm90IGdvaW5nIHRv IHJlaGFzaCB0aGF0IGFyZ3VtZW50IGhlcmUuIEV2ZXJ5dGhpbmcgd2UgaGFkIHRvIHNheSBhYm91 dCB0aGF0IGlzIGluIHRoZSBhcmNoaXZlcy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJIHN1cHBvcnQgTG9y ZW56b+KAmXMgc3VnZ2VzdGlvbiB0byBjaGFuZ2UgdGhlIHRleHQgaW4gdGhlIC1iaXMgdXBkYXRl IHRvIGVtcGhhc2lzZSB0aGUgcmVjb21tZW5kYXRpb24gaXMgZm9yICpzdGFibGUqIGlkZW50aWZp ZXJzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhpcyByZWZsZWN0 cyB3aGF0IHRoZSBkZWZhdWx0LWlpZHMgZHJhZnQgY2xlYXJseSBzdGF0ZXM6PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4mcXVvdDtUaGlzIGRvY3VtZW50IGNoYW5nZXMg dGhlIHJlY29tbWVuZGVkIGRlZmF1bHQgSUlEIGdlbmVyYXRpb24gc2NoZW1lDQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNw OyBmb3IgY2FzZXMgd2hlcmUgU0xBQUMgaXMgdXNlZCB0byBnZW5lcmF0ZSBhIHN0YWJsZSBJUHY2 IGFkZHJlc3MuJm5ic3A7IEl0PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyByZWNvbW1lbmRzIHVzaW5nIHRo ZSBtZWNoYW5pc20gc3BlY2lmaWVkIGluIFJGQzcyMTcgaW4gc3VjaCBjYXNlcyw8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7IGFuZCByZWNvbW1lbmRzIGFnYWluc3QgZW1iZWRkaW5nIHN0YWJsZSBsaW5rLWxh eWVyIGFkZHJlc3NlcyBpbiBJUHY2PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBJbnRlcmZhY2UgSWRlbnRp ZmllcnMu4oCdPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj5BbmQgaXTigJlzIG9ubHkgYSBy ZWNvbW1lbmRhdGlvbi4gVGhlIHRleHQgZG9lcyBub3QgcHJlY2x1ZGUgdXNlIG9mIGVtYmVkZGVk IHN0YWJsZSBNQUMgYWRkcmVzc2VzIGlmIHNvbWVvbmUgcmVhbGx5IHdhbnRzIHRvIGRvIHRoYXQu ICZuYnNwO05vciBkb2VzIGl0IHNheSBhbnl0aGluZyBhYm91dCB0aGUgcmVsYXRpb25zaGlwIHRv IHRlbXBvcmFyeSAobm9uLXN0YWJsZSkNCiBhZGRyZXNzZXMuPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBj bGFzcz0iIj5UaW08L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0D24BC9F26DD4ABF965A84C5708B900Djiscacuk_-- From nobody Thu Jan 12 06:29: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 E05831293EB for ; Thu, 12 Jan 2017 06:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52jD5v87lEnn for ; Thu, 12 Jan 2017 06:29:42 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8645F129417 for ; Thu, 12 Jan 2017 06:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Yz0R5J/O8g1SdYjg+36XoLQs4gw46hJLIGcNbRs8hpQ=; b=HTgXxGaCR42goxlMrG8cmNx0rCvanshBi++cZjkDqcPm8HpMHjktEpsR7XRKjRPIcyLSLllFXxTaf7Ixw0u3R6Drh/zirl+xYfCRXUxqOgOGpwyJNppIMgdoseVnDdgLGC1XTHLnidh1OQRkYxZITan46nG668XYat2BzebkVBk= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0146.outbound.protection.outlook.com [213.199.180.146]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-9-TdJsRQX-NQOsEIPNMOZkGg-1; Thu, 12 Jan 2017 14:29:34 +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_P384) id 15.1.845.6; Thu, 12 Jan 2017 14:29:33 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5973:c4fc:6c1c:27c2%14]) with mapi id 15.01.0845.014; Thu, 12 Jan 2017 14:29:33 +0000 From: Tim Chown To: Mark Smith Subject: Re: Errata for RFC4862 Thread-Topic: Errata for RFC4862 Thread-Index: AQHSaXBn5ebqxyUYbEyFjv7/ZjHe0aEv2MYAgAHTMACAAHGEgIAAJXQAgAKqxIA= Date: Thu, 12 Jan 2017 14:29:33 +0000 Message-ID: <9F634A38-468F-46B6-81D5-17D96223F163@jisc.ac.uk> References: <4921ADB7-42A6-443E-B639-A3F6F300B13C@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 57be8f33-8da7-4eae-80fe-08d43af76d7a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1138; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 7:MjAnonq1a41k88hkd6+wL5EAyesJwY5G94kgvaeTd1O3oWcnSyybM70x9KnM4b+yzo9bNP33Gp4EBXRH4dUSNjUvGiMB2FZKUQDjrRrlQ3eRRdbdRgkc8CI775ezBzA2ifIst27Qp9wAiSYnY2iCrQylw8VT/UU0BrA7nV9ptREQVinJuzcWlLAHX/3+HzHIoxs8OlmhEYC7oaCWvsGOrGyt63T8cPPi4mAz88+Az/APfCPZlSvCLJYRKCQP/CfjW5653E/+vLl+1BdQuskNMdq7wifOAcQPQhgy8JsloeCeKaEevg5OBe38C+jD+qO6hSQiRhn7YzHPqLBGTQILAKjKKFnXMHSStzI/jwPO4xp2FlTCjMlrCIsE2cI51IPQUGc+Ayt1jC5bRShk7jbWEdhOvnZugJQPtVRi2Kgy5xOLIUO2DNrptCwZVbPo9zgIejoNFDwETyd8Hw+sZFEzrQ==; 20:mA6y4EtN5J5K5Sm4ISm1z2ZiraXsFBbVzdEpsAZzSsVDcnvIWFzt7J7VfWKESuP6Hoq+qQ9fY3d/ct4Ct3hjCrzqZAQnkZpdubyUDZWdGlOBk+rhI6bEWKnUfjz24+Uzdtu7y/kXxItPtT0oBAK/JIdlPwTlB7eF1WkxXWmPElM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1138; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(377454003)(24454002)(189002)(8676002)(97736004)(81166006)(3280700002)(8936002)(50226002)(3660700001)(101416001)(33656002)(54896002)(6512007)(5250100002)(81156014)(76176999)(2900100001)(50986999)(6306002)(106356001)(105586002)(106116001)(36756003)(86362001)(102836003)(6116002)(92566002)(68736007)(93886004)(74482002)(3846002)(4326007)(38730400001)(229853002)(54906002)(2906002)(1411001)(57306001)(39060400001)(7736002)(7906003)(82746002)(66066001)(42882006)(6486002)(83716003)(6506006)(189998001)(5660300001)(6916009)(236005)(606005)(99286003)(2950100002)(6436002)(7116003)(110136003)(104396002); 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 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 14:29:33.3329 (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: TdJsRQX-NQOsEIPNMOZkGg-1 Content-Type: multipart/alternative; boundary="_000_9F634A38468F46B681D517D96223F163jiscacuk_" Archived-At: Cc: 6man WG , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 14:29:50 -0000 --_000_9F634A38468F46B681D517D96223F163jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KT24gMTAgSmFuIDIwMTcsIGF0IDIxOjQ1LCBNYXJrIFNtaXRoIDxtYXJrenp6 c21pdGhAZ21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPj4gd3JvdGU6DQoN Ck9uIDExIEphbi4gMjAxNyA2OjMyIGFtLCAi56We5piO6YGU5ZOJIiA8amlubWVpQHdpZGUuYWQu anA8bWFpbHRvOmppbm1laUB3aWRlLmFkLmpwPj4gd3JvdGU6DQpBdCBUdWUsIDEwIEphbiAyMDE3 IDEyOjQ1OjI3ICswMDAwLA0KVGltIENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51azxtYWlsdG86 VGltLkNob3duQGppc2MuYWMudWs+PiB3cm90ZToNCg0KPiBNeSByZWNvbGxlY3Rpb24gb2YgcnVu bmluZyByZW51bWJlcmluZyBleHBlcmltZW50cyBpcyB0aGF0IGl04oCZcyB0aGUNCj4gUHJlZmVy cmVkIExpZmV0aW1lIHRoYXQgbWF0dGVycywgaS5lLiB3aGVuIHRoYXQgaXMgc2V0IHRvIHplcm8g Zm9yIGENCj4gcHJlZml4LCB0aGUgcHJlZml4IGlzIG1hcmtlZCBhcyBkZXByZWNhdGVkLiAgU28g d2hlbiByZW51bWJlcmluZywNCj4geW91IHJ1biB3aXRoIHR3byBwcmVmaXhlcyBhZHZlcnRpc2Vk LCBvbGQgYW5kIG5ldywgc2V0dGluZyB0aGUNCj4gUHJlZmVycmVkIExpZmV0aW1lIHRvIDAgb24g dGhlIG9sZCBwcmVmaXggKGV2ZW4gdGhvdWdoIHRoZSBWYWxpZA0KPiBMaWZldGltZSBpcyBzZXQg dG8gMisgaG91cnMpLCBzbyB0aGF0IHRoZSBhZGRyZXNzIHdpdGggdGhlIG5ldw0KPiBwcmVmaXgg aXMgdXNlZCBmb3IgbmV3bHkgaW5pdGlhdGVkIGNvbW11bmljYXRpb25zIChhcyBwZXIgUkZDIDY3 MjQsDQo+IFJ1bGUgMykuDQoNClllcywgYnV0IEkgZ3Vlc3Mgd2hhdCBPbGUgdHJpZWQgdG8gcG9p bnQgb3V0ICh3aGljaCBJIGFncmVlIHdpdGgpIGlzDQp0aGF0IHRoZSB2YWxpZCBsaWZldGltZSB3 aWxsIGFsc28gaGF2ZSB0byBkZWNyZWFzZSB0byAwIGV2ZW50dWFsbHksDQphbmQgdGhpcyBvcmln aW5hbCB0ZXh0IG9mIFJGQzQ4NjIgYWxsb3dzIHN1Y2ggZGVjcmVhc2Ugb3BlcmF0aW9uDQp3aXRo b3V0IHJlcXVpcmluZyBleHBsaWNpdCBhdXRoZW50aWNhdGlvbiBpZiBkb25lIGJ5IGdyYWR1YWxs eToNCg0KSWYgdGhhdCBpcyB0aGUgY2FzZSAoYW5kIEkgZG9uJ3QgdGhpbmsgaXQgaXMsIGl0IGNy ZWF0ZXMgdGhlIERvUyBvcHBvcnR1bml0eSB0aGF0IGFsbCBvdGhlciA+MiBociBjaGVja3MgYXR0 ZW1wdCB0byBkZWZlYXQpLCB0aGVuIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZmFyIGJldHRlciBh bmQgbW9yZSBleHBsaWNpdGx5IGV4cGxhaW5lZCwgaW5jbHVkaW5nIHRoZSBzZXF1ZW5jZSBvZiBl dmVudHMuDQoNCldoYXQgaXMgdGhlIHVzZSBjYXNlIHRoYXQgY2FuJ3QgYmUgYWNoaWV2ZWQgYnkg c2V0dGluZyB0aGUgcHJlZmVycmVkIGxpZmV0aW1lIHRvIHplcm8sIGltbWVkaWF0ZWx5IGRlcHJl Y2F0aW5nIHRoZSBhZGRyZXNzZXMgKGFuZCBhIFZMIG9mIDIgaG91cnMgdG8gY2F1c2UgdGhlbSB0 byBkaXNhcHBlYXIgc2hvcnRseSkuDQoNCklmIGl0IGlzIHRvIHJlbW92ZSBhZGRyZXNzZXMgaW1t ZWRpYXRlbHkgZnJvbSBhIGhvc3QgYnkgc2V0dGluZyB0aGUgUkEgUElPIFZMIHRvIHplcm8gLSBh Y3R1YWxseSB0aGF0J3Mgbm90IGdvaW5nIHRvIHdvcmssIGJlY2F1c2Ugc2VlaW5nIFZMIHRvIHpl cm8gd2lsbCBmYWlsIHRoZSBncmVhdGVyIHRoYW4gcmVtYWluaW5nIHRpbWUgY2hlY2suDQoNCkl0 IHdvdWxkIGJlIHZlcnkgbGFib3Jpb3VzIHRvIHRyeSB0byByZW1vdmUgYW4gYWRkcmVzcyBieSBv bmx5IGJlaW5nIGFibGUgdG8gc2VuZCBhIFZMIGdyZWF0ZXIgdGhhbiB0aGUgYWRkcmVzcydzIHJl bWFpbmluZyB0aW1lLiBMZXR0aW5nIHRoZSBhZGRyZXNzIGFnZSBvdXQvZXhwaXJlIG5hdHVyYWxs eSBieSBpdHNlbGYgYnkgc3RvcHBpbmcgc2VuZGluZyB0aGUgUkEgUElPIGZvciB0aGUgcHJlZml4 IHdvbGYgYmUgZWFzaWVyIGFuZCBJIHRoaW5rIHF1aWNrZXIuDQoNClllcywgdGhlIHByb2Nlc3Mg eW91IGRlc2NyaWJlIGlzIGV4YWN0bHkgd2hhdCBSRkMgNDE5MiByZWNvbW1lbmRzIGZvciByZW51 bWJlcmluZywgYW5kIHdoaWNoIHdhcyB0ZXN0ZWQgb24gY29tbW9uIE9TZXMgYXQgdGhlIHRpbWUg dGhhdCBSRkMgd2FzIHdyaXR0ZW4uIFRvIGJlZ2luIHRoZSByZW51bWJlcmluZyBwcm9jZXNzLCB5 b3UgcnVuIHdpdGggUEwgMCBhbmQgVkwgMmhycyBvbiB0aGUg4oCcb2xk4oCdIHByZWZpeCwgYW5k IHdpdGggbm9ybWFsIHZhbHVlcyBvbiB0aGUg4oCcbmV34oCdIHByZWZpeC4gIFRvIHRyYW5zaXRp b24gdG8ganVzdCB0aGUgbmV3IHByZWZpeCBpbiB1c2UsIHlvdSBzdG9wIGFkdmVydGlzaW5nIHRo ZSBvbGQgcHJlZml4LCBzdWNoIHRoYXQgYWRkcmVzc2VzIGZvcm1lZCBmcm9tIGl0IHdpbGwgYmVj b21lIGludmFsaWQgYW5kIGJlIHJlbW92ZWQsIGFuZCBkdXJpbmcgd2hpY2ggdGltZSB0aGUgYWRk cmVzcyBnZW5lcmF0ZWQgZnJvbSB0aGUgbmV3IHByZWZpeCB3aWxsIGJlIHVzZWQgZHVlIHRvIFJG QyA2NzI0IFJ1bGUgMy4NCg0KU28gZnJvbSB0aGF0IHBlcnNwZWN0aXZlLCB0aGVyZeKAmXMgbm8g bmVlZCB0byBjaGFuZ2UgUkZDIDQ4NjIgdG8gYWxsb3cgYW4gdW5hdXRoZW50aWNhdGVkIFZMIDwg Mmhycy4NCg0KVGltDQoNCg0KUmVnYXJkcywNCk1hcmsuDQoNCg0KPiA+PiAgICAgMS4gIElmIHRo ZSByZWNlaXZlZCBWYWxpZCBMaWZldGltZSBpcyBncmVhdGVyIHRoYW4gMiBob3VycyBvcg0KPiA+ PiAgICAgICAgIGdyZWF0ZXIgdGhhbiBSZW1haW5pbmdMaWZldGltZSwgc2V0IHRoZSB2YWxpZCBs aWZldGltZSBvZiB0aGUNCj4gPj4gICAgICAgICBjb3JyZXNwb25kaW5nIGFkZHJlc3MgdG8gdGhl IGFkdmVydGlzZWQgVmFsaWQgTGlmZXRpbWUuDQoNCg0KLS0NCkpJTk1FSSwgVGF0dXlhDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0 Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN Cg== --_000_9F634A38468F46B681D517D96223F163jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgTWFyayw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIDEwIEphbiAyMDE3LCBhdCAyMTo0NSwgTWFyayBTbWl0aCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20iIGNsYXNzPSIiPm1hcmt6enpz bWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMSBKYW4u IDIwMTcgNjozMiBhbSwgJnF1b3Q756We5piO6YGU5ZOJJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86amlubWVpQHdpZGUuYWQuanAiIGNsYXNzPSIiPmppbm1laUB3aWRlLmFkLmpwPC9hPiZndDsg d3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNz PSJxdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KQXQgVHVlLCAxMCBKYW4gMjAxNyAxMjo0NToyNyAmIzQz OzAwMDAsPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0icXVvdGVkLXRleHQiPlRpbSBDaG93biAm bHQ7PGEgaHJlZj0ibWFpbHRvOlRpbS5DaG93bkBqaXNjLmFjLnVrIiBjbGFzcz0iIj5UaW0uQ2hv d25AamlzYy5hYy51azwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZndDsgTXkgcmVjb2xsZWN0aW9uIG9mIHJ1bm5pbmcgcmVudW1iZXJpbmcgZXhwZXJpbWVudHMg aXMgdGhhdCBpdOKAmXMgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyBQcmVmZXJyZWQgTGlmZXRpbWUg dGhhdCBtYXR0ZXJzLCBpLmUuIHdoZW4gdGhhdCBpcyBzZXQgdG8gemVybyBmb3IgYTxiciBjbGFz cz0iIj4NCiZndDsgcHJlZml4LCB0aGUgcHJlZml4IGlzIG1hcmtlZCBhcyBkZXByZWNhdGVkLiZu YnNwOyBTbyB3aGVuIHJlbnVtYmVyaW5nLDxiciBjbGFzcz0iIj4NCiZndDsgeW91IHJ1biB3aXRo IHR3byBwcmVmaXhlcyBhZHZlcnRpc2VkLCBvbGQgYW5kIG5ldywgc2V0dGluZyB0aGU8YnIgY2xh c3M9IiI+DQomZ3Q7IFByZWZlcnJlZCBMaWZldGltZSB0byAwIG9uIHRoZSBvbGQgcHJlZml4IChl dmVuIHRob3VnaCB0aGUgVmFsaWQ8YnIgY2xhc3M9IiI+DQomZ3Q7IExpZmV0aW1lIGlzIHNldCB0 byAyJiM0MzsgaG91cnMpLCBzbyB0aGF0IHRoZSBhZGRyZXNzIHdpdGggdGhlIG5ldzxiciBjbGFz cz0iIj4NCiZndDsgcHJlZml4IGlzIHVzZWQgZm9yIG5ld2x5IGluaXRpYXRlZCBjb21tdW5pY2F0 aW9ucyAoYXMgcGVyIFJGQyA2NzI0LDxiciBjbGFzcz0iIj4NCiZndDsgUnVsZSAzKS48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClllcywgYnV0IEkgZ3Vlc3Mgd2hhdCBPbGUg dHJpZWQgdG8gcG9pbnQgb3V0ICh3aGljaCBJIGFncmVlIHdpdGgpIGlzPGJyIGNsYXNzPSIiPg0K dGhhdCB0aGUgdmFsaWQgbGlmZXRpbWUgd2lsbCBhbHNvIGhhdmUgdG8gZGVjcmVhc2UgdG8gMCBl dmVudHVhbGx5LDxiciBjbGFzcz0iIj4NCmFuZCB0aGlzIG9yaWdpbmFsIHRleHQgb2YgUkZDNDg2 MiBhbGxvd3Mgc3VjaCBkZWNyZWFzZSBvcGVyYXRpb248YnIgY2xhc3M9IiI+DQp3aXRob3V0IHJl cXVpcmluZyBleHBsaWNpdCBhdXRoZW50aWNhdGlvbiBpZiBkb25lIGJ5IGdyYWR1YWxseTo8YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJxdW90ZWQtdGV4dCI+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+SWYgdGhhdCBpcyB0aGUg Y2FzZSAoYW5kIEkgZG9uJ3QgdGhpbmsgaXQgaXMsIGl0IGNyZWF0ZXMgdGhlIERvUyBvcHBvcnR1 bml0eSB0aGF0IGFsbCBvdGhlciAmZ3Q7MiBociBjaGVja3MgYXR0ZW1wdCB0byBkZWZlYXQpLCB0 aGVuIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgZmFyIGJldHRlciBhbmQgbW9yZSBleHBsaWNpdGx5 IGV4cGxhaW5lZCwgaW5jbHVkaW5nIHRoZSBzZXF1ZW5jZSBvZiBldmVudHMuPC9kaXY+DQo8ZGl2 IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byIgY2xhc3M9IiI+V2hhdCBpcyB0aGUgdXNlIGNhc2UgdGhhdCBjYW4ndCBiZSBhY2hpZXZlZCBi eSBzZXR0aW5nIHRoZSBwcmVmZXJyZWQgbGlmZXRpbWUgdG8gemVybywgaW1tZWRpYXRlbHkgZGVw cmVjYXRpbmcgdGhlIGFkZHJlc3NlcyAoYW5kIGEgVkwgb2YgMiBob3VycyB0byBjYXVzZSB0aGVt IHRvIGRpc2FwcGVhciBzaG9ydGx5KS48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5JZiBpdCBpcyB0 byByZW1vdmUgYWRkcmVzc2VzIGltbWVkaWF0ZWx5IGZyb20gYSBob3N0IGJ5IHNldHRpbmcgdGhl IFJBIFBJTyBWTCB0byB6ZXJvIC0gYWN0dWFsbHkgdGhhdCdzIG5vdCBnb2luZyB0byB3b3JrLCBi ZWNhdXNlIHNlZWluZyBWTCB0byB6ZXJvIHdpbGwgZmFpbCB0aGUgZ3JlYXRlciB0aGFuIHJlbWFp bmluZyB0aW1lIGNoZWNrLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPkl0IHdvdWxkIGJlIHZlcnkg bGFib3Jpb3VzIHRvIHRyeSB0byByZW1vdmUgYW4gYWRkcmVzcyBieSBvbmx5IGJlaW5nIGFibGUg dG8gc2VuZCBhIFZMIGdyZWF0ZXIgdGhhbiB0aGUgYWRkcmVzcydzIHJlbWFpbmluZyB0aW1lLiBM ZXR0aW5nIHRoZSBhZGRyZXNzIGFnZSBvdXQvZXhwaXJlIG5hdHVyYWxseSBieSBpdHNlbGYgYnkg c3RvcHBpbmcgc2VuZGluZyB0aGUgUkEgUElPIGZvciB0aGUgcHJlZml4IHdvbGYNCiBiZSBlYXNp ZXIgYW5kIEkgdGhpbmsgcXVpY2tlci4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMsIHRoZSBwcm9j ZXNzIHlvdSBkZXNjcmliZSBpcyBleGFjdGx5IHdoYXQgUkZDIDQxOTIgcmVjb21tZW5kcyBmb3Ig cmVudW1iZXJpbmcsIGFuZCB3aGljaCB3YXMgdGVzdGVkIG9uIGNvbW1vbiBPU2VzIGF0IHRoZSB0 aW1lIHRoYXQgUkZDIHdhcyB3cml0dGVuLiBUbyBiZWdpbiB0aGUgcmVudW1iZXJpbmcgcHJvY2Vz cywgeW91IHJ1biB3aXRoIFBMIDAgYW5kIFZMIDJocnMgb24gdGhlIOKAnG9sZOKAnSBwcmVmaXgs IGFuZCB3aXRoIG5vcm1hbA0KIHZhbHVlcyBvbiB0aGUg4oCcbmV34oCdIHByZWZpeC4gJm5ic3A7 VG8gdHJhbnNpdGlvbiB0byBqdXN0IHRoZSBuZXcgcHJlZml4IGluIHVzZSwgeW91IHN0b3AgYWR2 ZXJ0aXNpbmcgdGhlIG9sZCBwcmVmaXgsIHN1Y2ggdGhhdCBhZGRyZXNzZXMgZm9ybWVkIGZyb20g aXQgd2lsbCBiZWNvbWUgaW52YWxpZCBhbmQgYmUgcmVtb3ZlZCwgYW5kIGR1cmluZyB3aGljaCB0 aW1lIHRoZSBhZGRyZXNzIGdlbmVyYXRlZCBmcm9tIHRoZSBuZXcgcHJlZml4IHdpbGwgYmUgdXNl ZA0KIGR1ZSB0byBSRkMgNjcyNCBSdWxlIDMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5TbyBmcm9tIHRoYXQgcGVyc3BlY3RpdmUsIHRoZXJl4oCZcyBubyBuZWVkIHRv IGNoYW5nZSBSRkMgNDg2MiB0byBhbGxvdyBhbiB1bmF1dGhlbnRpY2F0ZWQgVkwgJmx0OyAyaHJz LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRpbTwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+UmVnYXJkcywm bmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5NYXJrLjwvZGl2Pg0KPGRpdiBk aXI9ImF1dG8iIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8i IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGNs YXNzPSJxdW90ZWQtdGV4dCI+PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7MS4mbmJzcDsgSWYgdGhlIHJlY2VpdmVkIFZhbGlkIExpZmV0aW1lIGlzIGdyZWF0 ZXIgdGhhbiAyIGhvdXJzIG9yPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtncmVhdGVyIHRoYW4gUmVtYWluaW5nTGlmZXRpbWUsIHNl dCB0aGUgdmFsaWQgbGlmZXRpbWUgb2YgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb3JyZXNwb25kaW5nIGFkZHJlc3MgdG8g dGhlIGFkdmVydGlzZWQgVmFsaWQgTGlmZXRpbWUuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0icXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9InF1b3RlZC10ZXh0Ij48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCi0tPGJyIGNsYXNzPSIiPg0KSklOTUVJLCBUYXR1eWE8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJlbGlkZWQtdGV4dCI+PGJyIGNsYXNzPSIiPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPHdiciBjbGFzcz0iIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 d2JyIGNsYXNzPSIiPi0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5v cmciIGNsYXNzPSIiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2NiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnIgY2xhc3M9IiI+bGlzdGluZm8vaXB2NjwvYT48 YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyIGNsYXNzPSIi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnIgY2xhc3M9IiI+LS0tLS0tLS08YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F634A38468F46B681D517D96223F163jiscacuk_-- From nobody Thu Jan 12 07:29: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 1FC98129518; Thu, 12 Jan 2017 07:29:15 -0800 (PST) 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 DcqzkXNKQQww; Thu, 12 Jan 2017 07:29:13 -0800 (PST) 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 E674E12946F; Thu, 12 Jan 2017 07:29:12 -0800 (PST) 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 v0CFTCIx048669; Thu, 12 Jan 2017 08:29:12 -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 v0CFT57r048597 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2017 08:29:05 -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.1178.4; Thu, 12 Jan 2017 07:29:04 -0800 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.1178.000; Thu, 12 Jan 2017 07:29:04 -0800 From: "Templin, Fred L" To: Tomoyuki Sahara Subject: RE: [Int-area] Route Information Options in Redirect Messages Thread-Topic: [Int-area] Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAXiyiAAA9u9DAAbzYZgAAACCrg Date: Thu, 12 Jan 2017 15:29:04 +0000 Message-ID: References: <113477DD-778C-4C0E-899C-A75C8D04A878@iij.ad.jp> In-Reply-To: <113477DD-778C-4C0E-899C-A75C8D04A878@iij.ad.jp> 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: Cc: INT Area , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:29:15 -0000 Thank you, Tomoyuki-san. I agree with your observation, and will make the necessary changes to the draft. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Tomoyuki Sahara [mailto:tsahara@iij.ad.jp] > Sent: Wednesday, January 11, 2017 11:28 PM > To: Templin, Fred L > Cc: 6man WG ; INT Area > Subject: Re: [Int-area] Route Information Options in Redirect Messages >=20 > Hi, Fred >=20 > > If the concern is for backwards compatibility with legacy deployments, = the > > proposal honors backwards compatibility per RFC4861. What do you think? >=20 > From the section 3. of the draft: >=20 > "The contents of the Reserved field, and of any unrecognized > options, MUST be ignored. Future, backward-compatible changes to > the protocol may specify the contents of the Reserved field or add > new options; " >=20 > RIO options in Redirect Message are not "unrecognized" options > but are "not specified to be used with Redirect memssages". The > next pragraph in RFC4861 is better text to be quoted: >=20 > The contents of any defined options that are not specified to be used > with Redirect messages MUST be ignored and the packet processed as > normal. The only defined options that may appear are the Target > Link-Layer Address option and the Redirected Header option. >=20 > ( https://tools.ietf.org/html/rfc4861#page-74 ) >=20 > Once the draft is published as a RFC, it shall update the second sentence= . >=20 >=20 > Thanks, > Tomoyuki >=20 From nobody Thu Jan 12 10: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 3872A12940F for ; Thu, 12 Jan 2017 10:27:50 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 pAbU0yt_RJyY for ; Thu, 12 Jan 2017 10:27:48 -0800 (PST) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::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 AD01B1293F3 for ; Thu, 12 Jan 2017 10:27:40 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id f4so3404160qte.2 for ; Thu, 12 Jan 2017 10:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=2+p8r15mlrkp1vdy+qrGvEIHTerTH1YnyI6xLtTpXQI=; b=fwzQVzII9OINhMro+b3AGz6oDnIBQdv4O0VxhzED4Y1lP8OA5W6CT2gDQ3leuFZHJT 8bLBrrfvAyb9mjjm1tg5OA+3Ip4IHLoY4AgRLgQQi5/xRbr78/h6po4aT1R+pgkuufJP 1Vp86YTRTRWJfQGcyuxyZLvSxzdB5JiLJGHNdyQMsRjKd4IgK35YBP3KXxuRS6KMoZPw 4YoKIb5CjPqJ7d0Dx7M1TKI+GlJC3WxLz3inQiv1FovtH1x5YYSnN94S8Fi8QQmOygIa Qtsnifp1HiuQdYpV+50Cnmut9r6rqc5PxRA7VLFF5qeLMeLsTnMGA6LE5TxJ4SJ3q/P3 Bqpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=2+p8r15mlrkp1vdy+qrGvEIHTerTH1YnyI6xLtTpXQI=; b=mPEtAmPGw+gLGihbbkhmNFfLuk2aI9G9U64lgAehUYdUSq7/QE9ED5fuSrg8UxxvoW o/qMzoyD+uYCCCwuxQCZvKX7+stEyKAu8I3h5Cp/+t837GvY8eR9bxdz4o5/baE6LID/ m/7D47b/5B1orp1h5cRWvc15JM/Ztpcg5PpHX6CXvepuJMAcTbIcsbGSdZh5TFCRudk8 3r0md9VYHt0etXacdFNoYOat4s8Hf9bGvc0U5Q6RDJQEKq8/d23K2/dqVclJ0VVoh9hp LZzYqBuX4Q4/3Gu3edlr+4JnLm8m1BtqshZ35MHg5EFsmuEeADTvOK4DDb83mlpzBB0b 8DSw== X-Gm-Message-State: AIkVDXKoDdAGIP/TeclcLfD8aJVQr2yAEuw9VhEdARlicqoMZEbLMKWKGHu5+d93XL6o+CfqYtPjxXrcKjsGJQ== X-Received: by 10.200.34.12 with SMTP id o12mr9521509qto.93.1484245659784; Thu, 12 Jan 2017 10:27:39 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Thu, 12 Jan 2017 10:27:39 -0800 (PST) In-Reply-To: <0D24BC9F-26DD-4ABF-965A-84C5708B900D@jisc.ac.uk> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <0D24BC9F-26DD-4ABF-965A-84C5708B900D@jisc.ac.uk> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 12 Jan 2017 10:27:39 -0800 X-Google-Sender-Auth: _v9XAIC09WeuuPN0jU0BlqcJEA4 Message-ID: Subject: Re: update to rfc2464bis To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:27:50 -0000 At Thu, 12 Jan 2017 13:38:31 +0000, Tim Chown wrote: > I support Lorenzo=E2=80=99s suggestion to change the text in the -bis upd= ate to emphasise the recommendation is for *stable* identifiers. > > This reflects what the default-iids draft clearly states: > > "This document changes the recommended default IID generation scheme > for cases where SLAAC is used to generate a stable IPv6 address. It > recommends using the mechanism specified in RFC7217 in such cases, > and recommends against embedding stable link-layer addresses in IPv6 > Interface Identifiers.=E2=80=9D +1. That matches my recollection of the latest discussion for default-iids. -- JINMEI, Tatuya From nobody Thu Jan 12 12:10:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19F7129408 for ; Thu, 12 Jan 2017 12:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNuUHC_ixZSR for ; Thu, 12 Jan 2017 12:10:05 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC8F1293F0 for ; Thu, 12 Jan 2017 12:10:05 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id i68so22518445uad.0 for ; Thu, 12 Jan 2017 12:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BKY0bfxMBQm9V7M7ID1pFkKnnU4JiKKUtQCEP2BLqF8=; b=IF8CvqfRFzI1j4iU3jKclHI7/rOLF5kD73CadxDCMYIu5FVtZsM0RGlTdMFRiUxozn cNb11GmE6ETPQAopUQf6MtL4DOO9OHawKXnZDGk7Xgp9wLcD+qlOTNM25fIwLvKhySKH KP1OA1CQtpNvs7gOmgwD2i+XAEEXF15gdFQu8hDEELF+OKiNgocXX++SW47/TBwXASf9 8E/4HqLeThW2b4XrnI7jYnT4nz4KZyTKiWxQszRw0qvYlx7PENQYdvihHXGh7rzoq98G DKwUNNDwda7DEzrZQYVIeisq1r/5twSbRgKmjHx6DEmz/OTRAPIW7vJYrsH9oE2ETVjT DSaw== 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=BKY0bfxMBQm9V7M7ID1pFkKnnU4JiKKUtQCEP2BLqF8=; b=Jed2MXzIgX4YXhqoVaP+2GwuyCksa1Qe5DuycTqMirQOtYj2yhLNVnHF+nGGNL0Ssu nskd02JNs/GF6FgeWn/ByRJ2sHNVXj5ngX3FztrurwIZcFSPPa5CL68273dvP9K+6NvN SGLEYzhiQuIadcfopEib8mJykkdYfU/UqPrUIqJVYnXxDFvrct5tHGpdNLHPmr5+pu8s m7tqjMrO0coEhSlsg6CSSXoxxcJXKYRHOrWUd32JvqdM6FtNTyuq42Vi54D8cYF9+3cX hepFbqlLsHTSWE3X0tA1kNj8sHBktwi6OPw3zitkxFUUD/a5cvN37xQf4DEpaAUHWOrJ v2Vw== X-Gm-Message-State: AIkVDXKUK1jO+GQ6OEumd/mCNJWYwhvbaZ9Mx+Pmj1rHQRgfGt5AYRCwSQ1vtzX7o14yRSvWzpz8Tw0CpQG6qQ== X-Received: by 10.159.36.73 with SMTP id 67mr8500748uaq.124.1484251804810; Thu, 12 Jan 2017 12:10:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Thu, 12 Jan 2017 12:09:34 -0800 (PST) In-Reply-To: References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> From: Mark Smith Date: Fri, 13 Jan 2017 07:09:34 +1100 Message-ID: Subject: Re: update to rfc2464bis To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , Bob Hinden , Suresh Krishnan , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:10:08 -0000 On 12 Jan. 2017 23:19, "Lorenzo Colitti" wrote: On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont wrot= e: > > > All these documents are about generating stable addresses, not temp= orary > > addresses. So I'm not sure why the text should be removed. The text= in > > all this documents ae about stable addresses. IETF-wise, the only d= oc > > that is about temporary addresses is RFC4941. Hence the text seems > > correct to me. > > > > If instead of removing that text we can clarify that it only applies to > > stable addresses, that works for me. Suggestion: change "These are > > described in Appendix A and are no longer recommended." to ""These are > > described in Appendix A and are no longer recommended for stable addres= ses." > > Fine. Isn't the assumption in all these RFCs that the addresses are > stable, and that the MAC addresses are unique? > Yes, those documents were written when randomized MAC addresses did not y= et exist, yes. But those assumptions are not valid today; randomized MAC ad= dresses are not only in use, there are standards track documents that assum= e their use (e.g., RFC7844). Since we're now republishing these documents, = we need to make them reflect the state of the world as it is today, and the= revised documents must not assume that MAC addresses are unique and static= . (IEEE) MAC addresses aren't the only types of link layer addresses and may not be in the future. ARCNet only has 8 bit link-layer addresses and despite its age, it still looks like it is being manufactured and used. https://www.ccontrols.com/tech/arcnet.htm CanBus, used in cars, looks to only have 11 bit or 29 bit addresses https://en.wikipedia.org/wiki/CAN_bus#Frames I'm sure there are other link layers out there that we would want IPv6 to run over that have similar sorts of link layer address sizes. I don't think we shouldn't bind IPv6 address security properties to link layer address properties, because then it puts the IPv6 address security properties out of our control. We could require link-layer addresses to be of a certain size and have certain properties before running IPv6 over it, however that will limit IPv6 applicability (in other words, demand that the link layer addresses under IPv6 MUST be IEEE MAC addresses.) We could try to check the randomness properties of the link layer address before using it in a IPv6 address, however then you still need a fall back if the link-layer address fails that test, so you're going to have general, non-link layer specific fall back method available anyway, and the extra code complexity of link layer address validation checks. I think it is simpler and easier to ignore the link layer address properties and generate IPv6 addresses with good security properties independently of them. The only use of link layer properties is as a possible seed and as an interface distinguisher when useful or necessary, which is what RFC7217 does. I think it is better to try to minimise the coupling and dependencies between the link layer and link layer properties and the IPv6 layer rather than trying to tighten it. That seems to have been a theme of IPv6 e.g., using DHCPv6 over PPP rather than embedding IPv6 upper layer parameters in PPP such as DNS addresses, and the shifting of neighbor discovery into IPv6 rather than having a parallel link layer specific neighbor discovery protocol (i.e., ARP and IPv4 being in a parallel, and ARP being Ethernet specific.) This theme is described in RFC1958, even though security benefits may not have been the reason for it at the time. "The Internet level protocol must be independent of the hardware medium and hardware addressing. This approach allows the Internet to exploit any new digital transmission technology of any kind, and to decouple its addressing mechanisms from the hardware. It allows the Internet to be the easy way to interconect fundamentally different transmission media, and to offer a single platform for a wide variety of Information Infrastructure applications and services. There is a good exposition of this model, and other important fundemental issues, in [Clark]." > > The reason the text needs to be changed is because during the discussio= n > > of default-iids there was substantial discussion of the use case of > > using EUI-64 with randomized MAC addresses. There was consensus that > > this is a use case we want to support, and as a result, the working > > group concluded that we should change every occurrence of the phrase > > "based on a link-layer address" to "based on a stable link-layer > > address" in the default-iids draft. > > My read of the discussion is that you didn't want default-iids to ban > this case (and maybe there was not more than one or two voices in this > direction), and we simply decided to have default-iids fous on stable > addresses to be able to do progress on something. Claiming that doing > temp adderesses by doing MOdified-EUI64 is streching that outcome quite > a bit, IMO. > Funny... my read of the discussion is that everyone wanted to support thi= s case and only you didn't (and maybe there was not more than one or two vo= ices in this direction". :-P I also supported the decoupling. I understand the convenience and motivation for using random MAC addresses (I've had many of my systems including my main laptop changing them at boot for a number of years now), however I think it is a layer dependency that is better to avoid (i.e., have addresses at both layers that have good security properties and that don't have any security bindings or couplings between each other.) Regards, Mark. >But seriously: regardless of which of the two interpretations above is cor= rect (likely neither), the fact of the matter is that the text in default-i= ids says "stable" and that did not happen by chance, but through explicit w= orking group discussion. We have to respect that here. > All this documents talk about stable addresses. Discussing temp > addresses in them is actually talking about stuff that simply wasn't > there, with operating conditions different from those assummed so far. Again: we are republish these documents and we have to do so taking into account things as they are today. Today, the fact of the matter today is that MAC addresses are in use and the documents have to reflect that. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Thu Jan 12 12:52:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE2129442; Thu, 12 Jan 2017 12:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRhuxpZokI4C; Thu, 12 Jan 2017 12:52:02 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128CE129435; Thu, 12 Jan 2017 12:52:02 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id u25so4395924qki.2; Thu, 12 Jan 2017 12:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wAGyaYxKQLManmZq7r5ngCgFcE9I3MNbdtLqto4d8A=; b=qy12Nu7HoTWTZsjSZ18Gef3dQUvgDo+4f7FFH8Ca5RJYz67R6nlTTRhqjVbApba6BO MD9sAXV/DHd4LV85UhKTSSjmWgbJ4v4+srwXXoY2Istdi8y4SW+4UCS9Nejadm4FY2vC OGxgOCE0L0/NkUZRIeb7LVSjpLevZ/1J1ms8oiL3UQ3DZgjVP62SUL91zPmeJq1/uQPq ic7eqNnQzXaLM1SHN2nehpnEvH5gPF+cvVLq9wsEdlzgsJC5H8Jhiq7ZmgQjXmTl9gSg Lm6qhAKUkoaRA3EmgXFIjDHX5wuHAiQsWrRG75udXcyevmS/62pZE8a8lIGN/unAxsu4 APEQ== 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=3wAGyaYxKQLManmZq7r5ngCgFcE9I3MNbdtLqto4d8A=; b=Rq1N2svxHqVcWAsTLQxwE187iphsp00eGV8y7pYaUQlfObaONbpGwk1padbAPBA/k+ 9huwK1ZCL/wI0O5NUX8r/yN/CvYQ41AR955hG1efsAQuYakcBABrSJ2dDP9lDpadCfRH n10lpaQCFzjg/APOmMQHKvzjYK7iCjr5rb5EIzsdRPRdDcYbQYbeNa+Wn8CNZzjzOiuB ilMDoTCclPm0nkamlEW0qNmIJqJTbPH5iMpU5GsXAsYvy8OH1g3kakVZEKftpCeHquXd MxftTIooenYAtE03kXsiiNmmIjZcT+cr+NKnAQM8sho+c2vUgmCpG/xGeL0UY3BXT5Zi FbYg== X-Gm-Message-State: AIkVDXLkLkK7KQpBdZHkJ2r/e5PhHerk+dUkpXmwqUFxVB60rz/tL/jSqScfn1hCUKfSaQ== X-Received: by 10.55.100.88 with SMTP id y85mr14447119qkb.194.1484254321246; Thu, 12 Jan 2017 12:52:01 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f68sm3696330qkf.34.2017.01.12.12.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 12:52:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 From: Bob Hinden In-Reply-To: <1817689823.74706.1484144674522@mail.yahoo.com> Date: Thu, 12 Jan 2017 12:51:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <521A0BF3-E8C8-4523-8CA7-4243DFA9AE82@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <1817689823.74706.1484144674522@mail.yahoo.com> To: Punana Lebo X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Brian Haberman , IPv6 List , IETF , "int-dir@ietf.org" , Bob Hinden , "draft-ietf-6man-rfc4291bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:52:04 -0000 Keolebogile, You are correct. I will fix in the next version. Thanks, Bob > On Jan 11, 2017, at 6:24 AM, Punana Lebo wrote: >=20 > Hello > =20 > I am new to this and I hope my comment is appropriate > =20 > The examples in recommendation 7 and 8 in section 2.2.3 have been = swapped. In other words, an example given for recommendation 7 = (0:0:0:0:0:ffff:192.0.2.1 should be shown as ::ffff:192.0.2.1) must be = for recommendation 8 (2001:0db8:0000:cd30:0000:0000:0000:0000/60 should = be shown as 2001:0db8:0:cd30::/60) and vise versa. > =20 > Regards > =20 > Keolebogile > =20 > =20 >=20 >=20 > On Tuesday, January 10, 2017 6:32 PM, Brian Haberman = wrote: >=20 >=20 > Reviewer: Brian Haberman > Review result: Ready with Nits >=20 > I just have a few comments/questions on this draft. Overall, it is in > pretty good shape... >=20 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? >=20 > 2. Section 2.6.1 captures some information about reserved IPv6 > multicast addresses, but not all of them. I think it would be > beneficial to point to the IPv6 Multicast Address Allocation registry > maintained by IANA, much like the way Section 2.3 points to the IANA > registries. >=20 > 3. Also in Section 2.6.1, the names of reserved addresses, like "All > Nodes Addresses", were made all lowercase. Was that intentional? Given > that IANA refers to them with capitalization, it would seem that we > need to be consistent. So, I would either retain the capitalization in > this document or ensure that Section 3 directs IANA to update the > names in the registries. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 From nobody Thu Jan 12 13:11: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 CA2B71294F9 for ; Thu, 12 Jan 2017 13:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojctseA0atjV for ; Thu, 12 Jan 2017 13:11:27 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC791294B7 for ; Thu, 12 Jan 2017 13:11:27 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 189so18750804pfu.3 for ; Thu, 12 Jan 2017 13:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PloKaH/T/tNoG4evU8jUcVuWlgBFgTsRE6HBLzauiLc=; b=Fj2mbNUOQQcc5sYTbhjbwmtLwmDxZMHan55IeT3yXeErRjZuy6gucjzAC4nrA9txiC 9DSsuSSUqVi1JvFi4QPdi/giWB3WLbbwlyyjNc91mES0RAHRPzKmf9rH/oXkDIKU1AA2 bS7ZXNBBF84oaCmERBYXOtcUnuFNC1TmfHj6kccEgLpfZxXRo028HOvHquLSVQ3h50f9 lPdohouZFYMV3zR6a6cG/az6JJ0Fg54i8G5o2z8jNjZ5NSs6g6RLuSm14fNtnWgSG7Q9 mTGMG1FF4Au7lxkdNlSfKtoEUxWeQy6xH3jPTheztzA9dhnuZ4tnxIz6AWTfs9vTOwF3 XPew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=PloKaH/T/tNoG4evU8jUcVuWlgBFgTsRE6HBLzauiLc=; b=qJ78XoGQFyHRndZX3gs6JnAmmPKLYxdxpLvHuP7pHpbQc+hvrs6DQI4f0/T6Y51MC8 fPoXWROVnPMAtBpUfCg2mbGiFKZR0Us46u8VxJBdqM4nZzD303EwxRszNF0thxiuUchq Xa7aKPL97j8Gl4T2qIlFy2XtsF3tleNyIywYzJs/06P93DpbWRnMpW8Mu/WZxsdqIeIe VyjaekYXjnQFbVisBNU3Vst2+8Zskx3Te6tco/NW8S3rdlx4qJcy57/toczDJ3AkNGLF 2ZiNl+6P2+AGsyn7kBLITtbNTNaT5wqceG6mTal+fYAcKsXFiN/0UVbpnsucbxNPVl4s gdJw== X-Gm-Message-State: AIkVDXJeioafuoCLF9SA5a/e6tyZgP+V7gcuyIGFWBiYwMrGPvElv0BHFPykwtKOpzxvRA== X-Received: by 10.84.241.8 with SMTP id a8mr23999261pll.74.1484255486732; Thu, 12 Jan 2017 13:11:26 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id g87sm2757467pfj.20.2017.01.12.13.11.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:11:25 -0800 (PST) Subject: Re: update to rfc2464bis To: Fernando Gont , Lorenzo Colitti References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6ae2b66b-21be-a413-ee59-8aa064e583b7@gmail.com> Date: Fri, 13 Jan 2017 10:11:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IPv6 List , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:11:29 -0000 On 13/01/2017 00:29, Fernando Gont wrote: > On 01/12/2017 08:08 AM, Lorenzo Colitti wrote: >> On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont > > wrote: >> >> > I don't see why we should forbid this. It's a legitimate implementation >> > choice, and has excellent privacy properties :-) >> >> I'm not saying we should forbid this -- actually, there are scenarios >> where it should probably be the recommended approach. >> >> But that's not the operating model we have right now -- that's the >> point. >> >> The point I am making is that according to current and >> about-to-be-published specs, a node is free to create addresses that >> change over time, since nothing forbids it. > > I guess you're allowed. That does change the operating assumptions, and > I wouldn't be surprised to see breakage. It will break on sites that choose a managed addressing policy (as Tim told us they do at CERN). I wonder what Android users at CERN do? Brian > > > >> > Sure. If you can find rough consensus to say all other methods of >> > generating IIDs are bad and should not be used, the IETF will publish a >> > document saying that. My bet is that you won't. >> >> I'm not saying that. For instance, if you want temp addresses, and you >> decide to send the 64 bits with a PRNG of your choice, that's fine. If >> your goal is privacy and you decide to waste 18 bits 'cause you want to >> stick to modified-eui64, you're doing a lousy job. >> >> Good, then we agree that a node is free to create addresses that change >> over time using schemes that are not described in RFC 7217, RFC 4941, or >> any other document. > > Yes, you're "free" to do your own proprietary thing, which does not > follow any IETF stds, I guess. > > > >> > To get back to the original point: in the current state of the documents >> > that we have published or are about to publish (e.g., the default-iids >> > draft), as reflecting the consensus call sin th it's not true that >> > modified EUI-64 is not recommended. It's only not recommended if you use >> > stable link-layer addresses. >> > >> > Bob, Ole, Suresh: can we also amend or remove this text in 4291bis >> > before we publish it? I think it's an oversight because there was clear >> > consensus in 6man (Fernando being in the rough) that it was OK to use >> > modified EUI-64 with non-stable MAC addresses: >> > >> > Earlier versions of this document described a method of forming >> > interface identifiers derived from IEEE MAC-layer addresses call >> > Modified EUI-64 format. These are described in Appendix A and are no >> > longer recommended. >> >> All these documents are about generating stable addresses, not temporary >> addresses. So I'm not sure why the text should be removed. The text in >> all this documents ae about stable addresses. IETF-wise, the only doc >> that is about temporary addresses is RFC4941. Hence the text seems >> correct to me. >> >> >> If instead of removing that text we can clarify that it only applies to >> stable addresses, that works for me. Suggestion: change "These are >> described in Appendix A and are no longer recommended." to ""These are >> described in Appendix A and are no longer recommended for stable addresses." > > Fine. Isn't the assumption in all these RFCs that the addresses are > stable, and that the MAC addresses are unique? > > > >> The reason the text needs to be changed is because during the discussion >> of default-iids there was substantial discussion of the use case of >> using EUI-64 with randomized MAC addresses. There was consensus that >> this is a use case we want to support, and as a result, the working >> group concluded that we should change every occurrence of the phrase >> "based on a link-layer address" to "based on a stable link-layer >> address" in the default-iids draft. > > My read of the discussion is that you didn't want default-iids to ban > this case (and maybe there was not more than one or two voices in this > direction), and we simply decided to have default-iids fous on stable > addresses to be able to do progress on something. Claiming that doing > temp adderesses by doing MOdified-EUI64 is streching that outcome quite > a bit, IMO. > > > >> We should make the same distinction >> in 4291bis and 2464bis: EUI-64 is not recommended for use with stable >> link-layer addresses, but it can be used with non-stable link-layer >> addresses. > > All this documents talk about stable addresses. Discussing temp > addresses in them is actually talking about stuff that simply wasn't > there, with operating conditions different from those assummed so far. > > Again, I sympathize with temp only in scenarios where they make sense. > But things like that don't seem within what has been specified so far > (i.e., there's work to be done, including analyzing what might break). > > Thanks, > From nobody Thu Jan 12 13:23: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 E23921294F9; Thu, 12 Jan 2017 13:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEscyawGqAVT; Thu, 12 Jan 2017 13:23:00 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4431289C4; Thu, 12 Jan 2017 13:23:00 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id a29so3966717qtb.1; Thu, 12 Jan 2017 13:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R+VhdfW2filhZ56WH8Iu0cuAdQBr7128BRBknFIr6hQ=; b=EMC3SXU74Ui0oP1JlqisfW39sI3cv+SyTycq2rvTUaJeyUYLiP4DwYCKAXBSGHulCN JJGoJb+pwEceRtvdf+SJHsyAFy1sFB99/u1LlBg/ztSpB9rCMyKZjK+fAwCxB8H7Dyyb 8zJnyYTLYWlk1eDVI+94BXu2hwaDr5QTycEuigjDUiPLxNUTeK0C+F0NXPk4Kw2OlAst gsWjDJTk0w2WWR7H+SZHq2tkZwLS73bopT1812EgoPqzTTipNqHmqn7rsrQM+clJF7E7 GW4gHeQEjFYZQLZi1pi8DA2Kw6j93GZzqMrOCTPI66ez83naj0haxswbJYHfOzpp+opi hZeA== 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=R+VhdfW2filhZ56WH8Iu0cuAdQBr7128BRBknFIr6hQ=; b=DNrR5fLLMOpVA1wQGiqTGawU3ux/bNdCk77w3nafYSiZ7Y0fzSGfNdcqg8ITML0YEj eDFBrrIEss1GkeHig8hL3fvC7PiMZKyOdyO4caFFfYk327UHNByKmy7xSQyD75ebCT5h chQVQM8UAv7+XO2lUzv+2Wa5Wt2liIfH3/OuvccChUnV2mAJLsOSLVIpAwLcb9D9kKyS m9WUoXbrtVtNC5+hEP+VhjsUqqBcfo9uVBL5oVq4ulveec52cW74no0jWNZb5TuDDb32 7Dz0h1peuneQxCLa3ZnvymHQEdRv1P0scDl+PFQO1CcrZZT8uyAgOJ6NMo5OXFdjBA7U eeqQ== X-Gm-Message-State: AIkVDXJiaA81XsmNe8Jn0NPH9tqrTs1ahQoe7ATAmxL7e/4DQDiFPu+1bqQYSeynLwWauQ== X-Received: by 10.237.50.193 with SMTP id z59mr3325956qtd.102.1484256179217; Thu, 12 Jan 2017 13:22:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z29sm7592799qtz.16.2017.01.12.13.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:22:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 From: Bob Hinden In-Reply-To: Date: Thu, 12 Jan 2017 13:22:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Brian Haberman , IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:23:02 -0000 Randy, > On Jan 10, 2017, at 5:52 PM, Randy Bush wrote: >=20 >> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but >> I don't see a reference to 5952. Is the intent to deprecate 5952 = since >> its content is now contained within 4291bis? >=20 > 5952 has much more very useful detail for those of us who write = software > to parse, compare, ... textual representations of ipv6 addresses, see > section 4 of 5952. so i suggest the replacement of 2.2 with a = reference > to 5952. Per your comment and Brian=E2=80=99s suggestion, I will add a reference = to RFC5952. RFC5952 doesn=E2=80=99t replace the definitions in RFC4291, = it make a recommendation on outputting IPv6 text representation, so I = don=E2=80=99t think it=E2=80=99s appropriate to replace 2.2 with just a = reference. >=20 > it is very cheering to see section 2.4.0, "96 more bits no magic" > [credit gaurab]. Good >=20 > but i am having a hard time reconciling 2.4.4's insistence on a > mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc > 6141, widespread operational practice, ... clue bat please. >=20 This was discussed extensively in 6MAN and resulted in RFC7421 "Analysis = of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The text in = rfc4291bis is: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Thanks, Bob From nobody Thu Jan 12 13:23: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 1EC4C12952C; Thu, 12 Jan 2017 13:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihmqukt2VTn1; Thu, 12 Jan 2017 13:23:05 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E94D129508; Thu, 12 Jan 2017 13:23:05 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id a20so4523780qkc.3; Thu, 12 Jan 2017 13:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPn2mmtkWbb7HcnLjVnLMoAjEEe6EW8/1dSGsa3/JjI=; b=T+u2Xv21uuW4Wj1OnQ4bDZaPJ6KjsRuaqV1FtfNNpOYtGoltMOpjw2juuFsOK6T3Dw HhnsXbvsi2aj4cqlA2H6UwQycpyTT90E2TMBy+t+GbGZ3eC0XcyLlG0459WYI6Yl0DG2 M4TQCKxWQ5znJt8phknmy3huf5sIZXa2Ef6DJpgAqhrRY7roJjpixZZzX5xSe0ET2h/Y g8hJp5nkfIpM5SSLzd2nuD0C/iwWZSFvWH0fUUV503uzYSpySuzk/vg+Cx6wSfVCGDKf s/Co1Z5VSMBRhc7pHgvnf6t/ZxDeqUJuQ8jxtYL/eZAc3QGrizmbBU86o0OXp2gJxwm/ 8PpQ== 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=GPn2mmtkWbb7HcnLjVnLMoAjEEe6EW8/1dSGsa3/JjI=; b=qJWFjx88YcHj8rqdKyOj5zaVNeOFOkJcccxuAv/ilXqtADS24tvBbu2BrC+HojTYiH FYGxU56SggStd5y9pBMa+151l7z1tEc0IOCq4gejzbOkqOYfmL7yZQ1rswXtZjQlIAe3 tki99hG2dXefnE19aJEpRByiIqnPqLY1srYo9AAAYVyxEFGSCc49gvMDAPmtNrHF2NWU 1D5AMWPjxdc05QeHd3710b1p7crmekaOmHUE/jx7BlXJf5V4PzjBaXgrv2ZJxMOJ/y5c uj5FEZF5MzuBzQqFg8NrRt1rFK/rKYOxn/gubBpmf+u2e1y4y+ju9pUL6QziWbydSM+z 21XQ== X-Gm-Message-State: AIkVDXIHdr3nbHVBWX2PmU7g3xWxKpUIXY+FtGIZ5YBH8FYVe85tfJQUwL4AnlWDwDBuTg== X-Received: by 10.233.216.7 with SMTP id u7mr14905579qkf.220.1484256184466; Thu, 12 Jan 2017 13:23:04 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z29sm7592799qtz.16.2017.01.12.13.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:23:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 From: Bob Hinden In-Reply-To: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Date: Thu, 12 Jan 2017 13:23:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , Bob Hinden , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:23:07 -0000 Brian, > On Jan 11, 2017, at 7:32 AM, Brian Haberman = wrote: >=20 > Hi Bob, >=20 > On 1/10/17 7:48 PM, Bob Hinden wrote: >> Brian, >>=20 >> Thanks for the review! >>=20 >>> On Jan 10, 2017, at 8:32 AM, Brian Haberman >>> wrote: >>>=20 >>> Reviewer: Brian Haberman Review result: Ready with Nits >>>=20 >>> I just have a few comments/questions on this draft. Overall, it is >>> in pretty good shape... >>>=20 >>> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, >>> but I don't see a reference to 5952. Is the intent to deprecate >>> 5952 since its content is now contained within 4291bis? >>=20 >> I didn=E2=80=99t include a direct reference in the Section as = incorporates >> the changes, but it is included in Appendix B describing the >> changes. >>=20 >> No current intent to deprecate RFC5952 as it updates RFC4291. I >> don=E2=80=99t see very much value in deprecating (Historic?) the = updating >> RFCs. >=20 > I will agree with Randy that there is useful info in 5952 that people > need to see. Adding a reference to 5952 here would point people in the > right direction. Makes sense, I will add a reference to RFC5952 in the next version of = the draft. Thanks, Bob >=20 > Regards, > Brian >=20 From nobody Thu Jan 12 15:26: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 74BD7128BA2; Thu, 12 Jan 2017 15:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 3un8lIYBLFpl; Thu, 12 Jan 2017 15:26:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AF2129439; Thu, 12 Jan 2017 15:26:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRoku-0000P5-1S; Thu, 12 Jan 2017 23:26:04 +0000 Date: Fri, 13 Jan 2017 08:26:00 +0900 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Brian Haberman , IPv6 List , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 23:26:07 -0000 >> but i am having a hard time reconciling 2.4.4's insistence on a >> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc >> 6141, widespread operational practice, ... clue bat please. > > This was discussed extensively in 6MAN and resulted in RFC7421 > "Analysis of the 64-bit Boundary in IPv6 Addressing$B!I(B. The text in > rfc4291bis is: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. > Background on the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. thanks for the review that the wg came to this decision in conflict with operational practice and its own statement in 2.4.0. i did read the documents. since it is incorrect, ietf last call seems to be the time to fix it. to be clear, i have no problem with iids being 64-bit. my issue is with unicast globals being classful in 2.4.4. randy From nobody Thu Jan 12 15:42:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ED8128824 for ; Thu, 12 Jan 2017 15:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlqb3FnAvIi5 for ; Thu, 12 Jan 2017 15:42:00 -0800 (PST) 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 09F12128B37 for ; Thu, 12 Jan 2017 15:42:00 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id 11so37914311qkl.3 for ; Thu, 12 Jan 2017 15:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=si4xgGvAS5IbOazva6BLUH0QYeWBjfvBaXtPvTK6CpY=; b=nESS9Rr240VEkN46/EiqcyLg9XJz8NJVQYfOLx03XhYsNG8FpGhuht8M8qxdv0ULGR VVIdgY30VybGlgazShhzYOQcu5hJUXcFncPLge1STwIwLahmJ/vJT5LFs9tE9ftaREo6 UaNJ/5NAD334nqnBSp087bF/M5Dk9xsCbcGErzdZwKxqio7MkLrdeuroY/keBg1CAAiy zU/wN9lP6MVf76vMOoXbpzevu5/093U9fVST7cBfYkIlHJROxS0O32DrDu0zRSey10Yd UV8glRtDnSKRPcPf92SNlhRmrvIlLATcXQ18jtZCArQbDezUFki+yFQRSlUvfuaIZa9I mqUQ== 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=si4xgGvAS5IbOazva6BLUH0QYeWBjfvBaXtPvTK6CpY=; b=IMmhSaWV3KkLFI18TLx0ymjWPIw9zu3T8/nU/xptw5GP9tL6uUDgQDCZHqMhiZsoQE n4t6pKrlvaz255s6X+CriVDSxRxZa2Qnf7Jbj+olsHDbeJZsn6DEY0NSBJSOSUHExC0w zkS+kxOv27dE1vWPFUzbAgIQaEyodp0qFLHbV0zQzCVSUvs4Df8oDUTggCXPdeYGAotH rjAhyj6tdvc4Wk6XwxmTLda2PSq6yG7yIX50IBMsWsWwxes/73MZwKpoPTTUYwDhV/0x eUXsWS9900wx3+f+63eAewxW2xIvBu4U0nQyOhwho70w6YPx12Gbk4ssePQ0R2cidXvR TNMw== X-Gm-Message-State: AIkVDXK5fDjawi5Jv0ihRv1Fl020lc2clTPPAiAtWl8go9ZMVepCesK+29yrerF4vhbGOA== X-Received: by 10.55.167.5 with SMTP id q5mr15453124qke.61.1484264519161; Thu, 12 Jan 2017 15:41:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c83sm7864182qkg.8.2017.01.12.15.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 15:41:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: update to rfc2464bis From: Bob Hinden In-Reply-To: <54156254-4bfd-d27f-a37d-7efa45cad218@si6networks.com> Date: Thu, 12 Jan 2017 15:41:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <674AEF02-9DEE-4BD1-AAC3-885E87123875@gmail.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <54156254-4bfd-d27f-a37d-7efa45cad218@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 23:42:02 -0000 Hi Fernando, Thanks for the comments. =20 Inline. Bob > On Jan 11, 2017, at 8:59 PM, Fernando Gont = wrote: >=20 > Hi, Bob, >=20 > I agree with your view. Some further comments below: >=20 > On 01/09/2017 05:40 PM, Bob Hinden wrote: >> Hi, >>=20 >> Based on update from draft-ietf-6man-default-iids (currently in RFC >> Editor queue) I changed the first two paragraphs of Section 4 of >> to: >>=20 >> 4. Stateless Autoconfiguration >>=20 >> The default approach to create stable Interface Identifiers=20 >> [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet=20 >> interface should be based on [RFC7217]. >=20 > maybe s/should be based on/is spaciefied in/ ? I used =E2=80=9Cshould=E2=80=9D because on it comes from = draft-ietf-6man-default-iids, that is: Nodes SHOULD implement and employ [RFC7217] as the default scheme = for generating stable IPv6 addresses with SLAAC. so I think the =E2=80=9Cshould=E2=80=9D is important. >=20 >=20 >=20 >> It is not recommended that Interface Identifiers for an Ethernet=20 >> interface be based on IEEE MAC-layer addresses. >=20 > Maybe s/It is not recommended/Nodes should not/ ? Likewise, draft-ietf-6man-default-iids uses the recommend language. = This is, By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID. In particular, this document RECOMMENDS that nodes do not generate stable IIDs with the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391], [RFC5121], and [RFC5072]. >=20 > Maybe a reference to default-iids could be useful here (in addition to > the text). Let me think about that a bit. >=20 >=20 >> Earlier versions of=20 >> this document described a method of forming interface identifiers=20 >> derived from IEEE MAC-layer addresses called Modified EUI-64 format.=20= >> This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is=20= >> no longer recommended. >>=20 >> Instead of having it pointing to , the >> new text points to RFC7271. I thought this was better as Section 3 >> of says the RFC2464 should now follow >> RFC7271 (including should use RFC7217 and should not use stable >> link-layer address). Avoids a extra hope so to speak. >=20 > Agreed. Good, thanks. >=20 >=20 >> I think the intent of is captured in >> the text in the new -01 version. >>=20 >> Comments? >=20 > Looks fine, but please check the small suggestions above. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Thu Jan 12 15:57: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 9EA2C1294EB for ; Thu, 12 Jan 2017 15:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 512YUpgQUerk for ; Thu, 12 Jan 2017 15:57:41 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 0A8E6129434 for ; Thu, 12 Jan 2017 15:57:41 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id a20so38479782qkc.1 for ; Thu, 12 Jan 2017 15:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xuzOfyQaPBxlLSaexFYy1Cox4Bv6jcw0UhngjEZ8bb8=; b=ckhIVyIdewuDFhkhBC1szU9znW25i0aPOKAhq1pnaMtx5SDVyDAJaPmIXzh15GUMMZ SB7x7URZ9J6vs9UqJDhco5DJz4H4v4fT2pTiz2SQQ/tr/X8nu5OwnnJzr4/HhyZbLRYl GNBthw3k7DL4cN8BDXYiiiG6qgVajt5RxynLSEPUji6Ct+icLMxubmDsmANDuCf7s+W8 fT6AcK2UPn4ADabdNNM/+VI4d2YxUatvuJd8pEEi9sI/sMAuxv7gJYZF8mGCx3KHPIcv 1XKo2BEhJ3rAsbY0LgDhpiacwYcg5Bi49ukBmEXPQ5MxQCyBoGCSQjFoMaW+G0NYyCxV KOGw== 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=xuzOfyQaPBxlLSaexFYy1Cox4Bv6jcw0UhngjEZ8bb8=; b=fY9PbIAj0+vKiIRU7SHLBWmqeuxH/awFDGcZbu5s692VrtEjP9wjDf06mZKsiZk4k5 8sT5tbaJY7cB7tGlkUmIZMbkyDwWYNW/UCGDHpi79b+pl91OxRdFix3m3cCGdS6C7Fg9 sLQOzw9WWcbiFEwJe98NmGaPVYlOKMltK0tpndSXe+6RJE+3V2EzMSBY0Dd52MjL/wXz qkchD3J1FDmdX+g4+17jIxDrPNI/BoP77/TmHh6XF6ibEHhIagjFG0LbXbdZtilErdWu KeQOXHhDD12RWwVJAnXKMVQgQnWuKReUI35XK+hBbkHVBSTqz6YJVumttRyo70QsIR/+ Y7ng== X-Gm-Message-State: AIkVDXLUW/9U/fAvo+q9zvTFtn7QBOUT3GvJ9NtIYZeFSSbLM7K5D0oJg0rp95D7bfrIsQ== X-Received: by 10.55.86.196 with SMTP id k187mr17026419qkb.203.1484265460237; Thu, 12 Jan 2017 15:57:40 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d20sm7847834qtb.17.2017.01.12.15.57.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 15:57:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: update to rfc2464bis From: Bob Hinden In-Reply-To: Date: Thu, 12 Jan 2017 15:57:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 23:57:42 -0000 Lorenzo, > On Jan 11, 2017, at 9:21 PM, Lorenzo Colitti = wrote: >=20 > On Tue, Jan 10, 2017 at 5:40 AM, Bob Hinden = wrote: > It is not recommended that Interface Identifiers for an Ethernet > interface be based on IEEE MAC-layer addresses. >=20 > Please include the word "stable" in this sentence. (See below.) I agree, this is consistent with draft-ietf-6man-default-iids. > Earlier versions of > this document described a method of forming interface identifiers > derived from IEEE MAC-layer addresses called Modified EUI-64 = format. > This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and = is > no longer recommended. >=20 > Based on my reading of draft-ietf-6man-default-iids-16 , it's not = correct to say that this approach is "not recommended". This approach is = not recommended for use with stable MAC addresses, but there is no = recommendation against using it for non-stable MAC addresses. We do = recommended that nodes use RFC7217 addresses by default, but only if the = node wishes to create stable addresses, and there is no requirement that = a node do so. Would it be better to say (incorporating the change above): It is not recommended that Interface Identifiers for an Ethernet interface be based on stable IEEE MAC-layer addresses. Earlier = versions of this document described a method of forming interface identifiers derived from stable IEEE MAC-layer addresses called Modified EUI-64 = format. This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is no longer recommended. That is, add =E2=80=9Cstable=E2=80=9D. Would it then make sense to be explicit to add a new sentence like: This approach may be used to create Interface Identifiers based on = non-stable (e.g., random) IEEE Mac-layer addresses. with a reference to the appropriate IEEE specification. Thanks, Bob From nobody Thu Jan 12 16:29: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 781FF12957D; Thu, 12 Jan 2017 16:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKOVtHmlE3mE; Thu, 12 Jan 2017 16:29:18 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF7F129580; Thu, 12 Jan 2017 16:29:18 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id 127so5550250pfg.0; Thu, 12 Jan 2017 16:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=fJwdA+GFBmpVQdICE14dIXwD83Nai+g5E/nJ+gki5JvAqkRUeIW22yFOL6Ksf19OBm xVWVvIJd7MuhGsxAUmO3T/8uMggk3FiYwsRr6kLA+TOEij9xdqlGMsXVJl3BFpVippI2 aNrydwKqGlml0QPQqy1zgAY4VdLgfBCdM4RFBMFum0Sc3eWGU7cY2u/CVE7e/cxJtvdz 9F3JlxUkFOUTOA6zi5zfJBfFWO+vvf+F0CuFL+yb5nkaIA+F5ED4mJ0mmkoAf0eTblln nQ5Z/K08d0Y/6Maqm5rxtqnrzBQ+2FKCP6Ij9h5VrSAbepuzL/rJgtL9aJU+iQRZRq8x DguA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=oVXEH9a3bXoN3HWLrXy+tdrJhx2pDgI9fHK8W5OD2HYsDqnw+e9ukt4nF9Rl8BljWd ZHYPAOFeIxXzaqB+dLbDXxAnkOXtQu9xUqvkmI5ECKzr6sPSIMLvH58d25jKrFDNx9ap C9Wb7ppVv/ZqJ83ebeleSxl/qEBOkHTe6eO0t+PUTVmjotx9QNA1ljbCMYifELLMvEJc kLBNtXGiU+GbBD8e2jkTonjuvULrxJUYqW5yiMnnS3ww+om6fafGDZ51yacdSuBMzbzC o3yDUiyXV1YJTjTwNnjFm3S5ah8hwK7kCGEDxAlp/H76dW8zBXSJKT/u3x8juL2Zow/x 2ROA== X-Gm-Message-State: AIkVDXLj8SAQIMc4otEZEcJykV3Uhi01Aujm0o8z+dqpju445OGgIn6EU/sZ9vRGb0028Q== X-Received: by 10.84.138.165 with SMTP id 34mr25534409plp.37.1484267357375; Thu, 12 Jan 2017 16:29:17 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id t87sm19496296pfe.59.2017.01.12.16.29.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 16:29:16 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush , Bob Hinden References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> Date: Fri, 13 Jan 2017 13:29:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: int-dir@ietf.org, IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:29:20 -0000 On 13/01/2017 12:26, Randy Bush wrote: >>> but i am having a hard time reconciling 2.4.4's insistence on a >>> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc= >>> 6141, widespread operational practice, ... clue bat please. >> >> This was discussed extensively in 6MAN and resulted in RFC7421 >> "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The tex= t in >> rfc4291bis is: >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. >> Background on the 64 bit boundary in IPv6 addresses can be found in= >> [RFC7421]. >=20 > thanks for the review that the wg came to this decision in conflict wit= h > operational practice and its own statement in 2.4.0. i did read the > documents. >=20 > since it is incorrect, ietf last call seems to be the time to fix it. >=20 > to be clear, i have no problem with iids being 64-bit. my issue is wit= h > unicast globals being classful in 2.4.4. RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exc= eption. To be precise it says: The de facto length of almost all IPv6 interface identifiers is therefore 64 bits. The only documented exception is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem. I would suggest adding a similar exception statement in 4291bis. Brian From nobody Thu Jan 12 16:36: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 0F270129591 for ; Thu, 12 Jan 2017 16:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aljQxlMiKr4L for ; Thu, 12 Jan 2017 16:36:55 -0800 (PST) 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 4E927129582 for ; Thu, 12 Jan 2017 16:36:55 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so34296989qtg.3 for ; Thu, 12 Jan 2017 16:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z593Yi5oyp+cNESLXxUXwV1ZD9YNPBwscZQQo16gYJU=; b=uYhdi1+ysN13uEe5qLw8sGx3stAEvcykmBeWHd0PGr2vFrS7XNAvdeEtG63JqakTgp QhM67AcOlDrQP/6a56L7IN5Qh9v+77SNmntxypukZJpnd1zQsCfROannvE5RAxgIQLox nocyYzXg6q/0t+fEYKM4nqqU75pRz9bzKLTustUT/nZmMi8n4fapL6aNmjE3lf6rlGxt SJz9Q+3GxTbDSXVfWxaXuJPH9R1egiVYBGfzERdDuXY41XFgdQTg9Kj37RJ/F9lZDbIW zXUdmJsbI9ROEh92onLiNQZTvqxynCz/US5PBJ77Ju0e832+QZzmOD3jzWyPZlnuKHWy m/MQ== 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=z593Yi5oyp+cNESLXxUXwV1ZD9YNPBwscZQQo16gYJU=; b=nSQNHY6lp1w7/DEHlZAFXh9NXjoMi22cvFDT2GwRvTND0KwmxNez8BDquusV+mQjfR r7Yo6+dhhSHh3Tq+wikQmY66Xgb/JNnH+WRMQ+KqotQYsJDHc2nqMNEdEkQi1MwdsBd4 tm7X7qDcudLrGwHkhH6GWn9T+Q57JH0rfxluKaf+TC0YImwAN0DVfr/+lKZ3lxIkc3B/ JSYHXQqF3Frco4CF1rzcsVJzQyw5CBs0HybxhYI5S9bANSHM1r+J0+GEFZEPcHLV7syZ 2txpRH4pjGu9QY4VAOq17qTb8V6tt9kvhzAsVhaj2e9Tex1qkr97xysk5CZyKY7jBgVS jZ/w== X-Gm-Message-State: AIkVDXKVavvRZE1h7SZUjCCID7FZCpUmWXo2sJC6XvRi6pX5jnlZffWWwf99IdUAGxNalQ== X-Received: by 10.200.41.73 with SMTP id z9mr15107384qtz.137.1484267814277; Thu, 12 Jan 2017 16:36:54 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id i125sm7938845qkf.24.2017.01.12.16.36.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 16:36:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: RFC6085 update to rfc2464bis From: Bob Hinden In-Reply-To: <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> Date: Thu, 12 Jan 2017 16:36:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7EF1DB66-565A-4107-A5C2-EB4387CC9707@gmail.com> References: <370BD98D-4AA3-460F-BCF0-A1B234C6161B@gmail.com> <7FA028F2-7E36-471F-90E3-9AC6C49B7DAD@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:36:57 -0000 Ole, > On Jan 11, 2017, at 1:48 AM, otroan@employees.org wrote: >=20 > Bob, Jinmei, >=20 > As one of the authors of RFC6085 let me try to clarify how it would = typically be used. > Scenario: Wireless AP that already knows the L2 unicast address of all = stations on a link. > Some APs try to improve on IPv6 multicast on wireless by sending the = RAs as L2 unicast to each individual station. > The AP then runs through it's list of L2 unicast addresses and sends = the multicast RA with the given L2 unicast mapping. >=20 > 2464bis says: > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as defined in Section 6. >=20 > An IPv6 node receiving an IPv6 packet with a multicast destination > address and an Ethernet link-layer unicast address must not drop the > packet as a result using of this form of address mapping. >=20 >=20 > As Jinmei also says, referring to section 6 is then wrong. That = implies that the 6085 address mapping uses address resolution. Which is = not the case. >=20 > 6085 is indeed very underspecified in stating how the mapping is done, = from 6085: > The determination of the unicast Ethernet link-layer > address and the construction of the outgoing IPv6 packet are out of > scope for this document. >=20 >=20 > Either do (Jinmei):=20 > An IPv6 multicast packet may also be mapped to a unicast Ethernet > Link layer address as described in RFC6085. >=20 > Or something like: > An IPv6 packet with a multicast destination address may also be = mapped to an=20 > Ethernet link-layer unicast address [RFC6085]. > E.g. when it is clear that only one address is relevant on the link = and that the > mapping between an IPv6 multicast destination address and an Ethernet = link-layer > unicast address is already known. I agree with Jinmei and your comments that referring to Section 6 is not = correct. Adding the reference to RFC6085 is good, but as you note = above, it doesn=E2=80=99t describe how to do this mapping. The text you = suggest may be the best we can do. It=E2=80=99s not exactly an = algorithmic mapping, as the node doing it needs to know something about = the environment it is running in. I guess this is the down side of = using =E2=80=9CEthernet=E2=80=9D on a variety of media that isn=E2=80=99t = a real multicast domain. =20 Any other suggestions? Bob From nobody Thu Jan 12 16:41: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 88E0A129591 for ; Thu, 12 Jan 2017 16:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c83QxJxxF7Xj for ; Thu, 12 Jan 2017 16:41:26 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087C4129599 for ; Thu, 12 Jan 2017 16:41:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 814E8B51 for ; Fri, 13 Jan 2017 00:41:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6vYXW4_lKUo for ; Thu, 12 Jan 2017 18:41:24 -0600 (CST) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 4FFB4B10 for ; Thu, 12 Jan 2017 18:41:24 -0600 (CST) Received: by mail-ua0-f199.google.com with SMTP id i68so21445557uad.3 for ; Thu, 12 Jan 2017 16:41:24 -0800 (PST) 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=DrBxsjUKKvdM4bCytvb029AVfcukq9wPun1NBpnvlBM=; b=DxL6SNJ8/+I2baiTISRWEV32fEZVKiYDTb6NkpuLjgJRqfA/Yki/uhkrK9misSSXHS ZSRt6TsiH4tbofNFMC5yqjNq/pnVRqAISzYm+7nBwW+IuE4zAiclGapYATQ9nYS991ah 9Ge6eOONrsiXdMoMQjZnKFk3uwuOHanxY0gnKeAwPPhZu6yj5QmJwy/C4Y4Z/Kcl8mpn NMRgDrfq6xSHchblynam7eMZbWinEg+tFPbkhxKcOhDPIsGzNYHeNaehVvlomctsDG6P TqbGRs7Xvjx/2rZrgJAGNYQefRCGtvW7dNRfOc42blPS8sQUhemTOU6Ls5QE5cc5Yb17 kAPA== 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=DrBxsjUKKvdM4bCytvb029AVfcukq9wPun1NBpnvlBM=; b=no0KY7rRYPg6tcJ6w2xe/XpaQFFuzvzuEAAtQrhbC0WNiO46HVig9twypRTDe35PyF ol+qLLn9mVV1kWuksvs/qL1wYXxsKqBp6LtWEFLKnOpHcKlRVygc1DXgiK5EAETOWoAN SLFJZ0eOQvvx8+2GZtpux9MXEqH2AbGlT7P1SktXrIl7xxTX+YlCd992LDY1pFwSNgom rZ6M40nbIkEM2t0Katifud0pzQtXJHnKOibjmQb3BoEnmuynvUX466jleBz5LfN0W8CU Ys1+AzsTC0KVcmQxHAuHreP9eHQLGPWBIi8wEwwbmsCGa+Wu4z2QOgq/Ff1YGbFO6REm GM7w== X-Gm-Message-State: AIkVDXLzhc3rYVYNfAwaxLdP6FfCyub0UGmVM/u6bJhJQhBo+kamw29oNyMr1PxR4jGbpDeXgzDD67SaGAKS1WJHhz9/kgr2X9jgYPj0IwgU/dkzYN1tAyCTzCkrYQ5z+pjquh1F67wjdt22/6c= X-Received: by 10.31.49.216 with SMTP id x207mr8272015vkx.82.1484268083740; Thu, 12 Jan 2017 16:41:23 -0800 (PST) X-Received: by 10.31.49.216 with SMTP id x207mr8272004vkx.82.1484268083510; Thu, 12 Jan 2017 16:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 12 Jan 2017 16:41:23 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: David Farmer Date: Thu, 12 Jan 2017 18:41:23 -0600 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush Content-Type: multipart/alternative; boundary=001a114409b2de9ec50545ef17cb Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:41:27 -0000 --001a114409b2de9ec50545ef17cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 5:26 PM, Randy Bush wrote: > >> but i am having a hard time reconciling 2.4.4's insistence on a > >> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc > >> 6141, widespread operational practice, ... clue bat please. > > > > This was discussed extensively in 6MAN and resulted in RFC7421 > > "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The text= in > > rfc4291bis is: > > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long. > > Background on the 64 bit boundary in IPv6 addresses can be found in > > [RFC7421]. > > thanks for the review that the wg came to this decision in conflict with > operational practice and its own statement in 2.4.0. i did read the > documents. > > since it is incorrect, ietf last call seems to be the time to fix it. > > to be clear, i have no problem with iids being 64-bit. my issue is with > unicast globals being classful in 2.4.4. > > randy > > Randy I take your point, but this supposed conflict isn't new, it's not introduced in 4291bis, it goes back to RFC3513. Do you have a suggestion how to change this within the context of advancing this to Internet Standard? --=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 --001a114409b2de9ec50545ef17cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 5:26 PM, Randy Bush <randy@psg.com> = wrote:
>> but i am having a hard ti= me reconciling 2.4.4's insistence on a
>> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, = rfc
>> 6141, widespread operational practice, ...=C2=A0 clue bat please.<= br> >
> This was discussed extensively in 6MAN and resulted in RFC7421
> "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D.=C2= =A0 The text in
> rfc4291bis is:
>
>=C2=A0 =C2=A0 For all unicast addresses, except those that start with t= he binary
>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits long.=
>=C2=A0 =C2=A0 Background on the 64 bit boundary in IPv6 addresses can b= e found in
>=C2=A0 =C2=A0 [RFC7421].

thanks for the review that the wg came to this decision in conflict with operational practice and its own statement in 2.4.0.=C2=A0 i did read the documents.

since it is incorrect, ietf last call seems to be the time to fix it.

to be clear, i have no problem with iids being 64-bit.=C2=A0 my issue is wi= th
unicast globals being classful in 2.4.4.

randy


Randy= I take your point, but this supposed conflict isn't new, it's not = introduced in 4291bis, it goes back to RFC3513.=C2=A0 Do you have a suggest= ion how to change this within the context of advancing this to Internet Sta= ndard?

--
=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 & Tele= communication Services
Office 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
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612= -812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
--001a114409b2de9ec50545ef17cb-- From nobody Thu Jan 12 16: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 DCDA71295AE; Thu, 12 Jan 2017 16:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 JvX4lMZxvm7a; Thu, 12 Jan 2017 16:49:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96C4129476; Thu, 12 Jan 2017 16:49:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRq3J-0000pc-Rw; Fri, 13 Jan 2017 00:49:10 +0000 Date: Fri, 13 Jan 2017 09:49:07 +0900 Message-ID: From: Randy Bush To: David Farmer Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:49:13 -0000 >> to be clear, i have no problem with iids being 64-bit. my issue is with >> unicast globals being classful in 2.4.4. > Randy I take your point, but this supposed conflict isn't new, it's not > introduced in 4291bis, it goes back to RFC3513. i know; and i have pushed back every cm of the way. it took years to get the other classful insanity, tls/nla, removed. the old cidr war continues. this last bit of classfulness (excuse the word) too will pass. > Do you have a suggestion how to change this within the context of > advancing this to Internet Standard? yes. simply remove the mandatory requirement for classful global unicast addresses. randy From nobody Thu Jan 12 16:50: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 B033B1295B0; Thu, 12 Jan 2017 16:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 vmdWQc2N3Uke; Thu, 12 Jan 2017 16:50:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8313C1294BC; Thu, 12 Jan 2017 16:50:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRq4l-0000qE-8F; Fri, 13 Jan 2017 00:50:39 +0000 Date: Fri, 13 Jan 2017 09:50:36 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:50:41 -0000 > RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. > To be precise it says: > > The de facto length of almost all IPv6 interface identifiers is > therefore 64 bits. The only documented exception is in [RFC6164], > which standardizes 127-bit prefixes for point-to-point links between > routers, among other things, to avoid a loop condition known as the > ping-pong problem. > > I would suggest adding a similar exception statement in 4291bis. and then next year we will go through another draft and have another exception. just get rid of classful addressing. we went through this in the '90s. randy From nobody Thu Jan 12 17:27: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 DAEC5129642 for ; Thu, 12 Jan 2017 17:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 EHS1nDxUkKDt for ; Thu, 12 Jan 2017 17:27:27 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 4BF5E129542 for ; Thu, 12 Jan 2017 17:27:27 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 96so27183257uaq.3 for ; Thu, 12 Jan 2017 17:27:27 -0800 (PST) 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=cM3KXsS4tcdULYzLP6dWuNtYMmfs6gt3dlCeYOPhmkM=; b=TfnUqvg/ODRg0F0mZUpubek4ahAvgU4q8zbHCCUPquaVpDbHZCTLIYn9AOrFh0wFsW k94VYuYleW5UhAWw1w9aNMBatPbGldatkBZO/1uMXT+T8HhIhFzfhbPCsK/Zh81hZNP7 eB2z27INguPRRVyYZ4akAy/xXjhrqk2Zl6cdYq6hMOJsqozm3U8X24tPCfrq9X1uAnVn XPCWHhBC0fK8yalvzTN6RhhuS5NmKz/kdtY3ydXFpHvPdonMjU5rl0ddoXISjcULFxSJ J18SCLORQ/lvzCpM3bpevV2dLngQ5WRLz9CKAJFqtqMHm63vj9uS49XK3VcBTZWbISVr iP7A== 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=cM3KXsS4tcdULYzLP6dWuNtYMmfs6gt3dlCeYOPhmkM=; b=FEWD/aGUpn/EePAjEJ3BOiMdAG6J+pDypzNM32/0NX3tPOLaESkDY2b+qgKwq5de6o zZwpEhlNNDUwW2LxiNIFjTLhYOiLfRLrf/wwZiFj2aJNrAVpcgyz9VYTcqYA8/q5AV3x WQKGboaiingzxUbs+LGYTUO8qvLl5t1WwFriN9/MFvrn0U4S+IeVSZZj8kGBwBzFgsu8 kuWep6fvzF2UQuxdHpXkNJ0y7FwGFryqEeynmK8lCf9OkYy+4HLPhwbMsXzaMGqEdhfP lReUTfGnrsnUjjyhr1XmAUF+VAS2KQehzPikb5fc8QtIOXzNqE98MGVb/L1dQeCIcTsj /ddg== X-Gm-Message-State: AIkVDXJtUqnnpiEvJETWvmJNr7WKgbF7sJ/I0YyTLJegHXxmHxN+lg0Dg5xldvxgo1X3n6VlNRUVm1JbdcAiQMZp X-Received: by 10.159.49.27 with SMTP id m27mr9203526uab.72.1484270846277; Thu, 12 Jan 2017 17:27:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 17:27:05 -0800 (PST) In-Reply-To: <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 10:27:05 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Bob Hinden Content-Type: multipart/alternative; boundary=f403045ddf748b50150545efbcdb Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 01:27:29 -0000 --f403045ddf748b50150545efbcdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 8:57 AM, Bob Hinden wrote: > It is not recommended that Interface Identifiers for an Ethernet > interface be based on stable IEEE MAC-layer addresses. Earlier > versions of > this document described a method of forming interface identifiers > derived from stable IEEE MAC-layer addresses called Modified EUI-64 > format. > This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is > no longer recommended. > > That is, add =E2=80=9Cstable=E2=80=9D. > That works for me. > Would it then make sense to be explicit to add a new sentence like: > > This approach may be used to create Interface Identifiers based on > non-stable (e.g., > random) IEEE Mac-layer addresses. > > with a reference to the appropriate IEEE specification. > Yes, that's great. --f403045ddf748b50150545efbcdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 8:57 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
=C2=A0 =C2= =A0It is not recommended that Interface Identifiers for an Ethernet
=C2=A0 =C2=A0interface be based on stable IEEE MAC-layer addresses.= =C2=A0 Earlier versions of
=C2=A0 =C2=A0this document described a method of forming i= nterface identifiers
=C2=A0 =C2=A0derived from stable IEEE MAC-layer addresses called Mod= ified EUI-64 format.
=C2=A0 =C2=A0This is described in Appendix A of [I-D.ietf-= 6man-rfc4291bis] and is
=C2=A0 =C2=A0no longer recommended.

That is, add =E2=80=9Cstable=E2=80=9D.

That works for me.
=C2=A0
Would it then make sense to be explicit to add a new sentence like:

=C2=A0 =C2=A0This approach may be used to create Interface Identifiers base= d on non-stable (e.g.,
=C2=A0 =C2=A0random) IEEE Mac-layer addresses.

with a reference to the appropriate IEEE specification.

Yes, that's great.
--f403045ddf748b50150545efbcdb-- From nobody Thu Jan 12 17:33: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 4F14E129642 for ; Thu, 12 Jan 2017 17:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Tnf4N3V1of1d for ; Thu, 12 Jan 2017 17:33:23 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC0F129542 for ; Thu, 12 Jan 2017 17:33:23 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id x75so24617922vke.2 for ; Thu, 12 Jan 2017 17:33:23 -0800 (PST) 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=/hrw/eGqPLdY5DE2j7HSHjtMaXh8lIPZf6NFoNuCvV8=; b=YvH7WJPJMgoFJeeBPGd9sarQ3pTt+95TIlqeSBRDel8H6UMstYK1X7jU5Za/hpc9a+ 99IOwD/7Vbr7mcfMNFUh8GRvReHzuo+09fmT4C7Vq1InslV7I72ALcLW6KcZb8ommoVP FW0XdjFZVQAU/JZMccAj0O+tRRkX6tnhbxB1+B3w65dPn9UBHLW4gZ8Gaq+4M5wJzpkM m0l+d6Lq5lk/pC+mWq63CwLOz+6oDuIlMWceU9IDPL1KiJRdC/bOr6Mn4sJCYkWYSVob sTvQ0mtjQj5CWT04bP5Zwas2kZtvOeg9mT2h+eQJ2dmp79vkMwitBEyaKLeoAlrPVWOj 0F8Q== 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=/hrw/eGqPLdY5DE2j7HSHjtMaXh8lIPZf6NFoNuCvV8=; b=T2o3qfx9z8Co78esYHHshn+2Er4APGUkMqz8+fVy9cRilnxHic5VBU/BoF7Sd4/w/N Gv6VPke4YBvEnnbeqX8TB5G9bHsXvGgUBmT/jJInvwUtbVStPo3AV7GVI9JneW/hmA84 kFenBMPmVVo2Oh+s1yVC2LjJ0fCClVSAH3ak7izoXyeVP+2AFpOwotTqG27jE9YSk9V3 ud8rCeXRUiOMA7C16VEFGIh82xQRTFSdgXjVJg8duW9TIpEmG5gE4O5xAM1f7xzmJ8SS Qv2IS8lY8UKNppIUrsPzEt7KUXgCnCWQt1x2ksUPnQbIjyrc8PjLJp/aN0EknxETWFHg nb7Q== X-Gm-Message-State: AIkVDXKBG8eLwPd0wR1QISBpOtyf3TKGyzH3+t8F181fxOsTM2lhv41IwuuPkeXve+7YTIjWr431i7048kOqhuax X-Received: by 10.31.137.68 with SMTP id l65mr8296634vkd.155.1484271202360; Thu, 12 Jan 2017 17:33:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 17:33:01 -0800 (PST) In-Reply-To: <6ae2b66b-21be-a413-ee59-8aa064e583b7@gmail.com> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> <6ae2b66b-21be-a413-ee59-8aa064e583b7@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 10:33:01 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11441656c4b9d70545efd16b Archived-At: Cc: Fernando Gont , IPv6 List , Suresh Krishnan , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 01:33:25 -0000 --001a11441656c4b9d70545efd16b Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 6:11 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > It will break on sites that choose a managed addressing policy (as > Tim told us they do at CERN). I wonder what Android users at CERN do? > Presumably they get IPv4 only and don't notice. The few that do, depending on their opinions, either ask their network admins to follow the best practices in RFC 7934 or go to http://b.android.com/32621 to complain about it. :-) --001a11441656c4b9d70545efd16b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 6:11 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
It will break on sites that choose a managed addressing policy = (as
Tim told us they do at CERN). I wonder what Android users at CERN do?

Presumably they get IPv4 only and don't = notice. The few that do, depending on their opinions, either ask their netw= ork admins to follow the best practices in RFC 7934 or go to http://b.android.com/32621 t= o=C2=A0complain about it. :-)
--001a11441656c4b9d70545efd16b-- From nobody Thu Jan 12 17:56:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551911289C4; Thu, 12 Jan 2017 17:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VEYxB43s1Dp; Thu, 12 Jan 2017 17:56:02 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403531296F9; Thu, 12 Jan 2017 17:55:56 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id y143so5855682pfb.1; Thu, 12 Jan 2017 17:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cXyVC6nbN/MBxf+WYJeO+dmtJOWSylI5XFI9pmVbiKg=; b=iiuWaEKr5yYNRrvQz9Erd3RLpi/fKFazsJMu4bw3do3uG9rC9FE4PxaUYpga38bk8N FpdHzgcY9DKly+Y/2AUFxQZU3XRk3qQMgaymXjVwGqZNAqRP+Q4F1mUtx271z7A7wPMD fDEzAVBzPhTe/peXDf4xJSt4P1hqhuLWOdvhElt0d4C0Zxy7Qed2izR+gFLvn73r7UJ+ m/9AuGUBfYXnrrNh5qZOAbEZEOAYk8lJOcnhhPNcTltsnsiEefgXmF/su+sombQTsxW9 d+S6TKro7jsXavwCsaogjxujGVcKahrOYY/wxTJBwGYIqPOoKzR0esQXtROeXfmqTgFt cBsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cXyVC6nbN/MBxf+WYJeO+dmtJOWSylI5XFI9pmVbiKg=; b=EyS8yzZyIwkZDCWC7jp+mEbfpSffqMeIxlkN0J3/JPSr/MyIgCMdl4gjaUgVwLD4io Tm6HuRLNMbUbbuGGQdbTeE3hj/QI3PmfHuP5yHA3NqzTER4lxUXC8jcL6dvy4W1qB+6D p5HXiX/+0fQwMxs4wMWnEMbK0//hM+IrnHHqkbCPbFA54tB/GmjzHayI2Tn6FEEiME8s CyMCctfLw4UagDAiywReOXzL9eNHxWUEILRodzSQZ4XwWpxW4mGWqwQI4f2kmga9++j+ K01t3XdsOzGtREWuGslicqZ8rk5Lkzlg3aSsyoEuPmQdGbIYOq+9prZNpBQe5+Pmi+84 W0sw== X-Gm-Message-State: AIkVDXJu5911SCRNNihcqjYs4zzN2h2mke9k0hzQ6Yyo3HlqFH1UGGuH8XtKxgAlPoh3ng== X-Received: by 10.99.36.65 with SMTP id k62mr21031471pgk.13.1484272555852; Thu, 12 Jan 2017 17:55:55 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id m67sm24451406pfc.64.2017.01.12.17.55.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 17:55:54 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> Date: Fri, 13 Jan 2017 14:55:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 01:56:04 -0000 On 13/01/2017 13:50, Randy Bush wrote: >> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >> To be precise it says: >> >> The de facto length of almost all IPv6 interface identifiers is >> therefore 64 bits. The only documented exception is in [RFC6164], >> which standardizes 127-bit prefixes for point-to-point links between >> routers, among other things, to avoid a loop condition known as the >> ping-pong problem. >> >> I would suggest adding a similar exception statement in 4291bis. > > and then next year we will go through another draft and have another > exception. just get rid of classful addressing. we went through this > in the '90s. The problem is (and why we wrote 7421) is that stuff breaks with subnet prefixes longer than 64, *except* for the point-to-point case covered by 6164. Yes, I see the problem in enshrining this but I think we face signifcant issues if we do otherwise. What we could conceivably say is that /64 is mandatory except for links where SLAAC will never be used. (SLAAC itself is designed to work with any reasonable length of IID, but again in practice it only works with /64, because we need mix-and-match capability. So although IID length is a parameter in the SLAAC design, it's a parameter whose value needs to be fixed globally.) Brian From nobody Thu Jan 12 18:07: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 A203E1297C4 for ; Thu, 12 Jan 2017 18:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hazpL4QiAjuG for ; Thu, 12 Jan 2017 18:07:53 -0800 (PST) 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 14F6812978C for ; Thu, 12 Jan 2017 18:07:53 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 127so22154791pfg.1 for ; Thu, 12 Jan 2017 18:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dSHMutc3On8P6w6ECd1MnSEMYJUuZZujYd1ExsZWJbs=; b=blL4N3PXShdFqQPrlK9baQaYBoJLf6aCbVgSKVFDOhoWq6JYgdQfuJZ538dF603gjJ yxOR2W+aAVXBqKekq3vbjDEWfzbqLoXmxuyTyzW1NJPf9qkvVss+dS86EOkAmgcgjXUe hZ7BWHxJ8GsL83r43HIAX+XZHbqMKiE99O5Gp1p76/B69PT59e/56nSFMcK90uqnXCV8 YziX27jyqQrJVCIbLvpmWppwaKfPnxWcT9c2yJdlNLbf4nKTluFbZ+3lzEoRQrgT+fUG k3eu+i9iTNDf7nsLxP7talnCbhFWNXCXcH6+uulpVyTJCRQW7VFggBB8PT4juH7P1nrt zFXA== 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=dSHMutc3On8P6w6ECd1MnSEMYJUuZZujYd1ExsZWJbs=; b=Sx/LOQJ0CgIWwWAANYi1rseWrl1McW6dBKaA57PSGDATZ22Abn51J4bZaI1hRcXf+g EsIOWHB3bu26eJo/dMMeAwh+wVV0raZZC8oqdGE4pyVx0ll6eotINnU4m90WAbNaQ2LZ zokchXCAVlxhcOixp1nE3gtp6k4D//ercvSxd+WljrI5MzZF14U/61gxAPaZU103CxLE CKh6hcQGr+N9lfCNkAcb3Jx4IyH5t6Aj5JhwqiELDu6rDeOyXj0ZD3pz0kSuyYd0s0Tc QRLQ6SCT/vURyg0WuMJl+s86nQoFDCj/vy7nUqqNaKihTUGGEGJFB0EHd445v9UQAbvD u8iQ== X-Gm-Message-State: AIkVDXKc/v0LzfrPMcoC3nDkUOBXL2FE1Bi0Ej3r0S+MZXCBrn0lzmeVXuj3wCM/JzcOTQ== X-Received: by 10.99.3.5 with SMTP id 5mr21249207pgd.150.1484273272654; Thu, 12 Jan 2017 18:07:52 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:400a:b890:2046:4b74? ([2601:647:4d01:db10:400a:b890:2046:4b74]) by smtp.gmail.com with ESMTPSA id c15sm24485882pfd.36.2017.01.12.18.07.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 18:07:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: update to rfc2464bis From: Bob Hinden In-Reply-To: Date: Thu, 12 Jan 2017 18:07:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 02:07:54 -0000 Lorenzo, > On Jan 12, 2017, at 5:27 PM, Lorenzo Colitti = wrote: >=20 >> On Fri, Jan 13, 2017 at 8:57 AM, Bob Hinden = wrote: >> It is not recommended that Interface Identifiers for an Ethernet >> interface be based on stable IEEE MAC-layer addresses. Earlier = versions of >> this document described a method of forming interface identifiers >> derived from stable IEEE MAC-layer addresses called Modified = EUI-64 format. >> This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and = is >> no longer recommended. >>=20 >> That is, add =E2=80=9Cstable=E2=80=9D. >>=20 > That works for me. Good > =20 >> Would it then make sense to be explicit to add a new sentence like: >>=20 >> This approach may be used to create Interface Identifiers based on = non-stable (e.g., >> random) IEEE Mac-layer addresses. >>=20 >> with a reference to the appropriate IEEE specification. >>=20 > Yes, that's great. Good. Do you have a reference to a document that defines random IEEE mac = addresses? Bob From nobody Thu Jan 12 18:31:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3A12986E for ; Thu, 12 Jan 2017 18:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PoBz2mTawpT for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41CA012986B for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id y9so28167562uae.2 for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) 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=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=klU95R2LEDpWw/f3XnlXtr5gYmdS53CS8bzm2NjXi36qU+1yAr7oIusV5MqCu3knV2 QNNxQNeU/1mQO4zt/pOfJx1hj3WJrNs6cAkv/f4IT4iQhG9utDR6VpcN2xpo5jgKNV+f LNTfvRr9bFoSehBgCqzHPqydVpPAzb6AUFvReZVkzRd4rKo15y6xwlDPNzpKR7vt4tiC 5Ux4mm+lNn/QrK0+19qHoIAMPYWdLmVBpCTelnsUnT5+/HrtLPVbxKSOxI4BjRkO/ER7 nbb/Nty1OMUqICmP4EZQaE04/UmdvhSAyyDKu3NnPfRdcz9r1iPciVH+KJ5Zf4uGSmgq ID2A== 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=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=GTaS4xD9+Dvei98E3gByXa2I1quQ05OuUkVx5aFQIcy3NDaa5udevox+J0DW1nN8rj Muqzu6Y65DOLGQ+1cYDCj84MW5XCJXWk19cMkemTOMASaYJ6jBGnUWzUfxQ8qwkhEOZy niQfMSBdZRrBOXeli7MxiKPogrWL2s6uFf5DrOHskfg3L1gjaGLOTxT6Fg+6mJxMDVQa R3X6e+g+pg+CBa9GLLKD4KzGex4YolWQdtmDzq9QDrPLknTRnaPUwrqNSAseetJ8WKzw IlQ7eDlgGsraY2AiNkeSHRsF9R4r4y9s+h77JXzHF3XcmRyiFzfbX9DAE8/xMkIoS4fn pdOw== X-Gm-Message-State: AIkVDXJINWAzHFlZTmXbgtttuVGMC4Vi9zO5NtNL/DLBMoJUclHBIvUCzgnP+qfwE+l5llwd31DoAO7ioJv5xWGB X-Received: by 10.159.48.203 with SMTP id k11mr9273853uab.42.1484274691203; Thu, 12 Jan 2017 18:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 18:31:10 -0800 (PST) In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 11:31:10 +0900 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f403045e34f4b8273e0545f0a1f6 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 02:31:35 -0000 --f403045e34f4b8273e0545f0a1f6 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The problem is (and why we wrote 7421) is that stuff breaks with subnet > prefixes longer than 64, *except* for the point-to-point case covered > by 6164. Yes, I see the problem in enshrining this but I think we face > signifcant issues if we do otherwise. > Also, RFC7934 says that networks that provide service to general-purpose hosts should be assigned /64 prefixes to avoid address scarcity. Networks that provide service to general purpose hosts make up a lot of the Internet. What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. (SLAAC itself is designed > to work with any reasonable length of IID, but again in practice it > only works with /64, because we need mix-and-match capability. So > although IID length is a parameter in the SLAAC design, it's a > parameter whose value needs to be fixed globally.) > I don't think that's a good idea. I strongly believe that unlike most areas of the IPv6 protocol where it is a good idea to automatically apply the lessons we learned in IPv4, in the specific field of IP subnet sizing, we should *not* automatically translate IPv4 practices to IPv6. This is because the difference between 32 bits and 128 bits is large enough that the semantics are fundamentally different. We may be lured by the fact that 128 is just 4 times larger than 32, but the difference is huge - remember that even just the first 64 bits are 4 billion times larger than the whole of the current Internet. So while Randy may well be right that we will move away from classful eventually (we certainly never had it in the top 64 bite of the address), I don't think it's necessarily a good idea to do that now. Let's have that conversation when IPv6 deployment has reached 90% and we have experience running the whole Internet with IPv6. For now, I'd much prefer to just add a similar exception to the one we have in 7421. --f403045e34f4b8273e0545f0a1f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
The problem is (and why we wrote 7421) is that stuff breaks wi= th subnet
prefixes longer than 64, *except* for the point-to-point case covered
by 6164. Yes, I see the problem in enshrining this but I think we face
signifcant issues if we do otherwise.

A= lso, RFC7934 says that networks that provide service to general-purpose hos= ts should be assigned /64 prefixes to avoid address scarcity. Networks that= provide service to general purpose hosts make up a lot of the Internet.

What we= could conceivably say is that /64 is mandatory except for
links where SLAAC will never be used. (SLAAC itself is designed
to work with any reasonable length of IID, but again in practice it
only works with /64, because we need mix-and-match capability. So
although IID length is a parameter in the SLAAC design, it's a
parameter whose value needs to be fixed globally.)
I don't think that's a good idea.

<= div>I strongly believe that unlike most areas of the IPv6 protocol where it= is a good idea to automatically apply the lessons we learned in IPv4, in t= he specific field of IP subnet sizing, we should *not* automatically transl= ate IPv4 practices to IPv6. This is because=C2=A0the difference between 32 = bits and 128 bits is large enough that the semantics are fundamentally diff= erent. We may be lured by the fact that 128 is just 4 times larger than 32,= but the difference is huge - remember that even just the first 64 bits are= 4 billion times larger than the whole of the current Internet.
<= br>
So while Randy may well be right that we will move away from = classful eventually (we certainly never had it in the top 64 bite of the ad= dress), I don't think it's necessarily a good idea to do that now. = Let's have that conversation when IPv6 deployment has reached 90% and w= e have experience running the whole Internet with IPv6.

For now, I'd much prefer to just add a similar exception to the o= ne we have in 7421.
--f403045e34f4b8273e0545f0a1f6-- From nobody Thu Jan 12 19:22: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 45CC3129487; Thu, 12 Jan 2017 19:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9iuAphrVRim; Thu, 12 Jan 2017 19:22:09 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267A7129401; Thu, 12 Jan 2017 19:22:09 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 92E5587F5E; Fri, 13 Jan 2017 03:22:08 +0000 (UTC) Date: Fri, 13 Jan 2017 03:22:08 +0000 From: heasley To: Randy Bush Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 Message-ID: <20170113032208.GA18762@shrubbery.net> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:22:10 -0000 Fri, Jan 13, 2017 at 09:49:07AM +0900, Randy Bush: > > Do you have a suggestion how to change this within the context of > > advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. yes, please. From nobody Thu Jan 12 19:47: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 C769C1299A4 for ; Thu, 12 Jan 2017 19:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 Qdrsym2iw_bt for ; Thu, 12 Jan 2017 19:47:29 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 39B601299A0 for ; Thu, 12 Jan 2017 19:47:29 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id c125so11716442ybf.1 for ; Thu, 12 Jan 2017 19:47:29 -0800 (PST) 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=hNF34HcE9m0aCoND6QKCnEkHqbrZ+rypQ7jbqBKgwDs=; b=DHpL2Kc8YQ/YlM9LEvAf5NP3dPAhHT6/tm4AxSpsgNNiwh+2fQUnWAl4AJFNoasAPf wcJOia4P4FjGgQO4N2nNYu+G1AT4J0LaB9F4/DR87Iur/eM9y32/F/GEEB6HHPuoeh3q 8hF6TqQgeo+IeuhGuzIDotv3e7v8C6bVFzW8o4zEwBT/7NgbqQ6xu7ZXo0uD5khcXqKD 0IDwaOOffg+UJtHdBAGU0xfMKCA6ofGmZqkaucanRo7Z2UdoUCssmUzB/C6b3wzt2QPw xZz49qQaj2sPumZrDBC2mvsg/G68PRSqsdADtteeDKY70QPwmfYMz6xXkZttCbD+JFYa +Rog== 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=hNF34HcE9m0aCoND6QKCnEkHqbrZ+rypQ7jbqBKgwDs=; b=IQHQDvcGcL8xQhu72UksRsl93ET7Xqvn9FDKRxjZ4uMbNHHTLcH+h5kgtQQvUV+Rp5 M/KFKd9DQcjk7WxQrogpcmU/k2h/F3jx2K9Df1fonZNNNxzKvDkt5uAC6Zv8pAzeLZTA H7m2nnuPilg8Whuvah0BT3ZK5TR8rVFQX3Yj9w3vhmdrXOx5qmI5LpAQTHNd4RJV3NyF 7k7yr5aHU9JwrEzaDZ1HsIOljN4RVwOSb20G/1vEWrSbn/UOh9HAGQr3hDmBCdLlg/gP dT5YU3RK6t073LSbDwdwTpJlBAlh/vdwf3fPJorugWxJuPOoIRWg02ZPBmJ4WZeF6bln hIVw== X-Gm-Message-State: AIkVDXLF1FiNbbw06YDytdfMpLp0lt8YkgoYuIsRYMP+IVcxT6JqC2gZQ8rJTo38z1NKB1RiNQbuZq8Zhq0H7fFS X-Received: by 10.37.60.195 with SMTP id j186mr10937903yba.73.1484279248270; Thu, 12 Jan 2017 19:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.109.3 with HTTP; Thu, 12 Jan 2017 19:47:07 -0800 (PST) In-Reply-To: References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 12:47:07 +0900 Message-ID: Subject: Re: update to rfc2464bis To: Bob Hinden Content-Type: multipart/alternative; boundary=001a114bc35c57aa4b0545f1b1a2 Archived-At: Cc: Christian Huitema , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:47:31 -0000 --001a114bc35c57aa4b0545f1b1a2 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 11:07 AM, Bob Hinden wrote: > >> Would it then make sense to be explicit to add a new sentence like: > >> > >> This approach may be used to create Interface Identifiers based on > non-stable (e.g., > >> random) IEEE Mac-layer addresses. > >> > >> with a reference to the appropriate IEEE specification. > >> > > Yes, that's great. > > Good. > > Do you have a reference to a document that defines random IEEE mac > addresses? > Not an IEEE reference, but we could certainly cite RFC 7844 section 2.1, which goes into the subject in detail. Christian might have a better reference. Christian? --001a114bc35c57aa4b0545f1b1a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 11:07 AM, Bob Hinden <bob.hinden@gmail.com><= /span> wrote:
>> Would it then make sense to be explicit to add a ne= w sentence like:
>>
>>=C2=A0 =C2=A0 This approach may be used to create Interface Identif= iers based on non-stable (e.g.,
>>=C2=A0 =C2=A0 random) IEEE Mac-layer addresses.
>>
>> with a reference to the appropriate IEEE specification.
>>
> Yes, that's great.

Good.

Do you have a reference to a document that defines random IEEE mac addresse= s?

Not an IEEE reference, but we could = certainly cite RFC 7844 section 2.1, which goes into the subject in detail.= Christian might have a better reference. Christian?
--001a114bc35c57aa4b0545f1b1a2-- From nobody Thu Jan 12 19:56: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 52252129972; Thu, 12 Jan 2017 19:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcYnnabN_OpW; Thu, 12 Jan 2017 19:56:01 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30B126BF7; Thu, 12 Jan 2017 19:56:00 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id 137so26175044vkl.0; Thu, 12 Jan 2017 19:56:00 -0800 (PST) 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=s822UKvoYi0+VtfpHcRcO1dh8gEFGkJnSjLjBOPFeAA=; b=NODKN09lzlcGv7ByOewW8rz8QeiZYqBmyem/T/3V+heo0xBAA28EoWm82cta2jhj6o UAUi7OxXsffUvrdt/OTDQ6w+kYfAxMxOHmlMi31hmnMmhw68hac0yMy1iKLeomM9W0vn wda4TmmLFrJTPGVDUGgVR8ajpV3Iwi30XA2tEMkJHKyUb2QpMr7bryKgA/cDaVbYgD3u yfnVi41nKbplsQZ2xwAVeyL4tWwcz5oKAIILIl+QWRV2dGPhEpC0kIJgiIT3E+5njrF2 vW/XywUE0wQMy1xmnYAHlmdUkdyrxpQR/h+hOWAp2gffkFkbBGoQJ8s7feat+O+JJmJR 3IAA== 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=s822UKvoYi0+VtfpHcRcO1dh8gEFGkJnSjLjBOPFeAA=; b=jXPd27OXgMVaxIesjFoKbXNY2fkz2/k435AYRFyiWLugpq9+KaRMstytbFEVZO1+Cm yACwgLZJb/6oPf+5QPVqC+sWIIAM0WjEztBfLM+oYjdhZektpIQJG8d+7cgTD8VlK6Nm +l8jqN824dXYCCu4axZxJ8uUAO/MDQU8/Idiiyb/Kvf+RqPak+2v7c0JTA/4UnYqvGJS 1l93M+JDcpgxI+mHDf5qcTPGVUYgIjzKUpOx3rsUEI0AxSLK6ycANoDbstKjOEjwlvoR uG3KbtJeon7BoyN0gtt2oseBGssXAMJEFjKQ+ZtC1H+KYWN5JN0WMkJlLdQedC+WqviK ifCg== X-Gm-Message-State: AIkVDXL4UK55Ih94rccW8pR1wVxe1w5vL184YZxEIjlJuqN7H2yg9qc51BykudHpeIf2+xAs6QvHOEP18P3vuQ== X-Received: by 10.31.149.145 with SMTP id x139mr7571659vkd.130.1484279759915; Thu, 12 Jan 2017 19:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.14 with HTTP; Thu, 12 Jan 2017 19:55:59 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Thu, 12 Jan 2017 22:55:59 -0500 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:56:03 -0000 Hi Randy, On Thu, Jan 12, 2017 at 7:49 PM, Randy Bush wrote: >>> to be clear, i have no problem with iids being 64-bit. my issue is with >>> unicast globals being classful in 2.4.4. >> Randy I take your point, but this supposed conflict isn't new, it's not >> introduced in 4291bis, it goes back to RFC3513. > > i know; and i have pushed back every cm of the way. it took years to > get the other classful insanity, tls/nla, removed. the old cidr war > continues. this last bit of classfulness (excuse the word) too will > pass. > >> Do you have a suggestion how to change this within the context of >> advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. I do see your point but I do not feel it is equivalent to classful addressing in IPv4. i.e. Looking at the leading X bits does not directly determine the IID length. That said, I would like to understand better your exact concern with the text in 2.4.4. What exactly would you like to change (is it the m-bit verbiage)? Can you come up with a text change proposal so that we can discuss it in the 6man WG? Thanks Suresh P.S.: The document is not in IETF Last Call yet. It has completed WGLC and is in AD evaluation. Brian did his INT Dir review for the INT ADs. The IETF Last Call will start soon. From nobody Thu Jan 12 21:10: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 16759129A18; Thu, 12 Jan 2017 21:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaMalI41yUgq; Thu, 12 Jan 2017 21:10:07 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) (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 F0D0E129A16; Thu, 12 Jan 2017 21:10:06 -0800 (PST) Received: from [127.0.0.1] (109.45.0.162) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 2C8500; Fri, 13 Jan 2017 06:09:47 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20170113050947.6025298.97977.75536@linfre.de> Date: Fri, 13 Jan 2017 06:09:47 +0100 Subject: AW: Review of draft-ietf-6man-rfc4291bis-06 From: Karsten Thomann In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> To: Randy Bush , Brian E Carpenter X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: Cc: IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 05:10:09 -0000 =C2=A0 Originalnachricht =C2=A0 Von: Randy Bush Gesendet: Freitag, 13. Januar 2017 01:51 An: Brian E Carpenter Cc: IPv6 List; int-dir@ietf.org; Bob Hinden; draft-ietf-6man-rfc4291bis.all= @ietf.org; IETF Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06 > RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exc= eption. > To be precise it says: >=20 > The de facto length of almost all IPv6 interface identifiers is > therefore 64 bits. The only documented exception is in [RFC6164], > which standardizes 127-bit prefixes for point-to-point links between > routers, among other things, to avoid a loop condition known as the > ping-pong problem. >=20 > I would suggest adding a similar exception statement in 4291bis. =C2=A0just get rid of classful addressing. we went through this in the '90s. =E2=80=8EI can only support this, while /127 is a good exception for ptp li= nks, it's still useless for small nets with 4-5 IPs like a network between = routers and a Firewall cluster. From nobody Thu Jan 12 21:36: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 DE521129A5C for ; Thu, 12 Jan 2017 21:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 vCZ583YUgKl3 for ; Thu, 12 Jan 2017 21:36:10 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 0E3E21295B1 for ; Thu, 12 Jan 2017 21:36:09 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cRuX1-00079I-UC for ipv6@ietf.org; Fri, 13 Jan 2017 06:36:08 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cRuWw-000085-1Q for ipv6@ietf.org; Fri, 13 Jan 2017 00:36:06 -0500 Received: (qmail 5753 invoked from network); 13 Jan 2017 05:35:58 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.42.59]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Jan 2017 05:35:58 -0000 From: "Christian Huitema" To: "'Lorenzo Colitti'" , "'Bob Hinden'" , "'Juan Carlos Zuniga'" References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> In-Reply-To: Date: Thu, 12 Jan 2017 21:35:56 -0800 Message-ID: <06fd01d26d5e$eae18f90$c0a4aeb0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI3va+3pzp5A16Rqn03yXBJ7A6VnAE9aweJATqNWL0BW9eoMQJnJWI4AZcAIemgLK1ggA== Content-Language: en-us Subject: RE: update to rfc2464bis X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.27) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoCxuGUM5AfbSImzFhiTmn9RcOb18WfxGyg6Om6u4YYm0PcRBUJ63TS4UVa U6YgUUk5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qhQRCdMNhge1Unb77YyuZq6Ca9IjT/McnoYcAq2BUfBeRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/edseI+0iffshWIcU02XSgP6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f3u07h1Ar0asfEVCjJZw/E01 aDvSI66S1J0VQ44N+76FAN4IxNZImptvEG4mfAHigamxVEE6gtF+B/lEIPzms74rHdmmurdkSlp8 bL7MuNSeJ6fVbIdD0RyyBL+RsQXLIsIclqURQOfTUwDe+Ri01fK//LgD8r/EmKnkLuRbKmSGqAhv h99pB+InXxDaW/Yn5/Y4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Cc: 'IPv6 List' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 05:36:12 -0000 On Thursday, January 12, 2017 7:47 PM, Lorenzo Colitti wrote: >> Do you have a reference to a document that defines random IEEE mac = addresses? >=20 > Not an IEEE reference, but we could certainly cite RFC 7844 section = 2.1, which goes > into the subject in detail. Christian might have a better reference. = Christian? RFC 7844 includes a couple of citations on past experience. There is = also the presentation that I gave in Prague: = https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf. = Mathy Vanhoef wrote a description of MAC Address Randomization in = Windows 10 here: = https://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-= on.html.=20 There is work in progress in IEEE 802. Juan Carlos is following it, and = may have a good reference. -- Christian Huitema From nobody Thu Jan 12 22:47:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FE0129AA7; Thu, 12 Jan 2017 22:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1rMJYgr6Tle; Thu, 12 Jan 2017 22:47:02 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AB7129AA4; Thu, 12 Jan 2017 22:47:01 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7478CA2; Fri, 13 Jan 2017 07:46:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1484290019; bh=8hlST7AMrE+6D+X+8gb2PLyUs0p20rv4a6tj0iJ8gaU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZXVqRRgMDxsX/zKdUAMlJhDOz5gvwoYIAgRbhpInAX4sz/ViOF+WuMLvYuVVvXsKO f5f6m6pqAagx4OiBv+dkIZhm/fBQp7M4+bLPBhVrXGvqVc1HA+vgVr7rgoIEjDxm5X 5GPtzlse9cN+s5DMVheuncrSeqrMy9uJC650a/wE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 70BA988; Fri, 13 Jan 2017 07:46:59 +0100 (CET) Date: Fri, 13 Jan 2017 07:46:59 +0100 (CET) From: Mikael Abrahamsson To: "Templin, Fred L" Subject: RE: [Int-area] Route Information Options in Redirect Messages In-Reply-To: Message-ID: References: <32fbea25-01c9-aa32-e70f-3e1282f56294@gmail.com> <5cd024891c204a9bb37dcc23796c36c6@XCH15-06-08.nw.nos.boeing.com> <016f01d26b78$870895a0$9519c0e0$@huitema.net> <6d21dd17f0b94a39a71600944878ec39@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: INT Area , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 06:47:04 -0000 On Wed, 11 Jan 2017, Templin, Fred L wrote: > SEND [RFC3971] provides one possible mitigation in other cases. Is there anything out there that implements SEND? I see Cisco IOS support, quick googling didn't yield anything I found that indicated "widely supported". Frankly, I don't even understand how it would work in a non-tightly-administrated network, with pre-provisioned cyrptographic information. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jan 12 23:03:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64908129AB7; Thu, 12 Jan 2017 23:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 7EAdrCYj8mY4; Thu, 12 Jan 2017 23:03:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34388129AAC; Thu, 12 Jan 2017 23:03:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRvtD-0003Ii-ME; Fri, 13 Jan 2017 07:03:08 +0000 Date: Fri, 13 Jan 2017 16:03:05 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:03:11 -0000 >> and then next year we will go through another draft and have another >> exception. just get rid of classful addressing. we went through >> this in the '90s. > > The problem is (and why we wrote 7421) is that stuff breaks with > subnet prefixes longer than 64, *except* for the point-to-point case > covered by 6164. Yes, I see the problem in enshrining this but I think > we face signifcant issues if we do otherwise. > > What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. i have no problem with this. i use slaac in environments where ip assignment is unimportant and there is only one exit, such as my home networks. fwiw, in racks, i use static addressing for ipv6 because dhcpv6 is broken. randy From nobody Thu Jan 12 23:09:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7159412948F; Thu, 12 Jan 2017 23:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 Ntl5aEPLZtaH; Thu, 12 Jan 2017 23:09:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3B3129479; Thu, 12 Jan 2017 23:09:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRvys-0003L2-Bp; Fri, 13 Jan 2017 07:08:58 +0000 Date: Fri, 13 Jan 2017 16:08:55 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:09:01 -0000 > So while Randy may well be right that we will move away from classful > eventually that is the line i was fed 15+ years ago. i did not accept it then and i see no good reason to accept it now. > we certainly never had it in the top 64 bite of the address bzzt! you may want to look at rfc 2450. > For now, I'd much prefer to just add a similar exception to the one we > have in 7421. you'll need to start an iana registry. for p2p some use /127, some /126, and i have seen /120 on a multipoint mesh, worked fine. we have had to fight massively with vendors to make it classless. please do not give them excuses to break things. randy From nobody Thu Jan 12 23:15:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD47126B6D; Thu, 12 Jan 2017 23:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 z1BCOdxeETyq; Thu, 12 Jan 2017 23:15:06 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B2E12941E; Thu, 12 Jan 2017 23:15:06 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id BA809E6065; Fri, 13 Jan 2017 08:15:04 +0100 (CET) Date: Fri, 13 Jan 2017 08:15:04 +0100 (CET) Message-Id: <20170113.081504.74741530.sthaug@nethelp.no> To: swmike@swm.pp.se Subject: Re: [Int-area] Route Information Options in Redirect Messages From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, int-area@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:15:08 -0000 > > SEND [RFC3971] provides one possible mitigation in other cases. > > Is there anything out there that implements SEND? I see Cisco IOS support, > quick googling didn't yield anything I found that indicated "widely > supported". Frankly, I don't even understand how it would work in a > non-tightly-administrated network, with pre-provisioned cyrptographic > information. - Juniper, at least in JunOS 15.1 and newer for the MX platform. - Huawei, at least in VRP 8.100 and newer for the NE40 platform. Note that I haven't checked in exactly which version it was introduced. (No, we don't use SEND.) Steinar Haug, AS2116 From nobody Thu Jan 12 23:16:59 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFE1294AB; Thu, 12 Jan 2017 23:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 7GHnV5ceNUoQ; Thu, 12 Jan 2017 23:16:56 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48CC126B6D; Thu, 12 Jan 2017 23:16:55 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B49ACE6065; Fri, 13 Jan 2017 08:16:54 +0100 (CET) Date: Fri, 13 Jan 2017 08:16:54 +0100 (CET) Message-Id: <20170113.081654.41643721.sthaug@nethelp.no> To: randy@psg.com Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 From: sthaug@nethelp.no In-Reply-To: References: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, ietf@ietf.org, int-dir@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:16:57 -0000 > > For now, I'd much prefer to just add a similar exception to the one we > > have in 7421. > > you'll need to start an iana registry. for p2p some use /127, some > /126, and i have seen /120 on a multipoint mesh, worked fine. /124 is also used, works fine. > we have had to fight massively with vendors to make it classless. > please do not give them excuses to break things. Agreed. IPv6 is classless. End of story. Steinar Haug, AS2116 From nobody Thu Jan 12 23:31:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23491294B3 for ; Thu, 12 Jan 2017 23:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZOpvelgWJp8 for ; Thu, 12 Jan 2017 23:31:30 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 0E5C712951A for ; Thu, 12 Jan 2017 23:31:29 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 96so31307831uaq.3 for ; Thu, 12 Jan 2017 23:31:28 -0800 (PST) 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=IqCSEjiUsSlu7HVzTqOlaxXEBuwS//Hpb4oi5j6mB9U=; b=oVoAPQGUNtf6GhuIn6S8cUXBOA0pTOF02yyqBWYUucR/GfdNC1tMQz/AfPWVhLZ2Zr W3YXjAFcKInSpnndtKf8yx2lpmhyIbMXRoYc+RJ6h6vuVUjDWmBMmdob/HTTu6bFIbP0 WxkZNQVb/xiWUBVaDm1GoBP8R7pov/r46TEMUoFcMN/4XaSeuqVidNO6N/pRA9WDX9gE kjPZZjQ6d0Ykn9vjHwlLqbt1PPeNKuy7X8vbsg4Wle6BKOGHaFC+M5dAlano6lX2M5GI bbwItz/VgkTdkE45bGD16uSJYrI0C46eRVeeHWULJYGFDZoEDkwkmY85fyjm6QZyRmh8 2oYw== 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=IqCSEjiUsSlu7HVzTqOlaxXEBuwS//Hpb4oi5j6mB9U=; b=Mb+f5wCtcyb415uJxnheWGjNIp0+MQCT6iIWAXq05Jm61e2CDyoFtkb4RYKE389x9r VACc1bfUY4yZ+6nZ6J7rLq6gK478Uul+pB70F2YK0ozGNmgQesqj0UbcLvEI8A0/xeln qRm4rbuJS1G70zc7uKViLdujG5Rf4gdDJ6x5Fd45/q3E5YbgJlXjDBV15rijhkyBG3Xh Yn1rQpDelUk6qVFladCCAVeffESt1Befp3ynCp6hYUpTo4clBTDXQQ6lG3GdN9EqSEdJ 9Wk64G8x6LXN1vuo+6YDHBy1JOpxwTmcl5j8MqQ7VqVf+MKxY3gySxYirBCTuKHvkxXS ouGQ== X-Gm-Message-State: AIkVDXI+a7RmA7LTBycIjzC3VYnAG77McVqFmBHDXTUYQ/3gEVYDPAzl3i3gl10GNF/AnFZQtRTtM8zXR4/HuZoZ X-Received: by 10.159.48.203 with SMTP id k11mr9754814uab.42.1484292688018; Thu, 12 Jan 2017 23:31:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 23:31:07 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 16:31:07 +0900 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush Content-Type: multipart/alternative; boundary=f403045e34f469bbf40545f4d233 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:31:31 -0000 --f403045e34f469bbf40545f4d233 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 4:08 PM, Randy Bush wrote: > > So while Randy may well be right that we will move away from classful > > eventually > > that is the line i was fed 15+ years ago. i did not accept it then and > i see no good reason to accept it now. > You might in another 15 years :) > > we certainly never had it in the top 64 bite of the address > > bzzt! you may want to look at rfc 2450. > Oh wow. Yes, I had forgotten. But that was not just classful addressing, that would have been a much bigger change, with business implications as well. > > For now, I'd much prefer to just add a similar exception to the one we > > have in 7421. > > you'll need to start an iana registry. for p2p some use /127, some > /126, and i have seen /120 on a multipoint mesh, worked fine. > I'm sure they worked fine. I don't know if there will be consensus to change the documents to say that those lengths are in spec. > we have had to fight massively with vendors to make it classless. > please do not give them excuses to break things. > On a lot of hardware /65 - /126 is not very well-supported. --f403045e34f469bbf40545f4d233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 4:08 PM, Randy Bush <randy@psg.com> wrote:
> So while Randy may w= ell be right that we will move away from classful
> eventually

that is the line i was fed 15+ years ago.=C2=A0 i did not accept it = then and
i see no good reason to accept it now.

= You might in another 15 years :)
=C2=A0
> we certainly never had it in the top 64 bi= te of the address

bzzt!=C2=A0 you may want to look at rfc 2450.
<= br>
Oh wow. Yes, I had forgotten. But that was not just classful = addressing, that would have been a much bigger change, with business implic= ations as well.
=C2=A0
> For now, I'd much prefer to just add a similar exceptio= n to the one we
> have in 7421.

you'll need to start an iana registry.=C2=A0 for p2p some use /1= 27, some
/126, and i have seen /120 on a multipoint mesh, worked fine.

I'm sure they worked fine. I don't know if t= here will be consensus to change the documents to say that those lengths ar= e in spec.
=C2=A0
we have had to fight massively with vendors to make it classless.
please do not give them excuses to break things.

<= /div>
On a lot of hardware /65 - /126 is not very well-supported.
=
--f403045e34f469bbf40545f4d233-- From nobody Thu Jan 12 23:34: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 3CA3B1294EC; Thu, 12 Jan 2017 23:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 dQ2emMd4Mdyt; Thu, 12 Jan 2017 23:34:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CE4129AD3; Thu, 12 Jan 2017 23:34:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRwNH-0003Y9-OR; Fri, 13 Jan 2017 07:34:12 +0000 Date: Fri, 13 Jan 2017 16:34:09 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:34:20 -0000 >> we have had to fight massively with vendors to make it classless. >> please do not give them excuses to break things. > > On a lot of hardware /65 - /126 is not very well-supported. guess the business reason why. the classful spec gave them a good excuse to do a tcam rinse repeat. i pay to feed the darned chickens, it's time to break the egg. randy From nobody Thu Jan 12 23:40: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 6116A129AE2 for ; Thu, 12 Jan 2017 23:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 bstq8EKyXCJ5 for ; Thu, 12 Jan 2017 23:40:41 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9965D129495 for ; Thu, 12 Jan 2017 23:40:41 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id r136so28439294vke.1 for ; Thu, 12 Jan 2017 23:40:41 -0800 (PST) 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=vgrydZisq0VfDIvgW3Ddd+gjpQx1+qhTo6aBnPcHvFM=; b=eEDWwbDfOe8DwVxqSEp5mnTWaXppc+yJafv9wQI9cmma+RPchKcupjyFzVbMICLmnz 4HH3u6C0eArrzRXrQ4imC5P4KW/pbxqIS536O0sMHHHTXiH4u/Fu4iZEKhhg1EXhKiRG nca0IG14H9vrQPGzT7w09PGZgWACAhTZ3QLP1vtNDg5SR8wM3lw2DXZNnCr+s6LGKLo0 A1VZu+7CNRPYCIsUK53bjKDk95aGC8CEUAUDgT4fRbd8wxECoMgLlakmMcAL/AY3kP4l H7L1mllua5/eJRZKS/GgSjU2LYEoOrS1bVVz5fzHRNcpX82fI8Qx1z9jeW8V4Axl3aL4 wKkw== 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=vgrydZisq0VfDIvgW3Ddd+gjpQx1+qhTo6aBnPcHvFM=; b=RihugN70qIw+/zjL2n2eZu9snLphnNuyst2aU/R7SImCIdkueXT5BporiCiOTrbwFd B5HKlxO4xfker9/7FqlNJD1g50ZicrwZzrh7sYIsf6lbbrPOPZ3mdJfSy2oi7EjhQPnz 6lR0Y1IzdF9yYptzM9sqGUxV9Vsg9NmAW1EFb6+P3WSf0aLB6JNi0Tw1jb4dqNCGUxAm sn6EvrKEgBYUz6VkS+ElB4Khzaa4xEMVg2sVVXHj08Zixz5j6FdT97zCSh9F7NXd6ql6 duWsTtWFNF+nCpeezgW0Kuht1umfVwPlnuMtLeNLPLQ/gngp+88W7rgyHWQa5Fmr021E zLpg== X-Gm-Message-State: AIkVDXJUUbKnJLRqoDBHALyLT8svP83Y1lJD975IrftX2Ebwd8IMeoBol6Gi0TPLLTkh1CJ+PxcOxgZj8msNgigV X-Received: by 10.31.88.1 with SMTP id m1mr9161178vkb.83.1484293240591; Thu, 12 Jan 2017 23:40:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 23:40:19 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 16:40:19 +0900 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush Content-Type: multipart/alternative; boundary=001a114e5364595c7b0545f4f381 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:40:43 -0000 --001a114e5364595c7b0545f4f381 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 4:34 PM, Randy Bush wrote: > >> we have had to fight massively with vendors to make it classless. > >> please do not give them excuses to break things. > > > > On a lot of hardware /65 - /126 is not very well-supported. > > guess the business reason why. the classful spec gave them a good > excuse to do a tcam rinse repeat. i pay to feed the darned chickens, > it's time to break the egg. > But it's true that supporting /65-/126 increases the cost of the device. The extra bits have to go somewhere. I think I've seen hardware that just converted all prefixes to 128 bit if there was at least one /65 - /126 prefix in the FIB. That costs money for RAM. Obviously that's silly if those prefixes are frequent, and you can save that money using better software engineering - but software engineering costs money too. Prefixes don't cost money, and if we know that we won't run out of them, what's the problem? --001a114e5364595c7b0545f4f381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 4:34 PM, Randy Bush <randy@psg.com> wrote:
>> we have had to f= ight massively with vendors to make it classless.
>> please do not give them excuses to break things.
>
> On a lot of hardware /65 - /126 is not very well-supported.

guess the business reason why.=C2=A0 the classful spec gave them a g= ood
excuse to do a tcam rinse repeat.=C2=A0 i pay to feed the darned=C2=A0 chic= kens,
it's time to break the egg.

But it&= #39;s true that supporting /65-/126 increases the cost of the device. The e= xtra bits have to go somewhere. I think I've seen hardware that just co= nverted all prefixes to 128 bit if there was at least one /65 - /126 prefix= in the FIB. That costs money for RAM. Obviously that's silly if those = prefixes are frequent, and you can save that money using better software en= gineering - but software engineering costs money too. Prefixes don't co= st money, and if we know that we won't run out of them, what's the = problem?
--001a114e5364595c7b0545f4f381-- From nobody Fri Jan 13 02:23:31 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 1D8FA12896F; Fri, 13 Jan 2017 02:23:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-segment-routing-header-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148430300711.26951.7773594636293442666.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 02:23:27 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:23:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Segment Routing Header (SRH) Authors : Stefano Previdi Clarence Filsfils Brian Field Ida Leung Jen Linkova Ebben Aries Tomoya Kosugi Eric Vyncke David Lebrun Filename : draft-ietf-6man-segment-routing-header-03.txt Pages : 29 Date : 2017-01-13 Abstract: Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 02:25: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 5407612944F for ; Fri, 13 Jan 2017 02:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ox_PJ0cldwZ for ; Fri, 13 Jan 2017 02:25:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F0E12896F for <6man@ietf.org>; Fri, 13 Jan 2017 02:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1776; q=dns/txt; s=iport; t=1484303130; x=1485512730; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mJAcM2d1rqwJIFqRLJtacaLDm5P6Ii7Zh8ogHHsc908=; b=Ocw/5llz9fbQuVfVxOOAxdraZx+Op1XsBhDMSjz8W4fRdr/GJ/Fztiu6 zh5AaXu++0hnxem+rYzW4y4FF1wqYzGpbI//OhmKDUhudaMQ6GpgfFTXN z05jV1WoBV+ZWC9japtbj4Lz6hWbtZ8uyRRtTvZ5R/rXmryGRuQKtsVIc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQAmqnhY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR9fgQkHjVGRdR+DGJISgg0shXYCghA/FAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEDATo9AgULAgEIGB4QMiUCBA4FiHsIDrJZig4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhkWCAgiCV4IUdYE9gzOCMQEEjyCMEgGGW4p9gXdRhD2JaJJ?= =?us-ascii?q?kAR84gUQVGDIBhh9zAYdYgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,221,1477958400"; d="scan'208";a="192201910" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2017 10:25:29 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0DAPTu9018714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 10:25:29 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 05:25:28 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Fri, 13 Jan 2017 05:25:28 -0500 From: "Stefano Previdi (sprevidi)" To: "<6man@ietf.org>" <6man@ietf.org> Subject: Re: New Version Notification for draft-ietf-6man-segment-routing-header-03.txt Thread-Topic: New Version Notification for draft-ietf-6man-segment-routing-header-03.txt Thread-Index: AQHSbYcWFbPe3FYJn0qdro5U7A6EbqE2h3yA Date: Fri, 13 Jan 2017 10:25:28 +0000 Message-ID: <961A621F-D5A2-4757-A40A-66843825BAE5@cisco.com> References: <148430300720.26951.2989954973688460708.idtracker@ietfa.amsl.com> In-Reply-To: <148430300720.26951.2989954973688460708.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.233.129] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FB16CCBE86E544CAD25186626A61A96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:25:32 -0000 updated version with the suggested diffs by Brian. s. > On Jan 13, 2017, at 11:23 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-6man-segment-routing-header-03.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-segment-routing-header > Revision: 03 > Title: IPv6 Segment Routing Header (SRH) > Document date: 2017-01-13 > Group: 6man > Pages: 29 > URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-segm= ent-routing-header-03.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-= routing-header/ > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-segment-routi= ng-header-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-segme= nt-routing-header-03 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending an SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > describes the Segment Routing Extension Header Type and how it is > used by SR capable nodes. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Jan 13 08:16: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 101C4129731 for ; Fri, 13 Jan 2017 08:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PilsnseynPNU for ; Fri, 13 Jan 2017 08:16:23 -0800 (PST) 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 2C46E1296B4 for ; Fri, 13 Jan 2017 08:16:23 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id y143so33475864pfb.0 for ; Fri, 13 Jan 2017 08:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3lgbc828knrRj3k34OcGaKe33iVGVJ5IgIEuUpr/uDA=; b=phe0tMsI38+fEpLtXuLRarX4P4pOYBazfvv/18Y0F51xBB+7g3sdXmsX/l2LE7J6gR VV9jmfKbYwmV6/J8Fjt+aXAYzeZksXmmgnndPdWTNzXV13o8xF2riJmB0vbgjRZLf/u7 wZTnHur1ReO5eau3zHbBDWXBfaWtQ2LInX6u1SK7DHedPhJXKbz3gZ337R7Mvuz8nkVM tY+0tneCpYcC9uvgMMRXoWgeXSYaKfLIMsaQgPnmNiMR6vA1NsgC5AheNh8tyZ6MIuKs sTIDEGUAPUccrLFrJe4/5Ue0tDjA+94veoF507b/3J5/n/d8UTVJxf+rApTjlVQebklZ Cdig== 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=3lgbc828knrRj3k34OcGaKe33iVGVJ5IgIEuUpr/uDA=; b=bFSq8a7eoO+UhmAQ1kPD1STPMTvOIZOakYXDbqLoSaWKGbTlWY8r/uRiVErtfCy52y 6MV4KiMcgAO1rCyvJ3uniKBAGY6n0PvqQ/ND3qhf24bE4D5eXf+c49q4/IRN8b9PJXve 5+T0lPj8CPC6VoU679sigh/IInFw3lPxN4lUixW2hzf2ECauFgjJ9R1Yk14SMehM9wD+ jvshUp8JMINvwwdO4H8BXRoXZNn2pVB3Kq5Y9/P1RO6qJoaTlO4YyVHBhY/bNzgnhtDF nrAF0t5NF/gWGA1U9/JK7NKEldlc1YbzEPqeky2VSDRYKpgScP1paaK+VF2ujeJ0sFks B8fg== X-Gm-Message-State: AIkVDXJMeNBXzUkI68fsSfPlq3FuOIcCgMBEAiJ0kQCQ3tz+8nr+118mmjI9zqy7fbAkMA== X-Received: by 10.84.210.228 with SMTP id a91mr31360288pli.0.1484324182732; Fri, 13 Jan 2017 08:16:22 -0800 (PST) Received: from [10.0.0.21] (c-71-202-18-198.hsd1.ca.comcast.net. [71.202.18.198]) by smtp.gmail.com with ESMTPSA id n8sm30493670pgc.0.2017.01.13.08.16.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 08:16:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: update to rfc2464bis From: Bob Hinden In-Reply-To: <06fd01d26d5e$eae18f90$c0a4aeb0$@huitema.net> Date: Fri, 13 Jan 2017 08:16:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <30097699-804D-40EA-8EAE-6D4745FE5E5C@gmail.com> <06fd01d26d5e$eae18f90$c0a4aeb0$@huitema.net> To: Christian Heuitema X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Juan Carlos Zuniga , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 16:16:25 -0000 Christian, > On Jan 12, 2017, at 9:35 PM, Christian Huitema = wrote: >=20 > On Thursday, January 12, 2017 7:47 PM, Lorenzo Colitti wrote: >=20 >>> Do you have a reference to a document that defines random IEEE mac = addresses? >>=20 >> Not an IEEE reference, but we could certainly cite RFC 7844 section = 2.1, which goes >> into the subject in detail. Christian might have a better reference. = Christian? >=20 > RFC 7844 includes a couple of citations on past experience. There is = also the presentation that I gave in Prague: = https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf. = Mathy Vanhoef wrote a description of MAC Address Randomization in = Windows 10 here: = https://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-o= n.html.=20 >=20 > There is work in progress in IEEE 802. Juan Carlos is following it, = and may have a good reference. Thanks, I will review the info, and look forward to hearing from Juan = Carlos. Bob >=20 > -- Christian Huitema >=20 >=20 >=20 From nobody Fri Jan 13 11:34: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 226C112940F; Fri, 13 Jan 2017 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfUM_Gnr_TVZ; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933B81293FC; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id 127so9551772pfg.0; Fri, 13 Jan 2017 11:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=boiLHfJmhNLeXv3Mrei5XLfHldfZClxRrzOUfeMGXAUAO8sHxElTGSf/TJjTXAbXbh rO7D6F7820o8qNfpyrbW0UXet4GBkRhEqgh949XmzfbkkNok8BW+6HFrrYy0pPWnR0VO vPO46+xejiZmJ7RzabsTsme56IAhadaZjzui8OdPxuJjBdrlGIIJOYqYe+jlaBMcfdP6 zgrMJNG0cMIf28sy2bfT2yyor5GUPKnsdTrEUOLwTHOXSHKQtpaP50hCR7BPBkfQ7oy9 LnF8vNAL7/7NkShnciMr4RLXlrIzt8NtPiCf/PmL0haAm22EoDR7KA6EPr/wgfBZl9E9 liMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=or9FVZikkdpkg9YmWQ4n86sZVoIVwKApO8dKongi0cLPac6+oOmVsj30SrScXAJlOR VrdL6b3s3VyFb2KKns6Is2yJygy3wlSZ2RO5fKAX2Jau7gMt5EUsZ0gFpGj0+GOxNDmQ P4bY1657n1T0ju4P0KNK3uTP9UTfKectixnOb8BWPXbrjHTqbkN+JWDwulKTKj5TQUoN 3SA9onAyGF+sMzUVbCLJ8e2yzFBOIKTuS3hmvmOpTsAFNVrTIyXywBBfKiUIAbW/T1DF ZZC7hin5OW9kHg+8GcpvEi7WWrz9rz5tG5ot/5Z+41VrIDSU/vWugpJwOMKXQjBawATe MJsw== X-Gm-Message-State: AIkVDXICifsqx3o18i9AHxxSLA007Rv77NfTyi7GeHdPTiMa+NNtjoyW9QHIyTm3EEYhnQ== X-Received: by 10.99.128.65 with SMTP id j62mr12339228pgd.87.1484336041039; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id u14sm31047520pfg.18.2017.01.13.11.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:34:00 -0800 (PST) Subject: Re: AW: Review of draft-ietf-6man-rfc4291bis-06 To: Karsten Thomann References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <20170113050947.6025298.97977.75536@linfre.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 14 Jan 2017 08:34:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170113050947.6025298.97977.75536@linfre.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:34:04 -0000 On 13/01/2017 18:09, Karsten Thomann wrote: >=20 > Originalnachricht =20 > Von: Randy Bush > Gesendet: Freitag, 13. Januar 2017 01:51 > An: Brian E Carpenter > Cc: IPv6 List; int-dir@ietf.org; Bob Hinden; draft-ietf-6man-rfc4291bis= =2Eall@ietf.org; IETF > Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06 >=20 >> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an = exception. >> To be precise it says: >> >> The de facto length of almost all IPv6 interface identifiers is >> therefore 64 bits. The only documented exception is in [RFC6164], >> which standardizes 127-bit prefixes for point-to-point links between >> routers, among other things, to avoid a loop condition known as the >> ping-pong problem. >> >> I would suggest adding a similar exception statement in 4291bis. >=20 > just get rid of classful addressing. we went through this > in the '90s. >=20 > =E2=80=8EI can only support this, while /127 is a good exception for pt= p links, it's still useless for small nets with 4-5 IPs like a network be= tween routers and a Firewall cluster. Please read RFC 7421. For example From an early stage, implementations and deployments of IPv6 assumed the /64 subnet length, even though routing was based on prefixes of any length. ... The main practical consequence of the existing specifications is that deployments in which longer subnet prefixes are used cannot make use of SLAAC-configured addresses and require either manually configured addresses or DHCPv6. Nobody is trying to un-CIDRise IPv6. But the price of not applying the /64 subnet size is that you lose automatic addressing. The 4291bis text doesn't yet explain this clearly enough. Brian From nobody Fri Jan 13 11:45: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 1AABC129DA2; Fri, 13 Jan 2017 11:44:56 -0800 (PST) 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 orO-SYn_Pxtq; Fri, 13 Jan 2017 11:44:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E218129DA0; Fri, 13 Jan 2017 11:44:53 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C981B82997; Fri, 13 Jan 2017 20:44:44 +0100 (CET) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Brian E Carpenter , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> Date: Fri, 13 Jan 2017 16:44:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:44:56 -0000 On 01/12/2017 10:55 PM, Brian E Carpenter wrote: > On 13/01/2017 13:50, Randy Bush wrote: >>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>> To be precise it says: >>> >>> The de facto length of almost all IPv6 interface identifiers is >>> therefore 64 bits. The only documented exception is in [RFC6164], >>> which standardizes 127-bit prefixes for point-to-point links between >>> routers, among other things, to avoid a loop condition known as the >>> ping-pong problem. >>> >>> I would suggest adding a similar exception statement in 4291bis. >> >> and then next year we will go through another draft and have another >> exception. just get rid of classful addressing. we went through this >> in the '90s. > > The problem is (and why we wrote 7421) is that stuff breaks with subnet > prefixes longer than 64, *except* for the point-to-point case covered > by 6164. Yes, I see the problem in enshrining this but I think we face > signifcant issues if we do otherwise. > > What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. (SLAAC itself is designed > to work with any reasonable length of IID, but again in practice it > only works with /64, because we need mix-and-match capability. So > although IID length is a parameter in the SLAAC design, it's a > parameter whose value needs to be fixed globally.) Well, yes and no. With the traditional slaac (embed the mac address) it only works with 64-bit IIDs. With something like RFC7217 (grab as many bits as needed to for an IID), it could work. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 11:46:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DAE129DA2; Fri, 13 Jan 2017 11:46:06 -0800 (PST) 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 NgThEzuczR5F; Fri, 13 Jan 2017 11:46:05 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08380129DB0; Fri, 13 Jan 2017 11:46:05 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6E08E829B9; Fri, 13 Jan 2017 20:45:59 +0100 (CET) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Suresh Krishnan , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Fernando Gont Message-ID: <75eca52d-f908-6933-fd06-f86c2e7cfef2@si6networks.com> Date: Fri, 13 Jan 2017 16:45:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Bob Hinden , IPv6 List , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:46:07 -0000 On 01/13/2017 12:55 AM, Suresh Krishnan wrote: > Hi Randy, > > On Thu, Jan 12, 2017 at 7:49 PM, Randy Bush wrote: >>>> to be clear, i have no problem with iids being 64-bit. my issue is with >>>> unicast globals being classful in 2.4.4. >>> Randy I take your point, but this supposed conflict isn't new, it's not >>> introduced in 4291bis, it goes back to RFC3513. >> >> i know; and i have pushed back every cm of the way. it took years to >> get the other classful insanity, tls/nla, removed. the old cidr war >> continues. this last bit of classfulness (excuse the word) too will >> pass. >> >>> Do you have a suggestion how to change this within the context of >>> advancing this to Internet Standard? >> >> yes. simply remove the mandatory requirement for classful global >> unicast addresses. > > I do see your point but I do not feel it is equivalent to classful > addressing in IPv4. i.e. Looking at the leading X bits does not > directly determine the IID length. Isn't that the case for the address block we're currently employing? - the IID is defined to be 64 bits. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 11:58: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 3C285129DB7; Fri, 13 Jan 2017 11:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTWcGHsYiG0J; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8739D129DB5; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id f144so9627721pfa.2; Fri, 13 Jan 2017 11:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jkofa3rGA+MwK7LkC97hv+ioepk9JPqnZKSj8+z7N3g=; b=RZmXHIM5iGgsFJda34WeE+MNzYbuLZ079FkctnUjZCv+qh8vl9lpiTBwYpdxUh6OYK 3pDyrhZNiFmvy2xAOzat1c4Y5OuCuxFyAVspuuXtjPnTQGAItVOSYJH1QSNCTIqoBOKN tpkjYxq55o/pwVcsGXZVrpY4lVWwrfxv/dYQt0n2RcUIAnNhAUqd353D0R5X9b8f47Gk XxpVZdpbZTHbLNEkFf5aZD58wD9CzF5ApiJZJJ+0acvmbvi9u8YWmm8DPPyDerEaQEPZ t7Cd1BjMeE3YNTGNnM2YqtML7ocdNRzB6ZbPNTDOBdnF3P3lHw8ikOrOxCR22WLx+wv0 9qcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jkofa3rGA+MwK7LkC97hv+ioepk9JPqnZKSj8+z7N3g=; b=pwvUyFTO2gMIyxeEF0+Ln+fgCOBRwWZ1CdL3vsQ4rf0i37HfXlHd5MJ4m3fyjtKpJS RonIOkWr4/iBuvO30CyRHNdf7GFqkuICTtoHe+6fpRorxyVSwpPb8TIp1P/27E8AsLO2 Z5X6jYpaK9nvg+9iN+gPEaY2tUfZsVj2zIVlBuWnlmNYuRCz0lP0uTjpbWmExjWxX8eo 44MUSdI6YUbJ8GubM6qOvL6i+M3KdnZJxI1Ou9waj+nErx2iYzLXG1yMU6GCsqS634xX gOkxLmv/L33gOkyXMYtbM+RuTEmdFvVca8KwYQeuQm0VDWSSRfJV/Tmc0y+Vqe4Pn+V6 L/nw== X-Gm-Message-State: AIkVDXIKywgVgndqf2gV4NXt6JHY0RBvb6kkRBSfrIGe8TRHZgD2vKHLFpEeWUo4st+zGA== X-Received: by 10.99.181.7 with SMTP id y7mr25739624pge.51.1484337490083; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id x2sm31037494pfx.65.2017.01.13.11.58.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:58:09 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Fernando Gont , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> Date: Sat, 14 Jan 2017 08:58:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:58:12 -0000 Regards Brian Carpenter On 14/01/2017 08:44, Fernando Gont wrote: > On 01/12/2017 10:55 PM, Brian E Carpenter wrote: >> On 13/01/2017 13:50, Randy Bush wrote: >>>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>>> To be precise it says: >>>> >>>> The de facto length of almost all IPv6 interface identifiers is >>>> therefore 64 bits. The only documented exception is in [RFC6164], >>>> which standardizes 127-bit prefixes for point-to-point links between >>>> routers, among other things, to avoid a loop condition known as the >>>> ping-pong problem. >>>> >>>> I would suggest adding a similar exception statement in 4291bis. >>> >>> and then next year we will go through another draft and have another >>> exception. just get rid of classful addressing. we went through this >>> in the '90s. >> >> The problem is (and why we wrote 7421) is that stuff breaks with subnet >> prefixes longer than 64, *except* for the point-to-point case covered >> by 6164. Yes, I see the problem in enshrining this but I think we face >> signifcant issues if we do otherwise. >> >> What we could conceivably say is that /64 is mandatory except for >> links where SLAAC will never be used. (SLAAC itself is designed >> to work with any reasonable length of IID, but again in practice it >> only works with /64, because we need mix-and-match capability. So >> although IID length is a parameter in the SLAAC design, it's a >> parameter whose value needs to be fixed globally.) > > Well, yes and no. With the traditional slaac (embed the mac address) it > only works with 64-bit IIDs. With something like RFC7217 (grab as many > bits as needed to for an IID), it could work. Technically that's true, but you can't mix IID sizes on a given link and expect it to work, so any legacy system will force the whole link to use /64. Brian From nobody Fri Jan 13 12:03: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 D46ED12711D; Fri, 13 Jan 2017 12:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWCtUPlaP03O; Fri, 13 Jan 2017 12:03:35 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F593127078; Fri, 13 Jan 2017 12:03:35 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id EE55E87CED; Fri, 13 Jan 2017 20:03:34 +0000 (UTC) Date: Fri, 13 Jan 2017 20:03:34 +0000 From: heasley To: Lorenzo Colitti Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 Message-ID: <20170113200334.GO40198@shrubbery.net> References: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:03:37 -0000 Fri, Jan 13, 2017 at 04:40:19PM +0900, Lorenzo Colitti: > But it's true that supporting /65-/126 increases the cost of the device. > The extra bits have to go somewhere. I think I've seen hardware that just > converted all prefixes to 128 bit if there was at least one /65 - /126 > prefix in the FIB. That costs money for RAM. Obviously that's silly if > those prefixes are frequent, and you can save that money using better > software engineering - but software engineering costs money too. do such limited devices really need complex ribs/fibs? address, router, neighbors. all of which are needed regardless of the prefix length. > Prefixes > don't cost money, but, they do: https://www.arin.net/fees/fee_schedule.html > and if we know that we won't run out of them do we know this? and 640k RAM is plenty. i'm not convinced. > the problem? rfc6164 s5.1, s5.2. s5.2 applies to your ram-limited devices. end users that want to subnet can't w/o additional /64s. From nobody Fri Jan 13 12:55: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 5D149129E41; Fri, 13 Jan 2017 12:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, 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 8W6XW6rtw6yv; Fri, 13 Jan 2017 12:55:20 -0800 (PST) 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 99098129DD5; Fri, 13 Jan 2017 12:55:20 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id r136so41190997vke.1; Fri, 13 Jan 2017 12:55:20 -0800 (PST) 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=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=Z9bgxrbNR1Vx1mqOHbJwO6M7vZD0e22dGf0hQCLaTdMoNbGlCPGsmCt7MFibXbJ0rN D7VMwr9f/kqVgYlb1x3QChikICOf5UEs9QBqWt/jaJMiU1JUQ01JzkyV+/PixiOub2WU 0ouP9SRHY2Nw07IA0l6G+6vTb5RBe4jjvDyOwS8mWh8LVPS7ZXLEAQj68G9VyeRH1eTD sk7E5X/WHgH5g7U36OqTJHRKI42FTJ4BQ1V/cXXrh/FRJDT2WptSxIWg9HTq7KaG0Jfj +1JHgLeKFD5K/2V7Q8ZsLVFuqhKFNol7wmCZVEBUc2YVZwgkY2xz1J0uPTvMa/0/YQ5t 3qtg== 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=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=LuHS+ao7wh9K+F/287lAKvp8sycaICTcH/BMcvIh7FNqqynowJ15R4KAm41MQXeKOC LRwCxsjAWgPdjN8hDA/aFBFtMAGXaKoj6bGkHzIwtUCBHpt+MlIVoWVaiMkp+VraVCfW Tefaf46qLwhOsliYrk6oddINBiT3+JrBQ5T/2zLzxcSE4pZbR9/QOAX0dCInWdWxdHU1 BlKsQ1Lq/Q4L1ULX48PNubHzzi0aeYVTIW9zLI8Jh7miFAvL2Bj6oqxWUaVtn3u4h7PK JKszEnOBZ8K9Byr80MYyGB2oIgx+HY6SV1ZjfzC6toF9126f7pUa//Do+k+36yQR+fAi agAQ== X-Gm-Message-State: AIkVDXI70WSlFwc1JqGZZYdwoneqv4URa2CQ2vpj9c8I/bg8X6UO4f4FE3fnENxdAjuOg4YgKRGZ5Himz1v6Sg== X-Received: by 10.31.203.132 with SMTP id b126mr8754667vkg.75.1484340919640; Fri, 13 Jan 2017 12:55:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 12:54:48 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Mark Smith Date: Sat, 14 Jan 2017 07:54:48 +1100 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:55:22 -0000 On 13 January 2017 at 11:49, Randy Bush wrote: >>> to be clear, i have no problem with iids being 64-bit. my issue is with >>> unicast globals being classful in 2.4.4. >> Randy I take your point, but this supposed conflict isn't new, it's not >> introduced in 4291bis, it goes back to RFC3513. > > i know; and i have pushed back every cm of the way. it took years to > get the other classful insanity, tls/nla, removed. the old cidr war > continues. this last bit of classfulness (excuse the word) too will > pass. > >> Do you have a suggestion how to change this within the context of >> advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. > I think people are combining together in this thread two separate things: - the addressing structure - how addresses are processed by routers when the router is forwarding a packet. In IPv6 they're separate things, in classful IPv4 they weren't (if I recall correctly). I think unicast IPv6 could only be described as classful if the structure of the address dictated how processing of addresses for forwarding occurred. (You could describe the difference between IPv6 unicast and multicast forwarding to be classful as forwarding is different for those two types of addresses.) BCP198/RFC7608, "IPv6 Prefix Length Recommendation for Forwarding" makes it very clear that forwarding is to occur based on the longest match rule of an IPv6 address, with no consideration of what the structure of the address happens to be for the purposes of device configuration or anything else. "Abstract IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length." Regards, Mark. From nobody Fri Jan 13 13:02:55 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA49129E45; Fri, 13 Jan 2017 13:02:47 -0800 (PST) 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 Sqr0IIxox-xd; Fri, 13 Jan 2017 13:02:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F74129496; Fri, 13 Jan 2017 13:02:44 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2B25D829A0; Fri, 13 Jan 2017 22:02:35 +0100 (CET) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Brian E Carpenter , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 13 Jan 2017 17:59:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:02:47 -0000 On 01/13/2017 04:58 PM, Brian E Carpenter wrote: > > On 14/01/2017 08:44, Fernando Gont wrote: >> On 01/12/2017 10:55 PM, Brian E Carpenter wrote: >>> On 13/01/2017 13:50, Randy Bush wrote: >>>>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>>>> To be precise it says: >>>>> >>>>> The de facto length of almost all IPv6 interface identifiers is >>>>> therefore 64 bits. The only documented exception is in [RFC6164], >>>>> which standardizes 127-bit prefixes for point-to-point links between >>>>> routers, among other things, to avoid a loop condition known as the >>>>> ping-pong problem. >>>>> >>>>> I would suggest adding a similar exception statement in 4291bis. >>>> >>>> and then next year we will go through another draft and have another >>>> exception. just get rid of classful addressing. we went through this >>>> in the '90s. >>> >>> The problem is (and why we wrote 7421) is that stuff breaks with subnet >>> prefixes longer than 64, *except* for the point-to-point case covered >>> by 6164. Yes, I see the problem in enshrining this but I think we face >>> signifcant issues if we do otherwise. >>> >>> What we could conceivably say is that /64 is mandatory except for >>> links where SLAAC will never be used. (SLAAC itself is designed >>> to work with any reasonable length of IID, but again in practice it >>> only works with /64, because we need mix-and-match capability. So >>> although IID length is a parameter in the SLAAC design, it's a >>> parameter whose value needs to be fixed globally.) >> >> Well, yes and no. With the traditional slaac (embed the mac address) it >> only works with 64-bit IIDs. With something like RFC7217 (grab as many >> bits as needed to for an IID), it could work. > > Technically that's true, but you can't mix IID sizes on a given link > and expect it to work, so any legacy system will force the whole link > to use /64. Well, you could say that you don't need to mix IID sizes on the same link: the IID size is whatever the local router happens to advertise (i.e., 128-Prefix_Length). And, if you do manual configuration, you're supposed to know the prefix length... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 19:07: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 B94F31296EE; Fri, 13 Jan 2017 19:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Tj2V-G_Cf7-p; Fri, 13 Jan 2017 19:07:03 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36071296AA; Fri, 13 Jan 2017 19:07:03 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cSEgH-000Aga-5S; Fri, 13 Jan 2017 22:07:01 -0500 Date: Fri, 13 Jan 2017 22:06:54 -0500 From: John C Klensin To: Lorenzo Colitti , Randy Bush Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 Message-ID: <2A5073777007277764473D78@PSB> In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Bob Hinden , IPv6 List , IETF , int-dir@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 03:07:06 -0000 --On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti wrote: > But it's true that supporting /65-/126 increases the cost of > the device. The extra bits have to go somewhere. I think I've > seen hardware that just converted all prefixes to 128 bit if > there was at least one /65 - /126 prefix in the FIB. That > costs money for RAM. Obviously that's silly if those prefixes > are frequent, and you can save that money using better > software engineering - but software engineering costs money > too. Prefixes don't cost money, and if we know that we won't > run out of them, what's the problem? Because you can pick the scenario -- lots of "things", an interplanetary network, both, or something else-- but we have been here before. Every time someone has said "there is so much address space that we will never run out no matter how inefficiently we use them", they have eventually been proven wrong. That history is obviously not just with the ARPANET/Internet or even computer networks: "if we know we won't ever run out of them" has a nasty tendency to prove that we didn't know and didn't get it right. john From nobody Fri Jan 13 19:33: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 E472F1293F5; Fri, 13 Jan 2017 19:33:35 -0800 (PST) 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=unavailable 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 atVacAo5chE4; Fri, 13 Jan 2017 19:33:34 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5D6129436; Fri, 13 Jan 2017 19:28:05 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 75so92459pgf.3; Fri, 13 Jan 2017 19:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4wvoy4pf9lVSDxPLScnBOMbbfsRh3H6RxnqB/4xdoMY=; b=myVyOWO9VvyRYbELppXBcXgO5KWxDo1OiJS8RHKW0zgsB84+E46GSa8Of2neh89zhb EoYIDdF83bxFMYs9ejb5I5yDiFm+mgQi/p/quTPi0OwzrIDa0rZiuy+95DLKTdFoMDD0 CpKZ49q+zCI8wzBBSVU/zOERL2xZsJ8QBZPOe3VudQMm6pGRXs/5CgJR+KRx/mc1pqQ6 0IRnI9TLWBjmqzkUOuSg/D99v5fkZ57xqyLufyPQvlcTv33M5P+V30xIMtcGM5posM/a kRB12o5Ai63TEO7V/YItFO8a4FpcAyIwk3YioVwHg+Toyu12PxyQZNB2D1MGt2CcMnlI 3AAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4wvoy4pf9lVSDxPLScnBOMbbfsRh3H6RxnqB/4xdoMY=; b=q2O+ENIR6ur8FHwsx5Mb37c7Bv9j4RWTfHlGz8HTZVRbEwBLMSJiA2jyiMoAdQ5D0O cBlQjMbyFehC8YM5wbTUdyiwu/VQV1eG+QHbYCEssyybmGZGdC2J3riU+vW9uoHHsfLS uKBjbLvEVH1J/rxUFu2MyAKVMiM0+mxgg7JnH85OWq1fDWPXOYididRFoIb3HuY+vIzR N9MfFa6jHNfbwB2U0T1KWF5L3gOVKEy7CYy8dL/5xobXcdbdv6+WWJ7/CTVHCEuW2als tZagw+ogTNeLU3J+tJ4saqAMmTzzvCYxdL466CnVsz71ua14QVZvaeF5XYFDnOP/Uet8 ymqw== X-Gm-Message-State: AIkVDXLzMHeQv9DYSOLGAUobqP+VnVuqUW5c0+agTlSQ2nvbkwQvoWArxVEKnq/0w2/tXw== X-Received: by 10.98.133.202 with SMTP id m71mr26533280pfk.102.1484364484772; Fri, 13 Jan 2017 19:28:04 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id y6sm32286658pge.16.2017.01.13.19.28.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 19:28:04 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: John C Klensin , Lorenzo Colitti , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Date: Sat, 14 Jan 2017 16:28:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2A5073777007277764473D78@PSB> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 03:33:36 -0000 On 14/01/2017 16:06, John C Klensin wrote: > > > --On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti > wrote: > >> But it's true that supporting /65-/126 increases the cost of >> the device. The extra bits have to go somewhere. I think I've >> seen hardware that just converted all prefixes to 128 bit if >> there was at least one /65 - /126 prefix in the FIB. That >> costs money for RAM. Obviously that's silly if those prefixes >> are frequent, and you can save that money using better >> software engineering - but software engineering costs money >> too. Prefixes don't cost money, and if we know that we won't >> run out of them, what's the problem? > > Because you can pick the scenario -- lots of "things", an > interplanetary network, both, or something else-- but we have > been here before. Every time someone has said "there is so > much address space that we will never run out no matter how > inefficiently we use them", they have eventually been proven > wrong. That history is obviously not just with the > ARPANET/Internet or even computer networks: "if we know we won't > ever run out of them" has a nasty tendency to prove that we > didn't know and didn't get it right. Which is exactly why we have so far only delegated 1/8 of the IPv6 address space for global unicast allocation, leaving a *lot* of space for fixing our mistakes. Moving away from /64 as the recommended subnet size might, or might not, prove to be necessary in the long term future. That's why the point about routing being classless is fundamental. I do think we need to be a bit more precise on this point in 4291bis. Brian From nobody Fri Jan 13 20:35: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 DC168129876 for ; Fri, 13 Jan 2017 20:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable 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 UswIM1kw2q9i for ; Fri, 13 Jan 2017 20:35:33 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7FD129875 for ; Fri, 13 Jan 2017 20:35:29 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 37B57CAD for ; Sat, 14 Jan 2017 04:35:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsRrAegvFj1W for ; Fri, 13 Jan 2017 22:35:29 -0600 (CST) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 0797DCD1 for ; Fri, 13 Jan 2017 22:35:28 -0600 (CST) Received: by mail-vk0-f71.google.com with SMTP id 75so39995161vkm.0 for ; Fri, 13 Jan 2017 20:35:28 -0800 (PST) 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=oN59oPvweuCcfvcoVPcu61J9ndm40GdhdczuJwCE1jg=; b=lF079WU0oNsWbBCUwBmI0UTK7Qyc5XXgUssuK4K+dfiATNmcyQ/Ajpqi61sG97CbTE 9a3tRtfHujMbcZXUa2y1DiXKLjx+vvnlLy/pLe6Rt8g6tCumE6FHA9eCbeFDF0ri4Tdj sLP5j05Khy9sR3GAsRvRx3uFvUy9Mtp5nOECtDC7B4SH92yObiRgiwxM61wrXx06eZx6 8+afR6dTN08s0kRIIXCS6xaQoiBo0zH2rx9eukbntuaE62aFPZvpdxnEmlA1/ROYodyz +cQOWTXQqjcIj/vT4t9VUvf9WGPpBpzGfoDcMRSMUDEHDhJ0dAg6nbgQa4OvCO9Qdmda 9VVw== 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=oN59oPvweuCcfvcoVPcu61J9ndm40GdhdczuJwCE1jg=; b=J1FbTjRWQ0WSuPfs+85GFyvnHq1A8wfWwPHcvU0RB4tL+r2OUNECA1z6migoR4J3JT DlWgMzcm4DF6SrTalaEZijQMkt9pSQqDVuT03tzZ24gRlzp3dM6ZX4Y81glD2gWmc/Re LqoAHWurwuYzn4rIwuL930jdPE3Ehmv5BQzWN05uKf/P11WRGUOoMfnQ0UwDt4rK3Riy a+2iYdaXRL6FFu28C5SQ/3oSCwk5r8VQIRIHvJud/U6hpYq5afEl3+JARNv5Ra+/QdcE tboqxaJh1B8cJqy5sJ516GHZn0nFWg/rPhZgSZG5b9PP1jH4bodZZFsLBxVxFpXgKmQh jmDg== X-Gm-Message-State: AIkVDXKfRDrgHYja6237gIpdGgRcc8e/y0OIr5TAY8SL6gJG7u7Fo/TAEZakgQ1T9+52QLrMAzqmayhM1j2AGFwBBsfP9bVQEOeJciNjnaNVBi/foZ/8S/1Ui6ZZLv8owF7Y1jnjt0WPKgs9wTU= X-Received: by 10.159.49.92 with SMTP id n28mr10834457uab.95.1484368528483; Fri, 13 Jan 2017 20:35:28 -0800 (PST) X-Received: by 10.159.49.92 with SMTP id n28mr10834451uab.95.1484368528319; Fri, 13 Jan 2017 20:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Fri, 13 Jan 2017 20:35:27 -0800 (PST) In-Reply-To: <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: David Farmer Date: Fri, 13 Jan 2017 22:35:27 -0600 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f403045dd9d8d8b9450546067aff Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 04:35:35 -0000 --f403045dd9d8d8b9450546067aff Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > .... > > Which is exactly why we have so far only delegated 1/8 of the > IPv6 address space for global unicast allocation, leaving a *lot* > of space for fixing our mistakes. Moving away from /64 as the > recommended subnet size might, or might not, prove to be necessary in > the long term future. That's why the point about routing being > classless is fundamental. I do think we need to be a bit more > precise on this point in 4291bis. > > Brian Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that, but that's not what the following says. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 ]. It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an Imperative as discussed in section 6 of RFC2119. I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support that and believe it to be the consensus of the IETF. Maybe even explicitly noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support by SLACC. But it is not correct to say the /64 is REQUIRED. I also believe RFC7608 supports this conclusion. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045dd9d8d8b9450546067aff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
....

Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.

=C2=A0 =C2=A0 Brian

Exactly, /64 is the REC= OMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that,= but that's not what the following says.

   For all unicast addresses, except those tha=
t start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

It says REQUIRED, that is a MUST from RFC2119, and I believe it = to be an Imperative as discussed in section 6 of RFC2119. =C2=A0
=
I'm fine with /64, /127 and /128 as the RECOMMENDED subn= et sizes, I support that and=C2=A0believe it to be the consensus of the IET= F. Maybe even explicitly noting=C2=A0/65 through /126 are NOT RECOMMENDED s= ubnet sizes, and not support by SLACC.=C2=A0 But it is not correct to say t= he /64 is REQUIRED.

I also believe RFC7608 support= s this conclusion.

Thanks.

-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Ser= vices
Office 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
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045dd9d8d8b9450546067aff-- From nobody Fri Jan 13 22:37: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 9793E1294D6; Fri, 13 Jan 2017 22:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpiCwNfpQVNI; Fri, 13 Jan 2017 22:37:25 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B223129412; Fri, 13 Jan 2017 22:37:25 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x75so46689429vke.2; Fri, 13 Jan 2017 22:37:25 -0800 (PST) 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=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=IvcL4rxvsCyDGtH81/4Mdf9qSqOwri6UYeQ3sPeD9zupwhRQLnI7Vj6h/PFi/2NkYT mYFuId8e8X8B3S4+B1URBh4H+hfZjGhKP/PUFk4jbgFQTCx/8Klmri+Ze54Xc0g6fPrL 0nPrLWAZEBhJqxEGMCd20bWN22vYud7E7YPC1WvsiIViXBggqoacLoWIH4Gh0yM5Ln1U tDWdytAVS/GjOmFLVScLjM3uZSajCr2JUQfWn02zAow5eFFP4HOuDlX/rIRJf4Y6NM3K kTXaIJKBfIiD2E8/b2hFCDfqrMB/Q8qgjXTWOvFp0Ght2xkupBjsjAowGtgwyXP4ceO4 K1RQ== 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=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=b+v0aWKVFSLD6Qts3XpSoroTMMksNwKqpzaltk9mo0qPJiWtLFu/y3uIPesm479URE tglrDnOvvIIkXlAQKeS1y4e8+3F+Lrkw3v0fQ9A0eVf86okGGtJAW0zuSaDjKLKgRpYw 1QerW9JRjjJJADxb445q3KupEO2oh61C+Na1d6wbWp032l2zTgWfWB3oxuGQZXbugWPF 5m+aD59GJFT8QqJPtR8JZgRAlejGQLe0l1m79E/NkYFDNtC4AWu+QblgOpULbEDkPjbU jLyb5tXXYoeAzPTRnoewB5Sf4uJzoSzX0v+BB6q/z3WCUzoWDVilptHu5Uj4mzKvUTqB 9GdA== X-Gm-Message-State: AIkVDXJqZa3/gBIYCMmFCwPy/rbfK8ElU5WPkdqmqvYWvxT0h2ewu/axgGtzhQypVQ5A7vWQhwDE5Gq2Elvinw== X-Received: by 10.31.79.132 with SMTP id d126mr11318853vkb.165.1484375844234; Fri, 13 Jan 2017 22:37:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST) Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Mark Smith Date: Sat, 14 Jan 2017 17:37:23 +1100 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: David Farmer Content-Type: multipart/alternative; boundary=001a114dd4cce8a94b0546082efe Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 06:37:27 -0000 --001a114dd4cce8a94b0546082efe Content-Type: text/plain; charset=UTF-8 On 14 Jan. 2017 15:36, "David Farmer" wrote: On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > .... > > > Which is exactly why we have so far only delegated 1/8 of the > IPv6 address space for global unicast allocation, leaving a *lot* > of space for fixing our mistakes. Moving away from /64 as the > recommended subnet size might, or might not, prove to be necessary in > the long term future. That's why the point about routing being > classless is fundamental. I do think we need to be a bit more > precise on this point in 4291bis. > > Brian > Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that, but that's not what the following says. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 ]. It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an Imperative as discussed in section 6 of RFC2119. I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support that and believe it to be the consensus of the IETF. Maybe even explicitly noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support by SLACC. But it is not correct to say the /64 is REQUIRED. I don't think /127s should really be recommended either. They don't guarantee that the ping pong problem is solved, because it depends on both ends being configured with the /127 prefix length by the operator or operators at each end if the link. There is no protocol requirement that both ends of a link have the same prefix and prefix length, nor is there any protocol checking of that condition. For example, if an ISP configures a /127 on their end of the customer's link, but the customer just configures a default route on their end over the link, it is a legitimate configuration by the protocols, Internet access will work (so the customer might assume the link is configured correctly), and yet the link is vulnerable to a ping pong attach despite it "having" a /127 prefix. So it is a mitigation, however it relies on the operator or operators being disciplined about the configuration, and comes at the cost of other things that may be useful if a 64 bit IID was available e.g. protect against discovery of link addresses via unsolicited inbound probing if the IIDs are random (which may include static configuration of an offline generated random 64 bit IID). Regards, Mark. I also believe RFC7608 supports this conclusion. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a114dd4cce8a94b0546082efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 Jan. 2017 15:36, "David Farmer" <farmer@umn.edu> wrote:
=

On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpe= nter <brian.e.carpenter@gmail.com> wrote:
....


Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.

=C2=A0 =C2=A0 Brian

Exactly, /64 is t= he RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with= that, but that's not what the following says.

   For all unicast addresses, except those that start with the bin=
ary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
=

It says REQUIRED, that is a MUST from RF= C2119, and I believe it to be an Imperative as discussed in section 6 of RF= C2119. =C2=A0

I'm fine with /64, /127 and /128= as the RECOMMENDED subnet sizes, I support that and=C2=A0believe it to be = the consensus of the IETF. Maybe even explicitly noting=C2=A0/65 through /1= 26 are NOT RECOMMENDED subnet sizes, and not support by SLACC.=C2=A0 But it= is not correct to say the /64 is REQUIRED.

I= don't think /127s should really be recommended either.

They don't guarantee that the pin= g pong problem is solved, because it depends on both ends being configured = with the /127 prefix length by the operator or operators at each end if the= link. There is no protocol requirement that both ends of a link have the s= ame prefix and prefix length, nor is there any protocol checking of that co= ndition.

For example, if= an ISP configures a /127 on their end of the customer's link, but the = customer just configures a default route on their end over the link, it is = a legitimate configuration by the protocols, Internet access will work (so = the customer might assume the link is configured correctly), and yet the li= nk is vulnerable to a ping pong attach despite it "having" a /127= prefix.

So it is a miti= gation, however it relies on the operator or operators being disciplined ab= out the configuration, and comes at the cost of other things that may be us= eful if a 64 bit IID was available e.g. protect against discovery of link a= ddresses via unsolicited inbound probing if the IIDs are random (which may = include static configuration of an offline generated random 64 bit IID).

Regards,
Mark.


I also believe RF= C7608 supports this conclusion.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
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-0815=
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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


--001a114dd4cce8a94b0546082efe-- From nobody Sat Jan 14 11:20:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299D129D01; Sat, 14 Jan 2017 11:20:38 -0800 (PST) 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 Zp2DkomxkgHY; Sat, 14 Jan 2017 11:20:36 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3A6129D0E; Sat, 14 Jan 2017 11:20:35 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 204so1525545pge.2; Sat, 14 Jan 2017 11:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NRCqXv1xP56HflJNjeS79cTQwn6m5hhABqCGv4Po2/Q=; b=kh68UXW5ckzUhsSi7DEoJ7SMJWpZbBp0txCigz0kuZ79YjYuvvZ1I7XuivV7acOPYG iCpCcmOjwQfyLA8VRxezqA6+5Ea+r9wuNbc7Ue4KZsHXR65FKWigCwcDpWhtJOAv1B7W VR36hEIb7H9MWNyW7RMGsHFR9HeWRz3w6O99zx9s97kum6FMZJ4hA7/LVTy+oJZ6en7o RlDpeuhvHrCd3lm4n1YwM1D9H+pYrMfg0XK8uF5Jv8kYez79Fh6WquhJRYZjC0OG5nbF zziqCIfyMi//6mhMGqInfC05c+qotGKezBVk/s/DdUy22qZYB8Mpg4FYnhj8+Unmnlik cwGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NRCqXv1xP56HflJNjeS79cTQwn6m5hhABqCGv4Po2/Q=; b=W2PQCEKNgO6yt2rlBe8+zVugqBXC/A+/mtR/2Du8fZctZX3FmHcJa5LD4TAVGpVBwx pUzkmrxqcQzfJftA0F4j7y4AdmR8v6APvFeFXw2L1qQ63TFz3CEVsfQ5lwztfF13iMEv bL/A8Dh5Bh4qpbUIpj0SN613eUHo5ohD8aQkpI/QUjULEjXryCQ6C23rkezc/ETJPu8U tV259dmmC4qATHikJH8sZ0N6obZOhunSL1RuPNF31L5Fk1fyMWPWXXkkVdiutCa2g4FW UM3or80s+TF9yN+lANhX9T97DYXEZHl5K+X8EN5t5hJGsGCFFQkOHjcJ/zRTy+1K9fBt 4kSg== X-Gm-Message-State: AIkVDXLZbF4gWYYZSCWxGNW06e/ZHKQYqDA6LU7ad3o2PxNTeGd/PF20+0ISyvrxnH1wew== X-Received: by 10.84.206.37 with SMTP id f34mr38600991ple.35.1484421635047; Sat, 14 Jan 2017 11:20:35 -0800 (PST) Received: from [192.168.178.21] ([118.149.103.96]) by smtp.gmail.com with ESMTPSA id u14sm36905769pfg.18.2017.01.14.11.20.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jan 2017 11:20:34 -0800 (PST) Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Mark Smith , David Farmer References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> Date: Sun, 15 Jan 2017 08:20:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:20:38 -0000 Mark, I think this thread has shown convincingly that there is a problem with the current wording of 4291bis about the 64 bit IID length. I suggest that we wordsmith it on the 6man list and come back to this broader CC list when we have a proposal. Regards Brian On 14/01/2017 19:37, Mark Smith wrote: > On 14 Jan. 2017 15:36, "David Farmer" wrote: > > > > On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> .... >> >> >> Which is exactly why we have so far only delegated 1/8 of the >> IPv6 address space for global unicast allocation, leaving a *lot* >> of space for fixing our mistakes. Moving away from /64 as the >> recommended subnet size might, or might not, prove to be necessary in >> the long term future. That's why the point about routing being >> classless is fundamental. I do think we need to be a bit more >> precise on this point in 4291bis. >> >> Brian >> > > Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and > I'm fine with that, but that's not what the following says. > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 > ]. > > > It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an > Imperative as discussed in section 6 of RFC2119. > > I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support > that and believe it to be the consensus of the IETF. Maybe even explicitly > noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support > by SLACC. But it is not correct to say the /64 is REQUIRED. > > > I don't think /127s should really be recommended either. > > They don't guarantee that the ping pong problem is solved, because it > depends on both ends being configured with the /127 prefix length by the > operator or operators at each end if the link. There is no protocol > requirement that both ends of a link have the same prefix and prefix > length, nor is there any protocol checking of that condition. > > For example, if an ISP configures a /127 on their end of the customer's > link, but the customer just configures a default route on their end over > the link, it is a legitimate configuration by the protocols, Internet > access will work (so the customer might assume the link is configured > correctly), and yet the link is vulnerable to a ping pong attach despite it > "having" a /127 prefix. > > So it is a mitigation, however it relies on the operator or operators being > disciplined about the configuration, and comes at the cost of other things > that may be useful if a 64 bit IID was available e.g. protect against > discovery of link addresses via unsolicited inbound probing if the IIDs are > random (which may include static configuration of an offline generated > random 64 bit IID). > > Regards, > Mark. > > > I also believe RFC7608 supports this conclusion. > > Thanks. > From nobody Sat Jan 14 11:49: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 13296129421 for ; Sat, 14 Jan 2017 11:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BORd5N6LqBU for ; Sat, 14 Jan 2017 11:49:42 -0800 (PST) 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 A5F171293DC for ; Sat, 14 Jan 2017 11:49:42 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id f144so42994590pfa.2 for ; Sat, 14 Jan 2017 11:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8bSnxapzg3EQI26ubZlie0A/es01iMVO26PDLuyKmQQ=; b=DRE/3exeXjo7xEmEYvvMN+Mmm40N0vYL4uiE2gt5Uu8sGkbMTcXoV4TlN88te8NMBi TFXbVFFL7lNKUmM8VMVpxIU2wJac0HcwkVWnSmPowuIV5StQ4W2xfWG8uLKrLanVuyal ypIr6nNaKqjnawNyyTrVJRCxvZ3lcy9TsppHofzeYE7ZWRd/M8io5NmzJuzIE8gxH7ry B6sOq4Z0iJ7UCMflbCq71ydWbZPszUhhAcKPvTm47siZQgXfMwpHN2TyaHMk3ZU4BrFJ aDaW1Lu2OJd3005T7IAWfCLuR1ksV0hPNIR3K5pKEMkDxnCuRlZ6DptsbQDPZyI41T22 DS1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8bSnxapzg3EQI26ubZlie0A/es01iMVO26PDLuyKmQQ=; b=Oew7TlfrUeoy2EZ0gj5uhUjPwZDBcDyAE5laOjIXddw4yWHx93S/4VdDZm46rqtK53 +zE53bHlvY+q1f2KHSko8Ecdt5C2+e/+7q2bO+ZwgwsNxk52hh6Eo1EAouVWl8aduN6h c3Q19JBYCcqrYdVlr4t2+zVDYJgd6ripnBXCggWASauZ0finnUFFrBiOvlBuD+EufJil 2U0KHLiVt8fklAnJSa/x7GbnpM6RjzkDh5JICtQdMdfY2g/qqxQVSiH4AJAFVyOwaMMc SUS5SLGFmugmOXQU2+NKWo9eDNN11cvcXNKtyrR94P5s5vY6NSZhb3fQyqAK2VMa7G00 FAaQ== X-Gm-Message-State: AIkVDXJDKs9dGIxOC3/LEROFBwYwZ8Q4nGQotzl6Zf3fYMwsPoacagnDJ+MllH/BFaL67Q== X-Received: by 10.98.160.89 with SMTP id r86mr17093576pfe.170.1484423382148; Sat, 14 Jan 2017 11:49:42 -0800 (PST) Received: from [192.168.178.21] ([118.149.103.96]) by smtp.gmail.com with ESMTPSA id z66sm13024389pfd.49.2017.01.14.11.49.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jan 2017 11:49:41 -0800 (PST) Subject: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 15 Jan 2017 08:49:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:49:44 -0000 A modest suggestion: OLD For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, consistent use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires that all interfaces on a link use the same length of Interface ID. In practice, this means that to guarantee interoperability of SLAAC, a fixed length of Interface ID is necessary. For all currently allocated unicast addresses, except those that start with the binary value 000, that length is 64 bits. Note that this value is an arbitrary choice and might be changed for some future allocation of unicast address space. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Regards Brian From nobody Sat Jan 14 15:41: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 BFF06129411 for ; Sat, 14 Jan 2017 15:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIv_1uiYln-A for ; Sat, 14 Jan 2017 15:41:47 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 23DE71293E0 for ; Sat, 14 Jan 2017 15:41:47 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id y9so60533842uae.2 for ; Sat, 14 Jan 2017 15:41:47 -0800 (PST) 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=l+6tCNl9tZh05fHBLrRZXcg/GALSOc5SuKnOPFsnWTM=; b=cFO27kxNBHr9u2GQ3cid1Ox+mzgTlWnwRB+8uM8CIXUNb7ZFqlpgibGU28I1wVtVkf apNUZHZloFp3IgqvodvpUmO2yB9arcFaOPjCbI80ViZv9dVA5sXXHkd+31cmaJn5mw8+ c+xB/MSQ68QmG9KCyfXyRhXYBYMLAyATrxIKwMZZ8DocOoYXYBtsop5NEhDg3oF/mMAl 6tXvuo6MzPW0HoyU4reBxoVaGnkOV3DiJlKlZupJKEnrjAl8IKZVvj/0/+DxqxudcEUZ +DpAGQhvc7KWs9PKVxS0u/HXfR2ZUOZ3yxDE3v/4n9Vk8Jn6Q461PNevIx+kA+R/N1sj qWNQ== 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=l+6tCNl9tZh05fHBLrRZXcg/GALSOc5SuKnOPFsnWTM=; b=nSw+fHkCu6NKxKf+IzCkK6lAp6LRW+/hJ970ry+rSjgAyl5jn8ydN5SOt88ItEoTPv yAUo3yooSJjM/rPifhf6MbBEv6S5tAq+gIjk/WoYeRilm/JlOpiwckMPw7xZOg9r+Xt+ 5AEQMU2oNCyisDY/ro8jNfKO+cER9QQvHbWxoQZ21wzM/vGd5ap9wyzck0AqqEHB+G6B JcMIzw6BnEiDNOjYByVu5iXaBnCQqFDWU3wo1W5X190PNrX3/PQj5If03WQpN9Rlvw/M m6UU6Jw1hAQqDBJdKRk7mUpAaFW+et6BfdjBJBaVLlksciCwWLf4UFw9CbldnI9yZRdm 0+uQ== X-Gm-Message-State: AIkVDXIghlQLeTL80V8cuJSC8rc/ATOIcFEyB7RvCUhp8opLwB0L6Of42+Z/Zu4X2l+H8o+oSe04WCkL1E/p4g== X-Received: by 10.176.2.86 with SMTP id 80mr14331323uas.11.1484437306257; Sat, 14 Jan 2017 15:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Sat, 14 Jan 2017 15:41:45 -0800 (PST) Received: by 10.176.2.235 with HTTP; Sat, 14 Jan 2017 15:41:45 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Mark Smith Date: Sun, 15 Jan 2017 10:41:45 +1100 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113cf1a854b7f10546167e73 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 23:41:49 -0000 --001a113cf1a854b7f10546167e73 Content-Type: text/plain; charset=UTF-8 Hi, On 15 Jan. 2017 06:49, "Brian E Carpenter" wrote: A modest suggestion: OLD For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, consistent use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires that all interfaces on a link use the same length of Interface ID. In practice, this means that to guarantee interoperability of SLAAC, a fixed length of Interface ID is necessary. For all currently allocated unicast addresses, except those that start with the binary value 000, that length is 64 bits. Note that this value is an arbitrary choice and might be changed for some future allocation of unicast address space. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. I think that new text is good. Perhaps a small addition, just to be obvious we have room to change if necessary. "Note that this value is an arbitrary choice and might be changed for some future allocation of unicast address space, outside of the current 1/8th allocation for unicast addresses." Regards, Mark. Regards Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a113cf1a854b7f10546167e73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 15 Jan. 2017 06:49, "Brian E Carpenter" <brian.e.carpenter@gmail.com&g= t; wrote:
A modest suggest= ion:

OLD
=C2=A0 =C2=A0For all unicast addresses, except those that start with the bi= nary
=C2=A0 =C2=A0value 000, Interface IDs are required to be 64 bits long.=C2= =A0 Background
=C2=A0 =C2=A0on the 64 bit boundary in IPv6 addresses can be found in [RFC7= 421].

NEW
=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 12= 8 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127 bit=C2=A0 prefixes on = point-to-point
=C2=A0 =C2=A0links. However, consistent use of Stateless Address Autoconfig= uration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires that all interfaces on a link use th= e same length
=C2=A0 =C2=A0of Interface ID. In practice, this means that to guarantee int= eroperability
=C2=A0 =C2=A0of SLAAC, a fixed length of Interface ID is necessary. For all= currently
=C2=A0 =C2=A0allocated unicast addresses, except those that start with the = binary
=C2=A0 =C2=A0value 000, that length is 64 bits. Note that this value is an = arbitrary
=C2=A0 =C2=A0choice and might be changed for some future allocation of unic= ast address
=C2=A0 =C2=A0space. Background on the 64 bit boundary in IPv6 addresses can= be found
=C2=A0 =C2=A0in [RFC7421].


I think that new text is good.

Perhaps a small addition, just = to be obvious we have room to change if necessary.
<= br>
"Not= e that this value is an arbitrary
=C2=A0 =C2=A0choice and might be changed for some future allocati= on of unicast address
=C2=A0 =C2=A0space, outside of the current 1/8= th allocation for unicast addresses."


Regards,
Mark.


=


Regards
=C2=A0 =C2=A0Brian

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

--001a113cf1a854b7f10546167e73-- From nobody Sun Jan 15 07:55: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 075E512945E for ; Sun, 15 Jan 2017 07:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBqjUxdtzsIH for ; Sun, 15 Jan 2017 07:54:55 -0800 (PST) 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 D0623129424 for ; Sun, 15 Jan 2017 07:54:53 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id y9so67442530uae.2 for ; Sun, 15 Jan 2017 07:54:53 -0800 (PST) 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=A/aiNMK6KzgNO/OZ9TKdlF1Bce6FkMDARouRcPxr3zk=; b=dLJeWpw36DL+BkInPLyJArnb0ueXSrkQ/yy0qzix1IWc1kURDJozCl1hO6XFbFin7l izPQegI8hjTWn6vsXJm3PXHSpRE08RTjMsDFjYeXm6Is3/ZbS9KxR0clvIPzi42CWm2e /eD6hI/3Dd75t/7gt3645qcP5ZGYwLSUcVyHuwyK2ZWzMCfQfPw/LUneFgvFFpeka3/f 7l/ud2Ybn/7Sbx4U/kR5Oqa++o4g6QPtSenSbpmX0VuZWBMZCI+SWt/AGQy23wHTaGos fQgVAPmLZM8mBOjFmkHqifqT04KEItE9uVIDIwOIipg8gKzhoo0eYaN2vXtoINnroNc1 fQ/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=A/aiNMK6KzgNO/OZ9TKdlF1Bce6FkMDARouRcPxr3zk=; b=cFN21R06C1UAbQyf/+0kud50KIvCXPOtnJf+E4Wbe0QsQ2n2aSHlEwj2gmcW9n5c5a zQ3SufS9gGpER+A+GDL+GgUkKQTVSJmMti3XeSn9JqsZYoprqwPeOf+GkIJM0mz7dOhG KCzIlktkSX535gKVZ6/Pc7qMdSW6z9gzm/tgofoHbkpkBe5YX+9gu4UqcKWNFYCntTzP yMyxKCf50AfP9EL5nHkSzFhFvwpXBbOcYNf3AzBYvupHDHqWL2+rEaKuB0mqOIxzjTMx 9uXVEbB7Xnbs8b/25kpDaV2d9nj+VHXC5lnqNpY4meGFdFu4nwxeRV6OItPp11EpEm6I uo9g== X-Gm-Message-State: AIkVDXJ1myrT5QNyRENL8wZV1HJSlBCfBRQ8R+QIHZSy2RGf/PHZnGIdk8iW++OzEZEja9stXHEpHVI+0KcbYTzk X-Received: by 10.176.5.138 with SMTP id e10mr12308210uae.109.1484495692536; Sun, 15 Jan 2017 07:54:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Sun, 15 Jan 2017 07:54:31 -0800 (PST) In-Reply-To: <20170113200334.GO40198@shrubbery.net> References: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <20170113200334.GO40198@shrubbery.net> From: Lorenzo Colitti Date: Mon, 16 Jan 2017 00:54:31 +0900 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: heasley Content-Type: multipart/alternative; boundary=94eb2c1247946fdc4405462416a4 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 15:54:56 -0000 --94eb2c1247946fdc4405462416a4 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 14, 2017 at 5:03 AM, heasley wrote: > > But it's true that supporting /65-/126 increases the cost of the device. > > The extra bits have to go somewhere. I think I've seen hardware that just > > converted all prefixes to 128 bit if there was at least one /65 - /126 > > prefix in the FIB. That costs money for RAM. Obviously that's silly if > > those prefixes are frequent, and you can save that money using better > > software engineering - but software engineering costs money too. > > do such limited devices really need complex ribs/fibs? address, router, > neighbors. all of which are needed regardless of the prefix length. > The "/65 - /126 challenged" devices I'm talking about were very big iron routers. > > Prefixes don't cost money, > > but, they do: https://www.arin.net/fees/fee_schedule.html No, they don't. The link you provide says you get a /32 for $1000, which puts the cost of a /64 at $1000 / 2^32 or $0.0000002. --94eb2c1247946fdc4405462416a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 14, 2017 at 5:03 AM, heasley <heas@shrubbery.net> w= rote:
> But it's true that supporting /65-/126 increases the cost o= f the device.
> The extra bits have to go somewhere. I think I've seen hardware th= at just
> converted all prefixes to 128 bit if there was at least one /65 - /126=
> prefix in the FIB. That costs money for RAM. Obviously that's sill= y if
> those prefixes are frequent, and you can save that money using better<= br> > software engineering - but software engineering costs money too.

do such limited devices really need complex ribs/fibs?=C2=A0 address= , router,
neighbors.=C2=A0 all of which are needed regardless of the prefix length.

The "/65 - /126 challenged" de= vices I'm talking about were very big iron routers.
=C2=A0
> Prefixes don't cost money,

but, they do: https://www.arin.net/fees/fee_s= chedule.html

No, they don't. The li= nk you provide says you get a /32 for $1000, which puts the cost of a /64 a= t $1000 / 2^32 or $0.0000002.
--94eb2c1247946fdc4405462416a4-- From nobody Mon Jan 16 01:37: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 21FA91293F2 for ; Mon, 16 Jan 2017 01:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 6LfYoQYGg5Fq for ; Mon, 16 Jan 2017 01:37:12 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22AC126D73 for ; Mon, 16 Jan 2017 01:37:11 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id k127so24161971vke.0 for ; Mon, 16 Jan 2017 01:37:11 -0800 (PST) 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=pMLvawMOL6w7uwwXwcN3cv7fFQcR+yl0U9vjm7vD+gQ=; b=CaIY6Fajh2rj33yyQyM3YgxfwaPIAKuw4BvHZVacXisDXDiAeaINjQvYfyKFw/kGew q8211lP6BJCA0dNvaotWSp7yRqG4bx+gKc9487vIjZTbV3mHMUOxiPVJJ/zDBMuM+EEO EfJPEvd1IjX/j3rxn0uWV+ekQpeKLbgmkvebAAJxgH/hExr9ekJdMtHIqysZX1AyDwsd gB/+hHjP8AHAGNaiE4hJfy8WYiwxmA3m3SlYnlw0H7rBRgOjcUefalE6RcfoXGtYbofX LhjxTS+P8eYkVyQajgKFHprXpACaKzcI2jVpdaetB9ePt6KG0wTsYW1dHqcmujn3ZfSo mIug== 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=pMLvawMOL6w7uwwXwcN3cv7fFQcR+yl0U9vjm7vD+gQ=; b=i4mf/GgjTAfL8GDfMjNdncQbnIIVWSQDcVvBxdvJPgQACUEnSIIK7B1nNKkYal9glY GQsfTPjwf0QU84NjqVs0mXxNWaFzToZZMimlRYpN+ZEzDGVbPnJIJ2bDEKf5eelGFkP8 DeTCOvi22ROxs+xfuHOJimaKNiHNmNeT9ko4VurjgzmR4efX0HfhPuSF3ONfQUSAZHsE BLf7mpNEsc5rB1C2ZvZZNKXZ+RXfpy0+fJ9dKOqqYVI23lef3zTI6WIj8lTz8t6WNxeW or6NDEhvyoTU0h05SP8AwMz9ll7+v51XaL5XSfAbS2CQKIaNgVFLHqSJ/Y1KnDrnELoi UvhA== X-Gm-Message-State: AIkVDXK13UJ+KpXtkZG3hxV7SYVQnGKylrREab3bYMgUy2HsYGDd8c8B4Sus0JDLXTibFUHD8p1Y1FQBSOcC6DQo X-Received: by 10.31.150.134 with SMTP id y128mr13298545vkd.102.1484559430868; Mon, 16 Jan 2017 01:37:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 01:36:50 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Lorenzo Colitti Date: Mon, 16 Jan 2017 18:36:50 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1141d60086b945054632ed71 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 09:37:14 -0000 --001a1141d60086b945054632ed71 Content-Type: text/plain; charset=UTF-8 Brian, what's the specific rationale for this change? Is it a bug in 4291 which you're proposing that we resolve in 4291 bis? If so, what is the bug? The "interface identifiers are 64 bits" long text in RFC 4291 goes back all the way to 1998 and the text below would be a major change to text that has likely been baked into implementations for almost two decades years. I don't see why we would change that now. BTW: if the reason for the text is a perceived contradiction between the fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all bit lengths" - I don't see a contradiction. In general, IPv6 addresses are aggregatable on all bit lengths. But global unicast addresses (other than ::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix lengths. These two properties can coexist even in global unicast space. For example, you could load-balance traffic to a given global unicast /64 by announcing it to the backbone as two /65s. The "addresses are aggregatable on all bit lengths" text means that the /65 are valid prefixes that can be routed by routers. Cheers, Lorenzo On Sun, Jan 15, 2017 at 4:49 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > NEW > IPv6 routing is based on prefixes of any valid length up to 128 > [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length > of Interface ID. In practice, this means that to guarantee > interoperability > of SLAAC, a fixed length of Interface ID is necessary. For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is 64 bits. Note that this value is an arbitrary > choice and might be changed for some future allocation of unicast > address > space. Background on the 64 bit boundary in IPv6 addresses can be found > in [RFC7421]. > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1141d60086b945054632ed71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bria= n,

wha= t's the specific rationale for this change? Is it a bug in 4291 which y= ou're proposing that we resolve in 4291 bis? If so, what is the bug?

The &quo= t;interface identifiers are 64 bits" long text in RFC 4291 goes back a= ll the way to 1998 and the text below would be a major change to text that = has likely been baked into implementations for almost two decades years. I = don't see why we would change that now.

BTW: if the reason for the text is a = perceived contradiction between the fact that "IIDs are 64 bits" = and "IPv6 addresses are aggregatable on all bit lengths" - I don&= #39;t see a contradiction. In general, IPv6 addresses are aggregatable on a= ll bit lengths. But global unicast addresses (other than ::/3) have a 64-bi= t IID, so links in that space are assigned 64-bit prefix lengths.=C2=A0Thes= e two properties can coexist even in global unicast space. For example, you= could load-balance traffic to a given global unicast /64 by announcing it = to the backbone as two /65s. The "addresses are aggregatable on all bi= t lengths" text means that the /65 are valid prefixes that can be rout= ed by routers.

Cheers,
Lorenzo

On Sun, Jan 15, 2017= at 4:49 AM, Brian E Carpenter <brian.e.carpenter@gmail.com&= gt; wrote:
NEW<= br> =C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 12= 8 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127 bit=C2=A0 prefixes on = point-to-point
=C2=A0 =C2=A0links. However, consistent use of Stateless Address Autoconfig= uration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires that all interfaces on a link use th= e same length
=C2=A0 =C2=A0of Interface ID. In practice, this means that to guarantee int= eroperability
=C2=A0 =C2=A0of SLAAC, a fixed length of Interface ID is necessary. For all= currently
=C2=A0 =C2=A0allocated unicast addresses, except those that start with the = binary
=C2=A0 =C2=A0value 000, that length is 64 bits. Note that this value is an = arbitrary
=C2=A0 =C2=A0choice and might be changed for some future allocation of unic= ast address
=C2=A0 =C2=A0space. Background on the 64 bit boundary in IPv6 addresses can= be found
=C2=A0 =C2=A0in [RFC7421].

Regards
=C2=A0 =C2=A0Brian

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

--001a1141d60086b945054632ed71-- From nobody Mon Jan 16 01:58: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 A8A8D129455 for ; Mon, 16 Jan 2017 01:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 fEs-oUKjfDZN for ; Mon, 16 Jan 2017 01:58:08 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90342126FDC for ; Mon, 16 Jan 2017 01:58:07 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c85so151468870wmi.1 for ; Mon, 16 Jan 2017 01:58:07 -0800 (PST) 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=8MqFnWUK1IkdesgUsx0Po1uXwUjfehBCgePIkYkFxDA=; b=YVN3tP1V1lDCdwYdJwpcJZ5rwr5FMGa07DR6PuUpQVNTQ+FJUsMrCOt6/m7lM94XNp vO/Y9jnhUEmHgIjVGANoCIERj4mLgDR/KDNwhBXVx3ZYs76e/uQWbh3k3rLBeGQFmCxj 8i7BWqAMn2WF8YZihlwhIZZBwK9qZR+XuysN30zX4FBCn/w9W92hGJP8GNNpK1pkaSpR ts7H0oDXo1Azho88Sv9SQIPBHNWXOWsp06f7kwPM8MOrlcYfaxK9nPOvBX5MSYgvkRcL 4XxuVs/vGamf4iIbuKE3ZQBXFVLhpLTZgFKBCTpWl8kty85GQRykBmK0tBP3qJBIwVdk gNbg== 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=8MqFnWUK1IkdesgUsx0Po1uXwUjfehBCgePIkYkFxDA=; b=WpBu8rkDnYsIMT/Tn+CHbRE0YLZJAB/Qa9Mhd5UepGf0ycKrSQyIaw/KQUeDqpfXhk eaVvSoLI3dsr1dn06nlTNvyBLRh/Kg/+SbApVAJY9A9oO9mvJ3vME98tytlG2Ol6heeG 7I4zQz1vAMGpLkIUdY6lUGMJsP3cJKZe189EYRTbkT79vmt8F7rC3TtlJqhB4FWfRAvy f+wBuPxee4MqYBVlB7B0pDqlBqViDRnwtxyNzUqbHaClYI1H1EowOkxq0CqL9eTbibBy x2AHvV+wLxaSifZHvZGsMmk5POI+TUe3pA9nbgWsyz22NGki1kxza5hCf9aCCYI/+2Qk CYmw== X-Gm-Message-State: AIkVDXJazrxoEeVjdc+0JurfGWB2LWNTYwfU3iu22svKBtkKPt3OoNC0EgbgOVUxzVvRe3iGsSjVjgnRl9u63DbL X-Received: by 10.223.128.202 with SMTP id 68mr22646843wrl.148.1484559903974; Mon, 16 Jan 2017 01:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 01:44:42 -0800 (PST) In-Reply-To: <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> From: Erik Kline Date: Mon, 16 Jan 2017 18:44:42 +0900 Message-ID: Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 To: Brian E Carpenter Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c08225857e15305463338ec" Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 09:58:09 -0000 --94eb2c08225857e15305463338ec Content-Type: text/plain; charset=UTF-8 It would definitely be very good to see specific text. Since this is (IIRC) being done for Standards Track purposes, the primary goal crudely phrased is to collapse the diffs between the base document and all those that modify it. Or so I have thought. Text that illuminates surely seems fine, but text that alters stuff at this stage doesn't seem like too good an idea to me. On 15 January 2017 at 04:20, Brian E Carpenter wrote: > Mark, > > I think this thread has shown convincingly that there is a problem with > the current wording of 4291bis about the 64 bit IID length. > > I suggest that we wordsmith it on the 6man list and come back to this > broader CC list when we have a proposal. > > Regards > Brian > > On 14/01/2017 19:37, Mark Smith wrote: >> On 14 Jan. 2017 15:36, "David Farmer" wrote: >> >> >> >> On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> .... >>> >>> >>> Which is exactly why we have so far only delegated 1/8 of the >>> IPv6 address space for global unicast allocation, leaving a *lot* >>> of space for fixing our mistakes. Moving away from /64 as the >>> recommended subnet size might, or might not, prove to be necessary in >>> the long term future. That's why the point about routing being >>> classless is fundamental. I do think we need to be a bit more >>> precise on this point in 4291bis. >>> >>> Brian >>> >> >> Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and >> I'm fine with that, but that's not what the following says. >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 >> ]. >> >> >> It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an >> Imperative as discussed in section 6 of RFC2119. >> >> I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support >> that and believe it to be the consensus of the IETF. Maybe even explicitly >> noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support >> by SLACC. But it is not correct to say the /64 is REQUIRED. >> >> >> I don't think /127s should really be recommended either. >> >> They don't guarantee that the ping pong problem is solved, because it >> depends on both ends being configured with the /127 prefix length by the >> operator or operators at each end if the link. There is no protocol >> requirement that both ends of a link have the same prefix and prefix >> length, nor is there any protocol checking of that condition. >> >> For example, if an ISP configures a /127 on their end of the customer's >> link, but the customer just configures a default route on their end over >> the link, it is a legitimate configuration by the protocols, Internet >> access will work (so the customer might assume the link is configured >> correctly), and yet the link is vulnerable to a ping pong attach despite it >> "having" a /127 prefix. >> >> So it is a mitigation, however it relies on the operator or operators being >> disciplined about the configuration, and comes at the cost of other things >> that may be useful if a 64 bit IID was available e.g. protect against >> discovery of link addresses via unsolicited inbound probing if the IIDs are >> random (which may include static configuration of an offline generated >> random 64 bit IID). >> >> Regards, >> Mark. >> >> >> I also believe RFC7608 supports this conclusion. >> >> Thanks. >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c08225857e15305463338ec Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgBk59CfRexYUa+F9v99AZW7DujE5ZSJgW WpFyohZmCL8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTE2 MDk1ODA2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGOh6tuFXowGc0BsisGwER9oZp/wjENF1wa3SmHVelQNl7Ot9ZNi Mr2dMwLNeFZgf3DFIdQ+MuViOQKBeDbImNWQxlhZe8NOr5DVT5PWXRQHFT9HMRuz0L16N3hgjU5y DBSSGf/7hBB/YL0cQff+eCuzAGElePi8NczsZhKjyG2sqYuInfTwIXC4vTA/dtqDfFrUuNg/iHQ3 yXLOuOR7myB9MHBsyH0iFlXyehfgoq+2KwMEkGE8kGDUF6QT8NiXqplxyM4Z2JT9Wim4f02NtRtR o/m8a9fFoaGqjzHIxeAxIbzWzafQy7y7d27NsPynYiKTT5XY8PvnjM2EBu54yhw= --94eb2c08225857e15305463338ec-- From nobody Mon Jan 16 03:00: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 BCE53129536; Mon, 16 Jan 2017 03:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 h-cW1Z2uiaWo; Mon, 16 Jan 2017 03:00:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2830B129491; Mon, 16 Jan 2017 03:00:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cT518-0007jj-TD; Mon, 16 Jan 2017 11:00:03 +0000 Date: Mon, 16 Jan 2017 19:59:59 +0900 Message-ID: From: Randy Bush To: Erik Kline Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 11:00:08 -0000 > Since this is (IIRC) being done for Standards Track purposes, the > primary goal crudely phrased is to collapse the diffs between the base > document and all those that modify it. i am not a fan of incorporating the content from A into B. if you get it wrongly, we chase the confusion caused by the conflict(s) forever. and if you get it correctly, then why the heck not just refer to it? ymmv, of course. my impression is that the 6man chair and document author (beep) is trying to produce a stone tablet to be carried down the mountain. which is partially why i am being such a bleep about getting it correct. randy From nobody Mon Jan 16 11:58: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 F22871299F6 for ; Mon, 16 Jan 2017 11:57:56 -0800 (PST) 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 lrYAqkmRuZbp for ; Mon, 16 Jan 2017 11:57:55 -0800 (PST) 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 8F07012962C for ; Mon, 16 Jan 2017 11:57:55 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 194so17858936pgd.2 for ; Mon, 16 Jan 2017 11:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Xg9aF18//bHp2tZYoipF8xFHtm92bAsqyWp2CNtr598=; b=WAwjwuJsJVF8+QZgQiA4n7eZlulsHR3Ppg8JxGYxtd2y5jVOeATzaBtsgqHmZPVluc x6FSTVJTvMSawySpcmcwyocdS6LLNXBRPTS56Vuy87JwgeJNxLWXWnO3BGY1oxKaV6AW H404mmCUV1EHVTvXxo0af0Ad/rxSEoHoPpoCe268nSTYF+UtGCny9SIiC4JQAKi7xezp 9AM0TecAnSFMGuXjmsDAcWYEWB3xFqpVFkx0llmhEgX3hkPVx8c7szb2AgOqAAAKbLUj Neof1WYKD5cEGmoke9Cd02wlapyUdTlnHluxFmL0o+Vl/jfYY0bXFqCFJAW/EpritPFU 9y1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Xg9aF18//bHp2tZYoipF8xFHtm92bAsqyWp2CNtr598=; b=ZB10JbekGtL3ycp1LEor+jgsnhhPJ1XSxILVToPcHP+w81/dPdrA9uhsgpfruZxhF2 v6SyulIn+qpAW0PypB+i6jDixTsyqjtjLBzyEvKM98MeJ5JW8v0KhwJkGTInUnkNPmDD Zkvlz7MKusuNIvQAZ5nGXAuw4U5WJGxAZAvOMXAHuligYtcxThy5l4q7EU/mjQboa0hJ Mzc0duamIe4MAFLc1IItwN8kgWlJ/D/HirONWAuTF3J84GqfYbLVhhklB2dZihCz+II2 FsaRyQEyWe5fguvVonTBWrJbbbNNhQkQfwYFCFKt9DaMMkSdTWifdh3XQb9i9Xee/Zxq JaPg== X-Gm-Message-State: AIkVDXJOnLQcOzxoywAKfM3HaADtxdolZRjeZLFzpuYn+jPfgTELGvf3yDRbbFRnReJYtA== X-Received: by 10.98.69.139 with SMTP id n11mr11091329pfi.65.1484596675069; Mon, 16 Jan 2017 11:57:55 -0800 (PST) Received: from ?IPv6:2406:e007:4961:1:28cc:dc4c:9703:6781? ([2406:e007:4961:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i82sm1046345pfk.52.2017.01.16.11.57.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 11:57:54 -0800 (PST) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> Date: Tue, 17 Jan 2017 08:57:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 19:57:57 -0000 On 16/01/2017 22:36, Lorenzo Colitti wrote: > Brian, > > what's the specific rationale for this change? Is it a bug in 4291 which > you're proposing that we resolve in 4291 bis? If so, what is the bug? The bug is that in SLAAC, the IID length is a parameter, not a constant, and that in routing protocols, the prefix length is a parameter, not a constant. The addressing architecture needs to recognise that. > The "interface identifiers are 64 bits" long text in RFC 4291 goes back all > the way to 1998 and the text below would be a major change to text that has > likely been baked into implementations for almost two decades years. I > don't see why we would change that now. Any SLAAC implementation that has 64 baked into it is already non-conformant. But I very much doubt if anyone will need to change their code as a result (except for any non-conformant routers such as you mentioned recently). > BTW: if the reason for the text is a perceived contradiction between the > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all > bit lengths" - I don't see a contradiction. I suggest discussing that with Randy Bush. > In general, IPv6 addresses are > aggregatable on all bit lengths. But global unicast addresses (other than > ::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix > lengths. These two properties can coexist even in global unicast space. For > example, you could load-balance traffic to a given global unicast /64 by > announcing it to the backbone as two /65s. The "addresses are aggregatable > on all bit lengths" text means that the /65 are valid prefixes that can be > routed by routers. Sure. And this text doesn't aim to change anything in any current (and non-broken) implememtations. It aims to respond to the objections that have been discussed on the IETF list recently. Brian > > Cheers, > Lorenzo > > On Sun, Jan 15, 2017 at 4:49 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> NEW >> IPv6 routing is based on prefixes of any valid length up to 128 >> [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, consistent use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same >> length >> of Interface ID. In practice, this means that to guarantee >> interoperability >> of SLAAC, a fixed length of Interface ID is necessary. For all currently >> allocated unicast addresses, except those that start with the binary >> value 000, that length is 64 bits. Note that this value is an arbitrary >> choice and might be changed for some future allocation of unicast >> address >> space. Background on the 64 bit boundary in IPv6 addresses can be found >> in [RFC7421]. >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From nobody Mon Jan 16 12:27: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 EB0E3129675 for ; Mon, 16 Jan 2017 12:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgBUJGFLy5CX for ; Mon, 16 Jan 2017 12:27:30 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 709A81294F3 for ; Mon, 16 Jan 2017 12:27:30 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id z134so88763426lff.3 for ; Mon, 16 Jan 2017 12:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=TByWd042lXcElA/8XJY8ZaUv+Rxcf4cHHcrCcBhdwb0=; b=lunnv0cHK6xWRKFXneRQ9Qr3p6RxuV6wQLpjJEevgye3oxs9wtMdoWkzg4hcuh8+g2 A+DNdJh9kwjDSGPZNANnJRvxhH+OO69OwaLySd5F+i2uVmAB8IivcZXl8FAlevuJ4bmD 7bxVY4b3Lxix56ek0ENVWscablCNiqjaGEsGysuZsyw+ae2ObHOtdQZBStjMPbH54wP7 9e1LFDKbK0pkXPMpNAltX1lGvivXlP+jTssPH0Ry/QQ3YPEiGijnVqagkCL1gTnTqr/u cY6+LAjCvsfd8gjaibP2l0mVSMcTtfsmd//fzV5OU279JRmpvjIoH23tNTLEZdIYyCE3 lcqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TByWd042lXcElA/8XJY8ZaUv+Rxcf4cHHcrCcBhdwb0=; b=lpcemV9FzVTxtFJmO6iIFd+PrzNMCwL+zv3Z/0UF0N+VxOa19C6lWE02TWrb/cSJBR vdXglc4M2iDsNpYWx90skGbPti37CIpjmksVwWmKWtixEhliP0U03di6Q6h4LNvQZ9dS zNMcrp6Ws91G83+81WnPsVvxxVJ8i2tfmu8QoC3TC/n7Anr34CS5OIHk2KhPRLqJVEsQ +GNYpHkgKgMADBYn82PSsSK6jfmbkGkaGEEI67CQ34harNRd6qYVPJ3HL1sB2XMuoHx1 BUmcZygfK7VCq+LU2J84RkmtyX3B2+HYwP7wCjQP/EAYNXx6luz1LTmCurfg/F4ZID4z DA+w== X-Gm-Message-State: AIkVDXLB8JyeBp3PMj6UTRq7Q/HMjioItefbpQGH9Ri9gmckf8wrqslJAQoSkGWdURoOIA== X-Received: by 10.25.216.3 with SMTP id p3mr12740968lfg.16.1484598448635; Mon, 16 Jan 2017 12:27:28 -0800 (PST) Received: from [192.168.1.73] (24.113.227.87.static.ld.siw.siwnet.net. [87.227.113.24]) by smtp.gmail.com with ESMTPSA id t1sm739840lja.48.2017.01.16.12.27.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 12:27:27 -0800 (PST) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu Subject: Re: IID length text To: Brian E Carpenter References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Message-ID: <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> Date: Mon, 16 Jan 2017 21:27:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 20:27:32 -0000 Le 14/01/2017 20:49, Brian E Carpenter a crit : > A modest suggestion: > > OLD > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > > NEW > IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same length > of Interface ID. In practice, this means that to guarantee interoperability > of SLAAC, a fixed length of Interface ID is necessary. For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is 64 bits. Note that this value is an arbitrary > choice and might be changed for some future allocation of unicast address > space. Background on the 64 bit boundary in IPv6 addresses can be found > in [RFC7421]. I agree with the change suggestion. The new text and references are enough motivation to clarify that that 64bit limit is an arbitrary choice and might change in the future. Alex > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jan 16 12:28: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 6F56712967B for ; Mon, 16 Jan 2017 12:28:52 -0800 (PST) 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 o9GsmtoowSUW for ; Mon, 16 Jan 2017 12:28:50 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F5612951B for ; Mon, 16 Jan 2017 12:28:50 -0800 (PST) Received: from [192.168.3.100] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 22E59829F6; Mon, 16 Jan 2017 21:28:46 +0100 (CET) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <64cfae99-3d70-25b7-09b1-a1d327c563bf@si6networks.com> Date: Mon, 16 Jan 2017 16:59:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 20:28:52 -0000 On 01/14/2017 04:49 PM, Brian E Carpenter wrote: > A modest suggestion: > > OLD > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > > NEW > IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same length > of Interface ID. In practice, this means that to guarantee interoperability > of SLAAC, a fixed length of Interface ID is necessary. fixed as "all nodes on the link use the same IID length" or as in "a hardcoded IID length, as the current 64 value"? If the former, I agree. If the later, I don't. The 64-bit length seems to have a lot to do with embedding MAC addresses (IIRC, the IID length was something like 48, but then changed to 64 in response to EUI-64). Certainly, if you generate IIDs by embedding some number which has constraints (as a MAC address), you need a fixed length. OTOH, if you select the IIDs from a stream of bits (as RFC7217 does), then you don't care about the length (other than "as many bits as necessary such that the host density is low, and hence collisions of IIDs are reduced). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 16 12: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 BE9FE12967E for ; Mon, 16 Jan 2017 12:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA_FxsP4-fWP for ; Mon, 16 Jan 2017 12:42:33 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 EEFEF126BF6 for ; Mon, 16 Jan 2017 12:42:32 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id z134so88988888lff.3 for ; Mon, 16 Jan 2017 12:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=No8VJFWkKtOc2/5eIX/8e1n3IuV8whnN3y2o9YO0FTY=; b=easBZ2f8Av87q/2o8iHjyY2nR44A8uwqazKUfcX/EFvO7UYfETwFmKoukqv8amS6aK rC354ilCyPb8e4rVP85ohJg5cC8qSS5Fr19C+H7r+oIE1daD+aMWkXakurlvh6wN2yLi tbdKPpHWNn7RfTGPfU0NZ2FR3t+u2kqhBwIjau8fDvzkW0lgRT3GSqKNmhW3ZDdWv9pG wBYl6GX68+BRnIn7UM4TjkYciee/Bsj7MVbS3bNQqsLGuBYR4RR7hVbBYRDGE7eLuGQ/ FSUmsOnvPi5pZzOQw5BxsyN7rPWfzraM4+EapQEtlc25qQwLZmEtEyuZ/eTDf+CTU6Vy uFOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=No8VJFWkKtOc2/5eIX/8e1n3IuV8whnN3y2o9YO0FTY=; b=GqfJVtm6oJMo7/03VV9QXkNUIdKaBGXS4CxY/2YBNqNOjnzTjUUr2LFKT+VjErDlUC FPvojrT8j6CNAagsvHHclmP0fSH3VF9d+5UBUObQndZPRFNugi9kuqLSnRShAv/Gh9+6 KwEmq3sD9COQ0pF/Kjpff2bfpzAtqI1knBLTC9Oe0dyUh77dFOG0qGvwJwEooidmM2wh dccov4e0fJkANZB4l9vr5YBbZ304BcOxKZDAXzk7i5q8z14HDYYBng8xre/Wto8NOsX+ oqWsBEJvHT5+InmhrY1bMPci4F86D+tfoslI/+SCBfM/1N2/cCt3/dXvrzL2OtuIXkZt 3Z+w== X-Gm-Message-State: AIkVDXKC1UGwX2zerzdtofK5BLdG4PUou9ngvQlDWRFTGn48JO7AMUwBVzazMEHKR/wHZIvy1252CScEjrivzw== X-Received: by 10.25.28.199 with SMTP id c190mr7088313lfc.173.1484599351098; Mon, 16 Jan 2017 12:42:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Mon, 16 Jan 2017 12:42:30 -0800 (PST) In-Reply-To: <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> From: Behcet Sarikaya Date: Mon, 16 Jan 2017 14:42:30 -0600 Message-ID: Subject: Re: IID length text To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 20:42:34 -0000 On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu wrote: > Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >> >> A modest suggestion: >> >> OLD >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> >> NEW >> IPv6 routing is based on prefixes of any valid length up to 128 >> [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-poi= nt >> links. However, consistent use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same >> length >> of Interface ID. In practice, this means that to guarantee >> interoperability >> of SLAAC, a fixed length of Interface ID is necessary. For all >> currently >> allocated unicast addresses, except those that start with the binary >> value 000, that length is 64 bits. Note that this value is an arbitra= ry >> choice and might be changed for some future allocation of unicast >> address >> space. Background on the 64 bit boundary in IPv6 addresses can be fou= nd >> in [RFC7421]. > > > I agree with the change suggestion. The new text and references are enou= gh > motivation to clarify that that 64bit limit is an arbitrary choice and mi= ght > change in the future. > 3GPP assigns 64 bit prefixes to each UE. Extended Unique Identifiers defined are EUI-48 and EUI-64. I don't think 64 bit limit is that arbitrary? Behcet > Alex > >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Mon Jan 16 13:15: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 D42E612968D for ; Mon, 16 Jan 2017 13:15:51 -0800 (PST) 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 PWt4LV8ZLv51 for ; Mon, 16 Jan 2017 13:15:50 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6984F12968C for ; Mon, 16 Jan 2017 13:15:50 -0800 (PST) Received: from [192.168.3.100] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5FCF683761; Mon, 16 Jan 2017 22:15:45 +0100 (CET) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter , Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8bd05d18-715c-2adc-e74b-a9a3cfe28b2e@si6networks.com> Date: Mon, 16 Jan 2017 17:45:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:15:52 -0000 On 01/16/2017 04:57 PM, Brian E Carpenter wrote: > On 16/01/2017 22:36, Lorenzo Colitti wrote: >> Brian, >> >> what's the specific rationale for this change? Is it a bug in 4291 which >> you're proposing that we resolve in 4291 bis? If so, what is the bug? > > The bug is that in SLAAC, the IID length is a parameter, not a constant, > and that in routing protocols, the prefix length is a parameter, not > a constant. The addressing architecture needs to recognise that. +1 >> The "interface identifiers are 64 bits" long text in RFC 4291 goes back all >> the way to 1998 and the text below would be a major change to text that has >> likely been baked into implementations for almost two decades years. I >> don't see why we would change that now. > > Any SLAAC implementation that has 64 baked into it is already non-conformant. > But I very much doubt if anyone will need to change their code as a result > (except for any non-conformant routers such as you mentioned recently). +1 >> In general, IPv6 addresses are >> aggregatable on all bit lengths. But global unicast addresses (other than >> ::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix >> lengths. These two properties can coexist even in global unicast space. For >> example, you could load-balance traffic to a given global unicast /64 by >> announcing it to the backbone as two /65s. The "addresses are aggregatable >> on all bit lengths" text means that the /65 are valid prefixes that can be >> routed by routers. > > Sure. And this text doesn't aim to change anything in any current (and > non-broken) implememtations. It aims to respond to the objections that have > been discussed on the IETF list recently. Agreed. (Thanks for proposing text, btw!) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 16 13:16: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 8229F129692 for ; Mon, 16 Jan 2017 13:15:56 -0800 (PST) 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 3q6i-QzzK9MZ for ; Mon, 16 Jan 2017 13:15:55 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63702129691 for ; Mon, 16 Jan 2017 13:15:55 -0800 (PST) Received: from [192.168.3.100] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F03C983761; Mon, 16 Jan 2017 22:15:51 +0100 (CET) Subject: Re: IID length text To: sarikaya@ieee.org, Alexandre Petrescu References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> From: Fernando Gont Message-ID: <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> Date: Mon, 16 Jan 2017 17:46:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:15:56 -0000 On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: > On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu > wrote: >> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit : >>> >>> A modest suggestion: >>> >>> OLD >>> For all unicast addresses, except those that start with the binary >>> value 000, Interface IDs are required to be 64 bits long. Background >>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >>> >>> NEW >>> IPv6 routing is based on prefixes of any valid length up to 128 >>> [BCP198]. >>> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >>> links. However, consistent use of Stateless Address Autoconfiguration >>> (SLAAC)[RFC4862] requires that all interfaces on a link use the same >>> length >>> of Interface ID. In practice, this means that to guarantee >>> interoperability >>> of SLAAC, a fixed length of Interface ID is necessary. For all >>> currently >>> allocated unicast addresses, except those that start with the binary >>> value 000, that length is 64 bits. Note that this value is an arbitrary >>> choice and might be changed for some future allocation of unicast >>> address >>> space. Background on the 64 bit boundary in IPv6 addresses can be found >>> in [RFC7421]. >> >> >> I agree with the change suggestion. The new text and references are enough >> motivation to clarify that that 64bit limit is an arbitrary choice and might >> change in the future. >> > > 3GPP assigns 64 bit prefixes to each UE. > Extended Unique Identifiers defined are EUI-48 and EUI-64. What does a layer-2 EUI have to do with a layer-3 address? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 16 13:22:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32BA1293DC for ; Mon, 16 Jan 2017 13:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuxBLhiOvQVo for ; Mon, 16 Jan 2017 13:22:12 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 F00A91293D6 for ; Mon, 16 Jan 2017 13:22:11 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id z134so89557522lff.3 for ; Mon, 16 Jan 2017 13:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=cnilp6Cyf6Xtd+eJMkouu29WEtWpqBlohfN52qoAw1o=; b=ftZx9fSjyIM/nFvl7hZHpWZbtDzPAjbQ6gGEAGaJODRvwVP4p8mq9wf4Pu9Ks6e4tv kPOZ6wYIEpqwScTbihE7h+zMbNts8i0WudAQmst2MiVDug8n/bUPKHisXpdD1qI7N5cT 4gXOZDR/Nl3EV27bXO+O8SoiaJO03QSPZG71OnLUBYsYVe98Nu0aTJDT7pqZASDICIKO AcnPv7FED0oHbzGR6x5pPVcIdlTa7hbdVMvvGGnUApsdgiHmVhHeGG9e0UPn/k/+c5Qk alOVm9ZwZryyB84IyDECAa5nLmEZkCNayezagbIyxg0dCZCtw4LKuyqdU9gZPLvr2/zJ eDnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=cnilp6Cyf6Xtd+eJMkouu29WEtWpqBlohfN52qoAw1o=; b=Xh/hTL+TO45QpaZLAMq4dFJpaN9llYSkfDuBjqs7IPNvlRlHtbBgep5XMKOeQlH4YW knvYhE9VQcmCJvdaw8Va2ddaHfWfYDkMGqt3W5vUVH+VT4Fuc7t85f+vgESxUoOjYoX+ I2HoRchOO8xTjdcv+QQrb+rgg8T3WVqwAMZdt4iiBjRZzdML6etY54iNt/iVVDf3alcB 7jrLDuFpjJyu47f4sbDQHYe6RwqrZSqJ+QCKgeZWCb6+0CTyYMTh1+riAGcAFoz8tMMi pPdtJmyir4O9siMCV06VwNwV5IxVfnHNcbY/FUOxufZfLBrLmGelWC4g+Iq7PiREZQQE 8TJw== X-Gm-Message-State: AIkVDXLNR2hmas9LH3eviiwGCJtUEYoDaQnx9V1kvETj0b4Xc8katRZekJyn5clDoY/i9IeJBNNXz4Pgyyo/ng== X-Received: by 10.46.77.17 with SMTP id a17mr14298501ljb.2.1484601729978; Mon, 16 Jan 2017 13:22:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Mon, 16 Jan 2017 13:22:09 -0800 (PST) In-Reply-To: <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> From: Behcet Sarikaya Date: Mon, 16 Jan 2017 15:22:09 -0600 Message-ID: Subject: Re: IID length text To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 21:22:13 -0000 On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont wrot= e: > On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >> wrote: >>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>> >>>> A modest suggestion: >>>> >>>> OLD >>>> For all unicast addresses, except those that start with the binary >>>> value 000, Interface IDs are required to be 64 bits long. Backgrou= nd >>>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >>>> >>>> NEW >>>> IPv6 routing is based on prefixes of any valid length up to 128 >>>> [BCP198]. >>>> For example, [RFC6164] standardises 127 bit prefixes on point-to-p= oint >>>> links. However, consistent use of Stateless Address Autoconfigurati= on >>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the sam= e >>>> length >>>> of Interface ID. In practice, this means that to guarantee >>>> interoperability >>>> of SLAAC, a fixed length of Interface ID is necessary. For all >>>> currently >>>> allocated unicast addresses, except those that start with the binar= y >>>> value 000, that length is 64 bits. Note that this value is an arbit= rary >>>> choice and might be changed for some future allocation of unicast >>>> address >>>> space. Background on the 64 bit boundary in IPv6 addresses can be f= ound >>>> in [RFC7421]. >>> >>> >>> I agree with the change suggestion. The new text and references are en= ough >>> motivation to clarify that that 64bit limit is an arbitrary choice and = might >>> change in the future. >>> >> >> 3GPP assigns 64 bit prefixes to each UE. >> Extended Unique Identifiers defined are EUI-48 and EUI-64. > > What does a layer-2 EUI have to do with a layer-3 address? I don't know, you tell me :-) > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Mon Jan 16 14:04: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 8CA481294F5 for ; Mon, 16 Jan 2017 14:04:06 -0800 (PST) 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 zoy0ScgPbrRr for ; Mon, 16 Jan 2017 14:04:05 -0800 (PST) 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 6B2201296A4 for ; Mon, 16 Jan 2017 14:04:05 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id 204so18539106pge.0 for ; Mon, 16 Jan 2017 14:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=y/jtzVchtZAxjRd4Oe8jYGGE2z3R3ro98E+l6JqRWMA=; b=R4cMNS1z3N9PIj2ydr9ZoTSTFaL2roYwwV55k74Yg321c2q3XMnfXQtwa1WK7BhgW+ hM4CXXcyfDyZD/8SueyvM8lqX/v5OYz6A4S6OWbNYKtb5zqO1PZwhdZHPb11dD1ELVGz 48AH7WOAJvtXNOGIyegmNIsGepDv2uu+/gHx6tnUOuR14/zY22Sp0GAy2GWg19UvFSgJ 33m9LOS/lQ/rCxtWqOL2UjWXNN/utEaTLtR99mRmq50rIOu0aWDas8JgW3ghKq4muhED hR/9ZYH/lShwRP7c4TGte1PitzAdBaBpiEh3UM7A2AWEL8PR1c0yDMBkTuiSUNIBX0y3 63aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=y/jtzVchtZAxjRd4Oe8jYGGE2z3R3ro98E+l6JqRWMA=; b=nWieZAgG++tIK8BY3KgOz14o8lJlhG4nR1NvqIq6HAENQNwRepBoXtpS6MEurjbG2c 0VfP77iGmv1uqXZpAPWTA276ilSeLP/2YlNen9Dd0m6Oypcfw2pmZ48uX3qFLdL1ixnT w6XpFeim+qMFfH8bLlHR3CYwZLKlI0eWlDLyGpbpNQz/scxCMcwJx/CgpcEH8CfaCl/V ui4R6XIkJ7vBeUCYrXOBpb7E75E9puS+HFZbqRFBlNSfyUBCJgV/8i8YVNlVzUSkkW2X LyxONg1fWR6WDj6JrZVivvIa87R3Gm1BveXtr6TIfTOeZoWRD1wWg9jZQxFSfMF1Um8W r1lw== X-Gm-Message-State: AIkVDXJ7+ZItuW/nql072oUAeDnXgCy3vMxf5gDWd55ygavQydmeJ72n56bEUyRSWBSJ0w== X-Received: by 10.99.117.8 with SMTP id q8mr9512474pgc.9.1484604244547; Mon, 16 Jan 2017 14:04:04 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id d69sm49940891pfd.11.2017.01.16.14.04.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 14:04:03 -0800 (PST) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Fernando Gont , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <64cfae99-3d70-25b7-09b1-a1d327c563bf@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 17 Jan 2017 11:04:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <64cfae99-3d70-25b7-09b1-a1d327c563bf@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:04:06 -0000 In line... On 17/01/2017 08:59, Fernando Gont wrote: > On 01/14/2017 04:49 PM, Brian E Carpenter wrote: >> A modest suggestion: >> >> OLD >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> >> NEW >> IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, consistent use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same length >> of Interface ID. In practice, this means that to guarantee interoperability >> of SLAAC, a fixed length of Interface ID is necessary. > > fixed as "all nodes on the link use the same IID length" or as in "a > hardcoded IID length, as the current 64 value"? > > If the former, I agree. If the later, I don't. You're right, that choice of word could be contradictory. I suggest s/fixed/consistent/. Brian > The 64-bit length seems > to have a lot to do with embedding MAC addresses (IIRC, the IID length > was something like 48, but then changed to 64 in response to EUI-64). > Certainly, if you generate IIDs by embedding some number which has > constraints (as a MAC address), you need a fixed length. OTOH, if you > select the IIDs from a stream of bits (as RFC7217 does), then you don't > care about the length (other than "as many bits as necessary such that > the host density is low, and hence collisions of IIDs are reduced). > > Thanks! > > Cheers, > From nobody Mon Jan 16 14:10: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 2213A12941D for ; Mon, 16 Jan 2017 14:10:19 -0800 (PST) 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 uoInQa9I8QlZ for ; Mon, 16 Jan 2017 14:10:17 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B57129438 for ; Mon, 16 Jan 2017 14:10:16 -0800 (PST) Received: from [192.168.3.100] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EC2948377F; Mon, 16 Jan 2017 23:10:13 +0100 (CET) Subject: Re: IID length text To: sarikaya@ieee.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Mon, 16 Jan 2017 19:09:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:10:19 -0000 On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: > On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont wrote: >> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>> wrote: >>>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit : >>>>> >>>>> A modest suggestion: >>>>> >>>>> OLD >>>>> For all unicast addresses, except those that start with the binary >>>>> value 000, Interface IDs are required to be 64 bits long. Background >>>>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >>>>> >>>>> NEW >>>>> IPv6 routing is based on prefixes of any valid length up to 128 >>>>> [BCP198]. >>>>> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >>>>> links. However, consistent use of Stateless Address Autoconfiguration >>>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the same >>>>> length >>>>> of Interface ID. In practice, this means that to guarantee >>>>> interoperability >>>>> of SLAAC, a fixed length of Interface ID is necessary. For all >>>>> currently >>>>> allocated unicast addresses, except those that start with the binary >>>>> value 000, that length is 64 bits. Note that this value is an arbitrary >>>>> choice and might be changed for some future allocation of unicast >>>>> address >>>>> space. Background on the 64 bit boundary in IPv6 addresses can be found >>>>> in [RFC7421]. >>>> >>>> >>>> I agree with the change suggestion. The new text and references are enough >>>> motivation to clarify that that 64bit limit is an arbitrary choice and might >>>> change in the future. >>>> >>> >>> 3GPP assigns 64 bit prefixes to each UE. >>> Extended Unique Identifiers defined are EUI-48 and EUI-64. >> >> What does a layer-2 EUI have to do with a layer-3 address? > > I don't know, you tell me :-) Answer: Nothing. The fact that we've been embedding layer-2 "addresses" into layer-3 addresses should not be taken as a reason for the two of them of having to do anything with each other. So, yes, the 64-bit IID length is, in reality, arbitrary. They could have been e.g. 32-bits or 48-bits (yes, multiples or 64 or 32 tend to be nicer) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 16 14:23: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 2C3F41296E8 for ; Mon, 16 Jan 2017 14:23:55 -0800 (PST) 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 a8Bech1BLiYB for ; Mon, 16 Jan 2017 14:23:52 -0800 (PST) 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 674BA1296F8 for ; Mon, 16 Jan 2017 14:23:51 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 194so18626507pgd.2 for ; Mon, 16 Jan 2017 14:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lxWB0ACjGqZy9Ajw28S28uYwR7hp3Jou5XhCWXoAO5E=; b=Brae8mjgzVOeQUUsZBZuObonxnM65zZL0c5NWfG9yU6AGIq73X9ckjQ5JRZ0tkG1Tt 3iAxDof7ygxjILE1IiyeoBbrUAKnww7XEdxTMcjQligY9MOT49ZdOA+RfieYicnjIi6M i9EDef9HMA2OK361rcWHydxx7B1qwy5rWBG4u+5La1BSwdpBrCgeF5SLFqyvP8sm8G0H 8F6SXySpYpYNq7RIiU9SaIpgAj7TEfy1ZbrWmiL/BCbZw8V97NTujxMqEvwNlenCQXgz fomA05h/UnWaNcHWRIe0U1FVc1pP2HaZRl6dMFlCXDC8Y7icNRs3v9kOj11tXCLnMueR mKUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=lxWB0ACjGqZy9Ajw28S28uYwR7hp3Jou5XhCWXoAO5E=; b=VqXKMQ6j7rfyiGoBUX+TVKmip91vN88pTEJHfIIFNusTW5ODU2RIqQAQU0qcAvRHwu DMBaCtbiptV5cDxuw09TrAjf13+6BIsIh5j1SysWNpMiYtUmnt0Tq7Et0ktR22DqlNvN M892faii7A7ySFZvbFbTPETFLkXwc+3NKN8nhc0LnrVGq591i669btMJflENvr/Nt03s ZuMKvNiBqGGLUQPBqWJCIBxsMGdJ157MqCXH3ocVsQPlQfNIVrgu5zDiNhQcahWoIMDx NOljdJFoaUJV5MTf2FaeVelQY7XHzF2mFscy6xSs1bfgtWbS0PdzjlJBvaqYkw0U8USC NNIA== X-Gm-Message-State: AIkVDXJEDoDek3MTXiqElZyxszc20MjQdlPl9ZXSuhu7zY7kAsu+MuBw9+MFsTXRvyPP+g== X-Received: by 10.84.214.150 with SMTP id j22mr13735217pli.23.1484605430915; Mon, 16 Jan 2017 14:23:50 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id z66sm26062866pfd.49.2017.01.16.14.23.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 14:23:50 -0800 (PST) Subject: Re: IID length text To: sarikaya@ieee.org, Alexandre Petrescu References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> Date: Tue, 17 Jan 2017 11:23:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 22:23:55 -0000 On 17/01/2017 09:42, Behcet Sarikaya wrote: > On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu > wrote: >> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>> >>> A modest suggestion: >>> >>> OLD >>> For all unicast addresses, except those that start with the binary= >>> value 000, Interface IDs are required to be 64 bits long. Backgro= und >>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]= =2E >>> >>> NEW >>> IPv6 routing is based on prefixes of any valid length up to 128 >>> [BCP198]. >>> For example, [RFC6164] standardises 127 bit prefixes on point-to-= point >>> links. However, consistent use of Stateless Address Autoconfigurat= ion >>> (SLAAC)[RFC4862] requires that all interfaces on a link use the sa= me >>> length >>> of Interface ID. In practice, this means that to guarantee >>> interoperability >>> of SLAAC, a fixed length of Interface ID is necessary. For all >>> currently >>> allocated unicast addresses, except those that start with the bina= ry >>> value 000, that length is 64 bits. Note that this value is an arbi= trary >>> choice and might be changed for some future allocation of unicast >>> address >>> space. Background on the 64 bit boundary in IPv6 addresses can be = found >>> in [RFC7421]. >> >> >> I agree with the change suggestion. The new text and references are e= nough >> motivation to clarify that that 64bit limit is an arbitrary choice and= might >> change in the future. >> >=20 > 3GPP assigns 64 bit prefixes to each UE. > Extended Unique Identifiers defined are EUI-48 and EUI-64. > I don't think 64 bit limit is that arbitrary? It's a parameter, which we happened to set initially to 48 and then changed to 64 because of FireWire. I don't know why 3GPP chose the same value. But indeed we (the IETF) chose it because of our now old-fashioned decision to copy Novell Netware by embedding layer 2 addresses in layer 3. A bad choice, as it turned out. The first two definitions of "arbitrary" in Merriam-Webster seem to fit, especially the second. "existing or coming about seemingly at random or by chance or as a capricious and unreasonable act of will" "based on or determined by individual preference or convenience rather than by necessity or the intrinsic nature of something" Regards Brian >=20 > Behcet >=20 >> Alex >> >>> >>> Regards >>> Brian >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > . >=20 From nobody Mon Jan 16 17:08: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 7673A1298D0 for ; Mon, 16 Jan 2017 17:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 eOeWivURLh0q for ; Mon, 16 Jan 2017 17:08:46 -0800 (PST) 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 D8A5312994F for ; Mon, 16 Jan 2017 17:08:45 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id k127so37889878vke.0 for ; Mon, 16 Jan 2017 17:08:45 -0800 (PST) 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=bfunVc9Iw7ub2GHEzCIxISw4bhfkVI2hJSVMRoujADQ=; b=QDyO+E6g7gzm+ObA14mzDI+354RkbiDMJTq5mE9x6zr3QulifDJwMHMUc1SZmQZuPD kqJE5AJaHtb0m+Lo2KRMdpsZhDoV53R58o3bImNmnBIK+IgMrjEoPF2ft/BqCoDYIdDB lQdxOFnCav2lt9o113e1yGoiMkMDWJQgpmDml7SqVgwhmSkQpzgvmOHaUNPTM642n8aR NfjHCkJjwBALEd7NA1+NBKiCp+e7wmH2BKiWdbaRPvmokvjZoqL7/cLvT6dUprqqt9mw 88M2tcN/Geo2yC+aJiIeV20s2er1Xi/dniND0hawZ+WNLy8MlYQOT3VmmA36HsfkgrlS rllg== 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=bfunVc9Iw7ub2GHEzCIxISw4bhfkVI2hJSVMRoujADQ=; b=OKg+LJIUFZMetSfM0Lz8IpI7OFQMnYqDTaEo2sRk1sTugEiZLH+NDmcDmEKIFUWSN7 wAiyI+OsT2CE0rW1Ux3BLiAX6q+m2D5FuADhdBW6IoR1N7xxof/2389rI4cyklv7WBtV X31cxgqcAFogyYDmU2CYeCf4C47ZDllTj/zJFvoseH6c7ZRoaaMBnuNNH89Pj0cyUHOJ cZDRHMzBobrW9ciM0pjbJ9JvfFBYvJwyHXthMKB/m1me/If/B/u343b71DfQgAn/QNiM yC+6YjbMQ9wkMIoK+XXBdTVOGHdHVFTlN5zrs511JZxw2aYLJT8b0HYsir19l8UqM/xz Kl+g== X-Gm-Message-State: AIkVDXJwejRl+gu8fAmIXGzPl9b1WFok14ptHSl3o58zhAnTTrkgY920dRk1j8QiF/j6fthW8NDbflN3Wsh2RuYx X-Received: by 10.31.88.1 with SMTP id m1mr17685637vkb.83.1484615324741; Mon, 16 Jan 2017 17:08:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 17:08:24 -0800 (PST) In-Reply-To: <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Lorenzo Colitti Date: Tue, 17 Jan 2017 10:08:24 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114e53640f7ed505463ff1c4 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:08:47 -0000 --001a114e53640f7ed505463ff1c4 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > what's the specific rationale for this change? Is it a bug in 4291 which > > you're proposing that we resolve in 4291 bis? If so, what is the bug? > > The bug is that in SLAAC, the IID length is a parameter, not a constant, > and that in routing protocols, the prefix length is a parameter, not > a constant. The addressing architecture needs to recognise that. > There is no bug here. What that text in 4291 says is that if you run SLAAC on a Global Unicast address not starting with ::/3, then the length of the IID is 64. But when running SLAAC on non-Global Unicast addresses, or Global Unicast addresses in ::/3, then the length of the IID is not specified in RFC 4291 (and presumably left up to the IPv6-over-foo documents). That is why, for example, RFC 2464 has to say that on Ethernet, the link-local address "is formed by appending the Interface Identifier [...] to the prefix FE80::/64". It also says that the IID length is always 64 bits and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the IID length were always 64 bits there would be no need to say that. Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to the addressing architecture, not the other way around. But that is not in any way necessary to resolve a conflict between the two documents, because there is no conflict. > BTW: if the reason for the text is a perceived contradiction between the > > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all > > bit lengths" - I don't see a contradiction. > > I suggest discussing that with Randy Bush. > While Randy's "I want to use smaller subnets than /64 because classful addressing is stupid" is a valid position, that does not mean that there is a contradiction between the two specifications. So again - what is the text trying to accomplish? I don't see a bug in the specs. Therefore, it seems to me that the proposed text is changing the IPv6 architecture in a pretty fundamental way, and I don't think it's reasonable to do that at the same time that we elevate it to full standard. --001a114e53640f7ed505463ff1c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
> what's the specific rationale for this change? Is it a bug in = 4291 which
> you're proposing that we resolve in 4291 bis? If so, what is the b= ug?

The bug is that in SLAAC, the IID length is a parameter, not a const= ant,
and that in routing protocols, the prefix length is a parameter, not
a constant. The addressing architecture needs to recognise that.

There is no bug here.

Wh= at that text in 4291 says is that if you run SLAAC on a Global Unicast addr= ess not starting with ::/3, then the length of the IID is 64. But when runn= ing SLAAC on non-Global Unicast addresses, or Global Unicast addresses in := :/3, then the length of the IID is not specified in RFC 4291 (and presumabl= y left up to the IPv6-over-foo documents).

That is= why, for example, RFC 2464 has to say that on Ethernet, the link-local add= ress "is formed by appending the Interface Identifier [...] to the pre= fix FE80::/64". It also says that the IID length is always 64 bits and= SLAAC prefixes must be /64. If IPv6 all addresses were classful and the II= D length were always 64 bits there would be no need to say that.
=
Also, I'd argue that SLAAC exists to generate IPv6 addre= sses that conform to the addressing architecture, not the other way around.= But that is not in any way necessary to resolve a conflict between the two= documents, because there is no conflict.

> BTW: if the reason for the text is a perc= eived contradiction between the
> fact that "IIDs are 64 bits" and "IPv6 addresses are ag= gregatable on all
> bit lengths" - I don't see a contradiction.

I suggest discussing that with Randy Bush.

=
While Randy's "I want to use smaller subnets than /64 b= ecause classful addressing is stupid" is a valid position, that does n= ot mean that there is a contradiction between the two specifications.
=

So again - what is the text trying to accomplish? I don= 't see a bug in the specs. Therefore, it seems to me that the proposed = text is changing the IPv6 architecture in a pretty fundamental way, and I d= on't think it's reasonable to do that at the same time that we elev= ate it to full standard.
--001a114e53640f7ed505463ff1c4-- From nobody Mon Jan 16 17:10: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 A00C5129954 for ; Mon, 16 Jan 2017 17:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 1OC0MBqrkjR6 for ; Mon, 16 Jan 2017 17:10:25 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F33112994F for ; Mon, 16 Jan 2017 17:10:25 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id x75so83553029vke.2 for ; Mon, 16 Jan 2017 17:10:25 -0800 (PST) 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=3rPHtBaLTpPCh4xhUZET3I49OkY7jj0mI1XCTtlAMuk=; b=M7QL8Z/T8OT50spzFfMKxTEbV/lKIwpO28ivkI/HxR3stSF2hekFGdB5o0qo5FiG7o 6IUVINpfStduGgqU1pfJ5LrwtHWi0oJTpLVvsafGkTJLpNT2XZFnp6wPf4rE5PSLtRhG oxvKI7bp7HwcFZc9h6fUHWieW8Yso20J5mANuHlgyRntxPEbsryXPBpCkKoQeBXoP8vY VgyqYHytDe2H7suCyJe3ZZ5S5sxlNwBzdSLPG+k61z8S8aLcpzoPRDZwz1MyXG8mSTzE z5j+lhobEpNyjwNqHWvOB5lJDu3JeGiAOC0Enw51STW26ygG8BsvOUXrnG3iHg5tlo67 4FLw== 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=3rPHtBaLTpPCh4xhUZET3I49OkY7jj0mI1XCTtlAMuk=; b=lgX5HZB3sIdFoKO4Ht712YifhPzPyOsY1mzlsWG34D5WTc7650gooYxtDa5kLKb3wm Tj/p2NCOmXuY4/Uig41wNwsnXfoMrcF2wpyEhXGdLiVE2dXblEM55xNlZv/W/9mvnZnb CHcRiKx6H0gWoCOEIoFfCiuJMNX9y9CRHUJ8AHZGFSY2dlfKF3+dnEDiwjuFksXa79i0 SWNdRy+0YyvbAo4BM1FBqlSwdXoM93IycXTNFb3AiWYOBy+9hXaRHejZQXuJ0GrNKLaM s3dGRBI+PYSEvnz0FZEElJ0Xeolx4//iGuZowi6rn70PMhPkE8qnMsQ8lFg+WDYuMUjd uHVw== X-Gm-Message-State: AIkVDXL32X6ouGcO8DtD3O7cW5n5dG2D/HVj+He33Ue626O4S7NvE18JTVNHDqhNWz5UuJ6Y57apACtbupMZVt5j X-Received: by 10.31.170.15 with SMTP id t15mr2427395vke.6.1484615424553; Mon, 16 Jan 2017 17:10:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 17:10:03 -0800 (PST) In-Reply-To: <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> From: Lorenzo Colitti Date: Tue, 17 Jan 2017 10:10:03 +0900 Message-ID: Subject: Re: IID length text To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11432250027b0305463ff701 Archived-At: Cc: 6man , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:10:27 -0000 --001a11432250027b0305463ff701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yep. It's an arbitrary choice, just like the choice to make IPv6 addresses 128 bits long, or the choice to make the header 40 bytes long. That doesn't mean we should change it. On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 17/01/2017 09:42, Behcet Sarikaya wrote: > > On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu > > wrote: > >> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : > >>> > >>> A modest suggestion: > >>> > >>> OLD > >>> For all unicast addresses, except those that start with the binary > >>> value 000, Interface IDs are required to be 64 bits long. > Background > >>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]= . > >>> > >>> NEW > >>> IPv6 routing is based on prefixes of any valid length up to 128 > >>> [BCP198]. > >>> For example, [RFC6164] standardises 127 bit prefixes on > point-to-point > >>> links. However, consistent use of Stateless Address > Autoconfiguration > >>> (SLAAC)[RFC4862] requires that all interfaces on a link use the sa= me > >>> length > >>> of Interface ID. In practice, this means that to guarantee > >>> interoperability > >>> of SLAAC, a fixed length of Interface ID is necessary. For all > >>> currently > >>> allocated unicast addresses, except those that start with the bina= ry > >>> value 000, that length is 64 bits. Note that this value is an > arbitrary > >>> choice and might be changed for some future allocation of unicast > >>> address > >>> space. Background on the 64 bit boundary in IPv6 addresses can be > found > >>> in [RFC7421]. > >> > >> > >> I agree with the change suggestion. The new text and references are > enough > >> motivation to clarify that that 64bit limit is an arbitrary choice and > might > >> change in the future. > >> > > > > 3GPP assigns 64 bit prefixes to each UE. > > Extended Unique Identifiers defined are EUI-48 and EUI-64. > > I don't think 64 bit limit is that arbitrary? > > It's a parameter, which we happened to set initially to 48 > and then changed to 64 because of FireWire. I don't know > why 3GPP chose the same value. But indeed we (the IETF) chose > it because of our now old-fashioned decision to copy Novell > Netware by embedding layer 2 addresses in layer 3. A bad > choice, as it turned out. > > The first two definitions of "arbitrary" in Merriam-Webster seem > to fit, especially the second. > > "existing or coming about seemingly at random or by chance > or as a capricious and unreasonable act of will" > "based on or determined by individual preference or convenience > rather than by necessity or the intrinsic nature of something" > > Regards > Brian > > > > > Behcet > > > >> Alex > >> > >>> > >>> Regards > >>> Brian > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >>> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > . > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11432250027b0305463ff701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yep. It's an arbitrary choice, just like the choice to= make IPv6 addresses 128 bits long, or the choice to make the header 40 byt= es long. That doesn't mean we should change it.

On Tue, Jan 17, 2017 at 7:23 AM, Br= ian E Carpenter <brian.e.carpenter@gmail.com> wrot= e:
On 17/01/2017 09:42, Behcet Sarikaya wrote:
> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
> <alexandru.petrescu= @gmail.com> wrote:
>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit :
>>>
>>> A modest suggestion:
>>>
>>> OLD
>>>=C2=A0 =C2=A0 For all unicast addresses, except those that star= t with the binary
>>>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bi= ts long.=C2=A0 Background
>>>=C2=A0 =C2=A0 on the 64 bit boundary in IPv6 addresses can be f= ound in [RFC7421].
>>>
>>> NEW
>>>=C2=A0 =C2=A0 IPv6 routing is based on prefixes of any valid le= ngth up to 128
>>> [BCP198].
>>>=C2=A0 =C2=A0 For example, [RFC6164] standardises 127 bit=C2=A0= prefixes on point-to-point
>>>=C2=A0 =C2=A0 links. However, consistent use of Stateless Addre= ss Autoconfiguration
>>>=C2=A0 =C2=A0 (SLAAC)[RFC4862] requires that all interfaces on = a link use the same
>>> length
>>>=C2=A0 =C2=A0 of Interface ID. In practice, this means that to = guarantee
>>> interoperability
>>>=C2=A0 =C2=A0 of SLAAC, a fixed length of Interface ID is neces= sary. For all
>>> currently
>>>=C2=A0 =C2=A0 allocated unicast addresses, except those that st= art with the binary
>>>=C2=A0 =C2=A0 value 000, that length is 64 bits. Note that this= value is an arbitrary
>>>=C2=A0 =C2=A0 choice and might be changed for some future alloc= ation of unicast
>>> address
>>>=C2=A0 =C2=A0 space. Background on the 64 bit boundary in IPv6 = addresses can be found
>>>=C2=A0 =C2=A0 in [RFC7421].
>>
>>
>> I agree with the change suggestion.=C2=A0 The new text and referen= ces are enough
>> motivation to clarify that that 64bit limit is an arbitrary choice= and might
>> change in the future.
>>
>
> 3GPP assigns 64 bit prefixes to each UE.
> Extended Unique Identifiers defined are EUI-48 and EUI-64.
> I don't think 64 bit limit is that arbitrary?

It's a parameter, which we happened to set initially to 48<= br> and then changed to 64 because of FireWire. I don't know
why 3GPP chose the same value. But indeed we (the IETF) chose
it because of our now old-fashioned decision to copy Novell
Netware by embedding layer 2 addresses in layer 3. A bad
choice, as it turned out.

The first two definitions of "arbitrary" in Merriam-Webster seem<= br> to fit, especially the second.

"existing or coming about seemingly at random or by chance
or as a capricious and unreasonable act of will"
"based on or determined by individual preference or convenience
rather than by necessity or the intrinsic nature of something"

Regards
=C2=A0 =C2=A0 Brian

>
> Behcet
>
>> Alex
>>
>>>
>>> Regards
>>>=C2=A0 =C2=A0 Brian
>>>
>>> ---------------------------------------------------------= -----------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org= /mailman/listinfo/ipv6
>>> ---------------------------------------------------------= -----------
>>>
>>
>> ------------------------------------------------------------<= wbr>--------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------<= wbr>--------
>>
> .
>

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

--001a11432250027b0305463ff701-- From nobody Mon Jan 16 17:36: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 4213E129958 for ; Mon, 16 Jan 2017 17:36:26 -0800 (PST) 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 T1zRoTEBNlaP for ; Mon, 16 Jan 2017 17:36:24 -0800 (PST) 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 5C7D9129695 for ; Mon, 16 Jan 2017 17:36:24 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id 194so19805757pgd.2 for ; Mon, 16 Jan 2017 17:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nT5FBbdTDSAoM6e+UficT6PLkqCLCrn//QvsKeG47zk=; b=tvf0FU1t//3ADm4H8Kyn41vdI0L65CQNH58RFLeNx35GObi4woGlXpPUpG5WBbVQ7R uJJrvhe2T4MNUdpOPa/MfBM2NwwvLAcRiTeklwKCnLmAaiLr0CMXQDPNXVzELqhU7v1p vyCw9L08OkLSvAADY++GOVQ955GmDZkrKFxXJsLUD2eTGbUNRl4IhjdKDFrmszyZ/p9d Al4r60RKHpgYDsIirTKVsqQfcZNtnLrDcMkMfQcN2B02fOr/zrJzqq6PPTDqFa54LbPY qsJRiwB0HsMTZxoLOeWeJeaGCc5Y/nbEf35dabOmxCebr0DehWOTUl0odB+EOgn7ZbAS 6SEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nT5FBbdTDSAoM6e+UficT6PLkqCLCrn//QvsKeG47zk=; b=gbDBzy3y9pEIFaKGjtmS6lCJR3kd6gYpHOfVKgeJ1GPhF9ns+OE2khSMEvCqa3Vq6d guGeVZhkj9igb9tYP+J95uI6GsRs5vd/WKIWPvQpocsr4E7zeB0q1qPd54qb3t5mjly+ rh75WOruFiKazThOUxtHBOtmSKvC8CRQr6b1l8IogCCBHalg7wsmN0mtqToP2XjqlMhT c06rtCUvAnXaU1jISccJaqQkVbxQRMnBtIlbAVSz+O2Y1D/WUrQX9fIg/r45qE6L1VcL AeWm1w+zziSN4R5hazhFf+s6GtgIDhdN24zvIX4hBn39OfUx3n5RVuHonDrAH3B9Nxj5 uVDA== X-Gm-Message-State: AIkVDXKXc4t8aI1SceTKj46nwHlyAw96YdJvyMnt9kqVS+slng2yRBkszxLBqWD1i8DJEg== X-Received: by 10.98.200.207 with SMTP id i76mr40233584pfk.38.1484616983890; Mon, 16 Jan 2017 17:36:23 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id p67sm50493381pfb.2.2017.01.16.17.36.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 17:36:23 -0800 (PST) Subject: Re: IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 17 Jan 2017 14:36:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:36:26 -0000 Nobody is saying we should change it in the foreseeable future. As for the unforeseeable future, I don't know ;-) Brian On 17/01/2017 14:10, Lorenzo Colitti wrote: > Yep. It's an arbitrary choice, just like the choice to make IPv6 addres= ses > 128 bits long, or the choice to make the header 40 bytes long. That doe= sn't > mean we should change it. >=20 > On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 17/01/2017 09:42, Behcet Sarikaya wrote: >>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>> wrote: >>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>>> >>>>> A modest suggestion: >>>>> >>>>> OLD >>>>> For all unicast addresses, except those that start with the bina= ry >>>>> value 000, Interface IDs are required to be 64 bits long. >> Background >>>>> on the 64 bit boundary in IPv6 addresses can be found in [RFC742= 1]. >>>>> >>>>> NEW >>>>> IPv6 routing is based on prefixes of any valid length up to 128 >>>>> [BCP198]. >>>>> For example, [RFC6164] standardises 127 bit prefixes on >> point-to-point >>>>> links. However, consistent use of Stateless Address >> Autoconfiguration >>>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the = same >>>>> length >>>>> of Interface ID. In practice, this means that to guarantee >>>>> interoperability >>>>> of SLAAC, a fixed length of Interface ID is necessary. For all >>>>> currently >>>>> allocated unicast addresses, except those that start with the bi= nary >>>>> value 000, that length is 64 bits. Note that this value is an >> arbitrary >>>>> choice and might be changed for some future allocation of unicas= t >>>>> address >>>>> space. Background on the 64 bit boundary in IPv6 addresses can b= e >> found >>>>> in [RFC7421]. >>>> >>>> >>>> I agree with the change suggestion. The new text and references are= >> enough >>>> motivation to clarify that that 64bit limit is an arbitrary choice a= nd >> might >>>> change in the future. >>>> >>> >>> 3GPP assigns 64 bit prefixes to each UE. >>> Extended Unique Identifiers defined are EUI-48 and EUI-64. >>> I don't think 64 bit limit is that arbitrary? >> >> It's a parameter, which we happened to set initially to 48 >> and then changed to 64 because of FireWire. I don't know >> why 3GPP chose the same value. But indeed we (the IETF) chose >> it because of our now old-fashioned decision to copy Novell >> Netware by embedding layer 2 addresses in layer 3. A bad >> choice, as it turned out. >> >> The first two definitions of "arbitrary" in Merriam-Webster seem >> to fit, especially the second. >> >> "existing or coming about seemingly at random or by chance >> or as a capricious and unreasonable act of will" >> "based on or determined by individual preference or convenience >> rather than by necessity or the intrinsic nature of something" >> >> Regards >> Brian >> >>> >>> Behcet >>> >>>> Alex >>>> >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> -------------------------------------------------------------------= - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6= >>>>> -------------------------------------------------------------------= - >>>>> >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>>> >>> . >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 From nobody Mon Jan 16 17:44: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 89BD3129952 for ; Mon, 16 Jan 2017 17:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 U7J-L-wtzFfb for ; Mon, 16 Jan 2017 17:44:22 -0800 (PST) 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 529CD1289B0 for ; Mon, 16 Jan 2017 17:44:22 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id t8so83739657vke.3 for ; Mon, 16 Jan 2017 17:44:22 -0800 (PST) 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=tA9K2v43HJunVxVijzJ5PrxVyPP4kdctNNK/Mi0BZmM=; b=q3+TwPEHgrwhMYriBgYZNto3G2XL2KkwBIgSaS3fXy/rvOyEQFdANpc87APJGESf0Z Y0UehHhVI+zxFqdd2mkb1NX9m0Lbk++rEeSAPlSh9j8y5M/imRmC1y19388j6GwHXCmy wHW7WqEYQIqe5ISxGKqNfQN8s6RmcPK+8E0lQHfByJke32O/BnVy2JA+NetXcamB7UDJ xKYgH4TQCPnA2xeJ4ma/kkquSp0mvmj0Z8aa8bZXprMWLKWXl4WNulwBV+umCvSd3WbK HzlKP3ifFpGyYsaylroxNjtNgZI2xvDWJoYxdnsFZfZ+dIieulmQiMaevSMI3fr4Kg5u FWdg== 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=tA9K2v43HJunVxVijzJ5PrxVyPP4kdctNNK/Mi0BZmM=; b=DO35fbGAD+090pGmA4TdY5GETUcbVNrDLDroW2VZy1jQ6TQWefhtSWXqFhW7DBuo+C aQVnGcYMfdYGlG/oN28J9xe25v/K6fEzOHUEdyJJPpl+85YduXpU4BZH1OqUDa2lmvNi Fj8irt/xX9wXqp7or1u98rzC829jdq+nqxD4M2pUFomGC9EcAFdy3ROX1gWdCs/Hp65H SsdsPdvIc/QySYpvPgBEVpVWzqckQIQrbFtjsyumv6Iydf43GrMIaiVx8S6iFOyF5dmA gwoInDB1Rnu/jNlshi4lLheKSykpCA53pgQl68xdjwKIfvQAmoOXDPtbggwwakp1I+oH DK2g== X-Gm-Message-State: AIkVDXLOt9JWyJw9K6/2OtoZryI5JUj7pmacyAlwOb3FIcWqMcJ8EET0EfvJX97nv+uJyhGaYbs8zBK+If7/V/Br X-Received: by 10.31.227.130 with SMTP id a124mr14007531vkh.45.1484617461320; Mon, 16 Jan 2017 17:44:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 17:44:00 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> From: Lorenzo Colitti Date: Tue, 17 Jan 2017 10:44:00 +0900 Message-ID: Subject: Re: IID length text To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114df632691ae90546407037 Archived-At: Cc: 6man , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 01:44:24 -0000 --001a114df632691ae90546407037 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But your text does change this arbitrary choice, by removing it. On Tue, Jan 17, 2017 at 10:36 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Nobody is saying we should change it in the foreseeable future. > As for the unforeseeable future, I don't know ;-) > > Brian > > On 17/01/2017 14:10, Lorenzo Colitti wrote: > > Yep. It's an arbitrary choice, just like the choice to make IPv6 > addresses > > 128 bits long, or the choice to make the header 40 bytes long. That > doesn't > > mean we should change it. > > > > On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 17/01/2017 09:42, Behcet Sarikaya wrote: > >>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu > >>> wrote: > >>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : > >>>>> > >>>>> A modest suggestion: > >>>>> > >>>>> OLD > >>>>> For all unicast addresses, except those that start with the bina= ry > >>>>> value 000, Interface IDs are required to be 64 bits long. > >> Background > >>>>> on the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. > >>>>> > >>>>> NEW > >>>>> IPv6 routing is based on prefixes of any valid length up to 128 > >>>>> [BCP198]. > >>>>> For example, [RFC6164] standardises 127 bit prefixes on > >> point-to-point > >>>>> links. However, consistent use of Stateless Address > >> Autoconfiguration > >>>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the > same > >>>>> length > >>>>> of Interface ID. In practice, this means that to guarantee > >>>>> interoperability > >>>>> of SLAAC, a fixed length of Interface ID is necessary. For all > >>>>> currently > >>>>> allocated unicast addresses, except those that start with the > binary > >>>>> value 000, that length is 64 bits. Note that this value is an > >> arbitrary > >>>>> choice and might be changed for some future allocation of unicas= t > >>>>> address > >>>>> space. Background on the 64 bit boundary in IPv6 addresses can b= e > >> found > >>>>> in [RFC7421]. > >>>> > >>>> > >>>> I agree with the change suggestion. The new text and references are > >> enough > >>>> motivation to clarify that that 64bit limit is an arbitrary choice a= nd > >> might > >>>> change in the future. > >>>> > >>> > >>> 3GPP assigns 64 bit prefixes to each UE. > >>> Extended Unique Identifiers defined are EUI-48 and EUI-64. > >>> I don't think 64 bit limit is that arbitrary? > >> > >> It's a parameter, which we happened to set initially to 48 > >> and then changed to 64 because of FireWire. I don't know > >> why 3GPP chose the same value. But indeed we (the IETF) chose > >> it because of our now old-fashioned decision to copy Novell > >> Netware by embedding layer 2 addresses in layer 3. A bad > >> choice, as it turned out. > >> > >> The first two definitions of "arbitrary" in Merriam-Webster seem > >> to fit, especially the second. > >> > >> "existing or coming about seemingly at random or by chance > >> or as a capricious and unreasonable act of will" > >> "based on or determined by individual preference or convenience > >> rather than by necessity or the intrinsic nature of something" > >> > >> Regards > >> Brian > >> > >>> > >>> Behcet > >>> > >>>> Alex > >>>> > >>>>> > >>>>> Regards > >>>>> Brian > >>>>> > >>>>> -------------------------------------------------------------------= - > >>>>> IETF IPv6 working group mailing list > >>>>> ipv6@ietf.org > >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>>> -------------------------------------------------------------------= - > >>>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>>> > >>> . > >>> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > --001a114df632691ae90546407037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But your text does change this arbitrary choice, by removi= ng it.

On Tu= e, Jan 17, 2017 at 10:36 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
Nobody = is saying we should change it in the foreseeable future.
As for the unforeseeable future, I don't know ;-)

=C2=A0 =C2=A0 Brian

On 17/01/2017 14:10, Lorenzo Colitti wrote:
> Yep. It's an arbitrary choice, just like the choice to make IPv6 a= ddresses
> 128 bits long, or the choice to make the header 40 bytes long. That do= esn't
> mean we should change it.
>
> On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> On 17/01/2017 09:42, Behcet Sarikaya wrote:
>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
>>> <alexandru.= petrescu@gmail.com> wrote:
>>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit= :
>>>>>
>>>>> A modest suggestion:
>>>>>
>>>>> OLD
>>>>>=C2=A0 =C2=A0 For all unicast addresses, except those t= hat start with the binary
>>>>>=C2=A0 =C2=A0 value 000, Interface IDs are required to = be 64 bits long.
>> Background
>>>>>=C2=A0 =C2=A0 on the 64 bit boundary in IPv6 addresses = can be found in [RFC7421].
>>>>>
>>>>> NEW
>>>>>=C2=A0 =C2=A0 IPv6 routing is based on prefixes of any = valid length up to 128
>>>>> [BCP198].
>>>>>=C2=A0 =C2=A0 For example, [RFC6164] standardises 127 b= it=C2=A0 prefixes on
>> point-to-point
>>>>>=C2=A0 =C2=A0 links. However, consistent use of Statele= ss Address
>> Autoconfiguration
>>>>>=C2=A0 =C2=A0 (SLAAC)[RFC4862] requires that all interf= aces on a link use the same
>>>>> length
>>>>>=C2=A0 =C2=A0 of Interface ID. In practice, this means = that to guarantee
>>>>> interoperability
>>>>>=C2=A0 =C2=A0 of SLAAC, a fixed length of Interface ID = is necessary. For all
>>>>> currently
>>>>>=C2=A0 =C2=A0 allocated unicast addresses, except those= that start with the binary
>>>>>=C2=A0 =C2=A0 value 000, that length is 64 bits. Note t= hat this value is an
>> arbitrary
>>>>>=C2=A0 =C2=A0 choice and might be changed for some futu= re allocation of unicast
>>>>> address
>>>>>=C2=A0 =C2=A0 space. Background on the 64 bit boundary = in IPv6 addresses can be
>> found
>>>>>=C2=A0 =C2=A0 in [RFC7421].
>>>>
>>>>
>>>> I agree with the change suggestion.=C2=A0 The new text and= references are
>> enough
>>>> motivation to clarify that that 64bit limit is an arbitrar= y choice and
>> might
>>>> change in the future.
>>>>
>>>
>>> 3GPP assigns 64 bit prefixes to each UE.
>>> Extended Unique Identifiers defined are EUI-48 and EUI-64.
>>> I don't think 64 bit limit is that arbitrary?
>>
>> It's a parameter, which we happened to set initially to 48
>> and then changed to 64 because of FireWire. I don't know
>> why 3GPP chose the same value. But indeed we (the IETF) chose
>> it because of our now old-fashioned decision to copy Novell
>> Netware by embedding layer 2 addresses in layer 3. A bad
>> choice, as it turned out.
>>
>> The first two definitions of "arbitrary" in Merriam-Webs= ter seem
>> to fit, especially the second.
>>
>> "existing or coming about seemingly at random or by chance >> or as a capricious and unreasonable act of will"
>> "based on or determined by individual preference or convenien= ce
>> rather than by necessity or the intrinsic nature of something"= ;
>>
>> Regards
>>=C2=A0 =C2=A0 =C2=A0Brian
>>
>>>
>>> Behcet
>>>
>>>> Alex
>>>>
>>>>>
>>>>> Regards
>>>>>=C2=A0 =C2=A0 Brian
>>>>>
>>>>> -------------------------------------------------= -------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.= ietf.org/mailman/listinfo/ipv6
>>>>> -------------------------------------------------= -------------------
>>>>>
>>>>
>>>> -----------------------------------------------------= ---------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf= .org/mailman/listinfo/ipv6
>>>> -----------------------------------------------------= ---------------
>>>>
>>> .
>>>
>>
>> ------------------------------------------------------------<= wbr>--------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------<= wbr>--------
>>
>


--001a114df632691ae90546407037-- From nobody Mon Jan 16 18:19: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 05D2B129438 for ; Mon, 16 Jan 2017 18:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 2e9iElC33rLl for ; Mon, 16 Jan 2017 18:19:03 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8704A129411 for ; Mon, 16 Jan 2017 18:19:02 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c85so181531118wmi.1 for ; Mon, 16 Jan 2017 18:19:02 -0800 (PST) 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=yWVjaQ6xvgVd/Ew5qomGcY5crZ0h6arEkweohWeQI+c=; b=eUUFrUGzKWSiCWKm/4P0PhFoRKERaA9G0LimD6pxW8wUa/OtqBdxhQBBmPZY8t+OGj ZxQweeuUqxwyisJsYuDhw+irzQKEYLOgT8RbEvR06ZiRoRfKAHpsZGX9eAhCDeAGNpiW +8nT2U/r36W144umTFNJmd81gNpfrf+prfopDBc/+go6xg03PaT0OVpb/3e7Ye9mhqdj Y2VcFfrGrAMgSXREw3m8QWJaHmGnWUSb5m/0W/ix2Hr/uyCDEKOYsnx1WjVnMFsgUXfZ vURTiBeqrAjS70lFHZMjJ9ThaXKZGfwqNUEfL9ldvkQLpGhIhgoGlsM3wZUtyD75rRTL +coA== 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=yWVjaQ6xvgVd/Ew5qomGcY5crZ0h6arEkweohWeQI+c=; b=iXOjzkKAzb/BR0JcjJcgHk2vMA3kb0x5ANwqGyVC1QQZDznXHQPsX4D3/6BvP60ccc GS1GC+egUpSV2Zqah22j/oiCClYrJa3XjFJogkQJyucEUfagbH9g66tHGp3CO5Mq/Q6x qLof/BaVAZWzK77A02knqIawEkdSygejlYXB/cujfqOqh5r9o+V25UbjMO7jZLbOg28J BgJSjEPfv9l3ER/uSDuWnSUfM/5HzvN6L7KkFFCeDitsaAwGELIPqIdlNiDdaapwRXB+ ug1OqwRCtRb3VV3LLqBmKBZZco8yL6enQULy5uOuB7ufB2Nhdo4e/iP3nunVoQ0+d4j3 oSdg== X-Gm-Message-State: AIkVDXILSSMI7FXRl71MwHt5d3V8uts0eQ2ZoUxAyoO3eKJTVxM0pvQxCe2o3xhBejUYPfB7W5N1MSwnMA9rGnJI X-Received: by 10.28.157.201 with SMTP id g192mr13290865wme.29.1484619540802; Mon, 16 Jan 2017 18:19:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 18:18:40 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Erik Kline Date: Tue, 17 Jan 2017 11:18:40 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Lorenzo Colitti Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b314c619cce054640ec7c" Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 02:19:05 -0000 --001a114b314c619cce054640ec7c Content-Type: text/plain; charset=UTF-8 On 17 January 2017 at 10:08, Lorenzo Colitti wrote: > On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter > wrote: >> >> > what's the specific rationale for this change? Is it a bug in 4291 which >> > you're proposing that we resolve in 4291 bis? If so, what is the bug? >> >> The bug is that in SLAAC, the IID length is a parameter, not a constant, >> and that in routing protocols, the prefix length is a parameter, not >> a constant. The addressing architecture needs to recognise that. > > > There is no bug here. > > What that text in 4291 says is that if you run SLAAC on a Global Unicast > address not starting with ::/3, then the length of the IID is 64. But when > running SLAAC on non-Global Unicast addresses, or Global Unicast addresses > in ::/3, then the length of the IID is not specified in RFC 4291 (and > presumably left up to the IPv6-over-foo documents). > > That is why, for example, RFC 2464 has to say that on Ethernet, the > link-local address "is formed by appending the Interface Identifier [...] to > the prefix FE80::/64". It also says that the IID length is always 64 bits > and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the > IID length were always 64 bits there would be no need to say that. > > Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to > the addressing architecture, not the other way around. But that is not in > any way necessary to resolve a conflict between the two documents, because > there is no conflict. > >> > BTW: if the reason for the text is a perceived contradiction between the >> > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all >> > bit lengths" - I don't see a contradiction. >> >> I suggest discussing that with Randy Bush. > > > While Randy's "I want to use smaller subnets than /64 because classful > addressing is stupid" is a valid position, that does not mean that there is > a contradiction between the two specifications. > > So again - what is the text trying to accomplish? I don't see a bug in the > specs. Therefore, it seems to me that the proposed text is changing the IPv6 > architecture in a pretty fundamental way, and I don't think it's reasonable > to do that at the same time that we elevate it to full standard. I would tend to agree. --001a114b314c619cce054640ec7c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgsc5uadUSaOYcdazUcatv3QsXW7HOmoQO fj/i/N76go8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTE3 MDIxOTAxWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAI20jLAOCqcUBPliGJw1NJ0n7tgu4M6H0elGPUsNrwAPCRteow7v CI0Ii5P0PcaJTHmijST3cUy5bVUFDeEIl6OML57BlDqD6sT9P2u6e5IxYOB0+44mpE/qOK4zT5Qo 9GKus2kbRj/FUyMCY4LH3r9vu8tk3IjFRV5253eSmiAbFKzh4kOTVbtgyIHuAfcm0aQJoH3kBpqZ wet+wwsLHHGXYI3FBmZaUc8jvvqwFY8loiX6mT/yb0lshTV3tPeKrl7T5Ym2cfKjy5AEFfe5qCB2 qc/ykU9c75gRHixdbSiOIf3N9pcLljYzKuswRzSY1/D/otcXnLC/u7jhgkqAHHM= --001a114b314c619cce054640ec7c-- From nobody Mon Jan 16 18:33: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 359A9129434 for ; Mon, 16 Jan 2017 18:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGrGY4KkxAza for ; Mon, 16 Jan 2017 18:33:10 -0800 (PST) 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 5D2D9129411 for ; Mon, 16 Jan 2017 18:33:10 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 189so57854814pfu.3 for ; Mon, 16 Jan 2017 18:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N/p5XI5wnx0jjL76g4GaDdVLu81BSFBEBEmhX0Qg52o=; b=DjzeOrOBKKDAGkuP1LE+S6kpFf2ROWxwRGRtC7SdFJP6nLKiWws3RJy8cv6/b3Hmjk /6XviqjtYbygFAZj1ggOR75Wmc6+tTTQZjZa4Oh8bq0EJsaJrgSqLZHvvBft95zEk/HP EmO+oTLwLhaZScjJhZ79nt8oJO2ZjfBjG9YGyYm8zC+lKYSa9WwNo2Mft6oM7ezK4Ryf jrW67VYtW9t/BRJhv2fnvnKw2IDzyUAAIFyGDTvo8PBIBgfMgbChyJmXkQAcLVigh3Ga WDSZoacXMuTBad3+1PlK8eLR/WncoLGePnIgPqgWNi87NE0IacwZAeDu7lRkUFuvTaXP Zm6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=N/p5XI5wnx0jjL76g4GaDdVLu81BSFBEBEmhX0Qg52o=; b=cVKeM6BD8wiQRo4n6qM2YGUyi2NTdBIPArhDz0Oxkx54FSL93dNrs7X/nioEpPup5b 9f9FgQwOSLvyg2tAQKQt6mElKX1yMsvUEw95NfYUMgNztEJHx/+Qh6wo9k8vURYwffvN gx8o3nk8diORPDfQAIlajpKgRFx5JixWrXnZFoNbPxl4ITAedYwZI2uy/mJLySb15uWS 0gEcQZWiCRZ24qAwjZWjxvEiKdfVNtZZUPp76D7Fj6WP4h77iZMLJf8sc+m+pMJFzLHp pdX/VLosibAhEXJsFLBG0oFr7mXECmPvmMwlvw8udWXSO8dwF3zo/1t4OiyKN7br0sTS juXw== X-Gm-Message-State: AIkVDXIf6TjRgLd75m0hIiTBUOxFjhSZo4pVSpKP2FdVN4lftiJAsxOgIsn+OeVyYAbCWw== X-Received: by 10.99.107.130 with SMTP id g124mr6863587pgc.108.1484620389916; Mon, 16 Jan 2017 18:33:09 -0800 (PST) Received: from ?IPv6:2406:e007:4961:1:28cc:dc4c:9703:6781? ([2406:e007:4961:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q145sm50592596pfq.22.2017.01.16.18.33.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 18:33:09 -0800 (PST) Subject: Re: IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <94dffda9-0a88-cfa1-6281-5d788a7ca121@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <052de47d-3075-8bd1-6bdf-c1e3f8adc6ef@gmail.com> Date: Tue, 17 Jan 2017 15:33:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 02:33:12 -0000 On 17/01/2017 14:44, Lorenzo Colitti wrote: > But your text does change this arbitrary choice, by removing it. Huh? It replaces the lower case required by "that length is 64 bits" and states that it *might* be changed in the future. And yes, if that makes designers a bit leery about embedding the constant 64 deep in their= implementations, that is entirely intentional. Brian >=20 > On Tue, Jan 17, 2017 at 10:36 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> Nobody is saying we should change it in the foreseeable future. >> As for the unforeseeable future, I don't know ;-) >> >> Brian >> >> On 17/01/2017 14:10, Lorenzo Colitti wrote: >>> Yep. It's an arbitrary choice, just like the choice to make IPv6 >> addresses >>> 128 bits long, or the choice to make the header 40 bytes long. That >> doesn't >>> mean we should change it. >>> >>> On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> On 17/01/2017 09:42, Behcet Sarikaya wrote: >>>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>>> wrote: >>>>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>>>>> >>>>>>> A modest suggestion: >>>>>>> >>>>>>> OLD >>>>>>> For all unicast addresses, except those that start with the bi= nary >>>>>>> value 000, Interface IDs are required to be 64 bits long. >>>> Background >>>>>>> on the 64 bit boundary in IPv6 addresses can be found in >> [RFC7421]. >>>>>>> >>>>>>> NEW >>>>>>> IPv6 routing is based on prefixes of any valid length up to 12= 8 >>>>>>> [BCP198]. >>>>>>> For example, [RFC6164] standardises 127 bit prefixes on >>>> point-to-point >>>>>>> links. However, consistent use of Stateless Address >>>> Autoconfiguration >>>>>>> (SLAAC)[RFC4862] requires that all interfaces on a link use th= e >> same >>>>>>> length >>>>>>> of Interface ID. In practice, this means that to guarantee >>>>>>> interoperability >>>>>>> of SLAAC, a fixed length of Interface ID is necessary. For all= >>>>>>> currently >>>>>>> allocated unicast addresses, except those that start with the >> binary >>>>>>> value 000, that length is 64 bits. Note that this value is an >>>> arbitrary >>>>>>> choice and might be changed for some future allocation of unic= ast >>>>>>> address >>>>>>> space. Background on the 64 bit boundary in IPv6 addresses can= be >>>> found >>>>>>> in [RFC7421]. >>>>>> >>>>>> >>>>>> I agree with the change suggestion. The new text and references a= re >>>> enough >>>>>> motivation to clarify that that 64bit limit is an arbitrary choice= and >>>> might >>>>>> change in the future. >>>>>> >>>>> >>>>> 3GPP assigns 64 bit prefixes to each UE. >>>>> Extended Unique Identifiers defined are EUI-48 and EUI-64. >>>>> I don't think 64 bit limit is that arbitrary? >>>> >>>> It's a parameter, which we happened to set initially to 48 >>>> and then changed to 64 because of FireWire. I don't know >>>> why 3GPP chose the same value. But indeed we (the IETF) chose >>>> it because of our now old-fashioned decision to copy Novell >>>> Netware by embedding layer 2 addresses in layer 3. A bad >>>> choice, as it turned out. >>>> >>>> The first two definitions of "arbitrary" in Merriam-Webster seem >>>> to fit, especially the second. >>>> >>>> "existing or coming about seemingly at random or by chance >>>> or as a capricious and unreasonable act of will" >>>> "based on or determined by individual preference or convenience >>>> rather than by necessity or the intrinsic nature of something" >>>> >>>> Regards >>>> Brian >>>> >>>>> >>>>> Behcet >>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Brian >>>>>>> >>>>>>> -----------------------------------------------------------------= --- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 >>>>>>> -----------------------------------------------------------------= --- >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------= -- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >>>>>> ------------------------------------------------------------------= -- >>>>>> >>>>> . >>>>> >>>> >>>> --------------------------------------------------------------------= >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> --------------------------------------------------------------------= >>>> >>> >> >> >=20 From nobody Mon Jan 16 18:37: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 C9C85129434 for ; Mon, 16 Jan 2017 18:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 tTBuAPIhBnQK for ; Mon, 16 Jan 2017 18:37:17 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D41129411 for ; Mon, 16 Jan 2017 18:37:16 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id c85so181879048wmi.1 for ; Mon, 16 Jan 2017 18:37:16 -0800 (PST) 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=TwtzmJs88HmZ/vD9vrHv7rqwShkXNepTpI+EmJG2B6o=; b=j0OqRIoOpG904pSGSaaUaTOsKXO2kPZOo/NYxRUD7s6zOQioh24oG7ic0hkm/oKyVp ZxyFP0QG67v4v56aFM0O3f7IT42Jsj+VEj+TgWxumKIglL3reOt1GaVMnvA5YA6fzu6k hUXShc3aRD4Thl63XyY1nSgLGipD4OQ0i4TrYnffsZajP7YQ/XFdIYZkI6r6mEX1p1l/ JFcWYYLMABUmdCcNMVc1JRrcRXBdgMmwrDiZzD8uyLa+xhxfifj/Xb3xkQTkPDpxThfV pOU67FBpunOTTAIGh4SkLXXZo0bhlqBlgnUFi9iT3RDouNyRuatTcxFGbe0ano+D5ELd 13wA== 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=TwtzmJs88HmZ/vD9vrHv7rqwShkXNepTpI+EmJG2B6o=; b=coi5aVFOEb/RfQxFNWgLXSMeeyKLF03jEYPaW+HQKUbvObVYpby6W1Te5ymSd5uVF7 6lB3jb8IOphF/TQRdYn17E+N7vj1WSP6qOPuCl2dJcZmFnk+CKseNwQGDqQHc77Cqkh2 jK0Vwk9QV4qiqu5ictZph5SLg1TK3I26HdCh3BkK2CpAddFmvz9KYNd188WdY5uC9W54 jDW8lmALSap8XLjmry7bpEd5nQNbZiDZztlbXHFUrHuAcVMtalG+8rkHxdfHkmzNaW3f JGX5OMA2sQmtTjKYzDXaQ8yBYu+OOoFMWJK1hqSCm6ohU/yaigZgGtDMAiQ7AsXsdgWM ns/Q== X-Gm-Message-State: AIkVDXL4vguMVI0hII/BL9tDdQjNDZQH3AmC58VDaH5T7+gsOuK/OFqLlshczy229yDV+o6RB2peY+l7WCld1/RF X-Received: by 10.28.37.71 with SMTP id l68mr12489775wml.74.1484620635009; Mon, 16 Jan 2017 18:37:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 18:36:54 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Erik Kline Date: Tue, 17 Jan 2017 11:36:54 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Lorenzo Colitti Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114e275c98f8a90546412d65" Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 02:37:19 -0000 --001a114e275c98f8a90546412d65 Content-Type: text/plain; charset=UTF-8 On 17 January 2017 at 11:18, Erik Kline wrote: > On 17 January 2017 at 10:08, Lorenzo Colitti wrote: >> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter >> wrote: >>> >>> > what's the specific rationale for this change? Is it a bug in 4291 which >>> > you're proposing that we resolve in 4291 bis? If so, what is the bug? >>> >>> The bug is that in SLAAC, the IID length is a parameter, not a constant, >>> and that in routing protocols, the prefix length is a parameter, not >>> a constant. The addressing architecture needs to recognise that. >> >> >> There is no bug here. >> >> What that text in 4291 says is that if you run SLAAC on a Global Unicast >> address not starting with ::/3, then the length of the IID is 64. But when >> running SLAAC on non-Global Unicast addresses, or Global Unicast addresses >> in ::/3, then the length of the IID is not specified in RFC 4291 (and >> presumably left up to the IPv6-over-foo documents). >> >> That is why, for example, RFC 2464 has to say that on Ethernet, the >> link-local address "is formed by appending the Interface Identifier [...] to >> the prefix FE80::/64". It also says that the IID length is always 64 bits >> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the >> IID length were always 64 bits there would be no need to say that. >> >> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to >> the addressing architecture, not the other way around. But that is not in >> any way necessary to resolve a conflict between the two documents, because >> there is no conflict. >> >>> > BTW: if the reason for the text is a perceived contradiction between the >>> > fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all >>> > bit lengths" - I don't see a contradiction. >>> >>> I suggest discussing that with Randy Bush. >> >> >> While Randy's "I want to use smaller subnets than /64 because classful >> addressing is stupid" is a valid position, that does not mean that there is >> a contradiction between the two specifications. >> >> So again - what is the text trying to accomplish? I don't see a bug in the >> specs. Therefore, it seems to me that the proposed text is changing the IPv6 >> architecture in a pretty fundamental way, and I don't think it's reasonable >> to do that at the same time that we elevate it to full standard. > > I would tend to agree. Actually, I think the NEW text is pretty reasonable if we could restore the word "required" for the currently allocated unicast status quo: From: ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length is 64 bits. To: ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length is required to be 64 bits. We can always produce a document that updates 4291bis for 4::/3 or whatever we want, and the new text states so explicitly. But I'm not convinced we should change to text that could be read to weaken the current situation. --001a114e275c98f8a90546412d65 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg0LWp5Ne2gLIhkjWI++L7Le2w4v8zFqLj CWGY16LimakwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTE3 MDIzNzE1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAIuHPIOQ0sMT9cT6VLMHBZogKjl8Wr8gS/wkhJbtjNA8VfBannBr fADKHHN5B7PqQmVeN9eBpcfd7UfH/8n5lTx0AlOVhHB3yVoxELDNBgxh9cJQF3dq/F6q3sOiPr/R +cNPsL/zOrrN08mZqRKdlCh/udWa+E/KthTi9dqd8U8zH+B5nVa59+nVy+RBWfuH0z3hPNkMSGzn 8ig8oWBOK9NKIN6GTQYdIrr6Liu5XVqJCpDq9cjWI7vBdgC6mzvbdL75GAOaqlIgvmcA5la0Z5hi wNp75UQrMQAz2p5LEd5flTwiu53Vb5Ah6uF1McMjAKf/Wbn2Kvj4l2acG17ZuNw= --001a114e275c98f8a90546412d65-- From nobody Mon Jan 16 19:39: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 8DC7E1298D5 for ; Mon, 16 Jan 2017 19:39:37 -0800 (PST) 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 QeowJeAqFBdd for ; Mon, 16 Jan 2017 19:39:36 -0800 (PST) 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 E7F54129466 for ; Mon, 16 Jan 2017 19:39:35 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id t6so15456837pgt.3 for ; Mon, 16 Jan 2017 19:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZkQTQqP12d6L5QOLrv2+Uyb3tAQ+ScG6S+HJP6rYA6I=; b=B2fdbaKATVGR9BX+pwXoSFF7qfQs7ntuWRQDTAPBXXl39lJ0Icgqvmh9kVYw+hjF4W zOXCu7/wrrV1qJ812utI81hU/bP9j7mDDjmxYTfg1Yq8W2eLb2szCTk7qFbBrNuasK6k sZq956O21DazxoUlXcTDVdhJsPaJLIy2D1LwUHjIhgO6Elo2oGx3W5tajrGSiBAzoCKY 2U5rV7mX+b4Z+HQo1W3N2njPfYgirhyqKnLaAVYP1CY3AS9KfuOXrTdiOHfI5A/INElB Cr3viq0RvjYf5WjNkzavztowGx9DRC6tthKf2n8cAVIBHXe19GN/ReiUGKXv3H2zxvoC KKoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ZkQTQqP12d6L5QOLrv2+Uyb3tAQ+ScG6S+HJP6rYA6I=; b=F9eNq+tzj/lKcFXqi//LtyB/wa0dX5+dh/ZSOJvx7h/TdSb0YSCbFxowrZCCrLjD9j EbZwakrIaYGasfeU0QJKN5/SrES8HzpqM/MMZBWLgt7gm0wlOiCXQ38voUKChvrYqVcE btnZH5yOlCQhUjNIdLTN1pS6dq2tkzZ5PF48aNp2AiwwJS0vsKVv7fgxvHywUcxkPOB0 vhLHg9N+Ue7eDZlWlchXzgvb4+NaixF+y2ktbLQE9ROnSzjumD8PynqbaGQulMhzNMBS f7K9zfnEHPrk7hnw6/t0AUTDzev52j3bWYkM9Ox5koP9GzS48UsngbDXK64vwckmnb4x Sa0g== X-Gm-Message-State: AIkVDXJaJ+4oyzimg20dqc8spPeM1+fqmRJnqbotQ2vRIrtqphazEVyNusqTdWQp0AueDw== X-Received: by 10.99.54.79 with SMTP id d76mr43173963pga.91.1484624375313; Mon, 16 Jan 2017 19:39:35 -0800 (PST) Received: from ?IPv6:2406:e007:4961:1:28cc:dc4c:9703:6781? ([2406:e007:4961:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w2sm8298167pfi.65.2017.01.16.19.39.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 19:39:34 -0800 (PST) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Erik Kline , Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 17 Jan 2017 16:39:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 03:39:37 -0000 Erik, On 17/01/2017 15:36, Erik Kline wrote: > On 17 January 2017 at 11:18, Erik Kline wrote: >> On 17 January 2017 at 10:08, Lorenzo Colitti wrote: >>> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter >>> wrote: >>>> >>>>> what's the specific rationale for this change? Is it a bug in 4291 which >>>>> you're proposing that we resolve in 4291 bis? If so, what is the bug? >>>> >>>> The bug is that in SLAAC, the IID length is a parameter, not a constant, >>>> and that in routing protocols, the prefix length is a parameter, not >>>> a constant. The addressing architecture needs to recognise that. >>> >>> >>> There is no bug here. >>> >>> What that text in 4291 says is that if you run SLAAC on a Global Unicast >>> address not starting with ::/3, then the length of the IID is 64. But when >>> running SLAAC on non-Global Unicast addresses, or Global Unicast addresses >>> in ::/3, then the length of the IID is not specified in RFC 4291 (and >>> presumably left up to the IPv6-over-foo documents). >>> >>> That is why, for example, RFC 2464 has to say that on Ethernet, the >>> link-local address "is formed by appending the Interface Identifier [...] to >>> the prefix FE80::/64". It also says that the IID length is always 64 bits >>> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the >>> IID length were always 64 bits there would be no need to say that. >>> >>> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to >>> the addressing architecture, not the other way around. But that is not in >>> any way necessary to resolve a conflict between the two documents, because >>> there is no conflict. >>> >>>>> BTW: if the reason for the text is a perceived contradiction between the >>>>> fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all >>>>> bit lengths" - I don't see a contradiction. >>>> >>>> I suggest discussing that with Randy Bush. >>> >>> >>> While Randy's "I want to use smaller subnets than /64 because classful >>> addressing is stupid" is a valid position, that does not mean that there is >>> a contradiction between the two specifications. >>> >>> So again - what is the text trying to accomplish? I don't see a bug in the >>> specs. Therefore, it seems to me that the proposed text is changing the IPv6 >>> architecture in a pretty fundamental way, and I don't think it's reasonable >>> to do that at the same time that we elevate it to full standard. >> >> I would tend to agree. > > Actually, I think the NEW text is pretty reasonable if we could > restore the word "required" for the currently allocated unicast status > quo: > > From: > > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is 64 bits. > > To: > > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is required to be 64 bits. I could live with that. The "currently allocated" is the point. Brian > > We can always produce a document that updates 4291bis for 4::/3 or > whatever we want, and the new text states so explicitly. > > But I'm not convinced we should change to text that could be read to > weaken the current situation. > From nobody Mon Jan 16 20:32: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 AD31B12949D for ; Mon, 16 Jan 2017 20:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R7y9T6FCIre for ; Mon, 16 Jan 2017 20:32:46 -0800 (PST) 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 23490129449 for ; Mon, 16 Jan 2017 20:32:46 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 8EDFE989 for ; Tue, 17 Jan 2017 04:32:45 +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 VzMN0Mom3ijX for ; Mon, 16 Jan 2017 22:32:45 -0600 (CST) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.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 5CDFD970 for ; Mon, 16 Jan 2017 22:32:45 -0600 (CST) Received: by mail-vk0-f71.google.com with SMTP id 78so21116312vkj.2 for ; Mon, 16 Jan 2017 20:32:45 -0800 (PST) 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=uLBf+Cq9ZbWDt8Qx9VDEZhdY1zs5CzkVoJPbYeUy/4U=; b=nEatuTePSDw1Q0xIkXOLdTLSx/EXwuGiQfdu9icwvTl1GgB+v39HcJhQD/zjLQc7VU ak6X29AZQc5PO54up+SlbiC4LSo7y2r/hURWdFGSmp7HUbB9EKEYZopHRwmkkSUrEjXB 4Q8ItPw0EyHlBzn03xwINCxyXYtwJqssjBjdPM0BGnoTzAAVGR4gQoXVeqRk9t+pGzy4 imZR/ACpYZtmg+QhSZf0eX53J9W/upZowATay/MXgdSqDjTBgDK/BGlwH4Bp/6cU71OG NEKSVFLNgoJaP0RegnPjgiPGvRNwPfmKN8rJ3kPi+qti4KRg6siay2P+HMVZrKZmfy9r Yw1Q== 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=uLBf+Cq9ZbWDt8Qx9VDEZhdY1zs5CzkVoJPbYeUy/4U=; b=XWeSXNLhXJ+NpYTbfF/ajw29evTkKTwvfX+VxaMxfu/Pnuk0Klgz3sewVneWYuxzZu TNOdfS8NVeTuj4hJIQRu9MAjf+lxhO98pwP8yCyLGYiQIiJ2dcuw7JLPq+e1nSZXYrAd HdV+gYEnEBfm2yNf4QlidrwbQsE0Rb7frzKraCiwmzTy0rAZUuRaj6f1SV+eX6mcoqCw xpssyc1cpNrK7Hq7QtdLHFdi+1m+0lQqn3tzOvzfCFgrpeioLIiQOPK1gHkvRIISSlBe l5/g2Op8gfA248MeyOywb/upSCo/fmHcJvFD1NN4YsNC43hry2s/Cbl9zSzF7NCoRXu8 WE6A== X-Gm-Message-State: AIkVDXJDQSLz5SFVtAeIRqjbzqqD4jh+1Jx4Cgze9F8bgO4kNbVYim+V+ZWk7emuzRhU45RwKX403nMiLPSzNY5hcHna3S3FojYxNyjh7e1DFveuof3fzn+mO2+GhAv9l1mS9HAI0C03t6ySDCM= X-Received: by 10.176.16.236 with SMTP id x44mr19889121uab.162.1484627564822; Mon, 16 Jan 2017 20:32:44 -0800 (PST) X-Received: by 10.176.16.236 with SMTP id x44mr19889116uab.162.1484627564661; Mon, 16 Jan 2017 20:32:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Mon, 16 Jan 2017 20:32:43 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: David Farmer Date: Mon, 16 Jan 2017 22:32:43 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Erik Kline Content-Type: multipart/alternative; boundary=94eb2c1cfa089da343054642ca0e Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 04:32:48 -0000 --94eb2c1cfa089da343054642ca0e Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 8:36 PM, Erik Kline wrote: > > Actually, I think the NEW text is pretty reasonable if we could > restore the word "required" for the currently allocated unicast status > quo: > > From: > > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is 64 bits. > > To: > > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is required to be 64 bits. > > We can always produce a document that updates 4291bis for 4::/3 or > whatever we want, and the new text states so explicitly. > > But I'm not convinced we should change to text that could be read to > weaken the current situation. > The new text correctly states that 64 bit IIDs are required for SLACC, reinserting "required" back in the phrase above just brings back the conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the statement isn't scoped to SLACC. 64 bit IIDs are clearly the consensus RECOMMENDATION, other than for point-to-point links, but saying they are REQUIRED for other than SLACC is plainly false. Manual configuration and DHCPv6 with other than 64 bit IIDs or /64 subnets, are in operational use in many places, this is clearly NOT RECOMMENDED, but it is completely consistent with all the rest of specifications of IPv6. Furthermore, if the old text was correctly understood we would not have needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly faulty. I support the new text with the minor tweaks begin discussed, s/fixed/consistent/. -- =============================================== 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 =============================================== --94eb2c1cfa089da343054642ca0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 8:36 PM, Erik Kline <ek@google.com> = wrote:

Actually, I think the NEW text is pretty reasonable if we could
restore the word "required" for the currently allocated unicast s= tatus
quo:

From:

=C2=A0 =C2=A0... For all currently
=C2=A0 =C2=A0allocated unicast addresses, except those that start with the = binary
=C2=A0 =C2=A0value 000, that length is 64 bits.

To:

=C2=A0 =C2=A0...=C2=A0 For all currently
=C2=A0 =C2=A0allocated unicast addresses, except those that start with the = binary
=C2=A0 =C2=A0value 000, that length is required to be 64 bits.

We can always produce a document that updates 4291bis for 4::/3 or
whatever we want, and the new text states so explicitly.

But I'm not convinced we should change to text that could be read to weaken the current situation.

The new t= ext correctly states that 64 bit IIDs are required for SLACC, reinserting &= quot;required" back in the phrase above just brings back the conflict = with section 2.4 and RFC6164, BCP198/RFC7608, because the statement isn'= ;t scoped to SLACC. =C2=A064 bit IIDs are clearly the consensus RECOMMENDAT= ION, other than for point-to-point links, but saying they are REQUIRED for = other than SLACC is plainly false.=C2=A0 Manual configuration and DHCPv6 wi= th other than 64 bit IIDs or /64 subnets, are in operational use in many pl= aces, this is clearly NOT RECOMMENDED, but it is completely consistent with= all the rest of specifications of IPv6.=C2=A0 Furthermore, if the old text= was correctly understood we would not have needed RFC5942 and BCP198/RFC76= 08, therefore the old text is clearly faulty.

I su= pport the new text with the minor tweaks begin discussed,=C2=A0s/fixed/consistent/.



--
=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
Office of Information Technology
Un= iversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
--94eb2c1cfa089da343054642ca0e-- From nobody Mon Jan 16 20:52: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 58027129A30 for ; Mon, 16 Jan 2017 20:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 uLr3p36LtKRZ for ; Mon, 16 Jan 2017 20:52:28 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A202129A2F for ; Mon, 16 Jan 2017 20:52:28 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id r136so85701243vke.1 for ; Mon, 16 Jan 2017 20:52:28 -0800 (PST) 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=nW+OFa7mt63TUIE6LCa0Mc7XZgXRqaCbmrYdgqF2V8o=; b=JBH6h4lon4kuBEO8GmXRLOUP6pt+f4H5XqBSoX0+YXNx4aFay5gB307JY4rPCVEG5h v9RzuZlDQn/EeJXJKCxxX+4LMJLD00BD8qtjY9uOfix15Nms9gRVSvo1j6SjZCfEEcN4 W2v1j+X/2oGT9WQHKxJOrea+O+MPSCMVi9RdedVjZCFbEp+HPla2jeHVeeg8RR8zi2De lMYaegn7BFYVmkQawht9nu6mmHrwsolzDVn+ZromiJTqlX03PzQa6OPAI5WgsS9WAIro ovHLu0ldOpAKe/UQdpnktk8dEoQ9SHfFajdQX2OJJtDOmpgVQc3ndiqn+kZXG2ZUaB4l EikQ== 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=nW+OFa7mt63TUIE6LCa0Mc7XZgXRqaCbmrYdgqF2V8o=; b=qhU3IDVFgu2TCELl8ebG6HsYyaO/xgK6ovAMEbRX9r7RjJ1IQ40w7bX7aH/PnJRe4Y AkaNVu+VdSs24lOqSUIRx60w6+ej3W1FEZl+sHKOU6XbzTWH/M7Z9ERzqfs2ibnwGLKf aXIqAtauaSPAeIZ5NpcGcvuTk7WIjmJjJpSk0dBp+K0LdQnEzbSiaEhbKfyuGzRLsns1 gaI0WmTZ0YbnRW4IU49iLrAumj6XmCKh3y5JM8CC4c5ccnxELHdgAlS/OTemcq5xAlbN BU0Escvd3fFPxeGgEeTq/HD7Jq5EzU2AF3AVisp0BCqufEaL/fxcRBza2STr5+j58AC1 gSgQ== X-Gm-Message-State: AIkVDXL+MaXV4oSZ1YjH4vbI9riGaQ918vhQPonmboNDqBI3eljOEv1GMavzJLnfhfK0+j/UpK/sI/9CwRy2XQVX X-Received: by 10.31.88.1 with SMTP id m1mr18004683vkb.83.1484628747441; Mon, 16 Jan 2017 20:52:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 16 Jan 2017 20:52:06 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Lorenzo Colitti Date: Tue, 17 Jan 2017 13:52:06 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: David Farmer Content-Type: multipart/alternative; boundary=001a114e53641dad8905464311a5 Archived-At: Cc: Erik Kline , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 04:52:30 -0000 --001a114e53641dad8905464311a5 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 17, 2017 at 1:32 PM, David Farmer wrote: > reinserting "required" back in the phrase above just brings back the > conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the > statement isn't scoped to SLACC. 64 bit IIDs are clearly the consensus > RECOMMENDATION, other than for point-to-point links, but saying they are > REQUIRED for other than SLACC is plainly false. > Required for what purpose? For things to work on a particular implementation? Or required by the standards? As far as the current standards are concerned, with the exception of /127, IIDs for global unicast addresses outside ::/0 are required to be 64 bits long, period. If we change that, we're making a substantive change to the standard. As for what is required for things to work on your favourite implementation, the list of of things that will work depends solely on your definition of work. For some people, things work "work" might "client applications can reach external servers", and the list of things that will work (even though it violates various standards) include numbering a 10000-person office with ULA and putting it behind a full-cone NAT66 that translates everything to one IPv6 address. > Manual configuration and DHCPv6 with other than 64 bit IIDs or /64 > subnets, are in operational use in many places, this is clearly NOT > RECOMMENDED, but it is completely consistent with all the rest of > specifications of IPv6. > Citing the "rest of the specifications" here is not germane to the discussion. Using non-/64 IIDs conflicts with precisely the RFC that is authoritative on that topic, which is RFC 4291. Saying that it doesn't conflict with any other RFCs is a bit like saying that tax evasion is not prohibited by any other law than tax law: (in first approximation) true, but not really relevant. > Furthermore, if the old text was correctly understood we would not have > needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly faulty. > "Not clear" != "faulty". As explained before, there is no conflict between RFC 4291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can you clarify what you mean? --001a114e53641dad8905464311a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 17, 2017 at 1:32 PM, David Farmer <farmer@umn.edu> wrot= e:
reinserting "required" back= in the phrase above just brings back the conflict with section 2.4 and RFC= 6164, BCP198/RFC7608, because the statement isn't scoped to SLACC. =C2= =A064 bit IIDs are clearly the consensus RECOMMENDATION, other than for poi= nt-to-point links, but saying they are REQUIRED for other than SLACC is pla= inly false.

Require= d for what purpose? For things to work on a particular implementation? Or r= equired by the standards? As far as the current standards are concerned, wi= th the exception of /127, IIDs for global unicast addresses outside ::/0 ar= e required to be 64 bits long, period. If we change that, we're making = a substantive change to the standard.

As for what = is required for things to work on your favourite implementation, the list o= f of things that will work depends solely on your definition of work. For s= ome people, things work "work" might "client applications ca= n reach external servers", and the list of things that will work (even= though it violates various standards) include numbering a 10000-person off= ice with ULA and putting it behind a full-cone NAT66 that translates everyt= hing to one IPv6 address.
=C2=A0
=
Manual configuration and DHCPv6 with other than 64 bit IIDs or /64 sub= nets, are in operational use in many places, this is clearly NOT RECOMMENDE= D, but it is completely consistent with all the rest of specifications of I= Pv6.

Citing the &qu= ot;rest of the specifications" here is not germane to the discussion. = Using non-/64 IIDs conflicts with precisely the RFC that is authoritative o= n that topic, which is RFC 4291. Saying that it doesn't conflict with a= ny other RFCs is a bit like saying that tax evasion is not prohibited by an= y other law than tax law: (in first approximation) true, but not really rel= evant.
=C2=A0
=C2=A0 Further= more, if the old text was correctly understood we would not have needed RFC= 5942 and BCP198/RFC7608, therefore the old text is clearly faulty.

"Not clear" !=3D = "faulty". As explained before, there is no conflict between RFC 4= 291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link = addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can y= ou clarify what you mean?
--001a114e53641dad8905464311a5-- From nobody Mon Jan 16 20:55: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 DC8C5129A32 for ; Mon, 16 Jan 2017 20:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPnFNT8nud9s for ; Mon, 16 Jan 2017 20:55:42 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 8AB39129A2F for ; Mon, 16 Jan 2017 20:55:42 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 315D379F for ; Tue, 17 Jan 2017 04:55:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihuvN5XCjtlI for ; Mon, 16 Jan 2017 22:55:41 -0600 (CST) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 025B8850 for ; Mon, 16 Jan 2017 22:55:40 -0600 (CST) Received: by mail-vk0-f72.google.com with SMTP id 75so80591770vkm.0 for ; Mon, 16 Jan 2017 20:55:40 -0800 (PST) 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=N6bEyu/fIzFwjs1RaG8S9R5ALzTwXur8WIMp2YPRuVI=; b=XByNkt9bXiJ3KfyW/xZptxm3a0Ai8m8lZdeNzTv2sCXvYkzppFpr9jO617fZvA/Ys/ CuKYGP+ZSGxmQiUiZRWMUwBYWkz2F9E51z+GAV1a9dJ5ZQRPO2Gg1EaLt/bb14cwvQgf suZR+DrSTCE62C9NtaNUowzhaQ8tXvabV+LVoth4Mb3rMV+bcd4aSYiWYacSOFX0itlR yVbYqix9T3Dp82kB0lDtg2C3DFUYR6O9gjku3NArK8JPYwFYP0A0pHg1K5k/yKcnMWIx bZSUJJueSefimrsCVJNnWRpS8j48vwuURihuaOXg9XZmyfp78QV4MBtScWnCkgs+ViWc y8Yg== 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=N6bEyu/fIzFwjs1RaG8S9R5ALzTwXur8WIMp2YPRuVI=; b=QQ1RKsJyzmuruvG6PFobBawJzESxXEr4A+hz6D1M8Q/HX1DsLFUvuip9jWhnU6FgBK G/6fhAZtsqwE8o/OPWSsWOt+0PoVPMaAQBtq93vPmzbUdYwcPOHS/6ho7DarHBT8dDS0 End6c5brnYpdkPsUWQkFntwHLsJ7V+wrRikAMyU3HGedU2QePglwhW1rc52JTlPz3ja3 yjpH2RRsoj04/PNbBiGI3P0FEHIfScnU5p2UzZkcSKa+PUi+rvuxVy3C5m4HbwvEq4dh xvfOmVeozMzrhfsSyRMlTYQKkXbU1W8+9D0mzqDPBT/rPNhKhSNmP9DeaeID5XL+wug3 rUyg== X-Gm-Message-State: AIkVDXJ1WfJtF0BDi6gK6DBIQWqMp2SmVZeLi+tfdMWdXfPKCEcCpSsMQma+EQrtEJBvQX7GlE2Bfdhfg8vK4WTlrOmdIO/Vv3dwARNgzjgJ7an8BBQ19h9Rgu6v9R9ZgQh0njq1jZUUqJ/+KNE= X-Received: by 10.176.91.214 with SMTP id z22mr18380053uae.135.1484628940088; Mon, 16 Jan 2017 20:55:40 -0800 (PST) X-Received: by 10.176.91.214 with SMTP id z22mr18380048uae.135.1484628939932; Mon, 16 Jan 2017 20:55:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Mon, 16 Jan 2017 20:55:39 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <64cfae99-3d70-25b7-09b1-a1d327c563bf@si6networks.com> From: David Farmer Date: Mon, 16 Jan 2017 22:55:39 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f403045f8cd69698f60546431c55 Archived-At: Cc: Fernando Gont , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 04:55:44 -0000 --f403045f8cd69698f60546431c55 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 4:04 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > In line... > On 17/01/2017 08:59, Fernando Gont wrote: > > On 01/14/2017 04:49 PM, Brian E Carpenter wrote: > >> A modest suggestion: > >> > >> OLD > >> For all unicast addresses, except those that start with the binary > >> value 000, Interface IDs are required to be 64 bits long. Background > >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > >> > >> NEW > >> IPv6 routing is based on prefixes of any valid length up to 128 > [BCP198]. > >> For example, [RFC6164] standardises 127 bit prefixes on > point-to-point > >> links. However, consistent use of Stateless Address Autoconfiguration > >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length > >> of Interface ID. In practice, this means that to guarantee > interoperability > >> of SLAAC, a fixed length of Interface ID is necessary. > > > > fixed as "all nodes on the link use the same IID length" or as in "a > > hardcoded IID length, as the current 64 value"? > > > > If the former, I agree. If the later, I don't. > > You're right, that choice of word could be contradictory. > I suggest s/fixed/consistent/. > > Brian > With that change I think the use of "consistent" in the previous sentence is somewhat redundant. How about; However, use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires that all interfaces on a link use the same length of Interface ID. In practice, this means that to guarantee interoperability of SLAAC, a consistent length of Interface ID is necessary. -- =============================================== 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 =============================================== --f403045f8cd69698f60546431c55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jan 16, 2017 at 4:04 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
In line...
On 17/01/2017 08:59, Fernando Gont wrote:
> On 01/14/2017 04:49 PM, Brian E Carpenter wrote:
>> A modest suggestion:
>>
>> OLD
>>=C2=A0 =C2=A0 For all unicast addresses, except those that start wi= th the binary
>>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits l= ong.=C2=A0 Background
>>=C2=A0 =C2=A0 on the 64 bit boundary in IPv6 addresses can be found= in [RFC7421].
>>
>> NEW
>>=C2=A0 =C2=A0 IPv6 routing is based on prefixes of any valid length= up to 128 [BCP198].
>>=C2=A0 =C2=A0 For example, [RFC6164] standardises 127 bit=C2=A0 pre= fixes on point-to-point
>>=C2=A0 =C2=A0 links. However, consistent use of Stateless Address A= utoconfiguration
>>=C2=A0 =C2=A0 (SLAAC)[RFC4862] requires that all interfaces on a li= nk use the same length
>>=C2=A0 =C2=A0 of Interface ID. In practice, this means that to guar= antee interoperability
>>=C2=A0 =C2=A0 of SLAAC, a fixed length of Interface ID is necessary= .
>
> fixed as "all nodes on the link use the same IID length" or = as in "a
> hardcoded IID length, as the current 64 value"?
>
> If the former, I agree. If the later, I don't.

You're right, that choice of word could be contradictory.
I suggest s/fixed/consistent/.

=C2=A0 =C2=A0 Brian

With that change I = think the use of "consistent" in= the previous sentence is somewhat redundant.=C2=A0 How about;
=

=C2=A0 =C2=A0However, use of Stateless Address Autoconf= iguration (SLAAC)[RFC4862]=C2=A0
=C2=A0 =C2=A0requires that all i= nterfaces on a link use the same length=C2=A0of Interface ID.=C2=A0
=C2=A0 =C2=A0In practice, this means that to guarantee interoperability = of SLAAC, a=C2=A0
=C2=A0 =C2=A0consistent length of Interface ID = is necessary.


--
=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 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, 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
--f403045f8cd69698f60546431c55-- From nobody Mon Jan 16 21:35: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 26E0B129A69 for ; Mon, 16 Jan 2017 21:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fok7ojjV74hT for ; Mon, 16 Jan 2017 21:35:22 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5665212947B for ; Mon, 16 Jan 2017 21:35:22 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id C3B8693C for ; Tue, 17 Jan 2017 05:35:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4GM0OSkBV_l for ; Mon, 16 Jan 2017 23:35:21 -0600 (CST) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 80C00812 for ; Mon, 16 Jan 2017 23:35:21 -0600 (CST) Received: by mail-vk0-f71.google.com with SMTP id k127so80353968vke.7 for ; Mon, 16 Jan 2017 21:35:21 -0800 (PST) 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=zvMp/IxZ2gvb3QGhGa0bUT23d9np3jeYdEx52EsYvg4=; b=BzOvZqpt7IugjKW/pQ/7+HpKJuedfXXaNEfullI9jxK+qVlvBlGm+kUj0jdPjzJuWs ZIU9KpfWBYKVQWPUwhD7YMgmWsQFmixVDOGShDYhFIlR5G9Cw8gIBgrSVM4ScCc1MM9n pLpqPWgjZ1gU+eJoiYyYP5t+vscCdYfKwgCDO1jFtEOjvhaKnLc4ypQOldgBDJKAdVG8 JYUxZN/PNjlCKb8kV74e7qxiI8ZOlB/y8YFXnjE82NDcGv+ll6PGQMCMZUn79vb0HvwM EFj7AE1DPr2FrrlF6H4ZTDQ8gXmAlYTju5rcrNzZkYnnLZ2u4KGR/YLNsHTng5aZbwjy FlXw== 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=zvMp/IxZ2gvb3QGhGa0bUT23d9np3jeYdEx52EsYvg4=; b=K0Pd8woY4lykV1ZK8CBBBjN2FQhXYfs4xAO3fa9/XCAo51V12MO/19CZh+dzOD37Ob o2C1m4HbC8fLDQghfGkrOrOmK0hhfYvfHMEZcHWEM2+7pkOIyW1aUOqUQQfyuk08UPJr zgKFyy9gqOojdL6jt+qOEESaa99IOKIMu6E118GOOND164oSModYYdswT8OOSYfZLwjU BMgKan1TfBC+q7hkG48RJWnrt+FheM7alhfiaUuJV5q2z1Yl19rzQx1yA0848BBb7rI5 y+veL0tn+YPKpfghKUUTZKgDYcr2Rk5RJjIEA0HDGxXZ3t6bZlFXSyhog6c058DwGB3D MOLQ== X-Gm-Message-State: AIkVDXLFxfEpcs3VFd2dxuKbt6abQO1xxwAJAmDqZwi48NgNbpRXQc12LU8pow6CV3532vPAghXGAXqBAcu5lcPyo6ASoXocyNL+uh+3yyDCCqeDPny3rSc8LMUaNgp90n6XLL638UjBT7W9E8g= X-Received: by 10.31.114.133 with SMTP id n127mr18292326vkc.129.1484631320912; Mon, 16 Jan 2017 21:35:20 -0800 (PST) X-Received: by 10.31.114.133 with SMTP id n127mr18292322vkc.129.1484631320724; Mon, 16 Jan 2017 21:35:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Mon, 16 Jan 2017 21:35:19 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: David Farmer Date: Mon, 16 Jan 2017 23:35:19 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=94eb2c1497b47e9a55054643aa8e Archived-At: Cc: Erik Kline , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 05:35:24 -0000 --94eb2c1497b47e9a55054643aa8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2017 at 10:52 PM, Lorenzo Colitti wrote: > On Tue, Jan 17, 2017 at 1:32 PM, David Farmer wrote: > >> reinserting "required" back in the phrase above just brings back the >> conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the >> statement isn't scoped to SLACC. 64 bit IIDs are clearly the consensus >> RECOMMENDATION, other than for point-to-point links, but saying they are >> REQUIRED for other than SLACC is plainly false. >> > > Required for what purpose? For things to work on a particular > implementation? Or required by the standards? As far as the current > standards are concerned, with the exception of /127, IIDs for global > unicast addresses outside ::/0 are required to be 64 bits long, period. I= f > we change that, we're making a substantive change to the standard. > What happens if they are not 64 bits long, do the proverbial Internet police write a ticket? Do I have to return my addresses to ARIN? This seems to be a false imperative to me. If 64 bit IIDs are really required, I'd like to see better motivation for this as a requirement. I only see motivation for this to be a recommendation, and I'm not the only one. As for what is required for things to work on your favourite > implementation, the list of of things that will work depends solely on yo= ur > definition of work. For some people, things work "work" might "client > applications can reach external servers", and the list of things that wil= l > work (even though it violates various standards) include numbering a > 10000-person office with ULA and putting it behind a full-cone NAT66 that > translates everything to one IPv6 address. > > >> Manual configuration and DHCPv6 with other than 64 bit IIDs or /64 >> subnets, are in operational use in many places, this is clearly NOT >> RECOMMENDED, but it is completely consistent with all the rest of >> specifications of IPv6. >> > > Citing the "rest of the specifications" here is not germane to the > discussion. Using non-/64 IIDs conflicts with precisely the RFC that is > authoritative on that topic, which is RFC 4291. Saying that it doesn't > conflict with any other RFCs is a bit like saying that tax evasion is not > prohibited by any other law than tax law: (in first approximation) true, > but not really relevant. > What breaks if all IIDs in global unicast are not 64 bits? Especially other than SLACC? I would hope such a REQUIREMENT has a better motivation that "we said so". Citing the "rest of the specifications" was simply my shorthand for I don't see what else breaks. > Furthermore, if the old text was correctly understood we would not have >> needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly fau= lty. >> > > "Not clear" !=3D "faulty". As explained before, there is no conflict betw= een > RFC 4291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies t= o > link addressing. I don't see a conflict between RFC 5942 and RFC 4291. Ca= n > you clarify what you mean? > I never said there was a conflict between conflict between RFC5942 and RFC4291, I was very careful about that. I said there was a "conflict with section 2.4 and RFC6164, BCP198/RFC7608". I was saying that the need for RFC5942 and BCP198/RFC7608 are evidence that the text in question is faulty[1], I think you would prefer misunderstood, but in my opinion its more that, so I went with faulty. [1} fault=C2=B7y - adjective - working badly or unreliably because of imperfections. --=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 --94eb2c1497b47e9a55054643aa8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 10:52 PM, Lorenzo Colitti <= ;lorenzo@google.com= > wrote:
On = Tue, Jan 17, 2017 at 1:32 PM, David Farmer <farmer@umn.edu> wro= te:
<= div class=3D"gmail_extra">
reinserting "= ;required" back in the phrase above just brings back the conflict with= section 2.4 and RFC6164, BCP198/RFC7608, because the statement isn't s= coped to SLACC. =C2=A064 bit IIDs are clearly the consensus RECOMMENDATION,= other than for point-to-point links, but saying they are REQUIRED for othe= r than SLACC is plainly false.
Required for what purpose? For things to work on a particular i= mplementation? Or required by the standards? As far as the current standard= s are concerned, with the exception of /127, IIDs for global unicast addres= ses outside ::/0 are required to be 64 bits long, period. If we change that= , we're making a substantive change to the standard.
<= /div>

What happens if they are not 64 bits = long, do the proverbial Internet police write a ticket?=C2=A0 Do I have to = return my addresses to ARIN?=C2=A0 This seems to be a false imperative to m= e.=C2=A0 If 64 bit IIDs are really required, I'd like to see better mot= ivation for this as a requirement.=C2=A0 I only see motivation for this to = be a recommendation, and I'm not the only one.

As for what is required fo= r things to work on your favourite implementation, the list of of things th= at will work depends solely on your definition of work. For some people, th= ings work "work" might "client applications can reach extern= al servers", and the list of things that will work (even though it vio= lates various standards) include numbering a 10000-person office with ULA a= nd putting it behind a full-cone NAT66 that translates everything to one IP= v6 address.
=C2=A0
Manual configuration and DHCPv6 with other than 64 bit IIDs or = /64 subnets, are in operational use in many places, this is clearly NOT REC= OMMENDED, but it is completely consistent with all the rest of specificatio= ns of IPv6.

Citing = the "rest of the specifications" here is not germane to the discu= ssion. Using non-/64 IIDs conflicts with precisely the RFC that is authorit= ative on that topic, which is RFC 4291. Saying that it doesn't conflict= with any other RFCs is a bit like saying that tax evasion is not prohibite= d by any other law than tax law: (in first approximation) true, but not rea= lly relevant.

What = breaks if all IIDs in global unicast are not 64 bits?=C2=A0 Especially othe= r than SLACC?=C2=A0 I would hope such a REQUIREMENT has a better motivation= that "we said so".=C2=A0 Citing the "rest of the specificat= ions" was simply my shorthand for I don't see what else breaks.
=C2=A0
<= div dir=3D"ltr">
=C2=A0 Furthermore, if the ol= d text was correctly understood we would not have needed RFC5942 and BCP198= /RFC7608, therefore the old text is clearly faulty.
=

"Not clear" !=3D "faulty&qu= ot;. As explained before, there is no conflict between RFC 4291 and RFC 760= 8. RFC 7608 applies to forwarding, RFC 4291 applies to link addressing. I d= on't see a conflict between RFC 5942 and RFC 4291. Can you clarify what= you mean?

I never said there was a conflict between conflict b= etween RFC5942 and RFC4291, I was very careful about that.=C2=A0 I said the= re was a "conflict with section 2.4 a= nd RFC6164, BCP198/RFC7608". =C2=A0

I was saying that the need for=C2= =A0RFC5942 and BCP198/RFC7608 are evidence that the text in question= is faulty[1], I think you would prefer misunderstood, but in my opinion it= s more that, so I went with faulty.

[1} fault=C2=B7y -= adjective - working badly or unreliably because of imperfections.

--
=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.ed= u
Networking & Telecommunication Services
Office of Informati= on Technology
University of Minnesota=C2=A0=C2=A0
2218 University Av= e SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 5541= 4-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
--94eb2c1497b47e9a55054643aa8e-- From nobody Tue Jan 17 02:01: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 AD93F129514 for ; Tue, 17 Jan 2017 02:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXWLSleW-cru for ; Tue, 17 Jan 2017 02:01:10 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id AC91212945F for ; Tue, 17 Jan 2017 02:01:10 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 17 Jan 2017 10:01:10 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EBA3AD788F; Tue, 17 Jan 2017 02:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=WWNYlEuJjofeApBBkNDfirUsGao=; b=XgJ17R2vb1ooOTMotL pWddwZpvIMV/iRyT3+lO8BLiD+FNr5UsHlwNvP05tavBIvOizbVh+Sw8zS9c1fV9 oMGrt5TjQ9LSntbVDbo6053WcGgfcFHaJgTu9C4XEYP0k7KVpJAIkFmBDZYidYvz YdtE5HX2nXyAbcYpebqxqldB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=YvhkMOjNzQPzDAo3jTmoSntXZsMUuld12id5SgwJwF5ihAgCNeS XxU6FTMGN6rgvPtgQqQcT7VWjgJwjLT3VqMN/EfwRFyz3oBYngoy5U4mHas2KjP8 BaWONIN/UZQ3ufx01lCfyS98vk+nmX/pxkNqis0I7HrqjBXq/YPd1MX8= Received: from h.hanazo.no (unknown [46.228.50.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 852C8D788D; Tue, 17 Jan 2017 02:01:09 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BCECE763FDE7; Tue, 17 Jan 2017 11:00:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] From: otroan@employees.org In-Reply-To: Date: Tue, 17 Jan 2017 11:00:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Erik Kline , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 10:01:17 -0000 > What breaks if all IIDs in global unicast are not 64 bits? Especially = other than SLACC? I would hope such a REQUIREMENT has a better = motivation that "we said so". Citing the "rest of the specifications" = was simply my shorthand for I don't see what else breaks. RFC7421, section 4.2. There's also a set of political considerations, where one tries to = achieve balance between the provider's desire to have effective = aggregation and the end-users desire to have enough address space. We = specifically want to avoid provider's charging by the address. O. From nobody Tue Jan 17 06: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 6C921129521 for ; Tue, 17 Jan 2017 06:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XgJT5z2LtdL for ; Tue, 17 Jan 2017 06:30:06 -0800 (PST) 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 199BD1294CA for ; Tue, 17 Jan 2017 06:30:06 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 82558212 for ; Tue, 17 Jan 2017 14:30:05 +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 bsd8dtgLgHAZ for ; Tue, 17 Jan 2017 08:30:05 -0600 (CST) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (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 4D265B05 for ; Tue, 17 Jan 2017 08:30:05 -0600 (CST) Received: by mail-vk0-f72.google.com with SMTP id r136so84899132vke.6 for ; Tue, 17 Jan 2017 06:30:05 -0800 (PST) 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=OSZe9WVweCGi/xeGKiNtCceueDqghbjTkSQI3q8b0Ks=; b=czyKGoSP3+cVduo3z7OVQLg22Fs7So4dF7PsHN46VlZjXyfddBhwWRV1K7BVex8HXn yyJsRcvqw6XMHUTLEju0w44UsVFdvkx6PK12ZbAA0RM5alV1QHLDTnR5pNWJTXAUDSzs C9ldHWuNOZYHFwTAiyjitv8Y1+FJPAWfU51XTIC+423D7E4ujQy+4lTas8s9slu3IAZW 8jNxdmRHoY30WhyVdB39ZNuwf9aPpFSvmC5eWjj/BwJQ7QLp2fU56xIeOGHL48TMsc/0 7j0xnbJVkATk8CJexfFBrmAqcWSlDQiOQGDhnp86WvDgRv58YywoX2BDA2pvTWJwGesS YO+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; bh=OSZe9WVweCGi/xeGKiNtCceueDqghbjTkSQI3q8b0Ks=; b=CEIZnJ19nwZ5BiDIYCyrPERHmFFexhuE2gi3B912JztvJbUG/s21rZJ4DN2sXIDgEO 6/bEGA8KHibOtxbBE8a3eHeb3ZWje0E837vlY9zTnlPtPLUit4jxjnwQqjYKAeR0UBkQ 3ZcBjNPNfm3VY2ap7NTkAQlaotpqmW1XcOKAZVm06r0+q6BWIAAOgXTza9/dV+1WRtmy dXAdB/+Aua5T1idd7sRdTcnPG7nL8oAZkY9bmT0Hx1egLyDHnA6OopWuG+HuxohHVJvm 9MRZO0oTOhKVWrE2lgrwdhN7UtO1f5EHmWDyioM6vbHElZgdny/BAETpNWq8w7YJ79uI 4LTg== X-Gm-Message-State: AIkVDXIz4XnkbnPBadd8WUfw7AvSnB+nghT0QInfBSeyj8xDRYCMacL2reNJkV5EkImKu+/b6tNJ6QkFJH/47+wWZRJSTXU0XO1ndAr3SCXtwymfqeAEjzlg0cqp9IV6ROZIH7+AW2NPljNEKy8= X-Received: by 10.176.16.73 with SMTP id g9mr4782839uab.92.1484663404719; Tue, 17 Jan 2017 06:30:04 -0800 (PST) X-Received: by 10.176.16.73 with SMTP id g9mr4782828uab.92.1484663404532; Tue, 17 Jan 2017 06:30:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Tue, 17 Jan 2017 06:30:03 -0800 (PST) In-Reply-To: <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> From: David Farmer Date: Tue, 17 Jan 2017 08:30:03 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Ole Troan Content-Type: multipart/alternative; boundary=f403045e33b2d6ae4405464b224c Archived-At: Cc: Erik Kline , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:30:08 -0000 --f403045e33b2d6ae4405464b224c Content-Type: text/plain; charset=UTF-8 On Tue, Jan 17, 2017 at 4:00 AM, wrote: > > What breaks if all IIDs in global unicast are not 64 bits? Especially > other than SLACC? I would hope such a REQUIREMENT has a better motivation > that "we said so". Citing the "rest of the specifications" was simply my > shorthand for I don't see what else breaks. > > RFC7421, section 4.2. > > There's also a set of political considerations, where one tries to achieve > balance between the provider's desire to have effective aggregation and the > end-users desire to have enough address space. We specifically want to > avoid provider's charging by the address. > > O. > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to me "IIDs MUST be 64 bits", this is a subtle but important difference. Furthermore, RFC7421, section 4.3.2, also say there is operational use of IID other than 64 bits, which to me disproves the statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 bits." So lets be clear, I'm not saying that we should RECOMMEND other than 64 bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC 2119. So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to the in my opinion the more proper "IIDs SHOULD be 64 bits". So, I would prefer: ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length should be 64 bits. But, I'm willing to live with what Brian proposed: ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length is 64 bits. But, I can not accept what Eric proposed: ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length is required to be 64 bits. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045e33b2d6ae4405464b224c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 17, 2017 at 4:00 AM, <otroan@employees.org> wrote:
> What b= reaks if all IIDs in global unicast are not 64 bits?=C2=A0 Especially other= than SLACC?=C2=A0 I would hope such a REQUIREMENT has a better motivation = that "we said so".=C2=A0 Citing the "rest of the specificati= ons" was simply my shorthand for I don't see what else breaks.

RFC7421, section 4.2.

There's also a set of political considerations, where one tries to achi= eve balance between the provider's desire to have effective aggregation= and the end-users desire to have enough address space. We specifically wan= t to avoid provider's charging by the address.

O.
=C2=A0
Exactly, and to me R= FC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to= me "IIDs MUST be 64 bits", this is a subtle but important differ= ence.=C2=A0 Furthermore, RFC7421, section 4.3.2, also say there is operatio= nal use of IID other than 64 bits, which to me disproves the statement &quo= t;IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 b= its."

So lets be clear= , I'm not saying that we should RECOMMEND other than 64 bit IIDs, I'= ;m simply differentiating between section 1 and section 3 of RFC 2119. =C2= =A0=C2=A0

So, I'm asking what breaks if we change from "IID= s MUST be 64 bits" to the in my opinion the more proper "IIDs SHO= ULD be 64 bits". =C2=A0

So, I would prefer:
=
=C2= =A0=C2=A0...=C2=A0 For all currently
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0allocated unicast addresses, e= xcept those that start with the binary
=C2=A0 =C2=A0value 000, that length shoul= d be 64 bits.

But, I'm willing to live with what Brian proposed:

=C2=A0 =C2=A0... For all currently
=C2=A0 =C2=A0allocated = unicast addresses, except those that start with the binary
=C2=A0 =C2=A0value 0= 00, that length is 64 bits.

But, I can not accep= t what Eric proposed:

=C2=A0 =C2=A0...=C2=A0 For = all currently
=C2=A0 =C2=A0allocated unicast addresses, except those that start = with the binary
=C2=A0 =C2=A0value 000, that length is required to be 64 bits.

Thanks.
-- <= br>
=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 Ser= vices
Office 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
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045e33b2d6ae4405464b224c-- From nobody Tue Jan 17 06:58: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 56100129470 for ; Tue, 17 Jan 2017 06:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpF3gphkSJbW for ; Tue, 17 Jan 2017 06:58:02 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0134512942F for ; Tue, 17 Jan 2017 06:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x3PfUSewppc/5sQ2IegEiJT8T/7jJegt2i1I6BcAqb4=; b=Q2r3fwrC5FENGafHgABS6f0VVf+srdjfxERhmRQEqjehbyRiNu4gK8L99maFXdrnRcR9iaLgz8d8PTqwHqAvxyvGWBd9wVmr74v2DqgQyoEqQHgY7J223TgLefh01OKMIqMQr8ZXT7iS2wDo+MfQXbMLexWpzhlrpi9zajItTdI= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0247.outbound.protection.outlook.com [213.199.154.247]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-K4SXe8myMu-WM9QK8gItyA-1; Tue, 17 Jan 2017 14:57:55 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 14:57:54 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480%15]) with mapi id 15.01.0860.008; Tue, 17 Jan 2017 14:57:54 +0000 From: Tim Chown To: David Farmer Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Topic: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Index: AQHSbp9kHWr9YQvRhEWArHxhZZH6KaE62uEAgACtgoCAAFbFAIAAE6IAgAAFGACAACBcgIAABWoAgAAME4CAAEougIAASzmAgAAHx4A= Date: Tue, 17 Jan 2017 14:57:54 +0000 Message-ID: <7024EF45-953E-4C5B-9069-8B61B7AADCD1@jisc.ac.uk> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: cc25a759-dd43-4959-c952-08d43ee93764 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:QIzyrp+ACEn/2dk2zl9renbAAKHTBPjQqIJAfWRZaM63mzPNwnwgkSWhsRNYHLVhYYVEy1sY3PsxDlpaovD+Q9o68CY6fvwgiu+8bgONcVPy/mU2c/JM5nPwwAWkdx36lqEjNvaiM32mk+dVmAfAo+FxLBUeW7vx/PRTkYL0oMPjsDqzgxl/cSbCzFcbc48RY2dLM3k3UYJ4cYT/zFMN9F48HJiV3Zc/UeT0jlMg94Pu7zwXFz9d40gJHQY0as1kl5Qtqmu5xu6ZHvcQ+prWqJUYVJ/lB5jrW2iSyCdM83548wWxjdrEDjFQCAX1J6zXumM4mHT/Ft54KNpuKaPkP6xt8MfaWS7oIuAVp1zA0ciO7oqmsOeUYCxgMJkPPEbo/owVpq3S63qh5j/ec5bZkOt2yw0lE8WoxDGYUNVwovrIzH/Jb3ejoiS+ivmLm1YPSYuVBfU6DKMwpwbCzu/CrQ==; 20:cREVtqZCIzImAEk834KZ0tBCeUvGikKmwTgL5UizErZusyBS5tpr0vLb+ekfI76HXzbicM3lwVX67EN2l5QK0epT5WU4a3XmlDizJgv0XMyXatzwu7nITNjM3ceN6Arp0erM3jAFl5UJSeJ7ri8v3soFdU1Vkxo3u9tkjioFjWY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(8104003914727); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(24454002)(86362001)(8936002)(8676002)(83716003)(81166006)(74482002)(81156014)(68736007)(6306002)(99286003)(54896002)(54906002)(2171001)(3280700002)(50226002)(33656002)(2906002)(6436002)(6506006)(2900100001)(6116002)(6486002)(229853002)(3846002)(102836003)(4326007)(38730400001)(36756003)(5250100002)(106356001)(106116001)(230783001)(92566002)(5660300001)(82746002)(7736002)(105586002)(93886004)(189998001)(66066001)(76176999)(110136003)(6916009)(50986999)(236005)(3660700001)(101416001)(42882006)(6512007)(97736004)(30001)(57306001)(2950100002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 14:57:54.2642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: K4SXe8myMu-WM9QK8gItyA-1 Content-Type: multipart/alternative; boundary="_000_7024EF45953E4C5B90698B61B7AADCD1jiscacuk_" Archived-At: Cc: Erik Kline , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:58:05 -0000 --_000_7024EF45953E4C5B90698B61B7AADCD1jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDE3IEphbiAyMDE3LCBhdCAxNDozMCwgRGF2aWQgRmFybWVyIDxmYXJtZXJAdW1u LmVkdTxtYWlsdG86ZmFybWVyQHVtbi5lZHU+PiB3cm90ZToNCg0KDQoNCk9uIFR1ZSwgSmFuIDE3 LCAyMDE3IGF0IDQ6MDAgQU0sIDxvdHJvYW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVt cGxveWVlcy5vcmc+PiB3cm90ZToNCj4gV2hhdCBicmVha3MgaWYgYWxsIElJRHMgaW4gZ2xvYmFs IHVuaWNhc3QgYXJlIG5vdCA2NCBiaXRzPyAgRXNwZWNpYWxseSBvdGhlciB0aGFuIFNMQUNDPyAg SSB3b3VsZCBob3BlIHN1Y2ggYSBSRVFVSVJFTUVOVCBoYXMgYSBiZXR0ZXIgbW90aXZhdGlvbiB0 aGF0ICJ3ZSBzYWlkIHNvIi4gIENpdGluZyB0aGUgInJlc3Qgb2YgdGhlIHNwZWNpZmljYXRpb25z IiB3YXMgc2ltcGx5IG15IHNob3J0aGFuZCBmb3IgSSBkb24ndCBzZWUgd2hhdCBlbHNlIGJyZWFr cy4NCg0KUkZDNzQyMSwgc2VjdGlvbiA0LjIuDQoNClRoZXJlJ3MgYWxzbyBhIHNldCBvZiBwb2xp dGljYWwgY29uc2lkZXJhdGlvbnMsIHdoZXJlIG9uZSB0cmllcyB0byBhY2hpZXZlIGJhbGFuY2Ug YmV0d2VlbiB0aGUgcHJvdmlkZXIncyBkZXNpcmUgdG8gaGF2ZSBlZmZlY3RpdmUgYWdncmVnYXRp b24gYW5kIHRoZSBlbmQtdXNlcnMgZGVzaXJlIHRvIGhhdmUgZW5vdWdoIGFkZHJlc3Mgc3BhY2Uu IFdlIHNwZWNpZmljYWxseSB3YW50IHRvIGF2b2lkIHByb3ZpZGVyJ3MgY2hhcmdpbmcgYnkgdGhl IGFkZHJlc3MuDQoNCk8uDQoNCkV4YWN0bHksIGFuZCB0byBtZSBSRkM3NDIxIHNheSB0byBtZSAi SUlEcyBTSE9VTEQgYmUgNjQgYml0cywiIGJ1dCBpdCBkb2VzIG5vdCBzYXkgdG8gbWUgIklJRHMg TVVTVCBiZSA2NCBiaXRzIiwgdGhpcyBpcyBhIHN1YnRsZSBidXQgaW1wb3J0YW50IGRpZmZlcmVu Y2UuICBGdXJ0aGVybW9yZSwgUkZDNzQyMSwgc2VjdGlvbiA0LjMuMiwgYWxzbyBzYXkgdGhlcmUg aXMgb3BlcmF0aW9uYWwgdXNlIG9mIElJRCBvdGhlciB0aGFuIDY0IGJpdHMsIHdoaWNoIHRvIG1l IGRpc3Byb3ZlcyB0aGUgc3RhdGVtZW50ICJJSURzIE1VU1QgYmUgNjQgYml0cyIgYW5kIHNoaWZ0 cyB0aGluZ3MgdG8gIklJRHMgU0hPVUxEIGJlIDY0IGJpdHMu4oCdDQoNCldlbGwsIHdoZW4gd2Ug d3JvdGUgdGhhdCBkb2N1bWVudCwgdGhlIGFpbSB3YXMgdG8gaGlnaGxpZ2h0IHRoZSBwcm9ibGVt cyB5b3UgbWF5IGVuY291bnRlciBpZiB5b3UgZGlkIGdvIG9mZiBwaXN0ZSBpbiB0ZXJtcyBvZiBJ SUQgbGVuZ3RoLiAgSXTigJlzIGp1c3QgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCwgc28gdGhv c2Ug4oCcU0hPVUxEc+KAnSBhcmUgcHVyZWx5IGltcGxpY2l0Lg0KDQpTZWN0aW9uIDQuMy4yIGlz IHB1cmVseSBub3RpbmcgY29tbWVudHMgbWFkZSBvbiB0aGUgNm1hbiBsaXN0IGR1cmluZyBkaXNj dXNzaW9uIG9mIHRoZSBXaHkgLzY0IGRyYWZ0IGFib3V0IHNvbWUgcmF0aGVyIHJhcmUgZGVwbG95 bWVudHMgaW4gdGhlIHdpbGQuICBXZSBzcGVjaWZpY2FsbHkgYXNrZWQsIGlpcmMsIGFib3V0IGtu b3duIG5vbiAvNjQgaG9zdC1iYXNlZCBzdWJuZXR0aW5nLCBhbmQgdGhpcyBzZWN0aW9uIHJlcG9y dHMgb24gdGhlIHJlc3BvbnNlcy4NCg0KU28gbGV0cyBiZSBjbGVhciwgSSdtIG5vdCBzYXlpbmcg dGhhdCB3ZSBzaG91bGQgUkVDT01NRU5EIG90aGVyIHRoYW4gNjQgYml0IElJRHMsIEknbSBzaW1w bHkgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gc2VjdGlvbiAxIGFuZCBzZWN0aW9uIDMgb2YgUkZD IDIxMTkuDQoNClNvLCBJJ20gYXNraW5nIHdoYXQgYnJlYWtzIGlmIHdlIGNoYW5nZSBmcm9tICJJ SURzIE1VU1QgYmUgNjQgYml0cyIgdG8gdGhlIGluIG15IG9waW5pb24gdGhlIG1vcmUgcHJvcGVy ICJJSURzIFNIT1VMRCBiZSA2NCBiaXRzIi4NCg0KU28sIEkgd291bGQgcHJlZmVyOg0KDQogIC4u LiAgRm9yIGFsbCBjdXJyZW50bHkNCiAgIGFsbG9jYXRlZCB1bmljYXN0IGFkZHJlc3NlcywgZXhj ZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0aCB0aGUgYmluYXJ5DQogICB2YWx1ZSAwMDAsIHRoYXQg bGVuZ3RoIHNob3VsZCBiZSA2NCBiaXRzLg0KDQpCdXQsIEknbSB3aWxsaW5nIHRvIGxpdmUgd2l0 aCB3aGF0IEJyaWFuIHByb3Bvc2VkOg0KDQogICAuLi4gRm9yIGFsbCBjdXJyZW50bHkNCiAgIGFs bG9jYXRlZCB1bmljYXN0IGFkZHJlc3NlcywgZXhjZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0aCB0 aGUgYmluYXJ5DQogICB2YWx1ZSAwMDAsIHRoYXQgbGVuZ3RoIGlzIDY0IGJpdHMuDQoNClRoaXMg c2VlbXMgZmluZS4NCg0KVGltDQoNCkJ1dCwgSSBjYW4gbm90IGFjY2VwdCB3aGF0IEVyaWMgcHJv cG9zZWQ6DQoNCiAgIC4uLiAgRm9yIGFsbCBjdXJyZW50bHkNCiAgIGFsbG9jYXRlZCB1bmljYXN0 IGFkZHJlc3NlcywgZXhjZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0aCB0aGUgYmluYXJ5DQogICB2 YWx1ZSAwMDAsIHRoYXQgbGVuZ3RoIGlzIHJlcXVpcmVkIHRvIGJlIDY0IGJpdHMuDQoNClRoYW5r cy4NCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K RGF2aWQgRmFybWVyICAgICAgICAgICAgICAgRW1haWw6ZmFybWVyQHVtbi5lZHU8bWFpbHRvOkVt YWlsJTNBZmFybWVyQHVtbi5lZHU+DQpOZXR3b3JraW5nICYgVGVsZWNvbW11bmljYXRpb24gU2Vy dmljZXMNCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJzaXR5IG9mIE1p bm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgUGhvbmU6IDYxMi02MjYtMDgx NQ0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkgICBDZWxsOiA2MTItODEyLTk5NTINCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0 bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_7024EF45953E4C5B90698B61B7AADCD1jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gMTcgSmFuIDIwMTcsIGF0IDE0OjMwLCBEYXZpZCBGYXJtZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpmYXJtZXJAdW1uLmVkdSIgY2xhc3M9IiI+ZmFybWVyQHVtbi5lZHU8L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBUdWUsIEphbiAxNywgMjAxNyBhdCA0OjAwIEFNLCA8c3BhbiBkaXI9Imx0ciIg Y2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+b3Ryb2FuQGVtcGxveWVlcy5vcmc8L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KJmd0OyBXaGF0IGJyZWFrcyBpZiBhbGwgSUlE cyBpbiBnbG9iYWwgdW5pY2FzdCBhcmUgbm90IDY0IGJpdHM/Jm5ic3A7IEVzcGVjaWFsbHkgb3Ro ZXIgdGhhbiBTTEFDQz8mbmJzcDsgSSB3b3VsZCBob3BlIHN1Y2ggYSBSRVFVSVJFTUVOVCBoYXMg YSBiZXR0ZXIgbW90aXZhdGlvbiB0aGF0ICZxdW90O3dlIHNhaWQgc28mcXVvdDsuJm5ic3A7IENp dGluZyB0aGUgJnF1b3Q7cmVzdCBvZiB0aGUgc3BlY2lmaWNhdGlvbnMmcXVvdDsgd2FzIHNpbXBs eSBteSBzaG9ydGhhbmQgZm9yIEkgZG9uJ3Qgc2VlIHdoYXQgZWxzZQ0KIGJyZWFrcy48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSRkM3NDIxLCBzZWN0aW9uIDQuMi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSdzIGFsc28gYSBzZXQgb2YgcG9saXRpY2FsIGNvbnNpZGVy YXRpb25zLCB3aGVyZSBvbmUgdHJpZXMgdG8gYWNoaWV2ZSBiYWxhbmNlIGJldHdlZW4gdGhlIHBy b3ZpZGVyJ3MgZGVzaXJlIHRvIGhhdmUgZWZmZWN0aXZlIGFnZ3JlZ2F0aW9uIGFuZCB0aGUgZW5k LXVzZXJzIGRlc2lyZSB0byBoYXZlIGVub3VnaCBhZGRyZXNzIHNwYWNlLiBXZSBzcGVjaWZpY2Fs bHkgd2FudCB0byBhdm9pZCBwcm92aWRlcidzIGNoYXJnaW5nIGJ5IHRoZSBhZGRyZXNzLjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJnbWFpbC1IT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpPLjxiciBjbGFzcz0iIj4NCjwvZm9udD48L3NwYW4+ PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ RXhhY3RseSwgYW5kIHRvIG1lIFJGQzc0MjEgc2F5IHRvIG1lICZxdW90O0lJRHMgU0hPVUxEIGJl IDY0IGJpdHMsJnF1b3Q7IGJ1dCBpdCBkb2VzIG5vdCBzYXkgdG8gbWUgJnF1b3Q7SUlEcyBNVVNU IGJlIDY0IGJpdHMmcXVvdDssIHRoaXMgaXMgYSBzdWJ0bGUgYnV0IGltcG9ydGFudCBkaWZmZXJl bmNlLiZuYnNwOyBGdXJ0aGVybW9yZSwgUkZDNzQyMSwgc2VjdGlvbiA0LjMuMiwgYWxzbyBzYXkg dGhlcmUgaXMgb3BlcmF0aW9uYWwgdXNlIG9mIElJRCBvdGhlciB0aGFuDQogNjQgYml0cywgd2hp Y2ggdG8gbWUgZGlzcHJvdmVzIHRoZSBzdGF0ZW1lbnQgJnF1b3Q7SUlEcyBNVVNUIGJlIDY0IGJp dHMmcXVvdDsgYW5kIHNoaWZ0cyB0aGluZ3MgdG8gJnF1b3Q7SUlEcyBTSE9VTEQgYmUgNjQgYml0 cy7igJ08L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCldlbGwsIHdoZW4gd2Ugd3JvdGUgdGhhdCBk b2N1bWVudCwgdGhlIGFpbSB3YXMgdG8gaGlnaGxpZ2h0IHRoZSBwcm9ibGVtcyB5b3UgbWF5IGVu Y291bnRlciBpZiB5b3UgZGlkIGdvIG9mZiBwaXN0ZSBpbiB0ZXJtcyBvZiBJSUQgbGVuZ3RoLiAm bmJzcDtJdOKAmXMganVzdCBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBzbyB0aG9zZSDigJxT SE9VTERz4oCdIGFyZSBwdXJlbHkgaW1wbGljaXQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDQuMy4yIGlzIHB1cmVseSBub3RpbmcgY29tbWVudHMgbWFk ZSBvbiB0aGUgNm1hbiBsaXN0IGR1cmluZyBkaXNjdXNzaW9uIG9mIHRoZSBXaHkgLzY0IGRyYWZ0 IGFib3V0IHNvbWUgcmF0aGVyIHJhcmUgZGVwbG95bWVudHMgaW4gdGhlIHdpbGQuICZuYnNwO1dl IHNwZWNpZmljYWxseSBhc2tlZCwgaWlyYywgYWJvdXQga25vd24gbm9uIC82NCBob3N0LWJhc2Vk IHN1Ym5ldHRpbmcsIGFuZCB0aGlzIHNlY3Rpb24gcmVwb3J0cyBvbiB0aGUNCiByZXNwb25zZXMu Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPlNvIGxldHMgYmUgY2xlYXIsIEkn bSBub3Qgc2F5aW5nIHRoYXQgd2Ugc2hvdWxkIFJFQ09NTUVORCBvdGhlciB0aGFuIDY0IGJpdCBJ SURzLCBJJ20gc2ltcGx5IGRpZmZlcmVudGlhdGluZyBiZXR3ZWVuIHNlY3Rpb24gMSBhbmQgc2Vj dGlvbiAzIG9mIFJGQyAyMTE5LiAmbmJzcDsmbmJzcDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpTbywgSSdtIGFza2luZyB3aGF0IGJyZWFrcyBpZiB3ZSBjaGFuZ2UgZnJvbSAmcXVvdDtJ SURzIE1VU1QgYmUgNjQgYml0cyZxdW90OyB0byB0aGUgaW4gbXkgb3BpbmlvbiB0aGUgbW9yZSBw cm9wZXIgJnF1b3Q7SUlEcyBTSE9VTEQgYmUgNjQgYml0cyZxdW90Oy4gJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+U28sIEkgd291bGQgcHJlZmVyOjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsuLi4m bmJzcDsgRm9yIGFsbCBjdXJyZW50bHk8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7YWxsb2NhdGVkIHVuaWNhc3QgYWRkcmVzc2VzLCBleGNlcHQgdGhvc2UgdGhhdCBz dGFydCB3aXRoIHRoZSBiaW5hcnk8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4mbmJzcDsg Jm5ic3A7dmFsdWUgMDAwLCB0aGF0IGxlbmd0aCBzaG91bGQgYmUgNjQgYml0cy48L3NwYW4+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+QnV0LCBJJ20gd2lsbGluZyB0byBs aXZlIHdpdGggd2hhdCBCcmlhbiBwcm9wb3NlZDo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsuLi4gRm9yIGFsbCBjdXJy ZW50bHk8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YWxsb2NhdGVk IHVuaWNhc3QgYWRkcmVzc2VzLCBleGNlcHQgdGhvc2UgdGhhdCBzdGFydCB3aXRoIHRoZSBiaW5h cnk8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7dmFsdWUgMDAwLCB0 aGF0IGxlbmd0aCBpcyA2NCBiaXRzLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgi IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoaXMgc2VlbXMgZmluZS48L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjhweCIgY2xhc3M9IiI+QnV0LCBJIGNhbiBub3QgYWNjZXB0IHdoYXQgRXJpYyBw cm9wb3NlZDo8L3NwYW4+PGJyIHN0eWxlPSJmb250LXNpemU6MTIuOHB4IiBjbGFzcz0iIj4NCjxi ciBzdHlsZT0iZm9udC1zaXplOjEyLjhweCIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjhweCIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOy4uLiZuYnNwOyBGb3IgYWxsIGN1cnJl bnRseTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDthbGxvY2F0ZWQg dW5pY2FzdCBhZGRyZXNzZXMsIGV4Y2VwdCB0aG9zZSB0aGF0IHN0YXJ0IHdpdGggdGhlIGJpbmFy eTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDt2YWx1ZSAwMDAsIHRo YXQgbGVuZ3RoIGlzIHJlcXVpcmVkIHRvIGJlIDY0IGJpdHMuPC9zcGFuPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZXh0cmEiPlRoYW5rcy48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4tLSA8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyIGNsYXNzPSIiPg0KRGF2 aWQgRmFybWVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+DQpFbWFpbDpmYXJtZXJAdW1uLmVkdTwvYT48YnIgY2xhc3M9IiI+DQpO ZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzPGJyIGNsYXNzPSIiPg0K T2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnIgY2xhc3M9IiI+DQpVbml2ZXJzaXR5 IG9mIE1pbm5lc290YSZuYnNwOyZuYnNwOyA8YnIgY2xhc3M9IiI+DQoyMjE4IFVuaXZlcnNpdHkg QXZlIFNFJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBob25lOiA2MTItNjI2LTA4MTU8YnIg Y2xhc3M9IiI+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA2 MTItODEyLTk5NTI8YnIgY2xhc3M9IiI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PSA8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBj bGFzcz0iIj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBjbGFzcz0iIj5pcHY2QGlldGYub3Jn PC9hPjxiciBjbGFzcz0iIj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7024EF45953E4C5B90698B61B7AADCD1jiscacuk_-- From nobody Tue Jan 17 07:20: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 0DC3C1294D4 for ; Tue, 17 Jan 2017 07:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ys_TLvPuAWpA for ; Tue, 17 Jan 2017 07:20:15 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1AA1294DC for ; Tue, 17 Jan 2017 07:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=er3iaKoWm1RfIQHi5BOTztaecKxadX90mpfOqUcm/Bo=; b=Uldvs0VYnuYWJR/q6lTpqEKulw6RMrfZoptAbXxkiZjqUYSohlgxfWpwkIryLLmwgPy0Bz8e1pXxBnaJJu6Xnarlwh+XfbPBj3sFG7PjapybsJG6i93VOq/ezmbuPQfPU24Y2ko3p8eQlWQxfeFEJZQIU4dlpUF1CHRYbLoiVmU= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0114.outbound.protection.outlook.com [213.199.154.114]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-OHYJpSIUPs2TsMPbasYsww-1; Tue, 17 Jan 2017 15:20:08 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 15:20:07 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480%15]) with mapi id 15.01.0860.008; Tue, 17 Jan 2017 15:20:07 +0000 From: Tim Chown To: Lorenzo Colitti Subject: Re: update to rfc2464bis Thread-Topic: update to rfc2464bis Thread-Index: AQHSari/YDPll7o19EGKcdCJAtd5oKE0Uf6AgAAhY4CAABG5gIAAD/YAgAAKHQCAAAfAAIAADBOAgAAF7ICAAKKEgIAASRKAgAcwaQA= Date: Tue, 17 Jan 2017 15:20:07 +0000 Message-ID: <7E262CA4-3A2B-49CC-A2A6-118F3E33A029@jisc.ac.uk> References: <1E7F90AC-79BB-49BE-B397-EC829EA95AA4@gmail.com> <7456833d-aa3f-d368-6041-cfdc1ac95f6f@si6networks.com> <89fc8838-f6cd-1647-8468-1c8c11466aff@si6networks.com> <33d91d6c-18dc-1ec0-fc4d-edc83a86ce83@si6networks.com> <6ae2b66b-21be-a413-ee59-8aa064e583b7@gmail.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.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 8a05c540-0042-44b2-92b3-08d43eec51f2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1137; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 7:TDISMmkpbssNGy+D3zvAtIc4labVFPltXwmIcrBf9fkkCk64o0FDTKpWrZb2TTKdPp96kl+3goykojdSfJ17BfcbNvTVL0wYRoPNuuFTxRYe2MBRmeBmpNmwptwDozksO5B/wDLafvgLVpfOhqEjec1SqbfuUEmGeu7ON+q2l6H6s4vgPiEWTyDEcNzlyf/qCqtNGz1qZs97jgFNtF6RPEiunnVs0M2zVVIhYYePqGUwFUTHYZOUFnSc6zlLxe5Ub6/8w1/bZBAIfq0X30hWBpH3KOlK8QC12pbABWn2+Qt8iv+hxPAB06/Uhy4Gq2Uo/1lbZmHHYS7bY/QKgXodEBCk+VcMMzlqR83qh8owvEquHCKEEjTHC1GirCb/I/6FYMBpFj6OXpNU8NhAdGTK+pQA0CeudQopuz+BLcH84Wg2NbYgF/p4Kf1ZUQdy0VNVaIZ4F5Pua93v/KG6X0gTbQ==; 20:FxCTt97Nyi3IAVWzZKQSq0CpIttWu1544PUz8uFy3Eet8FQanhAh43vgo56DuMx71qY/D8j/7dq2tKxPxlQPQARZwZUyQH+cuo5/NiLYMzP5tsvpOCErCbmg4sKHQZKhqFu7B4HBCCtjg0I2MaNLdKT0MYI5y9I21BzN7oAfxcw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1137; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(377454003)(189002)(24454002)(105586002)(5660300001)(50986999)(6506006)(106116001)(74482002)(39060400001)(68736007)(102836003)(66066001)(76176999)(36756003)(6486002)(106356001)(38730400001)(6436002)(3660700001)(5250100002)(3846002)(3280700002)(50226002)(606005)(6116002)(7736002)(33656002)(189998001)(81156014)(2900100001)(230783001)(8936002)(236005)(42882006)(82746002)(101416001)(93886004)(6916009)(110136003)(8676002)(15650500001)(10710500007)(7110500001)(6512007)(2950100002)(81166006)(2420400007)(57306001)(54896002)(99286003)(92566002)(7906003)(229853002)(2906002)(86362001)(54906002)(6306002)(4326007)(83716003)(97736004)(30001)(104396002)(16193025007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 15:20:07.2575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137 X-MC-Unique: OHYJpSIUPs2TsMPbasYsww-1 Content-Type: multipart/alternative; boundary="_000_7E262CA43A2B49CCA2A6118F3E33A029jiscacuk_" Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:20:17 -0000 --_000_7E262CA43A2B49CCA2A6118F3E33A029jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCk9uIDEzIEphbiAyMDE3LCBhdCAwMTozMywgTG9yZW56byBDb2xpdHRpIDxsb3Jlbnpv QGdvb2dsZS5jb208bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpPbiBGcmks IEphbiAxMywgMjAxNyBhdCA2OjExIEFNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90 ZToNCkl0IHdpbGwgYnJlYWsgb24gc2l0ZXMgdGhhdCBjaG9vc2UgYSBtYW5hZ2VkIGFkZHJlc3Np bmcgcG9saWN5IChhcw0KVGltIHRvbGQgdXMgdGhleSBkbyBhdCBDRVJOKS4gSSB3b25kZXIgd2hh dCBBbmRyb2lkIHVzZXJzIGF0IENFUk4gZG8/DQoNClByZXN1bWFibHkgdGhleSBnZXQgSVB2NCBv bmx5IGFuZCBkb24ndCBub3RpY2UuIFRoZSBmZXcgdGhhdCBkbywgZGVwZW5kaW5nIG9uIHRoZWly IG9waW5pb25zLCBlaXRoZXIgYXNrIHRoZWlyIG5ldHdvcmsgYWRtaW5zIHRvIGZvbGxvdyB0aGUg YmVzdCBwcmFjdGljZXMgaW4gUkZDIDc5MzQgb3IgZ28gdG8gaHR0cDovL2IuYW5kcm9pZC5jb20v MzI2MjEgdG8gY29tcGxhaW4gYWJvdXQgaXQuIDotKQ0KDQpZZXMsIHRoZXkgb25seSBnZXQgSVB2 NC4NCg0KQXMgZm9yIHRoZSDigJxwZXRpdGlvbuKAnSwgdGhhdCB3YXMgbWFya2VkIGxvdyBwcmlv cml0eSBhbmQgY2xvc2VkIHRocmVlIHllYXJzIGFnbywgc28gSSBhc3N1bWUgZXZlcnlvbmUgaGFz IGdpdmVuIHVwIQ0KDQpCYWNrIG1vcmUgZGlyZWN0bHkgb24gdG9waWMsIGFkZGl0aW9uIG9mIOKA nHN0YWJsZeKAnSBpcyArMSBoZXJlIHRvby4NCg0KVGltDQoNCg== --_000_7E262CA43A2B49CCA2A6118F3E33A029jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <2106B90E3A90A94E8BA86007F550FBCA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gMTMgSmFuIDIwMTcsIGF0IDAxOjMzLCBMb3JlbnpvIENvbGl0dGkgJmx0 OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIGNsYXNzPSIiPmxvcmVuem9AZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmks IEphbiAxMywgMjAxNyBhdCA2OjExIEFNLCBCcmlhbiBFIENhcnBlbnRlciA8c3BhbiBkaXI9Imx0 ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNv bTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpJdCB3aWxsIGJy ZWFrIG9uIHNpdGVzIHRoYXQgY2hvb3NlIGEgbWFuYWdlZCBhZGRyZXNzaW5nIHBvbGljeSAoYXM8 YnIgY2xhc3M9IiI+DQpUaW0gdG9sZCB1cyB0aGV5IGRvIGF0IENFUk4pLiBJIHdvbmRlciB3aGF0 IEFuZHJvaWQgdXNlcnMgYXQgQ0VSTiBkbz88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QcmVzdW1h Ymx5IHRoZXkgZ2V0IElQdjQgb25seSBhbmQgZG9uJ3Qgbm90aWNlLiBUaGUgZmV3IHRoYXQgZG8s IGRlcGVuZGluZyBvbiB0aGVpciBvcGluaW9ucywgZWl0aGVyIGFzayB0aGVpciBuZXR3b3JrIGFk bWlucyB0byBmb2xsb3cgdGhlIGJlc3QgcHJhY3RpY2VzIGluIFJGQyA3OTM0IG9yIGdvIHRvDQo8 YSBocmVmPSJodHRwOi8vYi5hbmRyb2lkLmNvbS8zMjYyMSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmh0dHA6Ly9iLmFuZHJvaWQuY29tLzMyNjIxPC9hPiB0byZuYnNwO2NvbXBsYWluIGFib3V0 IGl0LiA6LSk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlllcywgdGhleSBvbmx5IGdldCBJUHY0 LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QXMgZm9yIHRoZSDigJxw ZXRpdGlvbuKAnSwgdGhhdCB3YXMgbWFya2VkIGxvdyBwcmlvcml0eSBhbmQgY2xvc2VkIHRocmVl IHllYXJzIGFnbywgc28gSSBhc3N1bWUgZXZlcnlvbmUgaGFzIGdpdmVuIHVwITwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QmFjayBtb3JlIGRpcmVjdGx5IG9uIHRvcGlj LCBhZGRpdGlvbiBvZiDigJxzdGFibGXigJ0gaXMgJiM0MzsxIGhlcmUgdG9vLjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGltPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7E262CA43A2B49CCA2A6118F3E33A029jiscacuk_-- From nobody Tue Jan 17 09:39: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 4BD5E129587 for ; Tue, 17 Jan 2017 09:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYBgDR_Eu-wU for ; Tue, 17 Jan 2017 09:39:53 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 C7F6B129564 for ; Tue, 17 Jan 2017 09:39:52 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id z134so110775828lff.3 for ; Tue, 17 Jan 2017 09:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=d6hqmIayYscA/YVPiNnWCJMNCrRJuKhgOP9d6DQhdqM=; b=TSrRXmfh3P7dfm46KUkzGybsPNDQw0C9NEl9ladywfliCxGuMGzyTa9vxRKvcHFyqt 5Ezo2LMV5sXpM24ua3mdK+T7GD8cx4MY/hrY0fo+iOcV7YxeTYk92EE5+U3bcgEXDhuQ pk8oiRiahALQpxUgRmSY7JbY0/QkgG0kVHybQtgr+Lw717knyUNiyhtkUHgkG4rww6DV 85nW+9U7omO26oVgLm8f1unlqsbJjK1IZHPblYKLrAIgZN5NJnKFmrZOOHR6HalLdGQ9 l1n6vJcLBjXOzQJ05PtxC3fuoylHDSFehvrrJ8p8guHHJ/qZrrpbt8ERicoJAlisXqAM J6nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=d6hqmIayYscA/YVPiNnWCJMNCrRJuKhgOP9d6DQhdqM=; b=jVtgor5D4iXwLmnVjvZtrTrnHcBkk5extT1UHHCzcFGt9A71XqJda0YU8a/FP2kS0A EXXAeE4H4Ow2dPPwAwRQhBYK8zZg+SiW7Leim7OLYbruduTUaRxT0C2WPlkAfTVQaIiS fPao3vrTC3Bek37WMxhG62/lmaRBMZRDu49g30WkfF+e7h1Yn1Pm4VN1gI0/efW3VR92 FwgOW1/qLBbdvaiH2GNDQ2/ixUQon8DgUGKFi0WktO45lh56mrkVM8UU8SqoDfw4d1MU 6EIEhQXKX+KUV7LeyHClulrhjiYGBxBUcLJIjEhJUV3ntgOxjyzNRL+2zPExpodCCym9 cMIw== X-Gm-Message-State: AIkVDXJ/SY98bYuT1DMUrSzRe2kG9/nPf5udAZAaCOvK0Mj11uITBmttHmgRcsEr7yzwx7K0FnzJxcnxXVh6YQ== X-Received: by 10.46.76.10 with SMTP id z10mr12199002lja.9.1484674790677; Tue, 17 Jan 2017 09:39:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Tue, 17 Jan 2017 09:39:49 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> From: Behcet Sarikaya Date: Tue, 17 Jan 2017 11:39:49 -0600 Message-ID: Subject: Re: IID length text To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:39:54 -0000 On Mon, Jan 16, 2017 at 4:09 PM, Fernando Gont wrot= e: > On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: >> On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont w= rote: >>> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>> wrote: >>>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>>>> >>>>>> A modest suggestion: >>>>>> >>>>>> OLD >>>>>> For all unicast addresses, except those that start with the binar= y >>>>>> value 000, Interface IDs are required to be 64 bits long. Backgr= ound >>>>>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421= ]. >>>>>> >>>>>> NEW >>>>>> IPv6 routing is based on prefixes of any valid length up to 128 >>>>>> [BCP198]. >>>>>> For example, [RFC6164] standardises 127 bit prefixes on point-to= -point >>>>>> links. However, consistent use of Stateless Address Autoconfigura= tion >>>>>> (SLAAC)[RFC4862] requires that all interfaces on a link use the s= ame >>>>>> length >>>>>> of Interface ID. In practice, this means that to guarantee >>>>>> interoperability >>>>>> of SLAAC, a fixed length of Interface ID is necessary. For all >>>>>> currently >>>>>> allocated unicast addresses, except those that start with the bin= ary >>>>>> value 000, that length is 64 bits. Note that this value is an arb= itrary >>>>>> choice and might be changed for some future allocation of unicast >>>>>> address >>>>>> space. Background on the 64 bit boundary in IPv6 addresses can be= found >>>>>> in [RFC7421]. >>>>> >>>>> >>>>> I agree with the change suggestion. The new text and references are = enough >>>>> motivation to clarify that that 64bit limit is an arbitrary choice an= d might >>>>> change in the future. >>>>> >>>> >>>> 3GPP assigns 64 bit prefixes to each UE. >>>> Extended Unique Identifiers defined are EUI-48 and EUI-64. >>> >>> What does a layer-2 EUI have to do with a layer-3 address? >> >> I don't know, you tell me :-) > > Answer: Nothing. The fact that we've been embedding layer-2 "addresses" > into layer-3 addresses should not be taken as a reason for the two of > them of having to do anything with each other. So, yes, the 64-bit IID > length is, in reality, arbitrary. They could have been e.g. 32-bits or > 48-bits (yes, multiples or 64 or 32 tend to be nicer) > I don't think you know much about MAC addresses and its history. Behcet > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Tue Jan 17 12:10: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 DB07A1293EC for ; Tue, 17 Jan 2017 12:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7E9Vd9_ncBu for ; Tue, 17 Jan 2017 12:10:21 -0800 (PST) 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 A91A5127077 for ; Tue, 17 Jan 2017 12:10:21 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id e4so25944089pfg.1 for ; Tue, 17 Jan 2017 12:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R8IuHgEphoU/bayA4u3KCb9cDrCXxqNPGqapYoXBED4=; b=lvgq/onJ84+lYcA+QW2ibMvOGZ0OSPp5BiedVZ1FYMQWbxBn+/L7i5C1L6+2vngbVx 5llrhCL3ZTkFlNa82+SFhKk6SbaxqTrDFCO9iM44Pl3FeXWCBPtuQuwO2FFzCSX8GUvk 15fZWHG4WPNnD7j8hYo/wtiZXEWnc2iusstm+0YHq+0mt40mhhNR8dOBY1Sml7RB8a0T ZhTY9SW1Ja2qy64hhGmZIh9gK4Kd34JyCFZleU0jKBg5OEzYnXOtfZfjStrhh56poaYT c2ukVg8xWilM4NDe25HN7mHFrtCQmJSknWujPRwOanlrWE3U31aPA+UwRC628Nfti2pf XN8A== 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=R8IuHgEphoU/bayA4u3KCb9cDrCXxqNPGqapYoXBED4=; b=sXls/0nef/mD0oT6WmfkED8VInlAxc7N8Ijv+IPJg2fguK2VLvPETlcyRnnqkRonby u4agz8aCT8KkcLzHTkhSFOav2P78IQ00DNb0XwMPDCh0s7E8YlnNlCdCY060jmjCn4Kv K+XqSyyHnQS0dym7bysS85eWuPI6MrDliLLmKUttDX0RxtqSFpvGw2nzBK5WySPCBepM 4KK+JzxRnZkEq+sexCJ5+QfytbYabDO6VBznFIXuYRBfXWYlfVAi1pO/C1X+dwcLDMa3 XE0gqXSYTx8ygatlMcQi0f8ECSSrRwX1qm753AyMw/JYEe3BWc7hINZup3NQD3xrv/Pe jksg== X-Gm-Message-State: AIkVDXInJNBLatZU/hxdRiIslMNCFu3PeNArGEdyFQVDS4obenC8eb7gV9Ka/iv+nN9uTg== X-Received: by 10.84.206.37 with SMTP id f34mr61390692ple.35.1484683821301; Tue, 17 Jan 2017 12:10:21 -0800 (PST) Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id j7sm44926115pfe.84.2017.01.17.12.10.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 12:10:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] From: Fred Baker In-Reply-To: Date: Tue, 17 Jan 2017 12:10:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5FCF2986-2CED-4573-B87D-7788DA5C354D@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> To: David Farmer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Erik Kline , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:10:23 -0000 On Jan 16, 2017, at 9:35 PM, David Farmer wrote: > What breaks if all IIDs in global unicast are not 64 bits? Especially = other than SLACC? To my knowledge, the only device that cares about the length of the IID = is the device that inspects it, uses it, or supplies it. That would be, = in most cases, functionality on the actual host and (perhaps) the router = in front of it. There are additional services such as 802.1X or DHCP. = Each of those cares about a 128 bit address, not an IID. Everything that = doesn't care about a 128 bit address per se cares about a prefix, and = the prefix [RFC7608] may have any length from 0 to 128 bits. The one thing I can think of that cares about an IID separately from an = address is SLAAC.= From nobody Tue Jan 17 13:17: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 4CF38129495 for ; Tue, 17 Jan 2017 13:17:13 -0800 (PST) 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 Yksih0kBbNru for ; Tue, 17 Jan 2017 13:17:10 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787321294FC for ; Tue, 17 Jan 2017 13:17:09 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 12EB182B22; Tue, 17 Jan 2017 22:17:05 +0100 (CET) From: Fernando Gont Subject: Re: IID length text To: sarikaya@ieee.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 17 Jan 2017 17:55:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:17:13 -0000 Hello, Behcet, On 01/17/2017 02:39 PM, Behcet Sarikaya wrote: > On Mon, Jan 16, 2017 at 4:09 PM, Fernando Gont wrote: >> On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: >>> On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont wrote: >>>> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>>> wrote: >>>>>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit : >>>>>>> [....] >>>> >>>> What does a layer-2 EUI have to do with a layer-3 address? >>> >>> I don't know, you tell me :-) >> >> Answer: Nothing. The fact that we've been embedding layer-2 "addresses" >> into layer-3 addresses should not be taken as a reason for the two of >> them of having to do anything with each other. So, yes, the 64-bit IID >> length is, in reality, arbitrary. They could have been e.g. 32-bits or >> 48-bits (yes, multiples or 64 or 32 tend to be nicer) >> > > I don't think you know much about MAC addresses and its history. I don't know much about elephants, either. Whatever the history (which you imply I don't know), it is irrelevant, because it doesn't change the fact that you don't need to screw your layer-3 protocol with your layer-2 IDs/"addresses". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 13:31:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0B129502 for ; Tue, 17 Jan 2017 13:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBncZaNI-d-H for ; Tue, 17 Jan 2017 13:31:04 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 5FFB6129495 for ; Tue, 17 Jan 2017 13:31:04 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id v186so118955789lfa.1 for ; Tue, 17 Jan 2017 13:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=28U29E4CXQxqK9b8ALyHr/t9qnUMTt00JzF63YC6kZM=; b=eKEaG1huPJZhKphSulK4Ko6C78ME9tV5PP/ax4j2Pt+wDAYMawt+uLPAp9TleQdVGm qu2cJ+2mT5vxtUeOkuuLrQir3zgfU+6FaZH69JZWUXu46mHyMx4araTLcnpcSuo7sZVM 1PRScVz9qHWeWhFEiQmwdozWskngMUATFpD4nm1CsyHP4EctuiTCbmkKzeERY/Qo95Hk xmnYp01mQIeAm8lo6WP5GqFYo4xGgcTAX+zosl3E6jBqJPhYPoAXNih/kXA5PgACdAJ1 WcQjMp8txPojsEWVrfXBt2sTRj3tUyREe33T0cIG/A1RAOWFuXsNRIVT50ogk1P0nLKx ix6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=28U29E4CXQxqK9b8ALyHr/t9qnUMTt00JzF63YC6kZM=; b=UkVLDlT2IReMn0yTclfe6TmNG5Q9PuHY58AN5XnJgY15oOyDcBJNAFhrYUdLqmVd/5 sLVsQZ9c8hNKzNDSGS1wezN13A1eDbUiaran0THb3qf0FF0bddQxADWbmkl5emsgKaDu dWQP8OtqL9Rtp0zqeXIm5MGurvyFZqlx6NO2uRQsNcye+qrDIlep8MEuWITB4YayLJpu P0otxDomiMDq1dpe2DGp9AD3Rh+EC2Te/ARMscA1BBObce+5w1IfQPWA+m/fI8fv9yMv bMEtw0gnrs0Vk7AdjwP7X51iXSKpa8LDtnBGTUTkCAea5Z32x8oBeWZNdhKzR+HQMm3Y aKVw== X-Gm-Message-State: AIkVDXJkmT0ozpWc3j9bwElPeVbzoWDrGXSvuKPA0/oRpBH/5ro44HAcfdtms0E+RcNuiWFxTdaX5geySoZoVQ== X-Received: by 10.46.21.72 with SMTP id 8mr5921479ljv.11.1484688662431; Tue, 17 Jan 2017 13:31:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Tue, 17 Jan 2017 13:31:01 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> From: Behcet Sarikaya Date: Tue, 17 Jan 2017 15:31:01 -0600 Message-ID: Subject: Re: IID length text To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:31:06 -0000 On Tue, Jan 17, 2017 at 2:55 PM, Fernando Gont wrot= e: > Hello, Behcet, > > On 01/17/2017 02:39 PM, Behcet Sarikaya wrote: >> On Mon, Jan 16, 2017 at 4:09 PM, Fernando Gont w= rote: >>> On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: >>>> On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont = wrote: >>>>> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>>>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>>>> wrote: >>>>>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>>>>>> > [....] >>>>> >>>>> What does a layer-2 EUI have to do with a layer-3 address? >>>> >>>> I don't know, you tell me :-) >>> >>> Answer: Nothing. The fact that we've been embedding layer-2 "addresses" >>> into layer-3 addresses should not be taken as a reason for the two of >>> them of having to do anything with each other. So, yes, the 64-bit IID >>> length is, in reality, arbitrary. They could have been e.g. 32-bits or >>> 48-bits (yes, multiples or 64 or 32 tend to be nicer) >>> >> >> I don't think you know much about MAC addresses and its history. > > I don't know much about elephants, either. Whatever the history (which > you imply I don't know), it is irrelevant, because it doesn't change the > fact that you don't need to screw your layer-3 protocol with your > layer-2 IDs/"addresses". > Good luck then running SLAAC or ARP :-) Regards, Behcet > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Tue Jan 17 13:32: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 0B5A31295B5 for ; Tue, 17 Jan 2017 13:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt73Kt_yMMSN for ; Tue, 17 Jan 2017 13:32:36 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id D57911294FC for ; Tue, 17 Jan 2017 13:32:36 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 17 Jan 2017 21:32:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EDBE2D788A; Tue, 17 Jan 2017 13:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=6D+wnJjPlccjCCQtG4GUI+KlRrY=; b=AqV4Iw0RU11iiKX3eL UcZzsk5cgdEbaU2yXDsC5omJVobeQCXds2RE3Bng+S9Q7SnD8S8pZv6/lq7YY3mm DX3JWKL3WsMD3BhNHVfmMX3N9vbBtueHkf+BBdMfePBsgrIRdDJfXD9BYbNUQhYl 1eHy9eDx1CN/FgTm8FLdnUpb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=rfTXfaXDP2rSoJ78miVQjRGg3kHfcwEro+8JK67pIg+yf/GJF1P W88eH5zHIa2au4i2+mdsgHm3O9VdzF6vxIUO3eBLGHeG+EP3SLiYVapSN8XXoY8G 8cUWh+csmCOY2ngjDKDcmWYbx9eAsmko830M87bU4YDFjIC8sKpV/05g= Received: from h.hanazo.no (unknown [46.228.50.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 6BC53D788D; Tue, 17 Jan 2017 13:32:35 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2E4BD767C827; Tue, 17 Jan 2017 22:32:33 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] From: otroan@employees.org In-Reply-To: Date: Tue, 17 Jan 2017 22:32:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> To: David Farmer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Erik Kline , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:32:38 -0000 I would argue that we should not make any changes to this text (apart = from the eui-64 part). Cheers, Ole > On Tue, Jan 17, 2017 at 4:00 AM, wrote: > > What breaks if all IIDs in global unicast are not 64 bits? = Especially other than SLACC? I would hope such a REQUIREMENT has a = better motivation that "we said so". Citing the "rest of the = specifications" was simply my shorthand for I don't see what else = breaks. >=20 > RFC7421, section 4.2. >=20 > There's also a set of political considerations, where one tries to = achieve balance between the provider's desire to have effective = aggregation and the end-users desire to have enough address space. We = specifically want to avoid provider's charging by the address. >=20 > O. > =20 > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it = does not say to me "IIDs MUST be 64 bits", this is a subtle but = important difference. Furthermore, RFC7421, section 4.3.2, also say = there is operational use of IID other than 64 bits, which to me = disproves the statement "IIDs MUST be 64 bits" and shifts things to = "IIDs SHOULD be 64 bits." >=20 > So lets be clear, I'm not saying that we should RECOMMEND other than = 64 bit IIDs, I'm simply differentiating between section 1 and section 3 = of RFC 2119. =20 >=20 > So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to = the in my opinion the more proper "IIDs SHOULD be 64 bits". =20 >=20 > So, I would prefer: >=20 > ... For all currently > allocated unicast addresses, except those that start with the = binary > value 000, that length should be 64 bits. >=20 > But, I'm willing to live with what Brian proposed: >=20 > ... For all currently > allocated unicast addresses, except those that start with the = binary > value 000, that length is 64 bits. >=20 > But, I can not accept what Eric proposed: >=20 > ... For all currently > allocated unicast addresses, except those that start with the = binary > value 000, that length is required to be 64 bits. >=20 > Thanks. > --=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 =20 > 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 From nobody Tue Jan 17 14:28: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 809991294D3 for ; Tue, 17 Jan 2017 14:28:57 -0800 (PST) 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 lDN30DrjjE8c for ; Tue, 17 Jan 2017 14:28:56 -0800 (PST) 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 793191294A1 for ; Tue, 17 Jan 2017 14:28:56 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id t6so22642834pgt.3 for ; Tue, 17 Jan 2017 14:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=w0+U/MV1EXCHuEtKwqb/GSVUaHZC/PqNjGuQ0NEvCb0=; b=crQjIBR5CUzy5kt9cNRVe6PKdrntHXj3MDFJiSF3ScUhevBb1hpgV/rCuYKlSln3MZ YJvI9jcMBjXpia/QI7k4DT9LKePQYDTFViG7EhE6VySHb55giywFbiihQuRSSQG9BLl9 PnuCplx0hjR8QacMfbLNfTwO/uWwLwJ/00DsLwOLbyGgflfu7lyR43UEq/LIaa/YvVaF yPoWeoijau6c+aM8j46wf4YYGwe41bxbJl9KW0w0+tpOlmtqLFKm9JVtTiRSvovjTmpf 14IZs4SMUkbi4CTIR+wubz3Nzj88jxOB/iiyUYYIyb5/6hEp49tccZbENgYk0ZuFwKDD 91zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=w0+U/MV1EXCHuEtKwqb/GSVUaHZC/PqNjGuQ0NEvCb0=; b=HQorK/oLRAa5azQQNwKzC47As+MKZatsoudxIF9cyKXjam8H9Z1v6e4JjLqWMEpWAw BT2tmz5BTIPyL5Euf5+/f5j5VHUNMXigDAdYiHt7zmN1nafmpeh93xEecXHeTq3SC31p rYF/llfW4SZFBYXvfMytSESmm/iuN1l3qk07nG1dI6B3wh2BVVTJs3JubnEt+ttArmHN ZSfwd8eG7W4DyXbfbVur+aZBrFHc/fbUdenmvrmBuxa4KAUcdJkuUWbhYIxA50B8cvps Bf9ZfhJLMHv+23NYD52W8x9hck2VJY4KW41L82ttOJ4W8MU42tzzxgYIgYQYzYKjku5C q0Kg== X-Gm-Message-State: AIkVDXI7/ZaxezmPGeXi11MH26u5CFo6P6kIrC49Hnw7kxctacM/bXgqVOtVsZIj8xWWgw== X-Received: by 10.84.197.131 with SMTP id n3mr30403pld.6.1484692135897; Tue, 17 Jan 2017 14:28:55 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.53]) by smtp.gmail.com with ESMTPSA id a68sm58445556pgc.31.2017.01.17.14.28.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 14:28:55 -0800 (PST) Subject: Unclear text [was IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]] To: ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 18 Jan 2017 11:28:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:28:57 -0000 On 17/01/2017 17:52, Lorenzo Colitti wrote: ... > "Not clear" != "faulty". On the contrary, in a standards document, "Not clear" == "faulty" Really. If we publish text that is logically correct but can easily be misread (or, of course, text that is ambiguous) then it's faulty text. (On a personal note, I have always tried to discipline myself thus: if *anybody* misinterprets some text that I wrote, however clear I believe it to be, then it's the text that needs fixing, not the reader.) Brian From nobody Tue Jan 17 14:37: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 EF606129535 for ; Tue, 17 Jan 2017 14:37:38 -0800 (PST) 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 aFWbg_fzA6n0 for ; Tue, 17 Jan 2017 14:37:37 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8D81294D3 for ; Tue, 17 Jan 2017 14:37:37 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 14so27954234pgg.1 for ; Tue, 17 Jan 2017 14:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=I4GmebPtb8NMfWDBH/8jT6vkhCu90s2N4aPgwfnGoeo=; b=nncq4KLzHOCIC+XcM488XYUoytD6kqUhE8vg9xaMBZkt/FNNvRlEnTSjPR//jvrGcz sNQ93c2TS1jTU9fKiV5PemxLrxpD/jxelZg5CMk1cVUAqW7HmhNMGbYQKC9NC9OpVl3D 5C0ifCuwi12TZicpqm/kJmDewij79NRQbwdwmA+f3JeZWXR9UdH6898+9rl3s6BXrUPe XQEB6elaTgkytbX600KEAGxHE7RFRuX30Am7vP5sdUjvYe+UjTtQa41SVc5LGpb6E07U w9WkFm8jMm/66IWwbK1EEjMy7dUSYs87WsQBhH3qnTRXp9RH4r6o2R1pbXZIQcI/ZVo4 r11A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=I4GmebPtb8NMfWDBH/8jT6vkhCu90s2N4aPgwfnGoeo=; b=GwzePTKM8d9rSTgl0Jn2T23Nq+7lHYdrrZwcBK9tVfXGDVsyqDL2GIS6PEr6BHTRgs QouBj82fEx6DpYhDpBQyyUVD2FMFbeLy5jHNGG8W6g7TNeLarNvktAPOrYDIftWsnHFh 4KrElwyDeGtUgXi3ioAKcj7CnYItSjGoOqspUKDDpoEqWzS4kDAUdkxeEmldZ4LjOkkw /K9xhHWZ2hCQqkMQVEMm+OmQaFmBJjw0C++7mijQikDVZBcb8qQ7gn08acNQZAyBCtqO fgBUg94kwkdRu+syDTGGydWupsaazNHmXownBtyATf40/U0/CvsgbAUvxqQufgfrmqFY 8FBQ== X-Gm-Message-State: AIkVDXI/UlkULQGK05KTDziCLkHbYXPLyjL0EOWS1ce/eFpX6LNTGcjK9nnM3UJ9XDzqUA== X-Received: by 10.98.41.3 with SMTP id p3mr63269pfp.22.1484692656342; Tue, 17 Jan 2017 14:37:36 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.53]) by smtp.gmail.com with ESMTPSA id o24sm58093844pfj.78.2017.01.17.14.37.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 14:37:35 -0800 (PST) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> Date: Wed, 18 Jan 2017 11:37:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:37:39 -0000 On 18/01/2017 10:32, otroan@employees.org wrote: > I would argue that we should not make any changes to this text (apart from the eui-64 part). I think that the discussion on the IETF list has already shown that there is no consensus for the current text. I don't agree with it any more, either. It hides the tension between CIDR and the consistent length needed for SLAAC. Hence I'm still proposing that we change it. I think the median view at the moment is for the version that runs ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length should be 64 bits. Brian > Cheers, > Ole > > > >> On Tue, Jan 17, 2017 at 4:00 AM, wrote: >>> What breaks if all IIDs in global unicast are not 64 bits? Especially other than SLACC? I would hope such a REQUIREMENT has a better motivation that "we said so". Citing the "rest of the specifications" was simply my shorthand for I don't see what else breaks. >> >> RFC7421, section 4.2. >> >> There's also a set of political considerations, where one tries to achieve balance between the provider's desire to have effective aggregation and the end-users desire to have enough address space. We specifically want to avoid provider's charging by the address. >> >> O. >> >> Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to me "IIDs MUST be 64 bits", this is a subtle but important difference. Furthermore, RFC7421, section 4.3.2, also say there is operational use of IID other than 64 bits, which to me disproves the statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 bits." >> >> So lets be clear, I'm not saying that we should RECOMMEND other than 64 bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC 2119. >> >> So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to the in my opinion the more proper "IIDs SHOULD be 64 bits". >> >> So, I would prefer: >> >> ... For all currently >> allocated unicast addresses, except those that start with the binary >> value 000, that length should be 64 bits. >> >> But, I'm willing to live with what Brian proposed: >> >> ... For all currently >> allocated unicast addresses, except those that start with the binary >> value 000, that length is 64 bits. >> >> But, I can not accept what Eric proposed: >> >> ... For all currently >> allocated unicast addresses, except those that start with the binary >> value 000, that length is required to be 64 bits. >> >> Thanks. >> -- >> =============================================== >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jan 17 15:22:32 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 EDA071293F3; Tue, 17 Jan 2017 15:22:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rdnss-rfc6106bis-15.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148469534697.32075.7711094326379336169.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 15:22:26 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:22:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Router Advertisement Options for DNS Configuration Authors : Jaehoon Paul Jeong Soohong Daniel Park Luc Beloeil Syam Madanapalli Filename : draft-ietf-6man-rdnss-rfc6106bis-15.txt Pages : 17 Date : 2017-01-17 Abstract: This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rdnss-rfc6106bis-15 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 Tue Jan 17 16:16: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 2BA7E1293EB for ; Tue, 17 Jan 2017 16:16:36 -0800 (PST) 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 5ISxhshrQchm for ; Tue, 17 Jan 2017 16:16:34 -0800 (PST) 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 C70731293E9 for ; Tue, 17 Jan 2017 16:16:34 -0800 (PST) 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 v0I0GXoB042825; Tue, 17 Jan 2017 17:16:34 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0I0GTJd042430 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2017 17:16:29 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 Jan 2017 16:16:28 -0800 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.1178.000; Tue, 17 Jan 2017 16:16:29 -0800 From: "Manfredi, Albert E" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Topic: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Index: AQHSbp9rq4yOVtIe6EmSDRf4sDXhe6E7YP0AgACtg4CAAFbEAIAAE6IAgAAFGACAACBcgIAABWoAgAAME4CAAEougIAASzmAgAB2CwCAABIuAP//j4lw Date: Wed, 18 Jan 2017 00:16:28 +0000 Message-ID: <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> In-Reply-To: <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:16:36 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > I think that the discussion on the IETF list has already shown that there= is > no > consensus for the current text. I don't agree with it any more, either. I= t > hides > the tension between CIDR and the consistent length needed for SLAAC. >=20 > Hence I'm still proposing that we change it. I think the median view at t= he > moment > is for the version that runs >=20 > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length should be 64 bits. I think that as things are today, for unicast addresses allocated that may = use SLAAC, the "should" might not be strong enough. We have no other implem= entation of SLAAC, other than one that uses 64-bit IIDs. But I agree with y= ou, when you said that future implementations may not require 64-bit IIDs f= or SLAAC. But I completely concur with your point about tension with CIDR. In fact, o= ne thing that has always bothered me about the wording "all currently alloc= ated unicast addresses, except those that start with the binary value 000,"= is that it sounds like the 64-bit IID rule holds for the majority of the u= nicast address space. But that's not true. Only 1/8 of the total address sp= ace is "currently assigned to unicast," and a subset of that 1/8th has the = stipulation that the IIDs can be of any length. But the majority of the unicast address space is unconstrained, as it shoul= d be. Somehow, it always ends up sounding the 64-bit IID is a fixture, in m= ost IPv6 unicast. Bert From nobody Tue Jan 17 17:19: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 D47FA12948C for ; Tue, 17 Jan 2017 17:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xHdjuW7wD68 for ; Tue, 17 Jan 2017 17:18:56 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA9C12949F for ; Tue, 17 Jan 2017 17:18:56 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id t6so23706755pgt.3 for ; Tue, 17 Jan 2017 17:18:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=i0qxZcAjzk0WIDgSuT+/uG7eB0Gx6H6qa+w5y/SogD4=; b=v7doMdIFjT9UK9y0M1h3WPsneEMojC14KvtZ6oSjl0L2jGrWMNJ8ZUF8GBgIXO0PC5 L5MGuq6T37I69wATzjxuDUsdxYEooe3H/s07bMcJVersGOvFz7f877peF6ql6wAZdSMn pWI38kTk0pDy4RQgPqQqOVPnaGJD9+UMhAPKQMV2Hi2r2V9dXb2oC0OYPX/Fa1OQcrSh gfPhyfMYgv1HpOZSckUUApTc2LfuTa0xfHneL2xTGCViXAPjIvWl19k1t7e5eWFhy8Sp QJRmSB7VN6HUw3NYy5uFsXAV8AjCtNPrnyVRXZ59V9Tw9VL3wILgkvbkE45AQzIWnR/M Ghqg== 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 :content-transfer-encoding:message-id:references:to; bh=i0qxZcAjzk0WIDgSuT+/uG7eB0Gx6H6qa+w5y/SogD4=; b=fFjKtjAAxdQTSL9ld2iFcw4hiUEYetPskqDR+nKJ9vVg/LA2V6qhHYBQFpXhXd3kiY w5rbV+g8heJz95bKhM1dSn7USjUHOozX/Vp38EX/7jaeWQP+fsnFmzS/7NREdXD2K+Xv o5ARLv31MlvhzfoUDK8zQ5fbQVLXgoTl0sLrR8Skv4OPXbFz+SHSWnDjjeiIK9gLO9jF 0ejD+JBUgStz1Zff5PCmi4mZxaMAnFwcRIr7NEtwh8r2SoKZYn/nyTN5dAeGYOP6TFN8 tImR77sbIkUdBmyZ0LGV4vVBOPaD2fVaTcaotw0pwFFmX3+o65Cna4mHytny4jvGLtif Iuzg== X-Gm-Message-State: AIkVDXJZNExbpKaNrUw0AjXN4Ez2FAuWo4QU4vEHeMjL2VVwfar+xV3WmpbUPdoV+U+wqzSc X-Received: by 10.84.171.195 with SMTP id l61mr1015672plb.84.1484702335930; Tue, 17 Jan 2017 17:18:55 -0800 (PST) Received: from ?IPv6:2620::10e7:10:1deb:c2e4:c17b:3951? ([2620:0:10e7:10:1deb:c2e4:c17b:3951]) by smtp.gmail.com with ESMTPSA id n86sm58521722pfb.45.2017.01.17.17.18.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Jan 2017 17:18:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Int-area] Route Information Options in Redirect Messages From: james woodyatt In-Reply-To: Date: Tue, 17 Jan 2017 17:18:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: 6man WG , INT Area X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:18:59 -0000 On Jan 9, 2017, at 11:53, Templin, Fred L = wrote: > On Monday, January 09, 2017 11:02 AM, james woodyatt = wrote: >>=20 >> p2. Section 3.3, Host Specification says this: >>=20 >>>> In light of these considerations, a "Type C" host that receives a >>>> Redirect message containing RIOs adopts the combined behaviors of >>>> both of these specifications. Namely, the host updates its = neighbor >>>> cache entry for the Target and updates its routing table per the >>>> included RIOs. If the Destination address is not the unspecified >>>> address, the host further updates its destination cache. >>>>=20 >>>> Note that "Type A'" and "Type B" hosts ignore any RIOs and = process >>>> the Redirect message according to Section 8.3 of [RFC4861]. >>=20 >> And I wonder if you have considered the possibility of a =E2=80=9CType = D=E2=80=9D host, which in my conception would be capable of *only* = processing >> RIO options that appear in ND Redirect messages and *not* in RA = messages. >=20 > Had not considered that, but I don't see a problem with it. FWIW, the = 'Type A/B/C' comes from RFC4191 in case others are wondering. >=20 >> I=E2=80=99m not sure that=E2=80=99s a type of host we want to = encourage, >> but the idea of its possibility was one of the first things that = sprang to mind when I contemplated the reasons why so few Type C hosts >> are currently deployed in the wild after more than a decade since RFC = 4191 was published. >=20 > I am interested in usage inside of a managed network, and not so much = about > deployment in the wild. Inside of a managed network, the network = administrators > could enable this function among the deployed hosts to provide the = network with > a means to manage routing information for more-specific routes. Yes, well, as you might imagine, I=E2=80=99m interested in behavior of = commodity hosts on unmanaged networks. As far as I know, the most common types of commodity host = implementations are Type B at this point. Yes, I know at least one has a = configurable option to enable Type C behavior, but Type B is the = default, and it=E2=80=99s also rarely changed in managed host = configurations for mobile workstations and personal devices. I believe host implementations have not adopted Type C default behavior = because of security concerns on unmanaged networks like public Wi-Fi = hotspots, where the damage potentially caused by so-called =E2=80=9Crogue = routers=E2=80=9D is already perceived to be unacceptably high. The = theory being that adding support for processing RIO options would = further lower the network costs of mounting such attacks, in exchange = for a questionably valuable route optimization from hosts to possibly = illegitimate routers. I=E2=80=99m not a big fan of this line of = reasoning, but I=E2=80=99ve often seen it used to counter arguments that = adding default Type C behavior would be a good idea. A better argument against RIO options in RA Messages, as far as I=E2=80=99= m concerned, is that RA Guard [RFC6105] functions are often deployed in = L2 switching fabrics, and they=E2=80=99ll drop all the RA Messages from = most routers other than the protected default routers, which are likely = to be the ones advertising more specific routes. With ND Redirect = Messages, network operators can still have a reasonable assurance that = hosts never update their routing tables except at the initiation of one = of the legitimate default routers, which are protected by RA Guard. In light of that, I would suggest defining two new types of behavior, = which would permit implementers to continue resisting the adoption of = Type C by default, yet would allow them to add support for processing = RIO options just in ND Redirect messages and not RA messages. Call that = a Type D host, and call the functional combination Type C+D or = something. Here is my proposed text for Section 3.3 Host Specification. >>> The Host Specification follows Section 8.3 of Neighbor Discovery for = IP version 6 (IPv6) [RFC4861], Section 3 of Default Router Preferences = and More-Specific Routes [RFC4191], and Section 3 of First-Hop Router = Selection by Hosts in a Multi-Prefix Network [RFC8028]. According to = [RFC4861], a host that receives a valid ND Redirect message updates its = destination cache per the Destination information and its neighbor cache = per the Target information. According to [RFC4191], a =E2=80=9CType C=E2=80= =9D host that receives a valid RA message updates its routing table per = the RIO elements included in the message. Finally, according to = [RFC8028], a =E2=80=9CType C=E2=80=9D host operating on a Multi-Prefix = Network with multiple default routes can make source address selection = decisions based on information in its route table decorated with = information derived from the source of the RIO element. >>>=20 >>> In light of these considerations, this document introduces a new = =E2=80=9CType D=E2=80=9D behavior for hosts with the same kind of = routing table as a =E2=80=9CType C=E2=80=9D host, but which processes = RIO elements in ND Redirect Messages according to this specification = instead of RA Messages as in RFC 4191. Hosts that process RIO elements = in both RA messages and ND Redirect Messages are said to have =E2=80=9CTyp= e C+D=E2=80=9D behavior. >>>=20 >>> In both the =E2=80=9CType D=E2=80=9D and =E2=80=9CType C+D=E2=80=9D = cases, hosts process ND Redirect Messages by updating 1) their neighbor = cache per the Target information, 2) their destination cache per the = Destination information when the Destination Address field is not the = unspecified address, and 3) their routing tables per any RIO elements = present. >>>=20 >>> RIO elements in RA Messages are processed by =E2=80=9CType D=E2=80=9D = hosts in the same way that =E2=80=9CType B=E2=80=9D hosts process them, = i.e. by ignoring them. In =E2=80=9CType C+D=E2=80=9D hosts, RIO elements = in RA messages are processed in the same way that =E2=80=9CType C=E2=80=9D= hosts process them. >>>=20 >>> In the all the cases where hosts process RIO elements, i.e. in RA = Messages or in ND Redirect Messages or in both, hosts MAY make source = address selection decisions, as in [RFC8028], based on their route = tables decorated with information derived from the sources of received = RIO elements. >>>=20 >>> The behaviors of =E2=80=9CType A,=E2=80=9D =E2=80=9CType B=E2=80=9D = and =E2=80=9CType C=E2=80=9D hosts are not changed by this = specification. In particular, they all process ND Redirect Messages = according to Section 8.3 of [RFC4861]. --james woodyatt From nobody Tue Jan 17 17:42: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 1D643129483 for ; Tue, 17 Jan 2017 17:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml2TG9vi2ZEf for ; Tue, 17 Jan 2017 17:42:23 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8BE129481 for ; Tue, 17 Jan 2017 17:42:23 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2BA18800BC; Wed, 18 Jan 2017 02:42:18 +0100 (CET) Subject: Re: IID length text To: sarikaya@ieee.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <048015f0-877d-e1da-0406-5b516862b865@si6networks.com> Date: Tue, 17 Jan 2017 19:08:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 01:42:25 -0000 On 01/17/2017 06:31 PM, Behcet Sarikaya wrote: > On Tue, Jan 17, 2017 at 2:55 PM, Fernando Gont wrote: >> Hello, Behcet, >> >> On 01/17/2017 02:39 PM, Behcet Sarikaya wrote: >>> On Mon, Jan 16, 2017 at 4:09 PM, Fernando Gont wrote: >>>> On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: >>>>> On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont wrote: >>>>>> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>>>>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>>>>> wrote: >>>>>>>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit : >>>>>>>>> >> [....] >>>>>> >>>>>> What does a layer-2 EUI have to do with a layer-3 address? >>>>> >>>>> I don't know, you tell me :-) >>>> >>>> Answer: Nothing. The fact that we've been embedding layer-2 "addresses" >>>> into layer-3 addresses should not be taken as a reason for the two of >>>> them of having to do anything with each other. So, yes, the 64-bit IID >>>> length is, in reality, arbitrary. They could have been e.g. 32-bits or >>>> 48-bits (yes, multiples or 64 or 32 tend to be nicer) >>>> >>> >>> I don't think you know much about MAC addresses and its history. >> >> I don't know much about elephants, either. Whatever the history (which >> you imply I don't know), it is irrelevant, because it doesn't change the >> fact that you don't need to screw your layer-3 protocol with your >> layer-2 IDs/"addresses". >> > > Good luck then running SLAAC or ARP :-) SLAAC: Yes, mac addresses used to be embedded in the IID, That's an artifact of history, not a design principle. And we're heading towards replacing that with RFC7217 (which, for many implementations, is already the case) -- and has always been the case for, e.g., RFC4941. Neighbor Discovery: NS/NA messages employ link-layer address options, which essentially convey the link-layer address as an opaque value. That's used for learning the layer-2 address when sending a packet on a link, which is a totally different thing from exposing such layer-2 address at layer-3. There's no reason or requirement that I communicate my layer-2 address in my layer-3 protocol when, e.g., I connect with a web server. That has been an artifact of history (which may have happened as such for multiple (possibly valid) reasons), but please don't confuse that with a design principle or some sort of law from nature. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 18:11: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 1E957129619 for ; Tue, 17 Jan 2017 18:11:32 -0800 (PST) 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 6-CYf1nCft66 for ; Tue, 17 Jan 2017 18:11:31 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0384F129603 for ; Tue, 17 Jan 2017 18:11:31 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5537582BA9; Wed, 18 Jan 2017 03:11:28 +0100 (CET) Subject: Re: Unclear text [was IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]] To: Brian E Carpenter , ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> From: Fernando Gont Message-ID: Date: Tue, 17 Jan 2017 23:00:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:11:32 -0000 On 01/17/2017 07:28 PM, Brian E Carpenter wrote: > On 17/01/2017 17:52, Lorenzo Colitti wrote: > ... >> "Not clear" != "faulty". > > On the contrary, in a standards document, "Not clear" == "faulty" > > Really. If we publish text that is logically correct but can easily > be misread (or, of course, text that is ambiguous) then it's faulty text. > > (On a personal note, I have always tried to discipline myself thus: > if *anybody* misinterprets some text that I wrote, however clear > I believe it to be, then it's the text that needs fixing, not the > reader.) +1 (and applause ;-) ) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 18:11: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 BA983129619 for ; Tue, 17 Jan 2017 18:11:43 -0800 (PST) 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 JTCD-AOr_au7 for ; Tue, 17 Jan 2017 18:11:42 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9E412961E for ; Tue, 17 Jan 2017 18:11:42 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F1CF082BA7; Wed, 18 Jan 2017 03:11:36 +0100 (CET) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: "Manfredi, Albert E" , Brian E Carpenter , "ipv6@ietf.org" References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Tue, 17 Jan 2017 23:04:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:11:44 -0000 On 01/17/2017 09:16 PM, Manfredi, Albert E wrote: >> -----Original Message----- From: ipv6 >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > >> I think that the discussion on the IETF list has already shown that >> there is no consensus for the current text. I don't agree with it >> any more, either. It hides the tension between CIDR and the >> consistent length needed for SLAAC. >> >> Hence I'm still proposing that we change it. I think the median >> view at the moment is for the version that runs >> >> ... For all currently allocated unicast addresses, except those >> that start with the binary value 000, that length should be 64 >> bits. > > I think that as things are today, for unicast addresses allocated > that may use SLAAC, the "should" might not be strong enough. We have > no other implementation of SLAAC, other than one that uses 64-bit > IIDs. But I agree with you, when you said that future implementations > may not require 64-bit IIDs for SLAAC. > > But I completely concur with your point about tension with CIDR. In > fact, one thing that has always bothered me about the wording "all > currently allocated unicast addresses, except those that start with > the binary value 000," is that it sounds like the 64-bit IID rule > holds for the majority of the unicast address space. But that's not > true. Only 1/8 of the total address space is "currently assigned to > unicast," and a subset of that 1/8th has the stipulation that the > IIDs can be of any length. > > But the majority of the unicast address space is unconstrained, as it > should be. Somehow, it always ends up sounding the 64-bit IID is a > fixture, in most IPv6 unicast. Has anyone tred what happens if a prefix from::/3 is advertised for slaac? I wouldn't be surprised if, if we happen to want to use non-64 IIDS for ::/3, we find that we cannot because this 64-bit value is hardcoded everywhere. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 17 23: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 7D85F120727 for ; Tue, 17 Jan 2017 23:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 jY97o1QxdaC3 for ; Tue, 17 Jan 2017 23:37:10 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C95129667 for ; Tue, 17 Jan 2017 23:37:09 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id x75so3051758vke.2 for ; Tue, 17 Jan 2017 23:37:09 -0800 (PST) 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=XYI4+CfBHYbuvliN/1HqxjPjy8YF92ZWwAALkXluzd4=; b=sU+eLHyaoSMSDWm9AShi/TLjWoAyakit3uoocbKsVlJDUTai5UInmPzOqslWVWEJ+8 arTviyvSI4TMSo2SBAwL5MaEHI0KchDgu69bKUKdahZEDEpDK/Tk2X8JtBS1QOh8AgeI V71jOytajWTmj9aB0OJ4qAUmiMaEf+fmyvsLg4RxDTxayXWyAAcUhu/Ya7tWIxmH5r8A CGkLJvjQ22Cnr2+2JET1H6E1oSuH9w0VRtPuGljarNNNs0HIDN8HQ/RMOEH8vl0x0B/j rI/tZUcU+H7aYAihhnxKcchNNoq18MieEjLaNdTLiJCXJmP7mZVbnSfAdDia3Dw06ase NcUA== 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=XYI4+CfBHYbuvliN/1HqxjPjy8YF92ZWwAALkXluzd4=; b=QGsN3YS3/V0SkD7LkC5AH/1pFrwN9qxDdHp5JSj8IoTXVLxAoGS6rXCMwZV8NxPO/Z 1beqrAwvI3LordzOFYr4aejXRmOnBmhx5iA80AXqnfhLuG3gB+dhIYYzQLG7yihzvpYz 7UVzH25XShy1BBn+QAWJ1whEOGqVqMSjRmSRWEVHVIK0avhcSsF4PdVp9bvzpR+j/mOl mRoCHk9NeZv1kjQpu8icNRAjjx+IfP8vQtp6IxlG1ln7BOXkVlqgeryhAtoXIjNOvFOD dJALw+p1fUBDV7nOm5m8rJ34l773MisRZLxy23ZPyv6W/TO0ftkc1qfa9nF7PPIp560f kM7A== X-Gm-Message-State: AIkVDXJA4oPC0/72vWrIwOEcX94DlZmxlxdlGFDocMx0+srfBB8iOLE7f6v5wlKiw6VSf/fBILDOckUWnvysa/Zi X-Received: by 10.31.72.69 with SMTP id v66mr936328vka.156.1484725028952; Tue, 17 Jan 2017 23:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:36:48 -0800 (PST) In-Reply-To: <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> From: Lorenzo Colitti Date: Wed, 18 Jan 2017 16:36:48 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Ole Troan Content-Type: multipart/alternative; boundary=001a114d9c6ef0ec730546597b90 Archived-At: Cc: 6man WG , Erik Kline X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:37:13 -0000 --001a114d9c6ef0ec730546597b90 Content-Type: text/plain; charset=UTF-8 +1 I don't think we should change this text in a reclassification. The fact that there are such strong opinions about the fixed boundary suggests that people think that it's an important property of the standard. That text has been the standard for almost 20 years. If we want to change it, then let's do it the right way: write a draft of a document that updates 4291 (or updates whatever number 4291bis ends up being, if we can somehow resolve the current point and publish it), and see if we can reach consensus. I doubt that will be easy. On Wed, Jan 18, 2017 at 6:32 AM, wrote: > I would argue that we should not make any changes to this text (apart from > the eui-64 part). > > Cheers, > Ole > > > > > On Tue, Jan 17, 2017 at 4:00 AM, wrote: > > > What breaks if all IIDs in global unicast are not 64 bits? Especially > other than SLACC? I would hope such a REQUIREMENT has a better motivation > that "we said so". Citing the "rest of the specifications" was simply my > shorthand for I don't see what else breaks. > > > > RFC7421, section 4.2. > > > > There's also a set of political considerations, where one tries to > achieve balance between the provider's desire to have effective aggregation > and the end-users desire to have enough address space. We specifically want > to avoid provider's charging by the address. > > > > O. > > > > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it > does not say to me "IIDs MUST be 64 bits", this is a subtle but important > difference. Furthermore, RFC7421, section 4.3.2, also say there is > operational use of IID other than 64 bits, which to me disproves the > statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 > bits." > > > > So lets be clear, I'm not saying that we should RECOMMEND other than 64 > bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC > 2119. > > > > So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to > the in my opinion the more proper "IIDs SHOULD be 64 bits". > > > > So, I would prefer: > > > > ... For all currently > > allocated unicast addresses, except those that start with the binary > > value 000, that length should be 64 bits. > > > > But, I'm willing to live with what Brian proposed: > > > > ... For all currently > > allocated unicast addresses, except those that start with the binary > > value 000, that length is 64 bits. > > > > But, I can not accept what Eric proposed: > > > > ... For all currently > > allocated unicast addresses, except those that start with the binary > > value 000, that length is required to be 64 bits. > > > > Thanks. > > -- > > =============================================== > > David Farmer Email:farmer@umn.edu > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > > =============================================== > > --001a114d9c6ef0ec730546597b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I don't think we should change t= his text in a reclassification. The fact that there are such strong opinion= s about the fixed boundary suggests that people think that it's an impo= rtant property of the standard.

That text has been the s= tandard for almost 20 years. If we want to change it, then let's do it = the right way: write a draft of a document that updates 4291 (or updates wh= atever number 4291bis ends up being, if we can somehow resolve the current = point and publish it), and see if we can reach consensus. I doubt that will= be easy.

On Wed, Jan 18, 2017 at 6:32 AM, <otroan@employees.org> wrote:
I would argue that we should n= ot make any changes to this text (apart from the eui-64 part).

Cheers,
Ole



> On Tue, Jan 17, 2017 at 4:00 AM, <otroan@employees.org> wrote:
> > What breaks if all IIDs in global unicast are not 64 bits?=C2=A0 = Especially other than SLACC?=C2=A0 I would hope such a REQUIREMENT has a be= tter motivation that "we said so".=C2=A0 Citing the "rest of= the specifications" was simply my shorthand for I don't see what = else breaks.
>
> RFC7421, section 4.2.
>
> There's also a set of political considerations, where one tries to= achieve balance between the provider's desire to have effective aggreg= ation and the end-users desire to have enough address space. We specificall= y want to avoid provider's charging by the address.
>
> O.
>
> Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits,&quo= t; but it does not say to me "IIDs MUST be 64 bits", this is a su= btle but important difference.=C2=A0 Furthermore, RFC7421, section 4.3.2, a= lso say there is operational use of IID other than 64 bits, which to me dis= proves the statement "IIDs MUST be 64 bits" and shifts things to = "IIDs SHOULD be 64 bits."
>
> So lets be clear, I'm not saying that we should RECOMMEND other th= an 64 bit IIDs, I'm simply differentiating between section 1 and sectio= n 3 of RFC 2119.
>
> So, I'm asking what breaks if we change from "IIDs MUST be 64= bits" to the in my opinion the more proper "IIDs SHOULD be 64 bi= ts".
>
> So, I would prefer:
>
>=C2=A0 =C2=A0...=C2=A0 For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length should be 64 bits.
>
> But, I'm willing to live with what Brian proposed:
>
>=C2=A0 =C2=A0 ... For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length is 64 bits.
>
> But, I can not accept what Eric proposed:
>
>=C2=A0 =C2=A0 ...=C2=A0 For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length is required to be 64 bits.
>
> Thanks.
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email:farmer@umn.e= du
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815<= br> > Minneapolis, MN 55414-3029=C2=A0 =C2=A0Cell: 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


--001a114d9c6ef0ec730546597b90-- From nobody Tue Jan 17 23:42: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 34567129585 for ; Tue, 17 Jan 2017 23:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 hxksOZfkobsr for ; Tue, 17 Jan 2017 23:42:41 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 7B3B91293E8 for ; Tue, 17 Jan 2017 23:42:41 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id i68so3699271uad.0 for ; Tue, 17 Jan 2017 23:42:41 -0800 (PST) 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=/3ujtmce4tZHtDdAm9uwcTJeilGUQE98iQlkJTpN3ME=; b=XzMWyG5uPHEwqSm20tyYjK7wis8bsF9cNeHkp51aq+vQKxqhcLnminKzSw4iV0xEfB oSoFLayslnZ8QF2StO63x2Fu+5ybgIgbDx4PGU/d5JsdXNx+mIKHKn7ADuEbAuGeytIR hciYoy3iMj3/2tcjlVqU13Su+eskWqGYZPPlw1DFvU9DY1IaHs1tPj8/vJiN2aMZ3Thx +n1kbEDAm1myDFgXU5P70l7bqL58LOjCS7YGYHNCObecS/8nqI/vzOrlylBBX6PVm9ug ZDOjDpn3T6xbCfFmUmAwaC8t9933VkU8g4OcDRQWHNDZ5NIlpiBe1c/lB7i7LPjze2Op YB2g== 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=/3ujtmce4tZHtDdAm9uwcTJeilGUQE98iQlkJTpN3ME=; b=C7fJrhQ0t3jKbnPOy4yV6PK2SF1M1UoZcRVqtYq0FkNmB+H3RkiJlmUIpDKwa7dtJ1 hMt/tbR9/CXWn2VuJQX5fcA7PyrSdWBTpzBQfHv2KR8aMHIeA/JsLPVrZNZ2O2HmAUH6 WO20PFCsXUpVN4szYkDwO+E3QDHvitoiVssZA/0qZjUCnW/L2ewIfSHaYawihG0b1R9U SMpGN75Pl7uCaRqrwAkwS7wlllOQ4xHoj4TdyZG4gzKBw45TzSWuZTZMl3zW017szrCM CYUfC6jp8RGyM0zrx7k9wzIvwAywurdZmJEPOrfS5q2D4NEZuloIUIJoIuhRf1TIMmSs yqdQ== X-Gm-Message-State: AIkVDXKprwuj2CJ8fvhpC0NjI6roA0+Z9y/wTNmNDhYOY98k5hTnylUzNl3UrK+qeBPQkKqWPtAt+0ejkiYmoMYP X-Received: by 10.176.7.209 with SMTP id d17mr1165798uaf.171.1484725360374; Tue, 17 Jan 2017 23:42:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Tue, 17 Jan 2017 23:42:19 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 18 Jan 2017 16:42:19 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Fernando Gont Content-Type: multipart/alternative; boundary=f403045f7f26b2047f0546598f5c Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:42:43 -0000 --f403045f7f26b2047f0546598f5c Content-Type: text/plain; charset=UTF-8 On what link type? On Ethernet, RFC 2464 clearly defines the IID length to be 64 bits, period. So /64 is correct. If there's an IPv6-over-foo document that does not specify the IID length, then the IID length is unspecified. Because it's unspecified, whatever they pick is fine. "Do nothing" or "use /64 for consistency with global addresses" would be the most obvious choices. On Wed, Jan 18, 2017 at 11:04 AM, Fernando Gont wrote: > On 01/17/2017 09:16 PM, Manfredi, Albert E wrote: > >> -----Original Message----- From: ipv6 > >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > > > >> I think that the discussion on the IETF list has already shown that > >> there is no consensus for the current text. I don't agree with it > >> any more, either. It hides the tension between CIDR and the > >> consistent length needed for SLAAC. > >> > >> Hence I'm still proposing that we change it. I think the median > >> view at the moment is for the version that runs > >> > >> ... For all currently allocated unicast addresses, except those > >> that start with the binary value 000, that length should be 64 > >> bits. > > > > I think that as things are today, for unicast addresses allocated > > that may use SLAAC, the "should" might not be strong enough. We have > > no other implementation of SLAAC, other than one that uses 64-bit > > IIDs. But I agree with you, when you said that future implementations > > may not require 64-bit IIDs for SLAAC. > > > > But I completely concur with your point about tension with CIDR. In > > fact, one thing that has always bothered me about the wording "all > > currently allocated unicast addresses, except those that start with > > the binary value 000," is that it sounds like the 64-bit IID rule > > holds for the majority of the unicast address space. But that's not > > true. Only 1/8 of the total address space is "currently assigned to > > unicast," and a subset of that 1/8th has the stipulation that the > > IIDs can be of any length. > > > > But the majority of the unicast address space is unconstrained, as it > > should be. Somehow, it always ends up sounding the 64-bit IID is a > > fixture, in most IPv6 unicast. > > Has anyone tred what happens if a prefix from::/3 is advertised for slaac? > > I wouldn't be surprised if, if we happen to want to use non-64 IIDS for > ::/3, we find that we cannot because this 64-bit value is hardcoded > everywhere. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f403045f7f26b2047f0546598f5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On what link type? On Ethernet, RFC 2464 clearly defi= nes the IID length to be 64 bits, period. So /64 is correct.

=
If there's an IPv6-over-foo document that does not specify t= he IID length, then the IID length is unspecified. Because it's unspeci= fied, whatever they pick is fine. "Do nothing" or "use /64 f= or consistency with global addresses" would be the most obvious choice= s.

On = Wed, Jan 18, 2017 at 11:04 AM, Fernando Gont <fgont@si6networks.com> wrote:
On 01/17/2017 09:16 PM, Manfredi, Albert E wrote:
>> -----Original Message----- From: ipv6
>> [mailto:ipv6-bounces@ietf= .org] On Behalf Of Brian E Carpenter
>
>> I think that the discussion on the IETF list has already shown tha= t
>> there is no consensus for the current text. I don't agree with= it
>> any more, either. It hides the tension between CIDR and the
>> consistent length needed for SLAAC.
>>
>> Hence I'm still proposing that we change it. I think the media= n
>> view at the moment is for the version that runs
>>
>> ...=C2=A0 For all currently allocated unicast addresses, except th= ose
>> that start with the binary value 000, that length should be 64
>> bits.
>
> I think that as things are today, for unicast addresses allocated
> that may use SLAAC, the "should" might not be strong enough.= We have
> no other implementation of SLAAC, other than one that uses 64-bit
> IIDs. But I agree with you, when you said that future implementations<= br> > may not require 64-bit IIDs for SLAAC.
>
> But I completely concur with your point about tension with CIDR. In > fact, one thing that has always bothered me about the wording "al= l
> currently allocated unicast addresses, except those that start with > the binary value 000," is that it sounds like the 64-bit IID rule=
> holds for the majority of the unicast address space. But that's no= t
> true. Only 1/8 of the total address space is "currently assigned = to
> unicast," and a subset of that 1/8th has the stipulation that the=
> IIDs can be of any length.
>
> But the majority of the unicast address space is unconstrained, as it<= br> > should be. Somehow, it always ends up sounding the 64-bit IID is a
> fixture, in most IPv6 unicast.

Has anyone tred what happens if a prefix from::/3 is advertised= for slaac?

I wouldn't be surprised if, if we happen to want to use non-64 IIDS for=
::/3, we find that we cannot because this 64-bit value is hardcoded
everywhere.

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




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

--f403045f7f26b2047f0546598f5c-- From nobody Wed Jan 18 04:57: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 736CA129692 for ; Wed, 18 Jan 2017 04:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 dZgev3yncJzB for ; Wed, 18 Jan 2017 04:57:42 -0800 (PST) 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 195E112945B for ; Wed, 18 Jan 2017 04:57:42 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x49so10573809qtc.2 for ; Wed, 18 Jan 2017 04:57:42 -0800 (PST) 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=eTS+vNvy1LotjH0y9ogiUFCrWBGynOgy4wFZSiCVI7E=; b=LNHdc9S9+7ETaHFiPc7pCu833ScuaRGAaxYcT8DY3BkfmjNgj9seChF/147U7xLrqC zt9/Nk9IP8sFcJ9wIHPKpZsfAexYaBUmsomxaHCV1K0Yf+cinZZcQmBD3c7VwP+1hkG8 y/xhsjjLeTh5CJlRQFpZf9LSQi8219PQxJij8= 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=eTS+vNvy1LotjH0y9ogiUFCrWBGynOgy4wFZSiCVI7E=; b=dedhgo1EyMZbvjt03DUz/UBgNdjeQ1E4iXgHTmcvms8YgQ+/jovla6JyUwx3E7Kuqr sZaMiEloTuLyyTzA+S7LTmjp6uuUUzp2WPwdE/0oocQvvDwygavssT5wA3JkrM5GW6pG wydAsZz3sp72k062Ie6GqG7DgyCaxryOLXTDzuWrcxIaXeZGhUbTjrgmosShaixnFGnv U/ifqfjSBJwR7r9NQtJIpKnb0w3Gl6AJTMXGRV/i4Jjv1YMB95hmgFPDylg68krplvZj l8IC6D4ocl+Yxze1mRLPhBMKXsL1b3y0Zo1HL35NgASYDwIVgGQP9ZBm2Lo3MOuTuf1v Hk4A== X-Gm-Message-State: AIkVDXI+H0JgakcTwT/zIkBTaQYYxjK8zVzA3mUHNI+V3tWLCoyLWXmsuD8ze4sqYOkhvFu2zrGFRZl8B6dtg5th X-Received: by 10.200.39.212 with SMTP id x20mr2502517qtx.109.1484744261149; Wed, 18 Jan 2017 04:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.32.202 with HTTP; Wed, 18 Jan 2017 04:57:40 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> From: Timothy Winters Date: Wed, 18 Jan 2017 07:57:40 -0500 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1135b54244ce3305465df6b0 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 12:57:44 -0000 --001a1135b54244ce3305465df6b0 Content-Type: text/plain; charset=UTF-8 Hi Fernando, IPv6 Ready Logo have a test that advertises a prefix length of /96 for SLAAC, with the a flag set and we check that it's used for on-link determination as per 4862. "In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. If you read 5.5.3 of 4862 it has some text about prefix length and interface-id having to add up to 128. "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored." We haven't tried /3 but I'd be happy to try it on implementations to see what they do if it's interesting to the working group. My guess is they will ignore it for SLAAC but use it for on-link. ~Tim On Tue, Jan 17, 2017 at 9:04 PM, Fernando Gont wrote: > On 01/17/2017 09:16 PM, Manfredi, Albert E wrote: > >> -----Original Message----- From: ipv6 > >> [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > > > >> I think that the discussion on the IETF list has already shown that > >> there is no consensus for the current text. I don't agree with it > >> any more, either. It hides the tension between CIDR and the > >> consistent length needed for SLAAC. > >> > >> Hence I'm still proposing that we change it. I think the median > >> view at the moment is for the version that runs > >> > >> ... For all currently allocated unicast addresses, except those > >> that start with the binary value 000, that length should be 64 > >> bits. > > > > I think that as things are today, for unicast addresses allocated > > that may use SLAAC, the "should" might not be strong enough. We have > > no other implementation of SLAAC, other than one that uses 64-bit > > IIDs. But I agree with you, when you said that future implementations > > may not require 64-bit IIDs for SLAAC. > > > > But I completely concur with your point about tension with CIDR. In > > fact, one thing that has always bothered me about the wording "all > > currently allocated unicast addresses, except those that start with > > the binary value 000," is that it sounds like the 64-bit IID rule > > holds for the majority of the unicast address space. But that's not > > true. Only 1/8 of the total address space is "currently assigned to > > unicast," and a subset of that 1/8th has the stipulation that the > > IIDs can be of any length. > > > > But the majority of the unicast address space is unconstrained, as it > > should be. Somehow, it always ends up sounding the 64-bit IID is a > > fixture, in most IPv6 unicast. > > Has anyone tred what happens if a prefix from::/3 is advertised for slaac? > > I wouldn't be surprised if, if we happen to want to use non-64 IIDS for > ::/3, we find that we cannot because this 64-bit value is hardcoded > everywhere. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a1135b54244ce3305465df6b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fernando,

IPv6 Ready Logo have a tes= t that advertises a prefix length of /96 for SLAAC, with the a flag set and= we check that it's used for on-link determination as per 4862.

"In fact, the advertised length has non-trivial= meaning for on-link
=C2=A0 =C2=A0 =C2=A0 determination in [RFC48= 61] where the sum of the prefix length and
=C2=A0 =C2=A0 =C2=A0 t= he interface identifier length may not be equal to 128.
If you read 5.5.3 of 4862 it has some text about prefix length = and interface-id having to add up to 128. =C2=A0=C2=A0

=
"If the sum of the prefix length and interface identifier length<= /div>
=C2=A0 =C2=A0 =C2=A0 does not equal 128 bits, the Prefix Informat= ion option MUST be
=C2=A0 =C2=A0 =C2=A0 ignored."
=
We haven't tried /3 but I'd be happy to try it on im= plementations to see what they do if it's interesting to the working gr= oup. =C2=A0 My guess is they will ignore it for SLAAC but use it for on-lin= k.

~Tim

=
On Tue, Jan 17, 2017 at 9:04 PM, Fernando Gont <= span dir=3D"ltr"><fgont@si6networks.com> wrote:
On 01/17/2017 09:16 PM, Man= fredi, Albert E wrote:
>> -----Original Message----- From: ipv6
>> [mailto:ipv6-bounces@ietf= .org] On Behalf Of Brian E Carpenter
>
>> I think that the discussion on the IETF list has already shown tha= t
>> there is no consensus for the current text. I don't agree with= it
>> any more, either. It hides the tension between CIDR and the
>> consistent length needed for SLAAC.
>>
>> Hence I'm still proposing that we change it. I think the media= n
>> view at the moment is for the version that runs
>>
>> ...=C2=A0 For all currently allocated unicast addresses, except th= ose
>> that start with the binary value 000, that length should be 64
>> bits.
>
> I think that as things are today, for unicast addresses allocated
> that may use SLAAC, the "should" might not be strong enough.= We have
> no other implementation of SLAAC, other than one that uses 64-bit
> IIDs. But I agree with you, when you said that future implementations<= br> > may not require 64-bit IIDs for SLAAC.
>
> But I completely concur with your point about tension with CIDR. In > fact, one thing that has always bothered me about the wording "al= l
> currently allocated unicast addresses, except those that start with > the binary value 000," is that it sounds like the 64-bit IID rule=
> holds for the majority of the unicast address space. But that's no= t
> true. Only 1/8 of the total address space is "currently assigned = to
> unicast," and a subset of that 1/8th has the stipulation that the=
> IIDs can be of any length.
>
> But the majority of the unicast address space is unconstrained, as it<= br> > should be. Somehow, it always ends up sounding the 64-bit IID is a
> fixture, in most IPv6 unicast.

Has anyone tred what happens if a prefix from::/3 is advertised= for slaac?

I wouldn't be surprised if, if we happen to want to use non-64 IIDS for=
::/3, we find that we cannot because this 64-bit value is hardcoded
everywhere.

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




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



--
=

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

--001a1135b54244ce3305465df6b0-- From nobody Wed Jan 18 05:08: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 27A541296BD for ; Wed, 18 Jan 2017 05:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx_CqUz-sg9Z for ; Wed, 18 Jan 2017 05:08:24 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 805B3129467 for ; Wed, 18 Jan 2017 05:08:24 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 18 Jan 2017 13:08:24 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0B77AD788B; Wed, 18 Jan 2017 05:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=l5i8DInQF6g3tOZnrvvxUfPv+Q4=; b=reLy0Mg9M74YH7w5Zd 61reXQ6BNoxqVeBqDhPxz4s7U+xXRwhFYxoTWorki2fJfGEJ7KMADBGcXJst2k3m /+xiCJb6mNrILv2mFQ+sGAgPDsok+YhLAwkU0JtiLfWA3SvIJC9D+qP37cx7w2eu v4QiPClufFtMcp3NOpVhwZMUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Jl+//z2H5MrLidIVPYWebo7KkXIjZrn1eJFKSym67+rT+sYbgIG VPXfmP/f+5+rMU9iJB68CXEpPzni8vBC+iHGHycn4jVRugp/Xq9u6jU1UOsJUdsx ijvoG0zHdNVRndivjahcn3YDfmM+sR7dq9dxEhtwH1AqO3wa/ifVerf4= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id CB1CED788A; Wed, 18 Jan 2017 05:08:23 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0FC7C76A5255; Wed, 18 Jan 2017 14:08:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] From: otroan@employees.org In-Reply-To: <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> Date: Wed, 18 Jan 2017 14:08:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:08:25 -0000 Brian, >> I would argue that we should not make any changes to this text (apart = from the eui-64 part). >=20 > I think that the discussion on the IETF list has already shown that = there is no > consensus for the current text. I don't agree with it any more, = either. It hides > the tension between CIDR and the consistent length needed for SLAAC. >=20 > Hence I'm still proposing that we change it. I think the median view = at the moment > is for the version that runs >=20 > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length should be 64 bits. The 64-bit boundary is hard to defend technically. It is for example = trivial to make SLAAC deal with variable length prefixes. Our strongest argument is probably 8+8 aka ILNP. The other side "the CIDR argument" has no technical argument foot to = stand on either. There is no technical argument why the network / = routing side would require more than 64 bits. Given that what we are left with is policy, I think it is quite harsh of = you to declare that there is no consensus on the current text on the = IETF list. There are good technical arguments for why each host needs more than a = single address, and if we end up in a situation similar to IPv4 where = each address used has to be justified, then we have lost. There is a = justified fear that allowing the 64 bit boundary to slide, we will end = up in a situation similar to IPv4 addressing. E.g. charging per address. This is where the IETF has to perform a fine balancing act. On one side = ensure that the 64 bit boundary stands, at the other side ensure that = all implementors do not enshrine a hard-coded boundary in their = implementations. O. From nobody Wed Jan 18 05:34: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 B731D1296CE for ; Wed, 18 Jan 2017 05:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.264 X-Spam-Level: ** X-Spam-Status: No, score=2.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=3.599, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfXLo0XDpieJ for ; Wed, 18 Jan 2017 05:34:40 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [198.137.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id E3D5D12952C for ; Wed, 18 Jan 2017 05:34:40 -0800 (PST) Received: from cowbell.employees.org ([65.50.211.142]) by esa01.kjsl.com with ESMTP; 18 Jan 2017 13:34:40 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 594EDD788D; Wed, 18 Jan 2017 05:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=lGeLXmI52mFzYThhK5jFLj67FwQ=; b=lwbshx62Nc2pXqBmkM uKQTW9FVUJ1u/9L8ZwUlOOwzG23reZFJDMG+F26BnqGXPmZIHhl5Qj0Mm6Hybjmo 24UP11x/PzQTMAWSJmDFjkJijEhktxbHuXsE/Ph9W2bg9wO9+TSo+69/Sw5Lx6JW xPrlKJzcClvN/cJK2mNhH8wYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=l/+S4nZ6fMpo4CgENUsY/jeUaPqOtdsLnqAO6JMOjcYPQ5o6/r/ eCT+4j/s70jeU2KK6zcumKPv4B5uxNhpzvo7JBWv6AlJLsOrBJj++k3grd5/SqGt LJv47+xt+ND6FJdve5VNCZHZTXQOoTXE9Uz9NRtSUsuhgciEdCzVTw6M= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 2D2ABD788F; Wed, 18 Jan 2017 05:34:40 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C297976AD11F; Wed, 18 Jan 2017 14:34:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Unclear text [was IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]] From: otroan@employees.org In-Reply-To: Date: Wed, 18 Jan 2017 14:34:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 13:34:42 -0000 Brian, > ... >> "Not clear" !=3D "faulty".=20 >=20 > On the contrary, in a standards document, "Not clear" =3D=3D "faulty" >=20 > Really. If we publish text that is logically correct but can easily > be misread (or, of course, text that is ambiguous) then it's faulty = text. >=20 > (On a personal note, I have always tried to discipline myself thus: > if *anybody* misinterprets some text that I wrote, however clear > I believe it to be, then it's the text that needs fixing, not the > reader.) In the parts of a document describing the exact protocol specification = and where it affects interoperability I do agree with you. In other parts of a document I think ambiguity and leaving leeway up to = future readers is perfectly fine. Being very strict about this, might lead us into being prescriptive = where we have no business being prescriptive. O.= From nobody Wed Jan 18 08:44: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 548781294A9; Wed, 18 Jan 2017 08:44:24 -0800 (PST) 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 JON3uhSaL15q; Wed, 18 Jan 2017 08:44:16 -0800 (PST) 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 8C81012947A; Wed, 18 Jan 2017 08:44:16 -0800 (PST) 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 v0IGiFfm031602; Wed, 18 Jan 2017 09:44:16 -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 v0IGi71v031470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 09:44:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 08:44:06 -0800 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.1178.000; Wed, 18 Jan 2017 08:44:06 -0800 From: "Templin, Fred L" To: james woodyatt , 6man WG , INT Area Subject: RE: [Int-area] Route Information Options in Redirect Messages Thread-Topic: [Int-area] Route Information Options in Redirect Messages Thread-Index: AdJqj8MpX1D7bRpERNaWpSFDneETogAXiyiAAA9u9DABkA37AAAO+46w Date: Wed, 18 Jan 2017 16:44:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 16:44:24 -0000 SGkgSmFtZXMsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSW50LWFy ZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgamFtZXMg d29vZHlhdHQNCj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAxNyA1OjE5IFBNDQo+IFRv OiA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgSU5UIEFyZWEgPGludC1hcmVhQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBSb3V0ZSBJbmZvcm1hdGlvbiBPcHRpb25zIGluIFJl ZGlyZWN0IE1lc3NhZ2VzDQo+IA0KPiBPbiBKYW4gOSwgMjAxNywgYXQgMTE6NTMsIFRlbXBsaW4s IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gT24gTW9uZGF5 LCBKYW51YXJ5IDA5LCAyMDE3IDExOjAyIEFNLCBqYW1lcyB3b29keWF0dCA8amh3QGdvb2dsZS5j b20+IHdyb3RlOg0KPiA+Pg0KPiA+PiBwMi4gU2VjdGlvbiAzLjMsIEhvc3QgU3BlY2lmaWNhdGlv biBzYXlzIHRoaXM6DQo+ID4+DQo+ID4+Pj4gICBJbiBsaWdodCBvZiB0aGVzZSBjb25zaWRlcmF0 aW9ucywgYSAiVHlwZSBDIiBob3N0IHRoYXQgcmVjZWl2ZXMgYQ0KPiA+Pj4+ICAgUmVkaXJlY3Qg bWVzc2FnZSBjb250YWluaW5nIFJJT3MgYWRvcHRzIHRoZSBjb21iaW5lZCBiZWhhdmlvcnMgb2YN Cj4gPj4+PiAgIGJvdGggb2YgdGhlc2Ugc3BlY2lmaWNhdGlvbnMuICBOYW1lbHksIHRoZSBob3N0 IHVwZGF0ZXMgaXRzIG5laWdoYm9yDQo+ID4+Pj4gICBjYWNoZSBlbnRyeSBmb3IgdGhlIFRhcmdl dCBhbmQgdXBkYXRlcyBpdHMgcm91dGluZyB0YWJsZSBwZXIgdGhlDQo+ID4+Pj4gICBpbmNsdWRl ZCBSSU9zLiAgSWYgdGhlIERlc3RpbmF0aW9uIGFkZHJlc3MgaXMgbm90IHRoZSB1bnNwZWNpZmll ZA0KPiA+Pj4+ICAgYWRkcmVzcywgdGhlIGhvc3QgZnVydGhlciB1cGRhdGVzIGl0cyBkZXN0aW5h dGlvbiBjYWNoZS4NCj4gPj4+Pg0KPiA+Pj4+ICAgTm90ZSB0aGF0ICJUeXBlIEEnIiBhbmQgIlR5 cGUgQiIgaG9zdHMgaWdub3JlIGFueSBSSU9zIGFuZCBwcm9jZXNzDQo+ID4+Pj4gICB0aGUgUmVk aXJlY3QgbWVzc2FnZSBhY2NvcmRpbmcgdG8gU2VjdGlvbiA4LjMgb2YgW1JGQzQ4NjFdLg0KPiA+ Pg0KPiA+PiBBbmQgSSB3b25kZXIgaWYgeW91IGhhdmUgY29uc2lkZXJlZCB0aGUgcG9zc2liaWxp dHkgb2YgYSDigJxUeXBlIETigJ0gaG9zdCwgd2hpY2ggaW4gbXkgY29uY2VwdGlvbiB3b3VsZCBi ZSBjYXBhYmxlIG9mICpvbmx5Kg0KPiBwcm9jZXNzaW5nDQo+ID4+IFJJTyBvcHRpb25zIHRoYXQg YXBwZWFyIGluIE5EIFJlZGlyZWN0IG1lc3NhZ2VzIGFuZCAqbm90KiBpbiBSQSBtZXNzYWdlcy4N Cj4gPg0KPiA+IEhhZCBub3QgY29uc2lkZXJlZCB0aGF0LCBidXQgSSBkb24ndCBzZWUgYSBwcm9i bGVtIHdpdGggaXQuIEZXSVcsIHRoZSAnVHlwZSBBL0IvQycgY29tZXMgZnJvbSBSRkM0MTkxIGlu IGNhc2Ugb3RoZXJzIGFyZQ0KPiB3b25kZXJpbmcuDQo+ID4NCj4gPj4gSeKAmW0gbm90IHN1cmUg dGhhdOKAmXMgYSB0eXBlIG9mIGhvc3Qgd2Ugd2FudCB0byBlbmNvdXJhZ2UsDQo+ID4+IGJ1dCB0 aGUgaWRlYSBvZiBpdHMgcG9zc2liaWxpdHkgd2FzIG9uZSBvZiB0aGUgZmlyc3QgdGhpbmdzIHRo YXQgc3ByYW5nIHRvIG1pbmQgd2hlbiBJIGNvbnRlbXBsYXRlZCB0aGUgcmVhc29ucyB3aHkgc28g ZmV3IFR5cGUgQw0KPiBob3N0cw0KPiA+PiBhcmUgY3VycmVudGx5IGRlcGxveWVkIGluIHRoZSB3 aWxkIGFmdGVyIG1vcmUgdGhhbiBhIGRlY2FkZSBzaW5jZSBSRkMgNDE5MSB3YXMgcHVibGlzaGVk Lg0KPiA+DQo+ID4gSSBhbSBpbnRlcmVzdGVkIGluIHVzYWdlIGluc2lkZSBvZiBhIG1hbmFnZWQg bmV0d29yaywgYW5kIG5vdCBzbyBtdWNoIGFib3V0DQo+ID4gZGVwbG95bWVudCBpbiB0aGUgd2ls ZC4gSW5zaWRlIG9mIGEgbWFuYWdlZCBuZXR3b3JrLCB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9y cw0KPiA+IGNvdWxkIGVuYWJsZSB0aGlzIGZ1bmN0aW9uIGFtb25nIHRoZSBkZXBsb3llZCBob3N0 cyB0byBwcm92aWRlIHRoZSBuZXR3b3JrIHdpdGgNCj4gPiBhIG1lYW5zIHRvIG1hbmFnZSByb3V0 aW5nIGluZm9ybWF0aW9uIGZvciBtb3JlLXNwZWNpZmljIHJvdXRlcy4NCj4gDQo+IFllcywgd2Vs bCwgYXMgeW91IG1pZ2h0IGltYWdpbmUsIEnigJltIGludGVyZXN0ZWQgaW4gYmVoYXZpb3Igb2Yg Y29tbW9kaXR5IGhvc3RzIG9uIHVubWFuYWdlZCBuZXR3b3Jrcy4NCg0KT0ssIG5vIHByb2JsZW0u IEkgYWdyZWUgdGhpcyBkb2N1bWVudCBzaG91bGQga2VlcCBhbiBvcGVuIG1pbmQgaW4gdGVybXMg b2YNCnBvdGVudGlhbCB1c2UgY2FzZXMuDQoNCj4gQXMgZmFyIGFzIEkga25vdywgdGhlIG1vc3Qg Y29tbW9uIHR5cGVzIG9mIGNvbW1vZGl0eSBob3N0IGltcGxlbWVudGF0aW9ucyBhcmUgVHlwZSBC IGF0IHRoaXMgcG9pbnQuIFllcywgSSBrbm93IGF0IGxlYXN0IG9uZSBoYXMgYQ0KPiBjb25maWd1 cmFibGUgb3B0aW9uIHRvIGVuYWJsZSBUeXBlIEMgYmVoYXZpb3IsIGJ1dCBUeXBlIEIgaXMgdGhl IGRlZmF1bHQsIGFuZCBpdOKAmXMgYWxzbyByYXJlbHkgY2hhbmdlZCBpbiBtYW5hZ2VkIGhvc3Qg Y29uZmlndXJhdGlvbnMNCj4gZm9yIG1vYmlsZSB3b3Jrc3RhdGlvbnMgYW5kIHBlcnNvbmFsIGRl dmljZXMuDQo+IA0KPiBJIGJlbGlldmUgaG9zdCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBub3QgYWRv cHRlZCBUeXBlIEMgZGVmYXVsdCBiZWhhdmlvciBiZWNhdXNlIG9mIHNlY3VyaXR5IGNvbmNlcm5z IG9uIHVubWFuYWdlZCBuZXR3b3JrcyBsaWtlDQo+IHB1YmxpYyBXaS1GaSBob3RzcG90cywgd2hl cmUgdGhlIGRhbWFnZSBwb3RlbnRpYWxseSBjYXVzZWQgYnkgc28tY2FsbGVkIOKAnHJvZ3VlIHJv dXRlcnPigJ0gaXMgYWxyZWFkeSBwZXJjZWl2ZWQgdG8gYmUgdW5hY2NlcHRhYmx5IGhpZ2guDQo+ IFRoZSB0aGVvcnkgYmVpbmcgdGhhdCBhZGRpbmcgc3VwcG9ydCBmb3IgcHJvY2Vzc2luZyBSSU8g b3B0aW9ucyB3b3VsZCBmdXJ0aGVyIGxvd2VyIHRoZSBuZXR3b3JrIGNvc3RzIG9mIG1vdW50aW5n IHN1Y2ggYXR0YWNrcywgaW4NCj4gZXhjaGFuZ2UgZm9yIGEgcXVlc3Rpb25hYmx5IHZhbHVhYmxl IHJvdXRlIG9wdGltaXphdGlvbiBmcm9tIGhvc3RzIHRvIHBvc3NpYmx5IGlsbGVnaXRpbWF0ZSBy b3V0ZXJzLiBJ4oCZbSBub3QgYSBiaWcgZmFuIG9mIHRoaXMgbGluZSBvZg0KPiByZWFzb25pbmcs IGJ1dCBJ4oCZdmUgb2Z0ZW4gc2VlbiBpdCB1c2VkIHRvIGNvdW50ZXIgYXJndW1lbnRzIHRoYXQg YWRkaW5nIGRlZmF1bHQgVHlwZSBDIGJlaGF2aW9yIHdvdWxkIGJlIGEgZ29vZCBpZGVhLg0KDQpG b3IgUklPcyBpbiBSQSBtZXNzYWdlcywgSSBkb24ndCB0aGluayB0aGlzIHdvdWxkIHJlc3VsdCBp biBhIHJvdXRlIG9wdGltaXphdGlvbi4gSW4NCnRoYXQgY2FzZSwgdGhlIFJBIG1lc3NhZ2VzIHNp bXBseSBwcm92aWRlIG1vcmUtc3BlY2lmaWMgcm91dGVzLiBCdXQsIHRoZSBuZXh0DQpob3Agd2ls bCBhbHdheXMgYmUgdGhlIHJvdXRlciB0aGF0IHNlbnQgdGhlIFJBLCBpLmUuLCBhbmQgbm90IGEg ZGlmZmVyZW50IHJvdXRlci4NCg0KPiBBIGJldHRlciBhcmd1bWVudCBhZ2FpbnN0IFJJTyBvcHRp b25zIGluIFJBIE1lc3NhZ2VzLCBhcyBmYXIgYXMgSeKAmW0gY29uY2VybmVkLCBpcyB0aGF0IFJB IEd1YXJkIFtSRkM2MTA1XSBmdW5jdGlvbnMgYXJlIG9mdGVuDQo+IGRlcGxveWVkIGluIEwyIHN3 aXRjaGluZyBmYWJyaWNzLCBhbmQgdGhleeKAmWxsIGRyb3AgYWxsIHRoZSBSQSBNZXNzYWdlcyBm cm9tIG1vc3Qgcm91dGVycyBvdGhlciB0aGFuIHRoZSBwcm90ZWN0ZWQgZGVmYXVsdCByb3V0ZXJz LA0KPiB3aGljaCBhcmUgbGlrZWx5IHRvIGJlIHRoZSBvbmVzIGFkdmVydGlzaW5nIG1vcmUgc3Bl Y2lmaWMgcm91dGVzLiBXaXRoIE5EIFJlZGlyZWN0IE1lc3NhZ2VzLCBuZXR3b3JrIG9wZXJhdG9y cyBjYW4gc3RpbGwgaGF2ZSBhDQo+IHJlYXNvbmFibGUgYXNzdXJhbmNlIHRoYXQgaG9zdHMgbmV2 ZXIgdXBkYXRlIHRoZWlyIHJvdXRpbmcgdGFibGVzIGV4Y2VwdCBhdCB0aGUgaW5pdGlhdGlvbiBv ZiBvbmUgb2YgdGhlIGxlZ2l0aW1hdGUgZGVmYXVsdCByb3V0ZXJzLA0KPiB3aGljaCBhcmUgcHJv dGVjdGVkIGJ5IFJBIEd1YXJkLg0KPiANCj4gSW4gbGlnaHQgb2YgdGhhdCwgSSB3b3VsZCBzdWdn ZXN0IGRlZmluaW5nIHR3byBuZXcgdHlwZXMgb2YgYmVoYXZpb3IsIHdoaWNoIHdvdWxkIHBlcm1p dCBpbXBsZW1lbnRlcnMgdG8gY29udGludWUgcmVzaXN0aW5nIHRoZQ0KPiBhZG9wdGlvbiBvZiBU eXBlIEMgYnkgZGVmYXVsdCwgeWV0IHdvdWxkIGFsbG93IHRoZW0gdG8gYWRkIHN1cHBvcnQgZm9y IHByb2Nlc3NpbmcgUklPIG9wdGlvbnMganVzdCBpbiBORCBSZWRpcmVjdCBtZXNzYWdlcyBhbmQg bm90DQo+IFJBIG1lc3NhZ2VzLiBDYWxsIHRoYXQgYSBUeXBlIEQgaG9zdCwgYW5kIGNhbGwgdGhl IGZ1bmN0aW9uYWwgY29tYmluYXRpb24gVHlwZSBDK0Qgb3Igc29tZXRoaW5nLg0KDQpPSywgdGhh dCBtYWtlcyBzZW5zZSB0byBtZS4NCg0KPiBIZXJlIGlzIG15IHByb3Bvc2VkIHRleHQgZm9yIFNl Y3Rpb24gMy4zIEhvc3QgU3BlY2lmaWNhdGlvbi4NCj4gDQo+ID4+PiBUaGUgSG9zdCBTcGVjaWZp Y2F0aW9uIGZvbGxvd3MgU2VjdGlvbiA4LjMgb2YgTmVpZ2hib3IgRGlzY292ZXJ5IGZvciBJUCB2 ZXJzaW9uIDYgKElQdjYpIFtSRkM0ODYxXSwgU2VjdGlvbiAzIG9mIERlZmF1bHQgUm91dGVyDQo+ IFByZWZlcmVuY2VzIGFuZCBNb3JlLVNwZWNpZmljIFJvdXRlcyBbUkZDNDE5MV0sIGFuZCBTZWN0 aW9uIDMgb2YgRmlyc3QtSG9wIFJvdXRlciBTZWxlY3Rpb24gYnkgSG9zdHMgaW4gYSBNdWx0aS1Q cmVmaXggTmV0d29yaw0KPiBbUkZDODAyOF0uIEFjY29yZGluZyB0byBbUkZDNDg2MV0sIGEgaG9z dCB0aGF0IHJlY2VpdmVzIGEgdmFsaWQgTkQgUmVkaXJlY3QgbWVzc2FnZSB1cGRhdGVzIGl0cyBk ZXN0aW5hdGlvbiBjYWNoZSBwZXIgdGhlIERlc3RpbmF0aW9uDQo+IGluZm9ybWF0aW9uIGFuZCBp dHMgbmVpZ2hib3IgY2FjaGUgcGVyIHRoZSBUYXJnZXQgaW5mb3JtYXRpb24uIEFjY29yZGluZyB0 byBbUkZDNDE5MV0sIGEg4oCcVHlwZSBD4oCdIGhvc3QgdGhhdCByZWNlaXZlcyBhIHZhbGlkIFJB DQo+IG1lc3NhZ2UgdXBkYXRlcyBpdHMgcm91dGluZyB0YWJsZSBwZXIgdGhlIFJJTyBlbGVtZW50 cyBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZS4gRmluYWxseSwgYWNjb3JkaW5nIHRvIFtSRkM4MDI4 XSwgYSDigJxUeXBlIEPigJ0gaG9zdA0KPiBvcGVyYXRpbmcgb24gYSBNdWx0aS1QcmVmaXggTmV0 d29yayB3aXRoIG11bHRpcGxlIGRlZmF1bHQgcm91dGVzIGNhbiBtYWtlIHNvdXJjZSBhZGRyZXNz IHNlbGVjdGlvbiBkZWNpc2lvbnMgYmFzZWQgb24gaW5mb3JtYXRpb24gaW4NCj4gaXRzIHJvdXRl IHRhYmxlIGRlY29yYXRlZCB3aXRoIGluZm9ybWF0aW9uIGRlcml2ZWQgZnJvbSB0aGUgc291cmNl IG9mIHRoZSBSSU8gZWxlbWVudC4NCg0KQWxsIHNvdW5kcyBnb29kLCBidXQgdXNlIG9mIHRoZSB3 b3JkICJkZWNvcmF0ZWQiIHNlZW1zIHN0cmFuZ2UgaW4gdGhpcyBjb250ZXh0LiBJDQpkb24ndCBo YXZlIGEgYmV0dGVyIHN1Z2dlc3Rpb24gYXQgdGhlIG1vbWVudCwgdGhvdWdoLg0KDQo+ID4+PiBJ biBsaWdodCBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucywgdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2Vz IGEgbmV3IOKAnFR5cGUgROKAnSBiZWhhdmlvciBmb3IgaG9zdHMgd2l0aCB0aGUgc2FtZSBraW5k IG9mIHJvdXRpbmcgdGFibGUNCj4gYXMgYSDigJxUeXBlIEPigJ0gaG9zdCwgYnV0IHdoaWNoIHBy b2Nlc3NlcyBSSU8gZWxlbWVudHMgaW4gTkQgUmVkaXJlY3QgTWVzc2FnZXMgYWNjb3JkaW5nIHRv IHRoaXMgc3BlY2lmaWNhdGlvbiBpbnN0ZWFkIG9mIFJBIE1lc3NhZ2VzDQo+IGFzIGluIFJGQyA0 MTkxLiBIb3N0cyB0aGF0IHByb2Nlc3MgUklPIGVsZW1lbnRzIGluIGJvdGggUkEgbWVzc2FnZXMg YW5kIE5EIFJlZGlyZWN0IE1lc3NhZ2VzIGFyZSBzYWlkIHRvIGhhdmUg4oCcVHlwZSBDK0TigJ0N Cj4gYmVoYXZpb3IuDQoNClNvdW5kcyBnb29kLg0KDQo+ID4+PiBJbiBib3RoIHRoZSDigJxUeXBl IETigJ0gYW5kIOKAnFR5cGUgQytE4oCdIGNhc2VzLCBob3N0cyBwcm9jZXNzIE5EIFJlZGlyZWN0 IE1lc3NhZ2VzIGJ5IHVwZGF0aW5nIDEpIHRoZWlyIG5laWdoYm9yIGNhY2hlIHBlciB0aGUNCj4g VGFyZ2V0IGluZm9ybWF0aW9uLCAyKSB0aGVpciBkZXN0aW5hdGlvbiBjYWNoZSBwZXIgdGhlIERl c3RpbmF0aW9uIGluZm9ybWF0aW9uIHdoZW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQg aXMgbm90IHRoZQ0KPiB1bnNwZWNpZmllZCBhZGRyZXNzLCBhbmQgMykgdGhlaXIgcm91dGluZyB0 YWJsZXMgcGVyIGFueSBSSU8gZWxlbWVudHMgcHJlc2VudC4NCg0KU291bmRzIGdvb2QuDQoNCj4g Pj4+IFJJTyBlbGVtZW50cyBpbiBSQSBNZXNzYWdlcyBhcmUgcHJvY2Vzc2VkIGJ5IOKAnFR5cGUg ROKAnSBob3N0cyBpbiB0aGUgc2FtZSB3YXkgdGhhdCDigJxUeXBlIELigJ0gaG9zdHMgcHJvY2Vz cyB0aGVtLCBpLmUuIGJ5IGlnbm9yaW5nDQo+IHRoZW0uIEluIOKAnFR5cGUgQytE4oCdIGhvc3Rz LCBSSU8gZWxlbWVudHMgaW4gUkEgbWVzc2FnZXMgYXJlIHByb2Nlc3NlZCBpbiB0aGUgc2FtZSB3 YXkgdGhhdCDigJxUeXBlIEPigJ0gaG9zdHMgcHJvY2VzcyB0aGVtLg0KPiA+Pj4NCj4gPj4+IElu IHRoZSBhbGwgdGhlIGNhc2VzIHdoZXJlIGhvc3RzIHByb2Nlc3MgUklPIGVsZW1lbnRzLCBpLmUu IGluIFJBIE1lc3NhZ2VzIG9yIGluIE5EIFJlZGlyZWN0IE1lc3NhZ2VzIG9yIGluIGJvdGgsIGhv c3RzIE1BWQ0KPiBtYWtlIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbiBkZWNpc2lvbnMsIGFzIGlu IFtSRkM4MDI4XSwgYmFzZWQgb24gdGhlaXIgcm91dGUgdGFibGVzIGRlY29yYXRlZCB3aXRoIGlu Zm9ybWF0aW9uIGRlcml2ZWQgZnJvbSB0aGUNCj4gc291cmNlcyBvZiByZWNlaXZlZCBSSU8gZWxl bWVudHMuDQo+ID4+Pg0KPiA+Pj4gVGhlIGJlaGF2aW9ycyBvZiDigJxUeXBlIEEs4oCdIOKAnFR5 cGUgQuKAnSBhbmQg4oCcVHlwZSBD4oCdIGhvc3RzIGFyZSBub3QgY2hhbmdlZCBieSB0aGlzIHNw ZWNpZmljYXRpb24uIEluIHBhcnRpY3VsYXIsIHRoZXkgYWxsIHByb2Nlc3MgTkQNCj4gUmVkaXJl Y3QgTWVzc2FnZXMgYWNjb3JkaW5nIHRvIFNlY3Rpb24gOC4zIG9mIFtSRkM0ODYxXS4NCg0KVGhp cyBhbGwgc291bmRzIGdvb2QuIEhvdyB3b3VsZCB5b3UgZmVlbCBhYm91dCBoYXZpbmcgdGhpcyB0 ZXh0IHNob3cgdXANCmluIHRoZSBuZXh0IGRyYWZ0IHZlcnNpb24gKGFuZCBiZSBpbmNsdWRlZCBh cyBhIGNvLWF1dGhvcik/DQoNClNlY29uZCBxdWVzdGlvbiAtIHNob3VsZCB0aGUgbmV4dCBkcmFm dCB2ZXJzaW9uIGJlIGNhbGxlZDogIiotaW50YXJlYSoiIG9yDQoiKi02bWFuKiI/ICBJIGFtIGxl YW5pbmcgdG93YXJkIHRoZSBsYXR0ZXIgYmVjYXVzZSB0aGUgaW50ZXJlc3Qgc2VlbXMgdG8NCmJl IGNvbWluZyBmcm9tIHRoaXMgV0cuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJv ZWluZy5jb20NCg0KPiAtLWphbWVzIHdvb2R5YXR0IDxqaHdAZ29vZ2xlLmNvbT4NCj4gDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SW50LWFyZWEgbWFpbGluZyBsaXN0DQo+IEludC1hcmVhQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWENCg== From nobody Wed Jan 18 09:21: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 656071294C8 for ; Wed, 18 Jan 2017 09:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwuNqJJ84udC for ; Wed, 18 Jan 2017 09:21:15 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 9C48412943E for ; Wed, 18 Jan 2017 09:21:14 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id n124so17553524lfd.2 for ; Wed, 18 Jan 2017 09:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Zu0uvtSs+p7gY8qc0Qijw6ktj+0SQRiopIB+uZp0Go8=; b=lKr9+CVqJmMl8pbsyClSG5iWN7LJ9PxV2rlfPYh7fB9ACXo8ykh7vg0TCPbwZz2lnS P/uA75bjEGx+NidAi18Ovi+1pb6DkXU2O78ixZrLAuPIWMwbMAkKog2VSOc7QqdV0OD7 +rH9nBJi3bsvkuL5yDzpORbrAb7hbtbiA4JKa2dcl9jmhF+6BBB5L4Fn8AHMATtSuVyN uaoTkCOJET1eqJq7bZRE4T6YE0fJrovuMyAiiha6XIMNbVeUoMXdmzcf7bvlOatFt8Zi jeAkHU6f2JF8ro6mVd04ri3k6kZhAvsgEH01XKaCBzEgnRI76CDwlh0pDSTOPImA/DZM 17pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=Zu0uvtSs+p7gY8qc0Qijw6ktj+0SQRiopIB+uZp0Go8=; b=ivgqO/yBEZ1GiT2B9JwvnWoR7Yh5BxQvwJz183CFykefghfz0zB8pJprWjSRJJyvjD uGQeu2B0cli/pZfCQ4/cuBjUFwKHIpk+Z5mxgIb3KyyyHZJb5zsbGdaZBH2z2oFvbd4G BioXtMPoB3nbfEWObbl2MBZizM1cG+ghoUr0ByVpQvBkjvnih9c8JGes+WdUKhjrpCRX GhjqxzUz66N5qi2TnnOdDOS37lrfWwtW9+cPzsJxTBoKn21WE2rd8lzsf5X6/pgdnl81 kGYu71GE1GdezkSOVHcdT0z8HELoRUbHgKHwjoasBrvJzlfr5WOJs8F757YvUh8PzpMn DjUg== X-Gm-Message-State: AIkVDXIi/ayYPc221Vp/FJA5IsntbxOww+uoGQdRJX1xV+UwH2ZQyMU5th9YnVw2hElGWNTq2JtPdPmyZokUBg== X-Received: by 10.25.145.7 with SMTP id t7mr1701482lfd.91.1484760072804; Wed, 18 Jan 2017 09:21:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Wed, 18 Jan 2017 09:21:12 -0800 (PST) In-Reply-To: <048015f0-877d-e1da-0406-5b516862b865@si6networks.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> <048015f0-877d-e1da-0406-5b516862b865@si6networks.com> From: Behcet Sarikaya Date: Wed, 18 Jan 2017 11:21:12 -0600 Message-ID: Subject: Re: IID length text To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:21:16 -0000 On Tue, Jan 17, 2017 at 4:08 PM, Fernando Gont wrot= e: > On 01/17/2017 06:31 PM, Behcet Sarikaya wrote: >> On Tue, Jan 17, 2017 at 2:55 PM, Fernando Gont w= rote: >>> Hello, Behcet, >>> >>> On 01/17/2017 02:39 PM, Behcet Sarikaya wrote: >>>> On Mon, Jan 16, 2017 at 4:09 PM, Fernando Gont = wrote: >>>>> On 01/16/2017 06:22 PM, Behcet Sarikaya wrote: >>>>>> On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont wrote: >>>>>>> On 01/16/2017 05:42 PM, Behcet Sarikaya wrote: >>>>>>>> On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu >>>>>>>> wrote: >>>>>>>>> Le 14/01/2017 =C3=A0 20:49, Brian E Carpenter a =C3=A9crit : >>>>>>>>>> >>> [....] >>>>>>> >>>>>>> What does a layer-2 EUI have to do with a layer-3 address? >>>>>> >>>>>> I don't know, you tell me :-) >>>>> >>>>> Answer: Nothing. The fact that we've been embedding layer-2 "addresse= s" >>>>> into layer-3 addresses should not be taken as a reason for the two of >>>>> them of having to do anything with each other. So, yes, the 64-bit II= D >>>>> length is, in reality, arbitrary. They could have been e.g. 32-bits o= r >>>>> 48-bits (yes, multiples or 64 or 32 tend to be nicer) >>>>> >>>> >>>> I don't think you know much about MAC addresses and its history. >>> >>> I don't know much about elephants, either. Whatever the history (which >>> you imply I don't know), it is irrelevant, because it doesn't change th= e >>> fact that you don't need to screw your layer-3 protocol with your >>> layer-2 IDs/"addresses". >>> >> >> Good luck then running SLAAC or ARP :-) > > SLAAC: Yes, mac addresses used to be embedded in the IID, That's an > artifact of history, not a design principle. And we're heading towards > replacing that with RFC7217 (which, for many implementations, is already > the case) -- and has always been the case for, e.g., RFC4941. > > Neighbor Discovery: NS/NA messages employ link-layer address options, > which essentially convey the link-layer address as an opaque value. > That's used for learning the layer-2 address when sending a packet on a > link, which is a totally different thing from exposing such layer-2 > address at layer-3. > > There's no reason or requirement that I communicate my layer-2 address > in my layer-3 protocol when, e.g., I connect with a web server. That has > been an artifact of history (which may have happened as such for > multiple (possibly valid) reasons), but please don't confuse that with a > design principle or some sort of law from nature. > My friend Fernando, here is a quote from RFC 4941: Note that an IPv6 identifier does not necessarily have to be 64 bits in length, but the algorithm specified in this document is targeted towards 64-bit interface identifiers. I believe you will always need to send a packet on a link, even when connecting with a web server. I think you should read a basic telecom book such as from Jim Kurose. Also I think you and I are in agreement. No worries. Regards, Behcet > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Wed Jan 18 10:09: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 66C7812945E for ; Wed, 18 Jan 2017 10:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7knBci9EWE35 for ; Wed, 18 Jan 2017 10:09:32 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 11AFC12943E for ; Wed, 18 Jan 2017 10:09:32 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 8D5F463C for ; Wed, 18 Jan 2017 18:09:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoOJRb7FBMLg for ; Wed, 18 Jan 2017 12:09:31 -0600 (CST) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 42B5A676 for ; Wed, 18 Jan 2017 12:09:31 -0600 (CST) Received: by mail-vk0-f70.google.com with SMTP id n19so11303065vkd.4 for ; Wed, 18 Jan 2017 10:09:31 -0800 (PST) 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=ecRnXBq5KC5SRFDLXQCwtUuItLG/h65N0zDRp/dbrKE=; b=UuH2q7zTbz34BscIbnqHjvIxkxqR5ykGu4vRUs+/qEBgrflxR5uI/1kKhVKfvCoG61 CdPdA85BpuED/EDR/THju+xRxofYqIHg3kl+me3oUmy7EHQ8SYlpt6IndpyT0j2yd+Sy bj5LpzQSQvHz6ko5kxC9TCsToVYuzhtNj1dnyOLL3jJYBBYxvnaUb/b7dlc70dO+HBYA RhyDiWv3PMc9kShVrUR4hI05kAzzGNEaCgN0YD9X4NuJ7KsA2t9nscBKJJMoKcir8HtC NJIpV4zT1DNhAMMo/jYu2cq0jEPLnsilq/DLIVVCk/fG9NCRXFqCYE6B3xqztirWyCP4 WAfg== 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=ecRnXBq5KC5SRFDLXQCwtUuItLG/h65N0zDRp/dbrKE=; b=kwOSK69uNzYUbYoCDjTnyS85ustcwQucEqSqGbVd+fbBqO8wqSgMrzd2kOXGDhhHIK Q86+nPDRJybGKQAS58jz4tXBzL4yOyRZiPeW0WXc8exbuGknbygR3SvONKMzDuYZ1uFO 15LGrybvw28Uaftt+mESq4dQs5E60Y2/aO1cBBpLfHdSgEeSa8hKrh1tzq5xmbhxvNqf xTLY6aDa3K1wC+g2iUr36pgNCo3ZSbaCzp+OhhegwCfmco1qCLtAvnQt/JMzPh/8MPlf JeTrGbQ7toZGI/uPJVnoOPB3p9azB0/WhDoI8xDVFY7xfndWJd4azBGBw5dAeTRHS2CU /SWQ== X-Gm-Message-State: AIkVDXJiKQaP9mAPuZXdA/Ef2MWdH8XWyE7JMr4izur7GWwXhIuUXfLyy9UVwCaE/ah4tQoM9q9jra3ZdNHIIYN0ISqF8btSIzoGV2c5ljJgaKRbXBOz1ms2ZFCD33IsxcSct1R7y9X60gtrp+0= X-Received: by 10.31.49.216 with SMTP id x207mr2246683vkx.82.1484762970677; Wed, 18 Jan 2017 10:09:30 -0800 (PST) X-Received: by 10.31.49.216 with SMTP id x207mr2246669vkx.82.1484762970455; Wed, 18 Jan 2017 10:09:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Wed, 18 Jan 2017 10:09:29 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> From: David Farmer Date: Wed, 18 Jan 2017 12:09:29 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a114409b26e1dde05466251ea Archived-At: Cc: Erik Kline , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:09:34 -0000 --001a114409b26e1dde05466251ea Content-Type: text/plain; charset=UTF-8 For such a supposedly "fixed boundary" it's awfully schizophrenic. We supposedly want the option to change it in the future if necessary. So, then it's not so fixed that it's intended to be immutable, which is why we needed RFC 5942 and RFC 7608. It's not so fixed that we don't have exceptions, we have standardized /127 subnets and 127 IIDs for point-to-points links, with RFC 6164. It doesn't sound so fixed to me, and it seems intellectually dishonest as a standards body to keep saying it's a fixed boundary when their is so much evidence to the contrary. If fact, I believe it is down right dangerous and counter productive to our intent to keep saying it's a fixed boundary. If we are simply start calling it a "recommended subnet size" then the issues that make a "fixed boundary" schizophrenic are no longer much of an issue. Recommendations frequently have exceptions and they are allowed to change as things evolve, "fixed boundaries" aren't suppose to do either of those. /64 subnets are properly a recommendation, all be it, a very important recommendation, maybe even a fundamental. But, just because a recommendation is important doesn't turn it in to a requirement. That is intellectually dishonest and section 6 of RFC 2119 warns against it. If we want/need to enshrine /64 subnets and 64 bit IIDs for SLACC I'm willing to live with that. But to enshrining /64 subnets and 64 bit IIDs for all of IPv6 is a mistake. And, it's a mistake that I feel needs correcting before this document is promoted to full Internet Standard. So, how about; ... For all currently allocated unicast addresses, except those that start with the binary value 000, that length should be 64 bits and for SLACC [RFC 4862] that length is required to be 64 bits. On Wed, Jan 18, 2017 at 1:36 AM, Lorenzo Colitti wrote: > +1 > > I don't think we should change this text in a reclassification. The fact > that there are such strong opinions about the fixed boundary suggests that > people think that it's an important property of the standard. > > That text has been the standard for almost 20 years. If we want to change > it, then let's do it the right way: write a draft of a document that > updates 4291 (or updates whatever number 4291bis ends up being, if we can > somehow resolve the current point and publish it), and see if we can reach > consensus. I doubt that will be easy. > > On Wed, Jan 18, 2017 at 6:32 AM, wrote: > >> I would argue that we should not make any changes to this text (apart >> from the eui-64 part). >> >> Cheers, >> Ole >> >> >> >> > On Tue, Jan 17, 2017 at 4:00 AM, wrote: >> > > What breaks if all IIDs in global unicast are not 64 bits? >> Especially other than SLACC? I would hope such a REQUIREMENT has a better >> motivation that "we said so". Citing the "rest of the specifications" was >> simply my shorthand for I don't see what else breaks. >> > >> > RFC7421, section 4.2. >> > >> > There's also a set of political considerations, where one tries to >> achieve balance between the provider's desire to have effective aggregation >> and the end-users desire to have enough address space. We specifically want >> to avoid provider's charging by the address. >> > >> > O. >> > >> > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it >> does not say to me "IIDs MUST be 64 bits", this is a subtle but important >> difference. Furthermore, RFC7421, section 4.3.2, also say there is >> operational use of IID other than 64 bits, which to me disproves the >> statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 >> bits." >> > >> > So lets be clear, I'm not saying that we should RECOMMEND other than 64 >> bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC >> 2119. >> > >> > So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to >> the in my opinion the more proper "IIDs SHOULD be 64 bits". >> > >> > So, I would prefer: >> > >> > ... For all currently >> > allocated unicast addresses, except those that start with the binary >> > value 000, that length should be 64 bits. >> > >> > But, I'm willing to live with what Brian proposed: >> > >> > ... For all currently >> > allocated unicast addresses, except those that start with the binary >> > value 000, that length is 64 bits. >> > >> > But, I can not accept what Eric proposed: >> > >> > ... For all currently >> > allocated unicast addresses, except those that start with the binary >> > value 000, that length is required to be 64 bits. >> > >> > Thanks. >> > -- >> > =============================================== >> > David Farmer Email:farmer@umn.edu >> > Networking & Telecommunication Services >> > Office of Information Technology >> > University of Minnesota >> > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> > =============================================== >> >> > -- =============================================== 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 =============================================== --001a114409b26e1dde05466251ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For such a supposedly "fixed boundary&= quot; it's awfully schizophrenic. We supposedly want the option to chan= ge it in the future if necessary.=C2=A0 So, then it's not so fixed that= it's intended to be immutable, which is why we needed RFC 5942 and RFC= 7608. It's not so fixed that we don't have exceptions, we have sta= ndardized /127 subnets and 127 IIDs for point-to-points links, with RFC 616= 4. It doesn't sound so fixed to me, and it seems intellectually dishone= st as a standards body to keep saying it's a fixed boundary when their = is so much evidence to the contrary.=C2=A0 If fact, I believe it is down ri= ght dangerous and counter productive to our intent to keep saying it's = a fixed boundary. =C2=A0

If we are simply start calling = it a "recommended subnet size" then the issues that make a "= fixed boundary" schizophrenic are no longer much of an issue. Recommen= dations frequently have exceptions and they are allowed to change as things= evolve, "fixed boundaries" aren't suppose to do either of th= ose.=C2=A0 /64 subnets are properly a recommendation, all be it, a very imp= ortant recommendation, maybe even a fundamental.=C2=A0 But, just because a = recommendation is important doesn't turn it in to a requirement.=C2=A0 = That is intellectually dishonest and section 6 of RFC 2119 warns against it= .

If we want/need to enshrine /64 subnets and= 64 bit IIDs for SLACC I'm willing to live with that.=C2=A0 But to ensh= rining /64 subnets and 64 bit IIDs for all of IPv6 is a mistake. And, it= 9;s a mistake that I feel needs correcting before this document is promoted= to full Internet Standard.

So, how about;

=C2=A0 =C2=A0... For all currently
=C2=A0 =C2=A0= allocated unicast addresses, except those that start with the binary
=C2= =A0 =C2=A0value 000, that length should be 64 bits and for SLACC [RFC 4862]=
=C2=A0 =C2=A0that length=C2=A0is required to be 64 bits.

On Wed, Jan 18, 2017 at 1:36 AM, Lorenzo Colitti <lo= renzo@google.com> wrote:
+1

I don't think w= e should change this text in a reclassification. The fact that there are su= ch strong opinions about the fixed boundary suggests that people think that= it's an important property of the standard.

That te= xt has been the standard for almost 20 years. If we want to change it, then= let's do it the right way: write a draft of a document that updates 42= 91 (or updates whatever number 4291bis ends up being, if we can somehow res= olve the current point and publish it), and see if we can reach consensus. = I doubt that will be easy.

On Wed, Jan 18, 2017 at 6:32 AM, &l= t;otroan@employee= s.org> wrote:
I would argue that we should not make any changes to this text (apart= from the eui-64 part).

Cheers,
Ole



> On Tue, Jan 17, 2017 at 4:00 AM, <otroan@employees.org> wrote:
> > What breaks if all IIDs in global unicast are not 64 bits?=C2=A0 = Especially other than SLACC?=C2=A0 I would hope such a REQUIREMENT has a be= tter motivation that "we said so".=C2=A0 Citing the "rest of= the specifications" was simply my shorthand for I don't see what = else breaks.
>
> RFC7421, section 4.2.
>
> There's also a set of political considerations, where one tries to= achieve balance between the provider's desire to have effective aggreg= ation and the end-users desire to have enough address space. We specificall= y want to avoid provider's charging by the address.
>
> O.
>
> Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits,&quo= t; but it does not say to me "IIDs MUST be 64 bits", this is a su= btle but important difference.=C2=A0 Furthermore, RFC7421, section 4.3.2, a= lso say there is operational use of IID other than 64 bits, which to me dis= proves the statement "IIDs MUST be 64 bits" and shifts things to = "IIDs SHOULD be 64 bits."
>
> So lets be clear, I'm not saying that we should RECOMMEND other th= an 64 bit IIDs, I'm simply differentiating between section 1 and sectio= n 3 of RFC 2119.
>
> So, I'm asking what breaks if we change from "IIDs MUST be 64= bits" to the in my opinion the more proper "IIDs SHOULD be 64 bi= ts".
>
> So, I would prefer:
>
>=C2=A0 =C2=A0...=C2=A0 For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length should be 64 bits.
>
> But, I'm willing to live with what Brian proposed:
>
>=C2=A0 =C2=A0 ... For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length is 64 bits.
>
> But, I can not accept what Eric proposed:
>
>=C2=A0 =C2=A0 ...=C2=A0 For all currently
>=C2=A0 =C2=A0 allocated unicast addresses, except those that start with= the binary
>=C2=A0 =C2=A0 value 000, that length is required to be 64 bits.
>
> Thanks.
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
> David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Email:farmer@umn.e= du
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
> Minneapolis, MN 55414-3029=C2=A0 =C2=A0Cell: 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





--
=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
--001a114409b26e1dde05466251ea-- From nobody Wed Jan 18 10:18: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 726B31294EF for ; Wed, 18 Jan 2017 10:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUJTsfp_Vg_v for ; Wed, 18 Jan 2017 10:18:46 -0800 (PST) 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 1E0011294ED for ; Wed, 18 Jan 2017 10:18:45 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id e4so6096393pfg.1 for ; Wed, 18 Jan 2017 10:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=7s9a5lz2EYJcTedHgIPYVmGBtDi90anIDPzCC+gInVI=; b=fq2dVVsJOG9V1NSHZfAypJVDWrmS8R0LeZ+MLIbDjrfBhtHmm/msHV9ImyYdd+mcCV hdiDzOdC54WGRL2dFPKn/LY3rtfynwW46KkmjUYJ1Sqn3WtZhaIvAG1CplapEh3dj8Wr mluNzszbX4Hof5getePOZI5xp7LOA8Vo+N5yoU8hEVaVtN47PZZP+MZ6TACGYZKhDFu7 py/kyjZDUyYGax8yfzWkY0Qa3axyYY5pUmnlNzSHQh/JGJGlABfNQKmqGTHCur+Zz0/n 4V5Z/cuME3wQ5Nj4qXlkAIvD6WJasz+H4GnA7uaBlR2HeFMjEkG+wFpdk4CxPvtSuRLy CT+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:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7s9a5lz2EYJcTedHgIPYVmGBtDi90anIDPzCC+gInVI=; b=L0CwGuarHzT37zP3u0InysqJK7eS5Q2H/VUyHr2u6/4RIodbDDP5RoxgwL9vzLnIi6 ueqd0Gt2aaWJ43U8wzsFM6EAwbFQxD8i86xncS0a/WLrhy6TNixJo+gmurvKgoPFvwLh dc/QPvQih5wxSC+TICcCjg+htqMNX+HjzHBB+N36CNla00Ghbp4o61PzqshrJTfQC6zC hxjvk2vm0j4P34+DKxtpt6XKMJ+xBA22Ge8H+loe8ipLQfJt2T2QIpxOfvwmHWrCUFXI M5N9BaoVd3734sKOWhAYZF0c+dKDOfZLwdi9RfWN3q38crLDK9l7Dgg5nOvAlbfHveU0 q4xg== X-Gm-Message-State: AIkVDXKlD/JuEl1g+nHhCHLAge2hipaoWAxK0JfINzthy2+oUbdfIDgbsNtwUcPyxTAl+ohC X-Received: by 10.98.208.70 with SMTP id p67mr5357632pfg.101.1484763524587; Wed, 18 Jan 2017 10:18:44 -0800 (PST) Received: from ?IPv6:2620::10e7:10:1deb:c2e4:c17b:3951? ([2620:0:10e7:10:1deb:c2e4:c17b:3951]) by smtp.gmail.com with ESMTPSA id j185sm2327253pgd.35.2017.01.18.10.18.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Jan 2017 10:18:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7EE79DB7-ED4B-44EA-A446-405F85285D53" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Int-area] Route Information Options in Redirect Messages From: james woodyatt In-Reply-To: Date: Wed, 18 Jan 2017 10:18:43 -0800 Message-Id: References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: INT Area , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:18:47 -0000 --Apple-Mail=_7EE79DB7-ED4B-44EA-A446-405F85285D53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 18, 2017, at 08:44, Templin, Fred L = wrote: >=20 > This all sounds good. How would you feel about having this text show = up in the next draft version (and be included as a co-author)? Thank you for inviting me to be a co-author! Yes, I would be happy to = accept. Please sign me up. --james woodyatt > --Apple-Mail=_7EE79DB7-ED4B-44EA-A446-405F85285D53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 18, 2017, at 08:44, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

This all sounds good. How would you feel about = having this text show up in the next draft = version (and be included as a = co-author)?

Thank you for inviting me to be a = co-author! Yes, I would be happy to accept. Please sign me up.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_7EE79DB7-ED4B-44EA-A446-405F85285D53-- From nobody Wed Jan 18 10:40: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 0BF1012943B; Wed, 18 Jan 2017 10:39:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-segment-routing-header-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148476479804.1984.4001573248650342268.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 10:39:58 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IPv6 Segment Routing Header (SRH) Authors : Stefano Previdi Clarence Filsfils Brian Field Ida Leung Jen Linkova Ebben Aries Tomoya Kosugi Eric Vyncke David Lebrun Filename : draft-ietf-6man-segment-routing-header-04.txt Pages : 28 Date : 2017-01-18 Abstract: Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-segment-routing-header-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 18 10:41: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 3356C129556 for ; Wed, 18 Jan 2017 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYwdiIoK4OsG for ; Wed, 18 Jan 2017 10:41:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9578129557 for <6man@ietf.org>; Wed, 18 Jan 2017 10:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1484764862; x=1485974462; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IwsyuT/Y+x2Mg3oWs+wIU8hjmZ8/1UXHVNj1rh9UMGw=; b=BegrMd/vqWx/Se8s7fwjWhJ+ySyxKaTgMC9IziGdaURFYoDwAet1WcwT UWoTugvBwmtiS5GYw/9XJ0Y9vdGwIKLT8Ss78G07FC57oIeni/MKQGOIT WeevsJmEOC810sFrNAUvMyUuT4qBhdMyzTp8OWDAs/IgNZMp8AfG+dF1s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQDytX9Y/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9ggQkHg0qKCJFjH4MZkhOCCyyFdgIagWk/GAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEDASMRQwcLAgEIGAICJgICAjAVEAIEE4h7CA6ve4IlijgBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQuFQIIFCIJhghV3gT2DBi2CMQWPJ4waAYZ?= =?us-ascii?q?eiwOBd1GEPYlokm4BHziBRBUYMgGGInMBh3OBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,250,1477958400"; d="scan'208";a="196672145" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 18:41:01 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0IIf1eC004631 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6man@ietf.org>; Wed, 18 Jan 2017 18:41:01 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 13:41:00 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 18 Jan 2017 13:41:00 -0500 From: "Stefano Previdi (sprevidi)" To: "<6man@ietf.org>" <6man@ietf.org> Subject: Re: New Version Notification for draft-ietf-6man-segment-routing-header-04.txt Thread-Topic: New Version Notification for draft-ietf-6man-segment-routing-header-04.txt Thread-Index: AQHScbpI2O1w3AUU/U+EojDKCZE326E+5VQA Date: Wed, 18 Jan 2017 18:41:00 +0000 Message-ID: References: <148476479818.1984.4276872303819042324.idtracker@ietfa.amsl.com> In-Reply-To: <148476479818.1984.4276872303819042324.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.64.125] Content-Type: text/plain; charset="utf-8" Content-ID: <260ADD74B7D214488903D0E38F995E57@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:41:05 -0000 U29ycnksDQoNCkkgZm9yZ290IHRvIHJlbW92ZSBzb21lIOKAnGNsZWFudXAtYml04oCdIHRleHQg YW5kIHJlZmVyZW5jZXMgZnJvbSB0aGUgZHJhZnQuIE5vdywgaG9wZWZ1bGx5LCBpdCBpcyBjb25z aXN0ZW50Lg0KDQp0aGFua3MuDQpzLg0KDQoNCj4gT24gSmFuIDE4LCAyMDE3LCBhdCA3OjM5IFBN LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLTA0LnR4dA0K PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0ZWZhbm8gUHJldmlkaSBhbmQg cG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaWV0 Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXINCj4gUmV2aXNpb246CTA0DQo+IFRpdGxlOgkJ SVB2NiBTZWdtZW50IFJvdXRpbmcgSGVhZGVyIChTUkgpDQo+IERvY3VtZW50IGRhdGU6CTIwMTct MDEtMTgNCj4gR3JvdXA6CQk2bWFuDQo+IFBhZ2VzOgkJMjgNCj4gVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLTZtYW4tc2VnbWVu dC1yb3V0aW5nLWhlYWRlci0wNC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVy Lw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLTA0DQo+IERpZmY6ICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXItMDQNCj4gDQo+IEFic3RyYWN0Og0KPiAgIFNlZ21lbnQgUm91dGluZyAoU1Ip IGFsbG93cyBhIG5vZGUgdG8gc3RlZXIgYSBwYWNrZXQgdGhyb3VnaCBhDQo+ICAgY29udHJvbGxl ZCBzZXQgb2YgaW5zdHJ1Y3Rpb25zLCBjYWxsZWQgc2VnbWVudHMsIGJ5IHByZXBlbmRpbmcgYW4g U1INCj4gICBoZWFkZXIgdG8gdGhlIHBhY2tldC4gIEEgc2VnbWVudCBjYW4gcmVwcmVzZW50IGFu eSBpbnN0cnVjdGlvbiwNCj4gICB0b3BvbG9naWNhbCBvciBzZXJ2aWNlLWJhc2VkLiAgU1IgYWxs b3dzIHRvIGVuZm9yY2UgYSBmbG93IHRocm91Z2gNCj4gICBhbnkgcGF0aCAodG9wb2xvZ2ljYWws IG9yIGFwcGxpY2F0aW9uL3NlcnZpY2UgYmFzZWQpIHdoaWxlDQo+ICAgbWFpbnRhaW5pbmcgcGVy LWZsb3cgc3RhdGUgb25seSBhdCB0aGUgaW5ncmVzcyBub2RlIHRvIHRoZSBTUiBkb21haW4uDQo+ IA0KPiAgIFNlZ21lbnQgUm91dGluZyBjYW4gYmUgYXBwbGllZCB0byB0aGUgSVB2NiBkYXRhIHBs YW5lIHdpdGggdGhlDQo+ICAgYWRkaXRpb24gb2YgYSBuZXcgdHlwZSBvZiBSb3V0aW5nIEV4dGVu c2lvbiBIZWFkZXIuICBUaGlzIGRyYWZ0DQo+ICAgZGVzY3JpYmVzIHRoZSBTZWdtZW50IFJvdXRp bmcgRXh0ZW5zaW9uIEhlYWRlciBUeXBlIGFuZCBob3cgaXQgaXMNCj4gICB1c2VkIGJ5IFNSIGNh cGFibGUgbm9kZXMuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCg== From nobody Wed Jan 18 10:50: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 5754912945C for ; Wed, 18 Jan 2017 10:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 pg7mviov88Fk for ; Wed, 18 Jan 2017 10:50:54 -0800 (PST) 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 1F01312943E for ; Wed, 18 Jan 2017 10:50:54 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id e4so6281091pfg.1 for ; Wed, 18 Jan 2017 10:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=kV3twzg0JnGe2h7sZkkJnq1+k70hGvJf0tKip14YUfg=; b=u5vSWIhQMeuTLY4YogdsmeX/wRH6d4187E8meLSsS1PTWehKKTV5piDGAkyBRpc2rD 4bZMxnmnVp5uLPTT4a8Eh4Bw1JZoqGYPFVID+ldzBTl2HWytU2xK/OSl1Y6wJEh98M9Y 7zhMdH3u/Q6RYgB+4wXTfju2NWcnZdqaVJ42h969z4WCjGupj7in/lLCaRgIfK9pNye7 3zl1PMDR4Esw+qqHUGBoKrYehE9HZKyqIZHZBaJYOGpRlCnlMSnqMIopezIZGpTx/1Iv Bf3MBR9d6DLAr+ff0Mfo+WCjAxRfNTAbWHVoIMyJBDpo1wtRzIpIS/7BZm6s1cEzkZRK vyMQ== 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 :references:to:in-reply-to; bh=kV3twzg0JnGe2h7sZkkJnq1+k70hGvJf0tKip14YUfg=; b=hVHVykhCOlv6ACm+mqa18WlEpzUzYsw5rNxT35fPE9mwf8Ym1ohYW/krxkN6gw643K Vt7iDVWB6OrofTJKp1vbMQnRDZCRMhB1Hjtn1cD6+O8+j0Wd83iLQyIWheZWs+meNYbP 74eNhHCykHFaDz44nWDPtZNwkV38A+stqGywvr9RZilNWlzDXw3lZG8ymUYfgQ9HqVG+ /EbxJqGIE2AKQoUrglv9E2W5dSdAxigsi5ydSmr7IQsCuO945Ya/nnKZpG1IR51hsipj RdK4P7RHwpcODkND+HLCRTRL0fzbPocowNKr0rHgj7BD2/3NR67KQidVPdGD5XUHUMqi aIlQ== X-Gm-Message-State: AIkVDXKLd9iTdBja12BlhP13AZeXFLomJEFmDNeSqiRIISKxq2z5xlHGmUI6E0jdB9lOJm2j X-Received: by 10.98.3.7 with SMTP id 7mr5449720pfd.9.1484765453387; Wed, 18 Jan 2017 10:50:53 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id a8sm2533366pfa.19.2017.01.18.10.50.52 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Jan 2017 10:50:52 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_26BF2336-682A-4F79-88E7-7CE3628D493D" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Date: Wed, 18 Jan 2017 10:50:51 -0800 References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> To: 6man In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:50:55 -0000 --Apple-Mail=_26BF2336-682A-4F79-88E7-7CE3628D493D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 16, 2017, at 18:36, Erik Kline wrote: >=20 > Actually, I think the NEW text is pretty reasonable if we could > restore the word "required" for the currently allocated unicast status > quo: >=20 > From: >=20 > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is 64 bits. >=20 > To: >=20 > ... For all currently > allocated unicast addresses, except those that start with the binary > value 000, that length is required to be 64 bits. >=20 > We can always produce a document that updates 4291bis for 4::/3 or > whatever we want, and the new text states so explicitly. >=20 > But I'm not convinced we should change to text that could be read to > weaken the current situation. I fully agree. My apologies if I=E2=80=99m coming into the discussion with a point = everyone has already dismissed, but it seems to me there is a procedural = matter regarding the fact that RFC 4941 doesn=E2=80=99t actually = describe how to generate temporary addresses with IID length other than = 64 bits. In the first paragraph of Section 1, RFC 4941 says "Note that an IPv6 = identifier does not necessarily have to be 64 bits in length, but the = algorithm specified in this document is targeted towards 64-bit = interface identifiers.=E2=80=9D And nothing else about it appears = elsewhere in the text. It doesn=E2=80=99t seem like a host receiving a = RA Message containing a PIO option with A=3D1 is permitted to generate = temporary addresses by SLAAC unless the prefix length is 64 bits. This seems important to me because the text Erik proposes here provides = a guarantee to sub-IPv6 link protocol developers that RFC 4941 is an = available as a standard for generating temporary addresses using SLAAC = for every currently allocated globally-unique prefix. If that = requirement disappears in RFC 4291bis, then those of us involved in the = development of new sub-IPv6 link layers will not have that guarantee, = which may force some of us to develop link-layer alternatives (possibly = involving address translation) in order to provide comparable address = privacy properties on subnets with globally-unique prefixes longer than = 64 bits. I don=E2=80=99t want to see 6MAN place this possible new requirement on = link-layer developers by removing it from IPv6. --james woodyatt > --Apple-Mail=_26BF2336-682A-4F79-88E7-7CE3628D493D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 16, 2017, at 18:36, Erik Kline <ek@google.com> = wrote:

Actually, I think the NEW text is pretty = reasonable if we could
restore the word "required" for the = currently allocated unicast status
quo:

From:

  ... For all = currently
  allocated unicast addresses, except = those that start with the binary
  value 000, = that length is 64 bits.

To:
  ...  For all currently
=   allocated unicast addresses, except those that start with = the binary
  value 000, that length is required = to be 64 bits.

We can always produce a = document that updates 4291bis for 4::/3 or
whatever we = want, and the new text states so explicitly.

But I'm not convinced we should change to text that could be = read to
weaken the current = situation.

I fully = agree.

My apologies if I=E2=80=99m = coming into the discussion with a point everyone has already dismissed, = but it seems to me there is a procedural matter regarding the fact that = RFC 4941 doesn=E2=80=99t actually describe how to generate temporary = addresses with IID length other than 64 bits.

In the first paragraph of Section 1, RFC 4941 says = "Note that an IPv6 identifier does not necessarily have to be 64 bits in = length, but the algorithm specified in this document is targeted towards = 64-bit interface identifiers.=E2=80=9D And nothing else about it appears = elsewhere in the text. It doesn=E2=80=99t seem like a host receiving a = RA Message containing a PIO option with A=3D1 is permitted to generate = temporary addresses by SLAAC unless the prefix length is 64 = bits.

This seems important to me = because the text Erik proposes here provides a guarantee to sub-IPv6 = link protocol developers that RFC 4941 is an available as a standard for = generating temporary addresses using SLAAC for every currently allocated = globally-unique prefix. If that requirement disappears in RFC 4291bis, = then those of us involved in the development of new sub-IPv6 link layers = will not have that guarantee, which may force some of us to develop = link-layer alternatives (possibly involving address translation) in = order to provide comparable address privacy properties on subnets with = globally-unique prefixes longer than 64 bits.

I don=E2=80=99t want to see 6MAN place this = possible new requirement on link-layer developers by removing it from = IPv6.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_26BF2336-682A-4F79-88E7-7CE3628D493D-- From nobody Wed Jan 18 11:29: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 53057129864 for ; Wed, 18 Jan 2017 11:29:38 -0800 (PST) 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, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 oOWr9gB4F1Vv for ; Wed, 18 Jan 2017 11:29:37 -0800 (PST) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43B71297F7 for ; Wed, 18 Jan 2017 11:29:36 -0800 (PST) Received: by mail-qt0-x242.google.com with SMTP id l7so3475955qtd.3 for ; Wed, 18 Jan 2017 11:29:36 -0800 (PST) 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=JtVFZZHznI9mOyo5THB1BgWtbHc9s0xWyUdbclMbfwA=; b=HI2E+ffGRV0xS8S6pZJYpOpfReuikY1vZh4mIE3OuTn/7h0lBwJc8ZrhjrFP32aHfl atDc7ebhvWLIhHymUArlsfdOxfoQ7bMslrDqIrQ7L9VMVgGoLSeYByJ2FlZ3v5IDf3fy M21N5TtMmcPUQKM81IXmuizHoAyXhUGeANtxvbDyjn15knxV4kKpH6tl3opIZS74gs4U dL/SJNa6Kn+Oq5aq9/zNx8RQSzunSUOVPQ6e2Vn2Cyki9u72+moUbtZb0w2vuqNTBKC3 aUgfMgvxiWKuFdTlTohSuUu4JCSkGeBtP7LUHzDDQqBaLH0kJR6gCE6/8rWhjMYgE3jS WNcQ== 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=JtVFZZHznI9mOyo5THB1BgWtbHc9s0xWyUdbclMbfwA=; b=uP3aICV2fuqPZhO7HvGYs/a57SKg6M6IV+gEAkWZQsyo049laEiqi3jnHG93Xaa79I EBpuj7oqHo/uKxFCQ7zaLDz1lNogC5OqH9GlMX7vQRhFRZ7zEG158yQaB5NBLwp6niKI 08UBnKwH2oZMbz+U/3nCmSP8UgchxhKishoC2inlTp9/T0e6omE4FiSndqMZeO82d66G AVMGhAt5UNEvkYUqXff8kBXfreLm1PprR6+PIU3z/5qPZGCaNkAuFf6aHpwbPPOylMeq KODeYdbVCLBEgoPMx5uQjjD8n0j+tgew/ITayvzoGnQqg3EW11m7IItMiv7z6kROyGjb NghA== X-Gm-Message-State: AIkVDXLSDG1apFKYIioTgLmFfID+tPq2wCYeB5FkhYGkfkHFf2ts4g5ao6M8rnDE3R4RfWb6TfGnZS0VF/mA5w== X-Received: by 10.55.3.14 with SMTP id 14mr4354593qkd.86.1484767776010; Wed, 18 Jan 2017 11:29:36 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Wed, 18 Jan 2017 11:29:35 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <5c9ea94a40bf4d95b6656debfe24f69b@XCH15-06-11.nw.nos.boeing.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 18 Jan 2017 11:29:35 -0800 X-Google-Sender-Auth: 7tk_S6xIiKR_Frg5XrdzfJ-b770 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:29:38 -0000 At Tue, 17 Jan 2017 23:04:08 -0300, Fernando Gont wrote: > Has anyone tred what happens if a prefix from::/3 is advertised for slaac? I didn't, but I'm quite sure about BSD variants (perhaps including iOS) that they don't check the prefix (as long as they are global) for the purpose of SLAAC. This is based on the interpretation of RFC4862 that for the purpose of SLAAC the IID length is solely a parameter of the underlying link: interface identifier - a link-dependent identifier for an interface that is (at least) unique per link [RFC4291]. Stateless address autoconfiguration combines an interface identifier with a prefix to form an address. From address autoconfiguration's perspective, an interface identifier is a bit string of known length. The exact length of an interface identifier and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). Note that the address architecture [RFC4291] also defines the length of the interface identifiers for some set of addresses, but the two sets of definitions must be consistent. In many cases, the identifier will be derived from the interface's link-layer address. So, for example, if the advertised prefix length on an Ethernet link is not 64, that prefix is simply ignored for SLAAC according to Section 5.5.3 d) of RFC4862: If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. That's the same regardless of what prefix it is, whether it's in or outside of ::/3. -- JINMEI, Tatuya From nobody Wed Jan 18 12:54:07 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 95ED91293EC; Wed, 18 Jan 2017 12:54:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" Subject: Ben Campbell's No Objection on draft-ietf-6man-rdnss-rfc6106bis-15: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148477284160.2024.12629325086140818649.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 12:54:01 -0800 Archived-At: Cc: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, fgont@si6networks.com, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:54:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-6man-rdnss-rfc6106bis-15: 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-rdnss-rfc6106bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -5.2, "Domain Names of DNS Search List": Because the size of this field MUST be a multiple of 8 octets,..." Is the MUST intentionally capitalized? If so, please consider moving it out of the condition clause. From nobody Wed Jan 18 16:38:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76705129444 for ; Wed, 18 Jan 2017 16:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ehepi2XCm6SC for ; Wed, 18 Jan 2017 16:37:59 -0800 (PST) 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 4E0CC129435 for ; Wed, 18 Jan 2017 16:37:59 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id 189so8290240pfu.3 for ; Wed, 18 Jan 2017 16:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5y92gjYILb28s5hOLHik37NBWS3A1joY0d7K/A1INt8=; b=acLu2aaCyaVL1FWxddX1zTb2sENwEw5eI04j42M38icbTgcoQ88NG1+2C8Hk0R6m2E BB6gVf4xDeGhRMviKSvGIHHb1m7h2p1WkxwzBTEElOJWGOH7mWXh3eWP4Rcvff+AwxyG BvlYouDvTRLPiibDTOuxPKd4MFXeL16qK2oLnYRiGJaxo9rFqqgtkkypHH1EXy25ZqB0 qOCuCkxAAYDc8cg7jfGVTqHXKpYxFeEp9NK+0PZ5GYNKvNEaQZ2q2uyIWE39JMvfj3DN EnNTsiJXFaBSYLv49PMufmgGodqhgcNE81CHIfFi3+KB0jQmYlCR89o1t9hLKTmm2z0A nWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5y92gjYILb28s5hOLHik37NBWS3A1joY0d7K/A1INt8=; b=XqABTe6m6y4FmCEzv9IdZb7+mN01xMkrFl+0BnB+S3ykZwm8EAVGN78Qg3Tjtl0SIk be0q+8AsEWYIRuajcUSiJWUk4kjeZxFuf0W2lWL9LPOpOlZY2Y6lh+ux13DOmhxCheQp tYeWNMx9JHauDH6Azgr248RYQZEx2NcLyxrsFFUyAw1ueiIBBzMCsKHeckCnubql2YDI SCgyMp1SaDDajgVDc0wVByeV21+nbPwgghYL0Im3i4aOGGS0eWtfx8EvWv6NH0kmmu5s pu3F/+VNgbzY0TAmriYkvHME9L7r7lexPdqQ4T4qQDauVwP2rL8+s9oirLLI/eYtXv1P ihmw== X-Gm-Message-State: AIkVDXIg91HRL1d4vt87ZiW6GeHy4+psg0E5WSkBIt1+A2r9PMAlIS5aUNFS3696swPy/w== X-Received: by 10.99.5.15 with SMTP id 15mr7078516pgf.109.1484786278692; Wed, 18 Jan 2017 16:37:58 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id x16sm3303454pfk.79.2017.01.18.16.37.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 16:37:58 -0800 (PST) From: Brian E Carpenter Subject: Updated IID length text To: 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Organization: University of Auckland Message-ID: Date: Thu, 19 Jan 2017 13:37:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:38:00 -0000 OK, after all that discussion, here is a revised proposal. There is nothing new here at all, IMHO; just clarification: OLD For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, consistent use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires that all interfaces on a link use the same length of Interface ID. To guarantee interoperability of SLAAC, a fixed length of Interface ID is necessary. For all currently allocated unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Regards Brian From nobody Wed Jan 18 18:46: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 1AF85129453 for ; Wed, 18 Jan 2017 18:46:12 -0800 (PST) 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 p_QFAS0RzacK for ; Wed, 18 Jan 2017 18:46:10 -0800 (PST) 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 B37EB129464 for ; Wed, 18 Jan 2017 18:46:10 -0800 (PST) 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 v0J2kAb0003815; Wed, 18 Jan 2017 19:46:10 -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 v0J2k1LV003252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 19:46:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 18:46:00 -0800 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.1178.000; Wed, 18 Jan 2017 18:46:00 -0800 From: "Manfredi, Albert E" To: Brian E Carpenter , 6man Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexT724zBn76p0KKsEzsg727/qE/EBsQ Date: Thu, 19 Jan 2017 02:46:00 +0000 Message-ID: <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 02:46:12 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter =20 > OK, after all that discussion, here is a revised proposal. There is > nothing new here at all, IMHO; just clarification: >=20 > OLD > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >=20 > NEW > IPv6 routing is based on prefixes of any valid length up to 128 [BCP19= 8]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length > of Interface ID. To guarantee interoperability of SLAAC, a fixed lengt= h of > Interface ID is necessary. For all currently allocated unicast address= es, > except those that start with the binary value 000, Interface IDs are > required to be 64 bits long. Background on the 64 bit boundary in IPv= 6 > addresses can be found in [RFC7421]. Just some minor edits, to tie together the ideas. NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]= . For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, consistent use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires all interfaces on a link to use the same lengt= h of Interface ID. Furthermore, to guarantee robust interoperability of SL= AAC, a standard, fixed length of Interface ID is necessary. For this reason, = the Interface ID of all currently allocated unicast addresses, except those = that start with the binary value 000, are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. I don't think that SLAAC *must* require a single standard IID length, so th= at's why I added the word "robust." Now that we have moved away from using = the MAC address for SLAAC, it's not clear to me why a host cannot wait for = a RA, and then decide on how many IID bits to use, based on the prefix leng= th(s) advertised by the router. Bert From nobody Wed Jan 18 18:55: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 D3F841294AE for ; Wed, 18 Jan 2017 18:55:38 -0800 (PST) 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 Z2xtOpyXjMlN for ; Wed, 18 Jan 2017 18:55:37 -0800 (PST) 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 26A7B126579 for ; Wed, 18 Jan 2017 18:55:37 -0800 (PST) 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 v0J2tawd034469; Wed, 18 Jan 2017 19:55:36 -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 v0J2tSvc034445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 19:55:28 -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.1178.4; Wed, 18 Jan 2017 18:55:26 -0800 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.1178.000; Wed, 18 Jan 2017 18:55:27 -0800 From: "Manfredi, Albert E" To: Brian E Carpenter , 6man Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexT724zBn76p0KKsEzsg727/qE/EBsQgAAKfeA= Date: Thu, 19 Jan 2017 02:55:27 +0000 Message-ID: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <55bb8bdbfbf4439da0aa702e5bc03e2c@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 02:55:39 -0000 Shoot. Grammar alert. Subject must agree with predicate. NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]= . For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, consistent use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires all interfaces on a link to use the same lengt= h of Interface ID. Furthermore, to guarantee robust interoperability of SL= AAC, a standard, fixed length of Interface ID is desirable. For this reason, = the Interface ID of all currently allocated unicast addresses, except those = that start with the binary value 000, is required to be 64 bits long. Backgro= und on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Bert > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E > Sent: Wednesday, January 18, 2017 21:46 > To: Brian E Carpenter ; 6man > Subject: RE: Updated IID length text >=20 > > -----Original Message----- > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpente= r >=20 > > OK, after all that discussion, here is a revised proposal. There is > > nothing new here at all, IMHO; just clarification: > > > > OLD > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long. Backgroun= d > > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > > > > NEW > > IPv6 routing is based on prefixes of any valid length up to 128 > [BCP198]. > > For example, [RFC6164] standardises 127 bit prefixes on point-to-poi= nt > > links. However, consistent use of Stateless Address Autoconfiguratio= n > > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > > length > > of Interface ID. To guarantee interoperability of SLAAC, a fixed len= gth > of > > Interface ID is necessary. For all currently allocated unicast > addresses, > > except those that start with the binary value 000, Interface IDs are > > required to be 64 bits long. Background on the 64 bit boundary in I= Pv6 > > addresses can be found in [RFC7421]. >=20 > Just some minor edits, to tie together the ideas. >=20 > NEW > IPv6 routing is based on prefixes of any valid length up to 128 [BCP19= 8]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires all interfaces on a link to use the same len= gth > of Interface ID. Furthermore, to guarantee robust interoperability of > SLAAC, > a standard, fixed length of Interface ID is necessary. For this reason= , > the > Interface ID of all currently allocated unicast addresses, except thos= e > that > start with the binary value 000, are required to be 64 bits long. > Background on the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. >=20 > I don't think that SLAAC *must* require a single standard IID length, so > that's why I added the word "robust." Now that we have moved away from us= ing > the MAC address for SLAAC, it's not clear to me why a host cannot wait fo= r a > RA, and then decide on how many IID bits to use, based on the prefix > length(s) advertised by the router. >=20 > Bert >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jan 18 19:01: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 8703E12940F for ; Wed, 18 Jan 2017 19:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 cYS8v9h2X9O4 for ; Wed, 18 Jan 2017 19:01:15 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A128F1294C1 for ; Wed, 18 Jan 2017 19:01:15 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id r136so21292271vke.1 for ; Wed, 18 Jan 2017 19:01:15 -0800 (PST) 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=AGL5f0oxvBegNVxz1Y+Sbiv38dzm2uLHHMIxyr8zH0A=; b=ELf8qzNKLQBjtDVQiV9WAYkP9HjObxyw1qEJsq3KCp9643xryYtIvUTwqWleVpVdZN f8wUPDoSVBKdBH9oqU1+VyTvh8CaWvLdIcnw3/UB1ggayXHUiAH6n5NG7cDmHXsD7SDX tgF3ppJSx7V6kiH5s3M4IA0prydkEgiTUyuAD5cdLs884+2d8v8Ni5nrrmOU/30mxj0m Rx0BtJaXx5PLIMbmnoHNyjUF8ePwtWZ5UhKfdz4hJut9de1zmL9J4hIZ5Kejpz3q3JEg UZe5jMX8H0plvydaANM2o/SL4fUtQuB86GArePx32X5Vt6tb12abxOq6HIFSLlLUbMm+ 03ng== 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=AGL5f0oxvBegNVxz1Y+Sbiv38dzm2uLHHMIxyr8zH0A=; b=cDchtIUXXwFwso9YvXUfci1oTclmZ6/D1mNllQ3Grnw3OsQZEi/SkA3WMREjCl3Rkl 0827jlHxcTp7EIpu0QrAglloCjFC0gy+GTk4jz0Rh/KBLQVHQPgjTBcvX1+y9ewMM+9Z HRSZ+sgogNWtsXbvL+jx5DVq+qF2x32UEJonBVzaFC+d452qeKM3eUT0c6dEj8cbfTL4 c/QqSs18dERdx6Kh5OfoD0k5Fv6wKMd0DHRsKobecZU2tvgVA5/6wsPHwW4roRzOpOG6 xxTJZD/Qqqa7yElRk7ZHriSlcvDibtswEiHCGzgebKhhVN1mVC0f2tf8fYmAyrnBpLzt paWg== X-Gm-Message-State: AIkVDXKRib425XGhwGNKEUhZlT8bMf/WzZ3eIm6JMEKirJtdvJqqCq9P5r9QalWRtNXmciLJ3VpYev1IhieOrl3Y X-Received: by 10.31.192.204 with SMTP id q195mr3192265vkf.155.1484794874608; Wed, 18 Jan 2017 19:01:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 19:00:54 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 12:00:54 +0900 Message-ID: Subject: Re: Updated IID length text To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114388cc11132c054669bf7e Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:01:17 -0000 --001a114388cc11132c054669bf7e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length > of Interface ID. To guarantee interoperability of SLAAC, a fixed length > of > Interface ID is necessary. I'm not a fan of this text, because it's a weak argument. A possible (uninformed) response to it might be "why do we need this SLAAC thing anyway? I want to use /120 prefixes and DHCPv6, just like I do in IPv4". And really, SLAAC is only one of the reasons why we have a 64-bit IID. There are lots of good arguments for this in RFC7421 - solid arguments, about address scarcity and future flexibility, and so on. We should let those provide the rationale since they can give a much more complete picture than we can in two lines here. Since you cite RFC7421 just a couple of lines down, I would just strike this text entirely, since it looks like the text is only there to justify the following normative text. I think I'm fine with the text that precedes it (" IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] ...)" and the text that follows it. --001a114388cc11132c054669bf7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter <<= a href=3D"mailto:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.car= penter@gmail.com> wrote:
However, consistent= use of Stateless Address Autoconfiguration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires that all interfaces on a link use th= e same length
=C2=A0 =C2=A0of Interface ID. To guarantee interoperability of SLAAC, a fix= ed length of
=C2=A0 =C2=A0Interface ID is necessary.

I&#= 39;m not a fan of this text, because it's a weak argument. A possible (= uninformed) response to it might be "why do we need this SLAAC thing a= nyway? I want to use /120 prefixes and DHCPv6, just like I do in IPv4"= . And really, SLAAC is only one of the reasons why we have a 64-bit IID. Th= ere are lots of good arguments for this in RFC7421 - solid arguments, about= address scarcity and future flexibility, and so on. We should let those pr= ovide the rationale since they can give a much more complete picture than w= e can in two lines here. Since you cite RFC7421 just a couple of lines down= ,=C2=A0I would just strike this text entirely, since it looks like the text= is only there to justify the following normative text.

I think I'm fine with the text that precedes it (" =C2=A0 IP= v6 routing is based on prefixes of any valid length up to 128 [BCP198]. For= example, [RFC6164] ...)" and the text that follows it.
--001a114388cc11132c054669bf7e-- From nobody Wed Jan 18 19:04: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 92D4D129435 for ; Wed, 18 Jan 2017 19:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 gWtpK6AQuDNs for ; Wed, 18 Jan 2017 19:04:31 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095C412940F for ; Wed, 18 Jan 2017 19:04:31 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id i68so24283582uad.0 for ; Wed, 18 Jan 2017 19:04:30 -0800 (PST) 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=YjaWkpRftf4uyfQ9ymlOe7N0HTYdnaB60Gn9HDncQrE=; b=jmL+MUqxyENKAN79nH+RVoPFlbk6p0MBC3EITeDUEMDqWEYa9rt322xrwBEA5uGjv3 5SCRCG4VueRUdFIvS0UDPqWrUugp4/UCHNGKeEZpvRFA1dM4VuaZ119WuBYE5T4AUJ8X axv1hAJZDEEdQyhRNRMg8BkwvJj8yqmwSEWkrYWq1j8KG5Z+xqqdwqSeNCZ+HIjgSOBx XZZMpsAUHethlWv6/Mg8v2ffo75avRYOfmbM3zHBaC2N4j8f9IBQni5cHetQb6y1Axzk TyJEPovENnePu+0LScvS0WhTpUlj8zenirzv3Z8vqnZ4SaVZBP3AzsVyW7Nci4lE1zVZ JWAA== 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=YjaWkpRftf4uyfQ9ymlOe7N0HTYdnaB60Gn9HDncQrE=; b=oHGc6cIY4NuB0t3GShmSojUacA1D6eWfR7jpW+UqK13smh26cX4T+vqb038rMtEHPD ejPW3OirzoNg9w0i22IXFKwGtHk18/M0TaCZCGZmVxzLSgfDtsfM6Jk+FiobhmkbSoer wEiyFOjI8QMzykvnpjT2mpMVTjnS9LV4pJBWd33xak63Qu2QfkVHv8nhDYG456InWS9F 4xtbkgQcUnWNeDF6TPCb5Mgi5iITQ4zLqGrPZ4scBnAvaCVonru7HNp8cZj1UcrLeJNT oGn2bM6p3JIpyrq5Yi/D+Ayp0+Tcx2K/rT6rM+PoyAU/jK8kC4DO9cvKVsVIjxl04HC+ 1y5A== X-Gm-Message-State: AIkVDXLmkRHdRMvb7knbIJNlJQk7zBux2jq5R20AiiD+T0bjSDlInHGyB+HEmC4DLJGJ/42ps9BEHCwkgq2UyH/n X-Received: by 10.176.65.101 with SMTP id j92mr3810734uad.57.1484795069992; Wed, 18 Jan 2017 19:04:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 19:04:09 -0800 (PST) In-Reply-To: <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 12:04:09 +0900 Message-ID: Subject: Re: Updated IID length text To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=94eb2c122f9eb66246054669ca82 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:04:32 -0000 --94eb2c122f9eb66246054669ca82 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 11:46 AM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > Now that we have moved away from using the MAC address for SLAAC, it's not > clear to me why a host cannot wait for a RA, and then decide on how many > IID bits to use, based on the prefix length(s) advertised by the router. > The reason it can't do that is that in practice SLAAC only works well if the probability of collision is negligible. Even reducing that from 64 bits to 48 bits impacts that substantially. --94eb2c122f9eb66246054669ca82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 11:46 AM, Manfredi, Albert E <albert.e.manf= redi@boeing.com> wrote:
Now= that we have moved away from using the MAC address for SLAAC, it's not= clear to me why a host cannot wait for a RA, and then decide on how many I= ID bits to use, based on the prefix length(s) advertised by the router.
=

The reason it can't do that is that in= practice SLAAC only works well if the probability of collision is negligib= le. Even reducing that from 64 bits to 48 bits impacts that substantially.<= br>
--94eb2c122f9eb66246054669ca82-- From nobody Wed Jan 18 19:23: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 873C112940F for ; Wed, 18 Jan 2017 19:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKx3lSwfibsI for ; Wed, 18 Jan 2017 19:23:56 -0800 (PST) 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 69496126579 for ; Wed, 18 Jan 2017 19:23:56 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id e4so9448506pfg.1 for ; Wed, 18 Jan 2017 19:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/kFcL+MoTQL9ep4tmcaZP2Et2Ffdoggyv3k1m3yXMag=; b=PjpkwNrFpgci5Xo7ucgRPsvkVH5vtek5bxYDBwSWBYHxZ7sSZJjUM6BOhnx4WYCcf0 ACfL1qn97PKPnLyU9fRR6ouyvTPHu6uGlFEN4Fhg4KEJVA683Z4cHG0lqbu5lDz8SLll 2q0Lzj/zLZczvCGmfEVBwxyyaE+pORukb9hUNyUqnW1LyErp+cxVx/J/hx6DW0K6L+Sz qvwW/hQ1kdNq8WZlvIZtLyfQgm2Fa7or1b9Kx+haRCf9v3OYJRNQvGhpj97OEIZkhfdl rQVHCzSjfSGLkYTGg4p/0A7MBcqecauCBhJaKOar7Ag2i4enyGIg7cQJvB3OzdCpiCYR Ko7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=/kFcL+MoTQL9ep4tmcaZP2Et2Ffdoggyv3k1m3yXMag=; b=gI5O8vCoL82jrkYm7yEd5DZzCjDudc2SSWJjUE5THOS2S9K+buS32M7FNk2T0c4bLW f5GEVvzncVakoDQQpFoEhuvZW5qcSViihWYteWFcUykMu5taWSpYo1ouwm5HX4rxDZap iloDywxTk2IiaYbUvbZwBxSsq4nuJ/7CWaWFq4unQhH59Bzt3g32AXxLafOVnJToTyZC 1BxUNE7xXi2JEYCtj9Wj4xLFtQe7t1UwkZBfRjAW+PdeDv1cWHtlufDuOGxMY5k9+38i xXXNSOLp2ONTpK5+FtJ+WE+LMmoN30PwaNT9tMrh2zsd+yO2Zk666UupkpnodXVFISkZ f0dQ== X-Gm-Message-State: AIkVDXJ+avzdHZRWKJek3K8aSVeRM9T+MDdCYp5zT5pMmgDu0j3qv1LoA/q46AatATMqvQ== X-Received: by 10.98.138.155 with SMTP id o27mr7470630pfk.113.1484796236039; Wed, 18 Jan 2017 19:23:56 -0800 (PST) Received: from [192.168.178.21] ([118.148.124.183]) by smtp.gmail.com with ESMTPSA id c11sm3944653pfk.14.2017.01.18.19.23.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 19:23:55 -0800 (PST) Subject: Re: Updated IID length text To: "Manfredi, Albert E" , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 19 Jan 2017 16:23:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:23:57 -0000 On 19/01/2017 15:55, Manfredi, Albert E wrote: ... >> I don't think that SLAAC *must* require a single standard IID length, so >> that's why I added the word "robust." Now that we have moved away from using >> the MAC address for SLAAC, it's not clear to me why a host cannot wait for a >> RA, and then decide on how many IID bits to use, based on the prefix >> length(s) advertised by the router. Not if you want to form a link-local address first. Which you always do, because perhaps there *is* no router when you come up after a power cut. (In the Anima WG, we are very interested in the behaviour of nodes that have absolutely no external information when they come up, because it's their job to bootstrap the network out of nowhere.) Brian From nobody Wed Jan 18 19:24: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 B4F43126579 for ; Wed, 18 Jan 2017 19:24:19 -0800 (PST) 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 KMFsIdJchMJF for ; Wed, 18 Jan 2017 19:24:18 -0800 (PST) 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 86F1912947F for ; Wed, 18 Jan 2017 19:24:18 -0800 (PST) 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 v0J3OI5i047163; Wed, 18 Jan 2017 20:24:18 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0J3OFt0047143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 20:24:15 -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.1178.4; Wed, 18 Jan 2017 19:24:14 -0800 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.1178.000; Wed, 18 Jan 2017 19:24:15 -0800 From: "Manfredi, Albert E" To: Lorenzo Colitti Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexT724zBn76p0KKsEzsg727/qE/EBsQgACTkID//320gA== Date: Thu, 19 Jan 2017 03:24:14 +0000 Message-ID: <2889c46061ab47cfba8b54384778bd85@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@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: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:24:19 -0000 RnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXSANCg0KPj4g Tm93IHRoYXQgd2UgaGF2ZSBtb3ZlZCBhd2F5IGZyb20gdXNpbmcgdGhlIE1BQyBhZGRyZXNzIGZv ciBTTEFBQywgaXQncw0KPj4gbm90IGNsZWFyIHRvIG1lIHdoeSBhIGhvc3QgY2Fubm90IHdhaXQg Zm9yIGEgUkEsIGFuZCB0aGVuIGRlY2lkZSBvbg0KPj4gaG93IG1hbnkgSUlEIGJpdHMgdG8gdXNl LCBiYXNlZCBvbiB0aGUgcHJlZml4IGxlbmd0aChzKSBhZHZlcnRpc2VkIGJ5DQo+PiB0aGUgcm91 dGVyLg0KPg0KPiBUaGUgcmVhc29uIGl0IGNhbid0IGRvIHRoYXQgaXMgdGhhdCBpbiBwcmFjdGlj ZSBTTEFBQyBvbmx5IHdvcmtzIHdlbGwNCj4gaWYgdGhlIHByb2JhYmlsaXR5IG9mIGNvbGxpc2lv biBpcyBuZWdsaWdpYmxlLiBFdmVuIHJlZHVjaW5nIHRoYXQgZnJvbQ0KPiA2NCBiaXRzIHRvIDQ4 IGJpdHMgaW1wYWN0cyB0aGF0IHN1YnN0YW50aWFsbHkuDQoNClBlcmhhcHMsIGJ1dCBTTEFBQyBo YXMgYmVlbiBkZWVtZWQgdG8gd29yayBhZGVxdWF0ZWx5IHdlbGwgd2l0aCBvbmx5IHRoZSA0OC1i aXQgTUFDIGFkZHJlc3MgKHByZXN1bWFibHkpIGJlaW5nIHVuaXF1ZS4gU28gbm90aGluZyB3b3Vs ZCBjaGFuZ2UgaW4gdGhpcyAibmVnbGlnaWJsZSBjb2xsaXNpb24iIHJlZ2FyZCwgaWYgd2UgYWxs b3dlZCBmb3IgODAtYml0IHByZWZpeGVzIHdpdGggU0xBQUMuIFlvdSdkIHdhbnQgdG8gZG8gZHVw bGljYXRlIGFkZHJlc3MgZGV0ZWN0aW9uIHJlZ2FyZGxlc3MuDQoNCkJhY2sgaW4gdGhlIDE5ODBz LCBpdCBwcm9iYWJseSBzZWVtZWQgdGhhdCAzMiBiaXRzLCB0byBpZGVudGlmeSByZXNlYXJjaCBj b21wdXRlcnMsIHdhcyB3YXkgbW9yZSB0aGFuIGFkZXF1YXRlLiBDbGVhcmx5LCBwZW9wbGUgaGFk IG5vdCBhbnRpY2lwYXRlZCBob3cgdGhpcyBJbnRlcm5ldCB3YXMgZ29pbmcgdG8gYmUgdXNlZC4g U2FtZSBhcHBsaWVzIG5vdy4NCg0KQmVydA0KDQo= From nobody Wed Jan 18 19:30: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 46C151294AE for ; Wed, 18 Jan 2017 19:30:31 -0800 (PST) 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 jy8iZdhRHulY for ; Wed, 18 Jan 2017 19:30:30 -0800 (PST) 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 644BD1294C3 for ; Wed, 18 Jan 2017 19:30:30 -0800 (PST) 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 v0J3UUqT053909; Wed, 18 Jan 2017 20:30:30 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0J3URu7053891 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2017 20:30:27 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (137.136.239.220) by XCH15-06-12.nw.nos.boeing.com (137.136.239.221) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Jan 2017 19:30:26 -0800 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.1178.000; Wed, 18 Jan 2017 19:30:27 -0800 From: "Manfredi, Albert E" To: Brian E Carpenter , 6man Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexT724zBn76p0KKsEzsg727/qE/EBsQgAAKfeCAAI6ZgP//evLg Date: Thu, 19 Jan 2017 03:30:27 +0000 Message-ID: <663e5d5032a94f18b91b6a1dedcb8da7@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:30:31 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21h aWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQogDQo+IE9uIDE5LzAxLzIwMTcgMTU6 NTUsIE1hbmZyZWRpLCBBbGJlcnQgRSB3cm90ZToNCj4gLi4uDQo+ID4+IEkgZG9uJ3QgdGhpbmsg dGhhdCBTTEFBQyAqbXVzdCogcmVxdWlyZSBhIHNpbmdsZSBzdGFuZGFyZCBJSUQgbGVuZ3RoLCBz bw0KPiA+PiB0aGF0J3Mgd2h5IEkgYWRkZWQgdGhlIHdvcmQgInJvYnVzdC4iIE5vdyB0aGF0IHdl IGhhdmUgbW92ZWQgYXdheSBmcm9tDQo+IHVzaW5nDQo+ID4+IHRoZSBNQUMgYWRkcmVzcyBmb3Ig U0xBQUMsIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoeSBhIGhvc3QgY2Fubm90IHdhaXQgZm9yDQo+ IGENCj4gPj4gUkEsIGFuZCB0aGVuIGRlY2lkZSBvbiBob3cgbWFueSBJSUQgYml0cyB0byB1c2Us IGJhc2VkIG9uIHRoZSBwcmVmaXgNCj4gPj4gbGVuZ3RoKHMpIGFkdmVydGlzZWQgYnkgdGhlIHJv dXRlci4NCj4gDQo+IE5vdCBpZiB5b3Ugd2FudCB0byBmb3JtIGEgbGluay1sb2NhbCBhZGRyZXNz IGZpcnN0LiBXaGljaCB5b3UgYWx3YXlzIGRvLA0KPiBiZWNhdXNlIHBlcmhhcHMgdGhlcmUgKmlz KiBubyByb3V0ZXIgd2hlbiB5b3UgY29tZSB1cCBhZnRlciBhIHBvd2VyIGN1dC4NCj4gKEluIHRo ZSBBbmltYSBXRywgd2UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiB0aGUgYmVoYXZpb3VyIG9mIG5v ZGVzDQo+IHRoYXQgaGF2ZSBhYnNvbHV0ZWx5IG5vIGV4dGVybmFsIGluZm9ybWF0aW9uIHdoZW4g dGhleSBjb21lIHVwLCBiZWNhdXNlDQo+IGl0J3MgdGhlaXIgam9iIHRvIGJvb3RzdHJhcCB0aGUg bmV0d29yayBvdXQgb2Ygbm93aGVyZS4pDQoNClJpZ2h0LCBidXQgeW91IGNhbiBkaWZmZXJlbnRp YXRlIHRoYXQgbGluayBsb2NhbCBhZGRyZXNzIGZyb20gZ2xvYmFsIGFkZHJlc3Nlcywgc28geW91 IGNhbiByZXF1aXJlIGl0IHRvIGhhdmUgNjQtYml0IElJRHMuIEl0J3MgZm9yIHRoZSBnbG9iYWwg YWRkcmVzc2VzIHRoYXQgSSB0aGluayB3ZSBkb24ndCB3YW50IHRvIHJlcGVhdCB0aGUgQ0lEUiBs ZXNzb25zIG9mIHRoZSBwYXN0LiBEaXR0byBmb3IgVUxBcywgZm9yIGV4YW1wbGUuDQoNCkJlcnQN Cg0K From nobody Wed Jan 18 19:52: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 B807212949F for ; Wed, 18 Jan 2017 19:52:20 -0800 (PST) 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 G5GG8LjMtnta for ; Wed, 18 Jan 2017 19:52:18 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8640C127071 for ; Wed, 18 Jan 2017 19:52:18 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9368982A2E; Thu, 19 Jan 2017 04:52:14 +0100 (CET) Subject: Re: Updated IID length text To: Lorenzo Colitti , "Manfredi, Albert E" References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> Date: Thu, 19 Jan 2017 00:51:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 03:52:21 -0000 On 01/19/2017 12:04 AM, Lorenzo Colitti wrote: > On Thu, Jan 19, 2017 at 11:46 AM, Manfredi, Albert E > > wrote: > > Now that we have moved away from using the MAC address for SLAAC, > it's not clear to me why a host cannot wait for a RA, and then > decide on how many IID bits to use, based on the prefix length(s) > advertised by the router. > > > The reason it can't do that is that in practice SLAAC only works well if > the probability of collision is negligible. Even reducing that from 64 > bits to 48 bits impacts that substantially. Oh, I love this. So you are a fan of still doing modified EUI-64 with randomized MAC addresses (which wastes 18 bits, including the 16 bits that are wasted with embedding 0xfffe), and now you say that using /48 would impact things substantially? This can't possibly make sense. If you do /48 + RFC7217, you get even two ore bits of entropy than if you do Modified EUI-64 with random MAC addresses (a flowed scheme that you've been fighting for for a while now) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 18 20:08: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 471C612948C for ; Wed, 18 Jan 2017 20:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 phtm8Rjw5jQf for ; Wed, 18 Jan 2017 20:08:12 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 E5632127071 for ; Wed, 18 Jan 2017 20:08:11 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x75so21912981vke.2 for ; Wed, 18 Jan 2017 20:08:11 -0800 (PST) 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=69dAgAFalvaplD90WG58Mgpp+OUSUo7y3xqfPWXkFws=; b=CFRwZZPHRU7FzRW36jNcexIzHN3fKL32z5ffSMWqLPoRvPbcd+NNIjeneklby5cH4Y jH+zMFTAX/nzuFu7bsuIa1nL3Uqonl6L73RYI6BIiJH2czCDL64lKBTDiPAshCIrw1OI aNNv9jDcfRB+2oCXIpN6UNaGk9eW8zSe6lm55ZtWN/0Rx1aXJ0StxF6/1b1T/V0beLvo duIPtPPgv+JYZPQSbUDqX4easAq0Ifz85emHYktGsHBSaz9lpG3rWOnNpuuZziIj18i3 G0oDScrGkAKtKQx1/weOt7LfCIgQ9Y45P7nteKc/JZDGG3jUxAknXw+V19XetkMJmKni rGzQ== 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=69dAgAFalvaplD90WG58Mgpp+OUSUo7y3xqfPWXkFws=; b=E0vmDz1Iz7TP0A/Y36v9sRvjzWUPbst//9HRoq5jEEx6Zr1TubqG7b6IyYkVy7+sip zEEXFGR5eWaIVhley/qgoT83SswVsJWtyF9QrwKkZIKXgKchi1yuEmlqV0cGSGlyGwG7 T+SJXwUDxb8sxS2X3OmVAgbNfwlyHglME9yGAnKqpRsnjDgwi6P9pUYfnKKLGZvXJP6r feLDRTj88euos5sESG7OF8MGWDDpiG5yXhNcxGglGAFMpjREPnTZSSWJGSic08CNeEid q96G1oduSGUnfTUiYoK+SKEYFm4JK0uWdgEwXfr6SwdTVKp+uwSw1oV02o29dg3LxokM 1iCg== X-Gm-Message-State: AIkVDXJ8u+16YErMXbe+qr+LrYokufnqgnY7mWos9OcXcVkyM0sGNfSwU6xUQ5aMSfy2YtAYk1iHjxyMRnw5SBO7 X-Received: by 10.31.88.1 with SMTP id m1mr3403283vkb.83.1484798890783; Wed, 18 Jan 2017 20:08:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 20:07:50 -0800 (PST) In-Reply-To: <2889c46061ab47cfba8b54384778bd85@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <2889c46061ab47cfba8b54384778bd85@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 13:07:50 +0900 Message-ID: Subject: Re: Updated IID length text To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=001a114e53647300df05466aaeb5 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:08:13 -0000 --001a114e53647300df05466aaeb5 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 12:24 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > > The reason it can't do that is that in practice SLAAC only works well > > if the probability of collision is negligible. Even reducing that from > > 64 bits to 48 bits impacts that substantially. > > Perhaps, but SLAAC has been deemed to work adequately well with only the > 48-bit MAC address (presumably) being unique. So nothing would change in > this "negligible collision" regard, if we allowed for 80-bit prefixes with > SLAAC. You'd want to do duplicate address detection regardless. > No, the situation with MAC addresses is different because they are intended to be unique. --001a114e53647300df05466aaeb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 12:24 PM, Manfredi, Albert E <albert.e.manf= redi@boeing.com> wrote:
> The reason it can't do that is that in practice SLAA= C only works well
> if the probability of collision is negligible. Even reducing that from=
> 64 bits to 48 bits impacts that substantially.

Perhaps, but SLAAC has been deemed to work adequately well with only= the 48-bit MAC address (presumably) being unique. So nothing would change = in this "negligible collision" regard, if we allowed for 80-bit p= refixes with SLAAC. You'd want to do duplicate address detection regard= less.

No, the situation with MAC addres= ses is different because they are intended to be unique.
<= /div> --001a114e53647300df05466aaeb5-- From nobody Wed Jan 18 20:13:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7751295ED for ; Wed, 18 Jan 2017 20:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 yv82RtTxKVuR for ; Wed, 18 Jan 2017 20:12:57 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 AC86E1295F0 for ; Wed, 18 Jan 2017 20:12:57 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 96so24990244uaq.3 for ; Wed, 18 Jan 2017 20:12:57 -0800 (PST) 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=lJya4ghOTHCjza3b4TXE+3rq/2NE+mXe5rNuFDxQ9HQ=; b=BW23PzQJdoD69bpF4xVf9h+RSPjWWhYQRIAWpRGB77aPXzLWzY9CbFe2H+vma6QkNo ajtOzGnHKY2QUEwtmr5rdy5OW8Ti9gDuR719hkPLBLWiBB5eZoWzdb2GM728oyE/ZT0G AQAKS+xHYJsofa4C0cDA5GzD1UPTqwRq/4Ep8zEW1pF4x3y4qfy8WbVIH/8zMBCAT270 YAMFMDvxN+Wu8cYt8yRt+CI8h8rTBY67hQyshg6iphx61AtOrIvKYR9iwRVrNWs1GPiW mD4LHwzrhIylXv8+8ALMS4VT7IykalHgkh0Dfnyl6fnKgp1fFEQyxGLeKTw+Gx8wbah6 689A== 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=lJya4ghOTHCjza3b4TXE+3rq/2NE+mXe5rNuFDxQ9HQ=; b=Q5zmicm6GEXs7SEygxdjftRczIyhddoAk+kVAu7fR//00dBv3ZCwTD22u5jWTQ/RzD uNorQV1Eje49PvgVnWvwOZgNls4zDYgtYs+LtGjcu9lARIf9NdA/DSud+8w2/5OsD0VE P+To6ILDLjFW91t3pFggz0Pah8iToG5lZXmDWUN1ScqW//1INH4kEKAs/uyfgoUBUfLN w3xlkO8u1fZkl3K8YioCaz/7yDsvgzZk2ZeaOH8ltj+DUIKZe7Gu9P9KeYvKhNSEFVP4 A1wT15Rh74o40dE4EQhUKVFpkqshNZRtLUrwFt1KBBOjVhzELJk4Mmi9CTZWCPsd8Aww Cz0Q== X-Gm-Message-State: AIkVDXKswjaU4awd2lHkgARjurjp+x47qJPaOnvZEJeXf3NXUh0TznwQI1YC0nlsRMy7K6veHUh3AxMFXpex+EuP X-Received: by 10.159.36.73 with SMTP id 67mr3913010uaq.124.1484799176597; Wed, 18 Jan 2017 20:12:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 20:12:36 -0800 (PST) In-Reply-To: <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 13:12:36 +0900 Message-ID: Subject: Re: Updated IID length text To: Fernando Gont Content-Type: multipart/alternative; boundary=001a113e1c9c7c3f2a05466abf3d Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:13:00 -0000 --001a113e1c9c7c3f2a05466abf3d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 12:51 PM, Fernando Gont wrote: > Oh, I love this. So you are a fan of still doing modified EUI-64 with > randomized MAC addresses (which wastes 18 bits, including the 16 bits > that are wasted with embedding 0xfffe), and now you say that using /48 > would impact things substantially? > > This can't possibly make sense. It does make sense. /48 does impact things substantially. However, on like like wifi, the MAC address is the endpoint identifier, so if there's a duplicate MAC you can't get on the network. --001a113e1c9c7c3f2a05466abf3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113e1c9c7c3f2a05466abf3d-- From nobody Wed Jan 18 20:20:27 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A512948C for ; Wed, 18 Jan 2017 20:20:26 -0800 (PST) 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 nLYZDa0_NooZ for ; Wed, 18 Jan 2017 20:20:25 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCEF129438 for ; Wed, 18 Jan 2017 20:20:25 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7FEFA82AC1; Thu, 19 Jan 2017 05:20:22 +0100 (CET) Subject: Re: Updated IID length text To: Brian E Carpenter , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 19 Jan 2017 01:03:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:20:26 -0000 Hi, Brian, On 01/18/2017 09:37 PM, Brian E Carpenter wrote: > OK, after all that discussion, here is a revised proposal. There is > nothing new here at all, IMHO; just clarification: > > OLD > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > > NEW > IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same length > of Interface ID. To guarantee interoperability of SLAAC, a fixed length of > Interface ID is necessary. s/fixed/consistent/. Thanks for your energy in this, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 18 20:20: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 9599B1295F6 for ; Wed, 18 Jan 2017 20:20:35 -0800 (PST) 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 X9-RxNTMxqGL for ; Wed, 18 Jan 2017 20:20:31 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043EB1295F7 for ; Wed, 18 Jan 2017 20:20:31 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1C1EA82ABF; Thu, 19 Jan 2017 05:20:27 +0100 (CET) Subject: Re: Updated IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 19 Jan 2017 01:20:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:20:35 -0000 On 01/19/2017 01:12 AM, Lorenzo Colitti wrote: > On Thu, Jan 19, 2017 at 12:51 PM, Fernando Gont > wrote: > > Oh, I love this. So you are a fan of still doing modified EUI-64 with > randomized MAC addresses (which wastes 18 bits, including the 16 bits > that are wasted with embedding 0xfffe), and now you say that using /48 > would impact things substantially? > > This can't possibly make sense. > > > It does make sense. /48 does impact things substantially. However, on > like like wifi, the MAC address is the endpoint identifier, so if > there's a duplicate MAC you can't get on the network. Could you please explain how you do the math such that in these two scenarios: #1: SLAAC with 48-bit IIDs, where the IID is a random string of bits (e.g. as resulting from RFC7217) #2: Traditional SLAAC with 64-bit IIDs, where the IID is generated from a randomized MAC address (and in which, based on how MOdified EUI64 IIDs are generated, you have to embed the fixed 16-bit word 0xfffe in the IID) ..you get a reduced IID collision rate with #2? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 18 20:26: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 8332A1295ED for ; Wed, 18 Jan 2017 20:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 z_nyn1SozKVC for ; Wed, 18 Jan 2017 20:26:01 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4415312948C for ; Wed, 18 Jan 2017 20:26:01 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id t8so22078779vke.3 for ; Wed, 18 Jan 2017 20:26:01 -0800 (PST) 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=JXe9Wqrc856X2zLVqRVeVLrWDUntAwGM2LLG+yGDr4U=; b=kyRmOC/smeqziGVHH9eAefxDEXIDDYzKfQaXh2uX5xzQW3WxC1YIMfjcwTJ00q+KZX KNfIY24Tha5BURvt4nhiNv7OSrJ65LFxPnKQFqpKrfLVHxQHbnxvvUH9B212AbGQA1v8 FpQFywa2xEX6OkaR4gVY0DFKwUcykASMYSLnLRrQc8o3I2jpA1OeM1YJcjziibFjcm3u S7c+kSJYl3WjbMEO21GCA+5wvSxfuIpA+tdYLlxuxG5lDg6Rj++cGzWRb95Xlzj98ASZ sWmfSgX6kaIxuRXM2agiekUE28pjwNqc4OODp3rh8YYLvPEZJkJZ00mdAOMdCoXsM9vP Iw1A== 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=JXe9Wqrc856X2zLVqRVeVLrWDUntAwGM2LLG+yGDr4U=; b=lDQr4TJDEIoM/1p9F8eP0sxvWwNvKsERuQbNeqSmSi6qJ5j7UJhCMO7bBmj33vC3Bk VmdY5lalaRjUpAdhpK/UNwfvOcHPDqyFoj/tcBnTzczty73sOhBy2+lgxzRJ/tF5ZOZc nW0jd5JnIXP0ByiRljC4+jZZRuOzsu0Zth9sZpgm1Y0JUklYC1JnRZeM5RS7p8FqWnk8 9hJwOiBC4ybttf2+dfgJ16m8BaHB1sjmR5TxTY701qRxv2ryXqyoEza3OmAv+VwpIOX3 dEzNM26nnncVe7nRw9FtfueJlh1jNGPsDxpe7E/uZ1ZWbABImOaGQLMdyhn4DMd30805 tx7Q== X-Gm-Message-State: AIkVDXKBVkXOqTIeRHxmXeSxvgtKqxkJTFc9AXYN6TqoD05AyuVGjVNAUZhFc7si3d5UDnfOwn9EIMiYAD76O9Mr X-Received: by 10.31.192.204 with SMTP id q195mr3306446vkf.155.1484799960269; Wed, 18 Jan 2017 20:26:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 20:25:39 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 13:25:39 +0900 Message-ID: Subject: Re: Updated IID length text To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114388cc3213bf05466aee2a Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 04:26:02 -0000 --001a114388cc3213bf05466aee2a Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 1:20 PM, Fernando Gont wrote: > > It does make sense. /48 does impact things substantially. However, on > > like like wifi, the MAC address is the endpoint identifier, so if > > there's a duplicate MAC you can't get on the network. > > Could you please explain how you do the math such that in these two > scenarios: > > #1: SLAAC with 48-bit IIDs, where the IID is a random string of bits > (e.g. as resulting from RFC7217) > > #2: Traditional SLAAC with 64-bit IIDs, where the IID is generated from > a randomized MAC address (and in which, based on how MOdified EUI64 > IIDs are generated, you have to embed the fixed 16-bit word 0xfffe > in the IID) > You forgot the "where layer 2 ensures that there are no duplicate MAC addresses on the network" part of this scenario. --001a114388cc3213bf05466aee2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 1:20 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> I= t does make sense. /48 does impact things substantially. However, on
> like like wifi, the MAC address is the endpoint identifier, so if
> there's a duplicate MAC you can't get on the network.

Could you please explain how you do the math such that in these two<= br> scenarios:

#1: SLAAC with 48-bit IIDs, where the IID is a random string of bits
=C2=A0 =C2=A0 (e.g. as resulting from RFC7217)

#2: Traditional SLAAC with 64-bit IIDs, where the IID is generated from
=C2=A0 =C2=A0 a randomized MAC address (and in which, based on how MOdified= EUI64
=C2=A0 =C2=A0 IIDs are generated, you have to embed the fixed 16-bit word 0= xfffe
=C2=A0 =C2=A0 in the IID)

You forgot th= e "where layer 2 ensures that there are no duplicate MAC addresses on = the network" part of this scenario.
--001a114388cc3213bf05466aee2a-- From nobody Wed Jan 18 22:01: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 9A21B1294B7 for ; Wed, 18 Jan 2017 22:01:18 -0800 (PST) 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 V676eCZIKqEc for ; Wed, 18 Jan 2017 22:01:16 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A5B12940E for ; Wed, 18 Jan 2017 22:01:16 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AB3FC8286F; Thu, 19 Jan 2017 07:01:11 +0100 (CET) Subject: Re: Updated IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <8a6ba2e9-ef5b-87d0-d60b-dcc4916a2300@si6networks.com> Date: Thu, 19 Jan 2017 02:38:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 06:01:18 -0000 On 01/19/2017 01:25 AM, Lorenzo Colitti wrote: > On Thu, Jan 19, 2017 at 1:20 PM, Fernando Gont > wrote: > > > It does make sense. /48 does impact things substantially. However, on > > like like wifi, the MAC address is the endpoint identifier, so if > > there's a duplicate MAC you can't get on the network. > > Could you please explain how you do the math such that in these two > scenarios: > > #1: SLAAC with 48-bit IIDs, where the IID is a random string of bits > (e.g. as resulting from RFC7217) > > #2: Traditional SLAAC with 64-bit IIDs, where the IID is generated from > a randomized MAC address (and in which, based on how MOdified EUI64 > IIDs are generated, you have to embed the fixed 16-bit word 0xfffe > in the IID) > > You forgot the "where layer 2 ensures that there are no duplicate MAC > addresses on the network" part of this scenario. 1) AP != Network -- you might be assuming the network is simpler than it really is 2) How many nodes do you need in a 48-bit space for the probability of collisions to become a concern? 3) If you are concerned about collisions in 48 bits as a result of random numbers, I'm curious why layer-3 concerns you more -- particularly when, in layer-3 you do have a mechanism for detecting them, and one for recovering from them (whereas in layer-2, you don't). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 18 22:01: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 6E7C51295F1 for ; Wed, 18 Jan 2017 22:01:23 -0800 (PST) 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 SM63eXb3f1dD for ; Wed, 18 Jan 2017 22:01:21 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6B21294F7 for ; Wed, 18 Jan 2017 22:01:21 -0800 (PST) Received: from [192.168.3.101] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6E4F48284B; Thu, 19 Jan 2017 07:01:18 +0100 (CET) Subject: Re: Updated IID length text To: Lorenzo Colitti , Brian E Carpenter References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <6b090093-9a7b-9269-0730-78dd5c5be5e2@si6networks.com> Date: Thu, 19 Jan 2017 02:48:37 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 06:01:23 -0000 On 01/19/2017 12:00 AM, Lorenzo Colitti wrote: > On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter > > wrote: > > However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the > same length > of Interface ID. To guarantee interoperability of SLAAC, a fixed > length of > Interface ID is necessary. > > > I'm not a fan of this text, because it's a weak argument. A possible > (uninformed) response to it might be "why do we need this SLAAC thing > anyway? I want to use /120 prefixes and DHCPv6, just like I do in IPv4". > And really, SLAAC is only one of the reasons why we have a 64-bit IID. Please enlighten me. The 64-bit length has to do with SLAAC, and the fact that the IID had to be able to embed 64-bit link-layer addresses. If you were to start with a clean slate, you wouldn't embed link-layer addresses in the layer-3 address, and hence wouldn't need to do fixed-length 64-bit IIDs. With manual configuration or DHCPv6, you would support "any size that can fit all your systems and allow your network to grow". And with SLAAC (+ something like RFC7217), it would be the same, with the contraint that "the size results in low host density, so that IID collisions are not a concern". > There are lots of good arguments for this in RFC7421 - solid arguments, > about address scarcity and future flexibility, and so on. That translates well into "well... we have so many bits that... let's burn them in any possible way" (fwiw, I don't think that's the argument being made in RFC7421, though) An artifact of history need not and does not automagically become a design principle. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 18 22:21:35 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF712949A for ; Wed, 18 Jan 2017 22:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 NkBDKZ0TX2gs for ; Wed, 18 Jan 2017 22:21:32 -0800 (PST) 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 245E11200A0 for ; Wed, 18 Jan 2017 22:21:32 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id r136so23328575vke.1 for ; Wed, 18 Jan 2017 22:21:32 -0800 (PST) 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=FHTKneAw7TP48e8zg0N8BVrPQlNWk/+SJoozno9wmq0=; b=exBguq8S3Xnjss6XdgJb99unwcWhBPYy9+rnF4Jaj8WHkfgBL0PuJWZ0N15+RkS+hj xUpHBmgQS5TKwsfWB45zzQBiSXpvuwOgXYRNfaXcu2esE+1H7yNIueJscGJinKXy97Af oiED/IhggGK4h8/rXhDPD0f96IvV80D2n1FLD9xPuJE7cfl/KKAG2AO3sknJaSqCM+Xq x4t2YAaiYRyYfTPsUL4X/COB2eYaMWzCikz8M03yuBVvIF09Eh6//Gr1OOrGWojXpjI2 X7chLiUGXxIyLdZPuFF1p0crUA7VMcHi4BorBe01VEQhTktK2nTsJaHfH4GUdAPG+pE7 O11g== 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=FHTKneAw7TP48e8zg0N8BVrPQlNWk/+SJoozno9wmq0=; b=OMiarZpGf7bhUi4g/mH476hghQgXi2AxYC2rUiAtexjIhGiVgNy+z3a13pTURNdoPQ F865ff8f0TXUt8DrieKRsDjI4prpGt2EanZkoh7/jMtuk+ZI01ixU+ADyosrjto4/4fZ MnIWVEPahzQLi2P1Nbm9LFEU72izIkN7G8k/iaiD7BIRBmLK9NiSOAjgzBSAUk6MKiwh FQWwKUoTmLrvhMrgyZA9vxB7zuELBTOD0pZOww03+Bs3oHu+18t6VB6WvvoQBeGSk0o0 P8yf3cCXcUehkdCiTk4Qb2bhFXC5VQnLDCWM6rVxk1UKRfmwJ+1wXqyrKBimBwury9bk vOTw== X-Gm-Message-State: AIkVDXKkTr8t7A458I0BNGhaLmtp7p3EdtjU9iV7kFNM8+UYGZvDEalmpeDeEbsZ9oeMS2ygQOrAjWxQBBALZvW/ X-Received: by 10.31.150.134 with SMTP id y128mr3098683vkd.102.1484806891013; Wed, 18 Jan 2017 22:21:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Wed, 18 Jan 2017 22:21:10 -0800 (PST) In-Reply-To: <8a6ba2e9-ef5b-87d0-d60b-dcc4916a2300@si6networks.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <6b718d09-4a91-8128-0559-d072e1e1d832@si6networks.com> <8a6ba2e9-ef5b-87d0-d60b-dcc4916a2300@si6networks.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 15:21:10 +0900 Message-ID: Subject: Re: Updated IID length text To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1141d6004cf50705466c8b5f Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 06:21:33 -0000 --001a1141d6004cf50705466c8b5f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 2:38 PM, Fernando Gont wrote: > > You forgot the "where layer 2 ensures that there are no duplicate MAC > > addresses on the network" part of this scenario. > > 1) AP != Network -- you might be assuming the network is simpler than it > really is > In small networks, the probability of collision is low because there are few devices. Large networks are usually built with a centralized control plane, because otherwise roaming doesn't work, and in that sort of network, MAC addresses have to be unique or devices don't get on the network. > 2) How many nodes do you need in a 48-bit space for the probability of > collisions to become a concern? > I never said the probability is unacceptable with 48 bits. That depends a lot on the network circumstances. What I said that the increase in probability when going down from 64 bits to 48 bits, which it is. If you want 99.999% chance of no collisions, with 48 random bits I that puts you between 10k and 100k devices. With 64 bits that's more like 10^35 devices. That's an incredible difference. At 32 bits it's a joke - 1% chance of collision at 10k devices. > 3) If you are concerned about collisions in 48 bits as a result of > random numbers, I'm curious why layer-3 concerns you more -- > particularly when, in layer-3 you do have a mechanism for detecting > them, and one for recovering from them (whereas in layer-2, you don't). Sigh. Consider 802.11 wifi. Dynamic MAC addresses are desirable for privacy reasons. If there's a random MAC address collision, you don't get on the network (most of the time; as discussed above). At that point you either fail or you try again with a different random MAC address. That's your retry mechanism. Once you've cleared that retry mechanism, L2 guarantees that your EUI-64-based IPv6 address is unique. --001a1141d6004cf50705466c8b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 2:38 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
> You forgot the "where layer 2 ensures that the= re are no duplicate MAC
> addresses on the network" part of this scenario.

1) AP !=3D Network -- you might be assuming the network is simpler t= han it
really is

In small networks, the probab= ility of collision is low because there are few devices. Large networks are= usually built with a centralized control plane, because otherwise roaming = doesn't work, and in that sort of network, MAC addresses have to be uni= que or devices don't get on the network.
=C2=A0
2) How many nodes do you need in = a 48-bit space for the probability of
collisions to become a concern?

I never= said the probability is unacceptable with 48 bits. That depends a lot on t= he network circumstances. What I said that the increase in probability when= going down from 64 bits to 48 bits, which it is. If you want 99.999% chanc= e of no collisions, with 48 random bits I that puts you between 10k and 100= k devices. With 64 bits that's more like 10^35 devices. That's an i= ncredible difference. At 32 bits it's a joke - 1% chance of collision a= t 10k devices.
=C2=A0
3) If you are concerned about collisions in 48 bits as a result= of
random numbers, I'm curious why layer-3 concerns you more --
particularly when, in layer-3 you do have a mechanism for detecting
them, and one for recovering from them (whereas in layer-2, you don't).=

Sigh. Consider 802.11 wifi. Dynamic MAC ad= dresses are desirable for privacy reasons. If there's a random MAC addr= ess collision, you don't get on the network (most of the time; as discu= ssed above). At that point you either fail or you try again with a differen= t random MAC address. That's your retry mechanism. Once you've clea= red that retry mechanism, L2 guarantees that your EUI-64-based IPv6 address= is unique.
--001a1141d6004cf50705466c8b5f-- From nobody Thu Jan 19 01:26: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 7F73B129435 for ; Thu, 19 Jan 2017 01:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AskVVVyMlwYo for ; Thu, 19 Jan 2017 01:26:20 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14097129434 for ; Thu, 19 Jan 2017 01:26:20 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id h65so4561276lfi.3 for ; Thu, 19 Jan 2017 01:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=pbcH97dj0CTcUENZ0VOBEjW4WCJbV/edE0tnk51+g9Y=; b=vKmwW0RtMit7J4EedlFW9FPWZqmaOp1VBEEoDvJ113R1Ee2BJgjit/+7sJkq9GEjBq SWF/21C6ZEIUto2rEiFHQG7nPiicxsEhRMViM1Vgd9caTqEiAoON0lb44v7M9nI49Gaj VvcnJwdHx2hAsTFmwwcc2mRKbAeJK955C8vmZFGujiw9R6FDiiQoiJcdE4tI63ryiFG3 FSeAOtBOnRJgMG081mbM7Nw08+5F5a119/qq8ski+wQckna3fwb1jCOXtDwaJav3uWx+ lTFRRPBOPYvKjDrF3TsbDfL+ID4D9UTGo7Ziu516fAkoSizfcn3qOBNJEArQgPaud9LH zrog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pbcH97dj0CTcUENZ0VOBEjW4WCJbV/edE0tnk51+g9Y=; b=bz29bR+D0AgBsoYdDm9K/QJQ0Tui9JEiW25esJsiDF/oHcs0U6EclXdKlkHclpZuL0 p6KNpVqY8FHjbu/CjlLUbHinCMyEYoH8eiEJ9UOcUPa9sqjnOVcqSbks08QZeGuKx8Vm pzEJzi4QYDOjL8nz6tOVzahtss2a5UvSqryXB1fnn4BjjOYV/GyuFnBtBqE63FT0DQZ+ bSR8ou05NpvWfSpvo/WyMAH3V6FbcLAQO+yxtp50TMT2WffgBvFvEBIl25XCuzbN8V2p fHVGY4OzxuzvFsb8i8FzITYmgYXJep9E+C6a6Q2Gd0xJ/szQxDqQWyWkzWSKS5Y+MH4X eSoA== X-Gm-Message-State: AIkVDXLNyNyS/8oqSme0FYqyVMAppfiWnF78VL1ZWC0SjG0BDriOX8Jf+xtzWCLWv9N+Vg== X-Received: by 10.25.216.3 with SMTP id p3mr2626916lfg.16.1484817977707; Thu, 19 Jan 2017 01:26:17 -0800 (PST) Received: from [10.2.201.7] (edukc16.nat.wireless.lu.se. [130.235.136.16]) by smtp.gmail.com with ESMTPSA id 14sm1409586lju.16.2017.01.19.01.26.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 01:26:16 -0800 (PST) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu Subject: Re: Updated IID length text To: ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Message-ID: Date: Thu, 19 Jan 2017 10:26:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:26:21 -0000 Le 19/01/2017 04:00, Lorenzo Colitti a crit : > On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter > > > wrote: > > However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length of Interface ID. To guarantee interoperability of SLAAC, a > fixed length of Interface ID is necessary. > > > I'm not a fan of this text, because it's a weak argument. A possible > (uninformed) response to it might be "why do we need this SLAAC > thing anyway? I want to use /120 prefixes and DHCPv6, just like I do > in IPv4". And really, SLAAC is only one of the reasons why we have a > 64-bit IID. There are lots of good arguments for this in RFC7421 - > solid arguments, about address scarcity and future flexibility, and > so on. We should let those provide the rationale since they can give > a much more complete picture than we can in two lines here. Since > you cite RFC7421 just a couple of lines down, I would just strike > this text entirely, since it looks like the text is only there to > justify the following normative text. > > I think I'm fine with the text that precedes it (" IPv6 routing is > based on prefixes of any valid length up to 128 [BCP198]. For > example, [RFC6164] ...)" and the text that follows it. I am fine with that part too. I do not agree with the part that says "IIDs are required be 64bit long". If IIDs are required to be 64bit long (even if only in the 000-prefixed space) then the network can not grow at the edges, at least not with SLAAC. The network can not grow at the edges with SLAAC because the operators are already at this limit; they imagine no-one needs to grow beyond it. They also imagine that a 2^64 is enough for an end user, w/o understanding that /64 is but one subnet (because of SLAAC). We need the network to grow at the edge: cascading subnets at the edge. I could agree though the RFC2464-10MbitsEthernet be IID-len 64. Provided that document is used only on 10Mbps wired Ethernet only (not on WiFi, etc.) New documents for IPv6-over-WiFi, IPv6-over-100GBEthernet, could use other that 64bit IID lengths. Alex Alex > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jan 19 01:49: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 70676127ABE for ; Thu, 19 Jan 2017 01:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 PAtGcMxQMR5c for ; Thu, 19 Jan 2017 01:49:32 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20866120727 for ; Thu, 19 Jan 2017 01:49:32 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id k127so25868058vke.0 for ; Thu, 19 Jan 2017 01:49:32 -0800 (PST) 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=tcGqBKmqUg5PFola7LEwEJyGZ1On2gw8xFXItu/ig8s=; b=AiZOe4XPAe+m6t3aNbPuhIojgOxjbIPiVAvqgoPBQ2kG7meoIRkAK2sIMOcFQaIYcA 30Ya9oTrpgItxwqeBI19LHzVGVrq+s+anQRMt3qRveC3iCynX7cZL1c4BXxKBjm9Hx1t wZx0uHjZWYliBVPYxMxySaSXgF89L0bEkQ08/416Ye92kk0yS/FOxcvwOIDdsEFH3SvP ziUbCN9y+ewgAkR10B17y0DR7GlHO0hGU1W83MSEzLgGY2pHrNBgVkCglezaLII+hCbY tgKFcXHHNro8lvGeTX6UV1wLUhw9l/QEwSSGLeH1uLjj68+w++kUwiUKrYp91OSEp5TY QGYw== 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=tcGqBKmqUg5PFola7LEwEJyGZ1On2gw8xFXItu/ig8s=; b=mnIAatkKzBm5zQlyqrA+LBX4p8o6IyM7YAGk3bQc2sbK64muFDB1jvvrrhC/3lwrdF Tu9wO1Lt7uuItkrG/4t3YNe12CHKRhLPYOOReONBL16LbRoN364C2NTpui5ElKKubooo bEckdAcrWst4TrFv+/9y8S0zUPiAdfvtrK67nE0h8CCdOWcz/txK9Cs8KNkPfZac+TET /BM+DKHX+BwoupxVh8O2jSbZbfLPrSSRxakTo0faaBn8VH5AeFLrlu5w4Lz17VogiEPs YW5mui+i3GJOQuBJUppX9lNEdhIMbn9IylXu3+GWHJVWWWjmMMN3+BYlPi/3zoB3SPZy F1OA== X-Gm-Message-State: AIkVDXLRwHafeE60NKumGd9UKdXms5XeQxUQladYmMz9adx3sVTR8cnyGa8k0B79/8KU06Lvrl25aLw/9maucEGV X-Received: by 10.31.170.15 with SMTP id t15mr3299754vke.6.1484819371017; Thu, 19 Jan 2017 01:49:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 01:49:10 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Lorenzo Colitti Date: Thu, 19 Jan 2017 18:49:10 +0900 Message-ID: Subject: Re: Updated IID length text To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114322502b0fcd05466f736c Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:49:33 -0000 --001a114322502b0fcd05466f736c Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 6:26 PM, Alexandre Petrescu < alexandru.petrescu@gmail.com> wrote: > If IIDs are required to be 64bit long (even if only in the 000-prefixed > space) then the network can not grow at the edges, at least not with > SLAAC. > > The network can not grow at the edges with SLAAC because the operators > are already at this limit; they imagine no-one needs to grow beyond it. > They also imagine that a 2^64 is enough for an end user, w/o > understanding that /64 is but one subnet (because of SLAAC). > There are lots of things that you can do with one /64. For example, you can bridge at layer 2 and connect as many devices as you want. --001a114322502b0fcd05466f736c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 19, 2017 at 6:26 PM, Alexandre Petrescu <alexandru.petr= escu@gmail.com> wrote:
If I= IDs are required to be 64bit long (even if only in the 000-prefixed
space) then the network can not grow at the edges, at least not with
SLAAC.

The network can not grow at the edges with SLAAC because the operators
are already at this limit; they imagine no-one needs to grow beyond it.
=C2=A0They also imagine that a 2^64 is enough for an end user, w/o
understanding that /64 is but one subnet (because of SLAAC).

There are lots of things that you can do with one /64= . For example, you can bridge at layer 2 and connect as many devices as you= want.=C2=A0
--001a114322502b0fcd05466f736c-- From nobody Thu Jan 19 01:58: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 4310E127ABE for ; Thu, 19 Jan 2017 01:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjxGFsF-MLbY for ; Thu, 19 Jan 2017 01:58:33 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 6F1B1128B37 for ; Thu, 19 Jan 2017 01:58:33 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id n124so31933625lfd.2 for ; Thu, 19 Jan 2017 01:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=RVNA45Hj1kbX9w9vE4WxXQeFXuYO2n02hkXJyaNWQuM=; b=B9rIT278K5WRMjEFjZPMnUD6CbvDA9Ro2QoAAokh5VXKvOPvkUZPIiAwB6fX0El8nZ iN6MXEQK9mI/0HrfFPy2G3ZXwswgYShByHNw/QXakhpiElyQQrHKsiuPx3XOe2iuS/iZ 2UKrru0KV9vMh/stLeCMEqrTDtphU1pqs16DwQGElAQQlkP/Mu95nFLm8FOUNGRDyu7P YkzdP3VqJS2dE8YwzH5D9fEV8RoS6jjgX2YlAR7zbrlUTnu8kU5M/IszJKbCE4WYT8aM G9ZExeCoL22rVM0Qf1vgYpxwPC7NoYkCpTR0K7nONn2ayjadUalszBNhihFZI5/D+4P4 Hxaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RVNA45Hj1kbX9w9vE4WxXQeFXuYO2n02hkXJyaNWQuM=; b=owf7WDS/z839I+EIbad5xau+lNH4tW4PiVNp0jkFTwLIrJh8pxEJs9wJOefdRmX6BG diGPzwNBUG9Ex4CF2BMezld4+MvzsIhz0Z/Q9nLD1MxooT/H1Kycdcx9fg2IhDSKRd1X GsWORHyQecVupAr1WvLI+IwM6I5F7LvLd8k9HCGM6Jw/TGwY0ve82kRgc2XGJ4CdyXgT oXDGsvhJkEdRDjbX2BqWDk9lVgjf6wyjc75KbRCnAhhPsTn0wRt/tZCFi7d5a2/o2UYA Er6uc5t6b/jTvASEZFvIL6lgc/X9oYTzyHBrRc8IAspB4BrwMe3r9XbtFbn5/Tk4CZnK 7Xxw== X-Gm-Message-State: AIkVDXILb6jU4uqL0epaT6Sqj1u7qAqvzl5Qh0Xer0BEPISFXADptUNcI9z4zxmv2rdXMw== X-Received: by 10.25.169.67 with SMTP id s64mr2641696lfe.133.1484819911327; Thu, 19 Jan 2017 01:58:31 -0800 (PST) Received: from [10.2.201.7] (edukc16.nat.wireless.lu.se. [130.235.136.16]) by smtp.gmail.com with ESMTPSA id r127sm1497307lfr.3.2017.01.19.01.58.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 01:58:30 -0800 (PST) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu Subject: Re: Updated IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Message-ID: <00f4841b-5e76-a529-855a-9519c3527e71@gmail.com> Date: Thu, 19 Jan 2017 10:58:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 09:58:35 -0000 Le 19/01/2017 à 10:49, Lorenzo Colitti a écrit : > On Thu, Jan 19, 2017 at 6:26 PM, Alexandre Petrescu > > wrote: > > If IIDs are required to be 64bit long (even if only in the 000-prefixed > space) then the network can not grow at the edges, at least not with > SLAAC. > > The network can not grow at the edges with SLAAC because the operators > are already at this limit; they imagine no-one needs to grow beyond it. > They also imagine that a 2^64 is enough for an end user, w/o > understanding that /64 is but one subnet (because of SLAAC). > > > There are lots of things that you can do with one /64. For example, you > can bridge at layer 2 and connect as many devices as you want. Yes there are, and there are not: bridging only scales that much (maybe 1 or 2 PANs, but not to thousands of vehicles); bridging does not separate strongly enough between e.g. entertainment and safety. Alex From nobody Thu Jan 19 04:51:22 2017 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 548DF12007C; Thu, 19 Jan 2017 04:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" Subject: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 04:51:17 -0800 Archived-At: Cc: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, fgont@si6networks.com, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:51:17 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-6man-rdnss-rfc6106bis-15: 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-rdnss-rfc6106bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this is the first "configure my DNS" thing to come before the IESG since DPRIVE has gotten an output, so it seems fair to ask now: Why doesn't the DNS server information include a port now that we have both 53 and 853 as options? Without that, how is a host supposed to know which to use? Did the WG consider DPRIVE? If so, what was the conclusion? If not, what is the right thing to do? (Add the port no? Define a new DHCPv6 option for DNS/TLS? Something else?) From nobody Thu Jan 19 05:09:36 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 EA8B012007C; Thu, 19 Jan 2017 05:09:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" Subject: Benoit Claise's No Objection on draft-ietf-6man-rdnss-rfc6106bis-15: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483137495.10369.1985446039164787213.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 05:09:34 -0800 Archived-At: Cc: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, fgont@si6networks.com, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:09:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-6man-rdnss-rfc6106bis-15: 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-rdnss-rfc6106bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Good OPS-DIR review and nice to see that the new version already included all the changes. >From time to time, the AD live is easy :-) From nobody Thu Jan 19 05:43: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 1EB641295D0; Thu, 19 Jan 2017 05:43:19 -0800 (PST) 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 ooTcrK6Njikn; Thu, 19 Jan 2017 05:43:16 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F66129467; Thu, 19 Jan 2017 05:43:16 -0800 (PST) Received: from [192.168.3.102] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B26F582B0E; Thu, 19 Jan 2017 14:43:08 +0100 (CET) Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) To: Stephen Farrell , The IESG References: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> Date: Thu, 19 Jan 2017 10:36:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, bob.hinden@gmail.com, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:43:19 -0000 On 01/19/2017 09:51 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-6man-rdnss-rfc6106bis-15: 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-rdnss-rfc6106bis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I think this is the first "configure my DNS" thing to come > before the IESG since DPRIVE has gotten an output, so it seems > fair to ask now: > > Why doesn't the DNS server information include a port now that > we have both 53 and 853 as options? Without that, how is a > host supposed to know which to use? Did the WG consider > DPRIVE? If so, what was the conclusion? If not, what is the > right thing to do? (Add the port no? Define a new DHCPv6 option > for DNS/TLS? Something else?) FWIW, this is a revision of an existing standard, aimed at fixing known problems. Giving how critical it is to IPv6 deployment to convey DNS information, I'd personally expect that something like you suggest (which is sensible), would be done in a separate document -- e.g., in a brand-new option. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 19 06:14:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BB31295F1 for ; Thu, 19 Jan 2017 06:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSar9UNisIXq for ; Thu, 19 Jan 2017 06:14:07 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB011295F0 for ; Thu, 19 Jan 2017 06:14:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 330004B; Thu, 19 Jan 2017 15:14:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1484835242; bh=T9rS7DZ8ZfVeXHoscOS5/XuETRPc JNcP4EH29IofpyA=; b=A3JaGYAdRNXv4tFvQQhF6Qm2uoGM2eJEkOclgM5uBkCK NWT0BeisveLIQ/JALOYgJumLi0xC1pk53q/ghiyIpsDOZ/oH9H53Vozb7R1vM9Wu 15SfmtM8pvXDWCR/+ktdbdj2TW/ovICjw8VbZ8RNw6cgaRLfH4eZnZ3DRS2XzM8= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0t1kBcVuV0FV; Thu, 19 Jan 2017 15:14:02 +0100 (CET) Received: from [IPv6:2a02:a213:a300:9300:1cc7:83e8:5c1d:28b0] (unknown [IPv6:2a02:a213:a300:9300:1cc7:83e8:5c1d:28b0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 658144A; Thu, 19 Jan 2017 15:14:02 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C3E3EBBD-E445-45A3-A605-A24BFE72E974"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> Date: Thu, 19 Jan 2017 15:14:01 +0100 Message-Id: <4B3D8528-4F10-4E32-953E-F071EB6E7FB8@steffann.nl> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c 37ea8dc2c0d@gmail.com> <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:14:09 -0000 --Apple-Mail=_C3E3EBBD-E445-45A3-A605-A24BFE72E974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ole, > There are good technical arguments for why each host needs more than a = single address, and if we end up in a situation similar to IPv4 where = each address used has to be justified, then we have lost. There is a = justified fear that allowing the 64 bit boundary to slide, we will end = up in a situation similar to IPv4 addressing. E.g. charging per address. Well said, this is exactly the same feeling I have about the 64 bit = boundary. I don't think it's important what its exact history is, what = the relation to layer-2 addresses is, etc. What is important is that we = don't end up with situations where users and devices end up without = enough addresses despite the abundance that IPv6 provides. Cheers, Sander --Apple-Mail=_C3E3EBBD-E445-45A3-A605-A24BFE72E974 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYgMmpAAoJEKAtA7D+JBO5FpIH/2caVXZh3BFGXBaoSMAk5kL9 pEdEhzXzo9h0zfgP/vmC6ZoDOGvX1cPQxwu0X1+tH2aaQuz7J32y3pHmiXdP1S+0 vXn8NoltehXdjo5eMGEybD1Jd/HOASewXuEXeoZnYWk/nB+5KKtPRbpnMKCT7Pef WVaz9p5oAb6SFgLaYubOTACx3LBRGt4RiYWvlDj9SpeTC1I/sDa5Pi2wf2AmCE3X WUFUTHzrOI8e6NTcvsVDOq63IxQYx1CLnUnsIfh6yT7vJtHjaTzgCcMgtgiRyRJ1 aYbO6U9UPerbaWimoy2w0YnfG6lfGQwOo/E/2+x2bpVKsX8mYnZiY42WmAGQR7Y= =rlD9 -----END PGP SIGNATURE----- --Apple-Mail=_C3E3EBBD-E445-45A3-A605-A24BFE72E974-- From nobody Thu Jan 19 06:31: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 07C1712961A; Thu, 19 Jan 2017 06:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrK4xa1PyfLp; Thu, 19 Jan 2017 06:31:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A1F129602; Thu, 19 Jan 2017 06:31:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A92F6BE47; Thu, 19 Jan 2017 14:31:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuuMEpoiMFl0; Thu, 19 Jan 2017 14:31:19 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B660BE3E; Thu, 19 Jan 2017 14:31:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484836279; bh=BDH7GH9mDKLTB+5qdmQ879ILIAGCKlfIGo64V6TXjfc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4mTF0Tw3ZhU0ymwzh+GtazSUBv/SoVeVrFoFH//eCrAC548zoIpeQJRAtKKqhE5gV kwu9xgGEYTjs4fb8XnDAIDqM9iP1GxN8OgbCtUxYfIENGnj/GFfZzj5mmTGniw4No4 ZfMa7ZUCkEqx46UxInnCWg9jBUQWu+uOFQaPPB08= Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) To: Fernando Gont , The IESG References: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9020fab3-06cd-7de8-3a09-7ee0d8e6359a@cs.tcd.ie> Date: Thu, 19 Jan 2017 14:31:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040001020808070900080502" Archived-At: Cc: bob.hinden@gmail.com, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, ipv6@ietf.org, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:31:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040001020808070900080502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/01/17 13:36, Fernando Gont wrote: > On 01/19/2017 09:51 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-6man-rdnss-rfc6106bis-15: 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 thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> 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-rdnss-rfc6106bis/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I think this is the first "configure my DNS" thing to come >> before the IESG since DPRIVE has gotten an output, so it seems >> fair to ask now: >> >> Why doesn't the DNS server information include a port now that >> we have both 53 and 853 as options? Without that, how is a >> host supposed to know which to use? Did the WG consider >> DPRIVE? If so, what was the conclusion? If not, what is the >> right thing to do? (Add the port no? Define a new DHCPv6 option >> for DNS/TLS? Something else?) >=20 > FWIW, this is a revision of an existing standard, aimed at fixing known= > problems. Giving how critical it is to IPv6 deployment to convey DNS > information, I'd personally expect that something like you suggest > (which is sensible), would be done in a separate document -- e.g., in a= > brand-new option. I do agree that helping IPv6 deployment is more important at this stage than ensuring DPRIVE is handled as an integral part of this draft. OTOH, I'd be even happier if that's a WG consensus position and not just you and I:-) Cheers, S. >=20 > Thanks, >=20 --------------ms040001020808070900080502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTkx NDMxMThaMC8GCSqGSIb3DQEJBDEiBCCCxqC+BmzUtF8KPK62sfoV5hacEXifxg53hS+kAfB8 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQARH1uviBHf4CEKdMtf8bpBaqOGjz1QFpsLKxzO+gptzdyhWyegX8wG Jxk59JRkYNPc3ApZI8K1ti3EbxfEMCOd7bLhjiCBtdx2VovPlnym9zJiThYFipL8P+y8wUQ2 7WSh+J3eTNx6NCXQjIg7kCjRZ6KReecihhIYAFbr5vjuFZKV0dWT9UEWRPMmGTz2VbkziG68 ju2IgTHE16VNyB2dbm/NQ8z200zkGKE3E58sssBsodT+Kd5haPqOOzoyRuB3m4gsHbpglRm5 Rr0gya/aj45MKx8f1cXnbrwlXV8uWgaWcADTmj5LpnBuiu73la4sO163AGZcK/l1uhB0r2yB AAAAAAAA --------------ms040001020808070900080502-- From nobody Thu Jan 19 06:38: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 413F7129620; Thu, 19 Jan 2017 06:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 ce_pqI1w4L8I; Thu, 19 Jan 2017 06:38:48 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9062F12961E; Thu, 19 Jan 2017 06:38:48 -0800 (PST) X-AuditID: c618062d-aa3ff70000007359-7d-5880d635d3b9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id DC.1F.29529.536D0885; Thu, 19 Jan 2017 16:07:35 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 09:38:45 -0500 From: Suresh Krishnan To: Fernando Gont Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) Thread-Topic: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) Thread-Index: AQHSclK8V+ObW4qCzU6TVXv3hHtouaFAIVCAgAARVgA= Date: Thu, 19 Jan 2017 14:38:45 +0000 Message-ID: References: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> In-Reply-To: <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <020AE9FC82B55147BB93215401D91392@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyuXRPoK75tYYIgwmdfBa7p0xjs9j6fh+b xdeWuewWT1a9YbOY8Wcis8XLs++ZLCa3rWCzmL73GrsDh8fa7qtsHgePfWT02DnrLrvHkiU/ mTw+HOphD2CN4rJJSc3JLEst0rdL4Mp4/VKhYI5Qxf7mnSwNjJ/5uhg5OSQETCR+P2hg7WLk 4hASWM8oMfvxe0YIZzmjxMqGe+wgVWxAVRt2fmYCsUUENCXmPj/CBFLELHCLSeL0hE6gdg4O YYF4iSmH3SBqEiQuN59ihrCtJKbvWcgIYrMIqEqcu7ScBcTmFbCXePRlDgvEsjZGiZNPToM1 cAo4S3yc/g6sgVFATOL7qTVgi5kFxCVuPZnPBHG2gMSSPeeZIWxRiZeP/7FC2EoSH3/PZ4eo 15FYsPsTG4RtLfHoylyoOdoSyxa+ZoY4QlDi5MwnLBMYxWYhWTELSfssJO2zkLTPQtK+gJF1 FSNHaXFBTm66kcEmRmBkHpNg093BeH+65yFGAQ5GJR7egisNEUKsiWXFlbmHGCU4mJVEeDee BQrxpiRWVqUW5ccXleakFh9ilOZgURLnjVt9P1xIID2xJDU7NbUgtQgmy8TBKdXAmHn+m0vs l4zYY01tn+aENenNM54zhzfv08ynKx9dk//G5vDk35czZr5FWTLvE1Yarexg+WFv3XY753Hk 5+z6TwyLVA5can7N2n5nkYb1te7dx6S3P82ZydP8hHNdorJpaH9x2FWf3LO/me8/q4tcIGq9 /qyTesClk28mCkgfvdAwSW16VdvK/0osxRmJhlrMRcWJANG6HNDIAgAA Archived-At: Cc: 6man WG , Robert Hinden , "draft-ietf-6man-rdnss-rfc6106bis@ietf.org" , The IESG , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "Stephen Farrell \(stephen.farrell@cs.tcd.ie\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:38:52 -0000 Hi Stephen, > On Jan 19, 2017, at 8:36 AM, Fernando Gont wrote: >=20 > On 01/19/2017 09:51 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-6man-rdnss-rfc6106bis-15: 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.htm= l >> 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-rdnss-rfc6106bis/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >>=20 >> I think this is the first "configure my DNS" thing to come >> before the IESG since DPRIVE has gotten an output, so it seems >> fair to ask now: >>=20 >> Why doesn't the DNS server information include a port now that >> we have both 53 and 853 as options? Without that, how is a >> host supposed to know which to use? Did the WG consider >> DPRIVE? If so, what was the conclusion? If not, what is the >> right thing to do? (Add the port no? Define a new DHCPv6 option >> for DNS/TLS? Something else?) I think you have a fair point but it was not really within scope of what th= e WG wanted to accomplish with this document (which is to fix some issues t= hat were discovered during implementation/deployment).=20 >=20 > FWIW, this is a revision of an existing standard, aimed at fixing known > problems. Giving how critical it is to IPv6 deployment to convey DNS > information, I'd personally expect that something like you suggest > (which is sensible), would be done in a separate document -- e.g., in a > brand-new option. Yes. Given that this fixes some important issues like DNS information expir= y on lossy links as well as reduction of unnecessary multicast traffic, I w= ould hate to hold this document up. I would much rather have a separate doc= ument that extends this option with port info. Thanks Suresh From nobody Thu Jan 19 06:52: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 9937E12960C for ; Thu, 19 Jan 2017 06:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds_BXfjI2YpL for ; Thu, 19 Jan 2017 06:52:10 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F241270B4 for ; Thu, 19 Jan 2017 06:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NE4aTfK/ivAKfGcLYM1JR3YmUuvrPaiV6CG6Z9+8YE4=; b=npcK2IdmDIc5jwgog1RPqz7DwzR5jGnuv3hlw/Qys6FP1RaUjb9vymzL2QdV6dXolYlX/vsKKBk7Mrad51B/fIS+WwH80UR8xf9tV0H/PL2+/nw5zFl2NsbV01bxOtU8pxVCnMGG9l+dg+LldixELTkAE4jpsEwBgyvnTCKZy8w= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0240.outbound.protection.outlook.com [213.199.154.240]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-64-5HkeOHhcOQ6OZqQ7X8LyXA-1; Thu, 19 Jan 2017 14:50:59 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 14:50:57 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::5989:a034:d099:8480%15]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 14:50:57 +0000 From: Tim Chown To: Suresh Krishnan Subject: Re: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) Thread-Topic: Stephen Farrell's Discuss on draft-ietf-6man-rdnss-rfc6106bis-15: (with DISCUSS) Thread-Index: AQHSclLIkMmLGJegG06MeEhrNwRBb6E/zX6AgAARVYCAAANoAA== Date: Thu, 19 Jan 2017 14:50:57 +0000 Message-ID: <52F53F9D-CB8C-4CFD-A1CB-67293E727F52@jisc.ac.uk> References: <148483027733.10394.5733573036724815686.idtracker@ietfa.amsl.com> <677f1f83-a6ea-c03d-565d-33719cb0b924@si6networks.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a03:9800:30:0:55c9:c104:4ed4:dfd1] x-ms-office365-filtering-correlation-id: 7fbd4519-c0c4-4b34-f6c7-08d4407a93ba x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB1140; x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 7:DO0LqwCl8Pwj8m+CzwnGXkDTYlBRKgpqI/CQ/LVrrEA7SWR8u+jtGBXTUCX7GMyo5yrMgM+fmdEdfgu+ouTrildvzlW5C1yCSN3XMRULhedvujYHOepFaJm4mC5HHRFscge8SahjEtFefz1u0dTjhKZEAukcBlu+kXWnCTGAQOD3FqDhD6zEo06or+4YQu4dl5YkoXhCjFI/TJ683UhmpBq5i1lbXOV21HcoK4U5OtlI5rL0T3ft4Iqj1Gj5UJpfCuEWmYTvSuLVgmXzPnAZ9I301y10pv134Qr6yrnClnBaBoKfjen5uxnuNlXfPFZw43UOZMzEH4ygwyysDyB7d1oewXpLUIRNzWnjb3YhUVUgfW9XEWHshL52ydId/+0tKfQvxte+vSfUnEp3Yvsd34s6Kj+/EieaUyaqdfspEgivDPCWgM11hx/18RaI9pm7WAbyvtt+NT9ycOKBUfEtHg==; 20:pjLY2Dz9wAkd2DGU2tb1bQhEwroYnVVnSgcGJlQ7wiSUwtM9jto0m8ybQNYDnO2Fg87SLG1m1zuPdi0wo/t369hW8uu4lO+sSoPYtCOO+kInwWB/U5q+MEpvnEQzXoQ+Cp3g1jiHpjj5A9BeJHp4pEcc4zOSgGPieebFxUxMgrc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1140; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(377454003)(189002)(24454002)(38730400001)(229853002)(39060400001)(86362001)(5660300001)(110136003)(3280700002)(230783001)(36756003)(6916009)(50986999)(101416001)(42882006)(33656002)(2950100002)(76176999)(2900100001)(8676002)(7736002)(5250100002)(2906002)(106356001)(81166006)(81156014)(6512007)(97736004)(305945005)(57306001)(92566002)(4326007)(74482002)(6436002)(50226002)(6116002)(53936002)(6486002)(6506006)(99286003)(8936002)(106116001)(68736007)(6306002)(102836003)(54906002)(83716003)(189998001)(82746002)(3660700001)(105586002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <2B74C9BBEC04A9438A0F4BD2DA026B62@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 14:50:57.3992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: 5HkeOHhcOQ6OZqQ7X8LyXA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man WG , Robert Hinden , "draft-ietf-6man-rdnss-rfc6106bis@ietf.org" , The IESG , Fernando Gont , "Stephen Farrell \(stephen.farrell@cs.tcd.ie\)" , "6man-chairs@ietf.org" <6man-chairs@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:52:16 -0000 SGksDQoNCj4gT24gMTkgSmFuIDIwMTcsIGF0IDE0OjM4LCBTdXJlc2ggS3Jpc2huYW4gPHN1cmVz aC5rcmlzaG5hbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGkgU3RlcGhlbiwNCj4gDQo+ PiBPbiBKYW4gMTksIDIwMTcsIGF0IDg6MzYgQU0sIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5l dHdvcmtzLmNvbT4gd3JvdGU6DQo+PiANCj4+IE9uIDAxLzE5LzIwMTcgMDk6NTEgQU0sIFN0ZXBo ZW4gRmFycmVsbCB3cm90ZToNCj4+PiBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+Pj4gZHJhZnQtaWV0Zi02bWFuLXJkbnNzLXJm YzYxMDZiaXMtMTU6IERpc2N1c3MNCj4+PiANCj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4+PiBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcw0KPj4+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4+IA0KPj4+ IA0KPj4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4+IA0KPj4+IA0KPj4+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLTZt YW4tcmRuc3MtcmZjNjEwNmJpcy8NCj4+PiANCj4+PiANCj4+PiANCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4gRElTQ1VTUzoNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gDQo+Pj4gDQo+Pj4gSSB0aGlu ayB0aGlzIGlzIHRoZSBmaXJzdCAiY29uZmlndXJlIG15IEROUyIgdGhpbmcgdG8gY29tZQ0KPj4+ IGJlZm9yZSB0aGUgSUVTRyBzaW5jZSBEUFJJVkUgaGFzIGdvdHRlbiBhbiBvdXRwdXQsIHNvIGl0 IHNlZW1zDQo+Pj4gZmFpciB0byBhc2sgbm93Og0KPj4+IA0KPj4+IFdoeSBkb2Vzbid0IHRoZSBE TlMgc2VydmVyIGluZm9ybWF0aW9uIGluY2x1ZGUgYSBwb3J0IG5vdyB0aGF0DQo+Pj4gd2UgaGF2 ZSBib3RoIDUzIGFuZCA4NTMgYXMgb3B0aW9ucz8gIFdpdGhvdXQgdGhhdCwgaG93IGlzIGENCj4+ PiBob3N0IHN1cHBvc2VkIHRvIGtub3cgd2hpY2ggdG8gdXNlPyBEaWQgdGhlIFdHIGNvbnNpZGVy DQo+Pj4gRFBSSVZFPyBJZiBzbywgd2hhdCB3YXMgdGhlIGNvbmNsdXNpb24/IElmIG5vdCwgd2hh dCBpcyB0aGUNCj4+PiByaWdodCB0aGluZyB0byBkbz8gKEFkZCB0aGUgcG9ydCBubz8gRGVmaW5l IGEgbmV3IERIQ1B2NiBvcHRpb24NCj4+PiBmb3IgRE5TL1RMUz8gU29tZXRoaW5nIGVsc2U/KQ0K PiANCj4gSSB0aGluayB5b3UgaGF2ZSBhIGZhaXIgcG9pbnQgYnV0IGl0IHdhcyBub3QgcmVhbGx5 IHdpdGhpbiBzY29wZSBvZiB3aGF0IHRoZSBXRyB3YW50ZWQgdG8gYWNjb21wbGlzaCB3aXRoIHRo aXMgZG9jdW1lbnQgKHdoaWNoIGlzIHRvIGZpeCBzb21lIGlzc3VlcyB0aGF0IHdlcmUgZGlzY292 ZXJlZCBkdXJpbmcgaW1wbGVtZW50YXRpb24vZGVwbG95bWVudCkuIA0KDQo+PiBGV0lXLCB0aGlz IGlzIGEgcmV2aXNpb24gb2YgYW4gZXhpc3Rpbmcgc3RhbmRhcmQsIGFpbWVkIGF0IGZpeGluZyBr bm93bg0KPj4gcHJvYmxlbXMuIEdpdmluZyBob3cgY3JpdGljYWwgaXQgaXMgdG8gSVB2NiBkZXBs b3ltZW50IHRvIGNvbnZleSBETlMNCj4+IGluZm9ybWF0aW9uLCBJJ2QgcGVyc29uYWxseSBleHBl Y3QgdGhhdCBzb21ldGhpbmcgbGlrZSB5b3Ugc3VnZ2VzdA0KPj4gKHdoaWNoIGlzIHNlbnNpYmxl KSwgd291bGQgYmUgZG9uZSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IC0tIGUuZy4sIGluIGENCj4+ IGJyYW5kLW5ldyBvcHRpb24uDQo+IA0KPiBZZXMuIEdpdmVuIHRoYXQgdGhpcyBmaXhlcyBzb21l IGltcG9ydGFudCBpc3N1ZXMgbGlrZSBETlMgaW5mb3JtYXRpb24gZXhwaXJ5IG9uIGxvc3N5IGxp bmtzIGFzIHdlbGwgYXMgcmVkdWN0aW9uIG9mIHVubmVjZXNzYXJ5IG11bHRpY2FzdCB0cmFmZmlj LCBJIHdvdWxkIGhhdGUgdG8gaG9sZCB0aGlzIGRvY3VtZW50IHVwLiBJIHdvdWxkIG11Y2ggcmF0 aGVyIGhhdmUgYSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IGV4dGVuZHMgdGhpcyBvcHRpb24gd2l0 aCBwb3J0IGluZm8uDQoNCkkgYWdyZWUsIGFzIHlvdeKAmWQgdGhlbiBhbHNvIChJIHByZXN1bWUp IGJlIG5lZWRpbmcgdG8gZXh0ZW5kIERIQ1B2NiBvcHRpb25zIHRvIHN1cHBvcnQgY29udmV5aW5n IHRoZSBzYW1lIGluZm9ybWF0aW9uLCBzbyBjb3VsZCBjb3ZlciBvZmYgYm90aCBtZXRob2RzIGlu IG9uZSBkb2MgaW4gYSBzaW1pbGFyIHdheSB0byB0aGUgUkZDNzcxMCAiUmljayBSb2xsIiBvcHRp b24uDQoNClRpbQ== From nobody Thu Jan 19 11:26: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 937A3129407 for ; Thu, 19 Jan 2017 11:26:27 -0800 (PST) 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 RS7iaBeTiNow for ; Thu, 19 Jan 2017 11:26:26 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0F1129554 for ; Thu, 19 Jan 2017 11:26:26 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 14so16472748pgg.1 for ; Thu, 19 Jan 2017 11:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hZvQt2XgFsmOdZhhsSEggjAUJvkv9rGgUBpBC8IVIRU=; b=ZQs26AF1u0d7c4fyz3jjWNPWimAjot4PeYR47UdqMm0nh1JJrY7/9EBECGyHiyyppX DELV1wJi1QcnLeLccP/qJi/YIUTvcAKF2K5eN7fXe4DmWGHKco6baKWuTiUReKZmi2hy pWHnejOJIVioG0EWgE4T0R+9CYWXsU8jC0fdti1cY19k8NsskXiuEoiEtNBmyiEJgkKX 0oNfxR3UrjSW2epsrYEMzmkZMxP+40bTacqm2DKctdYMN7Uej/76KYkKtBLD2R6nh3fs lvmALzn7m69BPzRb+V496QVtpqKSUZTi13pUDq6hbitrw5AvTqP4X7b76hEmbYNpt/FX 3REQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hZvQt2XgFsmOdZhhsSEggjAUJvkv9rGgUBpBC8IVIRU=; b=gDnnMp7mX5sr3Xt9S7R+Domqiq5wxOXpnkJiLe4/Z+vX+gcgaLAD6RmHtTopMAi1ea YKHrz8zG3XVJYl+gucUJPXV66pVz+KW7m+145ova1feRkxDHSnCLS8JbPajGRumbA2Vy TQFKDM8IiVRHx2vTmqNzNAlmwjw0n9jJvqfmHgk6a0d2pJafOt+Hbooz1ItEZJNUHSwZ 7jaiJokPRscEXguNsol781y1RujL1Q0cD/1Zxwk6GcfoBKmW2aEPRxCdgJNtLLTcjBDF lwRXqpQcx/zBzIsBzpWeSh+voUV5qghxEGaK78BIDIfTHE+yorBVerHdlkwU/cY23wbo DEOw== X-Gm-Message-State: AIkVDXLoJvofeLN2jRyVNAjZws0gkdnMkbjBjqk2GfIuh504vZkaFrQXXCwQjK60whWmXA== X-Received: by 10.98.18.217 with SMTP id 86mr11928521pfs.90.1484853985803; Thu, 19 Jan 2017 11:26:25 -0800 (PST) Received: from [192.168.178.21] ([118.148.118.52]) by smtp.gmail.com with ESMTPSA id h17sm10693287pfh.62.2017.01.19.11.26.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:26:25 -0800 (PST) Subject: Re: Updated IID length text To: ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1798bf13-b031-8ffc-78ea-7d01c4756dc9@gmail.com> Date: Fri, 20 Jan 2017 08:26:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:26:27 -0000 On 19/01/2017 22:26, Alexandre Petrescu wrote: ... > I do not agree with the part that says "IIDs are required be 64bit long". But they are, today. In the move to full Standard, we cannot actually change that; we can only clarify the wording. > If IIDs are required to be 64bit long (even if only in the 000-prefixed > space) then the network can not grow at the edges, at least not with > SLAAC. That would be true if /64 prefixes were scarce. They are not. But that's why the proposed text is limited to currently allocated unicast space - if we ever need to change this, it will be a new tranche of unicast space. In any case, this is nothing to do with progressing to full Standard. Brian From nobody Thu Jan 19 11:28: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 6673A12943B for ; Thu, 19 Jan 2017 11:28:35 -0800 (PST) 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 55jxSqHbwv_P for ; Thu, 19 Jan 2017 11:28:34 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30897129407 for ; Thu, 19 Jan 2017 11:28:34 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id t6so16461632pgt.3 for ; Thu, 19 Jan 2017 11:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/tOWsMfvPWxAKlqAwS4Y7ObRhUwL9FmdK/4SqTvN2h0=; b=NA0Cyvw4xQtiFt/+7sRpBC8TmhF+iSxyUWggrWwdYw6gDuw/V3TRLrw+rJC+UUZZXq ryYfS9BMdeItD2PX6fnIa0Mt38ccI2QLHY3jIHnreSSfNBhCj0pKMrwCzyrAGxFB9Y+e X1PaQHVCw5OhckdQ0iaD2kf7EVP+anNgFbRTu0AqckCghGcA86ZTgtqa6WqilEMnW2xA lvix3DrTLkYXnSryKfLCYuzLwDPJ31xMKlkPlE00dPkZy/qUkElxUPAsNOf0rDuZ68K2 wlctStQjkVd18OmuOSLZ+csvFo6zFrIfYHB943kTMYcZUAIPnT3ULfxgoL+lq70eIh7G IQjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=/tOWsMfvPWxAKlqAwS4Y7ObRhUwL9FmdK/4SqTvN2h0=; b=jE4Cy/sSbwOoN0tiuH8x/QIPclWs+l85nUTMgB/Vgl5LaY1O5fLAXSLB92+Cc1Xb4g OMhR60HRd9Fxb53IyRoef4TrCP2PAbAkteVfOZNDiczcpu1iHaOSTSjdKcl72/Wqi/7B ZqietVqkLWlDFssMRwQtmAB5gvbTfX/S7Z+OHtuK6h7BAx+SnVGhjoT82aykBKHdhhg+ T/F4oQtXjWlx0lZTz9rLZBr3wg48ogntb4qOcUiMWS1ORtmLml+WaysLh7UwpDWOMFeZ c7L8B4ZGyqT2SUvqxB+C1286JeOQbgzs4UugsahELShFNcPCAKOa5amH6jJeuI3E65AV nvxg== X-Gm-Message-State: AIkVDXIW9uzujB5vn0MgXwwOEeTQNIS1+o7tMArDOa2QVAP5fxYqLj47PDPfy+vA45o5hw== X-Received: by 10.99.160.84 with SMTP id u20mr12242275pgn.141.1484854113566; Thu, 19 Jan 2017 11:28:33 -0800 (PST) Received: from [192.168.178.21] ([118.148.118.52]) by smtp.gmail.com with ESMTPSA id r8sm10661293pfi.82.2017.01.19.11.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:28:33 -0800 (PST) Subject: Re: Updated IID length text To: Fernando Gont , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Jan 2017 08:28:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:28:35 -0000 Hi Fernando, On 19/01/2017 17:03, Fernando Gont wrote: > Hi, Brian, > > On 01/18/2017 09:37 PM, Brian E Carpenter wrote: >> OK, after all that discussion, here is a revised proposal. There is >> nothing new here at all, IMHO; just clarification: >> >> OLD >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> >> NEW >> IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, consistent use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same length >> of Interface ID. To guarantee interoperability of SLAAC, a fixed length of >> Interface ID is necessary. > > s/fixed/consistent/. That would use the word 'consistent' twice, which is slightly horrible English. But I agree with the intention. Brian > > Thanks for your energy in this, > From nobody Thu Jan 19 11:41: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 8355812943B for ; Thu, 19 Jan 2017 11:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evNVEY9ITnj1 for ; Thu, 19 Jan 2017 11:41:31 -0800 (PST) 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 C7BD712951E for ; Thu, 19 Jan 2017 11:41:21 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id f144so15788093pfa.2 for ; Thu, 19 Jan 2017 11:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YC6jcr80Y3K5HvnbkDEIJ+qXslzoBxdp/Brlhw0RCqc=; b=NhQp+TCLro4PcQTNy/M1OHsyd4xBecX8e5YTgItWMuAi3oJhOCLIPr2Li7ZaddPjM6 9AdcrMtDMAk9bB8Q9BNdS1oXJZ8EuKli9Kf3Yt1Gl9Xjyb5PIfdt+vkLNAfTAPEey20+ YVNv33/KmVM9aOF5xMRnPFKIO+272aO0j8mBBWEGLcTpuuRmfu60W7xGEdMwrC/WKitR KOWg+w8pw6R0N9g9l2S5JHt/AiO6VY7rAH5cGO/pOZ1EPCb9EB4kCkd6M5iYIlV3cFOZ jaFEVv3sKZqX7xpjDMl5CAZkRpsM8Mi9ZiF8IitidXW3iHXOFM0DvvLgdyMHn12K85bj SZig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=YC6jcr80Y3K5HvnbkDEIJ+qXslzoBxdp/Brlhw0RCqc=; b=Ed0RZC/v1UaBIzsyMV1wxZ8yqxnBp3ZvRFOCOnIlTvqtR7q2gAoKezXgXnY7bF8tFS SkPJXG8oaQd6LnZpNpTPHz2guvHkgj42D7Edc22Ew3xzHo3Rf2KhUTOZFzD8LPuPkfaQ Jr0fFn3JeBo6KrR+0+jgwvgHkhE87k7s2ISkL7Sk50FBPvQqR6cMSkgqeUnCi1iOw3IQ FHgMWCAdlVDOoaZwFuU/7tyWWgAf54/Bv94rPIyOkMp3B3emv7S0BxujF9yehbbfPbrf 6mbKnf7bzvuoxnxe2D8E/ppQ814cs4ccrAowmkAa+WY3fzfwxCHNE/V9L7LTJYo0rHFN 6YWw== X-Gm-Message-State: AIkVDXJwws54MW8EpXg4ejUihAxJHaQLwT8xs3A+GNPD6dPOerKGIdLlH+XEXyZVMJ2UuA== X-Received: by 10.99.124.66 with SMTP id l2mr12374575pgn.116.1484854881329; Thu, 19 Jan 2017 11:41:21 -0800 (PST) Received: from [192.168.178.21] ([118.148.70.176]) by smtp.gmail.com with ESMTPSA id q2sm10863275pga.8.2017.01.19.11.41.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 11:41:20 -0800 (PST) Subject: Re: Updated IID length text To: "Manfredi, Albert E" , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Jan 2017 08:41:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:41:42 -0000 On 19/01/2017 16:23, Brian E Carpenter wrote: > On 19/01/2017 15:55, Manfredi, Albert E wrote: > ... >>> I don't think that SLAAC *must* require a single standard IID length, so >>> that's why I added the word "robust." Now that we have moved away from using >>> the MAC address for SLAAC, it's not clear to me why a host cannot wait for a >>> RA, and then decide on how many IID bits to use, based on the prefix >>> length(s) advertised by the router. > > Not if you want to form a link-local address first. Which you always do, > because perhaps there *is* no router when you come up after a power cut. > (In the Anima WG, we are very interested in the behaviour of nodes > that have absolutely no external information when they come up, because > it's their job to bootstrap the network out of nowhere.) I should have added that in the context of promoting the document to full Standard, we can't introduce new behaviour. But I don't object to the word 'robust'. I don't think it makes sense to use the word 'standard' inside a standard, however. And using 'consistent' twice is ugly. So I get to NEW NEW IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, correct use of Stateless Address Autoconfiguration (SLAAC)[RFC4862] requires all interfaces on a link to use the same length of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC, a consistent length of Interface ID is desirable. For this reason, the Interface ID of all currently allocated unicast addresses, except those that start with the binary value 000, is required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Any speculation about deviations from /64 is out of scope, IMHO, for a draft being proposed for full Standard, given that 4291 requires /64. Brian From nobody Thu Jan 19 12:30: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 D391F12956C for ; Thu, 19 Jan 2017 12:30:43 -0800 (PST) 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 LdsTVEdbJNVh for ; Thu, 19 Jan 2017 12:30:41 -0800 (PST) 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 15C03129573 for ; Thu, 19 Jan 2017 12:30:40 -0800 (PST) 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 v0JKUdw9057583; Thu, 19 Jan 2017 13:30:39 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0JKUZTN057542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 13:30:35 -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.1178.4; Thu, 19 Jan 2017 12:30:34 -0800 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.1178.000; Thu, 19 Jan 2017 12:30:35 -0800 From: "Manfredi, Albert E" To: Brian E Carpenter , 6man Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScowEqB5Tp7XZTkyunKSq9IrHHaFAPzhQ Date: Thu, 19 Jan 2017 20:30:34 +0000 Message-ID: <28102f87f8e043248da16d9273d4c7d7@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:30:44 -0000 QnJpYW4sIEknbSBjb21wbGV0ZWx5IG9uIGJvYXJkIHdpdGggeW91ciB0ZXh0IGJlbG93LiBJIHRo aW5rIHRoYXQgdGhpcyBzaG91bGQgc2F0aXNmeSBldmVuIHRoZSBvYmplY3Rpb25zLCBieSBhdm9p ZGluZyBhbnkgInNwZWN1bGF0aW9uLiINCg0KQmVydCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE5LCAyMDE3IDE0OjQxDQpUbzog TWFuZnJlZGksIEFsYmVydCBFIDxhbGJlcnQuZS5tYW5mcmVkaUBib2VpbmcuY29tPjsgNm1hbiA8 aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBVcGRhdGVkIElJRCBsZW5ndGggdGV4dA0KDQpP biAxOS8wMS8yMDE3IDE2OjIzLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4gT24gMTkvMDEv MjAxNyAxNTo1NSwgTWFuZnJlZGksIEFsYmVydCBFIHdyb3RlOg0KPiAuLi4NCj4+PiBJIGRvbid0 IHRoaW5rIHRoYXQgU0xBQUMgKm11c3QqIHJlcXVpcmUgYSBzaW5nbGUgc3RhbmRhcmQgSUlEIGxl bmd0aCwgc28NCj4+PiB0aGF0J3Mgd2h5IEkgYWRkZWQgdGhlIHdvcmQgInJvYnVzdC4iIE5vdyB0 aGF0IHdlIGhhdmUgbW92ZWQgYXdheSBmcm9tIHVzaW5nDQo+Pj4gdGhlIE1BQyBhZGRyZXNzIGZv ciBTTEFBQywgaXQncyBub3QgY2xlYXIgdG8gbWUgd2h5IGEgaG9zdCBjYW5ub3Qgd2FpdCBmb3Ig YQ0KPj4+IFJBLCBhbmQgdGhlbiBkZWNpZGUgb24gaG93IG1hbnkgSUlEIGJpdHMgdG8gdXNlLCBi YXNlZCBvbiB0aGUgcHJlZml4DQo+Pj4gbGVuZ3RoKHMpIGFkdmVydGlzZWQgYnkgdGhlIHJvdXRl ci4NCj4gDQo+IE5vdCBpZiB5b3Ugd2FudCB0byBmb3JtIGEgbGluay1sb2NhbCBhZGRyZXNzIGZp cnN0LiBXaGljaCB5b3UgYWx3YXlzIGRvLA0KPiBiZWNhdXNlIHBlcmhhcHMgdGhlcmUgKmlzKiBu byByb3V0ZXIgd2hlbiB5b3UgY29tZSB1cCBhZnRlciBhIHBvd2VyIGN1dC4NCj4gKEluIHRoZSBB bmltYSBXRywgd2UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiB0aGUgYmVoYXZpb3VyIG9mIG5vZGVz DQo+IHRoYXQgaGF2ZSBhYnNvbHV0ZWx5IG5vIGV4dGVybmFsIGluZm9ybWF0aW9uIHdoZW4gdGhl eSBjb21lIHVwLCBiZWNhdXNlDQo+IGl0J3MgdGhlaXIgam9iIHRvIGJvb3RzdHJhcCB0aGUgbmV0 d29yayBvdXQgb2Ygbm93aGVyZS4pDQoNCkkgc2hvdWxkIGhhdmUgYWRkZWQgdGhhdCBpbiB0aGUg Y29udGV4dCBvZiBwcm9tb3RpbmcgdGhlIGRvY3VtZW50IHRvDQpmdWxsIFN0YW5kYXJkLCB3ZSBj YW4ndCBpbnRyb2R1Y2UgbmV3IGJlaGF2aW91ci4gQnV0IEkgZG9uJ3Qgb2JqZWN0IHRvIHRoZSB3 b3JkDQoncm9idXN0Jy4gIEkgZG9uJ3QgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIHRoZSB3 b3JkICdzdGFuZGFyZCcgaW5zaWRlIGENCnN0YW5kYXJkLCBob3dldmVyLiBBbmQgdXNpbmcgJ2Nv bnNpc3RlbnQnIHR3aWNlIGlzIHVnbHkuIFNvIEkgZ2V0IHRvDQoNCk5FVyBORVcNCiAgIElQdjYg cm91dGluZyBpcyBiYXNlZCBvbiBwcmVmaXhlcyBvZiBhbnkgdmFsaWQgbGVuZ3RoIHVwIHRvIDEy OCBbQkNQMTk4XS4NCiAgIEZvciBleGFtcGxlLCBbUkZDNjE2NF0gc3RhbmRhcmRpc2VzIDEyNyBi aXQgcHJlZml4ZXMgb24gcG9pbnQtdG8tcG9pbnQNCiAgIGxpbmtzLiBIb3dldmVyLCBjb3JyZWN0 IHVzZSBvZiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbg0KICAgKFNMQUFDKVtS RkM0ODYyXSByZXF1aXJlcyBhbGwgaW50ZXJmYWNlcyBvbiBhIGxpbmsgdG8gdXNlIHRoZSBzYW1l IGxlbmd0aA0KICAgb2YgSW50ZXJmYWNlIElELiBGdXJ0aGVybW9yZSwgdG8gZ3VhcmFudGVlIHJv YnVzdCBpbnRlcm9wZXJhYmlsaXR5IG9mIFNMQUFDLA0KICAgYSBjb25zaXN0ZW50IGxlbmd0aCBv ZiBJbnRlcmZhY2UgSUQgaXMgZGVzaXJhYmxlLiBGb3IgdGhpcyByZWFzb24sIHRoZQ0KICAgSW50 ZXJmYWNlIElEIG9mIGFsbCBjdXJyZW50bHkgYWxsb2NhdGVkIHVuaWNhc3QgYWRkcmVzc2VzLCBl eGNlcHQgdGhvc2UgdGhhdA0KICAgc3RhcnQgd2l0aCB0aGUgYmluYXJ5IHZhbHVlIDAwMCwgaXMg cmVxdWlyZWQgdG8gYmUgNjQgYml0cyBsb25nLiBCYWNrZ3JvdW5kDQogICBvbiB0aGUgNjQgYml0 IGJvdW5kYXJ5IGluIElQdjYgYWRkcmVzc2VzIGNhbiBiZSBmb3VuZCBpbiBbUkZDNzQyMV0uDQoN CkFueSBzcGVjdWxhdGlvbiBhYm91dCBkZXZpYXRpb25zIGZyb20gLzY0IGlzIG91dCBvZiBzY29w ZSwgSU1ITywgZm9yDQphIGRyYWZ0IGJlaW5nIHByb3Bvc2VkIGZvciBmdWxsIFN0YW5kYXJkLCBn aXZlbiB0aGF0IDQyOTEgcmVxdWlyZXMgLzY0Lg0KDQogICAgQnJpYW4NCg0K From nobody Thu Jan 19 13:02: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 AD61312957E for ; Thu, 19 Jan 2017 13:02:51 -0800 (PST) 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 AyalV63TVkfC for ; Thu, 19 Jan 2017 13:02:50 -0800 (PST) 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 153CC12956C for ; Thu, 19 Jan 2017 13:02:50 -0800 (PST) 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 v0JL2nUA045662; Thu, 19 Jan 2017 14:02: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 v0JL2fvw045619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 14:02:41 -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.1178.4; Thu, 19 Jan 2017 13:02:40 -0800 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.1178.000; Thu, 19 Jan 2017 13:02:41 -0800 From: "Manfredi, Albert E" To: "otroan@employees.org" Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScowEqB5Tp7XZTkyunKSq9IrHHaFAy66A//98lQA= Date: Thu, 19 Jan 2017 21:02:40 +0000 Message-ID: <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> In-Reply-To: <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [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: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:02:51 -0000 > -----Original Message----- > From: otroan@employees.org [mailto:otroan@employees.org] >=20 > Brian, >=20 > [...] >=20 > > NEW NEW > > IPv6 routing is based on prefixes of any valid length up to 128 [BCP1= 98]. > > For example, [RFC6164] standardises 127 bit prefixes on point-to-poin= t > > links. However, correct use of Stateless Address Autoconfiguration > > (SLAAC)[RFC4862] requires all interfaces on a link to use the same le= ngth > > of Interface ID. Furthermore, to guarantee robust interoperability of > SLAAC, > > a consistent length of Interface ID is desirable. For this reason, th= e > > Interface ID of all currently allocated unicast addresses, except tho= se > that > > start with the binary value 000, is required to be 64 bits long. > Background > > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >=20 > By changing "For all unicast addresses" to "all currently allocated unica= st > addresses", >=20 > Are you proposing to reverse the decision that was made back when RFC3513 > updated RFC2373? > Change log: > - Revised sections 2.4 and 2.5.6 > to simplify and clarify how > different address types are identified. This was done to insure > that implementations do not build in any knowledge about global > unicast format prefixes. Changes include: > o Removed Format Prefix (FP) terminology > o Revised list of address types to only include exceptions to > global unicast and a singe entry that identifies everything > else as Global Unicast. Not speaking for Brian, my reaction to the RFC 3513 text would be that Bria= n's new text better responds to "This was done to insure that implementatio= ns do not build in any knowledge about global unicast format prefixes." We have a pragmatic requirement of 64-bit IIDs, for the existing (minority)= of assigned global unicast addresses. But we don't want to reverse the int= ention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which= has existed for too many years. Bert From nobody Thu Jan 19 13:57: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 810E5129640 for ; Thu, 19 Jan 2017 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, 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 FaztvOy0t6Nd for ; Thu, 19 Jan 2017 13:57:22 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC4D129481 for ; Thu, 19 Jan 2017 13:57:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v0JLvKcg010101 for ; Thu, 19 Jan 2017 22:57:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6731E202FA5 for ; Thu, 19 Jan 2017 22:57:20 +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 5DCA4202A0F for ; Thu, 19 Jan 2017 22:57:20 +0100 (CET) Received: from [132.166.84.48] ([132.166.84.48]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v0JLvJBE008001 for ; Thu, 19 Jan 2017 22:57:20 +0100 Subject: Re: Updated IID length text To: ipv6@ietf.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <1798bf13-b031-8ffc-78ea-7d01c4756dc9@gmail.com> From: Alexandre Petrescu Message-ID: <696433c7-e976-c334-1b67-edcf9ee45bcc@gmail.com> Date: Thu, 19 Jan 2017 22:57:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1798bf13-b031-8ffc-78ea-7d01c4756dc9@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:57:24 -0000 Le 19/01/2017 20:26, Brian E Carpenter a crit : > On 19/01/2017 22:26, Alexandre Petrescu wrote: ... >> I do not agree with the part that says "IIDs are required be 64bit >> long". > > But they are, today. In the move to full Standard, we cannot actually > change that; we can only clarify the wording. > >> If IIDs are required to be 64bit long (even if only in the >> 000-prefixed space) then the network can not grow at the edges, at >> least not with SLAAC. > > That would be true if /64 prefixes were scarce. They are not. The mobile network operators today make it look as if the /64 prefixes were scarce. Maybe they dont know these /64 are not scarce, or maybe they dont care about scarcity (just as it's not IPv4 scarcity making them deploy IPv6). The end result is the same: end users get each a /64, i.e. one single subnet. Spec-wise the IID len cant change, the Ethernet IID len cant change, the DHCPv6 PD is not deployed, the operators only give a /64 to end user... one is free to pick the reason, and again the end result is the same: no growth at the edge. The archi document is free to recognize reality. If so, it should recognize it so in a paragraph: no growth at the edges. Alex > But that's why the proposed text is limited to currently allocated > unicast space - if we ever need to change this, it will be a new > tranche of unicast space. In any case, this is nothing to do with > progressing to full Standard. > > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jan 19 14:04: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 2CB10129632 for ; Thu, 19 Jan 2017 14:04:17 -0800 (PST) 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 aj6uKsICZuan for ; Thu, 19 Jan 2017 14:04:12 -0800 (PST) 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 8D3B712961F for ; Thu, 19 Jan 2017 14:04:12 -0800 (PST) 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 v0JM4BvZ035034; Thu, 19 Jan 2017 15:04:12 -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 v0JM42Hj034885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 15:04:02 -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.1178.4; Thu, 19 Jan 2017 14:04:01 -0800 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.1178.000; Thu, 19 Jan 2017 14:04:01 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "ipv6@ietf.org" Subject: RE: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScp8Mid/NKuaNYkeeaZ/wu4YnU6FAWhGw Date: Thu, 19 Jan 2017 22:04:01 +0000 Message-ID: <0af627fdc8a448e4a98d03e856ffe2fe@XCH15-06-08.nw.nos.boeing.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <1798bf13-b031-8ffc-78ea-7d01c4756dc9@gmail.com> <696433c7-e976-c334-1b67-edcf9ee45bcc@gmail.com> In-Reply-To: <696433c7-e976-c334-1b67-edcf9ee45bcc@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="iso-8859-1" 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 22:04:17 -0000 Hi Alex, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, January 19, 2017 1:57 PM > To: ipv6@ietf.org > Subject: Re: Updated IID length text >=20 >=20 >=20 > Le 19/01/2017 =E0 20:26, Brian E Carpenter a =E9crit : > > On 19/01/2017 22:26, Alexandre Petrescu wrote: ... > >> I do not agree with the part that says "IIDs are required be 64bit > >> long". > > > > But they are, today. In the move to full Standard, we cannot actually > > change that; we can only clarify the wording. > > > >> If IIDs are required to be 64bit long (even if only in the > >> 000-prefixed space) then the network can not grow at the edges, at > >> least not with SLAAC. > > > > That would be true if /64 prefixes were scarce. They are not. >=20 > The mobile network operators today make it look as if the /64 > prefixes were scarce. >=20 > Maybe they dont know these /64 are not scarce, or maybe they dont care > about scarcity (just as it's not IPv4 scarcity making them deploy IPv6). > The end result is the same: end users get each a /64, i.e. one single > subnet. >=20 > Spec-wise the IID len cant change, the Ethernet IID len cant change, the > DHCPv6 PD is not deployed, the operators only give a /64 to end user... > one is free to pick the reason, and again the end result is the same: no > growth at the edge. I have deployed DHCPv6 PD in my network, and use it all the time for mobile devices. Thanks - Fred > The archi document is free to recognize reality. If so, it should > recognize it so in a paragraph: no growth at the edges. >=20 > Alex >=20 > > But that's why the proposed text is limited to currently allocated > > unicast space - if we ever need to change this, it will be a new > > tranche of unicast space. In any case, this is nothing to do with > > progressing to full Standard. > > > > Brian > > > > -------------------------------------------------------------------- > > 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 Jan 19 14:59: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 5C6C3129657 for ; Thu, 19 Jan 2017 14:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 l6JrC_vn7V3A for ; Thu, 19 Jan 2017 14:59:09 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06C6129637 for ; Thu, 19 Jan 2017 14:59:08 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 1F42B1FCAB6; Thu, 19 Jan 2017 22:59:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CCDF9160071; Thu, 19 Jan 2017 22:59:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B5DDC160072; Thu, 19 Jan 2017 22:59:02 +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 7TuSigO9re07; Thu, 19 Jan 2017 22:59:02 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CB254160071; Thu, 19 Jan 2017 22:59:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 86EAD5FEF515; Fri, 20 Jan 2017 09:58:58 +1100 (EST) To: Alexandre Petrescu From: Mark Andrews References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <1798bf13-b031-8ffc-78ea-7d01c4756dc9@gmail.com> <696433c7-e9 76-c334-1b67-edcf9ee45bcc@gmail.com> Subject: Re: Updated IID length text In-reply-to: Your message of "Thu, 19 Jan 2017 22:57:13 +0100." <696433c7-e976-c334-1b67-edcf9ee45bcc@gmail.com> Date: Fri, 20 Jan 2017 09:58:58 +1100 Message-Id: <20170119225858.86EAD5FEF515@rock.dv.isc.org> Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 22:59:14 -0000 In message <696433c7-e976-c334-1b67-edcf9ee45bcc@gmail.com>, Alexandre Petrescu writes: > > > Le 19/01/2017 =E0 20:26, Brian E Carpenter a =E9crit : > > On 19/01/2017 22:26, Alexandre Petrescu wrote: ... > >> I do not agree with the part that says "IIDs are required be 64bit > >> long". > > > > But they are, today. In the move to full Standard, we cannot actually > > change that; we can only clarify the wording. > > > >> If IIDs are required to be 64bit long (even if only in the > >> 000-prefixed space) then the network can not grow at the edges, at > >> least not with SLAAC. > > > > That would be true if /64 prefixes were scarce. They are not. > > The mobile network operators today make it look as if the /64 > prefixes were scarce. > > Maybe they dont know these /64 are not scarce, or maybe they dont care > about scarcity (just as it's not IPv4 scarcity making them deploy IPv6). > The end result is the same: end users get each a /64, i.e. one single > subnet. > > Spec-wise the IID len cant change, the Ethernet IID len cant change, the > DHCPv6 PD is not deployed, the operators only give a /64 to end user... > one is free to pick the reason, and again the end result is the same: no > growth at the edge. > > The archi document is free to recognize reality. If so, it should > recognize it so in a paragraph: no growth at the edges. > > Alex >From https://getipv6.info/display/IPv6/3GPP+Mobile+Networks Release 10 introduced DHCPv6-PD to the standards. If you operator doesn't support 3GPP Release 10 complain to them. >From memory DHCP-PD and the early releases of 3GPP were happening at about the same time and 3GPP decided not to wait for DHCP-PD. Mark > > But that's why the proposed text is limited to currently allocated > > unicast space - if we ever need to change this, it will be a new > > tranche of unicast space. In any case, this is nothing to do with > > progressing to full Standard. > > > > 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 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jan 19 15:31: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 7A122129421 for ; Thu, 19 Jan 2017 15:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLZK7wiOym7V for ; Thu, 19 Jan 2017 15:31:20 -0800 (PST) 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 E28FF1293D6 for ; Thu, 19 Jan 2017 15:31:19 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 3938F9DD for ; Thu, 19 Jan 2017 23:31:19 +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 JMtPmb5M1gtI for ; Thu, 19 Jan 2017 17:31:19 -0600 (CST) Received: from mail-ua0-f198.google.com (mail-ua0-f198.google.com [209.85.217.198]) (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 01BEF983 for ; Thu, 19 Jan 2017 17:31:18 -0600 (CST) Received: by mail-ua0-f198.google.com with SMTP id i68so35322397uad.3 for ; Thu, 19 Jan 2017 15:31:17 -0800 (PST) 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=89G8cq6DhJDRzPzbQkLVHEfBUXT34h2mvxmi/4RxoIg=; b=LZCa6/NFtxaaPCIA5z7EEaD98t/Xd/jc3jsZlN93Hc0yKs7CdBFuZzsVmtDh69MRkU UWUwD9Eu6CG5WaQ9ebHG6itKn2oXflUp4BcI6trKEOXTOIJaSsfAiUNZViCcowN3alvq yH5GUhDV7+e+r6EMnRfvDPh+aPNHNtpuJ8JJlZYXXD1JaivwYKeQzP5lJEc5RnRYMVCw 7STx/SBCH6xbh9jiEGrZHB3RjvvRaFpY3xUf6PsRE3ZGtaAQGeAcM9RRXvmUTvD/ip6t zI95Nr2pxAmDulZye4HXDVIP4HJoJHfX7rPhBLNvMscb724jJRpZ3wLIy0ohMd9b6ENf oe7Q== 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=89G8cq6DhJDRzPzbQkLVHEfBUXT34h2mvxmi/4RxoIg=; b=D/EJlb805TWL65QdqCqOVtlfPWVo7FnbAkS0mt3ovj9eer7fhny5xdzOPC+UpIZt3d 4UY2ysnRxJch3cxEGSFclb0V/AncaBl/eO3DM2Fd53XwxgHpUqyovVbi2azRdvORgFu3 O0kOdqyCZ/BEDVlv597CGBgBM8KOir1wXQrYC8FOBNqpwCt0XSSsGi5Zz+k8uBnh9F5Y V8L6EVypMQY1uglcbtzW70tIJv2wMDHF4DJAmLPvN1WZ9Wuw4r0ZR6Bz46SgRDaOuDmI 2Y6L9fJMfw+uAguKmtuXvULFjCEmhmmrSSheroIsS1JBS6SOdZWbANzz2Vnfyi3XWne8 BNdg== X-Gm-Message-State: AIkVDXKHTfZ9R4/AuOi/Ge9xyIYROv9Js/TPtfzXo9RN1uca1FyIdrMufm3TD/+YOKfQvohi5Q4WD5Qe0zVw4uXkapZQHt2eGgcKry8C7nJudAnLuPruhyUgR3JDQ1ioh0NZfPIaEkpMYgCqAYY= X-Received: by 10.176.91.155 with SMTP id y27mr6391510uae.151.1484868677575; Thu, 19 Jan 2017 15:31:17 -0800 (PST) X-Received: by 10.176.91.155 with SMTP id y27mr6391504uae.151.1484868677403; Thu, 19 Jan 2017 15:31:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 19 Jan 2017 15:31:16 -0800 (PST) In-Reply-To: <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> From: David Farmer Date: Thu, 19 Jan 2017 17:31:16 -0600 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Ole Troan Content-Type: multipart/alternative; boundary=f403045f8ec80e455a05467aee2a Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 23:31:21 -0000 --f403045f8ec80e455a05467aee2a Content-Type: text/plain; charset=UTF-8 On Wed, Jan 18, 2017 at 7:08 AM, wrote: > > Given that what we are left with is policy, I think it is quite harsh of > you to declare that there is no consensus on the current text on the IETF > list. > There are good technical arguments for why each host needs more than a > single address, and if we end up in a situation similar to IPv4 where each > address used has to be justified, then we have lost. There is a justified > fear that allowing the 64 bit boundary to slide, we will end up in a > situation similar to IPv4 addressing. E.g. charging per address. > I'm a little worried that your fighting yesterday's battle. To be honest, I'm less worried about charing for more than one IP address. I'm much more worried about charging for more than one subnet. In fact, I'm worried a hard and inflexible boundary at /64 reinforces a model for charging for more than one subnet. If that happens would you prefer people use NTPv6 or NAT66? I'd prefer a more flexible subnet boundary, that allows the18 quadrillion addresses in a /64 to be broken into smaller subnets. Furthermore, we are talking about giving individual devices their own subnets. I like this model and with today's scale that will be fine. But, longer-term this has me worried, especially if we keep a inflexible /64 boundary. This is where the IETF has to perform a fine balancing act. On one side > ensure that the 64 bit boundary stands, at the other side ensure that all > implementors do not enshrine a hard-coded boundary in their implementations. > Ok, are you willing to put that in the document? The /64 requirement, is a political consideration, not a technical one. Because other than /64 subnets are clearly technically possible, we have evidence of it in RFC 7421. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403045f8ec80e455a05467aee2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 at 7:08 AM, <otroan@employees.org> wrote:
Given that what we are left with is policy, I think it is quite harsh of yo= u to declare that there is no consensus on the current text on the IETF lis= t.
There are good technical arguments for why each host needs more than a sing= le address, and if we end up in a situation similar to IPv4 where each addr= ess used has to be justified, then we have lost. There is a justified fear = that allowing the 64 bit boundary to slide, we will end up in a situation s= imilar to IPv4 addressing. E.g. charging per address.
=
I'm a little worried that your fighting yesterday's = battle.=C2=A0 To be honest, I'm less worried about charing for more tha= n one IP address. I'm much more worried about charging for more than on= e subnet. In fact, I'm worried a hard and inflexible boundary at /64 re= inforces a model for charging for more than one subnet.

If that happens would you prefer people use NTPv6 or NAT66?=C2=A0 I&#= 39;d prefer a more flexible subnet boundary, that allows the18 quadrillion = addresses in a /64 to be broken into smaller subnets.=C2=A0

<= /div>
Furthermore, we are talking about giving individual devices their= own subnets.=C2=A0 I like this model and with today's scale that will = be fine.=C2=A0 But, longer-term this has me worried, especially if we keep = a inflexible /64 boundary.=C2=A0

This is where the IETF has to perform a fine balancing act. On one side ens= ure that the 64 bit boundary stands, at the other side ensure that all impl= ementors do not enshrine a hard-coded boundary in their implementations.

Ok, are you willing to put that = in the document?=C2=A0 The /64 requirement, is a political consideration, n= ot a technical one.=C2=A0 Because other than /64 subnets are clearly techni= cally possible, we have evidence of it in RFC 7421.=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
Min= neapolis, 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
--f403045f8ec80e455a05467aee2a-- From nobody Thu Jan 19 17:23: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 9AADF12944D for ; Thu, 19 Jan 2017 17:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clh4yhS1NGbR for ; Thu, 19 Jan 2017 17:23:14 -0800 (PST) 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 3DF7612943C for ; Thu, 19 Jan 2017 17:23:14 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id e4so17740552pfg.1 for ; Thu, 19 Jan 2017 17:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IvS0euO+chtCuwczPm2OoLhy0JsBCMt7fB+KeDWAi0Y=; b=GIKHOMMZYqvgk+uif9+Q0RRJt0mTBk6tiLEzJwVxONuLeQ4nAvGVvn31r7b8dFhX+/ 2Parekzl3PtlBlV6zXLQIWkyCdW2r7/eSyTPMl1G1VD4si2w5QGcSe50CXd4MqUGOBuN FexvGJNRstQN1MRfyQRYOU4jTQNhW3IUNXmUe5QSqngPsT8Kyq5Gl2vIdlhJh+Nqstt0 MLkMLKdBHScBv1QGYLanr/+39wHh5XrnpZsXRCZb6cEFmNer/gkk4M28FPZ4Q/5rF70Z gW3Zz6cOHET9pXYI+1D3PhsrbCSBxbJzBiakLYgLjZ5nrd+Y+0LrmAKOLCDTWwr351vx UdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IvS0euO+chtCuwczPm2OoLhy0JsBCMt7fB+KeDWAi0Y=; b=rVxhCTpkGHowtuHazkKrlKLrwM2YmYFlqEC3GOCFw8k9RWbmIp3IoW23O+8YcGykfX puME6zoid7+3+KFiWdLfZcYWaz0MkA/+F1JMg/GQ+ApJ8/KwAKOVlo8E+1L+rMxayI7e MUe1qDFCN5V3W+8m37IbkcMxKQfupQ3WDLaenZyyJHpld8Ossn/4GLT4hURIdv3Tbo0E A7a4x8GyLnwIw0Yeeg1FUJ1oJeO8YE9xiu5SkXiR55QX6UN5LF4WaBJKlzjpF3wLVoiQ NIJhKSMuqIKii4DlpEVfKMm81d0pZFLelUC/lfQq35svSUhpULJieEk69DYs4v5KbHKm /kFg== X-Gm-Message-State: AIkVDXJZQ4yhcv9eXCJ09alJI85bewH5ErgZSKj6KHWvZKFefUNEiArwvGlpNo59n2nkZg== X-Received: by 10.98.10.69 with SMTP id s66mr13281944pfi.146.1484875393551; Thu, 19 Jan 2017 17:23:13 -0800 (PST) Received: from [192.168.178.21] (136.226.69.111.dynamic.snap.net.nz. [111.69.226.136]) by smtp.gmail.com with ESMTPSA id q5sm11574157pgf.45.2017.01.19.17.23.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 17:23:12 -0800 (PST) Subject: Re: Updated IID length text To: Peter Dordal , "Manfredi, Albert E" , 6man References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <28102f87f8e043248da16d9273d4c7d7@XCH15-06-11.nw.nos.boeing.com> <049d1ecb-3780-9109-41c2-4e61f738adaf@cs.luc.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Jan 2017 14:23:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <049d1ecb-3780-9109-41c2-4e61f738adaf@cs.luc.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 01:23:15 -0000 On 20/01/2017 10:43, Peter Dordal wrote: > On 01/19/2017 02:30 PM, Manfredi, Albert E wrote: >> Brian, I'm completely on board with your text below. I think that this should satisfy even the objections, by avoiding any "speculation." >> >> Bert >> NEW NEW >> IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, correct use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires all interfaces on a link to use the same length >> of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC, >> a consistent length of Interface ID is desirable. For this reason, the >> Interface ID of all currently allocated unicast addresses, except those that >> start with the binary value 000, is required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> > I intend no quarrel with this wording, and I think it is unfortunate > this 64 debate has come up again. > Say whatever needs to be said, and ship it. > > However, the text above states that SLAAC is *the* reason for 64-bit > IIDs. No, it says it's the reason for needing a *consistent* length of IID, that's all. As others have pointed out, we wouldn't pick e.g. 8, for other reasons including the ones you give. Brian > This is only > partly true: 64-bit IIDs also have security and privacy implications. > > Security, because an attacker can't realistically probe a site that uses > randomized > 64-bit IIDs. A site that uses /120 prefixes, on the other hand, is quite > exposed. > > Privacy, because creating temporary IIDs becomes harder and harder as > the number > of bits goes down. In the IPv4 world, privacy is one reason we have NAT. > > Peter Dordal > Loyola University Chicago CS Dept > . > From nobody Thu Jan 19 17:30: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 147CC12946F for ; Thu, 19 Jan 2017 17:30:14 -0800 (PST) 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 cNBNVs31jvCa for ; Thu, 19 Jan 2017 17:30:12 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05E91293F3 for ; Thu, 19 Jan 2017 17:30:12 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id 194so18678219pgd.2 for ; Thu, 19 Jan 2017 17:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=88ZWi24u6Rngflp0iU2ixJbK6WC/AGQu6jHFoXE2OLI=; b=L4Awl3gf26Mt4QE8SV3DDhlbRt+shj2gTST0pBM0N4aHgwxoVTWH0zGPuoTDIBYI6b Y2WTP0kZax1AjURju6bPTi/Dp+rgLIabPkR6ARafEzEH2ozlla/5otnSSy9GoX/ZiqGH A5os1nlZE8wv7geNPLp+nzfxDye3r3gHWxNVN86e8NaRHOC0NK1dC2Eevab6WTe7/tVt DlIDzZCT9+O60ULtHcmRYk9Sa95mubV2dd2geT/cuQcpOAXUawZtkVqkFRt5pTgUe+eD rp3anpDBuGAGb72NeFTndYbdKzFmteLMr0OyAUhWg/YzK+tBOTMT5VyXPZfjA7lWNdRx KGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=88ZWi24u6Rngflp0iU2ixJbK6WC/AGQu6jHFoXE2OLI=; b=a6tcqLH4GJFLCglSpZn0dZuXpD4Li6QjCNrnruOgDu44cGu6ntPliAG3gSEEXdJvrw nRNxdX4DinuGqO9Z+zBM2wfeTSrxPGs/qh/KmFdZD6vINNZMsEjcNdMjE5ITICrbi3gy 1ofjpmxNUZhBFT0qyvxgjtXmI3mDPFExCpAn1F7oP2CDt+Q6NonQpLmL7XtB3lXLGUEx t0B76aPLbo+5AtFbqoCrXERqGiaFMphHUafH1iwgPrt0WMMO2wSPqKPC4javZY/UUN5u jUIF9SKdSESbF0BD6U0jE2a1j0qm1bmFDUJ8go2GgVV532YBJQXSXKnx8xrbLGuEV/Lu iBkQ== X-Gm-Message-State: AIkVDXJ/wKLDAKV87M1YSGu8Zvi2mTE9+1ik/KYhrYdWqsm6PN3dyA65bCuEiyBL5J+JTw== X-Received: by 10.99.49.132 with SMTP id x126mr13580306pgx.92.1484875812367; Thu, 19 Jan 2017 17:30:12 -0800 (PST) Received: from ?IPv6:2406:e007:71eb:1:28cc:dc4c:9703:6781? ([2406:e007:71eb:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z18sm11543172pfi.83.2017.01.19.17.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 17:30:11 -0800 (PST) Subject: Re: Updated IID length text To: "Manfredi, Albert E" , "otroan@employees.org" References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com> Date: Fri, 20 Jan 2017 14:30:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 01:30:14 -0000 On 20/01/2017 10:02, Manfredi, Albert E wrote: >> -----Original Message----- >> From: otroan@employees.org [mailto:otroan@employees.org] >> >> Brian, >> >> [...] >> >>> NEW NEW >>> IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. >>> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >>> links. However, correct use of Stateless Address Autoconfiguration >>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same length >>> of Interface ID. Furthermore, to guarantee robust interoperability of >> SLAAC, >>> a consistent length of Interface ID is desirable. For this reason, the >>> Interface ID of all currently allocated unicast addresses, except those >> that >>> start with the binary value 000, is required to be 64 bits long. >> Background >>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> >> By changing "For all unicast addresses" to "all currently allocated unicast >> addresses", >> >> Are you proposing to reverse the decision that was made back when RFC3513 >> updated RFC2373? >> Change log: >> - Revised sections 2.4 and 2.5.6 >> to simplify and clarify how >> different address types are identified. This was done to insure >> that implementations do not build in any knowledge about global >> unicast format prefixes. Changes include: >> o Removed Format Prefix (FP) terminology >> o Revised list of address types to only include exceptions to >> global unicast and a singe entry that identifies everything >> else as Global Unicast. > > Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes." > > We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years. Indeed. I've taken out the explicit text that people objected to, but if another /3 is released to IANA and the RIRs, don't we want to keep our options open? Brian From nobody Thu Jan 19 17:47:43 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6B1294AA for ; Thu, 19 Jan 2017 17:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiaDWi0OO6Y6 for ; Thu, 19 Jan 2017 17:47:39 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 41DB41296DE for ; Thu, 19 Jan 2017 17:47:30 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id AC378B0D for ; Fri, 20 Jan 2017 01:47:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JljqsiG7A-n for ; Thu, 19 Jan 2017 19:47:29 -0600 (CST) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 78BCCA96 for ; Thu, 19 Jan 2017 19:47:29 -0600 (CST) Received: by mail-vk0-f69.google.com with SMTP id 78so35937703vkj.2 for ; Thu, 19 Jan 2017 17:47:29 -0800 (PST) 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=D4GT480DqXufTUqI9pPPQCZ62Ug+b7cWs4OmHw84I7U=; b=Vs5DoMonB/23PCSWPAmAriiD3nqeJ6+VLEtJPR2THVjLdMKT7tN6vGNv0pkRBgARc7 ibVBI/pzPxwZztSa7/susV8dQZ3e7BJ7vR0mt2axtvHm2t4Z41SQBJmb72IIseoBLLuB S/d4Xp5znuFj+kf42D45HulWTP7EGFGq1ejRMDV1r4fIjInXbIPwomHfgJVETLUK12AG anevrvXB0pqAiVVH/fpR+XgnVFruyXYMzspISxjgWBSME/ncLOU57htkFxK/cjOJN/cL S7/k1DQHvaZ4VHa1b9Mmrn3NS0PRpyNwAt172qzUavyIE/dpD+J4Jdx9EPh5l677XPYm GA1A== 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=D4GT480DqXufTUqI9pPPQCZ62Ug+b7cWs4OmHw84I7U=; b=kC9BMGJAtl2SftfZC9/jPseYgpbBBKPbBgDhgZ7F6VVCMzrG4kkNPf3GodyE3/Ah5d v4D/y/uFMJMF+RfRN9hiE0iFzZL2T1XXmxyvA9b7bYQa8y5LOoBJDRyQuEAmUma7okbz b8ztluAjGj8vYq6MLc1Mi17m6l1I8jPs3HaY1BXjOmXVbvKUvEZXeTGo9HbC36J1Yupi ewQX/Vx9krqaTx9H+EMC8A4Eh/3RbRm4tzi7xOH3RnQ3wSLjGvm3m99E2v3wVU7FVtRU ORONbR3KKAtsyUsRcWI3PhL5yosCw0NixNDfOKkCWXhC30KHaOUMsRxtqfP5q2lAkLZO iiNA== X-Gm-Message-State: AIkVDXK5mldY5QnFKD0aSUR/o9ku+B9cGl1BFkwmOX74ukpZHifD+psx0EI0QxsheH6EYttZ5hKS2lXlqfGbgWZiTPxgLT3Rcc/OIp1QZrMpULqAQh82yFOfQHm12OGGFMOHWNuwt2XzNX0m0/I= X-Received: by 10.31.192.204 with SMTP id q195mr5975139vkf.155.1484876848890; Thu, 19 Jan 2017 17:47:28 -0800 (PST) X-Received: by 10.31.192.204 with SMTP id q195mr5975136vkf.155.1484876848720; Thu, 19 Jan 2017 17:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 19 Jan 2017 17:47:28 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: David Farmer Date: Thu, 19 Jan 2017 19:47:28 -0600 Message-ID: Subject: Re: Updated IID length text To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a114388cc1a84ab05467cd5ac Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 01:47:41 -0000 --001a114388cc1a84ab05467cd5ac Content-Type: text/plain; charset=UTF-8 I liked the following in the previous version; Note that this value is an arbitrary choice and might be changed for some future allocation of unicast address space. What was the issue with it? Thanks On Wed, Jan 18, 2017 at 6:37 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > OK, after all that discussion, here is a revised proposal. There is > nothing new here at all, IMHO; just clarification: > > OLD > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. > > NEW > IPv6 routing is based on prefixes of any valid length up to 128 > [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, consistent use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires that all interfaces on a link use the same > length > of Interface ID. To guarantee interoperability of SLAAC, a fixed length > of > Interface ID is necessary. For all currently allocated unicast > addresses, > except those that start with the binary value 000, Interface IDs are > required to be 64 bits long. Background on the 64 bit boundary in IPv6 > addresses can be found in [RFC7421]. > > Regards > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- =============================================== 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 =============================================== --001a114388cc1a84ab05467cd5ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I liked the following in the previous version;=C2=A0
<= span style=3D"font-size:12.8px">
=C2=A0 =C2=A0Note that this value is an arbitrary=C2=A0<= span style=3D"font-size:12.8px">choice and might be changed for=C2=A0
=C2=A0 =C2=A0some future alloc= ation of unicast address=C2=A0space= .=C2=A0

=
What was the issue=C2=A0with it?

Thanks
On Wed, Jan 18, 2017 at 6:37 PM, Brian E Carpen= ter <brian.e.carpenter@gmail.com> wrote:
OK, after all that discussion, here is a revised p= roposal. There is
nothing new here at all, IMHO; just clarification:

OLD
=C2=A0 =C2=A0For all unicast addresses, except those that start with the bi= nary
=C2=A0 =C2=A0value 000, Interface IDs are required to be 64 bits long.=C2= =A0 Background
=C2=A0 =C2=A0on the 64 bit boundary in IPv6 addresses can be found in [RFC7= 421].

NEW
=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 12= 8 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127 bit prefixes on point-= to-point
=C2=A0 =C2=A0links. However, consistent use of Stateless Address Autoconfig= uration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires that all interfaces on a link use th= e same length
=C2=A0 =C2=A0of Interface ID. To guarantee interoperability of SLAAC, a fix= ed length of
=C2=A0 =C2=A0Interface ID is necessary. For all currently allocated unicast= addresses,
=C2=A0 =C2=A0except those that start with the binary value 000, Interface I= Ds are
=C2=A0 =C2=A0required to be 64 bits long.=C2=A0 Background on the 64 bit bo= undary in IPv6
=C2=A0 =C2=A0addresses can be found in [RFC7421].

Regards
=C2=A0 =C2=A0Brian

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



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--001a114388cc1a84ab05467cd5ac-- From nobody Thu Jan 19 18:41: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 0F87E1296EA for ; Thu, 19 Jan 2017 18:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZa-kFtPf6W2 for ; Thu, 19 Jan 2017 18:41:34 -0800 (PST) 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 5A1381296EC for ; Thu, 19 Jan 2017 18:41:34 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id f144so18315926pfa.2 for ; Thu, 19 Jan 2017 18:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ytYiZNKZT5yR4rSkI7w7f7oZv7vsMVCldj6xzQUWtZw=; b=SFt1ffTJM4lq/5BhpYSGSQ4cFkU7vpCMF47Wosm+RcLbAyMbbSAcoV9vbLJQ5t7AbY tnLBZnL8IaUYpo+CTDaLw+mu2rLmwDsD7XBFqmRiy0Cj7iHcFsFLUul+tPKAr0TJWNml XA5LBjDWE/eawGRZpnZOLPE02Y8X03lTVLx2d1QRvp+NFN7UqCyYZXg3OoSx+43vMROQ i52Ram8WcxIQEn8nlKHcbFXsYyIJqnnUot1TD6kEOPAh1Zdq7jV26QpKHmAg3wQfYaN2 INKZqvGhCMLkKYKTx1JmiovubR1bsnvPIagOJ14FEvPtSetAnnivAP7d2IAu8fgK8yHS /5Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ytYiZNKZT5yR4rSkI7w7f7oZv7vsMVCldj6xzQUWtZw=; b=gA1ko/6l+3a4tKkLYbuTg0N4WcwbOzTkNBRxswlT6vDIOdoa05knvLF509gKmWTMEn R5locCQMM7+zSvFvbVA3SXVpcQBX4T+iMEq+n3bYugFhyfT62pabJhg7fRBMQsc00YCr GiXkpwXPFoasH9jgOQE0ernAqlbiab9ABprW9+q4+BquZgHWyjokmEBzaBwOkjEkmGvs OjfRiRqvssEC/ALpCxiE+WhaAsAohuap1+Sjv4DdnqylqiExbNJeddZKcV7Zk6Rf5vYa 4tW4SkwlqmLMFbeRcq3O6pVytNb9M0NTRSM93NqdswmBhtTxK42d8Mmv/kIcG0h9ommt VLeg== X-Gm-Message-State: AIkVDXLiMN7sCw6CWGT97EYURH6GY9terKgabutCPbX54eTocqd1XAkJKJw4XxGVJ9ZjnA== X-Received: by 10.84.238.1 with SMTP id u1mr18324100plk.174.1484880093875; Thu, 19 Jan 2017 18:41:33 -0800 (PST) Received: from [192.168.178.21] ([118.148.73.115]) by smtp.gmail.com with ESMTPSA id d68sm11715355pfj.92.2017.01.19.18.41.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 18:41:33 -0800 (PST) Subject: Re: Updated IID length text To: David Farmer References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <09b333b0-9a13-83c9-c195-f8104d31ac46@gmail.com> Date: Fri, 20 Jan 2017 15:40:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 02:41:36 -0000 On 20/01/2017 14:47, David Farmer wrote: > I liked the following in the previous version; > > Note that this value is an arbitrary choice and might be changed for > some future allocation of unicast address space. > > What was the issue with it? I've lost track of who said what, but there was a lot of griping at the word 'arbitrary' and FUD about the 'might be changed.' Lif is compromise... Brian > > Thanks > > On Wed, Jan 18, 2017 at 6:37 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> OK, after all that discussion, here is a revised proposal. There is >> nothing new here at all, IMHO; just clarification: >> >> OLD >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >> >> NEW >> IPv6 routing is based on prefixes of any valid length up to 128 >> [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, consistent use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires that all interfaces on a link use the same >> length >> of Interface ID. To guarantee interoperability of SLAAC, a fixed length >> of >> Interface ID is necessary. For all currently allocated unicast >> addresses, >> except those that start with the binary value 000, Interface IDs are >> required to be 64 bits long. Background on the 64 bit boundary in IPv6 >> addresses can be found in [RFC7421]. >> >> Regards >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > From nobody Thu Jan 19 19:23: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 A1BE91293F0; Thu, 19 Jan 2017 19:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 AYmZwcstQMFl; Thu, 19 Jan 2017 19:23:56 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CB012952D; Thu, 19 Jan 2017 19:23:56 -0800 (PST) X-AuditID: c618062d-aa3ff70000007359-79-5881898c6e95 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id F9.AA.29529.C8981885; Fri, 20 Jan 2017 04:52:47 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 22:23:51 -0500 From: Suresh Krishnan To: Randy Bush Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 Thread-Topic: Review of draft-ietf-6man-rfc4291bis-06 Thread-Index: AQHSbWvuCqVNPHOS30iin7FZujn7XaE2VvuAgAAA2YCAAAG5gIABRfEAgAAF8QCAABLMgIAAIhKAgADVMoCAAoPNAIAAFQmAgAXJ4oA= Date: Fri, 20 Jan 2017 03:23:51 +0000 Message-ID: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: <29BB651301F42B4D9E9D844F4FF8C636@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyuXRPgm5/Z2OEwbllNhZb3+9js2i7uI/J 4umcr+wWn2/PY7do/b2c2eLZxvksFo+udLNYvDz7nsmi9dIfNoudR46yWzxrfcnkwO2xc9Zd do8Fm0o9liz5yeRxeeVrZo+pM2czelxd2MQewBbFZZOSmpNZllqkb5fAlbH080rWgns8FT/X XmRtYNzC08XIySEhYCLxp20bSxcjF4eQwHpGifXn10A5yxkl1n26wQhSxQZUtWHnZyYQW0RA TuLiiXeMIEXMAlOYJdY2n2YDSQgDFT2+vZAVoshUYuORM2wQdplEY/9MZhCbRUBV4mdTDzuI zStgL3Hq6gtmiG3X2SX+bfsCluAU0JJYuGYV2DZGATGJ76fWgNnMAuISt57MZ4K4W0BiyZ7z zBC2qMTLx/9YIWwliY+/5wPN4QCq15RYv0sfotVaYuazVVBjFCWmdD+EukFQ4uTMJywTGMVm IdkwC6F7FpLuWUi6ZyHpXsDIuoqRo7S4ICc33chgEyMwfo9JsOnuYLw/3fMQowAHoxIPb8GV hggh1sSy4srcQ4wSHMxKIrzTGhojhHhTEiurUovy44tKc1KLDzFKc7AoifPGrb4fLiSQnliS mp2aWpBaBJNl4uCUamDcJOC7uy2N0cou0MTtk5WmzgPfn2Gy3Hujnni/7bOS2dMtqBA8o3v6 kmTFw8vDMpzs9kyZLc8XtuG4WLTNi7ZJi0p414fEVTzPtv+eu63aoCvi6JVfE26abeKMv7X9 TpuApdW2oomvj0pe2XIvaaOmxLm3aSvEexNNJ7slFxqUnwnIipeuclNiKc5INNRiLipOBACS wrEo2wIAAA== Archived-At: Cc: 6man WG , IETF , "int-dir@ietf.org" , Robert Hinden , "draft-ietf-6man-rfc4291bis.all@ietf.org" , John C Klensin , Erik Kline X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 03:23:57 -0000 SGkgUmFuZHksDQoNCj4gT24gSmFuIDE2LCAyMDE3LCBhdCA1OjU5IEFNLCBSYW5keSBCdXNoIDxy YW5keUBwc2cuY29tPiB3cm90ZToNCj4gDQo+PiBTaW5jZSB0aGlzIGlzIChJSVJDKSBiZWluZyBk b25lIGZvciBTdGFuZGFyZHMgVHJhY2sgcHVycG9zZXMsIHRoZQ0KPj4gcHJpbWFyeSBnb2FsIGNy dWRlbHkgcGhyYXNlZCBpcyB0byBjb2xsYXBzZSB0aGUgZGlmZnMgYmV0d2VlbiB0aGUgYmFzZQ0K Pj4gZG9jdW1lbnQgYW5kIGFsbCB0aG9zZSB0aGF0IG1vZGlmeSBpdC4NCj4gDQo+IGkgYW0gbm90 IGEgZmFuIG9mIGluY29ycG9yYXRpbmcgdGhlIGNvbnRlbnQgZnJvbSBBIGludG8gQi4gIGlmIHlv dSBnZXQNCj4gaXQgd3JvbmdseSwgd2UgY2hhc2UgdGhlIGNvbmZ1c2lvbiBjYXVzZWQgYnkgdGhl IGNvbmZsaWN0KHMpIGZvcmV2ZXIuDQo+IGFuZCBpZiB5b3UgZ2V0IGl0IGNvcnJlY3RseSwgdGhl biB3aHkgdGhlIGhlY2sgbm90IGp1c3QgcmVmZXIgdG8gaXQ/DQo+IA0KPiB5bW12LCBvZiBjb3Vy c2UuDQo+IA0KPiBteSBpbXByZXNzaW9uIGlzIHRoYXQgdGhlIDZtYW4gY2hhaXIgYW5kIGRvY3Vt ZW50IGF1dGhvciAoYmVlcCkgaXMNCj4gdHJ5aW5nIHRvIHByb2R1Y2UgYSBzdG9uZSB0YWJsZXQg dG8gYmUgY2FycmllZCBkb3duIHRoZSBtb3VudGFpbi4gIHdoaWNoDQo+IGlzIHBhcnRpYWxseSB3 aHkgaSBhbSBiZWluZyBzdWNoIGEgYmxlZXAgYWJvdXQgZ2V0dGluZyBpdCBjb3JyZWN0Lg0KDQpZ b3Uga25vdyB0aGF0IEkgcmVzcGVjdCB5b3VyIG9waW5pb24sIGJ1dCBJIHRoaW5rIHRoaXMgY2hh cmFjdGVyaXphdGlvbiBpcyBpbmFwcHJvcHJpYXRlLiBCb2IgaGFzIG5vdCBiZWVuIGludm9sdmVk IGluIHRoZSBkZWNpc2lvbiBtYWtpbmcgZm9yIHRoaXMgZG9jdW1lbnQgYXMgY2hhaXIuIFRoZSB0 ZXh0IGluIHRoZSBkb2N1bWVudCB3YXMgdGhlIHJlc3VsdCBvZiA2bWFuIFdHIGNvbnNlbnN1cy4g SSBhbSBwZXJmZWN0bHkgZmluZSBpZiB0aGUgV0cgcmV2aXNpdHMgaXRzIGNvbnNlbnN1cyBhcyBh IHJlc3VsdCBvZiB0aGUgcG9pbnRzIHRoYXQgY2FtZSB1cCBkdXJpbmcgQnJpYW4gSC7igJlzIElO VCBkaXJlY3RvcmF0ZSByZXZpZXcgYnV0IHJlc3QgYXNzdXJlZCB0aGF0IHRoZXJlIGlzIG5vIG1v dW50YWluIGFuZCBubyBzdG9uZSB0YWJsZXRzLiANCg0KVGhhbmtzDQpTdXJlc2gNCg0K From nobody Thu Jan 19 19: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 3E0F6129781 for ; Thu, 19 Jan 2017 19:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 BxTnJY9jP-lm for ; Thu, 19 Jan 2017 19:30:27 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CABDD12973A for ; Thu, 19 Jan 2017 19:30:27 -0800 (PST) X-AuditID: c618062d-ab7ff70000007359-da-58818b14a470 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 01.CA.29529.41B81885; Fri, 20 Jan 2017 04:59:19 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 22:30:23 -0500 From: Suresh Krishnan To: Fernando Gont Subject: Re: IID length text Thread-Topic: IID length text Thread-Index: AQHScDcHu5IrnyDX5kaJ4tCyEtG8qqE75X8AgAABHYCAAAn3gIAADVUAgAUQfwA= Date: Fri, 20 Jan 2017 03:30:13 +0000 Message-ID: <17F049ED-B1F9-4B18-AC4C-658AB93A6861@ericsson.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <32121fe2-85d5-4849-d77d-edda5825d8e7@gmail.com> <525a97ff-4314-676a-3ee2-7f1fb6c3bf82@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_17F049EDB1F94B18AC4C658AB93A6861ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPgq54d2OEwalXWhYz3/1gtXiy6g2b xcuz75ksZveeZnFg8dg56y67x9MJB5k8liz5yeTx4VAPewBLFJdNSmpOZllqkb5dAlfGyb0X mAq2VldsXr+WvYGxq6KLkZNDQsBE4uvHO8xdjFwcQgLrGSXO3t7EAuEsZ5SY9qGRDaSKDahq w87PTCC2iICmxNznR8BsZoFKia67B5hBbGEBGYnb/Y/YIGpkJeZc+M0CYftJ7Jv5nRHEZhFQ lTjQ+Z4dxOYVsJc4/e0p2BwhgQ0cEq/2uoLYnALOEn2n97OC2IwCYhLfT62B2iUucevJfCaI qwUkluw5zwxhi0q8fPyPFcJWkvj4ez7QfA6g+mSJ68f9IFYJSpyc+YRlAqPILCSTZiFUzUJS BRHWlFi/Sx+iWlFiSvdDdghbQ6J1zlwo21pi64WFTMhqFjByrGLkKC0uyMlNNzLYxAiMvGMS bLo7GO9P9zzEKMDBqMTDW3ClIUKINbGsuDL3EKMEB7OSCO+0hsYIId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rxxq++HCwmkJ5akZqemFqQWwWSZODilGhhDvI6ZuBbdCv7GIbsh4PPN1C0sEjxq m7NmfFpxKGPX3KDiTyXrE/WbrXZs9jJZFe7NUxcYzclq9ePG1unKCVEsCqmr8n1F2S3E844w zJ278cmNM2wfzmS5zf+s2RQ6e9a9199vCy/9Fzfnwz/np+dmPCn9dvZpZ856qY8tU0Nv/Q9x rD8mMYdFiaU4I9FQi7moOBEAjoptWrgCAAA= Archived-At: Cc: 6man WG , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 03:30:29 -0000 --_000_17F049EDB1F94B18AC4C658AB93A6861ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRmVybmFuZG8sDQoNCk9uIEphbiAxNiwgMjAxNywgYXQgNTowOSBQTSwgRmVybmFuZG8gR29u dCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+PiB3 cm90ZToNCg0KT24gMDEvMTYvMjAxNyAwNjoyMiBQTSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOg0K T24gTW9uLCBKYW4gMTYsIDIwMTcgYXQgMjo0NiBQTSwgRmVybmFuZG8gR29udCA8ZmdvbnRAc2k2 bmV0d29ya3MuY29tPG1haWx0bzpmZ29udEBzaTZuZXR3b3Jrcy5jb20+PiB3cm90ZToNCk9uIDAx LzE2LzIwMTcgMDU6NDIgUE0sIEJlaGNldCBTYXJpa2F5YSB3cm90ZToNCk9uIE1vbiwgSmFuIDE2 LCAyMDE3IGF0IDI6MjcgUE0sIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPGFsZXhhbmRydS5wZXRyZXNj dUBnbWFpbC5jb208bWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+PiB3cm90ZToN CkxlIDE0LzAxLzIwMTcgw6AgMjA6NDksIEJyaWFuIEUgQ2FycGVudGVyIGEgw6ljcml0IDoNCg0K QSBtb2Rlc3Qgc3VnZ2VzdGlvbjoNCg0KT0xEDQogIEZvciBhbGwgdW5pY2FzdCBhZGRyZXNzZXMs IGV4Y2VwdCB0aG9zZSB0aGF0IHN0YXJ0IHdpdGggdGhlIGJpbmFyeQ0KICB2YWx1ZSAwMDAsIElu dGVyZmFjZSBJRHMgYXJlIHJlcXVpcmVkIHRvIGJlIDY0IGJpdHMgbG9uZy4gIEJhY2tncm91bmQN CiAgb24gdGhlIDY0IGJpdCBib3VuZGFyeSBpbiBJUHY2IGFkZHJlc3NlcyBjYW4gYmUgZm91bmQg aW4gW1JGQzc0MjFdLg0KDQpORVcNCiAgSVB2NiByb3V0aW5nIGlzIGJhc2VkIG9uIHByZWZpeGVz IG9mIGFueSB2YWxpZCBsZW5ndGggdXAgdG8gMTI4DQpbQkNQMTk4XS4NCiAgRm9yIGV4YW1wbGUs IFtSRkM2MTY0XSBzdGFuZGFyZGlzZXMgMTI3IGJpdCAgcHJlZml4ZXMgb24gcG9pbnQtdG8tcG9p bnQNCiAgbGlua3MuIEhvd2V2ZXIsIGNvbnNpc3RlbnQgdXNlIG9mIFN0YXRlbGVzcyBBZGRyZXNz IEF1dG9jb25maWd1cmF0aW9uDQogIChTTEFBQylbUkZDNDg2Ml0gcmVxdWlyZXMgdGhhdCBhbGwg aW50ZXJmYWNlcyBvbiBhIGxpbmsgdXNlIHRoZSBzYW1lDQpsZW5ndGgNCiAgb2YgSW50ZXJmYWNl IElELiBJbiBwcmFjdGljZSwgdGhpcyBtZWFucyB0aGF0IHRvIGd1YXJhbnRlZQ0KaW50ZXJvcGVy YWJpbGl0eQ0KICBvZiBTTEFBQywgYSBmaXhlZCBsZW5ndGggb2YgSW50ZXJmYWNlIElEIGlzIG5l Y2Vzc2FyeS4gRm9yIGFsbA0KY3VycmVudGx5DQogIGFsbG9jYXRlZCB1bmljYXN0IGFkZHJlc3Nl cywgZXhjZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0aCB0aGUgYmluYXJ5DQogIHZhbHVlIDAwMCwg dGhhdCBsZW5ndGggaXMgNjQgYml0cy4gTm90ZSB0aGF0IHRoaXMgdmFsdWUgaXMgYW4gYXJiaXRy YXJ5DQogIGNob2ljZSBhbmQgbWlnaHQgYmUgY2hhbmdlZCBmb3Igc29tZSBmdXR1cmUgYWxsb2Nh dGlvbiBvZiB1bmljYXN0DQphZGRyZXNzDQogIHNwYWNlLiBCYWNrZ3JvdW5kIG9uIHRoZSA2NCBi aXQgYm91bmRhcnkgaW4gSVB2NiBhZGRyZXNzZXMgY2FuIGJlIGZvdW5kDQogIGluIFtSRkM3NDIx XS4NCg0KDQpJIGFncmVlIHdpdGggdGhlIGNoYW5nZSBzdWdnZXN0aW9uLiAgVGhlIG5ldyB0ZXh0 IGFuZCByZWZlcmVuY2VzIGFyZSBlbm91Z2gNCm1vdGl2YXRpb24gdG8gY2xhcmlmeSB0aGF0IHRo YXQgNjRiaXQgbGltaXQgaXMgYW4gYXJiaXRyYXJ5IGNob2ljZSBhbmQgbWlnaHQNCmNoYW5nZSBp biB0aGUgZnV0dXJlLg0KDQoNCjNHUFAgYXNzaWducyA2NCBiaXQgcHJlZml4ZXMgdG8gZWFjaCBV RS4NCkV4dGVuZGVkIFVuaXF1ZSBJZGVudGlmaWVycyBkZWZpbmVkIGFyZSBFVUktNDggYW5kIEVV SS02NC4NCg0KV2hhdCBkb2VzIGEgbGF5ZXItMiBFVUkgaGF2ZSB0byBkbyB3aXRoIGEgbGF5ZXIt MyBhZGRyZXNzPw0KDQpJIGRvbid0IGtub3csIHlvdSB0ZWxsIG1lIDotKQ0KDQpBbnN3ZXI6IE5v dGhpbmcuIFRoZSBmYWN0IHRoYXQgd2UndmUgYmVlbiBlbWJlZGRpbmcgbGF5ZXItMiAiYWRkcmVz c2VzIg0KaW50byBsYXllci0zIGFkZHJlc3NlcyBzaG91bGQgbm90IGJlIHRha2VuIGFzIGEgcmVh c29uIGZvciB0aGUgdHdvIG9mDQp0aGVtIG9mIGhhdmluZyB0byBkbyBhbnl0aGluZyB3aXRoIGVh Y2ggb3RoZXIuIFNvLCB5ZXMsIHRoZSA2NC1iaXQgSUlEDQpsZW5ndGggaXMsIGluIHJlYWxpdHks IGFyYml0cmFyeS4gVGhleSBjb3VsZCBoYXZlIGJlZW4gZS5nLiAzMi1iaXRzIG9yDQo0OC1iaXRz ICh5ZXMsIG11bHRpcGxlcyBvciA2NCBvciAzMiB0ZW5kIHRvIGJlIG5pY2VyKQ0KDQpLaW5kIG9m IGFncmVlIGJ1dCBub3QgZW50aXJlbHkuIFRoZXJlIGFyZSBzb21lIHByb3RvY29scyBpbiB0aGUg Y29uc3RyYWluZWQgc3BhY2UgdGhhdCBkZXBlbmQgb24gc29tZSBmb3JtIG9mIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIGFuIEwyIGFkZHJlc3MgYW5kIHRoZSBMMyBJUHY2IGFkZHJlc3MgdG8gYWNoaWV2 ZSBjb21wcmVzc2lvbi4NCg0KVGhhbmtzDQpTdXJlc2gNCg0K --_000_17F049EDB1F94B18AC4C658AB93A6861ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0180E3805003204A9AE09A1872904EB7@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgRmVybmFuZG8sDQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSmFuIDE2LCAyMDE3LCBhdCA1OjA5IFBNLCBGZXJuYW5k byBHb250ICZsdDs8YSBocmVmPSJtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tIiBjbGFzcz0i Ij5mZ29udEBzaTZuZXR3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0i QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pk9uDQogMDEvMTYvMjAxNyAwNjoyMiBQTSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOjwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpP biBNb24sIEphbiAxNiwgMjAxNyBhdCAyOjQ2IFBNLCBGZXJuYW5kbyBHb250ICZsdDs8YSBocmVm PSJtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tIiBjbGFzcz0iIj5mZ29udEBzaTZuZXR3b3Jr cy5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5PbiAwMS8xNi8yMDE3IDA1OjQyIFBNLCBCZWhjZXQgU2FyaWtheWEgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gTW9uLCBK YW4gMTYsIDIwMTcgYXQgMjoyNyBQTSwgQWxleGFuZHJlIFBldHJlc2N1PGJyIGNsYXNzPSIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tIiBjbGFzcz0i Ij5hbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+TGUgMTQvMDEvMjAxNyDDoCAyMDo0 OSwgQnJpYW4gRSBDYXJwZW50ZXIgYSDDqWNyaXQgOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkEgbW9kZXN0IHN1Z2dlc3Rpb246 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT0xEPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Rm9yIGFsbCB1bmljYXN0IGFkZHJlc3NlcywgZXhjZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0 aCB0aGUgYmluYXJ5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dmFsdWUgMDAwLCBJbnRlcmZh Y2UgSURzIGFyZSByZXF1aXJlZCB0byBiZSA2NCBiaXRzIGxvbmcuICZuYnNwO0JhY2tncm91bmQ8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtvbiB0aGUgNjQgYml0IGJvdW5kYXJ5IGluIElQdjYg YWRkcmVzc2VzIGNhbiBiZSBmb3VuZCBpbiBbUkZDNzQyMV0uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KTkVXPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7SVB2NiByb3V0aW5nIGlzIGJh c2VkIG9uIHByZWZpeGVzIG9mIGFueSB2YWxpZCBsZW5ndGggdXAgdG8gMTI4PGJyIGNsYXNzPSIi Pg0KW0JDUDE5OF0uPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Rm9yIGV4YW1wbGUsIFtSRkM2 MTY0XSBzdGFuZGFyZGlzZXMgMTI3IGJpdCAmbmJzcDtwcmVmaXhlcyBvbiBwb2ludC10by1wb2lu dDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2xpbmtzLiBIb3dldmVyLCBjb25zaXN0ZW50IHVz ZSBvZiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyhTTEFBQylbUkZDNDg2Ml0gcmVxdWlyZXMgdGhhdCBhbGwgaW50ZXJmYWNlcyBv biBhIGxpbmsgdXNlIHRoZSBzYW1lPGJyIGNsYXNzPSIiPg0KbGVuZ3RoPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7b2YgSW50ZXJmYWNlIElELiBJbiBwcmFjdGljZSwgdGhpcyBtZWFucyB0aGF0 IHRvIGd1YXJhbnRlZTxiciBjbGFzcz0iIj4NCmludGVyb3BlcmFiaWxpdHk8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtvZiBTTEFBQywgYSBmaXhlZCBsZW5ndGggb2YgSW50ZXJmYWNlIElEIGlz IG5lY2Vzc2FyeS4gRm9yIGFsbDxiciBjbGFzcz0iIj4NCmN1cnJlbnRseTxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwO2FsbG9jYXRlZCB1bmljYXN0IGFkZHJlc3NlcywgZXhjZXB0IHRob3NlIHRo YXQgc3RhcnQgd2l0aCB0aGUgYmluYXJ5PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7dmFsdWUg MDAwLCB0aGF0IGxlbmd0aCBpcyA2NCBiaXRzLiBOb3RlIHRoYXQgdGhpcyB2YWx1ZSBpcyBhbiBh cmJpdHJhcnk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtjaG9pY2UgYW5kIG1pZ2h0IGJlIGNo YW5nZWQgZm9yIHNvbWUgZnV0dXJlIGFsbG9jYXRpb24gb2YgdW5pY2FzdDxiciBjbGFzcz0iIj4N CmFkZHJlc3M8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzcGFjZS4gQmFja2dyb3VuZCBvbiB0 aGUgNjQgYml0IGJvdW5kYXJ5IGluIElQdjYgYWRkcmVzc2VzIGNhbiBiZSBmb3VuZDxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwO2luIFtSRkM3NDIxXS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFncmVlIHdpdGggdGhlIGNoYW5n ZSBzdWdnZXN0aW9uLiAmbmJzcDtUaGUgbmV3IHRleHQgYW5kIHJlZmVyZW5jZXMgYXJlIGVub3Vn aDxiciBjbGFzcz0iIj4NCm1vdGl2YXRpb24gdG8gY2xhcmlmeSB0aGF0IHRoYXQgNjRiaXQgbGlt aXQgaXMgYW4gYXJiaXRyYXJ5IGNob2ljZSBhbmQgbWlnaHQ8YnIgY2xhc3M9IiI+DQpjaGFuZ2Ug aW4gdGhlIGZ1dHVyZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQozR1BQIGFzc2lnbnMgNjQgYml0IHByZWZpeGVzIHRvIGVhY2ggVUUu PGJyIGNsYXNzPSIiPg0KRXh0ZW5kZWQgVW5pcXVlIElkZW50aWZpZXJzIGRlZmluZWQgYXJlIEVV SS00OCBhbmQgRVVJLTY0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0i Ij4NCldoYXQgZG9lcyBhIGxheWVyLTIgRVVJIGhhdmUgdG8gZG8gd2l0aCBhIGxheWVyLTMgYWRk cmVzcz88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIGRvbid0 IGtub3csIHlvdSB0ZWxsIG1lIDotKTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5BbnN3ZXI6DQogTm90aGlu Zy4gVGhlIGZhY3QgdGhhdCB3ZSd2ZSBiZWVuIGVtYmVkZGluZyBsYXllci0yICZxdW90O2FkZHJl c3NlcyZxdW90Ozwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+aW50bw0KIGxheWVyLTMgYWRkcmVzc2VzIHNob3VsZCBub3QgYmUgdGFrZW4gYXMgYSBy ZWFzb24gZm9yIHRoZSB0d28gb2Y8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPnRoZW0NCiBvZiBoYXZpbmcgdG8gZG8gYW55dGhpbmcgd2l0aCBlYWNo IG90aGVyLiBTbywgeWVzLCB0aGUgNjQtYml0IElJRDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+bGVuZ3RoDQogaXMsIGluIHJlYWxpdHksIGFyYml0 cmFyeS4gVGhleSBjb3VsZCBoYXZlIGJlZW4gZS5nLiAzMi1iaXRzIG9yPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj40OC1iaXRzDQogKHllcywgbXVs dGlwbGVzIG9yIDY0IG9yIDMyIHRlbmQgdG8gYmUgbmljZXIpPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQpLaW5kIG9mIGFncmVlIGJ1dCBub3QgZW50aXJlbHkuIFRoZXJlIGFyZSBzb21l IHByb3RvY29scyBpbiB0aGUgY29uc3RyYWluZWQgc3BhY2UgdGhhdCBkZXBlbmQgb24gc29tZSBm b3JtIG9mIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGFuIEwyIGFkZHJlc3MgYW5kIHRoZSBMMyBJUHY2 IGFkZHJlc3MgdG8gYWNoaWV2ZSBjb21wcmVzc2lvbi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzPC9kaXY+DQo8ZGl2PlN1cmVzaDwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_17F049EDB1F94B18AC4C658AB93A6861ericssoncom_-- From nobody Thu Jan 19 20:08: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 3D9F51297CE for ; Thu, 19 Jan 2017 20:08:23 -0800 (PST) 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 yYCwZnpJ8Ttm for ; Thu, 19 Jan 2017 20:08:22 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EB91297AA for ; Thu, 19 Jan 2017 20:08:22 -0800 (PST) X-AuditID: c6180641-e73ff70000000a0b-71-588138c6ada6 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 00.C3.02571.6C831885; Thu, 19 Jan 2017 23:08:10 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 23:08:17 -0500 From: Suresh Krishnan To: Brian E Carpenter Subject: Re: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexTEphs/8uw7UCjlzAHkgGpaKE/bE4AgAACpICAAAf0gIABERyAgACNnwA= Date: Fri, 20 Jan 2017 04:08:17 +0000 Message-ID: <453DEC8C-F825-40E3-8F7F-EFDEF372C4FD@ericsson.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@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-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <75D20DB621CA144A85A3FC38475BD286@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonVveURWOEwc0WIYveNRvYLNou7mOy eHn2PZMDs8fvg2+YPXbOusvusWTJT6YA5igum5TUnMyy1CJ9uwSujKctdxkLrrBW7D98hKWB 8QBrFyMnh4SAicSn45eYuhi5OIQE1jNKbHy6mxnCWc4o8ffCRrAqNqCqDTs/M4HYIgLGEo1d p4HiHBzMAkESD+aDlQgLqEh8XX+bHaJEVeLQrVYmkBIRAT+JL8cNQMIsQOE/uxsYQWxeAXuJ TQsnsEGs2sMhcffpQbAEp4CtROuy32wgNqOAmMT3U2vA1jILiEvcejKfCeJoAYkle84zQ9ii Ei8f/4N6RklizutrzBCnaUqs36UP0WotsXdCD9QYRYkp3Q/ZIW4QlDg58wnLBEaxWUg2zELo noWkexaS7llIuhcwsq5i5CgtLsjJTTcy3MQIjKZjEmyOOxj39noeYhTgYFTi4TWY0xAhxJpY VlyZe4hRgoNZSYR3WkNjhBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe6yH3w4UE0hNLUrNTUwtS i2CyTBycUg2Muctk/xw5Ynrnp+D6TR2nUqWFX77lz9GMDD0Zcf6BQaTjIV7G5j0PtLUyxPfE hPJ7Gyaa+HGkrjfKdT1V6LGraVJbpe31V37qXldVL2k5OXnMi4s+2i+i+urfLEFtNWmf19Iq 37pvuK/MWvCp5s/9Ky2HOjKrLzOyb2CpP1L1bGpTp8v846ZKLMUZiYZazEXFiQCRc+uMogIA AA== Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 04:08:23 -0000 SGkgQnJpYW4sDQoNCj4gSG93ZXZlciwgY29ycmVjdCB1c2Ugb2YgU3RhdGVsZXNzIEFkZHJlc3Mg QXV0b2NvbmZpZ3VyYXRpb24NCj4gICAoU0xBQUMpW1JGQzQ4NjJdIHJlcXVpcmVzIGFsbCBpbnRl cmZhY2VzIG9uIGEgbGluayB0byB1c2UgdGhlIHNhbWUgbGVuZ3RoDQo+ICAgb2YgSW50ZXJmYWNl IElELg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyB0cnVlLiBTTEFBQyBvbmx5IHJlcXVpcmVz IHRoYXQgdGhlIHByZWZpeCBsZW5ndGggYW5kIElJRCBsZW5ndGggYWRkIHVwIHRvIDEyOC4gU28s IHdlIGNhbiBhZHZlcnRpc2UgZGlmZmVyZW50IHByZWZpeGVzICh3aXRoIGRpZmZlcmVudCBsZW5n dGhzKSBvbiBhIGxpbmsgdG8gc3VwcG9ydCBkaWZmZXJlbnQgSUlEIGxlbmd0aHMuIFdlIG5ldmVy IGRpZCBiZWNhdXNlIGJvdGggdGhlIHByZWZpeCBsZW5ndGggYW5kIHRoZSBJSUQgbGVuZ3RoIGhh dmUgYmVlbiA2NCBiaXQgbG9uZyBpbiB0aGUgbW9zdCBwcmV2YWxlbnQgY2FzZXMuDQoNClRoYW5r cw0KU3VyZXNoDQoNCg== From nobody Thu Jan 19 20:39: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 1C6101297F1 for ; Thu, 19 Jan 2017 20:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 iKXCP4r8Dc93 for ; Thu, 19 Jan 2017 20:39:17 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 B80151297EF for ; Thu, 19 Jan 2017 20:39:17 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id y9so52811074uae.2 for ; Thu, 19 Jan 2017 20:39:17 -0800 (PST) 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=ozNlCXHdsztf/sliMpImuHjdok+SCxLitqRoysODjYE=; b=IgMWMw7Jd2RH6z4livEHSb2eUP1i2jEeQ8nBbcKLpYn2fqVvUM2nAIM9YTKzS9vFcW B5Jnko7QYIHn7dzDvBH6q7J30DVH2ZPPOxWb9om8WNpPdgUl9Ce0U4YtjnFkIT53B8I6 53yFrM6y7tGRSWDGDM5XwzzUzKhjPKThXYWSzTEXfTFXrzMp1kJLhixtz+6tJcAz8K64 xkzpPBOt8A962BkFmnoT5eayRAz0C83yWcUhu5RIIzA9YoC7w7B6J//zyQtMPWNrknWh 5z9rQATf3BnEYi2h26K+4nkXtjWuJzXaYEH608CpN/d5hs37Z/aPuPnzp8Wxx5v7T+1r KBWg== 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=ozNlCXHdsztf/sliMpImuHjdok+SCxLitqRoysODjYE=; b=RlSgfL9rd4sJM9fFVzRX+a95thg4V9H+ybqeMLJc2pVkuPvL1x5KBCIoCm2SJ2aSS1 Kd6TuPYkcmoFCzFRJb2MoYYxkQRhVKVsTatvs150n2HW9dyXpgGd3g4W13SvQvSKTdDf 5IgtWqKsXeppA78bKLqoU9Ur3EGbBydZNKb+AKEIMmVI7KBSJpZAedXUgA7a1+RC20M/ VHbYHXNT1kA91AngnfnYuZgEseW1Bu3sOUdRyZjsBUfc4IfbWXU+M9wVq7RIV785RtkI +WwMUTryMHhjLtoZ47zS2LGfubY9iH4dcvfQnAdAvKLGIVa2FrOCRA+rb4iNpwopPk04 s9Zw== X-Gm-Message-State: AIkVDXKNnUFHFs1y31S1zydJEX7HDGJRazAsOXvOkPNRXJvuAIZ9o5ddml4Tc8lzpMHiTNgj/d1OQ8ZYQu3daj/1 X-Received: by 10.159.41.198 with SMTP id s64mr6812167uas.72.1484887156645; Thu, 19 Jan 2017 20:39:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 20:38:55 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 13:38:55 +0900 Message-ID: Subject: Re: Updated IID length text To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1148d93a814adf05467f3b29 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 04:39:19 -0000 --001a1148d93a814adf05467f3b29 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > However, correct use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires all interfaces on a link to use the same > length > of Interface ID. Furthermore, to guarantee robust interoperability of > SLAAC, > a consistent length of Interface ID is desirable. For this reason, I object to the text "for this reason", because SLAAC is not the only reason. There are many reasons, many of which are written in 7421, and two sentences in this paragraph are not sufficient to describe them. I propose the following alternative, which I believe to be normatively identical: IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes on point-to-point links. However, the Interface ID of all currently allocated unicast addresses, except those that start with the binary value 000, is required to be 64 bits long. The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Cheers, Lorenzo --001a1148d93a814adf05467f3b29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
However, correct use of Stateless Address Autoconfiguration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires all interface= s on a link to use the same length
=C2=A0 =C2=A0of Interface ID. Furthermore, to guarantee robust interoperabi= lity of SLAAC,
=C2=A0 =C2=A0a consistent length of Interface ID is desirable. For t= his reason,

I object to the text "for = this reason", because SLAAC is not the only reason. There are many rea= sons, many of which are written in 7421, and two sentences in this paragrap= h are not sufficient to describe them. I propose the following alternative,= which I believe to be normatively identical:

=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 1= 28 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127= bit prefixes on point-to-point
=C2=A0 =C2=A0links. However, the = Interface ID of all currently allocated unicast addresses,
=C2=A0= =C2=A0except those that start with the binary value 000, is required to be= 64 bits
=C2=A0 =C2=A0long. The rationale for the 64 bit boundary= in IPv6 addresses can be found in
=C2=A0 =C2=A0[RFC7421].
<= div>
Cheers,
Lorenzo
--001a1148d93a814adf05467f3b29-- From nobody Thu Jan 19 20:42: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 1D46E1297EB for ; Thu, 19 Jan 2017 20:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvgg8LUoydXZ for ; Thu, 19 Jan 2017 20:42:49 -0800 (PST) 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 17155129443 for ; Thu, 19 Jan 2017 20:42:49 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 189so19204473pfu.3 for ; Thu, 19 Jan 2017 20:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GEFRubvm3lEnlQauzALXpGqSSr+4aHlXX4LScKIkECU=; b=jWmwBCYuhtEN4eobsdboxGljv3ScNO8sc380QeBBIQGJNdopYPkPd6X8HWJscwVnnQ O4J0Xw4T4j0ujnX2BwYHvHTqURgJRZo4IzDHxFW6dWctHkmlHsOFjhncKyb/qFrvzi0j CHYHQDicKDyTmb+7GoqqhOv0vgCF7ttmwtriqziFvlCWe2XrnA9t3SEL14LIDBIrQOdV R7VGJv71ReGPYEmT3RgZTa5N05SArKIHdJuNoiRODhbHo0ZgHZXzVzd7BWV6WI2TYvF7 xZg5LEU3h/zHqijnrxbBWGZGAk5c9/Y9uSegBz7kOERIao/Xp4Pq+pVq0MjtQc9i2g1W 4nBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GEFRubvm3lEnlQauzALXpGqSSr+4aHlXX4LScKIkECU=; b=GKbl294LMm+5ZeFZzZPSqDxUWqijSUksQNUvu4X7QCvi0gnM8dTgt37c7A6EPBBCy9 uN0NqNtRL7tMIiTFSLLl7SS4CyA6BBX54vtiwru0sxk2l1N+79n6Yx4C79i0iDKx2pvm s1RBzErgAkr7nm6bkdmfPBC/RsrE4NrgJGUQubbUA9j+lvxfmmixkLyXZtPEHvetYKln NNxoAyCxRKE1RrBQbMd6C/8589X4Lq/TzD6CERC3CkShSPXlIzOF4i4H2jCl9Xp2VuFS oEt4IehpapdN731TtWX8ka4Lf2wwc3chb2DUf60I3ABH1mk8JgrHbeLPK+eAf8wQCZSq h4+Q== X-Gm-Message-State: AIkVDXKN/ZL4Cyik7Gua1V41YqjNUTKlhzwlzyXqfJbomUR7OV9In0GPrS9EsMQI15YdcA== X-Received: by 10.98.19.12 with SMTP id b12mr14105159pfj.150.1484887368612; Thu, 19 Jan 2017 20:42:48 -0800 (PST) Received: from ?IPv6:2406:e007:4482:1:28cc:dc4c:9703:6781? ([2406:e007:4482:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h17sm12368190pfh.62.2017.01.19.20.42.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 20:42:47 -0800 (PST) Subject: Re: Updated IID length text To: Suresh Krishnan References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <453DEC8C-F825-40E3-8F7F-EFDEF372C4FD@ericsson.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <41aefbce-ead5-8800-bd66-0bbfe0bd6481@gmail.com> Date: Fri, 20 Jan 2017 17:42:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <453DEC8C-F825-40E3-8F7F-EFDEF372C4FD@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 04:42:50 -0000 On 20/01/2017 17:08, Suresh Krishnan wrote: > Hi Brian, >=20 >> However, correct use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires all interfaces on a link to use the same l= ength >> of Interface ID. >=20 > I don=E2=80=99t think this is true. SLAAC only requires that the prefix= length and IID length add up to 128. So, we can advertise different pref= ixes (with different lengths) on a link to support different IID lengths.= We never did because both the prefix length and the IID length have been= 64 bit long in the most prevalent cases. Technically, yes, but I doubt if much current code would work that way. I agree that the sentence needs that addition. Thanks Brian From nobody Thu Jan 19 21:25: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 C46B912989C for ; Thu, 19 Jan 2017 21:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoYP3bKqlHL6 for ; Thu, 19 Jan 2017 21:25:42 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 2574A129890 for ; Thu, 19 Jan 2017 21:25:42 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 9DCE87B6 for ; Fri, 20 Jan 2017 05:25:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6O_HCDiXNZj for ; Thu, 19 Jan 2017 23:25:41 -0600 (CST) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 662CC6CB for ; Thu, 19 Jan 2017 23:25:41 -0600 (CST) Received: by mail-ua0-f199.google.com with SMTP id 7so38889392uas.6 for ; Thu, 19 Jan 2017 21:25:41 -0800 (PST) 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=gJyWlwVxHu0QQUmKZQk/jwM09xhT0sTvGzhcKrryG+Y=; b=FKUl3z3d8/n583vvPVx/X9qWhouVLGw0Jp2uBiGlEd/OPwIDDh/bw9QQsuG+M9K4Cn tGjOqhiNgRlsVegZVxqdiS670CUa1qw3iepSPLr7yYmedAEOW3X850S2VFWOR5dd6032 5us2qzuQyVpL6Z/wKA24pjhllz4G0ifb7pLy3lvcgtB6zmovgetFIslLPPRmuCguynTC PwwLrV57tZoY6JQ5JDZ8+CfsYAagPv+1pQLe+iOAcnK6mW2yUoQHi/vu2Dg2egRxGtpQ r6G/9P6fTeW2HmY11cVHw9PeBzJHyQC5gxBefbLSY8fCklRECHZ4WzptNUKs3L2atzuZ R0/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=gJyWlwVxHu0QQUmKZQk/jwM09xhT0sTvGzhcKrryG+Y=; b=fUeLYvuCTTS1QVVbQdzDH/nj/23fg/JQTLM36EbtbI0wU6ro0OU5z3cpp8kNZqRhv6 SnLFzmL2uWu3Vmvv+ISNw6I/GksBjdSyTiLe0Bk2KoqVUlHZ4pfrnXjtXbegNgxGbXan c7oCjib9N8ObUJT1CCRWyZ6/JRGbfsaL/iDON7kcJOzHJz/79UbUAdm3ZkzXRHiSbT8M VCOckI6Zs1WdO4iUuxiWDHPp05TLsgH3snKUcl5JhDMa4Rd6veNgNL4jONPeLvv5otvF 4XERfugEY0ybO+JKPjC84XphJq6Xx50QJUXDk0GbS2IcsZ0LtAQmwlSqbDiFi/uc9PV9 4NRA== X-Gm-Message-State: AIkVDXJyjuckZVuzP2h6szK/+0YgebdOHUmW8CzYIGO9Atw0A7hPc5EzVwAEGcAkEal20oTHtejo/azUbJgrJalv2/J4rLpjiAFLFRAuN+RCGBq8zlV6TPY81RY5I6B0FqJuEFdbXzq57J54u5U= X-Received: by 10.31.5.67 with SMTP id 64mr6564122vkf.117.1484889940792; Thu, 19 Jan 2017 21:25:40 -0800 (PST) X-Received: by 10.31.5.67 with SMTP id 64mr6564116vkf.117.1484889940599; Thu, 19 Jan 2017 21:25:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 19 Jan 2017 21:25:39 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Thu, 19 Jan 2017 23:25:39 -0600 Message-ID: Subject: Re: Updated IID length text To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a1143cc7270bd0905467fe15b Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:25:44 -0000 --001a1143cc7270bd0905467fe15b Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti wrote: > On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> However, correct use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires all interfaces on a link to use the same >> length >> of Interface ID. Furthermore, to guarantee robust interoperability of >> SLAAC, >> a consistent length of Interface ID is desirable. For this reason, > > > I object to the text "for this reason", because SLAAC is not the only > reason. There are many reasons, many of which are written in 7421, and two > sentences in this paragraph are not sufficient to describe them. I propose > the following alternative, which I believe to be normatively identical: > > IPv6 routing is based on prefixes of any valid length up to 128 > [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, the Interface ID of all currently allocated unicast > addresses, > except those that start with the binary value 000, is required to be 64 > bits > long. The rationale for the 64 bit boundary in IPv6 addresses can be > found in > [RFC7421]. > > Cheers, > Lorenzo > How should that be interpreted? Do my Point-to-Point links need addresses that begin with binary 000? How do I get an allocation of those? Because it says I must use a 64 bit IID with the Global Unicast Allocation that I got from ARIN. Here is another problem, RFC 6164 probably should have updated 4291 for that reason. And if there are any future exceptions should update 4291bis, for similar reasons. There are lots of good reasons to use 64 bit IIDs almost everywhere, but there are exceptions. However this text doesn't leave room for any exceptions, even the one that it cites. Again keeping "required" I believe is a false imperative. If we can't fix that by going to "should", can we at least make room for official standards track exceptions, like the one cited and any future ones we agree on? Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a1143cc7270bd0905467fe15b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti <= ;lorenzo@google.com= > wrote:
On = Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
However, correct use of Stateless Address Autoconfiguration =C2=A0 =C2=A0(SLAAC)[RFC4= 862] requires all interfaces on a link to use the same length
=C2=A0 =C2=A0of Interface ID. Furthermore, to guarantee robust interoperabi= lity of SLAAC,
=C2=A0 =C2=A0a consistent length of Interface ID is desirable. For t= his reason,

I object to the text "for = this reason", because SLAAC is not the only reason. There are many rea= sons, many of which are written in 7421, and two sentences in this paragrap= h are not sufficient to describe them. I propose the following alternative,= which I believe to be normatively identical:

=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 1= 28 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127= bit prefixes on point-to-point
=C2=A0 =C2=A0links. However, the = Interface ID of all currently allocated unicast addresses,
=C2=A0= =C2=A0except those that start with the binary value 000, is required to be= 64 bits
=C2=A0 =C2=A0long. The rationale for the 64 bit boundary= in IPv6 addresses can be found in
=C2=A0 =C2=A0[RFC7421].
<= div>
Cheers,
Lorenzo
<= /blockquote>

How should that be interpreted? Do my Point= -to-Point links need addresses that begin with binary 000? How do I get an = allocation of those?=C2=A0 Because it says I must use a 64 bit IID with the= Global Unicast Allocation that I got from ARIN.=C2=A0

Here is another problem, RFC 6164 probably = should have updated 4291 for that reason.=C2=A0 And if there are any future= exceptions should update 4291bis, for similar reasons.

There are lots of good re= asons to use 64 bit IIDs almost everywhere, but there are exceptions.=C2=A0= However this text doesn't leave room for any exceptions, even the one = that it cites.

Again keeping "required" I believe is a false imperative= .=C2=A0 If we can't fix that by going to "should", can we at = least make room for official standards track exceptions, like the one cited= and any future ones we agree on? =C2=A0
Thanks

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <= a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn= .edu
Networking & Telecommunication Services
Office of Inform= ation Technology
University of Minnesota=C2=A0=C2=A0
2218 University= Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 5= 5414-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
--001a1143cc7270bd0905467fe15b-- From nobody Thu Jan 19 21:55: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 25F56129961 for ; Thu, 19 Jan 2017 21:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 wx77MDHU4s-6 for ; Thu, 19 Jan 2017 21:55:45 -0800 (PST) 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 1FB6512995B for ; Thu, 19 Jan 2017 21:55:45 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id k127so45338363vke.0 for ; Thu, 19 Jan 2017 21:55:45 -0800 (PST) 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=VV70ZzCcHJw9nuJM8wCKsQoSytWDiEIEXz7FHWB72Nc=; b=KSAc37TPme8ipjstn0iD4ZwCPT2KPhBBDAtzWGFB9KY/GIB+GiivmCF3/1/fZawfXm zLKXxiixCGMr7RCh1eP5P98mRMAiRFOYDk/nUwkCpn9Z1WToE1rPONvv5P0A9Awh0Zu9 jtgBqJtbTpr42nlW49SrlRgFVDIRAtiBSgndFEm99ipfv00TI4TxQXq+X9mM56ZyzXZW UfMnvdvs+L4VgHlr4b/tgywDEmdWzH5ASn8Fm85Tr+KwFeIkuJjfyUDc7t15tKTbA7WG V0exuEo+n4A0vuQMgonLT4A3yIVJqDsnNcLt37ci9mdWXrW9tBkeTxb6TukCoVfdVVcp fqFA== 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=VV70ZzCcHJw9nuJM8wCKsQoSytWDiEIEXz7FHWB72Nc=; b=dKUBUfpXOCBakkvkMPk3gJ7mouI0TxZ8bv30eJaVEZ0f6EE3FptVxuli/8FCttrcf4 1guowTIL/+aIQDZDGqt5zUDe8wkZbujhRPGyDSqjjtobKAVUOVgJI3Dg+n+ngiOcNSGJ PSPTaFyhvRervP6s0gu7J3vuQI6laFg4N23zhi+nbDK+OmHyjnxeRrvQ1d/XzaM2rVKc a4r8a5RZ3bs2fYIfsCFe7er3UX6hI5SfLRQ51xXKWY/g9bDrTeJsUF7z/vyrkcoFJ1oO HpGRY0hYGIIAbUF1FqwWTQL5y+/FINsuE56nbjOyKHKCtGTKhEgkIpnidIK/dFfOTnx6 jUtw== X-Gm-Message-State: AIkVDXKtmwqkHx8fRepyVjBMHioay7aupjBOHVy74ggmgYslVi6t0y9feVa746+ML0sOLIToD49767E9DQqWSWwH X-Received: by 10.31.192.204 with SMTP id q195mr6327521vkf.155.1484891744062; Thu, 19 Jan 2017 21:55:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Thu, 19 Jan 2017 21:55:23 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 20 Jan 2017 14:55:23 +0900 Message-ID: Subject: Re: Updated IID length text To: David Farmer Content-Type: multipart/alternative; boundary=001a114388ccef98000546804c40 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 05:55:47 -0000 --001a114388ccef98000546804c40 Content-Type: text/plain; charset=UTF-8 As Brian says, we can't change the normative effect in the context of promoting the document to full standard. As for making room for exceptions: isn't it a given that any standards track document can update RFC 4291? (Assuming 6man has either reviewed and gotten consensus on it, or not requested to review it) On Fri, Jan 20, 2017 at 2:25 PM, David Farmer wrote: > > > On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti > wrote: > >> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> However, correct use of Stateless Address Autoconfiguration >>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same >>> length >>> of Interface ID. Furthermore, to guarantee robust interoperability of >>> SLAAC, >>> a consistent length of Interface ID is desirable. For this reason, >> >> >> I object to the text "for this reason", because SLAAC is not the only >> reason. There are many reasons, many of which are written in 7421, and two >> sentences in this paragraph are not sufficient to describe them. I propose >> the following alternative, which I believe to be normatively identical: >> >> IPv6 routing is based on prefixes of any valid length up to 128 >> [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >> links. However, the Interface ID of all currently allocated unicast >> addresses, >> except those that start with the binary value 000, is required to be >> 64 bits >> long. The rationale for the 64 bit boundary in IPv6 addresses can be >> found in >> [RFC7421]. >> >> Cheers, >> Lorenzo >> > > How should that be interpreted? Do my Point-to-Point links need addresses > that begin with binary 000? How do I get an allocation of those? Because > it says I must use a 64 bit IID with the Global Unicast Allocation that I > got from ARIN. > > Here is another problem, RFC 6164 probably should have updated 4291 for > that reason. And if there are any future exceptions should update 4291bis, > for similar reasons. > > There are lots of good reasons to use 64 bit IIDs almost everywhere, but > there are exceptions. However this text doesn't leave room for any > exceptions, even the one that it cites. > > Again keeping "required" I believe is a false imperative. If we can't fix > that by going to "should", can we at least make room for official standards > track exceptions, like the one cited and any future ones we agree on? > > Thanks > > -- > =============================================== > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > --001a114388ccef98000546804c40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Brian says, we can't change the normative effect in= the context of promoting the document to full standard.

As for making room for excepti= ons: isn't it a given that any standards track document can update RFC = 4291? (Assuming 6man has either reviewed and gotten consensus on it, or not= requested to review it)

On Fri, Jan 20, 2017 at 2:25 PM, David Farmer <farmer@umn.edu> wrote:

=

On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colit= ti <lorenzo@google.com> wrote:
On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
However, correct use of Stateless Addr= ess Autoconfiguration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires all interfaces on a= link to use the same length
=C2=A0 =C2=A0of Interface ID. Furthermore, to guarantee robust interoperabi= lity of SLAAC,
=C2=A0 =C2=A0a consistent length of Interface ID is desirable. For t= his reason,

I object to the text "for = this reason", because SLAAC is not the only reason. There are many rea= sons, many of which are written in 7421, and two sentences in this paragrap= h are not sufficient to describe them. I propose the following alternative,= which I believe to be normatively identical:

=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 1= 28 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127= bit prefixes on point-to-point
=C2=A0 =C2=A0links. However, the = Interface ID of all currently allocated unicast addresses,
=C2=A0= =C2=A0except those that start with the binary value 000, is required to be= 64 bits
=C2=A0 =C2=A0long. The rationale for the 64 bit boundary= in IPv6 addresses can be found in
=C2=A0 =C2=A0[RFC7421].
<= div>
Cheers,
Lorenzo
<= /blockquote>

How should that be interpreted?= Do my Point-to-Point links need addresses that begin with binary 000? How = do I get an allocation of those?=C2=A0 Because it says I must use a 64 bit = IID with the Global Unicast Allocation that I got from ARIN.=C2=A0

Here is another problem, RFC 61= 64 probably should have updated 4291 for that reason.=C2=A0 And if there ar= e any future exceptions should update 4291bis, for similar reasons.

There are lot= s of good reasons to use 64 bit IIDs almost everywhere, but there are excep= tions.=C2=A0 However this text doesn't leave room for any exceptions, e= ven the one that it cites.

Again keeping "required" I believe is a fals= e imperative.=C2=A0 If we can't fix that by going to "should"= , can we at least make room for official standards track exceptions, like t= he one cited and any future ones we agree on? =C2=A0

Thanks

--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dav= id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.eduNetworking & Telecommunication Services
Office of Information Tech= nology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--001a114388ccef98000546804c40-- From nobody Thu Jan 19 22:11: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 CFC77129985 for ; Thu, 19 Jan 2017 22:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjgILiAoDJq3 for ; Thu, 19 Jan 2017 22:11:12 -0800 (PST) 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 A0307129981 for ; Thu, 19 Jan 2017 22:11:12 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id y143so19867521pfb.0 for ; Thu, 19 Jan 2017 22:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=V0GYpmZOJTRMBVVdMEAdD48YIv+9LXeB5bPeSe4wRlQ=; b=QUNbBzo1R+ybwDVYE2WRi4e3VnJ6oqF0aymyw73rhRPIM5vKpZPwgJDuXzgtb/7HnB WlHrGk+5/VpX0SnBPppfCw5LuCGXjEDqB7rc32hEl1qDUMsPn4mKuKmLHnucRgnVmyGN LULb8qhof8LeZ5uO48Q6DVztGSYysHVQbg+vqeRzHEUEAu491IksBIW/ZS9wQqhEM25r bscPtx/cQvALRbFWrUC/bTXlLVuRZ3wc/QpOlbkwbKr8UyNWFPMqwEjY6ofwQgppSkdK jPAl/QMx1d3OAgGL7kzS6jYSOqTyDukQ+UgXIYEqeTJfkXSIroprX71Y1hu2PoCrmcDp dmNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=V0GYpmZOJTRMBVVdMEAdD48YIv+9LXeB5bPeSe4wRlQ=; b=eT255xJ0PsCZiXD1wMWslVfdizm2cYYjHlgtFE3HXH1HO5cCYtciXRfsaCAmRjqL7R 6aCi76AfQOdR+fMg3IPyop4qxu90qbz0lWHkDKxtKEoBmdTufQ9T9FJZl44diI08mXFL R6/ba6hD5obpmoP7TeLFV0r2n/SCJRZVA0VhliP8S4yaFri+waneeo/IwfLvIZ9ocPRb IVYb2FaW+g6OyNNLP4uYNdF3zGx5AKUiF9DZkyb5TGMWXgp6ta5C/H5gJb8Z6fVc87QM MSAPaHG0PU65rjpARz3JTDmVbq/XaA++86KJIauT10RW9ADlElzc4lgxbVIGceV3y5ym IFfA== X-Gm-Message-State: AIkVDXJqbpxnGPPdIBOrZfws3+/xbi+Voy7OjuRomhQQAy3M5NGub+pHuj4hvG9Av+KOfA== X-Received: by 10.99.160.84 with SMTP id u20mr14917716pgn.141.1484892672217; Thu, 19 Jan 2017 22:11:12 -0800 (PST) Received: from ?IPv6:2406:e007:4482:1:28cc:dc4c:9703:6781? ([2406:e007:4482:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b1sm13207127pfa.28.2017.01.19.22.11.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 22:11:11 -0800 (PST) Subject: Re: Updated IID length text To: Lorenzo Colitti References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 20 Jan 2017 19:11:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 06:11:14 -0000 On 20/01/2017 17:38, Lorenzo Colitti wrote: > On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> However, correct use of Stateless Address Autoconfiguration >> (SLAAC)[RFC4862] requires all interfaces on a link to use the same >> length >> of Interface ID. Furthermore, to guarantee robust interoperability of >> SLAAC, >> a consistent length of Interface ID is desirable. For this reason, > > > I object to the text "for this reason", because SLAAC is not the only > reason. There are many reasons, many of which are written in 7421, and two > sentences in this paragraph are not sufficient to describe them. I propose > the following alternative, which I believe to be normatively identical: > > IPv6 routing is based on prefixes of any valid length up to 128 [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on point-to-point > links. However, the Interface ID of all currently allocated unicast addresses, > except those that start with the binary value 000, is required to be 64 bits > long. The rationale for the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. Yes, I'll buy 'however'. Brian From nobody Thu Jan 19 23:31: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 CBD1E129A4E for ; Thu, 19 Jan 2017 23:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsjZp3541I9H for ; Thu, 19 Jan 2017 23:31:18 -0800 (PST) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2173B129A56 for ; Thu, 19 Jan 2017 23:31:18 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9F55C5C0 for ; Fri, 20 Jan 2017 07:31:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8iFa9Akkn-F for ; Fri, 20 Jan 2017 01:31:17 -0600 (CST) Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 5E751A97 for ; Fri, 20 Jan 2017 01:31:17 -0600 (CST) Received: by mail-vk0-f72.google.com with SMTP id t8so38907767vke.3 for ; Thu, 19 Jan 2017 23:31:17 -0800 (PST) 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=qJYvSwA+MrxL2+rVDIyqXm/nUhkFuy3OSyWxrrT58ek=; b=O+YbRzx/p2qUg2b8iK4h8RXXFpkUP4weO2CiCBouDL05LQSK+qMtw5pFCQQ4b7y//j X+47EnMFI/o8d3veccnb3zDBDZcpOpUFVst8qsv7A9uvIGwa1DrJOE0a1aKi+q5suExD E8mjFjiUyLYer0BNzlYDDfnhu5g6rKizq6E2Eis9FAub5hnPRtAtopPLi5Vt0WgcZGAv XlIt7mk93pFq4RQv5l+wkvCTZif5/E67RFQ+YGz3WTGR4yvzaKLzPbMiM7vmtUoXnR2j sJj0M7d+JgwS1xebXYLmPt0KFIy8rla2zhVLiGI5SX5g4/r6AhkiifiXKKbpY4Bqfn7p An5Q== 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=qJYvSwA+MrxL2+rVDIyqXm/nUhkFuy3OSyWxrrT58ek=; b=qMqrN/OtU9k5NLqLUJrVno+MYpbC30+QZwltR1q8iVHGUI5xODAyt42RkoemqvZQoH UoSgl75wRoRbFQTcY0VEY+dz3sBDgHnWUkH1CFkDsWlaqcYYXvvvlzhHjI5OH8dQfjEk FxrFYR9w84dNqazgYLYVOJ4iHt/sReZj+PqR3DrQJGE+RuHtXFsM0fK/eokYNQ23HO2d uAQpVWK6dfFVomFBfLXsv6LBeUq4Y+T7DubgIc8tjTrNsvFwd6GWTWt/xTa0y+S2YEEx 6HofvxSV05Mp74u0yo6mnXjfOHT2Y04YyZ1a6OeMVXohabfhC9zIWswk9BxhFgkJVDku ev0Q== X-Gm-Message-State: AIkVDXIBP1LPyE9inxP+8jUQFM7zAHzioUe9uIo6KC7HESVLy6UhQIimVewpVIN6fo+BB6uNFJY+bTdap9FOqapxTRaHUXrIDnKY/XPNYNGrfhXmRxkvdBtah1gIE3z0xlnWVSodldl6i5QsFzE= X-Received: by 10.31.236.7 with SMTP id k7mr6710719vkh.96.1484897476738; Thu, 19 Jan 2017 23:31:16 -0800 (PST) X-Received: by 10.31.236.7 with SMTP id k7mr6710707vkh.96.1484897476463; Thu, 19 Jan 2017 23:31:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 19 Jan 2017 23:31:15 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> From: David Farmer Date: Fri, 20 Jan 2017 01:31:15 -0600 Message-ID: Subject: Re: Updated IID length text To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=94eb2c09617c9cf679054681a2a7 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 07:31:22 -0000 --94eb2c09617c9cf679054681a2a7 Content-Type: text/plain; charset=UTF-8 I think the reference to RFC6164 need to be included within the exception to the 64 bit requirement, something like the following; IPv6 routing is based on prefixes of any length up to 128 [BCP198]. However, the Interface ID of all currently allocated unicast addresses, except those that start with the binary value 000 or when use to address point-to-point link [RFC6164], is required to be 64 bits long. The rationale for the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. This is still a false imperative, but at least it is consistent with the intent of RFC6164. On Thu, Jan 19, 2017 at 11:55 PM, Lorenzo Colitti wrote: > As Brian says, we can't change the normative effect in the context of > promoting the document to full standard. > > As for making room for exceptions: isn't it a given that any standards > track document can update RFC 4291? (Assuming 6man has either reviewed and > gotten consensus on it, or not requested to review it) > > On Fri, Jan 20, 2017 at 2:25 PM, David Farmer wrote: > >> >> >> On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti >> wrote: >> >>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> However, correct use of Stateless Address Autoconfiguration >>>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same >>>> length >>>> of Interface ID. Furthermore, to guarantee robust interoperability >>>> of SLAAC, >>>> a consistent length of Interface ID is desirable. For this reason, >>> >>> >>> I object to the text "for this reason", because SLAAC is not the only >>> reason. There are many reasons, many of which are written in 7421, and two >>> sentences in this paragraph are not sufficient to describe them. I propose >>> the following alternative, which I believe to be normatively identical: >>> >>> IPv6 routing is based on prefixes of any valid length up to 128 >>> [BCP198]. >>> For example, [RFC6164] standardises 127 bit prefixes on point-to-point >>> links. However, the Interface ID of all currently allocated unicast >>> addresses, >>> except those that start with the binary value 000, is required to be >>> 64 bits >>> long. The rationale for the 64 bit boundary in IPv6 addresses can be >>> found in >>> [RFC7421]. >>> >>> Cheers, >>> Lorenzo >>> >> >> How should that be interpreted? Do my Point-to-Point links need addresses >> that begin with binary 000? How do I get an allocation of those? Because >> it says I must use a 64 bit IID with the Global Unicast Allocation that I >> got from ARIN. >> >> Here is another problem, RFC 6164 probably should have updated 4291 for >> that reason. And if there are any future exceptions should update 4291bis, >> for similar reasons. >> >> There are lots of good reasons to use 64 bit IIDs almost everywhere, but >> there are exceptions. However this text doesn't leave room for any >> exceptions, even the one that it cites. >> >> Again keeping "required" I believe is a false imperative. If we can't >> fix that by going to "should", can we at least make room for official >> standards track exceptions, like the one cited and any future ones we agree >> on? >> >> Thanks >> >> -- >> =============================================== >> David Farmer Email:farmer@umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> > > -- =============================================== 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 =============================================== --94eb2c09617c9cf679054681a2a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the reference to RFC6164 need to be included = within the exception to the 64 bit requirement, something like the followin= g; =C2=A0

IPv6 routing is based on prefixes o= f any length up to 128 [BCP198]. However,
the Interface ID of all= currently allocated unicast addresses, except those
that start w= ith the binary value 000 or when use to address point-to-point=C2=A0
<= div>link [RFC6164], is required to be 64 bits long. The rationale for the 6= 4 bit=C2=A0
boundary in IPv6 addresses can be found in [RFC7421].=

This is still a false imperative, but at le= ast it is consistent with the intent of RFC6164.=C2=A0

=

On Thu, Jan= 19, 2017 at 11:55 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
As Brian says, w= e can't change the normative effect in the context of promoting the doc= ument to full standard.

As for making room for exceptions: isn't it a given that an= y standards track document can update RFC 4291? (Assuming 6man has either r= eviewed and gotten consensus on it, or not requested to review it)

On Fri, Jan 20, 2017= at 2:25 PM, David Farmer <farmer@umn.edu> wrote:


On Thu, Jan 19, 2017 at 10:38 PM, Lorenzo Colitti <lorenzo@g= oogle.com> wrote:
On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <brian= .e.carpenter@gmail.com> wrote:
However, correct use of Stateless Address Autoconfig= uration
=C2=A0 =C2=A0(SLAAC)[RFC4862] requires= all interfaces on a link to use the same length
=C2=A0 =C2=A0of Interface ID. Furthermore, to guarantee robust interoperabi= lity of SLAAC,
=C2=A0 =C2=A0a consistent length of Interface ID is desirable. For t= his reason,

I object to the text "for = this reason", because SLAAC is not the only reason. There are many rea= sons, many of which are written in 7421, and two sentences in this paragrap= h are not sufficient to describe them. I propose the following alternative,= which I believe to be normatively identical:

=C2=A0 =C2=A0IPv6 routing is based on prefixes of any valid length up to 1= 28 [BCP198].
=C2=A0 =C2=A0For example, [RFC6164] standardises 127= bit prefixes on point-to-point
=C2=A0 =C2=A0links. However, the = Interface ID of all currently allocated unicast addresses,
=C2=A0= =C2=A0except those that start with the binary value 000, is required to be= 64 bits
=C2=A0 =C2=A0long. The rationale for the 64 bit boundary= in IPv6 addresses can be found in
=C2=A0 =C2=A0[RFC7421].
<= div>
Cheers,
Lorenzo
<= /blockquote>

How should that be interpreted?= Do my Point-to-Point links need addresses that begin with binary 000? How = do I get an allocation of those?=C2=A0 Because it says I must use a 64 bit = IID with the Global Unicast Allocation that I got from ARIN.=C2=A0

Here is another problem, RFC 61= 64 probably should have updated 4291 for that reason.=C2=A0 And if there ar= e any future exceptions should update 4291bis, for similar reasons.

There are lot= s of good reasons to use 64 bit IIDs almost everywhere, but there are excep= tions.=C2=A0 However this text doesn't leave room for any exceptions, e= ven the one that it cites.

Again keeping "required" I believe is a fals= e imperative.=C2=A0 If we can't fix that by going to "should"= , can we at least make room for official standards track exceptions, like t= he one cited and any future ones we agree on? =C2=A0

Thanks

--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2= =A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




--
=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
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--94eb2c09617c9cf679054681a2a7-- From nobody Fri Jan 20 10:14:01 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6078E129466 for ; Fri, 20 Jan 2017 10:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYhw3U1pZFbU for ; Fri, 20 Jan 2017 10:13:59 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9C612943D for ; Fri, 20 Jan 2017 10:13:59 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 19 Jan 2017 20:48:09 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BA442D788B; Thu, 19 Jan 2017 12:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=rKArhcFf3ppg8pSUBsL4QPRUUFc=; b=TQST4gnRflC8amLlwt IJayxVLd46O2IHvSjkC11Ulv3zpYBq/Lqudk6TJJRKBWbTn36g8ljbsKnB1Gns4T BxNZt6bNK4tvtnL0Yiq/ZXaaT7tfA0NZSFjG8id3bjm/lJi80xFgdCip5kdJaTwh 79myyBlxaItz2aq36Lkhv4nBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=mtPtr7cDZTRlNYVFbZ1TLlbWZt8fmRlbhh2kOHDEBaP2cuyDXKS 6SsHQHSWatr7V3G7nFHGIzacyLKy5BbWjUNwaaxuCoFuDlM4hRFWjMfxoj6Tfq4d flTnANlMHzpYxeOs1TS1HoClkx77zxsv3AVBk1GW1zAdll/D9l2r/FHE= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 806EDD788A; Thu, 19 Jan 2017 12:48:08 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C9A3878A40DB; Thu, 19 Jan 2017 21:48:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: otroan@employees.org In-Reply-To: Date: Thu, 19 Jan 2017 21:48:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:14:00 -0000 Brian, [...] > NEW NEW > IPv6 routing is based on prefixes of any valid length up to 128 = [BCP198]. > For example, [RFC6164] standardises 127 bit prefixes on = point-to-point > links. However, correct use of Stateless Address Autoconfiguration > (SLAAC)[RFC4862] requires all interfaces on a link to use the same = length > of Interface ID. Furthermore, to guarantee robust interoperability = of SLAAC, > a consistent length of Interface ID is desirable. For this reason, = the > Interface ID of all currently allocated unicast addresses, except = those that > start with the binary value 000, is required to be 64 bits long. = Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. By changing "For all unicast addresses" to "all currently allocated = unicast addresses", Are you proposing to reverse the decision that was made back when = RFC3513 updated RFC2373? Change log: - Revised sections 2.4 and 2.5.6 to simplify and clarify how different address types are identified. This was done to insure that implementations do not build in any knowledge about global unicast format prefixes. Changes include: o Removed Format Prefix (FP) terminology o Revised list of address types to only include exceptions to global unicast and a singe entry that identifies everything else as Global Unicast. Best regards, Ole= From nobody Fri Jan 20 10:17: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 5EEA6129405 for ; Fri, 20 Jan 2017 10:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfDO8uXi76T4 for ; Fri, 20 Jan 2017 10:17:15 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE05127076 for ; Fri, 20 Jan 2017 10:17:15 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 19 Jan 2017 23:52:46 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8AD95D788D; Thu, 19 Jan 2017 15:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=rMbLiTWCj5lmgCyCZfrJUj3GwPs=; b=p534nK0/dZGZiITH1A r2hm3U8OzsOr9op6fh6lFE1n4jscm2yhmpS5SAWAq0PE/nsh/gzLIIUEorApuqGm MzZa5AzmJLdKOS66dZRwcosgl5fbBgd42zuQA0+FpV0Za3t6R8+igQwVapORDa5i /3scPBiKSB+n76xMhVRYyglp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=hyIzdM2mBn7w4nhI0XDmbO6PYhLbCKzRnFMEcv6SDU1nlo5YPp2 /LJfRzQoFz+v0F6zEfTee37SrFsf4jgg/SMRYb5z3VG/BMgO+C7FQKVgiuroNwAk a+aJuU4BWej6/bqfhE2PHFvGkhUbJQlovVVQZuaSXsbVstd6NGCKjrDQ= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 1D299D788A; Thu, 19 Jan 2017 15:52:46 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id ECFEA78D9CE5; Fri, 20 Jan 2017 00:52:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] From: otroan@employees.org In-Reply-To: Date: Fri, 20 Jan 2017 00:52:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9DF96FB9-E922-4351-9D44-A80B0568194B@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> To: David Farmer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:17:16 -0000 Dave, > Given that what we are left with is policy, I think it is quite harsh = of you to declare that there is no consensus on the current text on the = IETF list. > There are good technical arguments for why each host needs more than a = single address, and if we end up in a situation similar to IPv4 where = each address used has to be justified, then we have lost. There is a = justified fear that allowing the 64 bit boundary to slide, we will end = up in a situation similar to IPv4 addressing. E.g. charging per address. >=20 > I'm a little worried that your fighting yesterday's battle. To be = honest, I'm less worried about charing for more than one IP address. I'm = much more worried about charging for more than one subnet. In fact, I'm = worried a hard and inflexible boundary at /64 reinforces a model for = charging for more than one subnet. >=20 > If that happens would you prefer people use NTPv6 or NAT66? I'd = prefer a more flexible subnet boundary, that allows the18 quadrillion = addresses in a /64 to be broken into smaller subnets.=20 Therein lays the paradox. If the IETF were to standardise arbitrary = prefix length > 64 you end up being charged per address. If = implementations don't support arbitrary prefix lengths > 64 you end up = having to do NAT66, ND proxy... Which is why all implementations should support arbitrary prefix length, = but not tell anyone. ;-) >=20 > Furthermore, we are talking about giving individual devices their own = subnets. I like this model and with today's scale that will be fine. = But, longer-term this has me worried, especially if we keep a inflexible = /64 boundary.=20 That would require extreme waste in the first 64 bits... 2^64 number of addresses is an awfully big number. > This is where the IETF has to perform a fine balancing act. On one = side ensure that the 64 bit boundary stands, at the other side ensure = that all implementors do not enshrine a hard-coded boundary in their = implementations. >=20 > Ok, are you willing to put that in the document? The /64 requirement, = is a political consideration, not a technical one. Because other than = /64 subnets are clearly technically possible, we have evidence of it in = RFC 7421.=20 But unless we also kept some technical limitations, would anyone accept = the boundary if it was purely policy? (And at this point there is surely a lot more technical reasons than = just SLAAC.) Best regards, Ole= From nobody Fri Jan 20 10:33: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 A162A129C52 for ; Fri, 20 Jan 2017 10:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwb-fxy5t9VP for ; Fri, 20 Jan 2017 10:33:20 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A46A1129C48 for ; Fri, 20 Jan 2017 10:33:20 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 19 Jan 2017 22:09:12 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 41124D789B; Thu, 19 Jan 2017 14:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=+NOEZLVG+/pB9qrWPkaxpYTgW20=; b=qDlkjIbmGhv9UsyTcl IaZJOs4WioldQQhZCYWLG5yZpy7jgSM16D60XoiAC3nuLkdWjEH4yAUpQqowfJm0 +YMV7IKX5ELqT8z9Sm8LfFB2QYgg4AxMhyJSZ9vj/IujQk2+653W3Iw8GPFteH6l 2yPa6VSUcQXury4A4PiE3z/3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=mefTrQTdPnAKws2uDA4loXondTuCbYqdf8JUVgnkwyo9NflVCFA u61Wqp3HLariCWDTLoSSiWlcHbZM9X1H1E5AGTXNmnfHWs0TErIeaZeTJ9p9afAB vN1NMD4O2lNPAe0PdiCEG1MObzjE2+ijJOyFEgkNvo7ZxkDyHq6hl+mA= Received: from h.hanazo.no (unknown [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id B8965D788F; Thu, 19 Jan 2017 14:07:27 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6A99478BB120; Thu, 19 Jan 2017 23:07:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: otroan@employees.org In-Reply-To: <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 19 Jan 2017 23:07:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:33:21 -0000 >>>=20 >>> NEW NEW >>> IPv6 routing is based on prefixes of any valid length up to 128 = [BCP198]. >>> For example, [RFC6164] standardises 127 bit prefixes on = point-to-point >>> links. However, correct use of Stateless Address Autoconfiguration >>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same = length >>> of Interface ID. Furthermore, to guarantee robust interoperability = of >> SLAAC, >>> a consistent length of Interface ID is desirable. For this reason, = the >>> Interface ID of all currently allocated unicast addresses, except = those >> that >>> start with the binary value 000, is required to be 64 bits long. >> Background >>> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. >>=20 >> By changing "For all unicast addresses" to "all currently allocated = unicast >> addresses", >>=20 >> Are you proposing to reverse the decision that was made back when = RFC3513 >> updated RFC2373? >> Change log: >> - Revised sections 2.4 and 2.5.6 >> to simplify and clarify how >> different address types are identified. This was done to = insure >> that implementations do not build in any knowledge about global >> unicast format prefixes. Changes include: >> o Removed Format Prefix (FP) terminology >> o Revised list of address types to only include exceptions = to >> global unicast and a singe entry that identifies = everything >> else as Global Unicast. >=20 > Not speaking for Brian, my reaction to the RFC 3513 text would be that = Brian's new text better responds to "This was done to insure that = implementations do not build in any knowledge about global unicast = format prefixes." >=20 > We have a pragmatic requirement of 64-bit IIDs, for the existing = (minority) of assigned global unicast addresses. But we don't want to = reverse the intention for CIDR, stated in RFC 3513. This is the = "tension" with CIDR, which has existed for too many years. I asked the clarification because RFC2373 did use the format prefix, = where only 2000::/3 was the Global Unicast prefix. That was changed to making the whole remaining address global unicast; = the worry was that this would make implementations treat different = 1/8ths differently (and therefore classful). I wanted to know if the intention of Brian's suggested text was to = reverse that? Ole From otroan@employees.org Fri Jan 20 10:55: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 AA9CF129C68 for ; Fri, 20 Jan 2017 10:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ca9fyxN2cLc for ; Fri, 20 Jan 2017 10:55:11 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id C255E129C63 for ; Fri, 20 Jan 2017 10:55:11 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 20 Jan 2017 10:30:35 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id EC983D7899; Fri, 20 Jan 2017 02:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=qApS3NYIbwPRq6MCxxiOwHNFa/Q=; b=Xb/30EXIC11Pf5iL41 3zoDcsZDHSadPPiP3MvLN/6Ktf74tkaFEJq5kyhqCFbL7ii0LJ/gwpADVxMj+T3p 0SsEANgEjMbui4YFCnf/sDNtxc23+ElZjRxwFMz7zAJe4PukwYGxdN3f0qkP5WrO Fi5L+w4mNEufIuybj3TIiYQv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=adSMM/rzo9twqZ09ILFDhwngrax1GIC7g3wl/2sCpzCNaMPWCJw SO8bj6wCmagL4T/b5kxDvcZpIStrdRfBFIAdOZ9ozwgPmxYQ1aabx9t+3EaRDczn wqcW3V7XyFv3+QU1DL4B0ufRnIQSES13elOtoyLnOmCdUcelMpmFQMW4= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C0B6ED7893; Fri, 20 Jan 2017 02:29:12 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 00C7C79889D2; Fri, 20 Jan 2017 11:29:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: otroan@employees.org In-Reply-To: <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com> Date: Fri, 20 Jan 2017 11:29:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:55:13 -0000 Brian, >>> By changing "For all unicast addresses" to "all currently allocated = unicast >>> addresses", >>>=20 >>> Are you proposing to reverse the decision that was made back when = RFC3513 >>> updated RFC2373? >>> Change log: >>> - Revised sections 2.4 and 2.5.6 >>> to simplify and clarify how >>> different address types are identified. This was done to = insure >>> that implementations do not build in any knowledge about global >>> unicast format prefixes. Changes include: >>> o Removed Format Prefix (FP) terminology >>> o Revised list of address types to only include exceptions = to >>> global unicast and a singe entry that identifies = everything >>> else as Global Unicast. >>=20 >> Not speaking for Brian, my reaction to the RFC 3513 text would be = that Brian's new text better responds to "This was done to insure that = implementations do not build in any knowledge about global unicast = format prefixes." >>=20 >> We have a pragmatic requirement of 64-bit IIDs, for the existing = (minority) of assigned global unicast addresses. But we don't want to = reverse the intention for CIDR, stated in RFC 3513. This is the = "tension" with CIDR, which has existed for too many years. >=20 > Indeed. I've taken out the explicit text that people objected to, but = if another /3 > is released to IANA and the RIRs, don't we want to keep our options = open? This isn't the right place to change the consensus that has held since = 3513. Making this change would require a much deeper analysis of why the = reasons outlined above don't apply anymore. You are essentially proposing to redefine the meaning of "Global = Unicast". And please note that 4291 already has provisions for this: Section 2.4: Future specifications may redefine one or more sub-ranges of the Global Unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses. Cheers, Ole= From nobody Fri Jan 20 11:59: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 2AF0C1270B4 for ; Fri, 20 Jan 2017 11:59:39 -0800 (PST) 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 UuVCd0ieTsRU for ; Fri, 20 Jan 2017 11:59:37 -0800 (PST) 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 6AADE126D74 for ; Fri, 20 Jan 2017 11:59:37 -0800 (PST) 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 v0KJxaeF014474; Fri, 20 Jan 2017 12:59:36 -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 v0KJxWBj014454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2017 12:59:33 -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.1178.4; Fri, 20 Jan 2017 11:59:32 -0800 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.1178.000; Fri, 20 Jan 2017 11:59:32 -0800 From: "Manfredi, Albert E" To: "otroan@employees.org" , David Farmer Subject: RE: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Topic: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Thread-Index: AQHScqwgjPqNAvQPbkeyQCElQvXC+aFA/wSAgADEgBA= Date: Fri, 20 Jan 2017 19:59:32 +0000 Message-ID: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <00D1565E-7119-4C52-AF06-95E3F4C5905A@employees.org> <562C040F-EC30-49C6-849F-F63BA22233C7@employees.org> <595c73ef-ffa4-6f9e-d810-c37ea8dc2c0d@gmail.com> <148B5BCE-ED32-4FA8-83BA-48F3F4149396@employees.org> <9DF96FB9-E922-4351-9D44-A80B0568194B@employees.org> In-Reply-To: <9DF96FB9-E922-4351-9D44-A80B0568194B@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [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: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 19:59:39 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of otroan@employees.o= rg > Therein lays the paradox. If the IETF were to standardise arbitrary prefi= x > length > 64 you end up being charged per address. If implementations don'= t > support arbitrary prefix lengths > 64 you end up having to do NAT66, ND > proxy... > Which is why all implementations should support arbitrary prefix length, = but > not tell anyone. ;-) Yes, that is the problem. However, the threat of being given just one addre= ss is already the case, is it not? Individuals are not being handed out /48= or even /56. So I don't see a /64 mandate solving anything, in this one re= spect. It just pushes people to use the same work-arounds as had to be inve= nted for IPv4.=20 > That would require extreme waste in the first 64 bits... > 2^64 number of addresses is an awfully big number. I keep seeing this stated, but I don't think this is necessarily true. This= type of assumption can change drastically, depending how Internet applianc= es evolve over time. With IPv4, no one predicted that every single hand-hel= p gadget might require its own IP address. And this time around, with devel= opments such as the so-called IoT, there's likely to be zillions of devices= that will require their own prefix, and will support multiple internal sub= nets. I think that Brian's NEW NEW test is what should be used, because it does N= OT imply that all global unicast addresses, minus one subset 000, must use = /64 addresses for all time. And too, the main reason for the specific 64 bit length mentioned, for curr= ently assigned global unicast IIDs, *is indeed* SLAAC. There is no good rea= son to hide this reality. RFC 7421: The notion of a /64 boundary in the address was introduced after the initial design of IPv6, following a period when it was expected to be at /80. There were two motivations for setting it at /64. One was the original "8+8" proposal [ODELL] that eventually led to the Identifier-Locator Network Protocol (ILNP) [RFC6741], which required a fixed point for the split between local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would become widespread in place of 48-bit addresses, coupled with the plan at that time that auto-configured addresses would normally be based on interface identifiers derived from MAC addresses. I do agree with the one objection, that on any given link, the prefix lengt= h only needs to be consistent for that subnet. For instance, a globally uni= que /80 should be able to coexist with ULAs, or link locals, or other examp= les of /64s. I do not think we should go back to text that implies /64 is f= or all unicast addresses, for all time. Bert From nobody Fri Jan 20 14:40:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8CD1294F8 for ; Fri, 20 Jan 2017 14:40:06 -0800 (PST) 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 NCa1jsK4Agd8 for ; Fri, 20 Jan 2017 14:40:05 -0800 (PST) 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 0A4A71294F6 for ; Fri, 20 Jan 2017 14:40:05 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 204so26918921pge.0 for ; Fri, 20 Jan 2017 14:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hKQFDUdoiDCLJKD0NiW4oYoXl/Wo6xd/MuQyMqHbyG0=; b=SJMMOBOeTqmcbNSl/k9oFg+IJv/ZdgbvTFDTYdyC99TuZDMJ1/cSLy2bT6roXvSTQJ 5g8wxvE+kI1qGisa8igOPy/zkjcFEEh1sqDVCa3+1IUXm/MCf6h8JHUkhxtHa4KwkX1j VdjqK4fQ8a6UHnJs6c6eaV0Rluq3PtQKJjbxCAf271bHDjCkJbmCGsqURU1dBH1h7jcG 7oHiL/UAIa5UV1V2EZy83E2VfQq58sZz0EuwNBdefaibBvfi4LM+fh45+QAjULhNbE8e 3WKunXyubzb5Y6+TlWif0c8fAWG7Gy8hSAYRUFtPF1hk0fbqi0gjiArPWi322drj1rBp DXvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hKQFDUdoiDCLJKD0NiW4oYoXl/Wo6xd/MuQyMqHbyG0=; b=Doxbz9Wh2/rlEAHPRLpmNjVQ6PYgOB8plqalNtHSy1/FJE4MSkj4DNnvifl9J1WBV5 gMnP+MU7IbvhtNT6s3wAP+PeSsQ3qtoEWDnKpxA14eFBDq3wFbbv8g0EgA1aZl8+8bWW fWuXVCUBofAGbHaL0Ge/gKOolQEgKL9ouFzKo2QMAkWwx7rp7H84phcClY7iH/Egeqet iSqVgEQ+9dHZi3Wf+bLiPS+Ch3sKRmdxc1CX7jzAgy5NY3vwbK/Ik/LXMeg7kZBoyjoi IBPFoNdHJz9tHbcVuVQYHSHPtabQvDiDbMUvJeXB743A3d7SW4MGayRiCDNnt+BUCUid udBQ== X-Gm-Message-State: AIkVDXLwwOOPR79N1HBpzp1pi3KQfvYFiDnAtEuPm51hCUpnSznstotVh86BpBX0GhqVZA== X-Received: by 10.99.237.69 with SMTP id m5mr19495322pgk.94.1484952004600; Fri, 20 Jan 2017 14:40:04 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.38]) by smtp.gmail.com with ESMTPSA id a8sm19215364pfa.19.2017.01.20.14.40.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 14:40:03 -0800 (PST) Subject: Re: Updated IID length text To: otroan@employees.org References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4c052d3c-7c57-c0b3-1dd3-de764eb99c13@gmail.com> Date: Sat, 21 Jan 2017 11:40:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 22:40:06 -0000 On 20/01/2017 23:29, otroan@employees.org wrote: > Brian, > >>>> By changing "For all unicast addresses" to "all currently allocated unicast >>>> addresses", >>>> >>>> Are you proposing to reverse the decision that was made back when RFC3513 >>>> updated RFC2373? >>>> Change log: >>>> - Revised sections 2.4 and 2.5.6 >>>> to simplify and clarify how >>>> different address types are identified. This was done to insure >>>> that implementations do not build in any knowledge about global >>>> unicast format prefixes. Changes include: >>>> o Removed Format Prefix (FP) terminology >>>> o Revised list of address types to only include exceptions to >>>> global unicast and a singe entry that identifies everything >>>> else as Global Unicast. >>> >>> Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes." >>> >>> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years. >> >> Indeed. I've taken out the explicit text that people objected to, but if another /3 >> is released to IANA and the RIRs, don't we want to keep our options open? > > This isn't the right place to change the consensus that has held since 3513. I agree with that, and it isn't my intention. > Making this change would require a much deeper analysis of why the reasons outlined above don't apply anymore. > You are essentially proposing to redefine the meaning of "Global Unicast". Well, I don't agree. I was just trying to confirm that the current rule applies to the whole of 2000::/3, without closing off future options. Actually it might have been better if this magic number had been left out of the addressing architecture and included in the SLAAC specification, but it's years too late to change that. > And please note that 4291 already has provisions for this: > Section 2.4: > Future specifications may redefine one or more sub-ranges of the > Global Unicast space for other purposes, but unless and until that > happens, implementations must treat all addresses that do not start > with any of the above-listed prefixes as Global Unicast addresses. Right. So 4000::1234 is clearly a unicast address, but if not used for SLAAC, it doesn't need a defined IID length. That's where we have muddled things a bit between the addressing architecture and the SLAAC spec. Brian From nobody Fri Jan 20 15:53: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 36BCD1295FE for ; Fri, 20 Jan 2017 15:53:05 -0800 (PST) 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 p7kHJFSRvyaK for ; Fri, 20 Jan 2017 15:53:03 -0800 (PST) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949491295B1 for ; Fri, 20 Jan 2017 15:53:03 -0800 (PST) Received: by mail-io0-x242.google.com with SMTP id q20so9569926ioi.3 for ; Fri, 20 Jan 2017 15:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qff75dr2N793umcAERMZLQ+pMrex0rThwhqVzaQAHtQ=; b=VR4mJ+I1rlmahQUtyYMmdz/MFcJYGPE8In62qua+nrU32a49RYyGq/8JWYS2IyRCAA PPmqPonjiz9Es3taS5uC9lYkJ8qki/EE3JoEcBA75pgvEddNMv4IYYGGCa9ZjmYtzyKR cHMOhtUkpOgxlevvJZ/8t9bslLdTQJ6clwItP4yKbCmHAix2UiXYbz2v4U63/p3iSNUT DqpZwcIGxcEfb9Et3BPhut6tgwpSDrFGy0dkEDROm0qQo+W0cX6Aakx8wrRr/hG8oQC5 gdgP4F7oNzEps6ikxdshAmACb7ft8IwCjzes8ZHOvpsZ1nLCR+LyMFhmn2ARZZVYpm5B WO8Q== 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=Qff75dr2N793umcAERMZLQ+pMrex0rThwhqVzaQAHtQ=; b=H0tdafsN6axA67zv6sPozsYFgAT64I/lR1+Nfhr2WNZ/1aVwGDVI3SnICAjLRLi/Iy hZNKhfPprxJTtPrBOYcEP2RnxYI2uL26jV4UdRfvLSVJG/dfU8+4RvDOBu91dVgmWz1c HO70+atzTCwfqtZA3Mc5sOYJ97RMd6RL1bSscdF7upCG/6U/V/RCA1Cd8+I5CdXZe88g 7pvkdvLGedpKBl+Juf2WcoL2EpYuPMDRX3Zj28eoXncYWbrB0dKhsRNzgJrHteuFT1xF QTEI4Ynk7z9SBJDGUhiGYs5REGBkOqkcDDq/C2kRTtcV8eZxIH/zc5wdGPVOV2t7Gzhp mVDg== X-Gm-Message-State: AIkVDXIswXKsnHnZuvqZDqXCCvGmzPdWohjcVh4GIwroQt5W1HDq4NGWQpmWnXHh15ZawQ== X-Received: by 10.107.173.95 with SMTP id w92mr18184694ioe.136.1484956382764; Fri, 20 Jan 2017 15:53:02 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id j79sm1918755itb.0.2017.01.20.15.53.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 15:53:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: Bob Hinden In-Reply-To: Date: Fri, 20 Jan 2017 15:53:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 23:53:05 -0000 Brian, > On Jan 19, 2017, at 10:11 PM, Brian E Carpenter = wrote: >=20 > On 20/01/2017 17:38, Lorenzo Colitti wrote: >> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>=20 >>> However, correct use of Stateless Address Autoconfiguration >>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same >>> length >>> of Interface ID. Furthermore, to guarantee robust interoperability = of >>> SLAAC, >>> a consistent length of Interface ID is desirable. For this reason, >>=20 >>=20 >> I object to the text "for this reason", because SLAAC is not the only >> reason. There are many reasons, many of which are written in 7421, = and two >> sentences in this paragraph are not sufficient to describe them. I = propose >> the following alternative, which I believe to be normatively = identical: >>=20 >> IPv6 routing is based on prefixes of any valid length up to 128 = [BCP198]. >> For example, [RFC6164] standardises 127 bit prefixes on = point-to-point >> links. However, the Interface ID of all currently allocated unicast = addresses, >> except those that start with the binary value 000, is required to = be 64 bits >> long. The rationale for the 64 bit boundary in IPv6 addresses can = be found in >> [RFC7421]. >=20 > Yes, I'll buy 'however=E2=80=99. I am generally OK with the text above, but wanted to point out that = Section 2.4. "Unicast Addresses=E2=80=9D there is more than one place = where 64 IIDs are mentioned. This discusion has been about the forth = paragraph in 2.4.1. "Interface Identifiers=E2=80=9D. It is also = mentioned in the second paragraph of 2.4.4. "Global Unicast = Addresses=E2=80=9D. I assume this would have to be modified if the w.g. = decides to adopt this text. As Ole pointed out there is text that discusses future changes: 2.3. Address Type Identification Future specifications may redefine one or more sub-ranges of the Global Unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as Global Unicast addresses. 2.4. Unicast Addresses There are several types of unicast addresses in IPv6, in particular, Global Unicast, Local unicast, and Link-Local unicast. There are also some special-purpose subtypes of Global Unicast, such as IPv6 addresses with embedded IPv4 addresses. Additional address types or subtypes can be defined in the future. I think that this makes it clear that things are allowed to change in = the future. I don=E2=80=99t think we have to capture this in the single = paragraph in 2.4.1, and there could be other kind of changes as well. Thanks, Bob From nobody Fri Jan 20 18:16:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4712964A for ; Fri, 20 Jan 2017 18:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_aTo1mt7V3Z for ; Fri, 20 Jan 2017 18:16:14 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD0A129642 for ; Fri, 20 Jan 2017 18:16:14 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id e4so26445856pfg.1 for ; Fri, 20 Jan 2017 18:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3jRB2F3xzxFPG46ZpqbkCWIwQLgD22JRq4LIla1IWyg=; b=NIe34VZCQDZr//1D5C7z1RIMdbMReqlL230bRNn100/dCCMOcgCQhVhjzZ3vyfr3QT QxehGqbNXkzyeEX5UJfefw0ArHPLJmFKCdBzV68trllNHO1aVncqSsIM6LXEZf4BwOhD 2iaLcG1SM/iIKfLDgUWXLkoxVWjhIvFxGWu+7UbNCPdLkovXxvcW9rxA3J2bILwrCAYn xPOLGCM9r2lmfVLiQRIzoplkhv/0D6ivIbAn9AXgh9jZFiemcedUKLGwkuYtuBDN339P S8R5gX7t/5ZOCQV0CKLLvgFGQj7nKOT2qr4NTurQDT8xQlXByRkydJFwmUCjpvhPFGKx MO2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3jRB2F3xzxFPG46ZpqbkCWIwQLgD22JRq4LIla1IWyg=; b=myK+Tvj1SlUQ62lHlcEYJzsyit19HACy6P5HSIcsfm5ls2DzSbhC/fbwX7pE6uQn6R AlTESG3OsHsMcQdCLCjkQ+s3TPWUNXkATb2exkuOajI7hUbYMCnLeUZyAJhNs4GEIcbJ WMCKZNsiFZzuzlQ/kcZBsObg7yHOj8Q5jbYEy5+h9WYTwyd30PLzqAmDyk3SeOZWyYZN ptDgy6+mT+TOkiaqj1+8u6TSnJkP3rob6tuOhpafecWz8lDaLIxDeEDK4P8gDP/xArLT gGh5pi+RogQQxTZlHrJ7+AbyIVo4+3fVLGSlxiJa0XIAYbDXTFnzVqmjhVTUeI8gFNRE bGKA== X-Gm-Message-State: AIkVDXL51aWXtHM0xErZjAUvleWPdHP4F7K+Wnz+vhvRYkeCbIaDYDm3qrFh8NEEcA2gqw== X-Received: by 10.84.233.201 with SMTP id m9mr26005290pln.91.1484964973875; Fri, 20 Jan 2017 18:16:13 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.38]) by smtp.gmail.com with ESMTPSA id o126sm19681375pga.34.2017.01.20.18.16.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 18:16:12 -0800 (PST) Subject: Re: Updated IID length text To: Bob Hinden References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> Date: Sat, 21 Jan 2017 15:16:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 02:16:16 -0000 Bob, Yes, I take your point. Maybe we can all close this thread now and you can decide what to put in the next draft. Regards Brian On 21/01/2017 12:53, Bob Hinden wrote: > Brian, >=20 >> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter wrote: >> >> On 20/01/2017 17:38, Lorenzo Colitti wrote: >>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> However, correct use of Stateless Address Autoconfiguration >>>> (SLAAC)[RFC4862] requires all interfaces on a link to use the same= >>>> length >>>> of Interface ID. Furthermore, to guarantee robust interoperability= of >>>> SLAAC, >>>> a consistent length of Interface ID is desirable. For this reason,= >>> >>> >>> I object to the text "for this reason", because SLAAC is not the only= >>> reason. There are many reasons, many of which are written in 7421, an= d two >>> sentences in this paragraph are not sufficient to describe them. I pr= opose >>> the following alternative, which I believe to be normatively identica= l: >>> >>> IPv6 routing is based on prefixes of any valid length up to 128 [BC= P198]. >>> For example, [RFC6164] standardises 127 bit prefixes on point-to-po= int >>> links. However, the Interface ID of all currently allocated unicast= addresses, >>> except those that start with the binary value 000, is required to b= e 64 bits >>> long. The rationale for the 64 bit boundary in IPv6 addresses can b= e found in >>> [RFC7421]. >> >> Yes, I'll buy 'however=E2=80=99. >=20 > I am generally OK with the text above, but wanted to point out that Sec= tion 2.4. "Unicast Addresses=E2=80=9D there is more than one place where = 64 IIDs are mentioned. This discusion has been about the forth paragraph= in 2.4.1. "Interface Identifiers=E2=80=9D. It is also mentioned in the = second paragraph of 2.4.4. "Global Unicast Addresses=E2=80=9D. I assume = this would have to be modified if the w.g. decides to adopt this text. >=20 > As Ole pointed out there is text that discusses future changes: >=20 > 2.3. Address Type Identification > Future specifications may redefine one or more sub-ranges of the > Global Unicast space for other purposes, but unless and until that > happens, implementations must treat all addresses that do not start > with any of the above-listed prefixes as Global Unicast addresses. >=20 > 2.4. Unicast Addresses > There are several types of unicast addresses in IPv6, in particular,= > Global Unicast, Local unicast, and Link-Local unicast. There are > also some special-purpose subtypes of Global Unicast, such as IPv6 > addresses with embedded IPv4 addresses. Additional address types or= > subtypes can be defined in the future. >=20 > I think that this makes it clear that things are allowed to change in t= he future. I don=E2=80=99t think we have to capture this in the single p= aragraph in 2.4.1, and there could be other kind of changes as well. >=20 > Thanks, > Bob >=20 >=20 >=20 >=20 >=20 >=20 From nobody Sat Jan 21 06:25: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 080A9129A80 for ; Sat, 21 Jan 2017 06:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvw2q5pJr-8t for ; Sat, 21 Jan 2017 06:25:28 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDE9129A7F for ; Sat, 21 Jan 2017 06:25:28 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 21 Jan 2017 14:25:27 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 7CB7ED788B; Sat, 21 Jan 2017 06:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=imqTajpd3E8EOcLrscZHgk1iSKw=; b=T4yc6eWRopJ/vhX/Ss 1/se0LRiv9BU8I+VxwYmFiCmYtxLNtqAliUK1Giv4H6ACo8O1XhrqjPh8UrBQrWy kw+ciCfhiiRuvC/3cDhD8qsvsl1drgKdQxsbmP8gG7gGjGkr/KSFutcmPqYJyvEn aVL4KKMg1yGmZ9/KPDTW2NErc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=UiPp/ARlrsyh0j9TrR1VRwiJexG75RyhdB6JK3cTy8YhdJdSC5m /iPdmGb7hy5SldmaOcRU5Z+7htRBDACRHUA5xJ7fk4IdkpQkgE2O2I6GCNlnFOaj 2DCyF/fNNRUiUv705yQU2OQ7lNLuHpmH1JcOPAdPRcHnAKC2n8DVsQ2k= Received: from h.hanazo.no (37.253.248.180.tmi.telenormobil.no [37.253.248.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A748CD788A; Sat, 21 Jan 2017 06:25:26 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C9CE279C1B40; Sat, 21 Jan 2017 15:25:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: otroan@employees.org In-Reply-To: <4c052d3c-7c57-c0b3-1dd3-de764eb99c13@gmail.com> Date: Sat, 21 Jan 2017 15:25:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F43722A-B1DF-4FAE-94CA-DFD58A0F1609@employees.org> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <54AD315E-301D-4052-9F0F-5E085C026094@employees.org> <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com> <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com> <4c052d3c-7c57-c0b3-1dd3-de764eb99c13@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 14:25:29 -0000 Brian, et al, >>>>> By changing "For all unicast addresses" to "all currently = allocated unicast >>>>> addresses", >>>>>=20 >>>>> Are you proposing to reverse the decision that was made back when = RFC3513 >>>>> updated RFC2373? >>>>> Change log: >>>>> - Revised sections 2.4 and 2.5.6 >>>>> to simplify and clarify how >>>>> different address types are identified. This was done to = insure >>>>> that implementations do not build in any knowledge about = global >>>>> unicast format prefixes. Changes include: >>>>> o Removed Format Prefix (FP) terminology >>>>> o Revised list of address types to only include exceptions = to >>>>> global unicast and a singe entry that identifies = everything >>>>> else as Global Unicast. >>>>=20 >>>> Not speaking for Brian, my reaction to the RFC 3513 text would be = that Brian's new text better responds to "This was done to insure that = implementations do not build in any knowledge about global unicast = format prefixes." >>>>=20 >>>> We have a pragmatic requirement of 64-bit IIDs, for the existing = (minority) of assigned global unicast addresses. But we don't want to = reverse the intention for CIDR, stated in RFC 3513. This is the = "tension" with CIDR, which has existed for too many years. >>>=20 >>> Indeed. I've taken out the explicit text that people objected to, = but if another /3 >>> is released to IANA and the RIRs, don't we want to keep our options = open? >>=20 >> This isn't the right place to change the consensus that has held = since 3513. >=20 > I agree with that, and it isn't my intention. Ah, excellent that wasn't clear to me. >> Making this change would require a much deeper analysis of why the = reasons outlined above don't apply anymore. >> You are essentially proposing to redefine the meaning of "Global = Unicast". >=20 > Well, I don't agree. I was just trying to confirm that the current = rule applies > to the whole of 2000::/3, without closing off future options. >=20 > Actually it might have been better if this magic number had been left = out > of the addressing architecture and included in the SLAAC = specification, but > it's years too late to change that. - There is no magic number in 4291 (The format prefix was removed in = 2373 -> 3513.) - The global unicast address space is defined as everything else than = (000, etc) - The 64-bit boundary applies to _all_ of the global unicast address = space - SLAAC is _not_ restricted to only 2000::/3 - IANA only assigns addresses out of 2000::/3 There was an explicit change to avoid implementations building in = knowledge about global unicast format prefixes. That means that today, all of the global unicast address space (the = 7/8ths) has the 64-bit boundary and of course can be used by SLAAC. If we got the addressing model (and the 64-bit boundary) wrong: - the safety valve is that addresses are only currently assigned from = 2000::/3. - a new document replacing 4291 would be required - implementations would have to be updated and a new format prefix would = be used Can the 64-bit boundary be changed within 2000::/3? Possibly, but someone would have to write a draft on that. This isn't a change that can be snuck in between working group last call = and IETF last call. >> And please note that 4291 already has provisions for this: >> Section 2.4: >> Future specifications may redefine one or more sub-ranges of the >> Global Unicast space for other purposes, but unless and until that >> happens, implementations must treat all addresses that do not start >> with any of the above-listed prefixes as Global Unicast addresses. >=20 > Right. So 4000::1234 is clearly a unicast address, but if not used for > SLAAC, it doesn't need a defined IID length. That's where we have = muddled > things a bit between the addressing architecture and the SLAAC spec. As currently specified, if the IETF's action was only to make e.g. = 4000::/3 available for the IANA for assignment, it would be address = space behaving exactly like 2000::/3. Ole= From nobody Sat Jan 21 06:29: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 B3218129A91 for ; Sat, 21 Jan 2017 06:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV5HgH3oLhI4 for ; Sat, 21 Jan 2017 06:29:36 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 11F54129A8F for ; Sat, 21 Jan 2017 06:29:36 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 21 Jan 2017 14:29:36 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CAF9DD788D; Sat, 21 Jan 2017 06:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=WO72in536/hre9gOL1yCf+/oIVM=; b=ahlR7FrK88lOFzh9hi OrezDEkMmsB1lYRjSloktrdNgAl3sKdrZayGTpd7uoHZaCQkdfkluwHxsIIG9R2A 9i+Ka38x0a5JdOVyRy5HiV+0qZpBRKH+6B6MtxFymsV5Zs0R2xjif+AHxktHsC7E o+bCqInun7bfwrP34cTJ/T2oU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=JogXqt1jPvxD7e9Q9GaEYBKyTbyzfjpHQb1wFFTBEPKE/FYQjht ik1/3w91qjG3oPX+lZPFjr7sSGVsqulKq/ms4cYCwwRhUJNtgq2yIfrw1fObL4T7 H7VETqHOlE+9MA+Oa1pAKKjyqdmhEQiwmn0/I9DWf/PETUy98OQvOP1U= Received: from h.hanazo.no (37.253.248.180.tmi.telenormobil.no [37.253.248.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 64024D788A; Sat, 21 Jan 2017 06:29:35 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C440279C2EDA; Sat, 21 Jan 2017 15:29:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: otroan@employees.org In-Reply-To: <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> Date: Sat, 21 Jan 2017 15:29:30 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 14:29:37 -0000 > Yes, I take your point. Maybe we can all close this thread now and you > can decide what to put in the next draft. A point of order. The document is now in AD Evaluation state. (https://datatracker.ietf.org/help/state/draft/iesg) Ole From nobody Sat Jan 21 06:58: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 DF842129AD1 for ; Sat, 21 Jan 2017 06:58:47 -0800 (PST) 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 dvBUx2pMO-v0 for ; Sat, 21 Jan 2017 06:58:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542F2129A97 for <6man@ietf.org>; Sat, 21 Jan 2017 06:58:45 -0800 (PST) Received: from [192.168.3.102] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BE1E282B45; Sat, 21 Jan 2017 15:58:41 +0100 (CET) To: "6man@ietf.org" <6man@ietf.org> From: Fernando Gont Subject: draft-ietf-6man-rfc4291bis-06: RFC4941 and comment on stable addresses X-Enigmail-Draft-Status: N1110 Message-ID: <2a65f642-e339-8bb1-229a-be589d818635@si6networks.com> Date: Sat, 21 Jan 2017 11:54:25 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc4291bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 14:58:48 -0000 Folks, Just happened to take a look at the I-D and have two comments: 1) The doc says: " The details of forming interface identifiers are defined in other specifications, such as "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"[RFC7217]. " While the text is not really incorrect, this one being a bis document to move rfc4291 to full std, referencing RFC4941 as is has two problems: 1) It would change the current operating model, where nodes employ stable addresses -- in which temp addresses are *additional* (to stable addresses) and an optional feature 2) Referenced "as is", it would seem that RFC4941 is an alternative to stable addresses, but as already discussed on this list, RFC4941 is specified such that temporary addresses are generated in addition to the stable ones. Side comment: The Security Considerations states: " One area relavant to IPv6 addressing is privacy. IPv6 addresses can be created using interface identifiers constructed with unique stable tokens. The addresses created in this manner can be used to track the movement of devices across the Internet." Based on the terminology in RFC7721, it is *constant* tokens (not stable) that would allow traking across the Internet. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 22 03:10:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE81295E3 for ; Sun, 22 Jan 2017 03:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 MPh1UQhtBP83 for ; Sun, 22 Jan 2017 03:10:53 -0800 (PST) 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 0D87D129574 for <6man@ietf.org>; Sun, 22 Jan 2017 03:10:53 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 35so92312663uak.1 for <6man@ietf.org>; Sun, 22 Jan 2017 03:10:52 -0800 (PST) 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=YrKcKEuCMRR1KI3Ks6AhmTobAdhLmC4+F2DOrPe5/8Y=; b=Hmh04tZfziGgVE11cqP8UCNvMF9BIN/4RwizNJlZkCaKWjPzyGxftsTtRJR8Wu60qx 5L9jGFHX+3Iaf/HVe4+uUkWtCc1h4aLEQlRquhBhXOm4mEgYkPkjcO18T8pF9BuCR8st gOxcXRLl4+u+m0PQWqBE4nB+g1/QmfepolPTh+44oimiZ+oukohEzopaDMplcw9hHTEM S9z6/NNat1dOkVq3GHB6h+4Eq547wZq2oOmNNrLZmsXSyL6yckuxdoOlz43ZJQ1CK7Fe l9r1ThSbh5qdmn2AZLS/88sijKBJLlR4qi6wUo96QOAKR8Nyc6LRO+4f7/6Vdo41p21i WDsg== 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=YrKcKEuCMRR1KI3Ks6AhmTobAdhLmC4+F2DOrPe5/8Y=; b=mc15zl12Rv6t6s+zPxu9kiTsS1dJT4+l7AC9fS5O0BIdW8FAy0Lpyo5A6AIdEOF11D y8bjgZFqE/6hwLUyu7wKJZQo4a47P6biCkFVy09b+kCFsIFWyhzFmG69OsMSlJW0eUM4 dvafZnphxQHGYk/pBuEca9Bh3imRcWrU5NiCC+o+t6lGSypKePPgJL+iswensFUxzdJl 01f4xeWSXK1t2YYoWSXE53PfWLtBvXA8L17lypH8gleCVQ4eAlPNFHMlWX3fjqPuaYj1 sq9B9mgR5aEsQpgBRdtJZJRZyG8Gd4mU6a2aaASOLfA0hBN7e83d0WXbZVOTHgaSl80+ k1mQ== X-Gm-Message-State: AIkVDXINs9GtgFJ4eAfqf6tVh0V56/z7S9jaGDuzAou1rWPppsGyl2tkiZTyv0/EAvplMSqJkptf/XR/Ymh4F/V5 X-Received: by 10.159.40.194 with SMTP id d60mr12813435uad.122.1485083451902; Sun, 22 Jan 2017 03:10:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Sun, 22 Jan 2017 03:10:31 -0800 (PST) In-Reply-To: <2a65f642-e339-8bb1-229a-be589d818635@si6networks.com> References: <2a65f642-e339-8bb1-229a-be589d818635@si6networks.com> From: Lorenzo Colitti Date: Sun, 22 Jan 2017 20:10:31 +0900 Message-ID: Subject: Re: draft-ietf-6man-rfc4291bis-06: RFC4941 and comment on stable addresses To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c1245be9d1fec0546acef7f Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-rfc4291bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 11:10:54 -0000 --94eb2c1245be9d1fec0546acef7f Content-Type: text/plain; charset=UTF-8 On Sat, Jan 21, 2017 at 11:54 PM, Fernando Gont wrote: > 1) The doc says: > " The details of forming interface identifiers are defined in other > specifications, such as "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating > Semantically Opaque Interface Identifiers with IPv6 Stateless Address > Autoconfiguration (SLAAC)"[RFC7217]. " > > While the text is not really incorrect, this one being a bis document to > move rfc4291 to full std, referencing RFC4941 as is has two problems: > > 1) It would change the current operating model, where nodes employ > stable addresses -- in which temp addresses are *additional* > (to stable addresses) and an optional feature > That text doesn't change anything. RFC4941 specifies that temporary addresses are additional to "public" addresses. > 2) Referenced "as is", it would seem that RFC4941 is an alternative > to stable addresses, but as already discussed on this list, RFC4941 > is specified such that temporary addresses are generated in > addition to the stable ones. > The text doesn't imply that at all. It simply says that those are two ways of generating IIDs, which they are. --94eb2c1245be9d1fec0546acef7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 21, 2017 at 11:54 PM, Fernando Gont <fgont@si6networks.com> wrote:
1) The doc says:
"=C2=A0 The details of forming interface identifiers are defined in ot= her
=C2=A0 =C2=A0specifications, such as "Privacy Extensions for Stateless= Address
=C2=A0 =C2=A0Autoconfiguration in IPv6" [RFC4941] or "A Method fo= r Generating
=C2=A0 =C2=A0Semantically Opaque Interface Identifiers with IPv6 Stateless = Address
=C2=A0 =C2=A0Autoconfiguration (SLAAC)"[RFC7217]. "

While the text is not really incorrect, this one being a bis document to move rfc4291 to full std, referencing RFC4941 as is has two problems:

=C2=A0 1) It would change the current operating model, where nodes employ =C2=A0 =C2=A0 =C2=A0stable addresses -- in which temp addresses are *additi= onal*
=C2=A0 =C2=A0 =C2=A0(to stable addresses) and an optional feature

That text doesn't change anything. RFC4941 s= pecifies that temporary addresses are additional to "public" addr= esses.
=C2=A0
=C2=A0 2) Refer= enced "as is", it would seem that RFC4941 is an alternative
=C2=A0 =C2=A0 =C2=A0to stable addresses, but as already discussed on this l= ist, RFC4941
=C2=A0 =C2=A0 =C2=A0is specified such that temporary addresses are generate= d in
=C2=A0 =C2=A0 =C2=A0addition to the stable ones.

<= /div>
The text doesn't imply that at all. It simply says that those= are two ways of generating IIDs, which they are.
--94eb2c1245be9d1fec0546acef7f-- From nobody Sun Jan 22 23:51: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 D48C61295D2 for ; Sun, 22 Jan 2017 23:51:54 -0800 (PST) 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 PGghRC-XNhhX for ; Sun, 22 Jan 2017 23:51:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EED1295D1 for <6man@ietf.org>; Sun, 22 Jan 2017 23:51:52 -0800 (PST) Received: from [192.168.3.102] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1011A82BFB; Mon, 23 Jan 2017 08:51:48 +0100 (CET) Subject: Re: draft-ietf-6man-rfc4291bis-06: RFC4941 and comment on stable addresses To: Lorenzo Colitti References: <2a65f642-e339-8bb1-229a-be589d818635@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <7a46b4c8-9dab-8da5-1d60-eaae0910d2af@si6networks.com> Date: Mon, 23 Jan 2017 03:28:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-rfc4291bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 07:51:55 -0000 On 01/22/2017 08:10 AM, Lorenzo Colitti wrote: > On Sat, Jan 21, 2017 at 11:54 PM, Fernando Gont > wrote: > > 1) The doc says: > " The details of forming interface identifiers are defined in other > specifications, such as "Privacy Extensions for Stateless Address > Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating > Semantically Opaque Interface Identifiers with IPv6 Stateless Address > Autoconfiguration (SLAAC)"[RFC7217]. " > > While the text is not really incorrect, this one being a bis document to > move rfc4291 to full std, referencing RFC4941 as is has two problems: > > 1) It would change the current operating model, where nodes employ > stable addresses -- in which temp addresses are *additional* > (to stable addresses) and an optional feature > > > That text doesn't change anything. RFC4941 specifies that temporary > addresses are additional to "public" addresses. This document is a bis document, which is not expected to change anything, right? RFC4291 was only about stable addresses. Hence referencing temporary addresses can be misleading. For instance, RFC4291 does 4291 does not contain any references to RFC3041. > 2) Referenced "as is", it would seem that RFC4941 is an alternative > to stable addresses, but as already discussed on this list, RFC4941 > is specified such that temporary addresses are generated in > addition to the stable ones. > > The text doesn't imply that at all. It simply says that those are two > ways of generating IIDs, which they are. Again, I think that'd be misleading. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 23 00:11: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 D19EA1294AC for ; Mon, 23 Jan 2017 00:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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 Yp6Gl5yq08AR for ; Mon, 23 Jan 2017 00:11:15 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376C112949E for <6man@ietf.org>; Mon, 23 Jan 2017 00:11:15 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id t8so85707860vke.3 for <6man@ietf.org>; Mon, 23 Jan 2017 00:11:15 -0800 (PST) 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=lUrze+uytOMBfoHTzFsrA7GgY25FV/PmUYyNwynzRyg=; b=o24w2cai8FZUlGygQUMe2Hcx7dHV89ukjo+6+4yrowyaisPlguBdaaVNovTD2Nh9aS f9XlXFe3VH7dButhXht1U/lR6Ny2o3SNmIWWvFSakXKEreXqfb+C4cMVgrrtUtBebo11 ftvxsEzbE1ayLBAwTPeOHkUcKYAMTouc+pvv7d5HHF5DVFy7J8xtGNdyK8kf8E53EO0a RURohq7WSzDaOas1TvlI0G12aBFe2dkhBIWoKIp83sp2fZu69n6V9d97u6UInRWzjwSQ /LBi1MXEwJFpGjs9Dz43qE7k5gYXJOBE/bxZZI4JY+GcNoI/EL/lxu9ZLRZcO/UAJNyy WT7Q== 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=lUrze+uytOMBfoHTzFsrA7GgY25FV/PmUYyNwynzRyg=; b=q0jyj9r6Evlzhe0GRnurMvIZtNINiNHftRz9kymT1+PMhvPMa/CmBTqoQh21tMrCqW msaCR1M87Msc+2EeBmURvv3LUpJD/E6PtOHG6ZjjKNfUdYzpIdftEA5BP5In8sEqKwfb 41WBZRLQp/y894xiK2ztw8+xi+ZArwf+uKnpjtEAh54JEIerqi3VF37Tai9p8VSCrYkC KFCDCFkg4giB4WeCjfem5A/MsR3aljuI2Y/xOjaMidkxjF6M4oHRkKJ1jBdL9kDC6zxS PTWdgIE1ZHH4dw5x25pMV3rq3AkwoB4CzcRo8xJQqx2gCet11+7oTuWaHdvWH0YLx9zO RnUg== X-Gm-Message-State: AIkVDXIR063Kl14PssVYmX0vLYcaMcGRKC7LFJC/atj0jxTj0gKdiauQ7FAgHMOYCQkEwZh0cfXGxW2EpUcBILKy X-Received: by 10.31.248.193 with SMTP id w184mr13006898vkh.10.1485159074028; Mon, 23 Jan 2017 00:11:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 23 Jan 2017 00:10:53 -0800 (PST) In-Reply-To: <7a46b4c8-9dab-8da5-1d60-eaae0910d2af@si6networks.com> References: <2a65f642-e339-8bb1-229a-be589d818635@si6networks.com> <7a46b4c8-9dab-8da5-1d60-eaae0910d2af@si6networks.com> From: Lorenzo Colitti Date: Mon, 23 Jan 2017 17:10:53 +0900 Message-ID: Subject: Re: draft-ietf-6man-rfc4291bis-06: RFC4941 and comment on stable addresses To: Fernando Gont Content-Type: multipart/alternative; boundary=94eb2c14bd2a0b918e0546be8bad Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-rfc4291bis@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:11:17 -0000 --94eb2c14bd2a0b918e0546be8bad Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 3:28 PM, Fernando Gont wrote: > This document is a bis document, which is not expected to change > anything, right? > And it doesn't. Whether RFC 4941 is cited in this document or not doesn't change the normative effects of this document, since it's only provided as an example. > RFC4291 was only about stable addresses. Hence referencing temporary > addresses can be misleading. For instance, RFC4291 does 4291 does not > contain any references to RFC3041. > RFC 4291 is not just about stable addresses, it's about all addresses (multicast, unicast, stable, unstable, manual, autoconfigured, random, ...). It says that "all unicast addresses [...][are] constructed in modified EUI-64 format". That includes RFC 4941 privacy addresses, which are in modified EUI-64 format (they set bit 6 to 0). --94eb2c14bd2a0b918e0546be8bad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 23, 2017 at 3:28 PM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
This= document is a bis document, which is not expected to change
anything, right?

And it doesn't. Wh= ether RFC 4941 is cited in this document or not doesn't change the norm= ative effects of this document, since it's only provided as an example.=
=C2=A0
RF= C4291 was only about stable addresses. Hence referencing temporary
addresses can be misleading. For instance, RFC4291 does 4291 does not
contain any references to RFC3041.

RFC = 4291 is not just about stable addresses, it's about all addresses (mult= icast, unicast, stable, unstable, manual, autoconfigured, random, ...). It = says that "all unicast addresses [...][are] constructed in modified EU= I-64 format". That includes RFC 4941 privacy addresses, which are in m= odified EUI-64 format (they set bit 6 to 0).
--94eb2c14bd2a0b918e0546be8bad-- From nobody Mon Jan 23 03:50:08 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1941295BB for ; Mon, 23 Jan 2017 03:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 AhCeBgIwfmFU for ; Mon, 23 Jan 2017 03:50:02 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12501270B4 for ; Mon, 23 Jan 2017 03:50:01 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=41178 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVd8F-0008GB-Az; Mon, 23 Jan 2017 12:49:55 +0100 Date: Mon, 23 Jan 2017 12:49:54 +0100 From: Tore Anderson To: Lorenzo Colitti Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Message-ID: <20170123124954.13329c33@echo.ms.redpill-linpro.com> In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man , Erik Kline X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 11:50:07 -0000 * Lorenzo Colitti > As explained before, there is no conflict between RFC 4291 and RFC > 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link > addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can > you clarify what you mean? Isn't there a conflict with RFC 6052, though? E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96, the IPv4-translatable representation of an IPv4 subnet such as 192.0.2.0/24 would be 2001:db8:6052::192.0.2.0/120 (2001:db8:6052::c000:200/120) and nodes in this subnet/link would necessarily have 8 bit long IIDs. Right? Tore From nobody Mon Jan 23 05:37: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 326FC1295F8 for ; Mon, 23 Jan 2017 05:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 Z8C2U2BV04BZ for ; Mon, 23 Jan 2017 05:37:49 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 8D1D712950B for ; Mon, 23 Jan 2017 05:37:49 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 35so109742467uak.1 for ; Mon, 23 Jan 2017 05:37:49 -0800 (PST) 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=RVMRVMhWweQ9VHsWtSybXmoP/VkRQ+FYCdJAODC0Tus=; b=ryNYOW71uj+dRNs8wnssTw/lBpPeT9ZAcgDbJECxaE2hugCXfB8JxxL8njm2JxU1b8 5oJDTcmdpZmW/QN70Zi3FbfNVkH/+j30qPSX1sKFJOqrrERB0EFWJHfDokNsNIATkMg1 CKaWsA6rG05Jel2J6SBl8bLhWezvX/Qe/iqpxlOKqSp8nm1lOyyZLi4r6z47EB7n8tfi oSrR75XlZUcpruD40FlCZTwOeiiR7mlIIyxLMNR/fjPESZkGa3887yahFZ0C9wSPCT9C b4scB1weY/9dvFXAdCgA7mUeRP1xVjBYFqtWq0rO7txwGruRTkixuk+tAxwPlyRipFVY HmMg== 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=RVMRVMhWweQ9VHsWtSybXmoP/VkRQ+FYCdJAODC0Tus=; b=icIbMEHHrD8R9zcp0RPbfQqaRYtfptE0n8ko4yXMPLervP2AHw/s12UE363jC87DW0 /7ppKJWXcmPmN+MrJ9RaFjLCC2aBv6GVBd5KBLHmAzfOo+9m4bUzGWFvpBQJoJtOW1KT FX3ivs6iI7IMCr2t7n2HYiFuhfLmpg5zCj3IaBoTVOlD0sBRWY9inCWp9W9fZDlmZaIN Ux7u5f1S8TuvK5GF74aXOb59nEpsxyNTAT0yVZnqXUQNmXBU+b5AOaauheR0BbNhpPtY moyrzxgzXqbNc+mCb5fSImMhG7VB9m8IbzBTxFYk3K1Xd9OnFvPH1bBUva8AU/PQb3I1 xRYg== X-Gm-Message-State: AIkVDXKTGB7VO98z6R8LCyjkeZZJeJm/NMx5pTGYwlgsPs9c62wey3AJ0z6pAM7TeouHSvEyUqnWhaPg55HTU8WU X-Received: by 10.176.7.209 with SMTP id d17mr15816196uaf.171.1485178668564; Mon, 23 Jan 2017 05:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Mon, 23 Jan 2017 05:37:27 -0800 (PST) In-Reply-To: <20170123124954.13329c33@echo.ms.redpill-linpro.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <20170123124954.13329c33@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Mon, 23 Jan 2017 22:37:27 +0900 Message-ID: Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] To: Tore Anderson Content-Type: multipart/alternative; boundary=f403045f7f26f812d00546c31a39 Archived-At: Cc: 6man , Erik Kline X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 13:37:51 -0000 --f403045f7f26f812d00546c31a39 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 8:49 PM, Tore Anderson wrote: > > As explained before, there is no conflict between RFC 4291 and RFC > > 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link > > addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can > > you clarify what you mean? > > Isn't there a conflict with RFC 6052, though? > > E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96, the > IPv4-translatable representation of an IPv4 subnet such as 192.0.2.0/24 > would be 2001:db8:6052::192.0.2.0/120 (2001:db8:6052::c000:200/120) and > nodes in this subnet/link would necessarily have 8 bit long IIDs. Right? > I'm not sure it makes sense to draw that conclusion. If you follow that reasoning, /96 might make sense, but all the other RFC 6052 prefix lengths don't really make sense. For example, if the NSP is 64 bits, how long would the IID be? If you say 8 bits, then that means there are 2^40 addresses routed to the same host, which means that the prefix length (88) plus the IID length (8) does not add up to 128. And if you say 48 bits, then that means that a host has 2^40 interface IDs for the same interface, so the interface ID isn't really an ID any more. --f403045f7f26f812d00546c31a39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 23, 2017 at 8:49 PM, Tore Anderson <tore@fud.no> wrote:
&= gt; As explained before, there is no conflict between RFC 4291 and RFC
> 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link
> addressing. I don't see a conflict between RFC 5942 and RFC 4291. = Can
> you clarify what you mean?

Isn't there a conflict with RFC 6052, though?

E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96, the IPv4-translatable representation of an IPv4 subnet such as 192.0.2.0/24
would be 2001:db8:6052::192.0.2.0/120 (2001:db8:6052::c000:200/120) and
nodes in this subnet/link would necessarily have 8 bit long IIDs. Right?

I'm not sure it makes sense to draw t= hat conclusion.

If you follow that reasoning, /96 = might make sense, but all the other RFC 6052 prefix lengths don't reall= y make sense. For example, if the NSP is 64 bits, how long would the IID be= ? If you say 8 bits, then that means there are 2^40 addresses routed to the= same host, which means that the prefix length (88) plus the IID length (8)= does not add up to 128. And if you say 48 bits, then that means that a hos= t has 2^40 interface IDs for the same interface, so the interface ID isn= 9;t really an ID any more.
--f403045f7f26f812d00546c31a39-- From nobody Mon Jan 23 06:15: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 ECF8F12960A for ; Mon, 23 Jan 2017 06:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 rxKHaMqAFkiN for ; Mon, 23 Jan 2017 06:15:44 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF47A12960C for ; Mon, 23 Jan 2017 06:07:45 -0800 (PST) Received: from [2a02:fe0:c420:6ae::c68] (port=58554 helo=envy.e1.y.home) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cVfHc-0005Tb-3y; Mon, 23 Jan 2017 15:07:44 +0100 Date: Mon, 23 Jan 2017 15:07:43 +0100 From: Tore Anderson To: Lorenzo Colitti Subject: Re: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06] Message-ID: <20170123150743.6960611b@envy.e1.y.home> In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <93700502-5d49-86ce-11b0-ab9904423961@gmail.com> <20170123124954.13329c33@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Erik Kline , 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 14:15:45 -0000 * Lorenzo Colitti > On Mon, Jan 23, 2017 at 8:49 PM, Tore Anderson wrote: >=20 > > Isn't there a conflict with RFC 6052, though? > > > > E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96, > > the IPv4-translatable representation of an IPv4 subnet such as > > 192.0.2.0/24 would be 2001:db8:6052::192.0.2.0/120 > > (2001:db8:6052::c000:200/120) and nodes in this subnet/link would > > necessarily have 8 bit long IIDs. Right? >=20 > I'm not sure it makes sense to draw that conclusion. >=20 > If you follow that reasoning, /96 might make sense, but all the other > RFC 6052 prefix lengths don't really make sense. For example, if the > NSP is 64 bits, how long would the IID be? If you say 8 bits, then > that means there are 2^40 addresses routed to the same host, which > means that the prefix length (88) plus the IID length (8) does not > add up to 128. And if you say 48 bits, then that means that a host > has 2^40 interface IDs for the same interface So with an NSP of 2001:db8:6052::/64, the IPv4 link subnet of 192.0.2.0/24 would be as I understand it be represented as 2001:db8:6052:0:c0:2::/96. In the =C2=ABvanilla=C2=BB RFC7915 operational mode, the default gateway on= that link (a.k.a. 192.0.2.1 from the IPv4 point of view) would be configured with 2001:db8:6052:0:c0:2:100:0/96, the node reachable at 192.0.2.10 would have 2001:db8:6052:0:c0:2:a00:0/96, 192.0.2.254 would be 2001:db8:6052:0:c0:2:fe00:0/96, and so on. The IPv6 addresses you actually need to configure on the routers and the nodes on this link will have an IPv6 prefix length of /96, so wouldn't that mean that the IIDs in question are 32 bits long? > the interface ID isn't really an ID any more. I suppose you can look at it that way too...but wouldn't that then mean that you're essentially saying that you can have whatever amount of suffix/node/host bits in an IPv6 address you'd like, but you're only allowed to call it an =C2=ABIID=C2=BB if it just so happens to be exactly 6= 4 of them? :-) Tore From nobody Mon Jan 23 07:36: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 2A73012962A for ; Mon, 23 Jan 2017 07:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 UCp5m9aJdIpP for ; Mon, 23 Jan 2017 07:36:11 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58921129609 for ; Mon, 23 Jan 2017 07:36:11 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 9D231E6065; Mon, 23 Jan 2017 16:36:09 +0100 (CET) Date: Mon, 23 Jan 2017 16:36:09 +0100 (CET) Message-Id: <20170123.163609.74661096.sthaug@nethelp.no> To: tore@fud.no Subject: Re: IID length text From: sthaug@nethelp.no In-Reply-To: <20170123150743.6960611b@envy.e1.y.home> References: <20170123124954.13329c33@echo.ms.redpill-linpro.com> <20170123150743.6960611b@envy.e1.y.home> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 15:36:13 -0000 > > the interface ID isn't really an ID any more. > = > I suppose you can look at it that way too...but wouldn't that then me= an > that you're essentially saying that you can have whatever amount of > suffix/node/host bits in an IPv6 address you'd like, but you're only > allowed to call it an =ABIID=BB if it just so happens to be exactly 6= 4 of > them? :-) Isn't that how IPv6 is sometimes used in the real world? E.g. transit providers who insist on a non-64 bit mask on the transit links. Anybody who believes that only /64 (and /127) is in use on interfaces in the real world is seriously deluded. Steinar Haug, AS2116 From nobody Mon Jan 23 11:33: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 79D031297CF for ; Mon, 23 Jan 2017 11:33:39 -0800 (PST) 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 BFj9tx_sQwv5 for ; Mon, 23 Jan 2017 11:33:38 -0800 (PST) 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 2A7A21297CE for ; Mon, 23 Jan 2017 11:33:38 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 14so47302773pgg.1 for ; Mon, 23 Jan 2017 11:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0BXc8pbDg2KSaB793Et4w6IwJOqnikEEiZzI82acagM=; b=hVUL1Ljsk3WrJqrZzfxlnLoJ8KKKKQdcvqkUziI+FP33e7Ng5CcNWJGmU/17YfBGu1 9Dl4gfuLZweTcaSHQ7n865JOJk+gBMpFObv8BCxjlt0sSIwNsYf1sIxE7F+rVwsy2KVI lHIv6IpTUHvGyXzTNXgE6TUsDcIE8sIgMcKlmcTAHqXpzx+qHqZP+MQEArEHI0FDVSWS ldE2tDzfB6vYlzLioq5hCUKsQKsZvcCP9clRb3gTc0VE04HPe+U1Be88soGS9nM4bwJ4 JMBo5czNtfYOYuOLsQkGeZrTiYIV8xaF31eo3KrcWMbHEmDoNL661kO1BS9gvBHh4/zM HRvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=0BXc8pbDg2KSaB793Et4w6IwJOqnikEEiZzI82acagM=; b=BQ8nIc2GcNcMgFX2Y12ydQN0rmRBrRQcBvrHhxY/pmDphKwLZcgP/CGaRlIci3yFx5 gxK7QtMh5lqp2bj1W+ZRG4B13dLA+mBMT1ARu8S3R27a1TEsRbT6pYsP2oXxER+ZZ3+G R4rcG5Zznv2AIs8mskv6ozMEw/f2Ci5OLKsR9srZOf+0GLtDf5TpMcZBNZBD5G2G+W06 S179Q+nyYyCy9JXL5FwDdxa5wNoo0fwCFLsoenNtRRlwrMWPfJPdM66yn1WHBSqLWk0O SGmxRsV3xmrCAnIezk4LD2Tglxa5YudFh4ItmNnj1AR05Edro/FT69yj44HE1zzcn+2Z Gx0Q== X-Gm-Message-State: AIkVDXIwzQNctKGKY2nNVFdRF+jRKQsPI+/7bFqWEQX1HDaFP3uaf80KCdG0WMWNoHqbqw== X-Received: by 10.84.211.137 with SMTP id c9mr44887940pli.8.1485200017536; Mon, 23 Jan 2017 11:33:37 -0800 (PST) Received: from ?IPv6:2406:e007:6c0c:1:28cc:dc4c:9703:6781? ([2406:e007:6c0c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p2sm39105211pgd.17.2017.01.23.11.33.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 11:33:36 -0800 (PST) Subject: Re: IID length text To: ipv6@ietf.org References: <20170123124954.13329c33@echo.ms.redpill-linpro.com> <20170123150743.6960611b@envy.e1.y.home> <20170123.163609.74661096.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 24 Jan 2017 08:33:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170123.163609.74661096.sthaug@nethelp.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:33:39 -0000 On 24/01/2017 04:36, sthaug@nethelp.no wrote: >>> the interface ID isn't really an ID any more. >> >> I suppose you can look at it that way too...but wouldn't that then mea= n >> that you're essentially saying that you can have whatever amount of >> suffix/node/host bits in an IPv6 address you'd like, but you're only >> allowed to call it an =C2=ABIID=C2=BB if it just so happens to be exac= tly 64 of >> them? :-) >=20 > Isn't that how IPv6 is sometimes used in the real world? E.g. transit > providers who insist on a non-64 bit mask on the transit links. >=20 > Anybody who believes that only /64 (and /127) is in use on interfaces > in the real world is seriously deluded. Indeed. But I think the point has been hammered home and I expect that the draft will be wordsmithed accordingly before we see a new version. Brian From nobody Mon Jan 23 14:41: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 E4C7E1298A1 for ; Mon, 23 Jan 2017 14:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_Mr2VrG5uhF for ; Mon, 23 Jan 2017 14:41:18 -0800 (PST) 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 464D81299B2 for ; Mon, 23 Jan 2017 14:41:08 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l7so151062879qtd.1 for ; Mon, 23 Jan 2017 14:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H88iYfWlvQU+nJl3HJ8agG6/iJ/U89Rtjg7BmGPzI0Y=; b=dhg7j3MOFwFU4pfO+VgXn+ywoW7Rlvktb6Q//jg4kyMwi1oLdcFA+bppXfek4s8gFh ue02KXlmbbv1z/3ryd/ktCGSJBHAxb6ImvtItKNzUcLu4p4jGXa10/UjrPRUs0CDUbO3 AYHg49DzZqAdVJJqmkR6UJAEPawx6ov4YuwygBFVkK0VrwdlyoqNkuVtNp0TFWhXOsE6 8yitDWT8jZozH4+zgWE5eGHBuHVqDhDZFogt5zUeLasrEiND0fQp+lDq1y7a28Wu/PlQ 6M3/cJoGiI4cGpe4GoKXySSG4jrYgzbai9Zv3qtCIFaDXq/Mi49KAi73RX72b1wQo05c XlPw== 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=H88iYfWlvQU+nJl3HJ8agG6/iJ/U89Rtjg7BmGPzI0Y=; b=YUhC0qWqLw9kd1H5Ox1r0wnlU04FT8o9fhLyijDHUbkhUmWM3fIHg6p78UE/C9STkX muNXTAa+c//r9/qgIRyVfw2imrXiS5Zs98VSbXPkFq+F1bw+VyyFbvcVvlPv1FMcw7L1 0qG5AjiKdOmdrk100A4q+7UkkpwU+2Yt+PajYwhoUXBWlqPsCxKKXWp4VG75qa5YKQ9t LpwKoIE7Wpl4YRgQgCNbV37mI2++a2glg6LepGew1Z0lHC6lZEIKpRqQoI3it7RdU574 22j/CR+y8Pk113wRZsyN/ln57Jp9w8BsV9EbeU34yDJjDvq/QWUac4mvS13ySzNaL+nM Ka7g== X-Gm-Message-State: AIkVDXLstZaCpB3AyImSkLR1aq0GFLLS+XMXbKv9Jiz/FHi3bJLTdaELOJ9xmcno1RKm/g== X-Received: by 10.237.50.229 with SMTP id z92mr25181607qtd.182.1485211267400; Mon, 23 Jan 2017 14:41:07 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id h56sm14272704qte.24.2017.01.23.14.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 14:41:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Updated IID length text From: Bob Hinden In-Reply-To: <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> Date: Mon, 23 Jan 2017 14:41:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1070FE68-62A2-4655-B66A-F0F74D58876C@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:41:20 -0000 Brian, I will work on some new text, but won=E2=80=99t submit anything till = after I get a go ahead from Suresh. Like the other changes from Brian = Haberman=E2=80=99s review. Bob > On Jan 20, 2017, at 6:16 PM, Brian E Carpenter = wrote: >=20 > Bob, >=20 > Yes, I take your point. Maybe we can all close this thread now and you > can decide what to put in the next draft. >=20 > Regards > Brian >=20 > On 21/01/2017 12:53, Bob Hinden wrote: >> Brian, >>=20 >>> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter = wrote: >>>=20 >>> On 20/01/2017 17:38, Lorenzo Colitti wrote: >>>> On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter < >>>> brian.e.carpenter@gmail.com> wrote: >>>>=20 >>>>> However, correct use of Stateless Address Autoconfiguration >>>>> (SLAAC)[RFC4862] requires all interfaces on a link to use the = same >>>>> length >>>>> of Interface ID. Furthermore, to guarantee robust = interoperability of >>>>> SLAAC, >>>>> a consistent length of Interface ID is desirable. For this = reason, >>>>=20 >>>>=20 >>>> I object to the text "for this reason", because SLAAC is not the = only >>>> reason. There are many reasons, many of which are written in 7421, = and two >>>> sentences in this paragraph are not sufficient to describe them. I = propose >>>> the following alternative, which I believe to be normatively = identical: >>>>=20 >>>> IPv6 routing is based on prefixes of any valid length up to 128 = [BCP198]. >>>> For example, [RFC6164] standardises 127 bit prefixes on = point-to-point >>>> links. However, the Interface ID of all currently allocated = unicast addresses, >>>> except those that start with the binary value 000, is required to = be 64 bits >>>> long. The rationale for the 64 bit boundary in IPv6 addresses can = be found in >>>> [RFC7421]. >>>=20 >>> Yes, I'll buy 'however=E2=80=99. >>=20 >> I am generally OK with the text above, but wanted to point out that = Section 2.4. "Unicast Addresses=E2=80=9D there is more than one place = where 64 IIDs are mentioned. This discusion has been about the forth = paragraph in 2.4.1. "Interface Identifiers=E2=80=9D. It is also = mentioned in the second paragraph of 2.4.4. "Global Unicast = Addresses=E2=80=9D. I assume this would have to be modified if the w.g. = decides to adopt this text. >>=20 >> As Ole pointed out there is text that discusses future changes: >>=20 >> 2.3. Address Type Identification >> Future specifications may redefine one or more sub-ranges of the >> Global Unicast space for other purposes, but unless and until that >> happens, implementations must treat all addresses that do not start >> with any of the above-listed prefixes as Global Unicast addresses. >>=20 >> 2.4. Unicast Addresses >> There are several types of unicast addresses in IPv6, in = particular, >> Global Unicast, Local unicast, and Link-Local unicast. There are >> also some special-purpose subtypes of Global Unicast, such as IPv6 >> addresses with embedded IPv4 addresses. Additional address types = or >> subtypes can be defined in the future. >>=20 >> I think that this makes it clear that things are allowed to change in = the future. I don=E2=80=99t think we have to capture this in the single = paragraph in 2.4.1, and there could be other kind of changes as well. >>=20 >> Thanks, >> Bob >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Tue Jan 24 05:30: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 5B92C1297C5 for ; Tue, 24 Jan 2017 05:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, 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 IgFPlXorBZRZ for ; Tue, 24 Jan 2017 05:30:36 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BE7129638 for ; Tue, 24 Jan 2017 05:30:36 -0800 (PST) X-AuditID: c618062d-ab7ff70000007359-38-58875deab0f6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 11.59.29529.AED57885; Tue, 24 Jan 2017 15:00:11 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 08:30:35 -0500 From: Suresh Krishnan To: Robert Hinden Subject: Re: Updated IID length text Thread-Topic: Updated IID length text Thread-Index: AQHScexTEphs/8uw7UCjlzAHkgGpaKE/bE4AgAACpICAAAf0gIABERyAgACWLYCAABnOAIABKKUAgAAoDACABHrZAIAA+GoA Date: Tue, 24 Jan 2017 13:30:34 +0000 Message-ID: <62AC1E85-420D-4CB3-952C-1B2839A914A6@ericsson.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <32A2D0A3-0FA4-40E8-B563-D1F90504E916@gmail.com> <5a804889-9c28-3787-a7d8-4f6bd9661c15@gmail.com> <1070FE68-62A2-4655-B66A-F0F74D58876C@gmail.com> In-Reply-To: <1070FE68-62A2-4655-B66A-F0F74D58876C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: <50EFB404EF9EB74BB3B918D4BE8A96B9@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRPd1bHuEwdFLjBZb3+9js2i7uI/J 4uXZ90wOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8bNn19YC/pYKub2bWRrYGxg6WLk 5JAQMJGY+/cWexcjF4eQwHpGiYMfZ7FBOMsZJf4v/cQEUsUGVLVh52cwW0RAQ+LnnyOMIDaz gJfExcdT2EFsYQEVia/rb7ND1KhKHLrVClWfJ3H75FmwbSxA8abzjcwgNq+AvcTeOf9ZoTZz SKx8NpUVJMEpYCtx+cdFNhCbUUBM4vupNUwQy8Qlbj2ZzwRxtoDEkj3nmSFsUYmXj/+xQthK Eh9/zwc6ggOoXlNi/S59CNNa4uzTIogpihJTuh+yQ5wgKHFy5hOWCYxis5AsmIXQPAuheRaS 5llImhcwsq5i5CgtLsjJTTcy2MQIjKFjEmy6OxjvT/c8xCjAwajEw7shqC1CiDWxrLgy9xCj BAezkgjv2ZD2CCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8cavvhwsJpCeWpGanphakFsFkmTg4 pRoYWwL6GTbdZ/mRbPcp+cMbYbG11brcWYe7Li7VPPrqF9dWr741WT/VLy/+u2HHTuvKgyc8 H/j8V+Lw9Fyb33G51jmfc8VyzZY7R5w9sqdcSnkWdGOdqsW6sE/Fwp1S9xXlpb99YfEK33P5 S8Iifxn3e0c/PJinEXT0zo3Px1Xnf1PaoLsyR+W4jBJLcUaioRZzUXEiAKZcckidAgAA Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 13:30:37 -0000 SGkgQm9iLA0KDQo+IE9uIEphbiAyMywgMjAxNywgYXQgNTo0MSBQTSwgQm9iIEhpbmRlbiA8Ym9i LmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gQnJpYW4sDQo+IA0KPiBJIHdpbGwgd29y ayBvbiBzb21lIG5ldyB0ZXh0LCBidXQgd29u4oCZdCBzdWJtaXQgYW55dGhpbmcgdGlsbCBhZnRl ciBJIGdldCBhIGdvIGFoZWFkIGZyb20gU3VyZXNoLiAgTGlrZSB0aGUgb3RoZXIgY2hhbmdlcyBm cm9tIEJyaWFuIEhhYmVybWFu4oCZcyByZXZpZXcuDQoNClNvdW5kcyBnb29kLiBQbGVhc2UgZ28g YWhlYWQgYW5kIHdvcmsgb24gdGhlIG5ldyB0ZXh0IGFuZCBwb3N0IGl0IHRvIHRoZSBsaXN0IHdo ZW4geW91IGFyZSByZWFkeS4gDQoNClRoYW5rcw0KU3VyZXNoDQoNCg== From nobody Wed Jan 25 19:59: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 0C25B12946B; Wed, 25 Jan 2017 19:59:32 -0800 (PST) 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 Ngl-TVpdAzYj; Wed, 25 Jan 2017 19:59:31 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162C4129468; Wed, 25 Jan 2017 19:59:31 -0800 (PST) X-AuditID: c6180641-e73ff70000000a0b-10-58891fb4e7f6 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 2C.E8.02571.4BF19885; Wed, 25 Jan 2017 22:59:18 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 22:59:28 -0500 From: Suresh Krishnan To: "draft-ietf-6man-rfc1981bis.all@ietf.org" Subject: AD evaluation: draft-ietf-6man-rfc1981bis-03 Thread-Topic: AD evaluation: draft-ietf-6man-rfc1981bis-03 Thread-Index: AQHSd4iWxq+eHy7wFEedQHnPCBKYwA== Date: Thu, 26 Jan 2017 03:59:27 +0000 Message-ID: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: <76F1E59602D3354C95BFE3A9460D5C3E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyuXRPoO42+c4IgzfNehbH1r5msXh59j2T A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyfm3/wlrQwFsxd/98lgbGKzxdjJwcEgImEv92rmbu YuTiEBJYzyix+l8/E4SznFGi9ft0ZpAqNqCqDTs/M4HYIgKREk/W7WIDsZkFpCVuLXkOFOfg EBYwlVi/ihOixEqiZ8UVdghbT2LN0wlgrSwCqhLfTnaBlfMK2Evs+SgNEmYUEJP4fmoNE8RE cYlbT+YzQdwmILFkz3lmCFtU4uXjf6wQtpLEnNfXmEHGMAtoSqzfpQ/Rai3xc95HFghbUWJK 90OwC3gFBCVOznzCMoFRZBaSDbMQumch6Z6FpHsWku4FjKyrGDlKiwtyctONDDcxAoP/mASb 4w7Gvb2ehxgFOBiVeHgNWjsihFgTy4orcw8xSnAwK4nwpl8GCvGmJFZWpRblxxeV5qQWH2KU 5mBREue9HnI/XEggPbEkNTs1tSC1CCbLxMEp1cDoqC5bFp5yyL1vt/33/U0Jnlb3ZvDX/5xx RuFi5YWbLzjMZu87LHvLS/Vuny5/romwsh9LkM+J3zr5O84xck3Jlcu/pOa9XG/Hk5N7qh7w JiUxrjlUIXjiS3ToffOwLwwGxr/2NqifyLYsmrdxil1qru9ChZcrt3jwHp6VJ5cSsWSKVNDT +5xKLMUZiYZazEXFiQAcqPERegIAAA== Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 03:59:32 -0000 SGkgYWxsLA0KICBJIGhhdmUgZ29uZSB0aHJvdWdoIGRyYWZ0LWlldGYtNm1hbi1yZmMxOTgxYmlz LTAzIGFuZCBJIGZvdW5kIGl0IHRvIGJlIGluIGdvb2Qgc2hhcGUgdG8gcHJvZ3Jlc3MuIEkganVz dCBzYXcgdHdvIG1pbm9yIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkDQoNCiogU2Vj dGlvbiAxDQoNCkkgZG9u4oCZdCB0aGluayB0aGF0IGhpcyB0ZXh0IHRoYXQgaXMgY29waWVkIG92 ZXIgZnJvbSBSRkM0ODIxIGlzIGhlbHBmdWwuIEkgdGhpbmsgdGhlIGVhcmxpZXIgcGFydCBvZiB0 aGUgcGFyYWdyYXBoIGlzIHdlbGwgd3JpdHRlbiwgdXNlZnVsIGFuZCBjb252ZXlzIGV4YWN0bHkg dGhlIHJpZ2h0IGFtb3VudCBvZiBjb250ZXh0Lg0KDQrigJwgICAgICAgICAgSW4gdGhpcyBhbGdv cml0aG0sIHRoZQkNCiAJICAgcHJvcGVyIE1UVSBpcyBkZXRlcm1pbmVkIGJ5IHN0YXJ0aW5nIHdp dGggc21hbGwgcGFja2V0cyBhbmQgcHJvYmluZwkNCiAJICAgd2l0aCBzdWNjZXNzaXZlbHkgbGFy Z2VyIHBhY2tldHMuICBUaGUgYnVsayBvZiB0aGUgYWxnb3JpdGhtIGlzCQ0KIAkgICBpbXBsZW1l bnRlZCBhYm92ZSBJUCwgaW4gdGhlIHRyYW5zcG9ydCBsYXllciAoZS5nLiwgVENQKSBvciBvdGhl cgkNCiAJICAgIlBhY2tldGl6YXRpb24gUHJvdG9jb2wiIHRoYXQgaXMgcmVzcG9uc2libGUgZm9y IGRldGVybWluaW5nIHBhY2tldAkNCiAJICAgYm91bmRhcmllcy4iDQoNCiogU2VjdGlvbiAzDQoN CkkgYW0gbm90IHN1cmUgd2h5IHRoZSBmb2xsb3dpbmcgdGV4dCBpcyByZXF1aXJlZC4gV2hhdCBh cmUgdGhlc2Ugbm9kZXM/IEkgdGhvdWdodCB3ZSBkaXNjdXNzZWQgdGhpcyBhbmQgZGVjaWRlZCB0 byBub3QgcHV0IGluIHN1Y2ggdGV4dC4NCg0KIihyZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgZGVj cmVtZW50cyB0aGUgSG9wIExpbWl0KSINCg0KSSB3b3VsZCBzdWdnZXN0IHJlbW92aW5nIHRoZSB0 ZXh0IG9yIGFkZGluZyBhbiBleGFtcGxlIG9mIHN1Y2ggYSBub2RlLg0KDQpUaGFua3MNClN1cmVz aA0KDQpQLlMuOiBJIGFncmVlIHdpdGggRG9uYWxk4oCZcyBjb21tZW50IGluIGhpcyBJTlQgRGly IHJldmlldyB0aGF0IHRoZSDigJxzZWN1cml0eSBjbGFzc2lmaWNhdGlvbnPigJ0gcGFyYWdyYXBo IHNlZW1zIGRhdGVkIGJ1dCBJIHdvdWxkIHByZWZlciBmb3IgaXQgdG8gYmUgcmVtb3ZlZCByYXRo ZXIgdGhhbiByZXdyaXR0ZW4u From nobody Thu Jan 26 12:33: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 B2F71129B06; Thu, 26 Jan 2017 12:33:20 -0800 (PST) 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 REK75iHPTrAz; Thu, 26 Jan 2017 12:33:18 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43F5129AF9; Thu, 26 Jan 2017 12:33:18 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id j13so46056979iod.3; Thu, 26 Jan 2017 12:33:18 -0800 (PST) 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=NS2pOGdVxvLkB2EmXb2KEwt2Yk4YJnxOpoTD9Sxnzls=; b=gGN1IRsbI/N9bqhElDeLPNf1kJPAKuPPUJA5LBOcSovO43a5AT00wOrkHSjEulM7mp sMU4Hbh6wETwnEwFX+3Gjz9kgnGCM9EBIiPYS8g9xPF+2ox1ensFyFc6596E81J72LFP RabVdeVSWmAKC1QAEH1uNDtprPTQsoUqXN/HepbcaTs8EDAi59TWgeE/+0mDuxShAtp4 IvwdBNnL3CpjGxeMl0+KP9xS9TuXrcCtlX3lyWDZc5meLB2cjK9SeFMC4zmr35cSa5fu cQsDlEiXfeM2s5frMUiqtmFPtNmCeDvVemLCRQazMeFVblH4ucfjboFqob/lmq3pWIS5 ZBiQ== 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=NS2pOGdVxvLkB2EmXb2KEwt2Yk4YJnxOpoTD9Sxnzls=; b=AP8ouLEw05TxUTLO2IblN7Me2TOnV57699ye9NUD6TF8ujN5DT1rT05aV/uyD+Zauh 9TNjj5sjviLU2QMtXmRdQuGizSiCtYCMhiS2/NNsOFiiAlbHWgpmsXxX9fwi6ziEI9pV dtLH8+KmWeik9DqQii9u4UPhH+7JUxNuMuZs9dIJiRXwQ9dhaoSzrXckQzXAhbdNo1YK 5ts0Dd7mL1dd+8noNEY6shno9dlwxG31Lb9Piv121hWD2M7rkwkvMEZTZv6UaWza1DO2 n/RsU4DXjTYsfwnDbTurNhEBPlPL3qmswj9kBO+xemRCyWWm01ndJ+lDw0/tU3d+PgSd PN+g== X-Gm-Message-State: AIkVDXKUwayWInfscI68noCJioR4Ou3lEOx6DQOFPbbaAVt+H8Gn87RCQ9uFWa64qGHRBw== X-Received: by 10.107.10.24 with SMTP id u24mr4607581ioi.94.1485462797892; Thu, 26 Jan 2017 12:33:17 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y126sm100199itf.14.2017.01.26.12.33.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 12:33:16 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_622A2676-33A2-4BAD-815E-B963E7FCC28C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: AD evaluation: draft-ietf-6man-rfc1981bis-03 Date: Thu, 26 Jan 2017 12:33:14 -0800 In-Reply-To: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com> To: Suresh Krishnan References: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden , "draft-ietf-6man-rfc1981bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 20:33:21 -0000 --Apple-Mail=_622A2676-33A2-4BAD-815E-B963E7FCC28C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Suresh, Thanks for your evaluation. > On Jan 25, 2017, at 7:59 PM, Suresh Krishnan = wrote: >=20 > Hi all, > I have gone through draft-ietf-6man-rfc1981bis-03 and I found it to = be in good shape to progress. I just saw two minor issues that need to = be addressed >=20 > * Section 1 >=20 > I don=E2=80=99t think that his text that is copied over from RFC4821 = is helpful. I think the earlier part of the paragraph is well written, = useful and conveys exactly the right amount of context. >=20 > =E2=80=9C In this algorithm, the > proper MTU is determined by starting with small packets and = probing > with successively larger packets. The bulk of the algorithm = is > implemented above IP, in the transport layer (e.g., TCP) or = other > "Packetization Protocol" that is responsible for determining = packet > boundaries.=E2=80=9D >=20 I tend to agree and am happy to remove it. I will note that there as a = lot of debate on what this paragraph should say. Unless someone = objects, I will plan to remove it from the next version. > * Section 3 >=20 > I am not sure why the following text is required. What are these = nodes? I thought we discussed this and decided to not put in such text. >=20 > "(regardless of whether it decrements the Hop Limit)" >=20 > I would suggest removing the text or adding an example of such a node. I went back and read the email thread: = https://mailarchive.ietf.org/arch/search/?qdr=3Da&email_list=3Dipv6&q=3Dte= xt%3A(regardless+of+whether+it+decrements+the+Hop+Limit)&as=3D1&so=3Ddate The discussion does go back and forth, but ends with Ole closing the = issue in the tracker: #13: Regardless of whether it decrements the Hop Limit Changes (by otroan@employees.org): * status: new =3D> closed * resolution: =3D> wontfix I interpert it to leave it in. I don=E2=80=99t have a strong view on = this, happy to remove it. Any objections? >=20 > Thanks > Suresh >=20 > P.S.: I agree with Donald=E2=80=99s comment in his INT Dir review that = the =E2=80=9Csecurity classifications=E2=80=9D paragraph seems dated but = I would prefer for it to be removed rather than rewritten. OK, I will remove it. Thanks, Bob --Apple-Mail=_622A2676-33A2-4BAD-815E-B963E7FCC28C 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 iQEcBAEBCgAGBQJYil0LAAoJEK7rdBF357uoWcAIAIE85hZkDxUYyIWO/fPLkfCZ DJGVJD1StRBQHeW8J+ehspS0boa+XZe1gIq895ujdYNzpQFHhpKCEBXfw7TnY/sg BZnfllpS5iJ6di0RE2MwVoIbmONBfE+EH8ErdykqiDD3qcDAp5vjnJvCv+kE5nc7 uvMEJ3FCQw9vY3zzEzfEu50pAXu6UXR6Yek7O5pc3eFpLIjWdAatM4K7Ma59C5nG kHOjSf2l4Yw5/ZD61HkGaqlKvsPmvZJLHoz/+xq73RK+EwFCrMTNLoo41qcdii9k 0qGy6aN2g+x+B0c+y/zCiqYX1o0WujxT4MRBctpExPLe48952ncUW9lnaZ9EvVI= =vn+Y -----END PGP SIGNATURE----- --Apple-Mail=_622A2676-33A2-4BAD-815E-B963E7FCC28C-- From nobody Thu Jan 26 14:21:09 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA30129C18; Thu, 26 Jan 2017 14:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38Ch-7K6zeo8; Thu, 26 Jan 2017 14:21:06 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEE91299B2; Thu, 26 Jan 2017 14:21:06 -0800 (PST) X-AuditID: c6180641-e73ff70000000a0b-1a-588a21e450a2 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 2E.91.02571.4E12A885; Thu, 26 Jan 2017 17:20:54 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 17:21:04 -0500 From: Suresh Krishnan To: Robert Hinden Subject: Re: AD evaluation: draft-ietf-6man-rfc1981bis-03 Thread-Topic: AD evaluation: draft-ietf-6man-rfc1981bis-03 Thread-Index: AQHSd4iXjA2mRRkD4kKirjH7D0ko7aFLi5YAgAAeHAA= Date: Thu, 26 Jan 2017 22:21:01 +0000 Message-ID: References: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_AA4F737CF8CF4741A5ED73999AA9B488ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPgu4zxa4Ig2W3mS22vt/HZnFs7WsW i5dn3zM5MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBmffk9kLvg9ibHi+4+sBsamfsYu Rk4OCQETiY/d55m6GLk4hATWM0o0tO9kBUkICSxnlJhwJRbEZgMq2rDzMxOILSKgIfHzzxGw ZmaBIokHp9azgdjCApYSHxoPsEHUWEn0rLjCDmM/vvYebCaLgKpEw86lzCA2r4C9xNmvMxkh dhVJvLl5CszmFLCV+P/nAVgvo4CYxPdTa5ggdolL3HoynwniaAGJJXvOM0PYohIvH/9jhbCV JD7+ng/UywFUnyzx7IY/xCpBiZMzn7BMYBSZhWTSLISqWUiqIMKaEut36UNUK0pM6X7IDmFr SLTOmQtlW0scuXWFDVnNAkaOVYwcpcUFObnpRoabGIGxdUyCzXEH495ez0OMAhyMSjy8G651 RgixJpYVV+YeYpTgYFYS4W0DRqYQb0piZVVqUX58UWlOavEhRmkOFiVx3ush98OFBNITS1Kz U1MLUotgskwcnFINjGY+zxqnhM1IL23ZLHPp54onfybN4Dyd/n7j1nM3z09bxGASMakvrOde W7P9LLes05aajCrlmYX+a5zd/8v8XJPLX3lSTKsl/knvv/WtV0KYLk2V4+edwP4tmaH0Ymjd nlmPmbmK9VxaV4s97JH+eeLlFkNNSw/jhdUTVnXnh70JP7Lyn4HCEyWW4oxEQy3mouJEAPyP O0GpAgAA Archived-At: Cc: 6man WG , "draft-ietf-6man-rfc1981bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 22:21:08 -0000 --_000_AA4F737CF8CF4741A5ED73999AA9B488ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KICBSZW1vdmluZyB0aGluZ3Mgd2UgYWdyZWVkIG9uLiBPbmUgdGhvdWdodCBpbmxp bmUuDQoNCk9uIEphbiAyNiwgMjAxNywgYXQgMzozMyBQTSwgQm9iIEhpbmRlbiA8Ym9iLmhpbmRl bkBnbWFpbC5jb208bWFpbHRvOmJvYi5oaW5kZW5AZ21haWwuY29tPj4gd3JvdGU6DQouLi4NCg0K KiBTZWN0aW9uIDMNCg0KSSBhbSBub3Qgc3VyZSB3aHkgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIHJl cXVpcmVkLiBXaGF0IGFyZSB0aGVzZSBub2Rlcz8gSSB0aG91Z2h0IHdlIGRpc2N1c3NlZCB0aGlz IGFuZCBkZWNpZGVkIHRvIG5vdCBwdXQgaW4gc3VjaCB0ZXh0Lg0KDQoiKHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBpdCBkZWNyZW1lbnRzIHRoZSBIb3AgTGltaXQpIg0KDQpJIHdvdWxkIHN1Z2dlc3Qg cmVtb3ZpbmcgdGhlIHRleHQgb3IgYWRkaW5nIGFuIGV4YW1wbGUgb2Ygc3VjaCBhIG5vZGUuDQoN Cg0KSSB3ZW50IGJhY2sgYW5kIHJlYWQgdGhlIGVtYWlsIHRocmVhZDoNCg0KaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/cWRyPWEmZW1haWxfbGlzdD1pcHY2JnE9dGV4 dCUzQShyZWdhcmRsZXNzK29mK3doZXRoZXIraXQrZGVjcmVtZW50cyt0aGUrSG9wK0xpbWl0KSZh cz0xJnNvPWRhdGU8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/cWRy PWEmZW1haWxfbGlzdD1pcHY2JnE9dGV4dDoocmVnYXJkbGVzcytvZit3aGV0aGVyK2l0K2RlY3Jl bWVudHMrdGhlK0hvcCtMaW1pdCkmYXM9MSZzbz1kYXRlPg0KDQpUaGUgZGlzY3Vzc2lvbiBkb2Vz IGdvIGJhY2sgYW5kIGZvcnRoLCBidXQgZW5kcyB3aXRoIE9sZSBjbG9zaW5nIHRoZSBpc3N1ZSBp biB0aGUgdHJhY2tlcjoNCg0KICAjMTM6IFJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBpdCBkZWNyZW1l bnRzIHRoZSBIb3AgTGltaXQNCg0KICBDaGFuZ2VzIChieSBvdHJvYW5AZW1wbG95ZWVzLm9yZzxt YWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc+KToNCg0KICAgICogc3RhdHVzOiAgbmV3ID0+IGNs b3NlZA0KICAgICogcmVzb2x1dGlvbjogICA9PiB3b250Zml4DQoNCkkgaW50ZXJwZXJ0IGl0IHRv IGxlYXZlIGl0IGluLiAgSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgdmlldyBvbiB0aGlzLCBoYXBw eSB0byByZW1vdmUgaXQuICBBbnkgb2JqZWN0aW9ucz8NCg0KTm90IGZyb20gbWUuIEJ1dCBteSBy ZWFkIG9mIHRoZSB0aHJlYWQgd2FzIHRoYXQgT2xlIHdhcyBhbHNvIHF1ZXN0aW9uaW5nIHRoZSB2 YWx1ZSBvZiB0aGUgdGV4dC4gSWYgdGhlIG9ubHkgY2FzZSB0aGlzIGNvdmVycyBpcyBhbiBORCBw cm94eSwgSSB0aGluayB0aGUgY2FzZSBpcyBhZGVxdWF0ZWx5IGhhbmRsZWQgYnkgU2VjdGlvbiA0 LjEuMS4gb2YgUkZDNDM4OS4NCg0KVGhhbmtzDQpTdXJlc2gNCg0K --_000_AA4F737CF8CF4741A5ED73999AA9B488ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <960007B464EF104C8BF16690B3C96AD7@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQm9iLA0KPGRpdiBjbGFzcz0i Ij4mbmJzcDsgUmVtb3ZpbmcgdGhpbmdzIHdlIGFncmVlZCBvbi4gT25lIHRob3VnaHQgaW5saW5l LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIEphbiAyNiwgMjAxNywgYXQgMzozMyBQTSwgQm9iIEhpbmRlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJvYi5oaW5kZW5AZ21haWwuY29tIiBjbGFzcz0iIj5ib2IuaGluZGVuQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi4uLjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQoqIFNlY3Rpb24gMzxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkkgYW0gbm90IHN1cmUgd2h5IHRoZSBmb2xsb3dpbmcgdGV4dCBpcyByZXF1aXJlZC4g V2hhdCBhcmUgdGhlc2Ugbm9kZXM/IEkgdGhvdWdodCB3ZSBkaXNjdXNzZWQgdGhpcyBhbmQgZGVj aWRlZCB0byBub3QgcHV0IGluIHN1Y2ggdGV4dC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQomcXVvdDsocmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGRlY3JlbWVudHMgdGhlIEhvcCBMaW1p dCkmcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdvdWxkIHN1Z2dlc3QgcmVt b3ZpbmcgdGhlIHRleHQgb3IgYWRkaW5nIGFuIGV4YW1wbGUgb2Ygc3VjaCBhIG5vZGUuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogd2VudCBiYWNr IGFuZCByZWFkIHRoZSBlbWFpbCB0aHJlYWQ6PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/cWRyPWEmYW1wO2VtYWlsX2xpc3Q9aXB2 NiZhbXA7cT10ZXh0OihyZWdhcmRsZXNzJiM0MztvZiYjNDM7d2hldGhlciYjNDM7aXQmIzQzO2Rl Y3JlbWVudHMmIzQzO3RoZSYjNDM7SG9wJiM0MztMaW1pdCkmYW1wO2FzPTEmYW1wO3NvPWRhdGUi IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP3Fkcj1hJmFtcDtlbWFp bF9saXN0PWlwdjYmYW1wO3E9dGV4dCUzQShyZWdhcmRsZXNzJiM0MztvZiYjNDM7d2hldGhlciYj NDM7aXQmIzQzO2RlY3JlbWVudHMmIzQzO3RoZSYjNDM7SG9wJiM0MztMaW1pdCkmYW1wO2FzPTEm YW1wO3NvPWRhdGU8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGUNCiBkaXNjdXNzaW9uIGRvZXMg Z28gYmFjayBhbmQgZm9ydGgsIGJ1dCBlbmRzIHdpdGggT2xlIGNsb3NpbmcgdGhlIGlzc3VlIGlu IHRoZSB0cmFja2VyOjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyMxMzoN CiBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgZGVjcmVtZW50cyB0aGUgSG9wIExpbWl0PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Q2hhbmdlcw0KIChieTxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm90cm9hbkBlbXBsb3llZXMub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj4pOjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyoNCiBzdGF0dXM6ICZuYnNwO25ldyA9Jmd0OyBjbG9zZWQ8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyoNCiByZXNvbHV0aW9uOiAmbmJzcDsmbmJzcDs9Jmd0OyB3b250Zml4PC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+SQ0KIGludGVycGVydCBpdCB0byBsZWF2ZSBpdCBpbi4gJm5ic3A7SSBkb27i gJl0IGhhdmUgYSBzdHJvbmcgdmlldyBvbiB0aGlzLCBoYXBweSB0byByZW1vdmUgaXQuICZuYnNw O0FueSBvYmplY3Rpb25zPzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQpO b3QgZnJvbSBtZS4gQnV0IG15IHJlYWQgb2YgdGhlIHRocmVhZCB3YXMgdGhhdCBPbGUgd2FzIGFs c28gcXVlc3Rpb25pbmcgdGhlIHZhbHVlIG9mIHRoZSB0ZXh0LiBJZiB0aGUgb25seSBjYXNlIHRo aXMgY292ZXJzIGlzIGFuIE5EIHByb3h5LCBJIHRoaW5rIHRoZSBjYXNlIGlzIGFkZXF1YXRlbHkg aGFuZGxlZCBieSBTZWN0aW9uIDQuMS4xLiBvZiBSRkM0Mzg5LiZuYnNwOzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlN1cmVzaDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AA4F737CF8CF4741A5ED73999AA9B488ericssoncom_-- From nobody Thu Jan 26 14:32: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 24EAC129BFE; Thu, 26 Jan 2017 14:32:20 -0800 (PST) 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 2S-os8R05U8F; Thu, 26 Jan 2017 14:32:18 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 699A7129BFC; Thu, 26 Jan 2017 14:32:18 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id r185so44328610ita.0; Thu, 26 Jan 2017 14:32:18 -0800 (PST) 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=ct9qS1o+3YBWw7j/nsy0d2Lf3dfO8Yz0Rx/VQUA8nL0=; b=sCVvSsVzwXzw7fYGHhpu4uYbrf1HEqT18Y674hRHVVWmlaXULbbugjeLYimrHnm+Jy o/pxlLLHW65jRBEnNsDA433Aj1J3pNGLHSgr12J/9K8RHR/eE/wfl5MpW/VK8ZjVLMc3 r/8hq4R0zlhIPSaYHCNgvGLktZXAqEzPXJkeenwEudIGzf3bm8eviLX33dcudjIngEbK XaQzfFWKEEiXN48vaaP60I+hFDXeKEyFhTb0kMiG8qqJuP3cAIDP1zmIX9pHQTO0ZzD4 bXov7ltD6pejDdo/cDNQpftmoDATdg8xLDaG5HZs9a8wxJotKyPm4UmCUX9QtOwlZwip riWw== 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=ct9qS1o+3YBWw7j/nsy0d2Lf3dfO8Yz0Rx/VQUA8nL0=; b=bAw/d3wM7QxjMryA8rMzwZnPzPrHgto3OhT0LGoI8Yk6poBaQASgcrave331V1jrYR t6bTF5botSxMVx9k0f4hBiVzreHda5O5TkX8yGSdD2FAOBrCkEfg68fx3njB6+EA9aVZ ulJGjgZc8d62iZRNb6xovygfnTNigqCdsn1iVvebzfjXkrCpIansxYNzQaXMMPbNhGBb j+oAYl1v363iRWUaLx+el/90Kt0x2zs3XSQLBw9NZcUB7i3IINB1sZy4KyUid/jD8/mO jHhUyT8pupaxATFhqtU+bCV2JBq1pWd3pmUo6gVbgT+XDA9CfpGYgN2P/1caVWPZnu+n OxJg== X-Gm-Message-State: AIkVDXLXuAr3VRJslaLln60FIsVSWEf71Enmo5+wbgyjMP2pLJBHAKCA+aWZr+SCsQ5FkQ== X-Received: by 10.36.62.133 with SMTP id s127mr801885its.110.1485469937722; Thu, 26 Jan 2017 14:32:17 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g78sm2130436ioi.41.2017.01.26.14.32.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 14:32:16 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CC072157-FA92-467C-A054-6BFCCC874B1B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: AD evaluation: draft-ietf-6man-rfc1981bis-03 Date: Thu, 26 Jan 2017 14:32:15 -0800 In-Reply-To: To: Suresh Krishnan References: <6BBA4B27-FE19-405C-A165-9973A8E9AE68@ericsson.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden , "draft-ietf-6man-rfc1981bis.all@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 22:32:20 -0000 --Apple-Mail=_CC072157-FA92-467C-A054-6BFCCC874B1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Suresh, > On Jan 26, 2017, at 2:21 PM, Suresh Krishnan = wrote: >=20 > Hi Bob, > Removing things we agreed on. One thought inline. >=20 >> On Jan 26, 2017, at 3:33 PM, Bob Hinden wrote: >> ... >>=20 >>> * Section 3 >>>=20 >>> I am not sure why the following text is required. What are these = nodes? I thought we discussed this and decided to not put in such text. >>>=20 >>> "(regardless of whether it decrements the Hop Limit)" >>>=20 >>> I would suggest removing the text or adding an example of such a = node. >>=20 >>=20 >> I went back and read the email thread: >>=20 >> = https://mailarchive.ietf.org/arch/search/?qdr=3Da&email_list=3Dipv6&q=3Dte= xt%3A(regardless+of+whether+it+decrements+the+Hop+Limit)&as=3D1&so=3Ddate >>=20 >> The discussion does go back and forth, but ends with Ole closing the = issue in the tracker: >>=20 >> #13: Regardless of whether it decrements the Hop Limit >>=20 >> Changes (by otroan@employees.org): >>=20 >> * status: new =3D> closed >> * resolution: =3D> wontfix >>=20 >> I interpert it to leave it in. I don=E2=80=99t have a strong view on = this, happy to remove it. Any objections? >=20 > Not from me. But my read of the thread was that Ole was also = questioning the value of the text. If the only case this covers is an ND = proxy, I think the case is adequately handled by Section 4.1.1. of = RFC4389. OK, I will remove it. Bob >=20 > Thanks > Suresh >=20 --Apple-Mail=_CC072157-FA92-467C-A054-6BFCCC874B1B 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 iQEcBAEBCgAGBQJYinjvAAoJEK7rdBF357uoU3MIAJJSX3b3P1FLs1eCnoFRAvq0 unKPIAA+2ixjLARWLYlVQXlMFcfg+hNuaqKAzmMsXwjXHrR9aLU3Jvsyaj04MVYM m6v4ccmSh60ZytaBDnwQH0tt2BpQhlhcr9+wDy3G+xmUSQAOoJIQ57jjKfvlMJIN uk7P3i1/LUa2qrZ5OJCIDD3d52jyRAHsW0EgfRDipNABdHwLS0qYBtpwQAZvKaDn gqvP5rX68E0jYXYAGNd60sKqp4caZQmZor38DLgtdcUcWU7rVlh0V7BP4TcLZP1E oMEvDB9HiS2snbFZDgaK4PFfW7OYxRypQr9AjJpYduYeFbzWHMO1Fl9n+EK0TU4= =SKdv -----END PGP SIGNATURE----- --Apple-Mail=_CC072157-FA92-467C-A054-6BFCCC874B1B-- From nobody Fri Jan 27 11:51:25 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 549DD129875; Fri, 27 Jan 2017 11:51:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'IPv6 Router Advertisement Options for DNS Configuration' to Proposed Standard (draft-ietf-6man-rdnss-rfc6106bis-15.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148554667434.17974.14860953923635867784.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 11:51:14 -0800 Archived-At: Cc: ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, draft-ietf-6man-rdnss-rfc6106bis@ietf.org, The IESG , fgont@si6networks.com, 6man-chairs@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 19:51:14 -0000 The IESG has approved the following document: - 'IPv6 Router Advertisement Options for DNS Configuration' (draft-ietf-6man-rdnss-rfc6106bis-15.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ Technical Summary This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. It obsoletes RFC 6106 and allows a higher default value of the lifetime of the DNS RA options to avoid the frequent expiry of the options on links with a relatively high rate of packet loss. Working Group Summary The working group preferred to work on a bis version to replace RFC 6106, instead of producing an RFC to update RFC 6106. Document Quality There are several implementations of RFC6106 and these implementations will most likely be updated pretty quickly after this document is published Personnel Fernando Gont is the document shepherd. Suresh Krishnan is the responsible AD From nobody Sun Jan 29 13:58: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 E80FA129667; Sun, 29 Jan 2017 13:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ6No9XHqJt5; Sun, 29 Jan 2017 13:57:57 -0800 (PST) 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 BD6AE129647; Sun, 29 Jan 2017 13:57:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AA53FB81141; Sun, 29 Jan 2017 13:57:57 -0800 (PST) To: tim.chown@jisc.ac.uk, suresh.krishnan@ericsson.com, jhw@apple.com, ek@google.com, Jim_Hoagland@symantec.com, manav.bhatia@alcatel-lucent.com Subject: [Errata Held for Document Update] RFC6564 (4807) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170129215757.AA53FB81141@rfc-editor.org> Date: Sun, 29 Jan 2017 13:57:57 -0800 (PST) Archived-At: Cc: ipv6@ietf.org, text/plain@rfc-editor.org, suresh.krishnan@ericsson.com, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 21:57:59 -0000 The following errata report has been held for document update for RFC6564, "A Uniform Format for IPv6 Extension Headers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6564&eid=4807 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Tim Chown Date Reported: 2016-09-20 Held by: Suresh Krishnan (IESG) Section: 4 and 9 Original Text ------------- In Section 4: Next Header 8-bit selector. Identifies the type of header immediately following the extension header. Uses the same values as the IPv4 Protocol field [IANA_IP_PARAM]. In Section 9: [IANA_IP_PARAM] IANA, "IP Parameters", . Corrected Text -------------- In Section 4: Next Header 8-bit selector. Identifies the type of header immediately following the extension header. Uses the same values as the IPv4 Protocol field [IANA-PN]. In Section 9: [IANA-PN] "Assigned Internet Protocol Numbers", . Notes ----- This is being handled in the 2460bis work. -------------------------------------- RFC6564 (draft-ietf-6man-exthdr-06) -------------------------------------- Title : A Uniform Format for IPv6 Extension Headers Publication Date : April 2012 Author(s) : S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Sun Jan 29 14: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 E3094129673; Sun, 29 Jan 2017 14:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ienPKjJmC_-q; Sun, 29 Jan 2017 14:04:37 -0800 (PST) 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 06AAE129672; Sun, 29 Jan 2017 14:04:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E2C43B811AE; Sun, 29 Jan 2017 14:04:36 -0800 (PST) To: robbat2@gentoo.org, pjeong@brocade.com, soohong.park@samsung.com, luc.beloeil@orange-ftgroup.com, smadanapalli@gmail.com Subject: [Errata Rejected] RFC6106 (4864) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170129220436.E2C43B811AE@rfc-editor.org> Date: Sun, 29 Jan 2017 14:04:36 -0800 (PST) Archived-At: Cc: ipv6@ietf.org, text/plain@rfc-editor.org, suresh.krishnan@ericsson.com, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 22:04:38 -0000 The following errata report has been rejected for RFC6106, "IPv6 Router Advertisement Options for DNS Configuration". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6106&eid=4864 -------------------------------------- Status: Rejected Type: Technical Reported by: Robin Johnson Date Reported: 2016-11-14 Rejected by: Suresh Krishnan (IESG) Section: 5.2. Original Text ------------- Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The minimum value is 2 if at least one domain name is contained in the option. The Length field is set to a multiple of 8 octets to accommodate all the domain names in the field of Domain Names of DNS Search List. Corrected Text -------------- Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. The minimum value is 2 if at least one domain name is contained in the option. The Length field is set to a multiple of 8 octets to accommodate all the domain names in the field of Domain Names of DNS Search List. The exact maximum value supported by a given network is dictated by the MTU of the link, because the Router Advertisement MUST NOT be fragmented as per RFC6980#section5. The lowest possible MTU of 1280 results in a lower bound for the maximum value of 148 (representing 1192 octets). Notes ----- While the submitter's point is valid, there is not much that can be done on a per-option basis. Even if this option is sized so that it does not result in the fragmentation of the RA message, there might be other options that do. That is why the restriction for non-fragmentation is specified in a separate document and not in each document that defines an ND option. --VERIFIER NOTES-- While the submitter's point is valid, there is not much that can be done on a per-option basis. Even if this option is sized so that it does not result in the fragmentation of the RA message, there might be other options that do. That is why the restriction for non-fragmentation is specified in a separate document and not in each document that defines an ND option. -------------------------------------- RFC6106 (draft-ietf-6man-dns-options-bis-08) -------------------------------------- Title : IPv6 Router Advertisement Options for DNS Configuration Publication Date : November 2010 Author(s) : J. Jeong, S. Park, L. Beloeil, S. Madanapalli Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Jan 31 11:05:00 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 7077D12955C; Tue, 31 Jan 2017 11:04:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc1981bis-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148588948845.5950.1016187970747980851.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 11:04:48 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:04:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : Path MTU Discovery for IP version 6 Authors : Jack McCann <> Stephen E. Deering <> Jeffrey Mogul <> Robert M. Hinden Filename : draft-ietf-6man-rfc1981bis-04.txt Pages : 17 Date : 2017-01-31 Abstract: This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc1981bis-04 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 Tue Jan 31 11:07:36 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 90F0D129572; Tue, 31 Jan 2017 11:07:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc4291bis-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148588965058.5958.5262882400788714848.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 11:07:30 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:07:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance of the IETF. Title : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering <> Filename : draft-ietf-6man-rfc4291bis-07.txt Pages : 33 Date : 2017-01-31 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-07 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 Tue Jan 31 11:32: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 167E01299DE for ; Tue, 31 Jan 2017 11:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpigTviTAkcg for ; Tue, 31 Jan 2017 11:32:20 -0800 (PST) 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 425061299D8 for ; Tue, 31 Jan 2017 11:32:20 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so175141836qki.2 for ; Tue, 31 Jan 2017 11:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=9oEn43vySEXMrlJ91RV6Cb+uyuyU2pm9ynRwZwxcc2E=; b=WTlKFd+VMNyQfkrvXpRaJjoMcVQYfMP+Avu9DDP9t97NTwyj1aULm+RGKNqyOXkJFg +mlRUYRA5kBWqMVr+NaRT3n4xvzfB+90gs97XVkR7KE0nG4zLpwvuFvoVWiS6XnYoihk eVDUCBSwX7kZFhDCAF9L+40/WX6uIeLB7S76rOCLQGy8diCjyxs1ckP0d4DWfQvkZygf JWXiuaeuW9UyJ/ZLhrGcBxRlojBSWm7KQ2c+p+89bKapV96uAMnp0S2erMLNHxN9H6nD p31Ff19k7nqpCdvYagKP2tBnjWs8FCL4k22QXCYTpjviGz/3EFTiso0dqA/uDW5sss1O 68Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=9oEn43vySEXMrlJ91RV6Cb+uyuyU2pm9ynRwZwxcc2E=; b=TCIzxESU25JUtMIDNXifJ3xd62pQ7twz2nci+B6wt0+CfIKs48dLJhwqEJyl88eAR0 /9NEOoGzW6NI58BnWgN/IKnw+YQ/Yh+Q3DNwBy4abYyQi9Ecyc0rRFOgIoVCTvLCm40d Mhp3BFz15/u466opR5BHx/Qks7PGXIMh4q8R/L3olDymF9xngHX+z2W7nFNHBeKnOLXA NbZHnvQYntxeGvJTrBob4nIfeNNRLKnexqk+iZlvbUaeHRgkb0UeXA1wdeAU9+0ZToNm Knel8PjmjEgcKYOSdq5dKjsMGa96i1fcB/eOPaRHSS4PiGDdRm/lrDuuu+gi5P8K0ldd 1Emg== X-Gm-Message-State: AIkVDXIzxYF79NoRuFy/sqO0d2Eib7zsmEdviATPIwUaAMih1Q/jAxNxiD2PgyGYFKNBqg== X-Received: by 10.55.165.142 with SMTP id o136mr21579981qke.113.1485891139452; Tue, 31 Jan 2017 11:32:19 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r24sm16181630qkl.5.2017.01.31.11.32.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 11:32:18 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_92AFA651-ABF4-4751-BA74-2FA973926C72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Date: Tue, 31 Jan 2017 11:32:15 -0800 References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> To: IPv6 List Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:32:22 -0000 --Apple-Mail=_92AFA651-ABF4-4751-BA74-2FA973926C72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new 6man w.g. version (-07) of the RFC4291bis draft. See = links below. The summary of the changes are: Added text to Section 2.4 summarizing IPv6 unicast routing and referencing BCP198, citing RFC6164 as an example of longer prefixes, and that IIDs are required to be 64 bits long as described in RFC7421. Based on review by Brian Haberman added reference to RFC5952 in Section 2.2.3, corrected case errors in Section 2.6.1, and added a reference to the IANA Multicast address registry in Section 2.6.1. Corrected errors in Section 2.2.3 where the examples in 7. and 8. were reversed. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-07 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc4291bis-07.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc4291bis > Revision: 07 > Title: IP Version 6 Addressing Architecture > Document date: 2017-01-31 > Group: 6man > Pages: 33 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-07.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-07 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-07 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". >=20 >=20 --Apple-Mail=_92AFA651-ABF4-4751-BA74-2FA973926C72 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 iQEcBAEBCgAGBQJYkOZAAAoJEK7rdBF357uoLN8H/jlcUcnfezGd97n9tEttFjqX viwUoT29ruKRdsrTGsrlS8gvMJd64QxQPRk9K5PM0LvIVZNsZbC5z1bATrdSB0q7 wlU8EuxaRJXqL375nXgEYrXxfk9WEMqgcr1Nnqm4chqkGCZT5/ukfhBhzi8zi66V 4R7ssgNkeRyogduwdoaQ+WhVruAlyyLOdv1tjOOUvzq/PYxvx+Vs9zMwzx3zKbkM p/Ti1WPfIP9zpnlIOZAx+RGW4IAqWxe2P1rIc6DS+ol8vpWXrSDvmDcuWQpx3oLn Z71kXodDGj4FyVdul/smvucsQxPCtkVjj/WqqC9vx97s+0wRYhQVVwPCS0PSbtU= =xA6t -----END PGP SIGNATURE----- --Apple-Mail=_92AFA651-ABF4-4751-BA74-2FA973926C72-- From nobody Tue Jan 31 11:33:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ABA1299E8 for ; Tue, 31 Jan 2017 11:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFh96-2Pm4Dw for ; Tue, 31 Jan 2017 11:33:00 -0800 (PST) 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 040941299D8 for ; Tue, 31 Jan 2017 11:33:00 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id w20so174780686qtb.1 for ; Tue, 31 Jan 2017 11:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=0baatYYf4XRvAhzKce2UJs0re1i5EbCL1DlJR3D9QoY=; b=LVW6NSu81bsxssIhh2ADffS2y8nQHPa5BmBy8JBfOxZoe7DQahZK4JOxO6eQsF3jek blBQdfkNuXlG/XZENselAVqmANBF56wdA/yuregdrPbTN2f+DQ1GQOlj0YRDLP0CoOvv 3DDnKs7VubDkqqivTNHIBatsKCAillJrJPy53znpAfc709ACncFB9D2hZFbbCGzOnnle UYr7duc+sPepuHhK5zFiVrs1tbLSZoXkbzih5OsPnvMMyO/n+yxW/3WStTkpO4LJsoto /KNFkk2YkILDFvWEIDXgNvCIKndoEdy0EXEB8qoS+ts6mQ9cHt+r2vrTV1ytjctPwoBa YVxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=0baatYYf4XRvAhzKce2UJs0re1i5EbCL1DlJR3D9QoY=; b=K+KX06NXcKY8d+1IXU4NGpdjw5gxIt0g+8x40YcSsManxXUDTj6o/dsnfBfiuqIuBm FVaFqLfchTXOwuk9fzbuGmX/ZIKE456BkAkeTxxUpjKAJPk+H59IumjJ6tWJwQe86r4Q uiUS6IB3OxD/gjRgGGP5MwjLHP2Xf9D4uxvSxFG1BTr6jWwwazbNs85kpYO60hTp8frX n4JQq1H37POMBb8FAKzf4Oz8MLl809gnsStuf14Y9b4gf7FCies6H0pZPo+gc0OiU7F8 kN0I0+0kfdBzsBpcc4Lo6+v1E87SDyNGO3yiyJ4H6qqB4A2ohudkg1MaKZvEYnvWv54o S8fA== X-Gm-Message-State: AIkVDXLA9wQrKO8y+hVBbpcocmjNeH6+PWcBfC08SHgAf8RHn6N7g29P/e74DK9yCXt2pA== X-Received: by 10.200.53.247 with SMTP id l52mr27329458qtb.144.1485891179107; Tue, 31 Jan 2017 11:32:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r24sm16181630qkl.5.2017.01.31.11.32.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 11:32:58 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_42FF274E-3F5A-418F-8D10-AF40B273D7FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Message-Id: Date: Tue, 31 Jan 2017 11:32:57 -0800 To: IPv6 List X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:33:01 -0000 --Apple-Mail=_42FF274E-3F5A-418F-8D10-AF40B273D7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published a new version of rfc1981bis (-04). Links to the document = below. The summary of changes in this version are: Changes based on AD Evaluation including removing details about RFC4821 algorithm in Section 1 , remove text about decrementing hop limit from Section 3, and removed text about obsolete security classifications from Section 5.2 . Editorial changes and clarification in Section 5.2 based on IP Directorate review by Donald Eastlake A diff from the previous version can be found at: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04.txt This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A new version of I-D, draft-ietf-6man-rfc1981bis-04.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc1981bis > Revision: 04 > Title: Path MTU Discovery for IP version 6 > Document date: 2017-01-31 > Group: 6man > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04 >=20 > Abstract: > This document describes Path MTU Discovery for IP version 6. It is > largely derived from RFC 1191, which describes Path MTU Discovery = for > IP version 4. It obsoletes RFC1981. >=20 >=20 --Apple-Mail=_42FF274E-3F5A-418F-8D10-AF40B273D7FA 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 iQEcBAEBCgAGBQJYkOZpAAoJEK7rdBF357uoBAsIAKPoAfNP0+NWc1poOuj1qFSD /Wff45wKCxWV7jLbXhtu8jCuiQ8m1LocPrVoY7ZqIpc2eMlHLNrIgoa7FN/wqAc6 L59Cqrdl35/yI5UqWnaH/UuvnSVJSVOoj72Lg0PJfwyO2BkLiR6iodKdlNssop9T 1975mH8ipBU8VNyiqriLF9QUBtb2JNKw8tsIDuSDW7VC+ogleyX8a7JROf2J4b3r R2IC3przeeUgP3MNBtM742PfiRKAjbm6KAmMdORTp0HnLcjOLc7CYAuyJhMXHCOd mWGZgc6sVGhLb1QLSX57hdgfPoxi7FP4zhRGukJxzh5KA0wUMV9fdPLi5uln8Cw= =S3p2 -----END PGP SIGNATURE----- --Apple-Mail=_42FF274E-3F5A-418F-8D10-AF40B273D7FA-- From nobody Tue Jan 31 12:39: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 891A0129A80 for ; Tue, 31 Jan 2017 12:39:14 -0800 (PST) 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 8H7vJwLZAsp6 for ; Tue, 31 Jan 2017 12:39:13 -0800 (PST) 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 E9051129A7C for ; Tue, 31 Jan 2017 12:39:12 -0800 (PST) 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 v0VKdC24040440; Tue, 31 Jan 2017 13:39:12 -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 v0VKd7I2039980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 31 Jan 2017 13:39:07 -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.1178.4; Tue, 31 Jan 2017 12:39:07 -0800 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.1178.000; Tue, 31 Jan 2017 12:39:06 -0800 From: "Templin, Fred L" To: Bob Hinden , IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHSe/jcOKsyqkIydUqod4YdsWWHP6FTC7+w Date: Tue, 31 Jan 2017 20:39:06 +0000 Message-ID: <88d5a5981f1245c39eda6f2ef6f4a70a@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 20:39:14 -0000 > value or the minimum IPv6 next hope MTU if that is larger. Spelling error - s/hope/hop Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > Sent: Tuesday, January 31, 2017 11:33 AM > To: IPv6 List > Cc: Bob Hinden > Subject: >=20 > Hi, >=20 > I published a new version of rfc1981bis (-04). Links to the document bel= ow. >=20 > The summary of changes in this version are: >=20 >=20 > Changes based on AD Evaluation including removing details about > RFC4821 algorithm in Section 1 , remove text about > decrementing hop limit from Section 3, and removed text about > obsolete security classifications from Section 5.2 > . > Editorial changes and clarification in Section 5.2 based on > IP Directorate review by Donald Eastlake >=20 > A diff from the previous version can be found at: >=20 > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04.txt >=20 > This is part of the project to move the core IPv6 specifications to Inter= net Standard. >=20 > Thanks, > Bob >=20 > > A new version of I-D, draft-ietf-6man-rfc1981bis-04.txt > > has been successfully submitted by Robert M. Hinden and posted to the > > IETF repository. > > > > Name: draft-ietf-6man-rfc1981bis > > Revision: 04 > > Title: Path MTU Discovery for IP version 6 > > Document date: 2017-01-31 > > Group: 6man > > Pages: 17 > > URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rf= c1981bis-04.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc198= 1bis/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-= 04 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc= 1981bis-04 > > > > Abstract: > > This document describes Path MTU Discovery for IP version 6. It is > > largely derived from RFC 1191, which describes Path MTU Discovery for > > IP version 4. It obsoletes RFC1981. > > > > From nobody Tue Jan 31 13:06: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 EE2541295A9 for ; Tue, 31 Jan 2017 13:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5vo7AuCIT1X for ; Tue, 31 Jan 2017 13:06:52 -0800 (PST) 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 701F21295A3 for ; Tue, 31 Jan 2017 13:06:52 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so245190905qtc.2 for ; Tue, 31 Jan 2017 13:06:52 -0800 (PST) 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=Gl2++VFp/ch3wKy1k19LWKfprWY/HHsbdTKPhKnIcmo=; b=G7I82I5KMtEFwCNUyJQftnQKftJrS6wdw1HPsvOcRsmnyDXpdlp6VI6Bmo1in65LlM HNij8WbBKCuD+bT5rruixNSE/SnorwnrMSMjzpGR9ME3LwzmfAzshJROhu2laS0KdsKS ZBJ016lRNlkfyahVFGOC3nO4bax63DPK/HbF+dA3IHHN89b8skXzPC1rQ7ubHKAk/wKY 20a2jIE3nGbe8kv/GOLxE9JntOqkNhrpu6IzSd88//IBSf5Ktj6HMGLQQ70ZtRWzjL09 924ML1r+t7/EQYGRWcNZ3jBVHUNX027TU3kC8XP3tIflDFLnlLEJfSbZYP4S+3lblke3 jPcA== 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=Gl2++VFp/ch3wKy1k19LWKfprWY/HHsbdTKPhKnIcmo=; b=UCWetklmqAfuKcVpgYs+koizUfick/wqecDNN0RHUHecXku9TuCnh9mD6wTUiG7Vrj CdBjx+glprSEO1xjKInZn3m6idkGxz72a7hGX6/Km35gkWWhwqb2k4ykn06pHIgW9qHJ f2/FsKk+rqXnugufwJtYNgWrhVTrnKnJOny9n85St/F5zObK7aVf8mtJoCyvw6mXBZnm w8+p6bm1Ma8v400gCHl8U2tpj1fm8hg1rnfzhxCejfIv45UUYXdbkje+QceF+wKVZKTX kuJI0ZuF3tOc9kBSfm6mz1Oq5TSQ2iyUu/KT3zlZw1Ddw2D6xZxJ+CjSclgnV8FeYErN kUlQ== X-Gm-Message-State: AIkVDXJgbWcxE0F6skfsWQfxLxhr6Wn+832PNcwiand2eNB5cze0H4poHCwA3Rdl+Cey1g== X-Received: by 10.200.54.10 with SMTP id m10mr26142071qtb.63.1485896811485; Tue, 31 Jan 2017 13:06:51 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id j140sm16454871qke.6.2017.01.31.13.06.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 13:06:50 -0800 (PST) From: Bob Hinden Message-Id: <4A5D6617-DEBC-4F02-B63E-997C5E5F7C5A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_14187756-5A62-43C1-A16D-0628AFF04037"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Date: Tue, 31 Jan 2017 13:06:47 -0800 In-Reply-To: <88d5a5981f1245c39eda6f2ef6f4a70a@XCH15-06-08.nw.nos.boeing.com> To: "Templin, Fred L" References: <88d5a5981f1245c39eda6f2ef6f4a70a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:06:54 -0000 --Apple-Mail=_14187756-5A62-43C1-A16D-0628AFF04037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fred, > On Jan 31, 2017, at 12:39 PM, Templin, Fred L = wrote: >=20 >> value or the minimum IPv6 next hope MTU if that is larger. >=20 > Spelling error - s/hope/hop oops :-( Will fix in next version. Bob >=20 > Fred >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden >> Sent: Tuesday, January 31, 2017 11:33 AM >> To: IPv6 List >> Cc: Bob Hinden >> Subject: >>=20 >> Hi, >>=20 >> I published a new version of rfc1981bis (-04). Links to the document = below. >>=20 >> The summary of changes in this version are: >>=20 >>=20 >> Changes based on AD Evaluation including removing details about >> RFC4821 algorithm in Section 1 , remove text about >> decrementing hop limit from Section 3, and removed text about >> obsolete security classifications from Section 5.2 >> . >> Editorial changes and clarification in Section 5.2 based on >> IP Directorate review by Donald Eastlake >>=20 >> A diff from the previous version can be found at: >>=20 >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04.txt= >>=20 >> This is part of the project to move the core IPv6 specifications to = Internet Standard. >>=20 >> Thanks, >> Bob >>=20 >>> A new version of I-D, draft-ietf-6man-rfc1981bis-04.txt >>> has been successfully submitted by Robert M. Hinden and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-ietf-6man-rfc1981bis >>> Revision: 04 >>> Title: Path MTU Discovery for IP version 6 >>> Document date: 2017-01-31 >>> Group: 6man >>> Pages: 17 >>> URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc1981bis-04.txt >>> Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/ >>> Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-04 >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04 >>>=20 >>> Abstract: >>> This document describes Path MTU Discovery for IP version 6. It is >>> largely derived from RFC 1191, which describes Path MTU Discovery = for >>> IP version 4. It obsoletes RFC1981. >>>=20 >>>=20 >=20 --Apple-Mail=_14187756-5A62-43C1-A16D-0628AFF04037 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 iQEcBAEBCgAGBQJYkPxoAAoJEK7rdBF357uo+RYH/RQ6fBxfdVbXOx9oznSCeAx6 +k8XrgBNBa46b7yvoELiM12jadSkfslEiB73k2x6Nzpw4JPOLYsfmCbNV+TxkaOg QRjLDSMboaXglKj+Tso3fY5vbzE87XAj0Zth3GQpL6QAweYs4ibOwSnRi0LKDG64 9+Zzst2CRDJUgoceqvqM/QfcLGZy0LqAYQc8xl69Giw66oyfOlJynp4bKh5TYrD9 bWn8UfNUgMiPWgfUi+GMmVap5Bg3uRLFMhdOiAylNeXe5YB2+eEGASWgQiNApGYt TtX/gVMu8sbS7M2SrzqN3siU07/3cyepmv3uxF/L0tjAo5QGf249LjvzNnG8eFk= =5jIu -----END PGP SIGNATURE----- --Apple-Mail=_14187756-5A62-43C1-A16D-0628AFF04037-- From nobody Tue Jan 31 13:09:48 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2811295A3 for ; Tue, 31 Jan 2017 13:09:45 -0800 (PST) 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 9r1OPGaUWkIO for ; Tue, 31 Jan 2017 13:09:43 -0800 (PST) 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 9BC1A129ACE for ; Tue, 31 Jan 2017 13:09:43 -0800 (PST) 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 v0VL9hQS027822; Tue, 31 Jan 2017 14:09:43 -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 v0VL9W5X027638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 31 Jan 2017 14:09:32 -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.1178.4; Tue, 31 Jan 2017 13:09:31 -0800 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.1178.000; Tue, 31 Jan 2017 13:09:31 -0800 From: "Templin, Fred L" To: Bob Hinden Subject: RE: Thread-Topic: Thread-Index: AQHSe/jcOKsyqkIydUqod4YdsWWHP6FTC7+wgACOSYD//3owYA== Date: Tue, 31 Jan 2017 21:09:31 +0000 Message-ID: <81186c98095f41388544da97351dd668@XCH15-06-08.nw.nos.boeing.com> References: <88d5a5981f1245c39eda6f2ef6f4a70a@XCH15-06-08.nw.nos.boeing.com> <4A5D6617-DEBC-4F02-B63E-997C5E5F7C5A@gmail.com> In-Reply-To: <4A5D6617-DEBC-4F02-B63E-997C5E5F7C5A@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: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:09:45 -0000 Hi Bob, > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Tuesday, January 31, 2017 1:07 PM > To: Templin, Fred L > Cc: Bob Hinden ; IPv6 List > Subject: Re: >=20 > Fred, >=20 > > On Jan 31, 2017, at 12:39 PM, Templin, Fred L wrote: > > > >> value or the minimum IPv6 next hope MTU if that is larger. > > > > Spelling error - s/hope/hop >=20 > oops :-( >=20 > Will fix in next version. Or, leave it as is - either way; expecting PMTUD to work is at best a "hope= ". Thanks - Fred > Bob >=20 > > > > Fred > > > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > >> Sent: Tuesday, January 31, 2017 11:33 AM > >> To: IPv6 List > >> Cc: Bob Hinden > >> Subject: > >> > >> Hi, > >> > >> I published a new version of rfc1981bis (-04). Links to the document = below. > >> > >> The summary of changes in this version are: > >> > >> > >> Changes based on AD Evaluation including removing details about > >> RFC4821 algorithm in Section 1 , remove text about > >> decrementing hop limit from Section 3, and removed text about > >> obsolete security classifications from Section 5.2 > >> . > >> Editorial changes and clarification in Section 5.2 based on > >> IP Directorate review by Donald Eastlake > >> > >> A diff from the previous version can be found at: > >> > >> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc1981bis-04.tx= t > >> > >> This is part of the project to move the core IPv6 specifications to In= ternet Standard. > >> > >> Thanks, > >> Bob > >> > >>> A new version of I-D, draft-ietf-6man-rfc1981bis-04.txt > >>> has been successfully submitted by Robert M. Hinden and posted to the > >>> IETF repository. > >>> > >>> Name: draft-ietf-6man-rfc1981bis > >>> Revision: 04 > >>> Title: Path MTU Discovery for IP version 6 > >>> Document date: 2017-01-31 > >>> Group: 6man > >>> Pages: 17 > >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-= rfc1981bis-04.txt > >>> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1= 981bis/ > >>> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc1981bi= s-04 > >>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-r= fc1981bis-04 > >>> > >>> Abstract: > >>> This document describes Path MTU Discovery for IP version 6. It is > >>> largely derived from RFC 1191, which describes Path MTU Discovery fo= r > >>> IP version 4. It obsoletes RFC1981. > >>> > >>> > > From nobody Tue Jan 31 13:17: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 0EDCF129ACD for ; Tue, 31 Jan 2017 13:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnzMfr2EkQVM for ; Tue, 31 Jan 2017 13:17:51 -0800 (PST) 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 D3143129AD0 for ; Tue, 31 Jan 2017 13:17:51 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id y143so111466445pfb.0 for ; Tue, 31 Jan 2017 13:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=vjcmTadjtd/I+0maq4yxJwSDwIJl92IrbEYLflGFSHI=; b=MNbvVkmV1aGzCp5oMuEGojyOCIZ9CtNs8h4nAGyQ4lqTpxI3L9ui/wJerkHiYyrOgY Hjg2wq3VBDlAPSTJzGcHHEU2vLljCnZ0QNzoztD+XMSIOqpLg+hqdXS0nGSjBurYkUZa C4atwEaGqtSCqayLG0rDaK3TXI71tEpgqKnDM/2SdU58WnUFccO2ZTOtkKVctsf/gNT3 9QQwwQruipq1cB6lZz/MQdd3TkWwNtnxflfeByP1lPUoq5Sqsn7FVr2efwpWjAgzK80J sFDppiuNbkybRFZFJGVg0x+vRgnLwbV7HAnVUTdulJC3rCnwgiTmmwmgWeikJAD+ZSTJ +DnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=vjcmTadjtd/I+0maq4yxJwSDwIJl92IrbEYLflGFSHI=; b=Fk1WGoXw/mm9mXuHPQoHYV8LRwadKkKDQ33+D8p/s28Vhim588dFmTzEia+lPlAhnx I57vu2nJP5a2b0f3kxFLQSPiaQBDHcMdi6sL+uZ4/0EvncUeO26STGp+AgTslnJABx6n 3r6Hq2zS8XAo5MCvPc08WWT1TuXIiKpNJfPDbrUXONNowWbgHL5ZfXpW7PzI+qn3jR5f ZuDrUZgeDZS3fftS6j3OeU6uT3fjTyMmz/1dypk1e7oRD/Eu6+KeDd8PSSHHaPkim1TC 6DMX1ssWoDbz353pTrJyhcKAZGtuvB+NF9GpMPTcDfyFot0loFg+JJrUgivhzpHFixH0 wWbA== X-Gm-Message-State: AIkVDXIC5Y+vuDJAmj3EU4Gt/XrOpFFk/u4To0uUI+c0DPJGLPeu7iTdwmzyo+nMQNfJ4w== X-Received: by 10.98.212.23 with SMTP id a23mr31932405pfh.18.1485897471276; Tue, 31 Jan 2017 13:17:51 -0800 (PST) Received: from [192.168.178.21] (179.218.69.111.dynamic.snap.net.nz. [111.69.218.179]) by smtp.gmail.com with ESMTPSA id g28sm43890659pgn.3.2017.01.31.13.17.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 13:17:50 -0800 (PST) Subject: Re: To: Bob Hinden , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <674b709d-265c-0b1b-e8fc-e2741853426d@gmail.com> Date: Wed, 1 Feb 2017 10:17:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:17:55 -0000 Since I was a bit noisy about the previous draft, let me say that I am quite OK with this one. Regards Brian Carpenter On 01/02/2017 08:32, Bob Hinden wrote: > Hi, > > I published a new 6man w.g. version (-07) of the RFC4291bis draft. See links below. > > The summary of the changes are: > > Added text to Section 2.4 summarizing IPv6 unicast routing and > referencing BCP198, citing RFC6164 as an example of > longer prefixes, and that IIDs are required to be 64 bits > long as described in RFC7421. > > Based on review by Brian Haberman added reference to RFC5952 > in Section 2.2.3, corrected case errors in Section 2.6.1, and > added a reference to the IANA Multicast address registry in > Section 2.6.1. > > Corrected errors in Section 2.2.3 where the examples in 7. > and 8. were reversed. > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-07 > > This is part of the project to move the core IPv6 specifications to Internet Standard. > > Thanks, > Bob > >> A new version of I-D, draft-ietf-6man-rfc4291bis-07.txt >> has been successfully submitted by Robert M. Hinden and posted to the >> IETF repository. >> >> Name: draft-ietf-6man-rfc4291bis >> Revision: 07 >> Title: IP Version 6 Addressing Architecture >> Document date: 2017-01-31 >> Group: 6man >> Pages: 33 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-07.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-07 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-07 >> >> Abstract: >> This specification defines the addressing architecture of the IP >> Version 6 (IPv6) protocol. The document includes the IPv6 addressing >> model, text representations of IPv6 addresses, definition of IPv6 >> unicast addresses, anycast addresses, and multicast addresses, and an >> IPv6 node's required addresses. >> >> This document obsoletes RFC 4291, "IP Version 6 Addressing >> Architecture". >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Tue Jan 31 15:15: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 F16CA129650 for ; Tue, 31 Jan 2017 15:15:11 -0800 (PST) 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 8JM6QU0xUyGC for ; Tue, 31 Jan 2017 15:15:10 -0800 (PST) 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 75168129A6B for ; Tue, 31 Jan 2017 15:15:10 -0800 (PST) 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 v0VNF9je026420; Tue, 31 Jan 2017 16:15:10 -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 v0VNF0sY026234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 31 Jan 2017 16:15:00 -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.1178.4; Tue, 31 Jan 2017 15:14:59 -0800 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.1178.000; Tue, 31 Jan 2017 15:14:59 -0800 From: "Templin, Fred L" To: IPv6 List Subject: Route Information Options in Redirect Messages (updated) Thread-Topic: Route Information Options in Redirect Messages (updated) Thread-Index: AdJ8F7CvYW0JrWzvRzOTQSlLsXA0KQ== Date: Tue, 31 Jan 2017 23:14:59 +0000 Message-ID: <9910b4acd87044e89fad83bb5c795b77@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: james woodyatt X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:15:12 -0000 An updated version of "Route Information Options in Redirect Messages" is n= ow available (see below). This version addresses 6man list comments posted in = the 1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man= . It also expands on several aspects of the proposal that were not covered in= the intarea draft. Please (re-)review and post comments to the list. Fred and James -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, January 30, 2017 2:33 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-6man-rio-redirect-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Route Information Options in Redirect Messages Authors : Fred L. Templin James Woodyatt Filename : draft-templin-6man-rio-redirect-01.txt Pages : 7 Date : 2017-01-30 Abstract: The IPv6 Neighbor Discovery protocol provides a Redirect function allowing routers to inform recipients of a better next hop on the link toward the destination. This document specifies a backward- compatible extension to the Redirect function to allow routers to include routing information that the recipient can associate with the next hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-templin-6man-rio-redirect-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-6man-rio-redirect-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt