From nobody Tue Aug 1 01:53: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 A3014132C47 for ; Tue, 1 Aug 2017 01:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Xecs-fxhBvr8 for ; Tue, 1 Aug 2017 01:53:30 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 9355C132C45 for ; Tue, 1 Aug 2017 01:53:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 82DD149; Tue, 1 Aug 2017 10:53:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1501577600; bh=9GSsPsn+KgVOzs5cf2i m0JRiMfmHrcwsETXquEZDo50=; b=i+NR/fmlGgxBMcSgaC2rZT571KqXbNOx4I4 ShkQy5oIemakXQdggkHcJT8ItIfswhEguUbFdJhXD5eqw4KwXqoMdvkA6AU0nEMQ MG9+2DIGq6E7V6a74OIWEpkxV2RX2IA/2VDvVaHUKEtNltaMP+BKJY0C4jmBvbFY fWOAMk30= 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 Q0YMqvQCyiJs; Tue, 1 Aug 2017 10:53:20 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:b480:49da:3a0f:1a80:39a6] (unknown [IPv6:2a02:a213:a301:b480:49da:3a0f:1a80:39a6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 9E70F3C; Tue, 1 Aug 2017 10:53:16 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <5BE01407-FBAA-486F-A2C6-B70D6F99B3FB@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_44796B83-9D94-4286-9F84-2B13D7B4AB3C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: fe80::/16 on specific link layers Date: Tue, 1 Aug 2017 12:53:15 +0200 In-Reply-To: Cc: Mark Smith , "ipv6@ietf.org" , =?utf-8?Q?Gert_D=C3=B6ring?= To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:53:33 -0000 --Apple-Mail=_44796B83-9D94-4286-9F84-2B13D7B4AB3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > Op 31 jul. 2017, om 19:09 heeft =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = het volgende geschreven: >=20 > At Mon, 31 Jul 2017 12:37:35 +1000, > Mark Smith wrote: >=20 >>> It would break BSD-variant implementations, which internally use the >>> 2nd 16-bit field of link-local addresses to identify the = corresponding >>> link, e.g., fe80:1::abcd means fe80::abcd in link "#1". (It's an >>> internal form and doesn't appear on wire). >>>=20 >>> Yes, that's an ugly implementation-specific hack and you could blame >>> the designer of the idea. But I'm afraid we can't simply ignore the >>> deployment base as a matter of practice. >>=20 >> I'm curious what the consequences would be of making BSD-variants >> compliant? Are any user space applications relying on it? Does BSD >> support the Sockets API and therefore applications should be using = the >> scope_id field for zone (ifindex) information rather than using this >> link ID in the reserved LL address field? >=20 > [...] >=20 > Some special purpose applications still deal with the hack themselves, > though. They include network statistics apps (that read the kernel > memory directly) and routing protocol apps (these tend to use > non-standard APIs to get access to the kernel's routing table, where > the raw in-memory representation is exchanged between the kernel and > apps). I also remember Gert D=C3=B6ring running into this when implementing = some OpenVPN IPv6 stuff as well, but then I guess OpenVPN does some = funny routing table manipulations and falls under that category :-) Cheers, Sander --Apple-Mail=_44796B83-9D94-4286-9F84-2B13D7B4AB3C 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----- iQEcBAEBCAAGBQJZgF2bAAoJEKAtA7D+JBO5v64H/jTV8W0nIfUfLs8UFutm8b1v dWEKX1erqgvVzGX5VwIYWgW22pBg6vBGY6kwqpSKMmVBgqkk9ewt0bdK8qoR5gCg l9ywbrOvkDQKEpU7IBsq/Lz/YE3Jj7D6JoROERGPWYiQfERp+n6+7c6fxhf/CIt1 GsGdArP2E+gVs0JTlf6juDnSSapah346LvKgQWb32YWM7tey5LozLYWxyB9kZdof pnrwGWS3Pa1qLq0y4byn0W/LU84BXrLBrk6rTfs0oPOufN2qeXVoYer2LIr10iOg xIPue+I9yxr4uyrqYKGp1Q8HTp7yBkgjqIQ0jfBmZBse6uoUwKZxG95DEYNT0Zc= =/eKb -----END PGP SIGNATURE----- --Apple-Mail=_44796B83-9D94-4286-9F84-2B13D7B4AB3C-- From nobody Tue Aug 1 10:35:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF41321CE for ; Tue, 1 Aug 2017 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlEmdEcqLiTd for ; Tue, 1 Aug 2017 10:35:08 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8751321CC for ; Tue, 1 Aug 2017 10:35:07 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id a18so13389190qta.0 for ; Tue, 01 Aug 2017 10:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bHx+VuFp5ZN9FO2PTrhFyU0eEFBcIWvaa5hfCL9Qv/0=; b=L9sOGNHzIX60J+jC/W4D3JQRKXWvXQBIApQ87fz4t5R4bcR4AT6oGHVmM+Cq1sEGth ZefQwWsg7L+iOr2hTC2qpgPne9NToC1DDsTIhlbAZXDky4lI1g759MdQSwdJ91qghx4o 9M7MP8MgznhUsfoHvMMGwzwf3TB+F7NAjV/fjZWtmyL1hv8xz9aVuIlcVei4NGsSD+86 sINRgeaqnqDsXQI/TjCKiDFC6ydW8Yld1rDeOSd6PHxbaN62ufGuQFDjaZmgalHWSA17 UIyolaMoPFN0wPTvF8bDT86+cSbIFRNA1Rx0B5OkKLzZTSk+IDv6gGzdpUg9t2FWop5b kmYg== 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=bHx+VuFp5ZN9FO2PTrhFyU0eEFBcIWvaa5hfCL9Qv/0=; b=sisy7Q5JzmIgbla8HGvwGctXzL6qSujoGVg1eaINYtuR1OuiLU48lDEgYpLeMlYTiL xaG3RkkeCIOPjH5bcifUckhnYz/M+wA0gtkbWOQ9iAs9TFAFXwoqxJqWYCb0/TPZfbmR 4LnVUIKHhcSdXIB4w/aAE9jF5wHLQ3Y36UUGYWRF9Cn+zlzBDZ1O9yNnacBNTNkRntFm +Iq5upyIwqlD+QJA6McoMbmhWbbdSDgKmzqUzaONg3Q5xdXAiteJJbTjm9Ha1QTbwAGO c8PZ8HkqmXMC7dd7Ttm/nEYzsyGVhgt60S4qZP5jnJjsWEOcD9xNWVawlDuvAc09VwDY +maQ== X-Gm-Message-State: AIVw112NWhjrSy7BNrKHzgJvOdzoj57otSqqMeX8KGwNp7K9k+1ZqFC9 5yw2qtSTMT6lA384ERobRvn3DJBBew== X-Received: by 10.237.60.57 with SMTP id t54mr29903305qte.281.1501608906735; Tue, 01 Aug 2017 10:35:06 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 1 Aug 2017 10:35:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 1 Aug 2017 10:35:06 -0700 X-Google-Sender-Auth: xMcSE8ltkmgJ5IpJ7U1fh77OJB4 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Mark Smith Cc: David Farmer , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 17:35:10 -0000 At Tue, 1 Aug 2017 16:10:16 +1000, Mark Smith wrote: >> In my opinion the current text gives the false impression that there is >> always a common prefix for address assignment and on-link determination, or >> the subnet prefix and the on-link prefix are the same, which they >> frequently are, but are not require to be. > > This is confusing. What address generation and configuration method is > being used? DHCPv6, SLAAC or manual configuration? > > I don't understand how the subnet prefix and the onlink (subnet) prefix can > be different. For simplicity let's focus on SLAAC for address configuration and RA-based on-link determination. Then, do you mean you don't understand how these two can be different? - a prefix advertised in an RA PIO with the A flag on, for SLAAC - a prefix advertised in an RA PIO with the L flag on, for on-link determination If that's what you mean, I'd suggest you read draft-jinmei-6man-prefix-clarify-00. Essentially, there's nothing new in this draft itself - one can reach the conclusion from existing RFCs, but this draft gives a set of facts regarding this specific question. You may not like the conclusion or might even want to call it "broken configuration" etc, but at least today these two can be different. And that's intentional for the protocol designer, explicitly discussed while the wg worked on rfc2462bis and confirmed. -- JINMEI, Tatuya From nobody Tue Aug 1 11:11: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 0C6971321CD for ; Tue, 1 Aug 2017 11:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waB26zHg8uAZ for ; Tue, 1 Aug 2017 11:11:42 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CEA131566 for ; Tue, 1 Aug 2017 11:11:41 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id p3so13847357qtg.2 for ; Tue, 01 Aug 2017 11:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VcFdR1EFwRx/767/dLRT3ug93U/E6H8eZhyOE9okd/o=; b=RpBmpN4sKOsmaGLsMdfcTJRn/oUuVU4Xpzvh4il07W/0agNKpdyxaQ6eECWmIdFeyq EqvimWMrIoKOO3mObXK/img/Wn2wWX4YYj2sIVgQI+LjT4lGRE2r8QTeiRZ7bZBeb7/o V+GCT2e0mRd4Uq4/nVUg0TLdVjkSXpNSDzEQUb9jvgjKehO17CfzdJStWSB6BF2ovOuq /cumLfacFyFZfBsBLINudRs32y7DuJyoHN/VtSQwb/SOTj+DoInOrjG6+x+/HheXjdwL Ns8ltHS2DPKRhgWSuIyKxFS8wGichBo51behx5gDdBKIvpeRUiswAvfBsyyORDAcSuml keUg== 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=VcFdR1EFwRx/767/dLRT3ug93U/E6H8eZhyOE9okd/o=; b=t6KY0j8mD+TTxdDtvJ1hbMMDMUyFVjF8BOidDsMpQj9V1M92ra8QxV/HWMCH7EQgpf udIE1ig5f8j3yCAAB4oAFd39P9Ta0CVfIp0nZ+JRq0r+pNvKJA+Ouz3rsyT8QAI/iAnm gq+FCogNR/d6Eox+qU+ZEYr+BYEwbARJw0emGWiHm2gJq83MtdJg2oH9l1SZf24TbEq2 r1f5zkU/2NpaxpA/vxgGRDHZSDaOEIVPfVHP1kqQeeWPLTbUZvTDMH8WJWccqJEguD6y pMeNQiR6xvdTMfqIERzIJwBmV5aZlBd38N0WpiZmOGgJDDrJHq1HbiIyH2G3xYFRGp+s sBRw== X-Gm-Message-State: AIVw110RqoCW66GL/BQyDqm22ApXa/KLmTV0wYtpOBP4/YJ/qT7A57u7 NP1UuOu1JFEGUSwaFqd2nQlHMvZ+zQ== X-Received: by 10.200.41.241 with SMTP id 46mr17600121qtt.339.1501611100720; Tue, 01 Aug 2017 11:11:40 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 1 Aug 2017 11:11:40 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 1 Aug 2017 11:11:40 -0700 X-Google-Sender-Auth: qV2DGUb3oVzD8T-tPn0FJUYv59I Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: David Farmer Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:11:43 -0000 At Mon, 31 Jul 2017 17:32:34 -0500, David Farmer wrote: > Recent discussion on the list have convinced me that section 2.4 really > needs to discuss on-link prefixes in some detail. It needs to describe > their format similar to how the format of subnet prefixes are described, > and describe how on-link prefixes are used by nodes. Also, a description of > how subnet prefixes are used is needed to differentiate the two types of > prefixes are used. Several other changes were needed to integrate these > major changes with the rest of the text, with other additional editorial > changes. [...] > What do others think? Personally, I can generally live with the proposed text in terms of making progress (with one reservation, see below), but I don't see much advantage over the way simpler proposal by Brian: On Sat, Jul 22, 2017 at 1:47 PM, Brian E Carpenter wrote: >> Here's a thought. How would it be if the contentious sentence in 4291bis >> read, in its entirety: >> >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." And, at least I don't think this is a good idea: > In my opinion the current text gives the false impression that there is > always a common prefix for address assignment and on-link determination, or > the subnet prefix and the on-link prefix are the same, which they > frequently are, but are not require to be. to be more specific, this is the actual proposed text: > A node may also be aware of on-link prefix(es) for the link(s) it is > attached to. Such nodes may use the on-link prefix(es) to determine > the unicast addresses for which packets may be locally delivered on > the attached link(s). Where different link(s) may have different > values for n: > > | n bits | 128-n bits | > +-------------------------------+---------------------------------+ > | on-link prefix | interface ID | > +-------------------------------+---------------------------------+ I'm afraid this is not only controversial but also technically not very accurate. If a host receives an on-link prefix 2001:db8:1:abc0:/60 in an RA PIO, for example, this prefix might actually be an aggregated on-link prefix for the following 16 /64 prefixes: 2001:db8:1:abc0::/64 2001:db8:1:abc1::/64 ... 2001:db8:1:abcf::/64 each of which is used as the subnet prefix for SLAAC. In this case the intermediate 4 bits are actually used as some intra-link group ID, and the remaining 64 bits are the "interface identifier". We could still call the combined 68 bits an "interface identifier" (after all, when you introduce a new definition it can have any name as you like), but I think it's rather confusing. -- JINMEI, Tatuya From nobody Tue Aug 1 11:59: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 6D89A1322AF for ; Tue, 1 Aug 2017 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwXvH0_aWZQr for ; Tue, 1 Aug 2017 11:59:05 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7F313229E for ; Tue, 1 Aug 2017 11:59:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v71Ix3DN041655; Tue, 1 Aug 2017 11:59:04 -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 v71Iwume041562 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 1 Aug 2017 11:58:57 -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.1320.4; Tue, 1 Aug 2017 11:58:55 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Tue, 1 Aug 2017 11:58:55 -0700 From: "Manfredi, Albert E" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: 6man WG Subject: RE: Section 2.4 of rfc4291bis Thread-Topic: Section 2.4 of rfc4291bis Thread-Index: AQHTCvGfxpcH+441Qkin2Iz+rr4Fg6Jv1XtQ Date: Tue, 1 Aug 2017 18:58:55 +0000 Message-ID: <737d661630f84c6ebeeaa13dc499e226@XCH15-06-11.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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:59:06 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of [Tatuya Jinmei] > For simplicity let's focus on SLAAC for address configuration > and RA-based on-link determination. Then, do you mean you > don't understand how these two can be different? > - a prefix advertised in an RA PIO with the A flag on, for SLAAC > - a prefix advertised in an RA PIO with the L flag on, for on-link > determination To me, the simplest way to get the point across is to explicitly state that= in principle, SLAAC can be used to configure interfaces that are not on-li= nk. And then, you let the reader wonder what good such addresses would be. = But the point is simple enough to make, using your example. It is conceivab= le that SLAAC creates an address, but too bad, so sad, it can=1B$B!G=1B(Bt = be used on this link. On Sat, Jul 22, 2017 at 1:47 PM, Brian E Carpenter wrote: >> Here's a thought. How would it be if the contentious sentence in 4291bis >> read, in its entirety: >> >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." Yes, stating also this explicitly helps, and it eliminates the need to list= exceptions. As of today, I don=1B$B!G=1B(Bt think there's any intention of= creating IIDs other than 64 bits using SLAAC, *and* I don=1B$B!G=1B(Bt thi= nk there's any desire to create IIDs longer than 64 bits at all. But that l= ast point could potentially change in the future. > for example, this prefix might actually be an aggregated on-link prefix > for the following 16 /64 prefixes: > 2001:db8:1:abc0::/64 > 2001:db8:1:abc1::/64 > ... > 2001:db8:1:abcf::/64 > each of which is used as the subnet prefix for SLAAC. In this case > the intermediate 4 bits are actually used as some intra-link group > ID, and the remaining 64 bits are the "interface identifier". We > could still call the combined 68 bits an "interface identifier" (after > all, when you introduce a new definition it can have any name as you > like), but I think it's rather confusing. Agreed. I've wondered about this very example. However, if IIDs longer than= 64 bits are not contemplated, then the situation is identical to what is a= lready the case in IPv4. A prefix assigned by, say, an ISP, can be further = lengthened on your premises. On the other hand, there's also no reason to d= ismiss the possibility of IIDs longer than 64 bits, on certain links, for w= hatever weird circumstances in the future. Bert From nobody Tue Aug 1 12:11: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 249B313229B for ; Tue, 1 Aug 2017 12:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXhfsScBCKq3 for ; Tue, 1 Aug 2017 12:11:47 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AB913229E for ; Tue, 1 Aug 2017 12:11:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v71JBj49064236; Tue, 1 Aug 2017 12:11:46 -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 v71JBiKB064220 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 1 Aug 2017 12:11:44 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 1 Aug 2017 12:11:43 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Tue, 1 Aug 2017 12:11:43 -0700 From: "Manfredi, Albert E" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: 6man WG Subject: RE: Section 2.4 of rfc4291bis Thread-Topic: Section 2.4 of rfc4291bis Thread-Index: AQHTCvGfxpcH+441Qkin2Iz+rr4Fg6Jv1XtQgAAHClA= Date: Tue, 1 Aug 2017 19:11:43 +0000 Message-ID: <59000fc1b71044f39b2691b2cb719afd@XCH15-06-11.nw.nos.boeing.com> References: 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-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:11:48 -0000 Just to clarify this: "To me, the simplest way to get the point across is to explicitly state tha= t in principle, SLAAC can be used to configure interfaces that are not on-l= ink." This would not be the responsibility of RFC 4291-bis, I shouldn't think. It= 's a quirk of SLAAC that RFC 4862-bis should elaborate. Bert From nobody Tue Aug 1 15:35: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 65CBC131CCE for ; Tue, 1 Aug 2017 15:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4o7ulcJNa3f for ; Tue, 1 Aug 2017 15:35:11 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6FA1294A2 for ; Tue, 1 Aug 2017 15:35:05 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x191so17557233qka.5 for ; Tue, 01 Aug 2017 15:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RUBcz0VnQkCR9+6BEtA3u95r0cSHkE693Uj2EUO8Z8Y=; b=Q7229FETk0RIbuZBwWHIQeoOUGMyxd6o4L8HewKxdgxhTwYVfUqtPAnClMfB5wz/NQ c+NpIA7yjp3DFluPoOFEJIvZVU31vX14zQK9BrnMW22qIwP5MzhiysVjSVanzgcd5hDA U/LRT+oVcieeSxU6JIRIrmw5bqIDvq6AQFbbv2LKTV/myNrmVN8X8DnI1Dh5vyjvCu1a Arks8u5VxcNQ9MbmkF+jILNxkG7C3O2SVV1gFW4JyBZQGGJBI7SpMze8//JEnmpHyiFJ Sv6QHWNQB58S4q/VE/GvRN+y8Jc2YFmPlrwVxKeOg5MFxsRcdOnXo4J+MMLTdlv7KeeW VNMQ== 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=RUBcz0VnQkCR9+6BEtA3u95r0cSHkE693Uj2EUO8Z8Y=; b=FLi797YXW4XIYGFLF9B8a9DqU9YpuxdNIhpeljUsyhoxn/hWck46HetizgvDs6AdzZ XF2fwkK2Vcrzr2K9sFxHEQISwaOI0OC1rKBmytw39WwLgQNc0bUHHyN2UeulJQKp1jME w+UAOGP0NmAas6YdrgRcyLSrlrhu378Q/Q5QdJRWv26OomqvhpwiGla94y/5+lxhl8iN qJzKhCphII824plJx3hGxDirzkEU1NtOYKyECmIRxNWQenorEba909Jh6oppo71wqhpr MKPUKDC27ICSzUEH4hNpM8qZQuRUHykQy+GE8PCb9xcjHsh/fBIS4jfjl7RzQOsFnHll nlkA== X-Gm-Message-State: AIVw112tCQSkyoeUbx2Gsn7iuz9KZBwGDFoYt/mcPn1XlwsUyAAFx3Sn os+9enNmfzXoZ9N2aHyGKLSbbQLdgA== X-Received: by 10.55.92.130 with SMTP id q124mr27044299qkb.274.1501626904374; Tue, 01 Aug 2017 15:35:04 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 1 Aug 2017 15:35:03 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 1 Aug 2017 15:35:03 -0700 X-Google-Sender-Auth: OeDoobt-fDG34RFtB_f0bjepIIw Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: David Farmer Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:35:13 -0000 On Tue, Aug 1, 2017 at 11:11 AM wrote: > And, at least I don't think this is a good idea: > >> In my opinion the current text gives the false impression that there is >> always a common prefix for address assignment and on-link determination, or >> the subnet prefix and the on-link prefix are the same, which they >> frequently are, but are not require to be. Oops, I've just noticed I made a cut-and-paste error and referred to the wrong text. What I meant here is this one: >> I have use Interface Identifier as the right-hand side of the >> on-link prefix, but this could have a different name if that is the >> consensus of the work group, but I think Interface Identifier makes >> the most sense. The rest of my point was about this text. Sorry for any possible confusion due to the error. > to be more specific, this is the actual proposed text: > >> A node may also be aware of on-link prefix(es) for the link(s) it is >> attached to. Such nodes may use the on-link prefix(es) to determine >> the unicast addresses for which packets may be locally delivered on >> the attached link(s). Where different link(s) may have different >> values for n: >> >> | n bits | 128-n bits | >> +-------------------------------+---------------------------------+ >> | on-link prefix | interface ID | >> +-------------------------------+---------------------------------+ > > I'm afraid this is not only controversial but also technically not > very accurate. If a host receives an on-link prefix 2001:db8:1:abc0:/60 > in an RA PIO, for example, this prefix might actually be an aggregated > on-link prefix for the following 16 /64 prefixes: > 2001:db8:1:abc0::/64 > 2001:db8:1:abc1::/64 > ... > 2001:db8:1:abcf::/64 > each of which is used as the subnet prefix for SLAAC. In this case > the intermediate 4 bits are actually used as some intra-link group > ID, and the remaining 64 bits are the "interface identifier". We > could still call the combined 68 bits an "interface identifier" (after > all, when you introduce a new definition it can have any name as you > like), but I think it's rather confusing. From nobody Tue Aug 1 21:42: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 9A68C126BF3 for ; Tue, 1 Aug 2017 21:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k55OkD5WJLSs for ; Tue, 1 Aug 2017 21:42:20 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0884F126B6D for ; Tue, 1 Aug 2017 21:42:20 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id q25so15823686uah.1 for ; Tue, 01 Aug 2017 21:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wBebsHs5syDLiJTz83K1/UM5GENL/rHwxi6DXvxGu34=; b=bnlJGW686G6Ftn2nB8bv4Xm8tItq/nt5ah092W26/cPHBo+7Et0Bqy3bKGN0Fyj78N c12MHZg0go7WYnQP2GFNSJ9agzpOJ8Z02blG41bzsuvzseTGCc4HiEmaDEDwF7prTigy JHWsSdUnaUDol8QYQbQEMbHfAAyYQuVy0SbMEXDSqHynrn9uCSP+M3e/hjXabloHEku3 mx8CtdW5Z1Y8bKdn5WT/c11I2j7PNl6hsPSGt8YRjcRvE37eFGoiWHhypXasGHbJ4FMj 8ZfyU/vLU+uzsj9a/SDRuPhi5qcaM+klQfqjf1ZKNO9T3An6ztn4pFLYdBr0hJxvQE3n 0+Rg== 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=wBebsHs5syDLiJTz83K1/UM5GENL/rHwxi6DXvxGu34=; b=lfUemrBGYr89cTTzsZp8qa+XKFABtfJ3yJ/oIyu7IdROfGaTr0bvgJDBVI65B1wez+ JGbuoH9UAir0u5t4ZVBWxroonT0//Nc8ZqXjW1E2inHgRvg7uxUh2Jr6MQXZO3CQWkMt aL40nHLsfJdEdeykzWo2/dL33T1Mn9G6a0TVQPaiFRni3luTIyfVeL1zktOomAaHeXgA LYMXYJCFbiAEK2/aONk7mTiQ6OippAvgeyaqfT4NRnm7EycsSKVvnnXyQhHgESRqr8ML PTWQegePTwztYkObbITw+qqbjRftzEXzFEIXvXTQN+Ei4HHUSd4KevCp9NuoqgdVJlnz KknQ== X-Gm-Message-State: AIVw110P6n9P4F453ptb5z4/szsnG6QAMwjelj/yMn3bHKkGyfmvBCx+ N93E2uEdYY2b2fc0xUdwukKKZfNZLQ== X-Received: by 10.159.54.197 with SMTP id p63mr16515968uap.136.1501648939126; Tue, 01 Aug 2017 21:42:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Tue, 1 Aug 2017 21:42:18 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Tue, 1 Aug 2017 21:42:18 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Wed, 2 Aug 2017 14:42:18 +1000 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man WG , David Farmer Content-Type: multipart/alternative; boundary="94eb2c048b649812430555bde37d" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 04:42:22 -0000 --94eb2c048b649812430555bde37d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 2 Aug. 2017 03:35, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: At Tue, 1 Aug 2017 16:10:16 +1000, Mark Smith wrote: >> In my opinion the current text gives the false impression that there is >> always a common prefix for address assignment and on-link determination, or >> the subnet prefix and the on-link prefix are the same, which they >> frequently are, but are not require to be. > > This is confusing. What address generation and configuration method is > being used? DHCPv6, SLAAC or manual configuration? > > I don't understand how the subnet prefix and the onlink (subnet) prefix can > be different. For simplicity let's focus on SLAAC for address configuration and RA-based on-link determination. Then, do you mean you don't understand how these two can be different? - a prefix advertised in an RA PIO with the A flag on, for SLAAC - a prefix advertised in an RA PIO with the L flag on, for on-link determination No, completely understand that e.g. https://www.slideshare.net/mobile/MarkSmith214/ipv6-ras-mostly-necessary I'm pretty confident of my understanding of all of these things. That's why I don't understand the need for any new terminology or concepts. The need is not obvious to me, which is why I need more stated and explained context and description of the problem and confusion. The problem may be that some of the concepts aren't as clear to others. I think that would argue for more clarity and explanation, perhaps in another ID. I think creating new terms and concepts may create more confusion rather than eliminating it. If that's what you mean, I'd suggest you read draft-jinmei-6man-prefix-clarify-00. Essentially, there's nothing new in this draft itself Agree. I haven't fully read it, however one thing I'd suggest adding (discovered missing by searching for 'DHCP') is that the use of stateful DHCPv6 for addressing is only an alternative to SLAAC addressing, and is not making any implied statements about the prefix the DHCPV6 addresses are coming from. If nodes receiving addresses via DHCPV6 are to consider other addresses in the link's prefix onlink, then there also needs to be an RA PIO with the L bit set for the prefix. I'd also mention that SLAAC and DHCPv6 addressing can coexist within the same prefix (and do in deployed practice, because that is the default IPv6 configuration for OpenWRT/LEDE). - one can reach the conclusion from existing RFCs, but this draft gives a set of facts regarding this specific question. You may not like the conclusion or might even want to call it "broken configuration" etc, but at least today these two can be different. And that's intentional for the protocol designer, explicitly discussed while the wg worked on rfc2462bis and confirmed. Regards, Mark. -- JINMEI, Tatuya --94eb2c048b649812430555bde37d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 2 Aug. 2017 03:35, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89&= quot; <jinmei@wide.ad.jp> wr= ote:
At Tue, 1 Aug 2017 16= :10:16 +1000,
Mark Smith <markzzzsmith@gmail.com> wrote:

>> In my opinion the current text gives the false impression that the= re is
>> always a common prefix for address assignment and on-link determin= ation, or
>> the subnet prefix and the on-link prefix are the same, which they<= br> >> frequently are, but are not require to be.
>
> This is confusing. What address generation and configuration method is=
> being used? DHCPv6, SLAAC or manual configuration?
>
> I don't understand how the subnet prefix and the onlink (subnet) p= refix can
> be different.

For simplicity let's focus on SLAAC for address configuration and=
RA-based on-link determination.=C2=A0 Then, do you mean you don't
understand how these two can be different?
- a prefix advertised in an RA PIO with the A flag on, for SLAAC
- a prefix advertised in an RA PIO with the L flag on, for on-link
=C2=A0 determination
No, completely understand that e.g.


I'm pretty confident of my understanding = of all of these things. That's why I don't understand the need for = any new terminology or concepts. The need is not obvious to me, which is wh= y I need more stated and explained context and description of the problem a= nd confusion.

The proble= m may be that some of the concepts aren't as clear to others. I think t= hat would argue for more clarity and explanation, perhaps in another ID. I = think creating new terms and concepts may create more confusion rather than= eliminating it.


If that's what you mean, I'd suggest you read
draft-jinmei-6man-prefix-clarify-00.=C2=A0 Essentially, there's no= thing new
in this draft itself

<= /div>
Agree.

I haven't fully read it, however one thing I'd suggest adding= (discovered missing by searching for 'DHCP') is that the use of st= ateful DHCPv6 for addressing is only an alternative to SLAAC addressing, an= d is not making any implied statements about the prefix the DHCPV6 addresse= s are coming from.

If no= des receiving addresses via DHCPV6 are to consider other addresses in the l= ink's prefix onlink, then there also needs to be an RA PIO with the L b= it set for the prefix.

I= 'd also mention that SLAAC and DHCPv6 addressing can coexist within the= same prefix (and do in deployed practice, because that is the default IPv6= configuration for OpenWRT/LEDE).


- one can reach the conclusion fr= om existing
RFCs, but this draft gives a set of facts regarding this specific
question.=C2=A0 You may not like the conclusion or might even want to call<= br> it "broken configuration" etc, but at least today these two can b= e
different.=C2=A0 And that's intentional for the protocol designer,
explicitly discussed while the wg worked on rfc2462bis and confirmed.

= Regards,
Mark.



--
JINMEI, Tatuya

--94eb2c048b649812430555bde37d-- From nobody Wed Aug 2 06:02: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 045F81320A2 for ; Wed, 2 Aug 2017 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59nKLPWj85nr for ; Wed, 2 Aug 2017 06:02:51 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6A71320A3 for ; Wed, 2 Aug 2017 06:02:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.55] (lan.furness.net [84.9.59.220]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2F3CF1BC37 for ; Wed, 2 Aug 2017 13:02:34 +0000 (UTC) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Section 2.4 of rfc4291bis From: Simon Hobson In-Reply-To: <737d661630f84c6ebeeaa13dc499e226@XCH15-06-11.nw.nos.boeing.com> Date: Wed, 2 Aug 2017 14:02:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <737d661630f84c6ebeeaa13dc499e226@XCH15-06-11.nw.nos.boeing.com> To: 6man WG X-Mailer: Apple Mail (2.1510) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:02:53 -0000 "Manfredi, Albert E" wrote: > To me, the simplest way to get the point across is to explicitly state = that in principle, SLAAC can be used to configure interfaces that are = not on-link. Do you mean "configure interface addresses" that are no "on link" ? If = so, then I agree - but it's also not confined to SLAAC. > And then, you let the reader wonder what good such addresses would be. = But the point is simple enough to make, using your example. It is = conceivable that SLAAC creates an address, but too bad, so sad, it = can=1B$B!G=1B(Bt be used on this link. Not "on link" =3D/=3D "not usable on this link". AIUI, all it means is = that other nodes (with addresses in the same prefix) will need to use a = router to get packets to you. AIUI some network types, either generally or as an option, restrict = direct node-node communications. Either due to physical constraints, or = for better control of traffic/security/privacy. Or have I misunderstood ? From nobody Wed Aug 2 06:46: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 9CB37126C83 for ; Wed, 2 Aug 2017 06:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLCB1URH2dVJ for ; Wed, 2 Aug 2017 06:46:17 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39272131EBA for ; Wed, 2 Aug 2017 06:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1501681575; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=nP8odYLz+o2+ngHnHise/s2OUgAJkr+SqTp3rZhv45s=; b=EbhDkBJnQIqfHrK/b7L3eCZERHiCokkoNKRdUHtgS2yH5rZRMbzvOzCrJCVLf3bpA8tt196IWl2XLe9d7mck9nR+pj5OkGbfGlXyoH9KZJv+5K4z3BWEw9o9exfLMB74TMiCwGqCGeP+1aE8mU9AvBerKe9Gv4OEnL9h2GCEh9o= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0152.outbound.protection.outlook.com [213.199.154.152]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-30-qVp9Fp1BPpa2xPHsBPjLng-1; Wed, 02 Aug 2017 14:46:12 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Wed, 2 Aug 2017 13:46:10 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.010; Wed, 2 Aug 2017 13:46:10 +0000 From: Tim Chown To: IPv6 Ops WG , 6man WG Subject: Re: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) Thread-Topic: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) Thread-Index: AQHTC5Wy7f5vc2yinEOig6bEWwhs6g== Date: Wed, 2 Aug 2017 13:46:10 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0632; 20:WLK6uIdb5y5hVnljSjHDbOKDorFrjSF0bAuRO8e/9YKRPIwZ6uqxbhZYi/FlFhoDGChaoZqT2JETrP1FEGBVyohKbCRIoWHh2+BXW6FjOU213JY1OBxGFJI+MIO4lT17YF1geXW9T+Sze1wbIbrvIrfSKl/Es78yFqqRwdiT0nQ= x-ms-office365-filtering-correlation-id: f8506432-3101-4e45-adee-08d4d9acd592 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0632; x-ms-traffictypediagnostic: AM3PR07MB0632: x-exchange-antispam-report-test: UriScan:(43178223235956); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0632; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0632; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(24454002)(189002)(199003)(450100002)(478600001)(6436002)(74482002)(81156014)(3660700001)(81166006)(76176999)(305945005)(3280700002)(7736002)(8936002)(53546010)(50986999)(3846002)(68736007)(36756003)(38730400002)(106356001)(8676002)(86362001)(5660300001)(2906002)(105586002)(566174002)(93886004)(6246003)(50226002)(229853002)(6306002)(66066001)(6512007)(5250100002)(189998001)(6116002)(966005)(6486002)(101416001)(102836003)(83716003)(99286003)(6506006)(82746002)(72206003)(97736004)(25786009)(33656002)(14454004)(2950100002)(2900100001)(53936002)(57306001)(42882006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0632; 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: 02 Aug 2017 13:46:10.6375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0632 X-MC-Unique: qVp9Fp1BPpa2xPHsBPjLng-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:46:19 -0000 Hi, > On 26 Jul 2017, at 22:44, Mark Smith wrote: >=20 > >=20 > No. On PPP you don't need DAD for LLA. >=20 > I think you now do per RFC8064/RFC7217. >=20 > I don't really understand the motivation for avoiding DAD. It's a very ma= rginal saving (1 packet) in comparison to the problems and time involved in= troubleshooting duplicate addresses. >=20 > In the scenario described, it can be much worse because there is likely a= non-technical end-user and a helpdesk involved in what can be an intermitt= ent and obscure fault (Helpdesks can be motivated to get the customer off t= he phone by saying "reboot the modem and call us back if you have more prob= lems", which doesn't prevent the fault re-occurring.) >=20 > I think absolute and consistent failure is much better and easier to trou= bleshoot than partial and intermittent failure when the cause is simple to = determine and discover. To step up back to the original question, what specific text or guidance sh= ould be in draft-ietf-v6ops-ipv6rtr-reqs-00, or even RFC6434-bis (hence my = interest), with respect to IPv6 CPEs shipping with IPv6 enabled by default? This is what the draft currently says about provisioning: https://tools.iet= f.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3 Is that sufficient?=20 Tim From nobody Wed Aug 2 12:09: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 AB67F131FBD for ; Wed, 2 Aug 2017 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsovo3J9BD4h for ; Wed, 2 Aug 2017 12:09:53 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D30A13202C for ; Wed, 2 Aug 2017 12:09:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v72J9n3e055402; Wed, 2 Aug 2017 12:09:50 -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 v72J9g7J055344 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 2 Aug 2017 12:09:42 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 2 Aug 2017 12:09:41 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Wed, 2 Aug 2017 12:09:41 -0700 From: "Manfredi, Albert E" To: Simon Hobson , 6man WG Subject: RE: Section 2.4 of rfc4291bis Thread-Topic: Section 2.4 of rfc4291bis Thread-Index: AQHTC4+as9/bTjVXKUubMSb6La5FMKJxa8Zg Date: Wed, 2 Aug 2017 19:09:41 +0000 Message-ID: References: <737d661630f84c6ebeeaa13dc499e226@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 19:09:55 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Simon Hobson >> To me, the simplest way to get the point across is to explicitly state >> that in principle, SLAAC can be used to configure interfaces that are >> not on-link. > > Do you mean "configure interface addresses" that are no "on link" ? Yes, sorry. > Not "on link" =3D/=3D "not usable on this link". AIUI, all it means is th= at > other nodes (with addresses in the same prefix) will need to use a > router to get packets to you. Okay. I suppose this could be true in some odd cases like IPv6 over ATM, or= whatever, or it could be that the prefix is not on link at all. Don't want= to speculate on all the ramifications or possible uses. However I agree with Mark, this has no impact on address format. It's not a= "different type" of IPv6 unicast address. RFC 4291 is about address archit= ecture, so the fine nuances of SLAAC don't need to be addressed here at all= ? Bert From nobody Wed Aug 2 14: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 1457F132178; Wed, 2 Aug 2017 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e627vpN0Yvez; Wed, 2 Aug 2017 14:01:14 -0700 (PDT) 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 92430132176; Wed, 2 Aug 2017 14:01:14 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id y129so25746589pgy.4; Wed, 02 Aug 2017 14:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+doTS0YpbX2J/TbPoWSlXzBTegIMTQZFDjN/6ZvDezA=; b=KlZIN76NDjW5itG5xHGRTMmSswSOPNC97mM5OTV24g1wc6pqlblzdj8b3p9wMslbl3 ZhIIF+iWs+RDWor3XLacBrPf+EZoMvuKaq1B+utjVp2ddo2VCbZUt2B2pG7H1nVFxkw9 2H0G/DK5GFrLWR4Hs4ucMBhKqIo73OFVRCYYLm0Ez2EBKcQStjNwFJ77L9k7D1UCaqJ+ XgVvdlxNfRHgu2bjAY10xjQcXA5VcyazShMQ1NckeOuGknT3fYoUvDsVhtEoB/FKWEBn tg/arEfXENd3QUKnrWCSaP62BOu7nyBw3BLz6OCKEbC2IrhaqV8SkQMQuIBrt6E6fFDM 7LeQ== 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:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+doTS0YpbX2J/TbPoWSlXzBTegIMTQZFDjN/6ZvDezA=; b=qLitqXpep7zotTgHtoYZk30tvdZH9d8hYnOO5V9LXUrDx6QGQH7CDbYPrT1uOiEnIO /8aiZRKZSkwqO91bUMDQdvm8DFE0c9BorAD9QE85Fff0hcgZMxSLhAGaR2fYvoynU7xB BvyCOm9q6Sg1h5NGM4zDJy1F1cTUhIZoQPeW96mlZVHLS+6CnWbI4SpzkgSt7f/UZYsB UT8Mmsec0encwDQKADEkrXbJUtycVeQhqabUZ7KsciT0Y38pUny0cpP+jXHG/wiOP7fv AM6TMAGYjvqZO2v78/Zlr06qBMG2fwbxwv0AxvVqCBzLJktgTVrcK3q05u5rsptrNIH7 9Feg== X-Gm-Message-State: AIVw112ZXdd2BUX6HOn/qckB4htuBgZdX4ww8+7xqjwXA27hnTtW+Exg lwoz2qrXu++SR8lv X-Received: by 10.84.224.141 with SMTP id s13mr26088581plj.212.1501707673198; Wed, 02 Aug 2017 14:01:13 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z66sm24366590pfi.137.2017.08.02.14.01.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 14:01:12 -0700 (PDT) Subject: Re: [v6ops] Turning on IPv6 Routers (was PPPoE requirements) To: Tim Chown , IPv6 Ops WG , 6man WG References: <2D09D61DDFA73D4C884805CC7865E6114DBDC2E7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DBDCD6D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Cc: draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Message-ID: Date: Thu, 3 Aug 2017 09:01:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 21:01:16 -0000 On 03/08/2017 01:46, Tim Chown wrote: > Hi, > >> On 26 Jul 2017, at 22:44, Mark Smith wrote: >> >> >> >> No. On PPP you don't need DAD for LLA. >> >> I think you now do per RFC8064/RFC7217. >> >> I don't really understand the motivation for avoiding DAD. It's a very marginal saving (1 packet) in comparison to the problems and time involved in troubleshooting duplicate addresses. >> >> In the scenario described, it can be much worse because there is likely a non-technical end-user and a helpdesk involved in what can be an intermittent and obscure fault (Helpdesks can be motivated to get the customer off the phone by saying "reboot the modem and call us back if you have more problems", which doesn't prevent the fault re-occurring.) >> >> I think absolute and consistent failure is much better and easier to troubleshoot than partial and intermittent failure when the cause is simple to determine and discover. > > To step up back to the original question, what specific text or guidance should be in draft-ietf-v6ops-ipv6rtr-reqs-00, or even RFC6434-bis (hence my interest), with respect to IPv6 CPEs shipping with IPv6 enabled by default? > > This is what the draft currently says about provisioning: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3 > > Is that sufficient? This seems under-specified to me: "SLAAC MUST be able to be disabled by operators who prefer to use some other mechanism for address management and assignment (specifically for customer facing edge ports)." Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as configuring LL addresses goes. So it can't be "disabled" as such. I think this wants to say that it MUST be possible to configure RA/PIOs with A=0. In turn that means that RFC4861 MUST be supported - and that isn't even cited anywhere in the draft. Doh! An IPv6 router without RAs would be a strange beast. Brian From nobody Wed Aug 2 20:56: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 C22C51321E8; Wed, 2 Aug 2017 20:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz_eONUt5PlM; Wed, 2 Aug 2017 20:56:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F3120727; Wed, 2 Aug 2017 20:56:33 -0700 (PDT) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id C3B10E6065; Thu, 3 Aug 2017 05:56:31 +0200 (CEST) Date: Thu, 03 Aug 2017 05:56:31 +0200 (CEST) Message-Id: <20170803.055631.74690322.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com Cc: Tim.Chown@jisc.ac.uk, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Subject: Re: [v6ops] Turning on IPv6 Routers 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 03:56:36 -0000 > This seems under-specified to me: > "SLAAC MUST be able to be disabled by operators > who prefer to use some other mechanism for address management and > assignment (specifically for customer facing edge ports)." > > Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as > configuring LL addresses goes. So it can't be "disabled" as such. I think this > wants to say that it MUST be possible to configure RA/PIOs with A=0. Or configure no RAs at all. LL address generation is *not* dependent on RA (but *does* depend on NS/NA/DAD). It is perfectly possible to run IPv6 routing without RA (even if you don't normally want to do that). Check your nearest Juniper router if you doubt this is possible. Steinar Haug, AS2116 From nobody Wed Aug 2 22:34: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 2F7D6131C8C; Wed, 2 Aug 2017 22:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVWixjEvskfC; Wed, 2 Aug 2017 22:34:31 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E03131C31; Wed, 2 Aug 2017 22:34:31 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v77so2141838pgb.3; Wed, 02 Aug 2017 22:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VbNqVkvQP6BdLw17W8hjvzWpa4umOQRj3Y7orafXwms=; b=m6JFpJ2mFp17lQ4jr6bRZRth4qh50UcMkpuTrXBCwK0AHGa0UCaWJoWFjqNl0SDlmK 6Eq0QjUVSGTLcGZEQvOZKbZ/3khFaHf3PctgOmdnAefpSLaRvYmsZhX3k6Sf053OaDfZ rets72f4BfGxmoLcGZ4y9/GkQNlglF5/N5iYNvz69oP8QlYLLm1Pme3MoiJk+RlMCoUw oxD1VwZhrdhKSJQ0kzEEqOj9uXoROebZOHwsu/+GUSbM9/3WPnUM3eIJioXp1T7SGveJ qsmfEpbY1nYqv2T7uEY0Z065ZS5HRoI7GTxTqJFApioj0eknd1GqmJqvHeMxUvhPSBGX /vYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VbNqVkvQP6BdLw17W8hjvzWpa4umOQRj3Y7orafXwms=; b=QaH854m0l8JjVIUGo9RZmD3IWPEp/KOJV1/JxRdUgt6I4pVC3q4mvr2ZFD6rWHPXGV 7EdUbfc1/pHTBoVp7Hqj/zCWYBW/A6QuinNUEBUmlGQwoiFSDN4/48N9B6ffANITKbnR pa6h90Ey6sX5/8GAXIlC5TOKr1MbQ/7b62BCofIF6AoCkIutWj0LxPabeBGM/1mWkFbm aKT15pJRC56BqlRAWRshs3oT/b2fbyHpQZLk51hHQXYwl/9JLp1dVBjYGQE8YDn3sq4L CFicFiyQwZa1kh2tTGJIUAvuBwkMeRkwINaphaVx59K4b61hxSxHEzmI6t8gGwwPxyPH eJmQ== X-Gm-Message-State: AIVw1110aZGJr5pCVoDiaO/EwGRYqVs0o979GjRJasMT1wt5qLU7tLWj 7ltB7vXu1qQSl10a X-Received: by 10.99.149.6 with SMTP id p6mr486547pgd.412.1501738470887; Wed, 02 Aug 2017 22:34:30 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b4sm58200248pgc.9.2017.08.02.22.34.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 22:34:29 -0700 (PDT) Subject: Re: [v6ops] Turning on IPv6 Routers To: sthaug@nethelp.no Cc: Tim.Chown@jisc.ac.uk, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org References: <20170803.055631.74690322.sthaug@nethelp.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 3 Aug 2017 17:34:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170803.055631.74690322.sthaug@nethelp.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:34:33 -0000 On 03/08/2017 15:56, sthaug@nethelp.no wrote: >> This seems under-specified to me: >> "SLAAC MUST be able to be disabled by operators >> who prefer to use some other mechanism for address management and >> assignment (specifically for customer facing edge ports)." >> >> Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as >> configuring LL addresses goes. So it can't be "disabled" as such. I think this >> wants to say that it MUST be possible to configure RA/PIOs with A=0. > > Or configure no RAs at all. LL address generation is *not* dependent > on RA (but *does* depend on NS/NA/DAD). > > It is perfectly possible to run IPv6 routing without RA (even if you > don't normally want to do that). Check your nearest Juniper router > if you doubt this is possible. Where does the default router address come from, then? Brian From nobody Wed Aug 2 22:42: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 703621317A4; Wed, 2 Aug 2017 22:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUPEeNmEWScX; Wed, 2 Aug 2017 22:41:56 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9546126B6D; Wed, 2 Aug 2017 22:41:55 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 80so1709831uas.0; Wed, 02 Aug 2017 22:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VneExqkh+doZSkepI4MxxKmjsu9sMNnwYFT923vfNm8=; b=aUjW95zCNbBjUvGS2MLz/uuhtC/1Ffk4lSTQde1yezOAFKWLdX1BGmz5iHxzmvLIJt NFaKnTmCVRjIahij4hGUxmsHVQzlk4l0mYqVqv0GYDkHmIjFXaowhTlxA96WPK/pGQNi +8SI368ZsnfC2zNs9gmwx73PfvdPQdN8AFvqf0n7Y7y1g9erHdPtbHP9GeQ25ZCqQurL TlTwE8GvD56agxNHIJv2eMown9sG4sUtiJLUBFga4e9AVxklHc7wWUIeyDP2RfxL0fEH 7siQrw6ypsBtihSsjpYjNnvsTDkUhFVM0BF3LB59hoSpQPKZ5JoQUfOQbtgzQgQlZoBv ipjA== 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=VneExqkh+doZSkepI4MxxKmjsu9sMNnwYFT923vfNm8=; b=FDWIe5krKcERwgBhJPV/uGUSecgk2vCtlzkRH7v22B4iuTFKXjeYsxjUemmPKe7D/2 F7QrgjP+RxJquvv8AYMPc5V1lUd1PNN8imn+i0EN6uWFH7b4zBTcTppCkwvrfFtgx63j +Odxc9/JbYWKHLdU4DXcU3p4jFfm3bW712GvzBfmR7Z5EDNacI9B6/x+kCWnbQ+wrZdK SfMorjNsY96OXSn9Dm8auLpFeP2asrPDT6yXaa58wTV6XEDnhyGGvY8eOsVtmOeU536H KqA40bbSU9az+1dAiOlDtNIqYKbIlOajRmpR1YVLDVmCGqbmXu36taS32flm+UrH9yEa VIqg== X-Gm-Message-State: AIVw110StdMQOQNgvQ0Apz21I8XHJF//anlfqbkahH+r3/lKKh3sh04r FWPTO6/tAsf+vFgpqV8Onhy9xl2unQ== X-Received: by 10.176.8.81 with SMTP id b17mr370996uaf.82.1501738915083; Wed, 02 Aug 2017 22:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Wed, 2 Aug 2017 22:41:24 -0700 (PDT) In-Reply-To: References: <20170803.055631.74690322.sthaug@nethelp.no> From: Mark Smith Date: Thu, 3 Aug 2017 15:41:24 +1000 Message-ID: Subject: Re: [v6ops] Turning on IPv6 Routers To: Brian E Carpenter Cc: sthaug@nethelp.no, v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 05:41:57 -0000 On 3 August 2017 at 15:34, Brian E Carpenter wrote: > On 03/08/2017 15:56, sthaug@nethelp.no wrote: >>> This seems under-specified to me: >>> "SLAAC MUST be able to be disabled by operators >>> who prefer to use some other mechanism for address management and >>> assignment (specifically for customer facing edge ports)." >>> >>> Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as >>> configuring LL addresses goes. So it can't be "disabled" as such. I think this >>> wants to say that it MUST be possible to configure RA/PIOs with A=0. >> >> Or configure no RAs at all. LL address generation is *not* dependent >> on RA (but *does* depend on NS/NA/DAD). >> >> It is perfectly possible to run IPv6 routing without RA (even if you >> don't normally want to do that). Check your nearest Juniper router >> if you doubt this is possible. > > Where does the default router address come from, then? > And potentially many other things: "IPv6 RAs Mostly Necessary" https://www.slideshare.net/MarkSmith214/ipv6-ras-mostly-necessary > Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Aug 3 00:30: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 96B49131687 for ; Thu, 3 Aug 2017 00:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S80ERw0cQFQA for ; Thu, 3 Aug 2017 00:30:51 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA213131D24 for ; Thu, 3 Aug 2017 00:30:51 -0700 (PDT) X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 33D4D429FE for ; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1B226429F8; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 17AD935C43; Thu, 3 Aug 2017 09:30:49 +0200 (CEST) Date: Thu, 3 Aug 2017 09:30:49 +0200 From: Gert Doering To: Brian E Carpenter Cc: sthaug@nethelp.no, v6ops@ietf.org, ipv6@ietf.org, draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Subject: Re: [v6ops] Turning on IPv6 Routers Message-ID: <20170803073048.GJ45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:30:53 -0000 Hi, On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: > > It is perfectly possible to run IPv6 routing without RA (even if you > > don't normally want to do that). Check your nearest Juniper router > > if you doubt this is possible. > > Where does the default router address come from, then? On the router? "OSPF, BGP, ..." On the host? "static route pointing to fe80::1%eth0" (which is the VRRP address of your upstream router pair) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Aug 3 01:03:12 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA506126CB6; Thu, 3 Aug 2017 01:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lNS7ibZgsnS; Thu, 3 Aug 2017 01:03:04 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF47C124234; Thu, 3 Aug 2017 01:03:03 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id q25so2824680uah.1; Thu, 03 Aug 2017 01:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Zldfp3GMYwHwmLnr03bcAbdzDF8f6y+4b2rNyTSrNc=; b=tOZJdvbb3L0XGO3E+e19L8NfmP7CS/fqyEkBjshFFiWzShwHh+DcXleTaPIV72m2nB yYP9f3RQdqVA43ZdTy5vsEB35Ihei6AkyhckjqwYeQpB7y+dGLMxErmqM7xd7YjgjrAU o1w1uJHjcFINjNptkKFzmSKH/TNmqvYpXMOXUkItwJNpfHbRxr/T54Q78yfJbfkmyrUX 2hMJ0Cz/IMgU7KvUJLkdR1mntHUDefJlS/1pa0fsnAn7CyqYpI95aFfdbArl1fJ8vg0o V0AS9eoZ+Uo7qoop5wFZMSMsdndABB1Hg6oMcnqyfROSIM9mq/wDRKSmnLZYd6ahHQJz qUDQ== 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=/Zldfp3GMYwHwmLnr03bcAbdzDF8f6y+4b2rNyTSrNc=; b=HeCSntLNgKEhVvLmExqwTR7kPaysc0cEyU0I0Zz3XK4MJf+9uvVZbBKZF3KWAX1jvm NwyDQBfWNeRzweJCrLs4Ks8dmnOPJ6FDbv9mbeslWErfe4gqyjId0tPuVE0TrqwRpHac bTOmYYa/bW6yGFG9qamOtptk7tMPJx/QRmK1pDC2fRgSxDqk4WvuhhaAl/ucPd5vbt6d yTfkM7aXqnusvdIyjg9Uk2rIzjr6lt/xYRTKIDngZUSUSRhkaBpAQAIqUVhft7QaOEr8 V2BVcni7lKa4g+MZWiCeU6pefrD1eew9z26yBkkszU2WVmHmBECBpXXQpisa52M1rcAY uPtA== X-Gm-Message-State: AIVw1126T/SZrkBOvytfLMWf4xETxgY5yMsbwJmpeGt0WdbzDFanmpvS fKd0cmhyycNXJ5j7P+4VL2tBnzw9Wg== X-Received: by 10.176.86.87 with SMTP id z23mr564915uaa.170.1501747383119; Thu, 03 Aug 2017 01:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 01:02:32 -0700 (PDT) In-Reply-To: <20170803073048.GJ45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> From: Mark Smith Date: Thu, 3 Aug 2017 18:02:32 +1000 Message-ID: Subject: Re: [v6ops] Turning on IPv6 Routers To: Gert Doering Cc: Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:03:10 -0000 On 3 August 2017 at 17:30, Gert Doering wrote: > Hi, > > On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: >> > It is perfectly possible to run IPv6 routing without RA (even if you >> > don't normally want to do that). Check your nearest Juniper router >> > if you doubt this is possible. >> >> Where does the default router address come from, then? > > On the router? "OSPF, BGP, ..." > > On the host? "static route pointing to fe80::1%eth0" (which is the VRRP > address of your upstream router pair) > I suppose there should also be a knob to turn neighbor resolution off too, so that people can exclusively use statically configured ND cache entries in routers. Regards, Mark. From nobody Thu Aug 3 01:12: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 A0F87126CB6 for ; Thu, 3 Aug 2017 01:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv_eqKOZ5AGS for ; Thu, 3 Aug 2017 01:12:01 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55DA13232B for ; Thu, 3 Aug 2017 01:11:59 -0700 (PDT) X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A016C429FF for ; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8AC45429FC; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8704935DFC; Thu, 3 Aug 2017 10:11:57 +0200 (CEST) Date: Thu, 3 Aug 2017 10:11:57 +0200 From: Gert Doering To: Mark Smith Cc: Gert Doering , Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Subject: Re: [v6ops] Turning on IPv6 Routers Message-ID: <20170803081157.GP45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJT2ufQLhymvxlcq" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:12:03 -0000 --IJT2ufQLhymvxlcq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 03, 2017 at 06:02:32PM +1000, Mark Smith wrote: > >> > It is perfectly possible to run IPv6 routing without RA (even if you > >> > don't normally want to do that). Check your nearest Juniper router > >> > if you doubt this is possible. > >> > >> Where does the default router address come from, then? > > > > On the router? "OSPF, BGP, ..." > > > > On the host? "static route pointing to fe80::1%eth0" (which is the VR= RP > > address of your upstream router pair) >=20 > I suppose there should also be a knob to turn neighbor resolution off > too, so that people can exclusively use statically configured ND cache > entries in routers. That's a different bag of worms, but indeed, a knob to replace NS/NA with something reasonable would be good. "Static ND cache" is not an exactly common request, though - but in a fully pre-defined scenario (think=20 industrial ethernet which already does away with MAC learning), this has benefits. Seriously: RAs for default router announcement work nicely for certain use cases, and are just not good enough for others, like "fast and=20 well-defined failover among multiple default gateways". But do not let me stop you from ridiculing other people's use cases - this is part of what has made IPv6 such a tremendous success, so by all means, give us more of it. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --IJT2ufQLhymvxlcq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmC2soACgkQ31bAZeTO f8XeGw//fztavJvLbBM1F341vD/7eYw1418oLqr+yV/408jGdzWR+0TWM9c4agZ3 j2xxZWT211SrGSxalF3KiFs5PLl3CmqJn8PGNG5GNbe9yF2JGuzm/ghgCeG3SfIi Ig2IjGONlBF+e2IUoM6o8KXGsUexY3bNDNqlO/goyv9hbpkYAwSC6L8QSJEu3zPA g1TJSXu5qHQLMxn09Fwh7Hha5Oezk73chc/nErSlnsoagX04PqO0XcAsr+VxBBqL D4Avk4oORY3QahKEvDNzJCgGo7LalKMxZmZMIm7ghO4mPPceONtYgqGHBDwRAm3J ZIS1J8TCQ97xnL3L0WqG1hTHpaQVMnfiHXB3nHY/ghATum4XcO+Z93R/t1fQjv6r uSBaw8Zf2OVqS+2//nLYYhRGJwjVwYaGcOjpUd4VIK1b9livSsmPOOZLn7p4Ps9g axeYEIddi4LIJmAafPYUZ/Zf9fnDgYK1Zljzw42ZlfmNXiSogvxXS7LXnRs3zwGx TvA3VA4DdqUPJQlC8W2CN7fvwkB/og9gXZ0d0KuxIUxKA+TyvL59P1vgu1kmW7Pz H+5vCDx5OYAVfglnISeMoCjdPoRo/yVPPd4+AeEkFhq7LHLOJfgUEaFfstQfu8gx l/Q7Sq+tHOh+22g7EncVC4ypaWbiwc6UQUEoAvuC4u4C2KmknXg= =Orm1 -----END PGP SIGNATURE----- --IJT2ufQLhymvxlcq-- From nobody Thu Aug 3 02:32: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 B145E128C81; Thu, 3 Aug 2017 02:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtLl8JFhznNp; Thu, 3 Aug 2017 02:32:39 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27216126CC4; Thu, 3 Aug 2017 02:32:39 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id q25so3636771uah.1; Thu, 03 Aug 2017 02:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o0FK8XoKFvwtp+bfdxsVr57CTPlRfkgoVxTzPIZOv6g=; b=eJOT4T8AMa4ceeUReZONuPiUYeT+nOogT6dI8b1YzuVdY3TiFlUJNwFTT94ooq7hnr yW3NIAyBb8z7BF2Hq4audqOSlgzP5pgGVazNZSV8lItIInPa1A7K/fAvVF0vaRD0DKKX EdrNBh7t+z0pdBhi38gMjyptDHrtap9kTOFlKECL8JyXs9hqwd8bcUDQQKOqvRUnNvQr F/PqH6mhsRtkSBCQJZSjgH/Nmt+hArvhEHZ0toYnZFhMnOH8M4tOP3Yr2Xwco9o8/XC3 k5LPGdLr94Wa/sAXp8p7l6Y8Jk3G/NB2A879QPkvIrca9SyAG833u9Q2nbt3A4jrI9Jd oYXw== 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=o0FK8XoKFvwtp+bfdxsVr57CTPlRfkgoVxTzPIZOv6g=; b=Qn2OvCCd3sQ3Jj7Y8XKTtdtGi/6sOMIE95yj5PtBQadzouEIRumN3X00vQOKQ1d/mO 2zAIaKGNwa18zUbyvygt058SraKLJqfeGOeoPLBPkxHVFbFLrhUZFv8zCRsvhXwwZQLE UNJZ3DvIOaExNittxBvHFqO9kMVMzrYtDLzx1zYyi4rnDOpj5fwY+/PVnGYkMyTGSt3N LeEPZQV3zOGbbJoroI2H6gWijuhEYZ+HrcRqONaBrWQwmV628LCIN0betzmVLTzchb1f OZZD+pRzFH3vm1h+AxOove9dZGIsDrS+OiOBphNyjR9rassV3Sw1W5KEj2lGrclY3386 I2RA== X-Gm-Message-State: AIVw111v9WjO3KpUMaVM0SQgNbjb00ZqCjhiavdTx1bYTphFNSGMrSqk 5YyBXHVvtAqj3Nc2+wV6ngzj74JHIw== X-Received: by 10.159.52.79 with SMTP id s15mr725421uab.157.1501752758169; Thu, 03 Aug 2017 02:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Thu, 3 Aug 2017 02:32:07 -0700 (PDT) In-Reply-To: <20170803081157.GP45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> <20170803081157.GP45648@Space.Net> From: Mark Smith Date: Thu, 3 Aug 2017 19:32:07 +1000 Message-ID: Subject: Re: [v6ops] Turning on IPv6 Routers To: Gert Doering Cc: Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 09:32:41 -0000 On 3 August 2017 at 18:11, Gert Doering wrote: > Hi, > > On Thu, Aug 03, 2017 at 06:02:32PM +1000, Mark Smith wrote: >> >> > It is perfectly possible to run IPv6 routing without RA (even if you >> >> > don't normally want to do that). Check your nearest Juniper router >> >> > if you doubt this is possible. >> >> >> >> Where does the default router address come from, then? >> > >> > On the router? "OSPF, BGP, ..." >> > >> > On the host? "static route pointing to fe80::1%eth0" (which is the VRRP >> > address of your upstream router pair) >> >> I suppose there should also be a knob to turn neighbor resolution off >> too, so that people can exclusively use statically configured ND cache >> entries in routers. > > That's a different bag of worms, but indeed, a knob to replace NS/NA with > something reasonable would be good. "Static ND cache" is not an exactly > common request, though - but in a fully pre-defined scenario (think > industrial ethernet which already does away with MAC learning), this > has benefits. > It would be an alternative method of mitigating ND cache attacks, which are exploiting dynamic ND cache entry creation. > > Seriously: RAs for default router announcement work nicely for certain > use cases, and are just not good enough for others, like "fast and > well-defined failover among multiple default gateways". > That's what VRRP, HSRP or GLBP are for. VRRP supporting IPv6 was specified in 2010 in RFC5798, and a search shows that Cisco have supported IPv6 in HSRP and GLBP since 2011. RAs plus NUD is going to be a poor mans or better than nothing VRRP. There was no such equivalent functionality in base IPv4. The out of the box IPv6 functionality is not better than VRRP/HSPR/GLBP, however it is better than IPv4's. > But do not let me stop you from ridiculing other people's use cases I usually understand the use cases, however I don't understand why the methods used in IPv6 must be the IPv4 methods, even though IPv6 methods exist and are deployed and are working for many people. People usually don't actually describe why the existing and widely deployed IPv6 methods cannot be used. They just assert it must be the way IPv4 worked. It's understandable because of familiarity, however things can't be improved without things being changed. Sometimes they also assert what they're objecting to is "religion". Asserting it is "religion" is implying that there was no objective or rational reasoning behind the decision (there always is), which is really just resorting to an ad hominem attack on the person they disagree with and also those who made those design and protocol decisions. Things should always be objectively evaluated here. I think blindly carrying over IPv4's practices and methods to IPv6 is closer to religion than anything that appears in IPv6 - it is saying "even though the situation and requirements have changed, we believe the old ways are and will always be the best ways". I think that is a very subjective approach. > - this > is part of what has made IPv6 such a tremendous success, so by all means, > give us more of it. > The best way to prove the IPv6 methods don't work is to deploy the IPv6 methods as they stand. If they fail, document the environment they failed in and how. Come back with that evidence, which may provide a solid reason to change how IPv6 works in that specific regard. Regards, Mark. From nobody Thu Aug 3 05:25: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 78EEA131ECE for ; Thu, 3 Aug 2017 05:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg-Ln9Ba6p4q for ; Thu, 3 Aug 2017 05:24:58 -0700 (PDT) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.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 64318131EB8 for ; Thu, 3 Aug 2017 05:24:58 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id v73COtaj001383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Aug 2017 08:24:55 -0400 Received: (qmail 15798 invoked by uid 0); 3 Aug 2017 12:24:55 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 3 Aug 2017 12:24:55 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 03 Aug 2017 08:24:49 -0400 Subject: Re: [v6ops] Turning on IPv6 Routers From: Lee Howard To: Nick Hilliard , Fred Baker CC: IPv6 Ops WG , 6man WG , Message-ID: Thread-Topic: [v6ops] Turning on IPv6 Routers References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> In-Reply-To: <5970CB51.3090806@foobar.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:25:00 -0000 On 7/20/17, 5:25 PM, "v6ops on behalf of Nick Hilliard" wrote: >Fred Baker wrote: >> "If IPv4 router operation is enabled by default, enable IPv6 router >> operation by default." > >this is undoubtedly well-intentioned, and the idealist bit in me >sympathises with the principal. However with my enable hat on, a >recommendation like this isn't going to fix any problem associated with >ipv6 adoption. I completely disagree, but it=E2=80=99s dependent on where the router exists. For a home gateway router, =E2=80=9CIPv6 on by default=E2=80=9D would increase the numb= er of people using IPv6, although I have no way to estimate the impact. For an enterprise edge router, =E2=80=9CIPv6 on by default=E2=80=9D might accidentally = get IPv6 deployed. There=E2=80=99s potential risk if =E2=80=9CIPv6 firewall on by default=E2=80= =9D isn=E2=80=99t also enabled, but this is mentioned in the Security Considerations section. In data centers and core networks, there isn=E2=80=99t a strong case either way, because those configurations should be tightly managed, and accidentally enabling IPv6 is unlikely to leak anywhere else. > >The problems with ipv6 adoption revolve entirely around cost/benefit. Well, yes, but not always in the way I think you mean it. Tens of millions of people use IPv6 daily without ever having done a cost-benefit analysis. >Pressing problems still include things that should have been resolved >years ago, e.g. vendors charging extra for ipv6 support (today's >bugbear: provisioning system vendors, please note that charging extra >for basic ipv6 functionality is destructive in the long term and >corrosive for your customer relationships) Yeah, that=E2=80=99s a bad vendor relationship, and a vendor doing that must be pretty confident that their customer otherwise loves their product and isn=E2=80=99t tempted to find an alternative vendor. > >As a separate issue, from an operational point of view, implicit >enabling of functionality in one area when it's explicitly enabled in >another is something that needs to be handled carefully because >otherwise you can end up violating the principal of least astonishment. Anyone astonished by IPv6 working needs to be astonished. Lee > >Nick > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Aug 3 06:07: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 7A389131F21 for ; Thu, 3 Aug 2017 06:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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=bcbsm.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 qtF4aFFuyQjQ for ; Thu, 3 Aug 2017 06:07:48 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 19630131F5C for ; Thu, 3 Aug 2017 06:07:43 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id A39E8C0E58 for ; Thu, 3 Aug 2017 08:07:42 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6AEDEC0D9A; Thu, 3 Aug 2017 08:07:41 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2F95692079; Thu, 3 Aug 2017 09:07:41 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EE1F692057; Thu, 3 Aug 2017 09:07:40 -0400 (EDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (unknown [207.46.163.87]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Thu, 3 Aug 2017 09:07:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=heBMdqaES+qxgi0D//ObzbVYAXhO2rtjypRdPNOAh9A=; b=mHcBX2IkQ4PtIONp8D8rehcQ8gXOIPOw9BcFkowPQQwmBmm2REmQID3TN86d1q/GE3mrO26v9QdaUScbBpoWVwc9ymx5D++kga1H9oRGpmaFAumiuxOQlSlt8vg6oC6ihx4Rhff+qos5bqgu0Bw3wq44mXc2l3cZMjaMKgcBmxM= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1366.namprd14.prod.outlook.com (10.172.158.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 13:07:39 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 13:07:39 +0000 From: "Ackermann, Michael" To: Lee Howard , Nick Hilliard , Fred Baker CC: IPv6 Ops WG , 6man WG , "draft-ietf-6man-rfc6434-bis@ietf.org" Subject: RE: [v6ops] Turning on IPv6 Routers Thread-Topic: [v6ops] Turning on IPv6 Routers Thread-Index: AQHTAWxnLK4tXfb/J0eDXgJbGwTvdaJypCaAgAALLVA= Date: Thu, 3 Aug 2017 13:07:39 +0000 Message-ID: References: <28757A47-53D8-459E-B76D-D5D5DE3D5897@gmail.com> <5970CB51.3090806@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR14MB1366; 20:RpApsfpfHToiR1aCMO32LTkRPXJqlgSnRvww6b1effWKiBwmai5qAYncYefn6RECvGbQeW/lCduBgZJr5kTYeyXVfRxclT5Sf81PN/stwKEQcrcYdeWRumhHB8SQbMAa9K2Dtq3bf22bQrJ7m0KdUHqjD5yFh3zWy8diLRiMjTI= x-ms-office365-filtering-correlation-id: c4d62c0e-c021-4711-ce97-08d4da709e99 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1366; x-ms-traffictypediagnostic: CY4PR14MB1366: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1366; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1366; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39830400002)(39400400002)(24454002)(189002)(377454003)(13464003)(199003)(4326008)(80792005)(25786009)(8676002)(101416001)(33656002)(478600001)(77096006)(189998001)(6436002)(229853002)(72206003)(86362001)(305945005)(97736004)(7736002)(2900100001)(6506006)(966005)(55016002)(38730400002)(6246003)(2950100002)(6116002)(102836003)(53546010)(3846002)(66066001)(106356001)(7696004)(2906002)(5660300001)(3660700001)(3280700002)(39060400002)(9686003)(74316002)(105586002)(6306002)(68736007)(53936002)(14454004)(54906002)(50986999)(8936002)(54356999)(99286003)(81156014)(81166006)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1366; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 13:07:39.6013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1366 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 4f985c0c-8936-4bd8-bf23-0e377d80b178 X-VPM-MSG-ID: 95429e47-ba06-47f4-bb07-8804d6c67bb1 X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 13:07:49 -0000 SnVzdCBhIHF1aWNrIDIgY2VudHMgZnJvbSB0aGUgRW50ZXJwcmlzZSBwZXJzcGVjdGl2ZS4g DQoNClVuZm9ydHVuYXRlbHkgKElNSE8pLCAgbW9zdCBFbnRlcnByaXNlcyBleHByZXNzbHkg YW5kIHB1cnBvc2VseSB0dXJuIElQdjYgb2ZmIGluIHJvdXRlcnMuICAgICBBcyBtZW50aW9u ZWQsICB0aGUgYnVzaW5lc3MgY2FzZShzKSBhcmUgc3RpbGwgbm90IG9idmlvdXMgYW5kIGl0 IGlzIHRodXMgc2VlbiBvbmx5IGFzIGV4Y2Vzc2l2ZSB0cmFmZmljIGFuZCBwb3RlbnRpYWwg cHJvYmxlbXMuICANCg0KUGxlYXNlIGRvbid0IHNob290IHRoZSBtZXNzZW5nZXIuICANCg0K VGhhbmtzDQoNCk1pa2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVl IEhvd2FyZA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzLCAyMDE3IDg6MjUgQU0NClRvOiBO aWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc+OyBGcmVkIEJha2VyIDxmcmVkYmFrZXIu aWV0ZkBnbWFpbC5jb20+DQpDYzogSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgNm1h biBXRyA8aXB2NkBpZXRmLm9yZz47IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gVHVybmluZyBvbiBJUHY2IFJvdXRlcnMNCg0K DQoNCk9uIDcvMjAvMTcsIDU6MjUgUE0sICJ2Nm9wcyBvbiBiZWhhbGYgb2YgTmljayBIaWxs aWFyZCINCjx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNrQGZvb2Jh ci5vcmc+IHdyb3RlOg0KDQo+RnJlZCBCYWtlciB3cm90ZToNCj4+ICJJZiBJUHY0IHJvdXRl ciBvcGVyYXRpb24gaXMgZW5hYmxlZCBieSBkZWZhdWx0LCBlbmFibGUgSVB2NiByb3V0ZXIg DQo+PiBvcGVyYXRpb24gYnkgZGVmYXVsdC4iDQo+DQo+dGhpcyBpcyB1bmRvdWJ0ZWRseSB3 ZWxsLWludGVudGlvbmVkLCBhbmQgdGhlIGlkZWFsaXN0IGJpdCBpbiBtZSANCj5zeW1wYXRo aXNlcyB3aXRoIHRoZSBwcmluY2lwYWwuICBIb3dldmVyIHdpdGggbXkgZW5hYmxlIGhhdCBv biwgYSANCj5yZWNvbW1lbmRhdGlvbiBsaWtlIHRoaXMgaXNuJ3QgZ29pbmcgdG8gZml4IGFu eSBwcm9ibGVtIGFzc29jaWF0ZWQgd2l0aA0KPmlwdjYgYWRvcHRpb24uDQoNCkkgY29tcGxl dGVseSBkaXNhZ3JlZSwgYnV0IGl04oCZcyBkZXBlbmRlbnQgb24gd2hlcmUgdGhlIHJvdXRl ciBleGlzdHMuDQpGb3IgYSBob21lIGdhdGV3YXkgcm91dGVyLCDigJxJUHY2IG9uIGJ5IGRl ZmF1bHTigJ0gd291bGQgaW5jcmVhc2UgdGhlIG51bWJlciBvZiBwZW9wbGUgdXNpbmcgSVB2 NiwgYWx0aG91Z2ggSSBoYXZlIG5vIHdheSB0byBlc3RpbWF0ZSB0aGUgaW1wYWN0Lg0KDQpG b3IgYW4gZW50ZXJwcmlzZSBlZGdlIHJvdXRlciwg4oCcSVB2NiBvbiBieSBkZWZhdWx04oCd IG1pZ2h0IGFjY2lkZW50YWxseSBnZXQNCklQdjYgZGVwbG95ZWQuIFRoZXJl4oCZcyBwb3Rl bnRpYWwgcmlzayBpZiDigJxJUHY2IGZpcmV3YWxsIG9uIGJ5IGRlZmF1bHTigJ0NCmlzbuKA mXQgYWxzbyBlbmFibGVkLCBidXQgdGhpcyBpcyBtZW50aW9uZWQgaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCkluIGRhdGEgY2VudGVycyBhbmQgY29yZSBu ZXR3b3JrcywgdGhlcmUgaXNu4oCZdCBhIHN0cm9uZyBjYXNlIGVpdGhlciB3YXksIGJlY2F1 c2UgdGhvc2UgY29uZmlndXJhdGlvbnMgc2hvdWxkIGJlIHRpZ2h0bHkgbWFuYWdlZCwgYW5k IGFjY2lkZW50YWxseSBlbmFibGluZyBJUHY2IGlzIHVubGlrZWx5IHRvIGxlYWsgYW55d2hl cmUgZWxzZS4NCg0KPg0KPlRoZSBwcm9ibGVtcyB3aXRoIGlwdjYgYWRvcHRpb24gcmV2b2x2 ZSBlbnRpcmVseSBhcm91bmQgY29zdC9iZW5lZml0Lg0KDQpXZWxsLCB5ZXMsIGJ1dCBub3Qg YWx3YXlzIGluIHRoZSB3YXkgSSB0aGluayB5b3UgbWVhbiBpdC4NClRlbnMgb2YgbWlsbGlv bnMgb2YgcGVvcGxlIHVzZSBJUHY2IGRhaWx5IHdpdGhvdXQgZXZlciBoYXZpbmcgZG9uZSBh IGNvc3QtYmVuZWZpdCBhbmFseXNpcy4NCg0KPlByZXNzaW5nIHByb2JsZW1zIHN0aWxsIGlu Y2x1ZGUgdGhpbmdzIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiByZXNvbHZlZCANCj55ZWFycyBh Z28sIGUuZy4gdmVuZG9ycyBjaGFyZ2luZyBleHRyYSBmb3IgaXB2NiBzdXBwb3J0ICh0b2Rh eSdzDQo+YnVnYmVhcjogcHJvdmlzaW9uaW5nIHN5c3RlbSB2ZW5kb3JzLCBwbGVhc2Ugbm90 ZSB0aGF0IGNoYXJnaW5nIGV4dHJhIA0KPmZvciBiYXNpYyBpcHY2IGZ1bmN0aW9uYWxpdHkg aXMgZGVzdHJ1Y3RpdmUgaW4gdGhlIGxvbmcgdGVybSBhbmQgDQo+Y29ycm9zaXZlIGZvciB5 b3VyIGN1c3RvbWVyIHJlbGF0aW9uc2hpcHMpDQoNClllYWgsIHRoYXTigJlzIGEgYmFkIHZl bmRvciByZWxhdGlvbnNoaXAsIGFuZCBhIHZlbmRvciBkb2luZyB0aGF0IG11c3QgYmUgcHJl dHR5IGNvbmZpZGVudCB0aGF0IHRoZWlyIGN1c3RvbWVyIG90aGVyd2lzZSBsb3ZlcyB0aGVp ciBwcm9kdWN0IGFuZCBpc27igJl0IHRlbXB0ZWQgdG8gZmluZCBhbiBhbHRlcm5hdGl2ZSB2 ZW5kb3IuDQoNCj4NCj5BcyBhIHNlcGFyYXRlIGlzc3VlLCBmcm9tIGFuIG9wZXJhdGlvbmFs IHBvaW50IG9mIHZpZXcsIGltcGxpY2l0IA0KPmVuYWJsaW5nIG9mIGZ1bmN0aW9uYWxpdHkg aW4gb25lIGFyZWEgd2hlbiBpdCdzIGV4cGxpY2l0bHkgZW5hYmxlZCBpbiANCj5hbm90aGVy IGlzIHNvbWV0aGluZyB0aGF0IG5lZWRzIHRvIGJlIGhhbmRsZWQgY2FyZWZ1bGx5IGJlY2F1 c2UgDQo+b3RoZXJ3aXNlIHlvdSBjYW4gZW5kIHVwIHZpb2xhdGluZyB0aGUgcHJpbmNpcGFs IG9mIGxlYXN0IGFzdG9uaXNobWVudC4NCg0KQW55b25lIGFzdG9uaXNoZWQgYnkgSVB2NiB3 b3JraW5nIG5lZWRzIHRvIGJlIGFzdG9uaXNoZWQuDQoNCkxlZQ0KDQoNCj4NCj5OaWNrDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52 Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnDQpBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCgpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBoaWdobHkgY29uZmlkZW50aWFsIGFuZCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgdG8gd2hv bSB0aGlzIGNvbW11bmljYXRpb24gaXMgZGlyZWN0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHZp ZXdpbmcsIGNvcHlpbmcsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIG9mIHRoaXMgaW5m b3JtYXRpb24gaXMgcHJvaGliaXRlZC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyLCBieSBl bGVjdHJvbmljIG1haWwgb3IgdGVsZXBob25lLCBvZiBhbnkgdW5pbnRlbmRlZCByZWNlaXB0 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugd2l0aG91dCBtYWtpbmcgYW55IGNv cGllcy4KIAogQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBvZiBNaWNoaWdhbiBhbmQgQmx1ZSBD YXJlIE5ldHdvcmsgb2YgTWljaGlnYW4gYXJlIG5vbnByb2ZpdCBjb3Jwb3JhdGlvbnMgYW5k IGluZGVwZW5kZW50IGxpY2Vuc2VlcyBvZiB0aGUgQmx1ZSBDcm9zcyBhbmQgQmx1ZSBTaGll bGQgQXNzb2NpYXRpb24uCg== From nobody Thu Aug 3 11: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 1997812DDD0 for ; Thu, 3 Aug 2017 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQzpivpFhoYP for ; Thu, 3 Aug 2017 11:09:45 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B445131C23 for ; Thu, 3 Aug 2017 11:09:45 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id z18so12160046qka.4 for ; Thu, 03 Aug 2017 11:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bzuOUcYF77t49BQCGVrNT0AtnWH8uDnEUKhDWhruznY=; b=lQ525KN5uDOVIqJ5WgsGE08uEX7Men0CEqClEX7bKuLQezKY3TWZIngCuzpFNI+K8J nS7f84NlHd4jX96wrLxZNG1pxRSYtIrrFcPpEkf/BHQ9ZQUG28eow2Usk3eppMsTSvPn kOUIQzIVpn+BhbAzroDcM9hkZcSnbqGujOnhlFT9n1NAdO8HG13EDY80014VtZpIHvEi xAFakTAVGTtOg3ghTpPHOuaKc3opBLFr0m/M5aWggn2ptngK87ePxHC/AuHzhTsq+R7s 8vC3TKAHFc5jQLsDFzx5ZVVZnXuYiWfekBVvbjxjTsr9r4m6tOMKgyUh0uYDamyENRYw acDg== 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=bzuOUcYF77t49BQCGVrNT0AtnWH8uDnEUKhDWhruznY=; b=lGZKJX63pnuac2tM9v5BxogvQQYld2uIdCp1WdtjlZ+1SyCC2W8GKSSK43rVeX6TvA OTQqQ39HTptNNnIapQaPXRTDZYU3QinM6GtPxojOCvFZHXARIu4y8mpwkP/zEeNoJ/rN cAI/sJGkG64Pe4Urpwg4WCSqFb7A+rOGO/9/Q6jRlIVbbu/0qnTMXAkbqxKGSp0MayQ9 p+hJGSX2DDrLIsNPdc1XC9VyUGx9HITgE3xa7wsJjCmjXBJI0t4fKYZ8kvb7mYEcCih2 LiGcN1Fdg4Iulo5jip/4kawSvD2E1MMhPjw0L1FiGJLuSQvf1bo6m6Ql5yf41vMYYsL2 6pWQ== X-Gm-Message-State: AHYfb5ieJUaEOySrTOGK/nS87BFx9VxRhjluFZzmkdg/rAok95H20yLO Z+oDoQgeHqq8TUwJ/2C/qQhdBa3gzuu26h0= X-Received: by 10.55.19.152 with SMTP id 24mr3433500qkt.78.1501783784226; Thu, 03 Aug 2017 11:09:44 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Thu, 3 Aug 2017 11:09:43 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 3 Aug 2017 11:09:43 -0700 X-Google-Sender-Auth: NIm4ElkYdBHlj5l6mHy8XJ5ysiY Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Mark Smith Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 18:09:47 -0000 At Wed, 2 Aug 2017 14:42:18 +1000, Mark Smith wrote: >> For simplicity let's focus on SLAAC for address configuration and >> RA-based on-link determination. Then, do you mean you don't >> understand how these two can be different? >> - a prefix advertised in an RA PIO with the A flag on, for SLAAC >> - a prefix advertised in an RA PIO with the L flag on, for on-link >> determination [...] > No, completely understand that e.g. > > https://www.slideshare.net/mobile/MarkSmith214/ipv6-ras-mostly-necessary > > I'm pretty confident of my understanding of all of these things. That's why > I don't understand the need for any new terminology or concepts. The need > is not obvious to me, which is why I need more stated and explained context > and description of the problem and confusion. > > The problem may be that some of the concepts aren't as clear to others. I > think that would argue for more clarity and explanation, perhaps in another > ID. I think creating new terms and concepts may create more confusion > rather than eliminating it. Okay, now I see what you mean, but I'm afraid your original message didn't read that way. Personally, I think it makes sense to introduce a new term, since when there's a confusion naming things appropriately is a good first step to clarify it. But I wouldn't be surprised if some others don't see the need for it. Whether a particular term (like "on-link prefix") is good choice or whether introducing a new term is a good way forward for rfc4291bis is a different question. -- JINMEI, Tatuya From nobody Thu Aug 3 13:23: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 632E0131BBF; Thu, 3 Aug 2017 13:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVYzjSTo49aP; Thu, 3 Aug 2017 13:23:25 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8153B1317C1; Thu, 3 Aug 2017 13:23:25 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id y129so10383811pgy.4; Thu, 03 Aug 2017 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qod4kIY0Y+Ys43MyLsz64IubOf6m5jZLHcWdAo8mYSQ=; b=I/SQE/5K7ef1Zqr89K8+FpMRqFGp5I5Qx8RHA7JDi3s6ANso+C1vtx7OXFp6QCAWVs kjplIGQMEHYNQWtlOdHmRBs0P2t6chj4Grxk9he/Vb6eqNdNE8JCmVQ6iXMC2OuuWh5q Eh4y7YjPArm6XXBOHeYGFTIfJaWUmg6gaJr9c7qiWlcpieJbx41mwZ6PeE06/W49ibNw SBFUmM2qC3jJXGhwfSuw/2rnMEnx2CYoBKqAIHpsFU0aalNMm7hQiwHNzxgt4JiXwFss Q7WPmmCmg58LUlcGy54gm0m4IIoF3aTQ0/ShEb55b40e1bFanTHn0AtPFpeh8QX6qdt2 fxDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qod4kIY0Y+Ys43MyLsz64IubOf6m5jZLHcWdAo8mYSQ=; b=YUexYp9xekecYouqYbcKwQshPDlW14ZxlqjMbldsjMLFygMjskeUIgun42AHzX/a8z MhuOyX/rvUw7L1fdW2Kowi+0WYb29ZvtjiLARC6gXKTn/rw+7hPfb0RDfxequt2VPC1j 7neqmkmBCg6fFz+RJr6fzkVRFnFB4OuNu5rnSPctFbd3B+1upu2biUtq1dzaSnECDS2a j1pw1LbwzH0Uu71X/qlhcHji3VLVbBCYo8M0/LpCrlTHbBbJI5CumiScTFuKIoiSCm2g +VBGV6+eaRwvHCR7+x2KelG8hJec7xpTr8WFxthr+mNZ3W34Wv/KCisXjBuWQOjCAR5Q 4e/A== X-Gm-Message-State: AIVw113GJyxWQbzCxGr/0E+22AX2LV1kypPvuLZbgdHjn3GslOWjSRVs 6/Lo4QCCF5RIGpxv X-Received: by 10.84.233.195 with SMTP id m3mr50037pln.292.1501791804807; Thu, 03 Aug 2017 13:23:24 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z189sm56208003pgb.12.2017.08.03.13.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 13:23:24 -0700 (PDT) Subject: Re: [v6ops] Turning on IPv6 Routers To: Mark Smith , Gert Doering Cc: v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <652bfd39-82f5-8737-9feb-dd79a55f37c1@gmail.com> Date: Fri, 4 Aug 2017 08:23:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 20:23:28 -0000 On 03/08/2017 20:02, Mark Smith wrote: > On 3 August 2017 at 17:30, Gert Doering wrote: >> Hi, >> >> On Thu, Aug 03, 2017 at 05:34:32PM +1200, Brian E Carpenter wrote: >>>> It is perfectly possible to run IPv6 routing without RA (even if you >>>> don't normally want to do that). Check your nearest Juniper router >>>> if you doubt this is possible. >>> >>> Where does the default router address come from, then? >> >> On the router? "OSPF, BGP, ..." >> >> On the host? "static route pointing to fe80::1%eth0" (which is the VRRP >> address of your upstream router pair) >> > > I suppose there should also be a knob to turn neighbor resolution off > too, so that people can exclusively use statically configured ND cache > entries in routers. Once you say "static" and "configured" you're outside the scope of default behaviour and automatic configuration. If that's in scope for the draft, fine, but it needs to be described much more explicitly than a throw-away line like "SLAAC MUST be able to be disabled by operators who prefer to use some other mechanism..." which is what I was commenting on. Remember that the section of the draft including that text is titled "Supporting Zero Touch Provisioning for Connected Devices". And (for example) VRRP isn't mentioned anywhere in the draft. (https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs in case anybody has lost track.) Brian From nobody Thu Aug 3 13:51: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 1F610131CA2 for ; Thu, 3 Aug 2017 13:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkyTZTEIU2jr for ; Thu, 3 Aug 2017 13:50:54 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7C2131CC6 for ; Thu, 3 Aug 2017 13:50:52 -0700 (PDT) X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3F5DF42A37 for ; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1F3B342A31; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1B63B6E62E; Thu, 3 Aug 2017 22:50:50 +0200 (CEST) Date: Thu, 3 Aug 2017 22:50:50 +0200 From: Gert Doering To: Mark Smith Cc: Gert Doering , Brian E Carpenter , v6ops list , 6man WG , draft-ietf-v6ops-ipv6rtr-reqs@ietf.org Subject: Re: [v6ops] Turning on IPv6 Routers Message-ID: <20170803205049.GD45648@Space.Net> References: <20170803.055631.74690322.sthaug@nethelp.no> <20170803073048.GJ45648@Space.Net> <20170803081157.GP45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="K+aa9f6bMAfttVCD" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 20:50:55 -0000 --K+aa9f6bMAfttVCD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Aug 03, 2017 at 07:32:07PM +1000, Mark Smith wrote: > >> > On the host? "static route pointing to fe80::1%eth0" (which is the= VRRP > >> > address of your upstream router pair) [..] > > Seriously: RAs for default router announcement work nicely for certain > > use cases, and are just not good enough for others, like "fast and > > well-defined failover among multiple default gateways". >=20 > That's what VRRP, HSRP or GLBP are for. VRRP supporting IPv6 was > specified in 2010 in RFC5798, and a search shows that Cisco have > supported IPv6 in HSRP and GLBP since 2011. >=20 > RAs plus NUD is going to be a poor mans or better than nothing VRRP. > There was no such equivalent functionality in base IPv4. The out of > the box IPv6 functionality is not better than VRRP/HSPR/GLBP, however > it is better than IPv4's. Which is exactly what I've been saying as a possible reason why people are running without default-route-from-RA. =20 So it seems I am misunderstanding your point. [..] > > But do not let me stop you from ridiculing other people's use cases >=20 > I usually understand the use cases, however I don't understand why the > methods used in IPv6 must be the IPv4 methods, even though IPv6 > methods exist and are deployed and are working for many people. We do use the IPv6 method: HSRP with an IPv6 LLA (because that *is* "the IPv6 method", as on all but one platform Cisco's HSRP for IPv6 does not permit configuring a GUA as HSRP address, which would be "the IPv4 way"). We've done RA based failover, and it was far too slow and far too=20 non-deterministic ("honour router priorities? why?") to be satisfying. [..] > > is part of what has made IPv6 such a tremendous success, so by all mean= s, > > give us more of it. >=20 > The best way to prove the IPv6 methods don't work is to deploy the > IPv6 methods as they stand. If they fail, document the environment > they failed in and how. Come back with that evidence, which may > provide a solid reason to change how IPv6 works in that specific > regard. While I agree with you, this is just so slightly straying off the original question I've replied to... And yes, I've tried most of "the IPv6 ways" to get things done, and my dislike is growing. Like, how comes there is no remote ARP attack on=20 anything, but multiple router platforms are vulnerable to remote ND attacks... (not speaking of neighbor cache exhaustion, but of the incoming queue saturation by bogus packets coming from anywhere bug). Using ICMP with (among others) GUAs for IPv6 ND was a tremendously bad idea. First you open an attack surface for off-link attacks, and then you hope that implementations would be able to do hopcount=3D255 filtering= =20 early enough that you do not drown out legitimate packets in a rate- limited queue later on... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --K+aa9f6bMAfttVCD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlmDjKcACgkQ31bAZeTO f8Vy6Q//S/JifdSnY7Xhj+tUhAhS8FVzdrAbh7QAVAiHJeuwsXSn3w2JYmcx0QSW h1OPKIzebTSLskA1yfP8POz5G19Yebdkj91i89wDpKKy5Q8AWsYlbhxsUGMfhusf T5KQcneIunNFTYHy1ZH9sxJMcuZfeKeLV3x7FS312ZvsWAVzKSbXObwrebXra7vN mGSgT+FbJIm+nMwdb+30AQ1a1NfBZh7WTT1sU4U4qW1J+fl1CdoypOsYZwU3kzOR 6q4Dulfmc06W2qFbWY9/D6icexd3bDPgKYHnh7zPlZJJJMQR8WFK4kzErvshqFcb Py9pRPJk7IRuy3t731/vEmGXBd43auxGaMEkgzMcoe6DC7QtJZxu79Er8ILkkUKp SgtA7DqqH8E3KuCrtlEDL+nHulIdjpdclI2569minPpNmN8P+8hm96tPJNCjA3BF s231wjHdT/bfNmH6xfpW46vUwA2OMvdE2+OY7rB/JAEURJMtKedGrL8QOQufDyEA MLWrT2/oqruQ68VBGUCMSnhb0PzQjRhH1LLmRIMPg9na9yTgM2lFr8E36L9ooNgB de1wVQcp1aUHY4r1zPH9ukI0SETbUGXkHVu1QM3hqJJD4Nf4wpF89nnsOErS/TIN Ogy4zmk1pUWUnZLcm4yt4cHU6YDF+Kt8TZGKhPnmff5m3a7NBEs= =+eg7 -----END PGP SIGNATURE----- --K+aa9f6bMAfttVCD-- From nobody Thu Aug 3 19: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 C4ED9131CE2 for ; Thu, 3 Aug 2017 19:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 M43I1chTHvsT for ; Thu, 3 Aug 2017 19:27:27 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1634312EC51 for ; Thu, 3 Aug 2017 19:27:27 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id t86so2119685pfe.2 for ; Thu, 03 Aug 2017 19:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=gjt4gui+GtEgeeVSQnM8Glh7+Sq4S5V+LaDUCbT9fS0=; b=blup3NTlMjmugW8HljhD1pXuVn194LONzHRFJJ5qetndsZQng4oytZ/UWVgYFP39da vWlCyBl+AahFoEWicqyTrvTK9B0r0z8XxTm5E5C29wEn2JOC2HPxLtYFnonEjvC5Re4Z WZjW+Z3uTQbjbTY0ixT5O7bt/U/AAADNEkWChYFIPgRUjHzAee4x++X2RbpLcGBqITSE BpOA4o700wJ2mb7WZ1OYA0hFcAqVNJCXoTrEDbu1SDrNR31K+YWQWVmE2FFzLJAdtYJa 2Yys8Eobcpa5F1w+mmxT2n0G6C7IIXxTruTWlEreP6ybXarwexEvDExYs1k5gVyyeUk8 DE1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=gjt4gui+GtEgeeVSQnM8Glh7+Sq4S5V+LaDUCbT9fS0=; b=X9qqUfh9OLHCmznvXB2mZN4t0wIbaE9YPWs/LjdXlI3nSUC/Qr/E4ogpJQBFNT+/kd JejROrW+jXGMcmSuLYzW96NNIFnWLUHwyOGIpVx10gUlH+bg2uUgR2ylSh1O5W0WwE83 bwGi6tNhbwrUWmizcIoVBP9VQr6vAAEbkvY6+ZFQqTTz8Zphp1vhd8sgdGQ6i4uYM6As q4vR0DvGy9ibCM1HnFZ1tYyEIlr/LzTqzPJ6x3s/R7G02aGogH1587WBCi7JQcsjtlXW D0aM6gL3GgAIWH/XiBbNsGlv6iKPDXkNeDUKpih9t2/Frt+XCQGRci9lxxZAsE49Gnbd 099g== X-Gm-Message-State: AIVw1108TmmvPCTR1cGZDX7d7SIY7UE5B7MCg69vhSwELm5VpkPV+MJG Q8YLWaj1n2RofhD2j64= X-Received: by 10.98.59.90 with SMTP id i87mr842239pfa.300.1501813646400; Thu, 03 Aug 2017 19:27:26 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id o125sm427736pfg.32.2017.08.03.19.27.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 19:27:25 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Fri, 4 Aug 2017 11:27:23 +0900 References: <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> <20170725.080841.74682960.sthaug@nethelp.no> To: 6man WG In-Reply-To: <20170725.080841.74682960.sthaug@nethelp.no> Message-Id: <42090144-DCFB-478A-AB71-8B7AC53A0A63@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:27:28 -0000 As someone has already pointed out, the following text in the beginning = of page 10 seems to be incorrect: > | 128 bits | > +-----------------------------------------------------------------+ > | node address | > +-----------------------------------------------------------------+ I=E2=80=99d think =E2=80=98node address=E2=80=99 has to be changed to = =E2=80=98interface address=E2=80=99. --- DY From nobody Thu Aug 3 20:39:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CC0131CB5 for ; Thu, 3 Aug 2017 20:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 u5S5NJiNXpnt for ; Thu, 3 Aug 2017 20:39:13 -0700 (PDT) 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 5110C132014 for ; Thu, 3 Aug 2017 20:39:12 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 860CE74D for ; Fri, 4 Aug 2017 03:39:11 +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 n34_kNMkRROf for ; Thu, 3 Aug 2017 22:39:11 -0500 (CDT) 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-p7.oit.umn.edu (Postfix) with ESMTPS id 348D998 for ; Thu, 3 Aug 2017 22:39:11 -0500 (CDT) Received: by mail-ua0-f198.google.com with SMTP id c26so2301772uah.0 for ; Thu, 03 Aug 2017 20:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/mhE/R1bmugc6mV+YI9d2pfo0Au+xrjhDl5tXJ0XAOI=; b=qJwZU2iDml9KgWTB9f1AqXM3DM58HO600MBTGKq4j2+JcJ5XvaH7q3c8GEUMQPKy11 63LFnMc8Yk/vR3/ehdXKqcSPOlnuFGO+CK6OCs83koF+GWx+nqXbJGEO3QfRV37y9DDv Uhhu6UPuzrHpfulQhCWXswAwYXD+UV+L6wQXLGgtZQwaIbzf83upCo4mJWeuWpJW66PQ i/0zAOOMqC9XUyvSJ74wdXrzXTU8On1zWcHY9+DGUev7APKNbHUV1Q/JUEaYAVuBn62l vfFhwv8nWT2qweuHOLqnBCWHvfqJGLFXHq6MoWMsIIcWyvLfqCWTXQWKhSY2qITQNCRQ GPGQ== 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=/mhE/R1bmugc6mV+YI9d2pfo0Au+xrjhDl5tXJ0XAOI=; b=gUd4kONIUlhnb8Efe/S7x2+nZ6/HyXefUMxE9nImmLzkEKsPMUr7bNuyun1/nYxBgm 2M2fkMC4Z/vshYLA3RYuqXflXD1sHcG2+DaYR3B/Pti9xDn3m84iOu7mQml9OTLgo60K Vhloax63FVM1eQrOPrgRGisTR04aKa7JkEUhPM0UdFikM+/ETgabFs1UErxXwhrVBkAg egPO6zl9iCQbinMW7jByok7MqquUIsgP0VjMJK49o/oxTvw0jbJKH81RialQU+DU99/g sV+ETO93C8ORGKA+4QogssWcgW0DV1Mxo/yaLPFpE9hoBqe99bxyvG6QzuwWb+Em+zzS Hx9g== X-Gm-Message-State: AHYfb5glO7jWTI1tD04QGb++Uqrvhm6ngOrHWHWtsm39ZaqoTG/s9lTI p/F9hVvlVBwBmwBklVP3Ft47glwcvwLc8Tcq2A/Zmzwv/CEsw/Qu89F+kSO88oHdUL2o9q9ns8J twP6zHuz8S6Jh+Eo= X-Received: by 10.176.0.33 with SMTP id 30mr764374uai.29.1501817950591; Thu, 03 Aug 2017 20:39:10 -0700 (PDT) X-Received: by 10.176.0.33 with SMTP id 30mr764368uai.29.1501817950386; Thu, 03 Aug 2017 20:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Thu, 3 Aug 2017 20:39:09 -0700 (PDT) In-Reply-To: References: From: David Farmer Date: Thu, 3 Aug 2017 22:39:09 -0500 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Mark Smith Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Type: multipart/alternative; boundary="001a114506b47355230555e53dd7" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 03:39:17 -0000 --001a114506b47355230555e53dd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 1, 2017 at 11:42 PM, Mark Smith wrote: > > On 2 Aug. 2017 03:35, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: > > At Tue, 1 Aug 2017 16:10:16 +1000, > Mark Smith wrote: > > >> In my opinion the current text gives the false impression that there i= s > >> always a common prefix for address assignment and on-link > determination, or > >> the subnet prefix and the on-link prefix are the same, which they > >> frequently are, but are not require to be. > > > > This is confusing. What address generation and configuration method is > > being used? DHCPv6, SLAAC or manual configuration? > > > > I don't understand how the subnet prefix and the onlink (subnet) prefix > can > > be different. > > For simplicity let's focus on SLAAC for address configuration and > RA-based on-link determination. Then, do you mean you don't > understand how these two can be different? > - a prefix advertised in an RA PIO with the A flag on, for SLAAC > - a prefix advertised in an RA PIO with the L flag on, for on-link > determination > > > No, completely understand that e.g. > > https://www.slideshare.net/mobile/MarkSmith214/ipv6-ras-mostly-necessary > > I'm pretty confident of my understanding of all of these things. That's > why I don't understand the need for any new terminology or concepts. The > need is not obvious to me, which is why I need more stated and explained > context and description of the problem and confusion. > > The problem may be that some of the concepts aren't as clear to others. I > think that would argue for more clarity and explanation, perhaps in anoth= er > ID. I think creating new terms and concepts may create more confusion > rather than eliminating it. > So a question for you Mark, when RFC4291 says "subnet prefix", in your mind what PIO flags does this translate to? To me, since RFC 4291 also says that an IID must be 64 bits, I feel it must only be referring to a PIOs with the A flag set, because RFC4682 is clear that you need a PIO with a length of 64 bits and the A flag set to use SLAAC. However, both RFC4681 and RFC4682 are quite clear that a PIO with the L flag set can be any length. So if a subnet is fixed at 64 bits, then how can it be referring to PIOs with only the L flag set which can be any length, therefore PIOs with only the L flag set must be something separate from a subnet prefix as defined in RFC4291. Now if a subnet prefix can be any length and then it could be referring to a PIO with only the L flag set. However, then something needs to constrain IIDs to 64 bits, but only for SLAAC. In my opinion, we either need to talk about on-link prefixes or we need to change the constraints on the definition of a subnet in RFC4291bis so it fits PIOs with the A flag set or PIOs with only the L flag set. So I think something like this would work; IPv6 unicast routing and on-link determination are based on prefixes of any valid length up to 128 bits[BCP198]. However, 64 bit prefixes are recommended for both subnet assignment and on-link determination. and; 64 bit Interface Identifiers are required for Stateless Address Autoconfiguration (SLAAC)[RFC4862], except if the first three bits of the address are 000, otherwise 64 bit Interface Identifiers are recommended. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. A definition of subnet prefix and IID something like that leaves room for it to be referring to PIOs with the A flag set or PIOs only the L flag set, then the gory details can be left to RFC4681 and RFC4682. However a definition tightly constrained to 64 bits for subnet prefixes and IIDs means it can't be referring to PIOs with only the L flag set, and I believe they are architectural important, therefore something needs to describe them that is distinct from a subnet prefix, in my mind that would be an on-link prefix. So, if you think the details of on-link prefixes don't belong in RFC4291bis, I'm fine with that, then just relax the definition of a subnet prefix so that PIOs with only the L flag fit within the definition of a subnet prefix. 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 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-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 --001a114506b47355230555e53dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 1, 2017 at 11:42 PM, Mark Smith <markzzzsmith@gmail.c= om> wrote:

On 2 Aug. 2017 03:35, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89&q= uot; <jinmei@wide= .ad.jp> wrote:
At Tue, 1 Aug 2017 16:10:16 +1000,
Mark Smith <markzzzsmith@gmail.com> wrote:

>> In my opinion the current text gives the false impression that the= re is
>> always a common prefix for address assignment and on-link determin= ation, or
>> the subnet prefix and the on-link prefix are the same, which they<= br> >> frequently are, but are not require to be.
>
> This is confusing. What address generation and configuration method is=
> being used? DHCPv6, SLAAC or manual configuration?
>
> I don't understand how the subnet prefix and the onlink (subnet) p= refix can
> be different.

For simplicity let's focus on SLAAC for address configuration and=
RA-based on-link determination.=C2=A0 Then, do you mean you don't
understand how these two can be different?
- a prefix advertised in an RA PIO with the A flag on, for SLAAC
- a prefix advertised in an RA PIO with the L flag on, for on-link
=C2=A0 determination
No, completely understand that e.g.



=
The problem may be that some of the concepts aren't a= s clear to others. I think that would argue for more clarity and explanatio= n, perhaps in another ID. I think creating new terms and concepts may creat= e more confusion rather than eliminating it.
=

So a question for you Mark, when RFC42= 91 says "subnet prefix", in your mind what PIO flags does this tr= anslate to?

To me, since RFC 4291 also says that an IID must be 64 bits, I feel i= t must only be referring to a PIOs with the A flag set, because RFC4682 is = clear that you need a PIO with a length of 64 bits and the A flag set to us= e SLAAC.=C2=A0 However, both RFC4681 and RFC4682 are quite clear that a PIO= with the L flag set can be any length. So if a subnet is fixed at 64 bits,= then how can it be referring to PIOs with only the L flag set which can be= any length, therefore PIOs with only the L flag set must be something sepa= rate from a subnet prefix as defined in RFC4291. =C2=A0

Now if a subnet prefix ca= n be any length and then it could be referring to a PIO with only the L fla= g set.=C2=A0 However, then something needs to constrain IIDs to 64 bits, bu= t only for SLAAC. In my opinion, we either need to talk about on-link prefi= xes or we need to change the constraints on the definition of a subnet in R= FC4291bis so it fits PIOs with the A flag set or PIOs with only the L flag = set.

S= o I think something like this would work;
<= br>
of an= y valid length up to 128 bits[BCP198]. However,=C2=A064 bit prefixes
=



A d= efinition of subnet prefix and IID something like that leaves room for it t= o be referring to PIOs with the A flag set or PIOs only the L flag set, the= n the gory details can be left to RFC4681 and RFC4682.=C2=A0 However a defi= nition tightly constrained to 64 bits for subnet prefixes and IIDs means it= can't be referring to PIOs with only the L flag set, and I believe the= y are architectural important, therefore something needs to describe them t= hat is distinct from a subnet prefix, in my mind that would be an on-link p= refix.

So, if you think the details of on-link prefixes don't belong in RFC42= 91bis, I'm fine with that, then just relax the definition of a subnet p= refix so that PIOs with only the L flag fit within the definition of a subn= et prefix.=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
--001a114506b47355230555e53dd7-- From nobody Thu Aug 3 20:55: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 B4EDC12ECBD for ; Thu, 3 Aug 2017 20:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9vwbkEpnwqY for ; Thu, 3 Aug 2017 20:55:12 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 0F4C11315FF for ; Thu, 3 Aug 2017 20:55:12 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c28so2133431pfe.3 for ; Thu, 03 Aug 2017 20:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dy49URSrN/7cSb35CG/zs5OZRR/RQfL+VvBA/8/yNrQ=; b=Xnnyi0+HiqWEEDPnI9o5085oZCYbusTSNMRTHaGPxg3vvAs/MP9KjVCMX2F/Xb/ATM TTJmllwFMVDcX+KwvA8kgo/ySjyUOjv18muL6DeliOM6nmoBVhu8vr3a3E0cGniFlRAK eQUEWNvKakAgCt2TQv+Nf9pMVeBxtOhngfroy0Waa8I5rzJgnnNZDWGWHrAkSutSgbiI 4lUOGwg/N3y9Z0ti7Bn9I2xQeSVrQWdkNmMopx1aY1rCDN+oiz7yaK5cncngtn5Jcc05 gVsM/82DT2DfcgHMelJqbnmbpOGUoF3eYPimfmQ/HDxn9frVfCEZ6bt2suWB9+QCmgX0 e+Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Dy49URSrN/7cSb35CG/zs5OZRR/RQfL+VvBA/8/yNrQ=; b=KKr5a/vxERnJOhxdcdMA6I+hJZlwKHfdfOEUZ1NLGNj8seyNYRAXZE6KVXM7U8Dd9D Ssj9vDqgcjvSy70ojRYsxDamasaCifDR9OU2KH3MtXqDAvX9mDCFtAFkTTk2OCtH8T7a iR5WSQlRhths/w13c/O8TWmVtskOgVFts0zez898iscmWK+TJJr2lwE1GC8OboJseOhl dl97mWR/sfIl+N+jxPSlLtX0SML5vxnwo4KJt+RY6O75pjLc1C4vYD1DFvyOzzrRBxDG YSvyfXh9tblzQ2MlBLVx+CcOJmwsCoZB95Toc9cS+35AnGl3syWyuiLGMciiP40C/t35 OHvQ== X-Gm-Message-State: AIVw113ncaP8Cfqvv/81uDWTIiM7Tz/jnzCYzjag6uUL2dw9qYSkuA3l pF5AzxesKW2YNw== X-Received: by 10.84.195.131 with SMTP id j3mr1100437pld.147.1501818911652; Thu, 03 Aug 2017 20:55:11 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p10sm624556pfk.103.2017.08.03.20.55.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 20:55:11 -0700 (PDT) Subject: Re: Section 2.4 of rfc4291bis To: David Farmer , Mark Smith Cc: 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> Date: Fri, 4 Aug 2017 15:55:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 03:55:14 -0000 On 04/08/2017 15:39, David Farmer wrote: ... > because RFC4682 is clear > that you need a PIO with a length of 64 bits No it isn't. Quite the opposite; it's carefully written to avoid such a statement. Brian From nobody Thu Aug 3 21:18:38 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CEC131DAE for ; Thu, 3 Aug 2017 21:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4gJGgbmnPbGA for ; Thu, 3 Aug 2017 21:18:35 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDF612EAF7 for ; Thu, 3 Aug 2017 21:18:35 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 0FE02A0F for ; Fri, 4 Aug 2017 04:18:34 +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 efcoRC27Z-zA for ; Thu, 3 Aug 2017 23:18:33 -0500 (CDT) 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-p6.oit.umn.edu (Postfix) with ESMTPS id D54A5A05 for ; Thu, 3 Aug 2017 23:18:33 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id p138so2415376vkp.8 for ; Thu, 03 Aug 2017 21:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q9Pyz0JHmci5gG4AkZn9HRhZuGJaO+JT6DtB5EnvCQ8=; b=qFsS1D2lm7olBWUj0mxryQRw+vhdtAaxlBrFcfNxwmZ5qPHEm4CNoVJv/Jh0x9A90p gFSAEM3uoEZlAzvVDA7OHSHknszkpwL4lFr8566NdycIPL5ECl+FMxBGx8h1iqbq8lQF RPZxplbNvD1+HbG/D4EKD4gS/mXybQuVCKT7bKkwq00feZansvs/Wt03sJd8KLeokPvE Ew9OmVnjrgP0G6Y3mzZBcTxB/r6V+pleZ+oA5IlFEk/bxa4u+Zc9zcikVpyA3hwR33/I 9FCe1u5kpWoMz+E9iDW3Dk48WDWAMfDr0aqMxtUTEfLlDNU9HeHiqZ3UR9o45nmP+pwF FszQ== 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=q9Pyz0JHmci5gG4AkZn9HRhZuGJaO+JT6DtB5EnvCQ8=; b=Qt2y6z34zuXB9yYa2j8Y1MuODY5BCwYa+esm7tyV/gWYHbruNdKnvNv48yyZRm65xQ YrHagFQOYJ1im0CkdD8Vg6/jflikV7oIf+3kfu/I3Shghw4OaKWWEF0D82PkeNNM8woM efpSKLJVyCxZ287Fq/a74vabfqODdVkUEooHl8SqHcmj+/B63MPrW4NLLutiBwlRe4X0 XEdM7VE3MFKzApjzhISbLDko2YAzC5O9Mj7KUcBQTLbWoabv1l5iNY6TaUR8WpnDl8HR xoNdRsmMJH2EsrjpmEHbsQDnJ4txhm660vgrRA3AL72HjJsk65CBOH1YtU+G23dpEdqL BCfQ== X-Gm-Message-State: AHYfb5iTLgPDGuCT2VgLomKTZ9tUe+ZjVPTdykOrb7L7hpfAAlvwzbho jXTX9YkNhP9bprACnCSQUARXj31jtxR1PFtClW2WlyM+bQFKxZspIAo12FOuflS7VUVfIpr2yUx xxEObjCgPbcJ4ccg= X-Received: by 10.176.26.174 with SMTP id j46mr765964uai.81.1501820313356; Thu, 03 Aug 2017 21:18:33 -0700 (PDT) X-Received: by 10.176.26.174 with SMTP id j46mr765957uai.81.1501820313215; Thu, 03 Aug 2017 21:18:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Thu, 3 Aug 2017 21:18:32 -0700 (PDT) In-Reply-To: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> From: David Farmer Date: Thu, 3 Aug 2017 23:18:32 -0500 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Brian E Carpenter Cc: Mark Smith , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="f40304362f96493ba50555e5ca34" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 04:18:37 -0000 --f40304362f96493ba50555e5ca34 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 10:55 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 04/08/2017 15:39, David Farmer wrote: > > ... > > because RFC4682 is clear > > that you need a PIO with a length of 64 bits > No it isn't. Quite the opposite; it's carefully written to avoid > such a statement. > Well, yes, by itself it it was carefully worded not to say that, but combined with RFC4291 its quite clear, and I'm not aware of any implementations of SLAAC that will generate addresses for PIOs with the A flag set and any-other length than 64. (If you are please tell, I'd really like to be able to argue this differently) So, I don't think the combination of RFC4291bis and RFC4682 could legitimately allow any-other length than 64 for PIOs with the A flag set as well, otherwise its more than a just a bis, it would be an actual change. 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 =============================================== --f40304362f96493ba50555e5ca34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 10:55 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 04/08/2017 15:39, David Farmer wrote:

...
> because RFC4682 is clear
> that you need a PIO with a length of 64 bits
No it isn't. Quite the opposite; it's carefully written to avoid such a statement.

Well, yes, by itself = it it was carefully worded not to say that, but combined with RFC4291 its q= uite clear, and I'm not aware of any implementations of SLAAC that will= generate addresses for PIOs with the A flag set and any-other length than = 64. (If you are please tell, I'd really like to be able to argue this d= ifferently)

So, I don't think the combination = of RFC4291bis and RFC4682 could legitimately allow any-other length than 64= for PIOs with the A flag set as well, otherwise its more than a just a bis= , it would be an actual change.

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
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
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-30= 29=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
--f40304362f96493ba50555e5ca34-- From nobody Thu Aug 3 21:59: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 CBACC120227 for ; Thu, 3 Aug 2017 21:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, 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 fEZqvP5AF0hJ for ; Thu, 3 Aug 2017 21:59:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5EC128AA1 for ; Thu, 3 Aug 2017 21:59:50 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3DC6734ADB2; Fri, 4 Aug 2017 04:59:47 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 29B9616004C; Fri, 4 Aug 2017 04:59:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 102E1160051; Fri, 4 Aug 2017 04:59:47 +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 VOdpJYGwl5pf; Fri, 4 Aug 2017 04:59:46 +0000 (UTC) Received: from jmb.localhost (c-69-181-118-158.hsd1.ca.comcast.net [69.181.118.158]) by zmx1.isc.org (Postfix) with ESMTPSA id D399E16004C; Fri, 4 Aug 2017 04:59:46 +0000 (UTC) Date: Thu, 03 Aug 2017 21:59:41 -0700 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: David Farmer Cc: Brian E Carpenter , 6man WG Subject: Re: Section 2.4 of rfc4291bis In-Reply-To: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 04:59:53 -0000 At Thu, 3 Aug 2017 23:18:32 -0500, David Farmer wrote: > > > because RFC4682 is clear > > > that you need a PIO with a length of 64 bits > > No it isn't. Quite the opposite; it's carefully written to avoid > > such a statement. > > Well, yes, by itself it it was carefully worded not to say that, but > combined with RFC4291 its quite clear, and I'm not aware of any > implementations of SLAAC that will generate addresses for PIOs with the A > flag set and any-other length than 64. (If you are please tell, I'd really > like to be able to argue this differently) I'm afraid we're now in another distraction for 4291bis, but I'll answer this particular question. I'd say the SLAAC implementation of most if not all BSD variants carefully interpret the sense of RFC4862 in that the SLAAC spec itself doesn't specify the IID (or subnet prefix) length. As I'll explain below, it's true that this implementation (happens to) only allow 64-bit IID for SLAAC, but it has nothing to do with RFC4291. To be more specific, see the prelist_update() function of the FreeBSD implementation: https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_rtr.c#L1469 in particular, this part: /* * Prefix Length check: * If the sum of the prefix length and interface identifier * length does not equal 128 bits, the Prefix Information * option MUST be ignored. The length of the interface * identifier is defined in a separate link-type specific * document. */ ifidlen = in6_if2idlen(ifp); ... if (ifidlen + pr->ndpr_plen != 128) { nd6log((LOG_INFO, "prelist_update: invalid prefixlen " "%d for %s, ignored\n", pr->ndpr_plen, if_name(ifp))); goto end; } and, you can see the implementation of in6_if2idlen(): https://github.com/freebsd/freebsd/blob/master/sys/netinet6/in6.c#L1961 It only refers to link-type spec like RFC2464, etc, and has nothing to do with the addressing architecture (if you read the entire function you may find the default case interesting in this context, but this should actually be an "impossible" case, and in any event irrelevant to the addressing architecture). So, yes, the current implementation only allows 64-bit IID in the end, but that's simply because all published link-type specifications adopt this value. The "SLAAC implementation" (the prelist_update() function()) itself is completely agnostic about these values, and if and when some link type defines a non-64-bit IID, all you have to do would be to update another 'case' to in6_if2idlen() (which is an implementation of "link-type specification", not SLAAC itself). > So, I don't think the combination of RFC4291bis and RFC4682 could > legitimately allow any-other length than 64 for PIOs with the A flag set as > well, otherwise its more than a just a bis, it would be an actual change. I tend to agree on the conclusion (i.e., talking about non-64 IID for SLLAC would be a subject of bis), but to be very accurate, it's not directly because of the combination of RFC4291 (or its bis) and RFC4862. It's because of the combination of RFC4862 and currently published link-type specifications such as RFC2464 (RFC4862 assumes the latter is consistent with RFC4291, and it's the case today, but that's an indirect cause). -- JINMEI, Tatuya From nobody Thu Aug 3 23:55: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 6267013170E for ; Thu, 3 Aug 2017 23:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuRhAefgj73k for ; Thu, 3 Aug 2017 23:55:36 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD6112EA7C for ; Thu, 3 Aug 2017 23:55:35 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id u185so1005432pgb.0 for ; Thu, 03 Aug 2017 23:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xJyW7SlCCXqJLVf0EpAmbogyoZu4d49Kjc4nKZFfwf8=; b=uW06cXb5zooD2JElV+Q0n10XRaHKlxWHk54/EJP6yArHTojEF1tD5xIhFFMedXVLjX MKg1NWHbqkTyuURb0Mf3dG9T+Sg81jT8vWOYxN0YGyD0Ij3rPFR+2iA5hz1PlzrA+0yV Bp6fnfIqaqVRvxzyDpZHHDc5vCPGYbuAZpnpCQzDMbJc1s0j6haFWu9YbWA6mP4y1phS oqT2hG2DUAWoQjBu1vvVlBwCzQdtixn3/Zx8NLYksq3KotFta6BMCHq5cJGja/iBIcVT x6V9aZ/c8zMWYkMwrD0SVb54o1LpUGJ2ZcnMdeZj946fCCC6LYPLM32VZHzvih/HBRWy h7Mg== 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=xJyW7SlCCXqJLVf0EpAmbogyoZu4d49Kjc4nKZFfwf8=; b=PnBnqHxrsImHNGYgfW1m143hCzNnUIL+YTQXiJdhgkWKLF/pq2bP8psUqhV9sVuzR9 RuEYpqHCvrEjs+3I2QExLSq/1TOLLg8FZwSyUOaj0KoGyW18+hs0zHEQ/4FJicQZofYq HNb0WIiyGC5WAag10F2osYDkPP+c05AiFBR1WnoOuLaU0Ettm4ToVzFB5X+m9Og7xB8b YUVpnr2yycc8X6Z/40GdF0Q015uiAU7a7pSCIJgWo4OYW2A8nc80I1XsiqgfZ98gdad5 Gw7hOVn2xVNzb94w8mFua+bmL7nfdBirg0mgCKu0onXJBh268rErcwzPr2GYlpWYw+V0 +dgQ== X-Gm-Message-State: AIVw112H4pMORYrszfRBw0cQhVr06crrCC5ZfVCkL3vNJMD19t23cEkZ 2lzrXi7pTlDuGw== X-Received: by 10.98.73.198 with SMTP id r67mr1403669pfi.83.1501829734461; Thu, 03 Aug 2017 23:55:34 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id m3sm1457427pfm.175.2017.08.03.23.55.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 23:55:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: Date: Fri, 4 Aug 2017 15:55:29 +0900 Cc: David Farmer , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 06:55:38 -0000 The only way to interpret the RFC 4291bis text "Interface Identifiers are 64 bit long except =E2=80=A6 when the = addresses are manually configured=E2=80=9D should be that the length is 64 bits long if the addresses are = auto-configured by SLAAC. In constrast, SLAAC doesn=E2=80=99t for itself constrain the length of = the IID. Then, it=E2=80=99s RFC 4291bis which mandates the IID length of IID = before anyone else does; even before any link-layer-specific documents = mandate it. I=E2=80=99d assume RFC 4291bis is the primary place for the idea of IID = length of 64 bits. No one else to blame. Am I correct? Regards, DY > On 4 Aug 2017, at 13:59, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: >=20 > At Thu, 3 Aug 2017 23:18:32 -0500, > David Farmer wrote: >=20 >>>> because RFC4682 is clear >>>> that you need a PIO with a length of 64 bits >>> No it isn't. Quite the opposite; it's carefully written to avoid >>> such a statement. >>=20 >> Well, yes, by itself it it was carefully worded not to say that, but >> combined with RFC4291 its quite clear, and I'm not aware of any >> implementations of SLAAC that will generate addresses for PIOs with = the A >> flag set and any-other length than 64. (If you are please tell, I'd = really >> like to be able to argue this differently) >=20 > I'm afraid we're now in another distraction for 4291bis, but I'll > answer this particular question. I'd say the SLAAC > implementation of most if not all BSD variants carefully interpret the > sense of RFC4862 in that the SLAAC spec itself doesn't specify the IID > (or subnet prefix) length. As I'll explain below, it's true that > this implementation (happens to) only allow 64-bit IID for SLAAC, but > it has nothing to do with RFC4291. >=20 > To be more specific, see the prelist_update() function of the FreeBSD > implementation: > = https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_rtr.c#L146= 9 > in particular, this part: >=20 > /* > * Prefix Length check: > * If the sum of the prefix length and interface = identifier > * length does not equal 128 bits, the Prefix = Information > * option MUST be ignored. The length of the interface > * identifier is defined in a separate link-type = specific > * document. > */ > ifidlen =3D in6_if2idlen(ifp); > ... > if (ifidlen + pr->ndpr_plen !=3D 128) { > nd6log((LOG_INFO, > "prelist_update: invalid prefixlen " > "%d for %s, ignored\n", > pr->ndpr_plen, if_name(ifp))); > goto end; > } >=20 > and, you can see the implementation of in6_if2idlen(): > = https://github.com/freebsd/freebsd/blob/master/sys/netinet6/in6.c#L1961 > It only refers to link-type spec like RFC2464, etc, and has nothing to > do with the addressing architecture (if you read the entire function > you may find the default case interesting in this context, but this > should actually be an "impossible" case, and in any event irrelevant > to the addressing architecture). >=20 > So, yes, the current implementation only allows 64-bit IID in the end, > but that's simply because all published link-type specifications adopt > this value. The "SLAAC implementation" (the prelist_update() > function()) itself is completely agnostic about these values, and if > and when some link type defines a non-64-bit IID, all you have to do > would be to update another 'case' to in6_if2idlen() (which is an > implementation of "link-type specification", not SLAAC itself). >=20 >> So, I don't think the combination of RFC4291bis and RFC4682 could >> legitimately allow any-other length than 64 for PIOs with the A flag = set as >> well, otherwise its more than a just a bis, it would be an actual = change. >=20 > I tend to agree on the conclusion (i.e., talking about non-64 IID for > SLLAC would be a subject of bis), but to be very accurate, it's not > directly because of the combination of RFC4291 (or its bis) and > RFC4862. It's because of the combination of RFC4862 and currently > published link-type specifications such as RFC2464 (RFC4862 > assumes the latter is consistent with RFC4291, and it's the case > today, but that's an indirect cause). >=20 > -- > JINMEI, Tatuya >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Aug 4 01:06: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 BBE2F132145 for ; Fri, 4 Aug 2017 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8ZaFPl28Ytf for ; Fri, 4 Aug 2017 01:06:49 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7858A126B6D for ; Fri, 4 Aug 2017 01:06:49 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id d124so3314164vkf.2 for ; Fri, 04 Aug 2017 01:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iIX1DWM0YcPEE8Mk4g9LXTUmXI2qCchkx7jf61WX0gA=; b=KUQ+nFmWwRanf8419Td9/e5GPG0hArBiU0BjK3t99HwOo0jnF6cQt6+3jpimQxLYRG SzzZ54jYIDtIt+GyaaEJ009dlnw0UXdyNFBnS8LcnWrv0IGpCfUaWbBnpAKGp9Pk4+IU 4UBwG2+dWZEcqX4XVRGmGZn3iC867C6jDiG9sPYyZLtm59xPZdBYMhnIdC0Iz6DeIcXF fTb8QWV57bI6UyO3GTtJ9gAJpa5296mC+3ErrhKxHm98PAiH0MsC2AHBtxlvNZAqptph C+rmOzHHg7oLyl9IISjbAsEAyYhmwebW5dE3W2el/eWyczMn0MQMeaB9JJFSge27kb+0 eHoQ== 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=iIX1DWM0YcPEE8Mk4g9LXTUmXI2qCchkx7jf61WX0gA=; b=ZL8MHnuraLMfyveHi1da/BLo8zmT04y9QPtkKTUvKDnvCbnrRUXUrH+XxMnZv4+EbP 1AEZi9rCy59/DG+Z7JTeyAmQgOIF1ZrduNtL4xd/L8Z6DKTHY4wtAQ1SPXpsrLzmGBWj /TiN+KSPi9AHgOSpSr7dyTQw4m1Zo5q/5INmDFPRJnZqbbHCFzci0K4Y13WPeDOSpxEA 7cMFXP6mk2Fq3xiZ3+OoX2ID5VXARCtbPkIqs3C6HkNRyrw1gOFF79JRp1r3bvaVOL09 UeiTqLuFLnNmDpJuF0d87M9YdDNQ+jdGQU+98hE76Lm1dhlJ03ndwiMrp4eiAX1xbbI/ kqkg== X-Gm-Message-State: AHYfb5jx79DdiVdHl+CiJ88PPoB7kewLyf4e0OGTbhkUNMUvBKrumdL3 8PD1LoPuRn0qGqIvTYJRUF0SfTD7GQ== X-Received: by 10.31.84.130 with SMTP id i124mr905999vkb.41.1501834008423; Fri, 04 Aug 2017 01:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 01:06:17 -0700 (PDT) In-Reply-To: References: From: Mark Smith Date: Fri, 4 Aug 2017 18:06:17 +1000 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: David Farmer Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:06:51 -0000 Hi David, On 4 August 2017 at 13:39, David Farmer wrote: > > > On Tue, Aug 1, 2017 at 11:42 PM, Mark Smith wrot= e: >> >> >> On 2 Aug. 2017 03:35, "=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89" wrote: >> >> At Tue, 1 Aug 2017 16:10:16 +1000, >> Mark Smith wrote: >> >> >> In my opinion the current text gives the false impression that there = is >> >> always a common prefix for address assignment and on-link >> >> determination, or >> >> the subnet prefix and the on-link prefix are the same, which they >> >> frequently are, but are not require to be. >> > >> > This is confusing. What address generation and configuration method is >> > being used? DHCPv6, SLAAC or manual configuration? >> > >> > I don't understand how the subnet prefix and the onlink (subnet) prefi= x >> > can >> > be different. >> >> For simplicity let's focus on SLAAC for address configuration and >> RA-based on-link determination. Then, do you mean you don't >> understand how these two can be different? >> - a prefix advertised in an RA PIO with the A flag on, for SLAAC >> - a prefix advertised in an RA PIO with the L flag on, for on-link >> determination >> >> >> No, completely understand that e.g. >> >> https://www.slideshare.net/mobile/MarkSmith214/ipv6-ras-mostly-necessary >> >> I'm pretty confident of my understanding of all of these things. That's >> why I don't understand the need for any new terminology or concepts. The >> need is not obvious to me, which is why I need more stated and explained >> context and description of the problem and confusion. >> >> The problem may be that some of the concepts aren't as clear to others. = I >> think that would argue for more clarity and explanation, perhaps in anot= her >> ID. I think creating new terms and concepts may create more confusion ra= ther >> than eliminating it. > > > So a question for you Mark, when RFC4291 says "subnet prefix", in your mi= nd > what PIO flags does this translate to? > So by itself, the term "subnet prefix" or an instance of a subnet prefix (e.g., 2001:db8::/64) doesn't really tell me anything about the context it is being used in, so it doesn't automatically translate in my mind into a set of PIO flags. A "subnet prefix" could be appearing in a route table, in an ACL, in an RA PIO, or on a training course page. I don't know or can accurately guess anything further about the subnet prefix without knowing the use context. If the use context is added, e.g. "a subnet prefix within a PIO", then the associated properties of what the L and A bit values are become relevant because the use context of the subnet prefix was stated. > To me, since RFC 4291 also says that an IID must be 64 bits, > I feel it must > only be referring to a PIOs with the A flag set, So in section 2.5, "Unicast Addresses", which I think is the formal definition of the structure of addresses, there are no statements that the context of the "subnet prefix" and "interface ID" definitions are only when SLAAC is used to generate and configure them. There isn't mention of any address generation or configuration method at all (i.e, no mention of SLAAC, DHCPv6 or manual configuration), so that says to me that those definitions of address format and structure apply in all cases - they're properties of an address as an entity by itself, and are not properties that may or may not apply for different address configuration methods. So from "2001:db8::1/64" you can say that the boundary between the subnet prefix and the IID is 64 bits into the address, that the subnet prefix value is 2001:db8:0:0 and the IID value is 0:0:0:1. However you cannot accurately say anything else about it, because there is no other information provided including use context. > because RFC4682 is clear > that you need a PIO with a length of 64 bits and the A flag set to use > SLAAC. However, both RFC4681 and RFC4682 are quite clear that a PIO with > the L flag set can be any length. So if a subnet is fixed at 64 bits, the= n > how can it be referring to PIOs with only the L flag set which can be any > length, therefore PIOs with only the L flag set must be something separat= e > from a subnet prefix as defined in RFC4291. I may not be fully understanding this, however I think you might be saying that the following could be interpreted as valid in theory in an RA: RA PIO 1: 2001:db8::/64 [L=3D0][A=3D1] RA PIO 2: 2001:db8::/120 [L=3D1][A=3D0] meaning that for SLAAC's purposes, there are 64 bits available to generate the IID, where as the host will only consider the range of addresses 2001:db8::0 through 2001:db8::ff to be onlink, and the other 2^64 - 256 addresses within 2001:db8::/64 are off-link (or the opposite could be valid in theory - the onlink prefix size is larger than the SLAAC prefix size). It might be valid. Although RFC4861 says, "Prefix Information options: one Prefix Information option for each prefix listed in AdvPrefixList with the option fields set from the information in the AdvPrefixList entry as follows ..." the subnet prefixes are have different prefix lengths so they are different subnet prefixes. If it were valid, I wonder if there is a useful use case. I suppose you could use it to do something like divide the /64 subnet prefix up into e.g. half SLAAC, half DHCP e.g., RA PIO 1: 2001:db8::/65 [L=3D0][A=3D1], and a DHCPv6 address range of 2001:db8:0:0:8000::/65. Although in practice we now have 2 x /65s, the IID is still 64 bits in size. A bit of a bodge. > > Now if a subnet prefix can be any length and then it could be referring t= o a > PIO with only the L flag set. However, then something needs to constrain > IIDs to 64 bits, but only for SLAAC. In my opinion, we either need to tal= k > about on-link prefixes or we need to change the constraints on the > definition of a subnet in RFC4291bis so it fits PIOs with the A flag set = or > PIOs with only the L flag set. > > So I think something like this would work; > > IPv6 unicast routing and on-link determination are based on prefixes > of any valid length up to 128 bits[BCP198]. However, 64 bit prefixes > are recommended for both subnet assignment and on-link determination. > > > and; > > 64 bit Interface Identifiers are required for Stateless Address > Autoconfiguration (SLAAC)[RFC4862], except if the first three bits of > the address are 000, otherwise 64 bit Interface Identifiers are > recommended. The rationale for using 64 bit Interface > > Identifiers can be found in [RFC7421]. > > > A definition of subnet prefix and IID something like that leaves room for= it > to be referring to PIOs with the A flag set or PIOs only the L flag set, > then the gory details can be left to RFC4681 and RFC4682. However a > definition tightly constrained to 64 bits for subnet prefixes and IIDs me= ans > it can't be referring to PIOs with only the L flag set, and I believe the= y > are architectural important, therefore something needs to describe them t= hat > is distinct from a subnet prefix, in my mind that would be an on-link > prefix. > > So, if you think the details of on-link prefixes don't belong in RFC4291b= is, > I'm fine with that, Broadly do. While the line is probably already blurred, and perhaps it may not be realistically possible, however it would be nice to have RFC4291bis dealing with properties of addresses, subnet prefixes and IIDs that are common across use contexts, and then have other RFCs provide and describe those specific use contexts, and which then add properties to the addresses and subnet prefixes that suit the specific use context. > then just relax the definition of a subnet prefix so > that PIOs with only the L flag fit within the definition of a subnet pref= ix. > Regards, Mark. From nobody Fri Aug 4 09:38: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 CA2121321E7 for ; Fri, 4 Aug 2017 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IqXI1WyshUz for ; Fri, 4 Aug 2017 09:38:19 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744BC1321E0 for ; Fri, 4 Aug 2017 09:38:19 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id v29so12069438qtv.3 for ; Fri, 04 Aug 2017 09:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=sByiToPmq82FLqdrxyC8uts7b+C016sCNzgsJTUGra0=; b=DQN55tgQ7Fv/EqFGvdz6WmmvoO9Ghc+ZvVSScuWeSi7KEk1Bxxl1Ks69UITlTFqe5h LAH42CG3CGrr/RBUJVe/yKTFD9lMNvvQEEdr+wGrl+8zoaLwJLQvvyzsuR78ETZuEbwn R/Kp1tjCWHNCF6c8u1QuM9T+H+jy3SAl7J3bRpTw41OxZPv4ox5fAAhe0PMlUkS2jpzD 1Dnd+Pf0armOPIjzm/IBi6wuNjS9ElYro7ORtk7hJ2T7iI7GP1xgUiCP1VNgBHzSgl+W pyBiHbfEbXMeYca+dc1uZftcC5zM7pQ0bh3lc6LaVURdd67f8Rcr1RmbPDsWi7iZdXn9 YogQ== 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=sByiToPmq82FLqdrxyC8uts7b+C016sCNzgsJTUGra0=; b=eOJ8c5HUhxCcbMEeAY1/j9eqBsmKFELLc3dqXvo4jkk52QD6dX5EtzZchAayxe5mco yAIP0Plzd8EhEqC7q54tEbMjWqmViYAGZbeCJRe841W6oRgyRKmzWsVAXjV1tdqNSRLY WB4RP7zaVfp+FFIRZaWSheIQsbli4LcP1Hw/zsywkt/M/PPvPXJuUfiaezSerWbOxiF8 IevaDPzRxJGOKwZIM16mvGfnrtSr2XUNGlR1seABxyrzmwCWpwguKtUzxGcZzgHljOz3 T8BiVOz+/YiWxHIBsq6QVUWG1ovroo0s1YKKSNPJMPzdzyW47rcJ9wO9SY149ZbY1iRW rwPw== X-Gm-Message-State: AHYfb5gUrW+74NWBe6O49gyfW0RHDX1Faw5GJo+kuvPa4FTFqi7yFgXX 8fZgU6Hs10eUloxhyTq7ykFHEqRNyW/fzi8= X-Received: by 10.237.47.133 with SMTP id m5mr3795185qtd.246.1501864698473; Fri, 04 Aug 2017 09:38:18 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 4 Aug 2017 09:38:17 -0700 (PDT) In-Reply-To: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 4 Aug 2017 09:38:17 -0700 X-Google-Sender-Auth: vtMzo57tNYr49z3Vbu_KjjNK3jY Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 16:38:21 -0000 At Fri, 4 Aug 2017 15:55:29 +0900, DY Kim wrote: > "Interface Identifiers are 64 bit long except =E2=80=A6 when the addres= ses are manually > configured=E2=80=9D > > should be that the length is 64 bits long if the addresses are auto-confi= gured by SLAAC. > > In constrast, SLAAC doesn=E2=80=99t for itself constrain the length of th= e IID. > > Then, it=E2=80=99s RFC 4291bis which mandates the IID length of IID befor= e anyone else does; even before any link-layer-specific documents mandate i= t. > > I=E2=80=99d assume RFC 4291bis is the primary place for the idea of IID l= ength of 64 bits. No one else to blame. > > Am I correct? It's subtle. The facts are: - RFC4291 specifies the length of IIDs for some set of addresses to be 64 bits. rfc4291bis-09 introduces some more exceptions, but essentially it's the same as RFC4291 in this sense. - Some link-type specifications such as RFC2464 also specify the length of IIDs independently (RFC2464 only refers to the addressing architecture RFC for the concept IID, not for the length of it). As far as I know all existing such link-type specs use 64 bits for the length of IIDs. - SLAAC spec (RFC4862) doesn't specify the length of IIDs. It simply uses link-type specs for the primary reference of it with the assumption that those link-type specs are consistent with the addressing architecture. >From these I can only say for sure that RFC4862 itself is agnostic about the length of IIDs. At least to me, it's not so obvious whether "RFC 4291bis is the primary place for the idea of IID length of 64 bits". -- JINMEI, Tatuya From nobody Fri Aug 4 10:19: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 8B2A01323AC for ; Fri, 4 Aug 2017 10:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfGP3KKX8b9H for ; Fri, 4 Aug 2017 10:19:14 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5AE1323A6 for ; Fri, 4 Aug 2017 10:19:14 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y129so10342086pgy.4 for ; Fri, 04 Aug 2017 10:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B6tzQxuktCZ7XHfiO4f+3zl0ECynup5BJdPaLZv4tP0=; b=Xk+085djy2LfORoF7obRTmQ8vQGk8UnzGsySExft+FG7+7LZaRWIFh2qBiAglEm5vO u9tmobsuLCCz3z9SiEpCg+Dy/5CQxhCXT4MTNOU2ch/zZb+u3Ym0zK2abaDDil21hy5T oq4WibAos1uptb+rXDR+wNmko3lOdIL6no4BJg7VeIWFXkcoB+CFebnEX62unLKqoqbh GNef7ay/a7dMC6hIrVV046J12l4qQCB+wsgFy2pS6eonaw9thgSyJRok9obi0pyARYQa Rzq6EPsWKzNod+b2RxYH62dQDVxaikTdcCeWKpvkdcUTGfRmkn8Jge0Kw3N3wYsmCCUq 4gOA== 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=B6tzQxuktCZ7XHfiO4f+3zl0ECynup5BJdPaLZv4tP0=; b=FbsoXmQyGqK1/RHSVlbiomofaA0Blq/O6whTaL3CrrHGHawgpcBVwJVGMBjhaJJQ7V sp3coD0qyQ6t0OB8WRpuTskxVDhJU73/6sC9ENwxmyaPQRceJRzWKffBQrTS8NV671OH Kvp3YOc5KPc+XW4O++S6aaaEN6FVKrzHeTb3Oi+R/ds2FY92Hes+oWfwsiWjgiaLbEw5 LG7W6TLzgoF/yTnQC/ZdWH5ljSK2Nw/2AsSsfy7QG4K9M7DToEhGjK1ktcO9PTqGSXkP 7HzvgpHShBDI96HrNWhzXJS4IoNwkwqJb5ukczP0EsbrNQs1ZHH3HAWem/rECH00afwA Fy3Q== X-Gm-Message-State: AIVw110sad/REgdvMdjOWRc9Vh0LJMq+3huE9dbSML3UuAKgihgYihy7 SkiSOjUZxfcV4cKB6Vo= X-Received: by 10.84.232.206 with SMTP id x14mr3585175plm.434.1501867153916; Fri, 04 Aug 2017 10:19:13 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id p67sm4205313pga.79.2017.08.04.10.19.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 10:19:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 02:19:09 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:19:15 -0000 RFC2464 is =E2=80=98by exception=E2=80=99, according to the wording used = in RFC4291bis. For that, RFC 4291bis should be the primary (albeit not =E2=80=98the = only=E2=80=99) place mandating the IID length of 64 bits. This is my understanding. -------- Regards, DY > On 5 Aug 2017, at 01:38, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Fri, 4 Aug 2017 15:55:29 +0900, > DY Kim wrote: >=20 >> "Interface Identifiers are 64 bit long except =E2=80=A6 when the = addresses are manually >> configured=E2=80=9D >>=20 >> should be that the length is 64 bits long if the addresses are = auto-configured by SLAAC. >>=20 >> In constrast, SLAAC doesn=E2=80=99t for itself constrain the length = of the IID. >>=20 >> Then, it=E2=80=99s RFC 4291bis which mandates the IID length of IID = before anyone else does; even before any link-layer-specific documents = mandate it. >>=20 >> I=E2=80=99d assume RFC 4291bis is the primary place for the idea of = IID length of 64 bits. No one else to blame. >>=20 >> Am I correct? >=20 > It's subtle. The facts are: >=20 > - RFC4291 specifies the length of IIDs for some set of addresses to be > 64 bits. rfc4291bis-09 introduces some more exceptions, but > essentially it's the same as RFC4291 in this sense. > - Some link-type specifications such as RFC2464 also specify the > length of IIDs independently (RFC2464 only refers to the addressing > architecture RFC for the concept IID, not for the length of it). As > far as I know all existing such link-type specs use 64 bits for the > length of IIDs. > - SLAAC spec (RFC4862) doesn't specify the length of IIDs. It simply > uses link-type specs for the primary reference of it with the > assumption that those link-type specs are consistent with the > addressing architecture. >=20 > =46rom these I can only say for sure that RFC4862 itself is agnostic > about the length of IIDs. At least to me, it's not so obvious > whether "RFC 4291bis is the primary place for the idea of IID length > of 64 bits". >=20 > -- > JINMEI, Tatuya From nobody Fri Aug 4 10:42: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 632A01321D2 for ; Fri, 4 Aug 2017 10:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttCTZck6DjtN for ; Fri, 4 Aug 2017 10:42:17 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D3C1321DD for ; Fri, 4 Aug 2017 10:42:16 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id u139so12904726qka.1 for ; Fri, 04 Aug 2017 10:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=7ffHn6gd4zLDlhB9OnE07qC0rWlpEhyffA81xAQFJBc=; b=Oz4WFvGR/oXiR4vW3OV0e25zRql6oebvjmbHKsg8sOg2oULlFcqJTPsAeg/T61cq4y 2Bn7jeLkQg2rDRhItzMJINO6KNo27r8IrBIz5BPhvFSFsNG55AoD1S/JvPtiFAG52KI8 BXx3fTRRW8vER7XipQdea6/IgN07vHxqG/auX7aQxywu06pOudDHfg1VwPbND8zsQv1X 07KjuGTPZ+zU9L/MGwl0lzZ0Mp+bcHt4e/Biw0P3QmtN+AupCE3lloXvDh9pQ+6irc8v yjMPV/ivEMzDfu7bjfbiOI6HnAcL5rvba764E28xEGgNlgN93paiXk817G9eQpqv+gnz 29fQ== 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=7ffHn6gd4zLDlhB9OnE07qC0rWlpEhyffA81xAQFJBc=; b=rO+E4Idtuh0JhBotztEYNp1KstIqRL/NrA96B91N/kM0NWAjXIimtJ6E0xLt3CdNEP FnH1r2ii0rHLrKG8YmKGZFMzUlZ3drscjRL7LMT+i4+oSTMcKkqHoqEwGYlcpIqW0ckd S3BG3Md5H1u8lbe3mf247JrNfJcnh4MJHNoWE8EpJEGYtCBx/vDm3TBh8y2ym/o5BbkR CLWDpG41aClMwjNnKxKyGQYIQvlc+b615J0IERWhiUy2mv/FhaDhUdZsF2d1UZ9WgTv4 FSCsy4iIuaL+vA5lxyY/IH75I+u7wSyD4cwN34YVOjavZyHor2AMa9MuEVniV4vEQHws pH9A== X-Gm-Message-State: AHYfb5jBT0vCi8ooh6BpfJakWCSHHGb+KuS5HLC+T28e/bd81ftio788 DSmVk+cH2OGopmD00xM2+zhHSmOvxA== X-Received: by 10.55.144.130 with SMTP id s124mr4216492qkd.136.1501868536044; Fri, 04 Aug 2017 10:42:16 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 4 Aug 2017 10:42:15 -0700 (PDT) In-Reply-To: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 4 Aug 2017 10:42:15 -0700 X-Google-Sender-Auth: m06OyCXL3eZ2U9rbSovNNAblRLY Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:42:18 -0000 At Sat, 5 Aug 2017 02:19:09 +0900, DY Kim wrote: > RFC2464 is =E2=80=98by exception=E2=80=99, according to the wording used = in RFC4291bis. If you mean "by exceptions defined in standards track documents" Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. then no, this phrase actually has RFC6164 (and future similar RFCs) in mind. Besides, RFC2462 can't be an "exception" in this context as it says the IIDs are 64 bit long. RFC2462 is actually one of the cases where link-type specifications and the addressing architecture are consistent. -- JINMEI, Tatuya From nobody Fri Aug 4 10:54: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 B21EA132172 for ; Fri, 4 Aug 2017 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTky8oxlk2uh for ; Fri, 4 Aug 2017 10:54:03 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C150F132145 for ; Fri, 4 Aug 2017 10:54:03 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id y129so10652838pgy.4 for ; Fri, 04 Aug 2017 10:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2DLGzEPxWfz8xPdFMtsNHsGsFxOFfXVqczLMQmq4Z+k=; b=ICF0joySjCqcO2KeLXZQTgCG8REABvdCrrpICM33/yMGOw2QOr2j3SBo4nJ2kQ5kRd g7y43xk2XYr41eoInTaHAcvGFctiXLr0DwHTGg8Y1sRVwS/whI32f1CDAuDZC1nP910A EtXcqZzm1pjozWJNLOc+S1IB6Y26i3Z8bFjc83MTgjs7/42KLWGQXD+SEnhJYHsvuHvd uMt3K3C8t79wzJID1r1CTJmLNwmLXMStQHQM0M9GAp+cjIqDTrKXWvynWocP5xw3pITI vCWN89ZKxCtS7iVG+ZQPHIYOjdYmLqpFSSSgzN05PPhgwSzmbaQ8VwvlFKalndIsZ+Ew qMAA== 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=2DLGzEPxWfz8xPdFMtsNHsGsFxOFfXVqczLMQmq4Z+k=; b=FVtBB0veFJyHXQTGr/AAxm2hge5jvRve02gIAhYbaZvN0t1+1yWiy7HmPj8K/6sSid jgN5bfXe5GE4qzBn/raY7og7oQ84AKfV8GEfFwcPbJncun5afpcWdcno4xijFNuBy4Kt vtuLvtGWyJ4yuDE2LlKbfJG2QEbPY/loYZCbtvM1eqL4/eNUPeZ3n+1GKQ1YXaBEhnWw tIOlAMeed/NSQF+GdF3GziUIm0obgUkv369uW5+tDZosIeRJC4HzIVD3LppaxOXdN+kd tjeJbrfyh2/A29v+jyV0xcs8i2ODq8XJ2Ypv9Hj32hKu3G1xi1jFlIEgtVVCmQrXHfEq Rw0g== X-Gm-Message-State: AIVw110MRjWHUL066hlKEK7+imw8aJcFnv2RS6AhtuvTnBFOZ4zYYM1j p4VfTupCi4/KTakK+Bw= X-Received: by 10.84.176.100 with SMTP id u91mr3902362plb.390.1501869243289; Fri, 04 Aug 2017 10:54:03 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id r9sm3765238pgf.83.2017.08.04.10.54.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 10:54:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 02:53:59 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:54:05 -0000 Yes, although defined separately, RFC2462 comes up with the same IID = length. Other than that, do you know any other standards of the same case = wherein the IID length is defined to be 64 bits long? If such cases are not prevalent, =E2=80=98primary=E2=80=99 might be in = place if not =E2=80=98only=E2=80=99. --- DY > On 5 Aug 2017, at 02:42, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > Besides, RFC2462 can't be an "exception" in this context as it > says the IIDs are 64 bit long. RFC2462 is actually one of the cases > where link-type specifications and the addressing architecture are > consistent. From nobody Fri Aug 4 11:45: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 9F524132125 for ; Fri, 4 Aug 2017 11:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72hqJIsjlqBo for ; Fri, 4 Aug 2017 11:45:51 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A0F1320BE for ; Fri, 4 Aug 2017 11:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v74IjoC8029064; Fri, 4 Aug 2017 11:45:50 -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 v74IjkDN029033 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 Aug 2017 11:45:46 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 4 Aug 2017 11:45:45 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Fri, 4 Aug 2017 11:45:45 -0700 From: "Manfredi, Albert E" To: DY Kim CC: 6man WG Subject: RE: Section 2.4 of rfc4291bis Thread-Topic: Section 2.4 of rfc4291bis Thread-Index: AQHTDNM64Rh5ER6T/ESU/RywpcHQRaJ0BqeAgAAGggCAAAt/gIAAIFqAgACi1oCAAAtrgP//nw4Q Date: Fri, 4 Aug 2017 18:45:45 +0000 Message-ID: <19982cec8d46435fb3cf9c060d1c6395@XCH15-06-11.nw.nos.boeing.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 18:45:53 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEWSBLaW0NCg0KPiBSRkMyNDY0IGlzIOKAmGJ5IGV4 Y2VwdGlvbuKAmSwgYWNjb3JkaW5nIHRvIHRoZSB3b3JkaW5nIHVzZWQgaW4gUkZDNDI5MWJpcy4N Cj4NCj4gRm9yIHRoYXQsIFJGQyA0MjkxYmlzIHNob3VsZCBiZSB0aGUgcHJpbWFyeSAoYWxiZWl0 IG5vdCDigJh0aGUgb25seeKAmSkgcGxhY2UNCj4gbWFuZGF0aW5nIHRoZSBJSUQgbGVuZ3RoIG9m IDY0IGJpdHMuDQoNCkkgZG9u4oCZdCBhZ3JlZS4gSSB0aGluayB0aGF0IFRhdHV5YSBKaW5tZWkg c2FpZCBpdCB2ZXJ5IGNvbmNpc2VseSBoZXJlOg0KDQoiSSdtIGFmcmFpZCB3ZSdyZSBub3cgaW4g YW5vdGhlciBkaXN0cmFjdGlvbiBmb3IgNDI5MWJpcywgYnV0IEknbGwgYW5zd2VyIHRoaXMgcGFy dGljdWxhciBxdWVzdGlvbi4gIEknZCBzYXkgdGhlIFNMQUFDIGltcGxlbWVudGF0aW9uIG9mIG1v c3QgaWYgbm90IGFsbCBCU0QgdmFyaWFudHMgY2FyZWZ1bGx5IGludGVycHJldCB0aGUgc2Vuc2Ug b2YgUkZDNDg2MiBpbiB0aGF0IHRoZSBTTEFBQyBzcGVjIGl0c2VsZiBkb2Vzbid0IHNwZWNpZnkg dGhlIElJRCAob3Igc3VibmV0IHByZWZpeCkgbGVuZ3RoLiAgIEFzIEknbGwgZXhwbGFpbiBiZWxv dywgaXQncyB0cnVlIHRoYXQNCnRoaXMgaW1wbGVtZW50YXRpb24gKGhhcHBlbnMgdG8pIG9ubHkg YWxsb3cgNjQtYml0IElJRCBmb3IgU0xBQUMsIGJ1dCBpdCBoYXMgbm90aGluZyB0byBkbyB3aXRo IFJGQzQyOTEuIg0KDQpBbmQgdGhlbiBmdXJ0aGVyIGRvd246DQoNCiJJdCBvbmx5IHJlZmVycyB0 byBsaW5rLXR5cGUgc3BlYyBsaWtlIFJGQzI0NjQsIGV0YywgYW5kIGhhcyBub3RoaW5nIHRvIGRv IHdpdGggdGhlIGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIC4uLiINCg0KIlNvLCB5ZXMsIHRoZSBj dXJyZW50IGltcGxlbWVudGF0aW9uIG9ubHkgYWxsb3dzIDY0LWJpdCBJSUQgaW4gdGhlIGVuZCwg YnV0IHRoYXQncyBzaW1wbHkgYmVjYXVzZSBhbGwgcHVibGlzaGVkIGxpbmstdHlwZSBzcGVjaWZp Y2F0aW9ucyBhZG9wdCB0aGlzIHZhbHVlLiINCg0KKFNvcnJ5IGZvciBoYWNraW5nIHVwIHlvdXIg ZmluZSBwcm9zZSwgSmlubWVpLXNhbi4pDQoNCkluIG15IHZpZXcsIGlmIHRoZXJlJ3MgYW4gaW50 ZW50aW9uIG9mIGJlaW5nIG1vcmUgaW5zaXN0ZW50IG9uIDY0LWJpdCBib3VuZGFyaWVzIGZvciBT TEFBQywgd2hpY2ggSSB0aGluayBtYW55IHBlb3BsZSB3YW50LCB0aGF0IGJlbG9uZ3MgaW4gYW4g UkZDIDQ4NjItYmlzLCBhbmQgbm90IGluIHRoZSBhZGRyZXNzIGFyY2hpdGVjdHVyZSBSRkMuIFRo aXMgbWFrZXMgYW55IGNoYW5nZSBpbiB0aGUgZnV0dXJlIGEgbG90IHNpbXBsZXIuDQoNCkFzIG9m IG5vdywgdGhlIG9ubHkgc3RpcHVsYXRpb24gaW4gUkZDIDQ4NjIgaXMgdGhhdCB0aGUgSUlEIGxl bmd0aCBmb3IgU0xBQUMgaXMgdGhlIElJRCBsZW5ndGggb2YgZGVzY3JpYmVkIGluIHRoZSBJUHY2 LW92ZXItZm9vIFJGQywgZm9yIHRoYXQgbGluayB0eXBlJ3MgTExBLiAoUkZDIDI0NjQgc2V0cyBJ SUQgbGVuZ3RoIDY0IGJpdHMgZm9yIEV0aGVybmV0LiBPaCBieSB0aGUgd2F5LCBpdCBhbHNvIG1h bmRhdGVzIEVVSS02NCEpDQoNCkJlcnQNCg0K From nobody Fri Aug 4 13:05: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 54FDF13207E for ; Fri, 4 Aug 2017 13:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9L1kifQ6hhd for ; Fri, 4 Aug 2017 13:05:56 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC1413202B for ; Fri, 4 Aug 2017 13:05:56 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id l64so11739966pge.5 for ; Fri, 04 Aug 2017 13:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3s4NxW+CISxhiLRiaxC4lS87knfZkXCTrt/axpsI6cI=; b=TmJDDROakOqilLg0BWuNAmbn9hMAqCnXvlIpj9xkdzkVFofJHXN4W6qMheqX0MEB6E JaAn+MR2NEELQL4l+hz4LsTyw7PMkVlxRM5oyojoFPsrDQCIzynnBPg4/sQfOcoNB4A8 0Teaob/DEtH5TcJaxyOZnWrrNE8fkWIjNgCf/TzUfhalBj1DR2AgF+b104DnRRclqw1Q Ha58+WKHhFyyVvNZ6i3JJgqHXxC3uxIc8ndH9/z5TXa422urKQTye2+8Qf2daZpkI3I2 179payBGIim3Wa4urGh83V2OAUIPIPX6NCI23xeKoTiU3EbNz4bP5hthvUNAS62sxXiZ VIYg== 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=3s4NxW+CISxhiLRiaxC4lS87knfZkXCTrt/axpsI6cI=; b=L/2WPw8cTtauURmx+HwZiFk6f2OQH+vHNJw8Y++ha0mEyUcQ2a3xLVkTlWe2Tp9V26 qBHXnjuL4/gNydC7CdhmR1BbNMaAyAvalFA8+8npopP8kqR0w/2v5srUGHGjz2TIh4oC yWOidP0twmdiKKzn7kFj7hQO3DSb+5EWhZF8rRBKAOB5bnBje8F/eufqf/mT5+f2ZsP4 wUPLIaUPQ1el/s3+ANYnLwJF4+uy00ubcV+0tuHQ6rnUmqB3Yw8hHbXW7BXB1mwzjNxO VZwAgctkuHl7eiilpg8LTqNGBngBARQcFwvLUfH7kSnVXr9gas3jEK6zZMvJaAMdexhh 8BHw== X-Gm-Message-State: AIVw111QkRoUm9RLLsVEgerNdZubq1RcCMd/8s1Zuhft2pTDnehu0gcU 5YJa7xWigfKPCUYZRX8= X-Received: by 10.84.215.206 with SMTP id g14mr4108326plj.217.1501877155802; Fri, 04 Aug 2017 13:05:55 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id c69sm4054816pfd.76.2017.08.04.13.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 13:05:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: <19982cec8d46435fb3cf9c060d1c6395@XCH15-06-11.nw.nos.boeing.com> Date: Sat, 5 Aug 2017 05:05:52 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <8B55AF78-30BD-4D4C-A16F-CC9CA66F08A6@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <19982cec8d46435fb3cf9c060d1c6395@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:05:57 -0000 I=E2=80=99m not sure whether you agree or don=E2=80=99t. So, the only practical places to confine the IID length to 64 bits are = the link-type specs like rfc2464. Then, why not simply state as such in rfc4291bis like, e.g.: =E2=80=9CThe length of the interface identifier is defined in = link-layer-specific standard track documents.=E2=80=9D PERIOD, which should replace the current text, Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links. --- DY > On 5 Aug 2017, at 03:45, Manfredi, Albert E = wrote: >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of DY Kim >=20 >> RFC2464 is =E2=80=98by exception=E2=80=99, according to the wording = used in RFC4291bis. >>=20 >> For that, RFC 4291bis should be the primary (albeit not =E2=80=98the = only=E2=80=99) place >> mandating the IID length of 64 bits. >=20 > I don=E2=80=99t agree. I think that Tatuya Jinmei said it very = concisely here: >=20 > "I'm afraid we're now in another distraction for 4291bis, but I'll = answer this particular question. I'd say the SLAAC implementation of = most if not all BSD variants carefully interpret the sense of RFC4862 in = that the SLAAC spec itself doesn't specify the IID (or subnet prefix) = length. As I'll explain below, it's true that > this implementation (happens to) only allow 64-bit IID for SLAAC, but = it has nothing to do with RFC4291." >=20 > And then further down: >=20 > "It only refers to link-type spec like RFC2464, etc, and has nothing = to do with the addressing architecture ..." >=20 > "So, yes, the current implementation only allows 64-bit IID in the = end, but that's simply because all published link-type specifications = adopt this value." >=20 > (Sorry for hacking up your fine prose, Jinmei-san.) >=20 > In my view, if there's an intention of being more insistent on 64-bit = boundaries for SLAAC, which I think many people want, that belongs in an = RFC 4862-bis, and not in the address architecture RFC. This makes any = change in the future a lot simpler. >=20 > As of now, the only stipulation in RFC 4862 is that the IID length for = SLAAC is the IID length of described in the IPv6-over-foo RFC, for that = link type's LLA. (RFC 2464 sets IID length 64 bits for Ethernet. Oh by = the way, it also mandates EUI-64!) >=20 > Bert >=20 From nobody Fri Aug 4 13:13: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 CC9B612EC4B for ; Fri, 4 Aug 2017 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEkRMm5naCgn for ; Fri, 4 Aug 2017 13:13:48 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F16129B5E for ; Fri, 4 Aug 2017 13:13:48 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id z18so14956321qka.4 for ; Fri, 04 Aug 2017 13:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=KjisQMQ96i1tPok/u3yuJkqFPCGSCcphKq5fwCni9/M=; b=NMzKlDbf+qCFHtNRhpxNq7dL1exSk3112yir82XH43DffbukJEa7944Dp4LmOd1aTp BQMP3vo1Gt4ItziyWgXO2jp70ITKbZ2MR9uDUhFzl9gvLBQraEGhbeuaNpffavD9Lu+B oezLPmV7jmsyDP3As79J8oo5USoGTIBAuHgS98p4xQtunO4KUvnhmXuFeNR20fGuMVHx Qx8PRcsXMnP5z4HFxhkLiXFgB03Iqc3DaV+dBWvnYaXFfBQr5XLCzE5kJFZPjZy0v3V3 zg9mpVaunAUwIavPIJ7vg1BFTfGsgsJYDxCP1tCFLTFmnjQJrKy8eEX8N6/SKDtPYY9m AqfA== 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=KjisQMQ96i1tPok/u3yuJkqFPCGSCcphKq5fwCni9/M=; b=dTvTBj5B0F279H8ZikALDTS1ojl9L6cGDghpEYhRXjH3FfjfuqIHjZZIl7F+ALvb41 U31pu0lrVzkal/25SKGkNNqx3gRuopr9/Abfs2XlQM/VV8bQ2g+IX3KYB6ua4yXmoAJA 5Ue6k0twVGMnfgxtZ2Fcs0fR2plYe0cT4YwAEsIzp0Ajv15dWBr1MGgEmrEvryR/y9gY GgXenPs6Sz0lEEI6WJWaSS9QTprn2Btzn2q6a7HVpJd1GTP14yRoZDdh6pxylZes+Opf NbxojcowQ0ivNklzQpem6j7I4QTl70pWzX1qx2Z0NXo2GQ4l9FzmQhbqYZelWVLFpZv4 Typg== X-Gm-Message-State: AHYfb5jeU0/EbSA8Axwd7BP31zwAklXPOs+r/TLI7IiRQDdhWRSPgYqo X6+csr5aG/fcx5mZjQ/ssqaiVs3/C95gGuo= X-Received: by 10.55.125.6 with SMTP id y6mr4743671qkc.83.1501877625962; Fri, 04 Aug 2017 13:13:45 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 4 Aug 2017 13:13:45 -0700 (PDT) In-Reply-To: <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 4 Aug 2017 13:13:45 -0700 X-Google-Sender-Auth: kYo_P1TY1NPFSh1Rdt9Fj2wXVrY Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:13:50 -0000 At Sat, 5 Aug 2017 02:53:59 +0900, DY Kim wrote: > Yes, although defined separately, RFC2462 comes up with the same IID leng= th. (BTW, I made a confusing typo: it should have been RFC2464, not 2462). > Other than that, do you know any other standards of the same case wherein= the IID length is defined to be 64 bits long? RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072. Perhaps some more. > If such cases are not prevalent, =E2=80=98primary=E2=80=99 might be in pl= ace if not =E2=80=98only=E2=80=99. Whether something is "primary" is quite subjective in general, and especially so in this specific case. I respect your own opinion, but, to me, it's not that obvious as I explained in a few messages ago. Anyway, almost lost in context I don't what you're trying to achieve, but at least I'm pretty sure it's even quite difficult to reach a consensus that rfc4291bis is the primary reference about the IID length. -- JINMEI, Tatuya From nobody Fri Aug 4 13: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 93F62129A84 for ; Fri, 4 Aug 2017 13:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyvv--8gMpwT for ; Fri, 4 Aug 2017 13:20:03 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6157A120713 for ; Fri, 4 Aug 2017 13:20:03 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u5so11932575pgn.0 for ; Fri, 04 Aug 2017 13:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oXMYpahDdoqR1HYg5lKwAHFOP39evfLv84gMpaKC8H8=; b=RiDmy3SWR1IuQecnKvukS08zH2Nvyy/5tM/Lhef/OR2U1naRWBPhH6TXHSCA6Eelx0 f2pNt/avjy2HhIAzchR09l5H8QJIOwUwWZa3L0w4NaMWuGoAJ8RCUooNOPL4I9/kDFKY CggE7WuSo4uiVnper3vr7JY1CDSFLPz17Woe/RB9tTtfPZ159Q8P+E/jXRCVk0Q3H0ux jv6DGCMbm+vYpozWtdjzcM9I+YPDHa3z7i7s66S98umHIrKuPzrxRt5Aa+s656s7CMuh Tq0M487kA1zRRcX1xc4rajk15g5en6ILrUZZmHv38AYRFV4dtdI27AYhNhzfpmIpZHQh mRcg== 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=oXMYpahDdoqR1HYg5lKwAHFOP39evfLv84gMpaKC8H8=; b=oF8cahXP8i0vkCFVYkI4u5dI6t7dcLPEQzvCSXEhYrSa3eRvu2sJmnRNXoqLrzckQ/ u6/vwB+7nPJW5JzOBlMJQ2AV1erKdUhKbK+H3kOHsjoxQKaq77diUt14G1jPBRLs0E18 TT1NGrlMVYF0AaH5pFOfIIWqDJvAWltkz/38UjBU0ivuHCOEfuFxMXUF2lnPFX56aR2F JnnFUcylKozo4+m+WanaDkPmfBiwfadDke85oDz/fu/qZw3SVVXaH4hhWanvr301UYE/ OmFs596VKZGeHqJdgwnuUtu9HVb9sd82tMsBx0Wb1uspfCyXAW1AD3j71YzDCJ7SMcGC huFw== X-Gm-Message-State: AIVw112iK3T3iiTZ2L3XCAfQjCtxQ1XO5lqX2bM0b0lSVJLD3A3nl/in yTycoXHLKR88rg== X-Received: by 10.99.120.200 with SMTP id t191mr3592992pgc.191.1501878002833; Fri, 04 Aug 2017 13:20:02 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id e123sm4179135pfa.96.2017.08.04.13.20.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 13:20:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 05:19:59 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:20:05 -0000 OK. Let=E2=80=99s pin down two points: o SLAAC is agnostic to the length of IID. o Explicit definition on the length of IID are with other standard = track documents. Then, why not simply state as such in rfc4291bis like, e.g.: =E2=80=9CThe length of the interface identifier is defined in = link-layer-specific standard track documents.=E2=80=9D PERIOD, which should replace the whole of the current related text, Interface Identifiers are 64 bit long except if the first three bits of the address are 000, or when the addresses are manually configured, or by exceptions defined in standards track documents. The rationale for using 64 bit Interface Identifiers can be found in [RFC7421]. An example of a standards track exception is [RFC6164] that standardises 127 bit prefixes on inter-router point-to-point links. --- DY > On 5 Aug 2017, at 05:13, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072. > Perhaps some more. From nobody Fri Aug 4 13:33: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 483D412EC4B for ; Fri, 4 Aug 2017 13:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MIS4qVO0etuG for ; Fri, 4 Aug 2017 13:33:34 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC405129B5E for ; Fri, 4 Aug 2017 13:33:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 07C4E5C3 for ; Fri, 4 Aug 2017 20:33:30 +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 Hx5YGSJZdkoi for ; Fri, 4 Aug 2017 15:33:29 -0500 (CDT) 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 C88DACD3 for ; Fri, 4 Aug 2017 15:33:29 -0500 (CDT) Received: by mail-vk0-f72.google.com with SMTP id z187so10571553vkd.5 for ; Fri, 04 Aug 2017 13:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vGsiDlwocA8Tt3RVwAgv26LfYeZX9fTWW187F3DisIk=; b=Nd2/cnE3geL8tbKwICIuR3Vim2rjmibRteVA7nW/ecSGFQq/cBy8Yd1WpVutirFo8p iaqXIF/5MwIt/jYJYk+YpSq3lTLLhbn82jMhEKCIWGHrssuPQIrceUvQLA9i8Apd75/i P3kb18Ku72cIRcxK2W1YPgatMttVq68AzDFXn11T8zBFdq5r9VjUoZ/MBmAbCezsQ990 NMz151UxG6abx01+T3iR3Iwd3A2/5HgBxGmR+kZM/HgXHVh1gB7AGUKFxhNaseluN272 qaBtSj817bS5KWvrdxX+ltcpajJg0OxHnmO6DV53Tk1QlKd0/c96spkp5CFEOfiF4Uzg ZSFw== 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=vGsiDlwocA8Tt3RVwAgv26LfYeZX9fTWW187F3DisIk=; b=Muk0OyfpCFRWinzOo4ASgUQZeGXo0VVWDczYFQCN8ZoZKXdiNrLHO5gbaBmgqujEpW AWrhKY6JbGcCGqYaNcnERMIWAWxt4XzVZyTW7GULo+FqfWrQJZCvL+yA6miADbm20hkl 9jMD87o87YSi2l2vZsDuKEm2KvGvkD3/oVgiSJ2YMl/1S5hdkPZRuT8nnOjZDUamY7eU 0cKj9tA7ItJb3PV7J7lAO+1zfAD299uPL9Y1+LM8iEKg8DVw5q2g3iRrbzm+Ibr0GndQ wIFcJkpV9t0cnz2p2KsiACC1p1Y+DQ4pOF0B8Od4JoU3w9jdPLjCwGATGydltAalHid7 K3iQ== X-Gm-Message-State: AIVw110KKypeKS7fYZ6681D7rC+aP4DZ7gyj6eqiF69RYpFyU8DGjQdo fQiV5oxpAZOmUqVoCAddeovYUxnPzsif26dx8APi7U5D9AvUT82LmT77BjOkHsQ6XUGi50W9eZz k+r5VOp/alxTnPLs= X-Received: by 10.176.2.205 with SMTP id 71mr2696040uah.161.1501878809296; Fri, 04 Aug 2017 13:33:29 -0700 (PDT) X-Received: by 10.176.2.205 with SMTP id 71mr2696032uah.161.1501878809125; Fri, 04 Aug 2017 13:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Fri, 4 Aug 2017 13:33:28 -0700 (PDT) In-Reply-To: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> From: David Farmer Date: Fri, 4 Aug 2017 15:33:28 -0500 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: DY Kim , 6man WG Content-Type: multipart/alternative; boundary="001a113acb42ea53140555f3681e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:33:37 -0000 --001a113acb42ea53140555f3681e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 4, 2017 at 3:13 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Sat, 5 Aug 2017 02:53:59 +0900, > DY Kim wrote: > > > Yes, although defined separately, RFC2462 comes up with the same IID > length. > > (BTW, I made a confusing typo: it should have been RFC2464, not 2462). > > > Other than that, do you know any other standards of the same case > wherein the IID length is defined to be 64 bits long? > > RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072. > Perhaps some more. > > > If such cases are not prevalent, =E2=80=98primary=E2=80=99 might be in = place if not > =E2=80=98only=E2=80=99. > > Whether something is "primary" is quite subjective in general, and > especially so in this specific case. I respect your own opinion, but, > to me, it's not that obvious as I explained in a few messages ago. > Anyway, almost lost in context I don't what you're trying to achieve, > but at least I'm pretty sure it's even quite difficult to reach a > consensus that rfc4291bis is the primary reference about the IID > length. > I think we give a non-normative statement that gives a sense of the answer in RFC4291bis like they "are usually 64 bits" and then point to where is is normatively defined. That seems like the what should be said in an architectural document like RFC4291bis. --=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 --001a113acb42ea53140555f3681e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 4, 2017 at 3:13 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <= jinmei@wide.ad.jp> wrote:
A= t Sat, 5 Aug 2017 02:53:59 +0900,
DY Kim <dykim6@gmail.com> wro= te:

> Yes, although defined separately, RFC2462 comes up with the same IID l= ength.

(BTW, I made a confusing typo: it should have been RFC2464, not 2462).

> Other than that, do you know any other standards of the same case wher= ein the IID length is defined to be 64 bits long?

RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072.
Perhaps some more.

> If such cases are not prevalent, =E2=80=98primary=E2=80=99 might be in= place if not =E2=80=98only=E2=80=99.

Whether something is "primary" is quite subjective in general, an= d
especially so in this specific case.=C2=A0 I respect your own opinion, but,=
to me, it's not that obvious as I explained in a few messages ago.
Anyway, almost lost in context I don't what you're trying to achiev= e,
but at least I'm pretty sure it's even quite difficult to reach a consensus that rfc4291bis is the primary reference about the IID
length.

I think we give a non-normative= statement that gives a sense of the answer in RFC4291bis like they "a= re usually 64 bits" and then point to where is is normatively defined.= That seems like the what should be said in an architectural document like = RFC4291bis.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
--001a113acb42ea53140555f3681e-- From nobody Fri Aug 4 13:34:11 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE00B131C25 for ; Fri, 4 Aug 2017 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyYES_DgNOA2 for ; Fri, 4 Aug 2017 13:34:07 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A178212ECC6 for ; Fri, 4 Aug 2017 13:34:07 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id s6so15568884qtc.1 for ; Fri, 04 Aug 2017 13:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=HHLyZxqUIzduHYc2MKCPg6Q4iAAfeibMUTqgZJaqX48=; b=MIICcj6nQm+xyr3BducUCZvL94KK8GNqbKcREN11DoOZOyxrFPRf1FGVuaCn6I76rd p6w+/L5BOqljyK9mNZ97RGBV5q+R/xTd4jA8nkQR32rNnbdecoMeOooQq697QHD9vlPt IJtNNX+sWkxuuG4ApfUbxHtjmHMkw3YqCX8H0tIThpu6HUHJd6skCA8nrYyGroo5RTYG ELtXbYQrkPCcWtr6Wp6H6rV1yQxJAIqvTIWIaypXqwzWmmpzx6cke5MI0ezIXosueAHv MdkxAaWTPh/6O/jaXzh7azewaM5PahPmdM7bVn/AHb0ikX7S+MNGGUxr35vbUEaGWZzI zYzw== 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=HHLyZxqUIzduHYc2MKCPg6Q4iAAfeibMUTqgZJaqX48=; b=ZLX4aScU8haaFxviesMrjuo2BXVvcOz7BL/SLcXsF0fEGKBM+XafsGU/pR4uHnvHD+ +5imjJMZCnOghUt07nJy2s/pJdKOVoacDuvovOvbwGHHOAUEUEDNmMgpB/REnxt7EaxN 2la4FLpWdnp+RVk/lKyOp4xOg1V5HLGdy7dRl8LPT2d4AtuKfWtDDshsTW+C3pDg/lBA Jo9v++8vDQHvDNdMPScFeLtBtR6RMQnrM1xKuemDCthV/kBrwapHWTwDOTJWWBZzC9gA zjHPvOSwCYXjzM71V0NCWg4hsU7C/hSPoegwcu5hD5a6mrsWl+hWqg/HLY4ZXFqMmRnP ELdg== X-Gm-Message-State: AHYfb5gYG2bmKpSYrImTKEABvdlQIH50cuJdmRF1qhmxkfFmxCai+k/9 ByiKuLYVGC3pCQaFguf8Y/RfySJtMw== X-Received: by 10.200.44.170 with SMTP id 39mr5040347qtw.160.1501878846722; Fri, 04 Aug 2017 13:34:06 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Fri, 4 Aug 2017 13:34:06 -0700 (PDT) In-Reply-To: <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 4 Aug 2017 13:34:06 -0700 X-Google-Sender-Auth: osp2_MfaOPvV8o5_KKAFrAasiKw Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:34:09 -0000 At Sat, 5 Aug 2017 05:19:59 +0900, DY Kim wrote: > OK. Let=E2=80=99s pin down two points: > > o SLAAC is agnostic to the length of IID. > o Explicit definition on the length of IID are with other standard trac= k documents. You can't ignore this: o RFC4291 and rfc4291bis also say the length of IID is 64 bits for some set of IPv6 addresses. Reconciling the 2nd and 3rd points would be quite tricky, and that's one main reason why I don't think "what's the primary definition" is so obvious. So... > Then, why not simply state as such in rfc4291bis like, e.g.: > > =E2=80=9CThe length of the interface identifier is defined in link-layer= -specific standard track documents.=E2=80=9D PERIOD, ...it can't be that simple anyway. In addition, (in my understanding) because it's too substantial a change from RFC4291. rfc4291bis is basically an attempt of elevating the original RFC to an Internet Standard, so, in general, we can only make clarifications or minor changes. >From a purely technical point of view, such a change can be a subject of discussion. IIRC some people have actually proposed ideas like that. But this won't be in the scope of rfc4291bis. -- JINMEI, Tatuya From nobody Fri Aug 4 13:48:10 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436D312700F for ; Fri, 4 Aug 2017 13:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJdN3HqySbKK for ; Fri, 4 Aug 2017 13:48:08 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10B7126E3A for ; Fri, 4 Aug 2017 13:48:06 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v77so12107821pgb.3 for ; Fri, 04 Aug 2017 13:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GkBpb7lj1ymioLYnZ1SK1GlhlhAuty5QGX5+rc48+Ro=; b=HMTcsSvx4/hhSwGV93kFcqR4A8W04au50kHElL8QRJuMU6XHvE6ReHmovHfgZc/RPt G6o/P8qdZ50q8lxnLrgJNxBrLPcgt3aVMdTubvrdHFt/F5LgrE7uGkPp4K64qE1SrIHQ qcOzu/Bv3ZescOg/u72VqMLJoI4i+V3CQwOhH8yZntE7CUISuW+vpBBqnVeuTPi0LORX t69VAHMuy9RQ+7+EYNx5zPO0dONHgMtMkxMdYZeOiEo8nYhtvkRFPmqkGxZfENX2sA4W aMelqV/dk83U57EDMTYZ4XRGaRg5IQK8TbHojPpxWWLWkRrZH7l+fcjflNNjJlj+MZbS S52g== 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=GkBpb7lj1ymioLYnZ1SK1GlhlhAuty5QGX5+rc48+Ro=; b=ee1TXGFCL1Rw8Wa2wCi1OxnEysTsk3rEd0m4DYhv5pNi4USa9bB/35KNUtlrvP+1xa AQ37jjY4GtGzO22OfkazIYJavPUWe0/UszoQ9lcwPd1jLNYshj9zr8gbi5pDsDp4qa8y XqTmDDnIOpKsccunUc+qil5mAl30/fYKr7SsB7MN9aPn9kKmAzK/XNXOMdY7lhurzjVH 1BhePaBosCs8EC/m/Hj4vt5Sc6FW/yzMQtGRs8DrzASR6qpBtG0F99CRzr/48AMUIBmz MfNHPF3+ZJhPqHlqITEGCM3JUOZWroVBA5KWptwXnVKLV0EJKxnOlccR5FMHdGZ+rUH6 rJdA== X-Gm-Message-State: AIVw1107L+Go9HHhGziss+5elcSAAkfbds0bG/qQ3nqtW4QToWudb8Df SBdOW4xRHeCc3xKIC1k= X-Received: by 10.99.234.69 with SMTP id l5mr3620087pgk.221.1501879686273; Fri, 04 Aug 2017 13:48:06 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id r86sm5039927pfi.138.2017.08.04.13.48.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 13:48:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: Date: Sat, 5 Aug 2017 05:48:02 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <3DE924C8-7EB0-47C2-97E2-D5A3142A27F2@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:48:09 -0000 Which some? Some other than =E2=80=98standard track documents'? Could you please point me to? --- DY > On 5 Aug 2017, at 05:34, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > o RFC4291 and rfc4291bis also say the length of IID is 64 bits for > some set of IPv6 addresses. From nobody Fri Aug 4 14:00:21 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05C124207 for ; Fri, 4 Aug 2017 14:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 mk61p-zUxc5d for ; Fri, 4 Aug 2017 14:00:16 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF831241F5 for ; Fri, 4 Aug 2017 14:00:16 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id t86so12107246pfe.2 for ; Fri, 04 Aug 2017 14:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=6XBCHWhC8StxWiAe+zduj01GnNmQu8BLTaftnGzycJU=; b=jvE9sOs1D3wtdMludWdcdf4pDyxfTiVekht6I9ZStycUEUomFED7AEIhpYUFl/P9Ti Es8G5ZG2PP6kAJix4K7E479L4w5MmYmdaPHCJWDqS/JDEEip75iuuMhPNRycaQ4Ypjjm Hxub1o/dFUuNxT8TX05O0Uzquw8vf8ut4kQaDWuT1R9Zfnlnr1HXsOT7soGUjO0J0quo 04mx8SpbQvP/TiKwJpMsprJ7x1WEQoCc8nU+UUVjQOTrHPmvHvQW49Ri8+SotIwMHTFN t7zbVF5HtSHArDdLgD7XWKL+Wm3kxpPtrStSmu03QE+aOEZKYHWH4R2xVKtG7B9IMsfN 1gpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=6XBCHWhC8StxWiAe+zduj01GnNmQu8BLTaftnGzycJU=; b=mbQKvsfeo/C+rWu0MjT/JiRQCEZs9hsXyXr9pZWBTUVGfa0noqH8MNjCXVnAG3fpam sK2RqblxsIXMKmzohVcK+UMbRGc6geFa7Yul/lqiahDh0RRqG07ggKooZaaqiWIgf1lX EASGqFd2lvnygG0ArfJQCSAV851MkJQvrpD0pG9PGxG7QyGjrDQ+b8p0ZSQFoeVdASYt RgL1HnZdU/sdUTS+96BFZAKELihis1aa6FHsyG5fSPvbf4l4Dk4xZV2drO2XtkJzmCh5 AHMqx30w3mdjyuimfSKJLemavJhMpd42B9gPLQ2YkZ9Zo4ZCLKtZEuu5npwq8JN1GglC MODA== X-Gm-Message-State: AIVw113IMa/DG96DaaglCaXcv937IIrL1TXE0lh44ryNej3++24jYN+t d8bl04u0cRd7lyh71Js= X-Received: by 10.84.245.9 with SMTP id i9mr4434512pll.284.1501880415640; Fri, 04 Aug 2017 14:00:15 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id i133sm4941482pgc.0.2017.08.04.14.00.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:00:15 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis Date: Sat, 5 Aug 2017 06:00:12 +0900 References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <3DE924C8-7EB0-47C2-97E2-D5A3142A27F2@gmail.com> To: 6man WG In-Reply-To: <3DE924C8-7EB0-47C2-97E2-D5A3142A27F2@gmail.com> Message-Id: <1F7A0F32-6EB8-4B8A-9012-C7AD41D17200@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:00:17 -0000 In light of the upcoming standard track document = which deals with = =E2=80=98host prefix=E2=80=99, may I suggest to change the text now in = the beginning of Sec. 2.4 | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ to | n bits | 128-n bits | +-------------------------------+---------------------------------+ | prefix | interface ID | = +-------------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94---------+ for generalization and to leave room for other types of prefix could = chip in? --- DY From nobody Fri Aug 4 14:02: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 CDF1D126C23 for ; Fri, 4 Aug 2017 14:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vGjzvTsO7ou for ; Fri, 4 Aug 2017 14:02:43 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BD3126C0F for ; Fri, 4 Aug 2017 14:02:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v74L2frU057112; Fri, 4 Aug 2017 14:02:42 -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 v74L0flS053348 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 Aug 2017 14:00:41 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 4 Aug 2017 14:00:40 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Fri, 4 Aug 2017 14:00:40 -0700 From: "Manfredi, Albert E" To: DY Kim CC: 6man WG Subject: RE: Section 2.4 of rfc4291bis Thread-Topic: Section 2.4 of rfc4291bis Thread-Index: AQHTDNM64Rh5ER6T/ESU/RywpcHQRaJ0BqeAgAAGggCAAAt/gIAAIFqAgACi1oCAAAtrgP//nw4QgACPhgD//5b9oA== Date: Fri, 4 Aug 2017 21:00:40 +0000 Message-ID: <6e2efd228761483f9f6a386d32a30315@XCH15-06-11.nw.nos.boeing.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <19982cec8d46435fb3cf9c060d1c6395@XCH15-06-11.nw.nos.boeing.com> <8B55AF78-30BD-4D4C-A16F-CC9CA66F08A6@gmail.com> In-Reply-To: <8B55AF78-30BD-4D4C-A16F-CC9CA66F08A6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:02:45 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERZIEtpbSBbbWFpbHRvOmR5a2ltNkBn bWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDQsIDIwMTcgMTY6MDYNCg0KPiBTbywg dGhlIG9ubHkgcHJhY3RpY2FsIHBsYWNlcyB0byBjb25maW5lIHRoZSBJSUQgbGVuZ3RoIHRvIDY0 IGJpdHMgYXJlIHRoZQ0KPiBsaW5rLXR5cGUgc3BlY3MgbGlrZSByZmMyNDY0Lg0KDQpFeGFjdGx5 Lg0KDQo+IFRoZW4sIHdoeSBub3Qgc2ltcGx5IHN0YXRlIGFzIHN1Y2ggaW4gcmZjNDI5MWJpcyBs aWtlLCBlLmcuOg0KPg0KPiDigJxUaGUgbGVuZ3RoIG9mIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmll ciBpcyBkZWZpbmVkIGluIGxpbmstbGF5ZXItc3BlY2lmaWMNCj4gc3RhbmRhcmQgdHJhY2sgZG9j dW1lbnRzLuKAnSBQRVJJT0QsDQoNCkV4YWN0bHkuDQoNCj4gd2hpY2ggc2hvdWxkIHJlcGxhY2Ug dGhlIGN1cnJlbnQgdGV4dCwNCg0KICAgSW50ZXJmYWNlIElkZW50aWZpZXJzIGFyZSA2NCBiaXQg bG9uZyBleGNlcHQgaWYgdGhlIGZpcnN0IHRocmVlIGJpdHMNCiAgIG9mIHRoZSBhZGRyZXNzIGFy ZSAwMDAsIG9yIHdoZW4gdGhlIGFkZHJlc3NlcyBhcmUgbWFudWFsbHkNCiAgIGNvbmZpZ3VyZWQs IG9yIGJ5IGV4Y2VwdGlvbnMgZGVmaW5lZCBpbiBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnRzLg0K ICAgVGhlIHJhdGlvbmFsZSBmb3IgdXNpbmcgNjQgYml0IEludGVyZmFjZSBJZGVudGlmaWVycyBj YW4gYmUgZm91bmQgaW4NCiAgIFtSRkM3NDIxXS4gQW4gZXhhbXBsZSBvZiBhIHN0YW5kYXJkcyB0 cmFjayBleGNlcHRpb24gaXMgW1JGQzYxNjRdDQogICB0aGF0IHN0YW5kYXJkaXNlcyAxMjcgYml0 IHByZWZpeGVzIG9uIGludGVyLXJvdXRlciBwb2ludC10by1wb2ludA0KICAgbGlua3MuDQoNClll cyBhZ2Fpbi4gVGhhdCB0ZXh0IGNhbiBiZSBncmVhdGx5IHNpbXBsaWZpZWQsIGFzIEJyaWFuIENh cnBlbnRlciBhbmQgb3RoZXJzIGhhdmUgc3VnZ2VzdGVkIGluIHRoZSBjb3Vyc2Ugb2YgdGhpcyB0 aHJlYWQuIE1heWJlICJyZWNvbW1lbmRlZCwiIG9yICJkZWZhdWx0LCIgYXQgNjQgYml0cywgd291 bGQgbWFrZSBzZW5zZS4NCg0KSSB0aGluayB0aGUgZGV0YWlscyBvZiBTTEFBQyBiZWxvbmcgaW4g YW4gUkZDIDQ4NjItYmlzLCBidXQgd291bGRuJ3QgY2hhbmdlIGEgbG90IGluIHByYWN0aWNlLiBN b3N0IExMQSBJSURzLCBhcyBzcGVjaWZpZWQgaW4gd2hhdGV2ZXIgbGluay10eXBlLXNwZWNpZmlj IFJGQ3MsIGFyZSBhbHJlYWR5IDY0IGJpdHMgbG9uZywgc28gdGhhdCBjYXJyaWVzIG92ZXIgdG8g dGhlIFNMQUFDIGZvcm1hdC4gQnV0IG5vdCBuZWNlc3NhcmlseSB0byBvdGhlciB3YXlzIG9mIGZv cm1hdHRpbmcgdW5pY2FzdCBhZGRyZXNzZXMgKERIQ1B2NiwgbWFudWFsIHN0YXRpYyBhc3NpZ25t ZW50cykuDQoNCkFuZCBldmVuIGlmIHRoZSByZWFzb24gZm9yIExMQSBJSURzIGF0IDY0IGJpdHMg aXMgbm8gbG9uZ2VyIHRoYXQgdGhlIElJRCBtdXN0IGJlIEVVSS02NCwgSSB0aGluayB0aGUgZ2Vu ZXJhbCBjb25zZW5zdXMgaXMgdG8ga2VlcCB0aG9zZSBMTEEgSUlEcyBhdCA2NCBiaXRzLg0KDQpC ZXJ0DQoNCg== From nobody Fri Aug 4 14:15:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54FD12008A for ; Fri, 4 Aug 2017 14:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg5wX-3yqVA1 for ; Fri, 4 Aug 2017 14:15:13 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 8A924120727 for ; Fri, 4 Aug 2017 14:15:13 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id o86so12239016pfj.1 for ; Fri, 04 Aug 2017 14:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ev6DOuzOma5CyyUR/BlmWP1N6NuqFqTn5rVK1mCvSSw=; b=FCPB4OXXJBd9CGtpyNvnuqZKkJHp7rc5rDzCh7SJ5Vpm3BdKAjJSE3fS+r+FiWdTQ9 GYHQhHj9uDrjmWhuV+VTCRqWL537tspV2jsFosepJhyhZj/mazvF01Sz/CtmDufKj0Wr UG0GEBKtGSKRKK8RcIAOyk1e9KcEAB3LHB19rWCx2Ev9+cI/nDsd8/c2UIUJxuFBGdUd nWOe1+EOpuJoNHv3s0wHnwkOesfDxYASBiTjFhtxuxspqsL33zyt1EHQWKpjwKSTUzLi vRIx5y+Rz/kn16+wjunEIvfFkx7eYvKStUA7W3JjfF4myXx4e63KQIPGY78zIKNFwol1 K7cA== 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=ev6DOuzOma5CyyUR/BlmWP1N6NuqFqTn5rVK1mCvSSw=; b=W+P3fQuIdP8j/aBAs41+KtsHvmV1tISWDdRfSCWD/VaQbc/6hBsR/EDcwuRtdg9aRk 1nMFydMykSuYOrUt0a9hsWEx2jfNGUb/x9zusTL2YD08eXytutOscb+vA0um1hONsTPK 1I9JDvHfYxA3g0qKg8IOrUgVLxBkAGgAc+z7TJjDQY18/0Hl5K++QfZObxBzk+odyimy DzIxMlJEVkDt24EXCnT/ZgpQVitpML3itiY/IQeI51ZVq9ia5Tvc2dENpH/+wQBAiRq2 GUWpQXvv7YomiCgqm+XPnh77QZHO+j6FIn5W7YYFLhsv97ObdASlZbgsj8ihUO1wplKu B5/g== X-Gm-Message-State: AIVw1120Q3n3JMkjLMx8+i2LDfSJ/ewPoPsJUNA8ICZ7OPPVPcG5PDAB ElYbF5NXejghwg== X-Received: by 10.99.173.6 with SMTP id g6mr3675635pgf.1.1501881313153; Fri, 04 Aug 2017 14:15:13 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id m6sm4171817pgn.86.2017.08.04.14.15.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:15:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: <6e2efd228761483f9f6a386d32a30315@XCH15-06-11.nw.nos.boeing.com> Date: Sat, 5 Aug 2017 06:15:09 +0900 Cc: 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <2DFFF79B-BA1E-47FD-B061-94A8CFD2EDDA@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <19982cec8d46435fb3cf9c060d1c6395@XCH15-06-11.nw.nos.boeing.com> <8B55AF78-30BD-4D4C-A16F-CC9CA66F08A6@gmail.com> <6e2efd228761483f9f6a386d32a30315@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:15:15 -0000 Fine with the general consensus. But still, why not leave it open in rfc4291bis, like=E2=80=A6: =E2=80=9CThe length of the interface identifier is defined in = link-layer-specific standard track documents.=E2=80=9D PERIOD --- DY > On 5 Aug 2017, at 06:00, Manfredi, Albert E = wrote: >=20 > I think the general consensus is to keep those LLA IIDs at 64 bits. From nobody Fri Aug 4 14:23: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 C7AAE127136 for ; Fri, 4 Aug 2017 14:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 QVbBdeIrNMxN for ; Fri, 4 Aug 2017 14:23:32 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BEE12711E for ; Fri, 4 Aug 2017 14:23:32 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v189so12389258pgd.2 for ; Fri, 04 Aug 2017 14:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Ys95/GNpaDbuuIobI9p6dMcz3FZviGz4KlTTFJZytM8=; b=B8NtFEhwKfLuNS0loUTZfYIiZ0aJcIQ9UFQEji80cfUbZBH/l3nS9PZdtGHHAMj8rS kw5/VLmm15/xfSQ10NyKMAeDuoX3FqcoMw2oOLaWK/uzMzKhZ5W0cFAyAKEFy0ylbuBt PfWSwt5jKrNpl9uexz5h/SVSh2Rhl8AYWNgufyANcujjoXLwnZFC7OfllJRoSMlOXb1n OoyPbC/VcLKt1VJZnDLmt0TcnwRQrjtkid3m/b8DSzDuO4kDqNtPqFsJbS69/kUG/exP uwJ1GXLfwP/AzumbxGrl7VHR3GcuSU6Lg47qJekFUa7NvLCdUzmVyPmM1lCbB0tLUV/s th9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Ys95/GNpaDbuuIobI9p6dMcz3FZviGz4KlTTFJZytM8=; b=ZKHbZZbQ2LEwgYJeJlAgsBDn1wtx1atqAkLYy810zCGbyLEY8ZsNpORpXArcwTlsD+ JAiSMLSWthQ8c1vinoOnAyxhPaOlrSDMJWiSSaKZXdA1hv9owXV/gyNJsxfckNu1anC4 mC5RW8Xn49nXrGeQmxbITTelbdlNhwVo7IuUP35nbYscUygVPuaMYSkddcBamm6V5I+V jznDir9p+1AaGCJfutMo/93yYqR47U1Cx8lScUYljN0+ajmXuSv5MQj+ES+6pU8oPxeq Q1LNMQ2xJGZnQW8RDVOB0Px70tXi0GY5Yo4E/DVGT+gHwvb0BBSy3gJiexVLoD1KT2hK N5/A== X-Gm-Message-State: AIVw111mqJzMIjwDuVAINNK2MF6HgQI70TN7s4rw+1pafeTWkWGucDpV MSokwOLpEudeT4HGu+0= X-Received: by 10.84.225.134 with SMTP id u6mr4346025plj.176.1501881812055; Fri, 04 Aug 2017 14:23:32 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id 133sm4227719pge.29.2017.08.04.14.23.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 14:23:31 -0700 (PDT) From: DY Kim Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Date: Sat, 5 Aug 2017 06:23:28 +0900 References: <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> <20170725.080841.74682960.sthaug@nethelp.no> <42090144-DCFB-478A-AB71-8B7AC53A0A63@gmail.com> To: 6man WG In-Reply-To: <42090144-DCFB-478A-AB71-8B7AC53A0A63@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:23:34 -0000 The first line of Sec. 2.1 also says: "IPv6 addresses of all types are assigned to interfaces, not nodes." --- DY > On 4 Aug 2017, at 11:27, DY Kim wrote: >=20 > As someone has already pointed out, the following text in the = beginning of page 10 seems to be incorrect: >=20 >> | 128 bits | >> +-----------------------------------------------------------------+ >> | node address | >> +-----------------------------------------------------------------+ >=20 >=20 > I=E2=80=99d think =E2=80=98node address=E2=80=99 has to be changed to = =E2=80=98interface address=E2=80=99. >=20 > --- > DY >=20 From nobody Fri Aug 4 15:59: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 3A7F2129562 for ; Fri, 4 Aug 2017 15:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAsXmcaFEeWE for ; Fri, 4 Aug 2017 15:59:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409E2129AA0 for ; Fri, 4 Aug 2017 15:59:56 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B2F5E58C4AF for ; Sat, 5 Aug 2017 00:59:52 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9F9B6B0C7BA; Sat, 5 Aug 2017 00:59:52 +0200 (CEST) Date: Sat, 5 Aug 2017 00:59:52 +0200 From: Toerless Eckert To: ipv6@ietf.org Subject: Re: rfc6164 vs rfc4291 question Message-ID: <20170804225952.GA14972@faui40p.informatik.uni-erlangen.de> References: <20170728092328.GA4567@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170728092328.GA4567@faui40p.informatik.uni-erlangen.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:59:58 -0000 Nobody ? On Fri, Jul 28, 2017 at 11:23:28AM +0200, Toerless Eckert wrote: > Why if rfc6164 not tracked as an update to rfc4291 given how it explicitly refers > to not complying to RFC4291 specification (eg: non /64 interface identifiers) ? > > I also think to remember that one of the co-authors of rfc4291 said during prague > 6man that documents that do this should be tracked as updates of rfc4291. > > Cheers > Toerless From nobody Fri Aug 4 16:28: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 1C415129AD3 for ; Fri, 4 Aug 2017 16:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJOjSJWot44e for ; Fri, 4 Aug 2017 16:28:09 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C67129ACD for ; Fri, 4 Aug 2017 16:28:09 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id y129so13176827pgy.4 for ; Fri, 04 Aug 2017 16:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OkOxrdvi2avJOFrfgkF27r0B85YYXjR4K8dl3FSr97E=; b=ly1CRWDH0cTGBBl7FwNKnpyRWgE8VG55gLDkbGCcxLFpjYLxuFr5tpOOY5psXZlVJB Hp8y6XIC8QqjWA+YJBTuJbPXcdYCWlZ37nZ2pvPmUwyGRvZJBhbdMhnKTEKq073McC4I Er5+yFXPmTqxXGQiuUKQFxBwltjKbkM7TUFhO+zLGQHaijjokWYbDUOZSAEGp8HFFNoD vFnrT97r9eoYt0y9Pu1GBL0iEgPz7CL7OoPB8ozuWjgF7veqIccHW2pwlvozBt4KtHOI KSgAKpZ/YfP4IML+GUzFYgD7ZVV21aeiFNILpmHIIfiR09TpvTpZrdp7Vir0GF92Xenf wdxA== 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-language:content-transfer-encoding; bh=OkOxrdvi2avJOFrfgkF27r0B85YYXjR4K8dl3FSr97E=; b=Kv/fJ0EDeKMTXvyarxCK2JE8V4Ve9dnpzfrTXsCy0f5Jy4y9B8A9LmSEGZIIT+FTI0 fsGF947T2jBb9eRXagNv3WSO/mcTCzZcCP1as/53POUVGFuifXTSFawLfdjf/3BcX9A0 bc3rzQToqV/MJERPflWVbBWKXP475v7Za4s4oDcwaJfod5WHxWkSEF5t3neIXUKHMJ2n QvKedZDhdnw5CBh1LGunWxHwpyhLMlpS2yAti+lXaAtr64so0yfIYfERjcOXDdNRo7t4 W2sWVutIDUfeKxzXRFjzFex/Z5AN1Fo61kWIWb4ZRA9o5iUJsKovgd9hmVFQq2woRdeq HE/A== X-Gm-Message-State: AIVw113FGEUYZ7f19MYd+IUbNvLd5unTjzxRNIp9ZIq+6v+HpqxJ7isA w11ZhsRN6JAigQ95 X-Received: by 10.84.236.6 with SMTP id q6mr4679903plk.341.1501889288327; Fri, 04 Aug 2017 16:28:08 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 133sm4382620pge.29.2017.08.04.16.28.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 16:28:07 -0700 (PDT) Subject: Re: rfc6164 vs rfc4291 question To: Toerless Eckert References: <20170728092328.GA4567@faui40p.informatik.uni-erlangen.de> <20170804225952.GA14972@faui40p.informatik.uni-erlangen.de> Cc: ipv6@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <2009e3b9-39ad-6f5a-5864-4e475ce9d8d9@gmail.com> Date: Sat, 5 Aug 2017 11:28:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170804225952.GA14972@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 23:28:11 -0000 If you think it's an error in RFC6164, you should report it: https://www.rfc-editor.org/errata.php#reportnew It's an interesting question whether, if such an erratum is accepted, the RFC Editor would then update the metadata for RFC4291. However, if we manage to get rfc4291bis out, the issue will be resolved anyway. Regards Brian On 05/08/2017 10:59, Toerless Eckert wrote: > Nobody ? > > On Fri, Jul 28, 2017 at 11:23:28AM +0200, Toerless Eckert wrote: >> Why if rfc6164 not tracked as an update to rfc4291 given how it explicitly refers >> to not complying to RFC4291 specification (eg: non /64 interface identifiers) ? >> >> I also think to remember that one of the co-authors of rfc4291 said during prague >> 6man that documents that do this should be tracked as updates of rfc4291. >> >> Cheers >> Toerless > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Aug 4 16: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 D9579129AEB for ; Fri, 4 Aug 2017 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuizpKIL2liN for ; Fri, 4 Aug 2017 16:34:40 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CE2129B26 for ; Fri, 4 Aug 2017 16:34:31 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id u185so13251401pgb.1 for ; Fri, 04 Aug 2017 16:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ah4NRK2MBqPYBUNp0upX2RdqkCwBVU76fxtVmRSjFWk=; b=jy1sLwFxvqOTc2JAiWclYi8Q4dGfzPHt9n/g3DY4UDgLXy+3M4k+l02KMXgDUC71d9 8JHMAyiYZwJ68jfkwFtT8R3nykjuuJm5NqGq2ezjF2bkffttc3y69ELHuNSRPJvIrbOg pAz0Ep36yeWlXpL5gTk1mX/P0sVso5BJ3PrY8lSvPIIn9aFDdVYh/cnJEJE7vV5QtZwU 7owpbdHx/KAKno34Svt7jllpcerWl+Z0I9K4r9L+JQ/39HUeYw307hJxg9AEJ8akbn5o mNZX15WHPmS4cs3zbYlYR1rF/O91Yux53TImeI1Bl6y/5sOCPHYOcdQG3LrBfKT3Q1mE 1AEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Ah4NRK2MBqPYBUNp0upX2RdqkCwBVU76fxtVmRSjFWk=; b=Q59EWEiIj7OpskX0gzun6kU6UG9XSWm6lY20Ngh3UPk7t5HxcB4C57FS7LJgZdWau6 DWImlCuIcTxz7vY9FqbhRcqkIT3kHqe6wG4r13RRHuY7MerpkH9W2stY4WYwSD+Ezmle p1GXjjQFrTE5mHdllvUfFYC3CTXB/hP5xGnUIHCV0RV0XbV344bGTghhSiZQfVLsbZok uC9rGPOh/xmPMtLw5LUcT1/xIDPsjzyOeioM5+/SXYyIxZJ2dkJcTH6Ad6sDJGcNMYjs KuxgbpopuFRKylmetyjCiW7PwkTsiArJUc7jrOcXBTvYfzcaLR20yKQ3lVTLEIwDAvty Xx0g== X-Gm-Message-State: AIVw111pVR5OiFjMXknLapAc461q1w35ZaZOm2JPJ7x6ToM/D7ycjYWw fDgOEFxrzuAyqQ93 X-Received: by 10.99.96.148 with SMTP id u142mr3924463pgb.16.1501889670944; Fri, 04 Aug 2017 16:34:30 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q88sm4701632pfk.8.2017.08.04.16.34.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 16:34:30 -0700 (PDT) Subject: Re: Section 2.4 of rfc4291bis To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man WG References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> Date: Sat, 5 Aug 2017 11:34:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 23:34:42 -0000 On 05/08/2017 08:34, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Sat, 5 Aug 2017 05:19:59 +0900, > DY Kim wrote: >=20 >> OK. Let=E2=80=99s pin down two points: >> >> o SLAAC is agnostic to the length of IID. >> o Explicit definition on the length of IID are with other standard t= rack documents. >=20 > You can't ignore this: >=20 > o RFC4291 and rfc4291bis also say the length of IID is 64 bits for > some set of IPv6 addresses. >=20 > Reconciling the 2nd and 3rd points would be quite tricky, and that's > one main reason why I don't think "what's the primary definition" is > so obvious. So... >=20 >> Then, why not simply state as such in rfc4291bis like, e.g.: >> >> =E2=80=9CThe length of the interface identifier is defined in link-la= yer-specific standard track documents.=E2=80=9D PERIOD, >=20 > ...it can't be that simple anyway. In addition, (in my understanding) > because it's too substantial a change from RFC4291. rfc4291bis is > basically an attempt of elevating the original RFC to an Internet > Standard, so, in general, we can only make clarifications or minor > changes. Correct. That's why I most recently suggested: "Interface Identifiers are 64 bits long when used for Stateless Address Autoconfiguration (SLAAC) [RFC4862]." That's a statement of fact. IMNSHO anything more than that is basically noise, in terms of rough consensus and running code. =20 > From a purely technical point of view, such a change can be a subject > of discussion. IIRC some people have actually proposed ideas like > that. But this won't be in the scope of rfc4291bis. Correct. Brian From nobody Fri Aug 4 17: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 7F184129B14 for ; Fri, 4 Aug 2017 17:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG5n0gAM_Tjk for ; Fri, 4 Aug 2017 17:19:59 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687D3129AEB for ; Fri, 4 Aug 2017 17:19:59 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id d29so13423194uai.2 for ; Fri, 04 Aug 2017 17:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X/q6IFRoG9R1vZXmY/KLEFu0rlgJ8jNIfAviDaIZXBk=; b=UWaCinUFROU71eEVRo/xCCInD5KhX/GbFQ3jmd5fk24vIiTBCzZK3HdTfUxh/l7GYa dFQztolj4O/tfWV9cSQO0W15vQs0QPPpE4H9GZHOqX1Tbti0yKyYB7XrsTSP+0yAEq6e m/Xz9jAe2BEQfAg9ZIp27F7ScJGCiZ7FRyvIXZmH/1Gm0dLQudJxNazOti6cw+fawJJN jpkC91CJfBqKsefb0SdfMNU6ad/YQ5p+jE+3pSYiDaimxKOrGl4KM8etkSbxRZrVoqGa 3iukjsTEnU7vPUhX+cTCeSzei9/Vg20dkPshBTuvDQKGwFZAllaoOuHJ/hiAQBVNq8O1 nD/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=X/q6IFRoG9R1vZXmY/KLEFu0rlgJ8jNIfAviDaIZXBk=; b=bEt7TeU7i333hTC6hPmOgc3LzQQ58llOxudQ7AH+6tMJp0dm418otoC6zux3gHHOnQ p251fnkWfQima9o4zxplF7t4Ndm0zGnh2yEnLjD3hZrhvahKoJfMDpnBCDXFDiDfqMSZ sb/qrj2LwwJ1Ib+rjFusXKg4MUQz0i4ESUr25k/nCmCgn2Y6dM00BDYPpHxdBgssmrOr iHV5QtPGK67zuZm+49bLoimJdzO36IMslF+AVYNKcOmsk7VPXCEMG81gZ2i5IT8uUzn8 hjNZQPmtziFOWjkLqMNVsSkhjooLA7U8xwahsbygSvgACfh/cLT5S8iyuDQKo30J/qlY NlvQ== X-Gm-Message-State: AHYfb5jHraX66Ej6hcoLvmvp3UCw6z59CNoCYT35l84CHim2BKtf5OIS CrK2UU72Yh0Q8ZSH9e0WqbIgLhLGHQ== X-Received: by 10.176.8.81 with SMTP id b17mr3104758uaf.82.1501892398502; Fri, 04 Aug 2017 17:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 17:19:57 -0700 (PDT) Received: by 10.176.18.105 with HTTP; Fri, 4 Aug 2017 17:19:57 -0700 (PDT) In-Reply-To: <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5AB14F48-2799-4A86-830D-E8A89CCADAAC@gmail.com> <596F63F4.9010501@foobar.org> <69a7f9f2-584e-a2bc-1200-64fad8f9baf7@gmail.com> <652efa7dcb414b7ba6128bb4f93a3d7e@XCH15-06-11.nw.nos.boeing.com> <4f91c2f03b3a4af2941e4c8ceb29ed25@XCH15-06-11.nw.nos.boeing.com> <2953666cc36f499199dbbd458fdb43c0@XCH15-06-11.nw.nos.boeing.com> From: Mark Smith Date: Sat, 5 Aug 2017 10:19:57 +1000 Message-ID: Subject: RE: To: "Manfredi, Albert E" Cc: David Farmer , 6man WG Content-Type: multipart/alternative; boundary="f403045f8e20e757b70555f692dc" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 00:20:02 -0000 --f403045f8e20e757b70555f692dc Content-Type: text/plain; charset="UTF-8" On 25 Jul. 2017 06:18, "Manfredi, Albert E" wrote: From: David Farmer [mailto:farmer@umn.edu] > What? Yes it says they are 64bits, but it is just referencing RFC 3513, > which is what I would expect it to do, which is the predecessor of RFC 4291. Agreed. These two RFCs do not differ, in regards to requiring 64 bits, *and* EUI-64 in particular. > If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so is > RFC 3513 and RFC 4193 too. No, RFC 4291 is agnostic on SLAAC IID length. It refers the reader to whatever IPv6-over-foo RFC, for IID length and formulation. But RFC 4193 (ULA) seems more insistent that it must be 64 bits and EUI-64. After all, as specific as RFC 4193 is on how to create ULA prefixes, there's no other option than 64-bit IIDs, for ULAs. What I am saying is that 6man seems to have come to an agreement that SLAAC should be restricted to using 64-bit IIDs. This SLAAC restriction is not directly related to RFCs 2464, 4291, or 4862, because these all mandated EUI-64. Still, we seem to want 64-bit IIDs mandatory for SLAAC. Why? Because we want 64-bit IIDs to be the "default" and "recommended" length, and because we figure that SLAAC will be the most popular way of forming IPv6 addresses. So, if RFC 4291-bis wants to state as much, that's okay with me. I think the IID length rules can be considerably simplified, compared with the "exceptions" listed in RFC 4291. Instead of "exceptions" to the 64-bit hard boundary, list the cases where it applies. SLAAC mostly, maybe a mention of Ethernet LLAs (although subject to update of RFC 2464), and ULAs. Just trying to be consistent here. Look at RFC8064, the list of Foo-over- IPv6 RFCs that it updates all generate 64 bit IIDs. We simplify in computing by generalising and by reducing or avoiding exceptions. Simplicity makes things more robust, as there is less opportunity for faults to occur (e.g., coding bugs, misconfiguration, unexpected function or system interaction). Tying IID size to specific link layers or specific address configuration methods is increasing complexity, not reducing it. What justifies this increased complexity? I don't think "because that's how IPv4 worked" does. IPv4 is complex (e.g. classes, subnets) because there weren't enough addressing bits. (People may not be aware, the first IPv4 address structure was a simple N.H.H.H format. Classes were introduced between RFC760 and RFC791 because they were going to run out of network numbers and couldn't increase the size of the IPv4 address.) Regards, Mark. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --f403045f8e20e757b70555f692dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 25 Jul. 2017 06:18, "Manfredi, Albert E" <albert.e.manfredi@boeing.com&g= t; wrote:
From: David Farm= er [mailto:farmer@umn.edu]

> What? Yes it says they are 64bits, but it is just referencing RFC 3513= ,
> which is what I would expect it to do, which is the predecessor of RFC= 4291.

Agreed. These two RFCs do not differ, in regards to requiring 64 bits= , *and* EUI-64 in particular.

> If you think RFC 4291 is really saying SLAAC IIDs are 64 bits then so = is
> RFC 3513 and RFC 4193 too.

No, RFC 4291 is agnostic on SLAAC IID length. It refers the reader to= whatever IPv6-over-foo RFC, for IID length and formulation. But RFC 4193 (= ULA) seems more insistent that it must be 64 bits and EUI-64. After all, as= specific as RFC 4193 is on how to create ULA prefixes, there's no othe= r option than 64-bit IIDs, for ULAs.

What I am saying is that 6man seems to have come to an agreement that SLAAC= should be restricted to using 64-bit IIDs.

This SLAAC restriction is not directly related to RFCs 2464, 4291, or 4862,= because these all mandated EUI-64. Still, we seem to want 64-bit IIDs mand= atory for SLAAC. Why? Because we want 64-bit IIDs to be the "default&q= uot; and "recommended" length, and because we figure that SLAAC w= ill be the most popular way of forming IPv6 addresses.

So, if RFC 4291-bis wants to state as much, that's okay with me.

I think the IID length rules can be considerably simplified, compared with = the "exceptions" listed in RFC 4291. Instead of "exceptions&= quot; to the 64-bit hard boundary, list the cases where it applies. SLAAC m= ostly, maybe a mention of Ethernet LLAs (although subject to update of RFC = 2464), and ULAs. Just trying to be consistent here.
<= /div>

Look at RFC8064, t= he list of Foo-over- IPv6 RFCs that it updates all generate 64 bit IIDs.=C2= =A0

We simplify in compu= ting by generalising and by reducing or avoiding exceptions. Simplicity mak= es things more robust, as there is less opportunity for faults to occur (e.= g., coding bugs, misconfiguration, unexpected function or system interactio= n).

Tying IID size to sp= ecific link layers or specific address configuration methods is increasing = complexity, not reducing it. What justifies this increased complexity? I do= n't think "because that's how IPv4 worked" does. IPv4 is = complex (e.g. classes, subnets) because there weren't enough addressing= bits.

(People may not b= e aware, the first IPv4 address structure was a simple N.H.H.H format. Clas= ses were introduced between RFC760 and RFC791 because they were going to ru= n out of network numbers and couldn't increase the size of the IPv4 add= ress.)


Regards,
Mark.


Bert

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

--f403045f8e20e757b70555f692dc-- From nobody Fri Aug 4 19:19: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 1E8D5126B6D for ; Fri, 4 Aug 2017 19:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nQjntJZTyhZk for ; Fri, 4 Aug 2017 19:19:40 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4639124B18 for ; Fri, 4 Aug 2017 19:19:39 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z18so17923635qka.4 for ; Fri, 04 Aug 2017 19:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3XywqYHCHVeKFMhSjtezcibipXJWy7iJHhn4v0qxpms=; b=c8/Nvk4hIlCEmvgq7WO8rNwRef2icWdhrcb7W65xgKECGFDa1CvXToWc++3AC5tOmi xFalcFodMd0JMk2XIFKx8jsgdM1IcPF8FnFUZ0GXfkH3ecIRPWx4xo7X0id9s6B+vGzy gvpvRGC1+pP0x8ud6FHaGagmuOOCbjVQuDr2DEg7rJom1iaqcNfDfeFj91tmHmN3oHk0 9Qf0KXZjspz2Fe57eLtMNL7GkjSFuEMd12q86DzQ1UEsMVethrCMa4eE7V3SkcC9xKuF zaO5L58aaMRuZIP78gJLqZvdFpEZ4UF47FdnHPhfQpfRpw9MBuhlWv5FdYYshkO20kJ+ fCEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3XywqYHCHVeKFMhSjtezcibipXJWy7iJHhn4v0qxpms=; b=GIL9Q6k7xuFBS/LPOa65vEuEX9OQteKsX1cYTRFzN8lT3l7h/8e8k0m6sMkv/UZe0u kJmgQ4LVd4QMPYp5rlV9Xaz7i5/iZf6GP7+/eGxi4itFPlv/1DrYBVro4oDlvW/xxKg1 oJ2jahqUobgRO6gFIvItyMo+JZn2LF7OLdGenrmZJQpJ4X4qM6h9q1BiI2btMLTqZ3C/ RG1nlc6Zm9YLfvPDIrNNB+9NaO2OUKl9UCeWp2T6CRm1a2y+NAaJnFI1iPNWWDcr3rtw gAiP8O7ii4Qb5Qn812AKh5oGYzts2mDJCjYcaAjddO9RG9hjijqU4kqavUQFGlwcxTNZ jQ7g== X-Gm-Message-State: AHYfb5hx3wT2kcrhLCYZLGW9A9yy4rN2arTTOMvAtKsfhFpMGdKS1Cfp rCg1GKQ4R/SaWUbPgMVHQ2nw62oURA== X-Received: by 10.55.46.196 with SMTP id u187mr5762616qkh.156.1501899578736; Fri, 04 Aug 2017 19:19:38 -0700 (PDT) MIME-Version: 1.0 References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> In-Reply-To: <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> From: DY Kim Date: Sat, 05 Aug 2017 02:19:27 +0000 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Brian E Carpenter , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man WG Content-Type: multipart/alternative; boundary="001a114f5f8ae106860555f83ed0" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 02:19:41 -0000 --001a114f5f8ae106860555f83ed0 Content-Type: text/plain; charset="UTF-8" On Sat, 5 Aug 2017 at 08:34 Brian E Carpenter > > Correct. That's why I most recently suggested: > > "Interface Identifiers are 64 bits long when used for Stateless > Address Autoconfiguration (SLAAC) [RFC4862]." > Why do you have to mention SLAAC at all here? It will by itself generate 64 bit IIDs based on other link-layer-specific standard track documents, without necessarily resorting to 4291bis. 4291bis just can leave any more details of IID to SLAAC and other std track docs. -- DY --001a114f5f8ae106860555f83ed0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, 5 Aug 2017 at 08:34 Brian = E Carpenter <brian.e.carp= enter@gmail.com>

Correct. That's why I most recently suggested:

"Interface Identifiers are 64 bits long when used for Stateless
Address Autoconfiguration (SLAAC) [RFC4862]."
Why do you have to mention SLAAC= at all here? It will by itself generate 64 bit IIDs based on other link-la= yer-specific standard track documents, without necessarily resorting to 429= 1bis.

4291bis just can l= eave any more details of IID to SLAAC and other std track docs.

--
DY
--001a114f5f8ae106860555f83ed0-- From nobody Fri Aug 4 20:04: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 5F393129B5E for ; Fri, 4 Aug 2017 20:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 0gvmu9BDrvnx for ; Fri, 4 Aug 2017 20:04:37 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B620A128D86 for ; Fri, 4 Aug 2017 20:04:37 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id u185so14403724pgb.1 for ; Fri, 04 Aug 2017 20:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DNig7G/Wq3UL6N834Mxm9nM52/kzRkjsDyiqLy1mgrY=; b=h6hoAFwyHfNwdyDcpNm9EuMR3n0nA3q1pgOIqvNM11jaRVpgi+xkwbomxNpu2GdK0G 3BZ9dKFlAt9NUzYSnVO1pwXdrK4R6brZXrkDfXVb+XEoMX4oxUTNGcJN5rOPVYDT7WJf W2D5NonKJ2Kmf9CbF9G8PfvUeXSCRrk7XY3HZRMP/WZ9ACVfXGL3ejzunrNB9hCYKw+W xUF8EGRieo9MhW/HlPDGYaoQvUd/ajv4OOHYA60eHQrIMF0GC6DoLUDxpvbI9hrf531x O4wHqmNwpf3R8+VLsVd6NboG7nr3wmBEYyXzqwViOzWdPF5qn0tklJqVpm6H0GCz7KjY OioA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=DNig7G/Wq3UL6N834Mxm9nM52/kzRkjsDyiqLy1mgrY=; b=D11IYSUS+CWZInIHJksLCoi2MmP1Pa6ib+XL7y+8a9uor9yFIKP2esiKNWNQHNjgvJ Ipirb2AzLszld0B7h96djJmmiV7zbhIpYrR86bwM9anNPS9PeK5LFpk4lLcEqZhkjxda zrQSuaw9Wc3yE3pyIPb5BD8wVcckpPn3Pm6Xdto2n9gQbzwuOU5AjE7ZE0VVIeXfm0Ov 1+9s2c7PPv28mranqetmswR3VavZglttDpDD8y/xCDlHPcKJGhWubYrt+fbn8vOsdwzK IBPzYYYNp7i8b5AZnWY60DK5/KD0N33cJOcQsSWciaJmbRvvfZH9LzdX9qlFPYPfDcYK i29Q== X-Gm-Message-State: AIVw111NJMgTlc//tjWvotQz7Ptx3osahTiFjryckFJFqoVpasXnn4Ue QbFP5xtBXMsvzVhL X-Received: by 10.84.241.70 with SMTP id u6mr5192225plm.96.1501902276975; Fri, 04 Aug 2017 20:04:36 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g67sm5633322pfe.104.2017.08.04.20.04.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 20:04:35 -0700 (PDT) Subject: Re: Section 2.4 of rfc4291bis To: DY Kim , =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: 6man WG References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> Date: Sat, 5 Aug 2017 15:04:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 03:04:40 -0000 On 05/08/2017 14:19, DY Kim wrote: > On Sat, 5 Aug 2017 at 08:34 Brian E Carpenter > >> >> Correct. That's why I most recently suggested: >> >> "Interface Identifiers are 64 bits long when used for Stateless >> Address Autoconfiguration (SLAAC) [RFC4862]." >> > Why do you have to mention SLAAC at all here? 1) Because it is a fact that SLAAC today uses 64 bit IIDs, and the purpose of a full Internet Standard is to define precisely the solution that has been proved to work by widely deployed running code. 2) Because there is no need to define a globally fixed IID length for other methods of address generation. (Yes, there is an alternative - to say nothing about the length in 4291bis, and define it either in a 4862bis or a completely separate document, but that seems like more work for no gain. The result will be the same whatever we do: SLAAC will continue to use 64 bit IIDs, and nobody will change a thing in their software or configurations.) Brian From nobody Fri Aug 4 21:25: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 D89FF12EB99 for ; Fri, 4 Aug 2017 21:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 honqyF8IwW6H for ; Fri, 4 Aug 2017 21:25:01 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9030E12DDD0 for ; Fri, 4 Aug 2017 21:25:01 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id u5so14859609pgn.0 for ; Fri, 04 Aug 2017 21:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mhz3VN8gQio1cuq4bCxn9g/BP6N5rJ6Bo8vjpn656Vg=; b=VRrmDUK7dHdqQumHeA39W41ItxclCY9nSXsc/TYcPLbHDbxLYNo4YNzH2tYDyYqSmX Y3us1o5vXbZ6lQrGu8GTeHrT4rl0seF7QrXBJJHk6vwnBTL3gm/pNXIRysN2K2+/Eu6x s/efvu9zUoCXX5Z9rxhxkOC3+1TdZrjCVQBTGPyFxCyUC4AM9ZH99b2mBa3oy6oFIEdG VtYNhb42uSk250SwYtxxkwYTx1pou6y7eTkUjE2jTUrhyBhRfASGjsuXaElfdCMruW42 F55eyk4Z/4pZwTAs4/Jnm6suvFIgRiKbwzS2IIq3766RyRGAHICSebfO+Zs5EQGbPcCz QgpA== 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=mhz3VN8gQio1cuq4bCxn9g/BP6N5rJ6Bo8vjpn656Vg=; b=hGBPZobuo+PhRPYJdrgIE7QmV4AwvpvapR3q0kMuZBpudv5qdYd4ThstPo+DANHNMa UakbmAbdwYupGH8R5ayDw1eagmA05z9gNJKPIX2Ja6Ya0/1cRPpzH/bAwqseMGAcjsBq tc5owPaxksPfL2fHnDCqf7wUUIZn8U6Of77HSQChwftnaxcixi/OCRM7iWwMH60JVaff 4entip8hCH/D+hGkzvHE8nOTCr18SnrFxwuOwuhpZLS95F6IZpiORgtgR55ElFK0tgGn 8W1+VdKXZdYxs3ElPWIiZEYSrBmkjx6B8AaN7yAB/BUcvVBFmZ2dtiiSB/WHb2OuwSV4 sMCQ== X-Gm-Message-State: AIVw111BxqXta1LlFy6qc4MHGBnVdiLw2sGBkQ2UB3Sg14y+G4n8QnHy PYuWnk/LbLY65+ni5sg= X-Received: by 10.99.117.90 with SMTP id f26mr4502841pgn.441.1501907100991; Fri, 04 Aug 2017 21:25:00 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id q79sm7046102pfi.99.2017.08.04.21.24.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 21:24:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> Date: Sat, 5 Aug 2017 13:24:56 +0900 Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 04:25:03 -0000 =E2=80=98Architecture=E2=80=99 of any kind by nature should deal with = the generic part of the matter, leaving implementation specifics to = companion protocol specs. It is taken that the community consensus is to use 64 bits IID for = SLAAC, no objection to that. However, =E2=80=98architecture=E2=80=99 should not indulge into that = implementation specifics, and, to the same effect as you note, SLAAC and = other link-layer-specific standard track documents will take good care = so that only prefixes of length 64 will be accepted by SLAAC and IIDs of = the same length would be generated. =E2=80=98Architecture=E2=80=99 is a parent/reference document and should = not rely on any implementation specific children specs like SLAAC. I do think it=E2=80=99s enough to state in 4291bis =E2=80=9CThe length of the interface identifiers are defined in = separate link-layer-specific standard track document.=E2=80=9D to the same implementation effect you=E2=80=99re concerned about. --- DY > On 5 Aug 2017, at 12:04, Brian E Carpenter = wrote: >=20 > 1) Because it is a fact that SLAAC today uses 64 bit IIDs, and the = purpose of > a full Internet Standard is to define precisely the solution that has = been > proved to work by widely deployed running code. >=20 > 2) Because there is no need to define a globally fixed IID length for = other > methods of address generation. >=20 > (Yes, there is an alternative - to say nothing about the length in = 4291bis, > and define it either in a 4862bis or a completely separate document, = but > that seems like more work for no gain. The result will be the same = whatever > we do: SLAAC will continue to use 64 bit IIDs, and nobody will change = a thing > in their software or configurations.) From nobody Fri Aug 4 21:37: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 306DC12EC11 for ; Fri, 4 Aug 2017 21:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xair57VKDQ4E for ; Fri, 4 Aug 2017 21:37:55 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0224812EAE8 for ; Fri, 4 Aug 2017 21:37:54 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id v189so14915908pgd.2 for ; Fri, 04 Aug 2017 21:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aGj2pnZel4FNzSRw0aIB6xL2q43sY5Vb+k3mJg77JZg=; b=chkoqpMMhdnbsnTlg9c3OmIYc+6M+Mc6mNIoNKORWqtewvT+xVWVEYi1MjjC1HeLtb TT2VV6ftJTSQGHZ9E0aV761Y+HlODi2F0dm48NwpNcQd4BG1Uk9CVsu8MvCdSH7w9LbY Ujp10DHF6Tq+Jva+XmnHtUl2cqVo9ds3ZfLNhoJVAWZCdZlBdJVz6nFhc93yH2uyb72E NFcYhzVsAqA6tcZ6w1aRBZVhbhVuXWqQcFd8eJXQUCdKYECb5AT7zpNZEMgkLJhJlFHU tkMH30X/FLwxfJU8GuqgnT31JF71x4/MXgNt1JKF2IdzLCm3yJksFtuyPhI/0fLZju5h bYjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=aGj2pnZel4FNzSRw0aIB6xL2q43sY5Vb+k3mJg77JZg=; b=MGEWtDnvFCWy73IYNAlXt5qAd+pSRHro75UZIr88bATvMmonptsCilGYnGQpQH42Eg TGuoMB3EvAFZBxH4pmtg8wRCivYxCv2E+eLAlZLnxh20fnFm6GFHqNH9HuzxDYSbXvX8 mTYql8egERYmYIy6lp6973WK5NmFxPVuUCaH2ezIoeZLnd4U2gPHLdWiTB/Eky0Umqqe 3e61Ai7CXaf0+Y4PuYwJjCkot/ZE0HzxHh025AakMdAsN8G55G2Rc9GG747B159MoRxO cGjnLGYziXxazFFQWHOo09JqQXwCrD1AAroPJ1mapozCIeqaq3QZYy1fSCv9sriVXo52 FFFA== X-Gm-Message-State: AIVw110eE1qO+UuhdCr6so+ra24uLIdndk+YU6GzLyd++b8+Fw0FcEMP nJxUXsDYShrJMvpS X-Received: by 10.99.9.69 with SMTP id 66mr4439487pgj.178.1501907874273; Fri, 04 Aug 2017 21:37:54 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t64sm5011826pgd.80.2017.08.04.21.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 21:37:53 -0700 (PDT) Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , 6man WG References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> Date: Sat, 5 Aug 2017 16:38:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 04:37:58 -0000 On 05/08/2017 16:24, DY Kim wrote: > =E2=80=98Architecture=E2=80=99 of any kind by nature should deal with t= he generic part of the matter, leaving implementation specifics to compan= ion protocol specs. >=20 > It is taken that the community consensus is to use 64 bits IID for SLAA= C, no objection to that. >=20 > However, =E2=80=98architecture=E2=80=99 should not indulge into that im= plementation specifics, and, to the same effect as you note, SLAAC and ot= her link-layer-specific standard track documents will take good care so t= hat only prefixes of length 64 will be accepted by SLAAC and IIDs of the = same length would be generated. >=20 > =E2=80=98Architecture=E2=80=99 is a parent/reference document and shoul= d not rely on any implementation specific children specs like SLAAC. >=20 > I do think it=E2=80=99s enough to state in 4291bis >=20 > =E2=80=9CThe length of the interface identifiers are defined in separ= ate link-layer-specific standard track document.=E2=80=9D >=20 > to the same implementation effect you=E2=80=99re concerned about. In theory I agree with that, but we didn't reach consensus on that approa= ch when it was proposed some months ago. I'm hoping we can reach rough conse= nsus on something, sometime. Brian >=20 > --- > DY >=20 >=20 >> On 5 Aug 2017, at 12:04, Brian E Carpenter wrote: >> >> 1) Because it is a fact that SLAAC today uses 64 bit IIDs, and the pur= pose of >> a full Internet Standard is to define precisely the solution that has = been >> proved to work by widely deployed running code. >> >> 2) Because there is no need to define a globally fixed IID length for = other >> methods of address generation. >> >> (Yes, there is an alternative - to say nothing about the length in 429= 1bis, >> and define it either in a 4862bis or a completely separate document, b= ut >> that seems like more work for no gain. The result will be the same wha= tever >> we do: SLAAC will continue to use 64 bit IIDs, and nobody will change = a thing >> in their software or configurations.) >=20 >=20 From nobody Fri Aug 4 23: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 CABAC12F287 for ; Fri, 4 Aug 2017 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 SfHXJirGvpt9 for ; Fri, 4 Aug 2017 23:53:56 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC29126BF3 for ; Fri, 4 Aug 2017 23:53:56 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id h75so3799873pfh.5 for ; Fri, 04 Aug 2017 23:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rYDrau+tZypNnJLjE8zC0R6IndzOtkGullJWfNyUkSk=; b=MMszSbHWH4bFW9dEt3h7awPJnN5enI58r7TO6i8h9OsRUoVEDArHRKzxETKWv5Y2R3 5ijnNR0feTQAdrhWtw6SFhILz1vQ5AgLtt6+VTs/9u+8FNQwYZpZxIL5MlMSpQEkZdOx KWGP4H3QqYo9aszNPUuYb+8XSEa2KEJz7o8JkH3due/fnFeT6w1kcXfr3GvWcPzRTxo8 GqJ+gK1V1ZmD0gxv6DKTZDQ40GQ8oCJ2Dx58w9GlPAftilSEefmHDtHzENPwzGrcnGLw QaaIzwMMnN9U5/tBpmui6Q59QvCp5hu4nu9E8OSDThbplZcH9b2XvjcLH6QLnIXOm0h7 8TMw== 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=rYDrau+tZypNnJLjE8zC0R6IndzOtkGullJWfNyUkSk=; b=eFa5GJ5bqiyIZu99SVtjGMarmpiSgtAUe3VtEaQkXVCAP5keMx2VbC3PilvnfcJe/A FMEgYoUKjcKNCPsyobs8sXxzQuPvjl3fgXSnfE6jZs9XnDjDYoG6mK6IBAvou4TPs1Km 65aFUrs7I8W2sxBzcY0cU1m9D7kje/SSbUFf9rDI5eMYmfcOHABzw6hWMAn8F27suJA5 LOH7LKW1VslvHSnT6JoFwDV1Yvz4ZQziNfVEY0k/vy8PNKzZrXwZpX2OwcFM2cqRHA0T T9tvo8hvMxJ/ZdMLM0N6OKEWkL67l4rtbgnBxMJv7uX8QmnNRRL2kZ7gloYtIhc4JgUy sifA== X-Gm-Message-State: AIVw112bzeE6dm32kQmOm19dqjH1Tju5v5dPF1RtUPhLIAXJNgVq2XWj LH0HZ2j8BziuHg== X-Received: by 10.99.111.132 with SMTP id k126mr4739083pgc.76.1501916036200; Fri, 04 Aug 2017 23:53:56 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id l5sm5735063pfg.50.2017.08.04.23.53.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 23:53:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> Date: Sat, 5 Aug 2017 15:53:51 +0900 Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 06:53:58 -0000 This is indeed very regretful. So long as the document is addressing = =E2=80=98architecture=E2=80=99, addresses (or part thereof) (A) should = best be described independently of the way (B) they are generated. B = surely should be subject to A, but not the other way around. The logical = relation should be unidirectional (A -> B), not looped bidirectional (A = <-> B). If the two are bidirectionally looped, the next immediate question = should be 'which overrides the other?' Now that they are loop-linked, = none of which, or both are equal=E2=80=A6 confusion,... logical fallacy. This logical fallacy, I=E2=80=99d think, might be one of the sources of = reasons for the endless debates on this list in regard to the IID = length. It=E2=80=99d be my last intention ever to represent any of the two = camps, but before any debates I=E2=80=99d hope the group acknowledge = that the document in this specific part is subject to logical fallacy, = lacking in logical integrity. Before anything, one might clean up the = text, fist of all, I=E2=80=99d hope. --- DY > On 5 Aug 2017, at 13:38, Brian E Carpenter = wrote: >=20 > On 05/08/2017 16:24, DY Kim wrote: >> =E2=80=98Architecture=E2=80=99 of any kind by nature should deal with = the generic part of the matter, leaving implementation specifics to = companion protocol specs. >>=20 >> It is taken that the community consensus is to use 64 bits IID for = SLAAC, no objection to that. >>=20 >> However, =E2=80=98architecture=E2=80=99 should not indulge into that = implementation specifics, and, to the same effect as you note, SLAAC and = other link-layer-specific standard track documents will take good care = so that only prefixes of length 64 will be accepted by SLAAC and IIDs of = the same length would be generated. >>=20 >> =E2=80=98Architecture=E2=80=99 is a parent/reference document and = should not rely on any implementation specific children specs like = SLAAC. >>=20 >> I do think it=E2=80=99s enough to state in 4291bis >>=20 >> =E2=80=9CThe length of the interface identifiers are defined in = separate link-layer-specific standard track document.=E2=80=9D >>=20 >> to the same implementation effect you=E2=80=99re concerned about. >=20 > In theory I agree with that, but we didn't reach consensus on that = approach > when it was proposed some months ago. I'm hoping we can reach rough = consensus > on something, sometime. >=20 > Brian >=20 >>=20 >> --- >> DY >>=20 >>=20 >>> On 5 Aug 2017, at 12:04, Brian E Carpenter = wrote: >>>=20 >>> 1) Because it is a fact that SLAAC today uses 64 bit IIDs, and the = purpose of >>> a full Internet Standard is to define precisely the solution that = has been >>> proved to work by widely deployed running code. >>>=20 >>> 2) Because there is no need to define a globally fixed IID length = for other >>> methods of address generation. >>>=20 >>> (Yes, there is an alternative - to say nothing about the length in = 4291bis, >>> and define it either in a 4862bis or a completely separate document, = but >>> that seems like more work for no gain. The result will be the same = whatever >>> we do: SLAAC will continue to use 64 bit IIDs, and nobody will = change a thing >>> in their software or configurations.) From nobody Sun Aug 6 16:07:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1632131EB8 for ; Sun, 6 Aug 2017 16:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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_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 AyY6KbKnSlnY for ; Sun, 6 Aug 2017 16:07:34 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA25120720 for ; Sun, 6 Aug 2017 16:07:34 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v189so26871553pgd.2 for ; Sun, 06 Aug 2017 16:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R1w+rpHJIi5znm6V6gKjch36eobDJxVzQZZLdXviJl8=; b=nmBOps+WwUzHZgviTXURkK+f5+5bPie+l3odrRI8ic+E8jRmJza1nCaStHilkoVvlL NdaIcrYm2bW6so/vYDZeAlovF9SgzxuGFKnmUMAZ0jiH3xjffm1pdlvpsYST6oxVILtX oeOXmti5NT/MjE8j0ZtPrsYSsklOuusOmDf8IppFDpKu1sB4jf0/uL9U1jxQ60O784Ej kpF7UQv+B/llXL+TDHm7Sk3KA0JwfPi/oLqRfHt9sBOlRAEXwvrHVheW93hsdV69rEI5 RfqGgcoj5dPZkaH7TvPz/GvGKYFi9SPJ09zRmlAQkSFX+JwEjpM/TnVy0t5I5/un/N2E C0FQ== 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=R1w+rpHJIi5znm6V6gKjch36eobDJxVzQZZLdXviJl8=; b=DeyIIY5AtH6QQ5FSyjT8KTfDQd7iBuB2D0/gU8RmesYg+edrncoUeBJ88ACB9BaX4i TtYPyyvQMaRXi419h9CPaxkWI+8b/MW5vVF1ns78mJax4A+WzuKD5kjyYCrDl2fjKn0M E8aFjgTekwgVu6xff/sHftzUC7ZvfawQQSnqDioZXf9n7FNnCushgmlSMtYSUAl0gE/T Xv4bJtkJfA6gAbr4G56+cOy7+Kb00LRk5g8JehKmZ7u1P0BtRHxilF7dWb424DZt2GmP ru3THB+EDzV1zT8YTPBVGvf7R64zVdNdXBGbMxqNeu22p8I1qABn0V9UG0ymuKI1Ufwo SadQ== X-Gm-Message-State: AIVw110b6uytEM0u64uhJ0ub8x4tG7/sGddbGN3MU6ZV62LhAwad9q05 QWTzJM6x0rtLMQ== X-Received: by 10.84.245.8 with SMTP id i8mr12303854pll.264.1502060854389; Sun, 06 Aug 2017 16:07:34 -0700 (PDT) Received: from [112.167.24.200] ([112.167.24.200]) by smtp.gmail.com with ESMTPSA id u1sm12431640pfk.31.2017.08.06.16.07.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2017 16:07:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis From: DY Kim In-Reply-To: <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> Date: Mon, 7 Aug 2017 08:07:30 +0900 Cc: =?utf-8?B?56We5piO6YGU5ZOJ?= , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <2632FD33-75C1-422F-B815-191FBB260F9B@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 23:07:35 -0000 The firm reference pole RFC7421 along with a number of docs prescribing 64 bits for the IID length RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072 (thanks to Tatuya Jinmei for the list) would be enough to ensure that SLAAC will accept only 64-bit long prefixes and produce 64-bit long IIDs. not to disturb the wide deployment of SLAAC implementation as such. RFC4291bis doesn=E2=80=99t need (or even ought not to, for it's about = =E2=80=98architecture=E2=80=99) mention or mandate the length of IID, = leaving such implementation specific details to companion docs like = those listed above. --- DY > On 5 Aug 2017, at 15:53, DY Kim wrote: >=20 > This is indeed very regretful. So long as the document is addressing = =E2=80=98architecture=E2=80=99, addresses (or part thereof) (A) should = best be described independently of the way (B) they are generated. B = surely should be subject to A, but not the other way around. The logical = relation should be unidirectional (A -> B), not looped bidirectional (A = <-> B). >=20 > If the two are bidirectionally looped, the next immediate question = should be 'which overrides the other?' Now that they are loop-linked, = none of which, or both are equal=E2=80=A6 confusion,... logical fallacy. >=20 > This logical fallacy, I=E2=80=99d think, might be one of the sources = of reasons for the endless debates on this list in regard to the IID = length. >=20 > It=E2=80=99d be my last intention ever to represent any of the two = camps, but before any debates I=E2=80=99d hope the group acknowledge = that the document in this specific part is subject to logical fallacy, = lacking in logical integrity. Before anything, one might clean up the = text, fist of all, I=E2=80=99d hope. >=20 > --- > DY >=20 >=20 >> On 5 Aug 2017, at 13:38, Brian E Carpenter = wrote: >>=20 >> On 05/08/2017 16:24, DY Kim wrote: >>> =E2=80=98Architecture=E2=80=99 of any kind by nature should deal = with the generic part of the matter, leaving implementation specifics to = companion protocol specs. >>>=20 >>> It is taken that the community consensus is to use 64 bits IID for = SLAAC, no objection to that. >>>=20 >>> However, =E2=80=98architecture=E2=80=99 should not indulge into that = implementation specifics, and, to the same effect as you note, SLAAC and = other link-layer-specific standard track documents will take good care = so that only prefixes of length 64 will be accepted by SLAAC and IIDs of = the same length would be generated. >>>=20 >>> =E2=80=98Architecture=E2=80=99 is a parent/reference document and = should not rely on any implementation specific children specs like = SLAAC. >>>=20 >>> I do think it=E2=80=99s enough to state in 4291bis >>>=20 >>> =E2=80=9CThe length of the interface identifiers are defined in = separate link-layer-specific standard track document.=E2=80=9D >>>=20 >>> to the same implementation effect you=E2=80=99re concerned about. >>=20 >> In theory I agree with that, but we didn't reach consensus on that = approach >> when it was proposed some months ago. I'm hoping we can reach rough = consensus >> on something, sometime. >>=20 >> Brian From nobody Mon Aug 7 20:10:44 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275011243F3 for ; Mon, 7 Aug 2017 20:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 4MXMjpXKOADz for ; Mon, 7 Aug 2017 20:10:40 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A045E1204DA for ; Mon, 7 Aug 2017 20:10:40 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l82so13772879ywc.2 for ; Mon, 07 Aug 2017 20:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D/jitit7Zq7L7l97G327HksVl/A7TcXlQ/61tDKY124=; b=ujE+TWSMTh+Fq+VQpjGvZjc8F/amwZP3yyxUV3B8y89q6BeHNVzJwZkv6jdCuwZAHA EHxIsTxwpPFp8lFmMWOKVjhe+sgg7fZ5cG86Zfrp99ZvPLu7z09J/8QhpctAiRmyrYf+ TXzFvHixzNE9c1TXLGO2hGKIKjRXugiuaclvojPXX/DBeGM02AZq+/9SRVdy7CH72eoA zR2tPxE4EnM7iBEnjg80YiiRArUXwmK+AJZ8K8C72uPOPMU4pfEWX6YXCvnBPTcy/eO9 3XNLk8c/ZSqQCP9VbT544T509DR8hNqIE8YE2RXcakLA2rvAUsx1Y5BCqqKRlSIwY20m GZWw== 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=D/jitit7Zq7L7l97G327HksVl/A7TcXlQ/61tDKY124=; b=c4iDjsTMpTP8jhJllTTyNvLKn0D+ojUp/IqeCOrr0lEzqWZZLo2GhQzPi9Jx3HPHhG JTjJtO4qseRS3iLqU0yP7qb5ReR/wHpCQgYRZ7oxSe/W1MqkLA+sVFgv64odieAIBnBE 1Iqk/TUGcL6BOgCusiC7AoSv3ZjRF0zQJhmduU4Td9/icVOs5foPPjGuEQXbZ+JQVEVv CoWFZp1Q/X7CKvRTCPBin9yy64YzL39PkwTG2mAXcc4yLP9ArOql9FQZl/IR5sArHh4t XHhQRaFdBhHTCBIApGfwnc3Gnr4gjnGD4D9RJqzjVfFRDl0VlFUXoPQ9duEf+cszkM8Y al9A== X-Gm-Message-State: AHYfb5gfZSxEcivHMYMA7YEk78SAJvdjOTzHtZMUI+iKUX/HO4rX1CQI fiul/PqhWOjzRPDia5S3ZRAISrVXHaZ5 X-Received: by 10.129.141.9 with SMTP id d9mr2363213ywg.116.1502161839595; Mon, 07 Aug 2017 20:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.38.74 with HTTP; Mon, 7 Aug 2017 20:10:18 -0700 (PDT) In-Reply-To: <2632FD33-75C1-422F-B815-191FBB260F9B@gmail.com> References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> <2632FD33-75C1-422F-B815-191FBB260F9B@gmail.com> From: Erik Kline Date: Mon, 7 Aug 2017 20:10:18 -0700 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: DY Kim Cc: Brian E Carpenter , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045e6012df56930556354ecb" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 03:10:43 -0000 --f403045e6012df56930556354ecb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still don't think any of these changes are appropriate for just moving the doc to standard. On 6 August 2017 at 16:07, DY Kim wrote: > The firm reference pole > > RFC7421 > > along with a number of docs prescribing 64 bits for the IID length > > RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072 > (thanks to Tatuya Jinmei for the list) > > would be enough to ensure that > > SLAAC will accept only 64-bit long prefixes > and produce 64-bit long IIDs. > > not to disturb the wide deployment of SLAAC implementation as such. > > RFC4291bis doesn=E2=80=99t need (or even ought not to, for it's about =E2= =80=98architecture=E2=80=99) mention or mandate the length of IID, leaving = such implementation specific details to companion docs like those listed ab= ove. > > --- > DY > >> On 5 Aug 2017, at 15:53, DY Kim wrote: >> >> This is indeed very regretful. So long as the document is addressing =E2= =80=98architecture=E2=80=99, addresses (or part thereof) (A) should best be= described independently of the way (B) they are generated. B surely should= be subject to A, but not the other way around. The logical relation should= be unidirectional (A -> B), not looped bidirectional (A <-> B). >> >> If the two are bidirectionally looped, the next immediate question shoul= d be 'which overrides the other?' Now that they are loop-linked, none of wh= ich, or both are equal=E2=80=A6 confusion,... logical fallacy. >> >> This logical fallacy, I=E2=80=99d think, might be one of the sources of = reasons for the endless debates on this list in regard to the IID length. >> >> It=E2=80=99d be my last intention ever to represent any of the two camps= , but before any debates I=E2=80=99d hope the group acknowledge that the do= cument in this specific part is subject to logical fallacy, lacking in logi= cal integrity. Before anything, one might clean up the text, fist of all, I= =E2=80=99d hope. >> >> --- >> DY >> >> >>> On 5 Aug 2017, at 13:38, Brian E Carpenter wrote: >>> >>> On 05/08/2017 16:24, DY Kim wrote: >>>> =E2=80=98Architecture=E2=80=99 of any kind by nature should deal with = the generic part of the matter, leaving implementation specifics to compani= on protocol specs. >>>> >>>> It is taken that the community consensus is to use 64 bits IID for SLA= AC, no objection to that. >>>> >>>> However, =E2=80=98architecture=E2=80=99 should not indulge into that i= mplementation specifics, and, to the same effect as you note, SLAAC and oth= er link-layer-specific standard track documents will take good care so that= only prefixes of length 64 will be accepted by SLAAC and IIDs of the same = length would be generated. >>>> >>>> =E2=80=98Architecture=E2=80=99 is a parent/reference document and shou= ld not rely on any implementation specific children specs like SLAAC. >>>> >>>> I do think it=E2=80=99s enough to state in 4291bis >>>> >>>> =E2=80=9CThe length of the interface identifiers are defined in separa= te link-layer-specific standard track document.=E2=80=9D >>>> >>>> to the same implementation effect you=E2=80=99re concerned about. >>> >>> In theory I agree with that, but we didn't reach consensus on that appr= oach >>> when it was proposed some months ago. I'm hoping we can reach rough con= sensus >>> on something, sometime. >>> >>> Brian > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --f403045e6012df56930556354ecb 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg/0nNWLZMo7gE5+nCGeFPTQGqOOXfBP4c N8kLOFTNZuAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODA4 MDMxMDQwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAIgIvYiYiip+o1twA0reXbxWUFt8hgd3sHdpAi0ZNGT3l9LLM7cJ KaAgpH6B1mQFlRh07AqrJZjtsLBJYyJETbU5r5v8iQwblEEVNKjgwU4tP3CE+0I5QMky83wRVpeK agpttP77WCcihXA+GR7ycg+gfa+ViqaiFH4vmFLygMT4/UBQg6OLHHD0qJNkP5NxAZgp1jZo3CLe NG6vgLpx1w+s+MNTps3hAbEalsAZ5Jj3ImIan2mCE5Oo+b2Blo2dJl+7fOrBnEHtN16Nj0823LSk EmbcGYKDbOybC3ikip+W28q9FDpsojKwsIDpHbSJ/mAbKTC6ttwdJdFF4V24T5Y= --f403045e6012df56930556354ecb-- From nobody Tue Aug 8 09:43: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 7D84D13273A for ; Tue, 8 Aug 2017 09:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6ODjPKzYrhQ for ; Tue, 8 Aug 2017 09:43:04 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E981326FF for ; Tue, 8 Aug 2017 09:43:03 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 41127969 for ; Tue, 8 Aug 2017 16:43:03 +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 BT-QJcuMLm0s for ; Tue, 8 Aug 2017 11:43:03 -0500 (CDT) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) (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 EDFE47B2 for ; Tue, 8 Aug 2017 11:43:02 -0500 (CDT) Received: by mail-ua0-f200.google.com with SMTP id m32so13838544uah.4 for ; Tue, 08 Aug 2017 09:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YFLJPWg2Z19UAi62UszMIMAYWm1XLqLl39jF7TYFzKo=; b=B54dVsJ7sXa6UgsifZZxVorVs4ZaHQu+YEcZbMYV+znOnrnaj2q0Myk/xVhxtoEV4/ n6715YsGEV5D1RzD2milB9bzk9cNSJVSl9syVWD0LlXT96Y1SdkxpRWsqYJEVIwg1TAg QNzEVBJnQ7jJd1OvopwThYgoFk4mWsSZPbzRdLzJZfd3PBdVtHybf7hHUhyvnkfctbox yrGyrxs/cPrm1Apzpd7AlfmrFm9eVUUeR1c6uqQ2vNvT3hAox3me23yqaDxCUs2NAneH 9lmKz+3Pnu5KEQnmwgsvaJua1k+YZ/imybyIaG7M6qATdE1akqfNAzdcXdG1X+WUVK/D kTLg== 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=YFLJPWg2Z19UAi62UszMIMAYWm1XLqLl39jF7TYFzKo=; b=IUSMfDuB+SaU687bGR2LEC+X5wRf+pq52KrATfElTToTuP03c5gNRFCGOkqK+VI3hj j8d0E32enKjHz2ixMj94UiBXrbHGETpYRbDxmfp9gV/0KQutKVKiqFp8xV3q0hWFVC25 V3rWzhBKG4K30wiJHi5tzhTUSG65FanRUh2H0wDCOt11r0qY60nErCtaWReNXJy8/Hsr qF/o7vN1io/iF7YnHTKc8AdV7Ovggt28igt6qy6JGlEkD/BoB4DwxGC5HkE+cuwTwB7j WYcK5Fp9tqj+QILZbSyu59bCjXLiHIre6lHdnz2x+nUWL6CqtqXwSANYDjLKopM7k1An hJQg== X-Gm-Message-State: AHYfb5gHIFQrBDKwAYOkRX7RqGFc3ghwjxhIyx1LhBulrNT3nCTAduPw NSnKPRF9E+b3DQygLjtDvO0MNPymsVCn90qWYNtBoSZht+U2yJiyxp+U+jK691rK9QfmIoJuKi2 2JVGxiDBHxqEeiZI= X-Received: by 10.31.81.195 with SMTP id f186mr3167675vkb.119.1502210582041; Tue, 08 Aug 2017 09:43:02 -0700 (PDT) X-Received: by 10.31.81.195 with SMTP id f186mr3167667vkb.119.1502210581797; Tue, 08 Aug 2017 09:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.221 with HTTP; Tue, 8 Aug 2017 09:43:01 -0700 (PDT) In-Reply-To: References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> <2632FD33-75C1-422F-B815-191FBB260F9B@gmail.com> From: David Farmer Date: Tue, 8 Aug 2017 11:43:01 -0500 Message-ID: Subject: Re: Section 2.4 of rfc4291bis To: Erik Kline Cc: DY Kim , 6man WG , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="001a114e3a8c1b51ee055640a80c" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 16:43:07 -0000 --001a114e3a8c1b51ee055640a80c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Erik, I think your point is valid, but do you have any suggestions how to move this forward, other than that ain't it? I think some version of Brian's suggestion of scoping the requirement for 64 bit IIDs to SLAAC with a recommendation for 64 bit prefixes for subnets and on-link determination works, what do you think of that? Thanks. On Mon, Aug 7, 2017 at 10:10 PM, Erik Kline wrote: > I still don't think any of these changes are appropriate for just > moving the doc to standard. > > On 6 August 2017 at 16:07, DY Kim wrote: > > The firm reference pole > > > > RFC7421 > > > > along with a number of docs prescribing 64 bits for the IID length > > > > RFC2464, RFC2467, RFC2470, RFC2497, RFC2590, RFC3146, RFC5072 > > (thanks to Tatuya Jinmei for the list) > > > > would be enough to ensure that > > > > SLAAC will accept only 64-bit long prefixes > > and produce 64-bit long IIDs. > > > > not to disturb the wide deployment of SLAAC implementation as such. > > > > RFC4291bis doesn=E2=80=99t need (or even ought not to, for it's about > =E2=80=98architecture=E2=80=99) mention or mandate the length of IID, lea= ving such > implementation specific details to companion docs like those listed above= . > > > > --- > > DY > > > >> On 5 Aug 2017, at 15:53, DY Kim wrote: > >> > >> This is indeed very regretful. So long as the document is addressing > =E2=80=98architecture=E2=80=99, addresses (or part thereof) (A) should be= st be described > independently of the way (B) they are generated. B surely should be subje= ct > to A, but not the other way around. The logical relation should be > unidirectional (A -> B), not looped bidirectional (A <-> B). > >> > >> If the two are bidirectionally looped, the next immediate question > should be 'which overrides the other?' Now that they are loop-linked, non= e > of which, or both are equal=E2=80=A6 confusion,... logical fallacy. > >> > >> This logical fallacy, I=E2=80=99d think, might be one of the sources o= f reasons > for the endless debates on this list in regard to the IID length. > >> > >> It=E2=80=99d be my last intention ever to represent any of the two cam= ps, but > before any debates I=E2=80=99d hope the group acknowledge that the docume= nt in this > specific part is subject to logical fallacy, lacking in logical integrity= . > Before anything, one might clean up the text, fist of all, I=E2=80=99d ho= pe. > >> > >> --- > >> DY > >> > >> > >>> On 5 Aug 2017, at 13:38, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> > >>> On 05/08/2017 16:24, DY Kim wrote: > >>>> =E2=80=98Architecture=E2=80=99 of any kind by nature should deal wit= h the generic > part of the matter, leaving implementation specifics to companion protoco= l > specs. > >>>> > >>>> It is taken that the community consensus is to use 64 bits IID for > SLAAC, no objection to that. > >>>> > >>>> However, =E2=80=98architecture=E2=80=99 should not indulge into that= implementation > specifics, and, to the same effect as you note, SLAAC and other > link-layer-specific standard track documents will take good care so that > only prefixes of length 64 will be accepted by SLAAC and IIDs of the same > length would be generated. > >>>> > >>>> =E2=80=98Architecture=E2=80=99 is a parent/reference document and sh= ould not rely on > any implementation specific children specs like SLAAC. > >>>> > >>>> I do think it=E2=80=99s enough to state in 4291bis > >>>> > >>>> =E2=80=9CThe length of the interface identifiers are defined in sepa= rate > link-layer-specific standard track document.=E2=80=9D > >>>> > >>>> to the same implementation effect you=E2=80=99re concerned about. > >>> > >>> In theory I agree with that, but we didn't reach consensus on that > approach > >>> when it was proposed some months ago. I'm hoping we can reach rough > consensus > >>> on something, sometime. > >>> > >>> 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 --001a114e3a8c1b51ee055640a80c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Erik,=C2=A0

I think your point is valid= , but do you have any suggestions how to move this forward, other than that= ain't it?

I think some version of Brian's= suggestion of scoping the requirement for 64 bit IIDs to SLAAC with a reco= mmendation for 64 bit prefixes for subnets and on-link determination works,= what do you think of that? =C2=A0=C2=A0

Thanks.

On Mon, Aug 7= , 2017 at 10:10 PM, Erik Kline <ek@google.com> wrote:
I still don't think any of these changes are ap= propriate for just
moving the doc to standard.

On 6 August 2017 at 16:07, DY Kim <d= ykim6@gmail.com> wrote:
> The firm reference pole
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC7421
>
> along with a number of docs prescribing 64 bits for the IID length
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC2464, RFC2467, RFC2470, RFC2497, R= FC2590, RFC3146, RFC5072
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(thanks to Tatuya Jinmei for the list= )
>
> would be enough to ensure that
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SLAAC will accept only 64-bit long pr= efixes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and produ= ce 64-bit long IIDs.
>
> not to disturb the wide deployment of SLAAC implementation as such. >
> RFC4291bis doesn=E2=80=99t need (or even ought not to, for it's ab= out =E2=80=98architecture=E2=80=99) mention or mandate the length of IID, l= eaving such implementation specific details to companion docs like those li= sted above.
>
> ---
> DY
>
>> On 5 Aug 2017, at 15:53, DY Kim <dykim6@gmail.com> wrote:
>>
>> This is indeed very regretful. So long as the document is addressi= ng =E2=80=98architecture=E2=80=99, addresses (or part thereof) (A) should b= est be described independently of the way (B) they are generated. B surely = should be subject to A, but not the other way around. The logical relation = should be unidirectional (A -> B), not looped bidirectional (A <->= B).
>>
>> If the two are bidirectionally looped, the next immediate question= should be 'which overrides the other?' Now that they are loop-link= ed, none of which, or both are equal=E2=80=A6 confusion,... logical fallacy= .
>>
>> This logical fallacy, I=E2=80=99d think, might be one of the sourc= es of reasons for the endless debates on this list in regard to the IID len= gth.
>>
>> It=E2=80=99d be my last intention ever to represent any of the two= camps, but before any debates I=E2=80=99d hope the group acknowledge that = the document in this specific part is subject to logical fallacy, lacking i= n logical integrity. Before anything, one might clean up the text, fist of = all, I=E2=80=99d hope.
>>
>> ---
>> DY
>>
>>
>>> On 5 Aug 2017, at 13:38, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:<= br> >>>
>>> On 05/08/2017 16:24, DY Kim wrote:
>>>> =E2=80=98Architecture=E2=80=99 of any kind by nature shoul= d deal with the generic part of the matter, leaving implementation specific= s to companion protocol specs.
>>>>
>>>> It is taken that the community consensus is to use 64 bits= IID for SLAAC, no objection to that.
>>>>
>>>> However, =E2=80=98architecture=E2=80=99 should not indulge= into that implementation specifics, and, to the same effect as you note, S= LAAC and other link-layer-specific standard track documents will take good = care so that only prefixes of length 64 will be accepted by SLAAC and IIDs = of the same length would be generated.
>>>>
>>>> =E2=80=98Architecture=E2=80=99 is a parent/reference docum= ent and should not rely on any implementation specific children specs like = SLAAC.
>>>>
>>>> I do think it=E2=80=99s enough to state in 4291bis
>>>>
>>>> =E2=80=9CThe length of the interface identifiers are defin= ed in separate link-layer-specific standard track document.=E2=80=9D
>>>>
>>>> to the same implementation effect you=E2=80=99re concerned= about.
>>>
>>> In theory I agree with that, but we didn't reach consensus= on that approach
>>> when it was proposed some months ago. I'm hoping we can re= ach rough consensus
>>> on something, sometime.
>>>
>>>=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
-----------------------------------------------------------------= ---




--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 &am= p; Telecommunication Services
Office of Information Technology
Univer= sity 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 Ce= ll: 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
--001a114e3a8c1b51ee055640a80c-- From nobody Tue Aug 8 10:25:26 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6B13286C for ; Tue, 8 Aug 2017 10:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO5IGC5XXQKR for ; Tue, 8 Aug 2017 10:25:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD92132869 for ; Tue, 8 Aug 2017 10:25:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 32ABEB811F1; Tue, 8 Aug 2017 10:25:02 -0700 (PDT) To: mkohno@juniper.net, nitzan@juniper.net, randy@psg.com, maz@iij.ad.jp, lorenzo@google.com, narten@us.ibm.com, suresh.krishnan@gmail.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com Subject: [Technical Errata Reported] RFC6164 (5080) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: tte+ietf@cs.fau.de, ipv6@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170808172502.32ABEB811F1@rfc-editor.org> Date: Tue, 8 Aug 2017 10:25:02 -0700 (PDT) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:25:25 -0000 The following errata report has been submitted for RFC6164, "Using 127-Bit IPv6 Prefixes on Inter-Router Links". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5080 -------------------------------------- Type: Technical Reported by: toerless Eckert Section: GLOBAL Original Text ------------- Request for Comments: 6164 Category: Standards Track Corrected Text -------------- Request for Comments: 6164 Category: Standards Track Updates: RFC4291 Notes ----- The solution described in RFC6164 updates RFC4291 because it violates the requirement of RFC4291 section 2.5.1 for the IIDs to be 64-bit long and be constructed from EUI-64 format. Please feel free to reconfirm with 6man WG. In Prague, the suggestion was made that all documents introducing solutions that are not compliant with this requirement must be tracked as updated to RFC6164. When i asked on the list recently, i was given the suggestion to file an Errata as i am doing right now. Note that i think that i do not think that "just wait for rfc4291bis" would be a good answer to this errata because rfc6164 of course predates it, and even more so, correct proedural tracking of rfc4291 updates can potentially help the process of getting to rfc4291bis. 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. -------------------------------------- RFC6164 (draft-ietf-6man-prefixlen-p2p-01) -------------------------------------- Title : Using 127-Bit IPv6 Prefixes on Inter-Router Links Publication Date : April 2011 Author(s) : M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Aug 8 10:26: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 0082713252E for ; Tue, 8 Aug 2017 10:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYiyhflQHriL for ; Tue, 8 Aug 2017 10:26:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5422B132518 for ; Tue, 8 Aug 2017 10:26:36 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A0F3D58C4BC; Tue, 8 Aug 2017 19:26:32 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8BD7EB0C816; Tue, 8 Aug 2017 19:26:32 +0200 (CEST) Date: Tue, 8 Aug 2017 19:26:32 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: ipv6@ietf.org Subject: Re: rfc6164 vs rfc4291 question Message-ID: <20170808172632.GA25781@faui40p.informatik.uni-erlangen.de> References: <20170728092328.GA4567@faui40p.informatik.uni-erlangen.de> <20170804225952.GA14972@faui40p.informatik.uni-erlangen.de> <2009e3b9-39ad-6f5a-5864-4e475ce9d8d9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2009e3b9-39ad-6f5a-5864-4e475ce9d8d9@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:26:38 -0000 Thanks, done. Strange system. Didn't give me a ticket number but just "we'll get back to you". On Sat, Aug 05, 2017 at 11:28:15AM +1200, Brian E Carpenter wrote: > If you think it's an error in RFC6164, you should report it: > https://www.rfc-editor.org/errata.php#reportnew > > It's an interesting question whether, if such an erratum is accepted, > the RFC Editor would then update the metadata for RFC4291. > > However, if we manage to get rfc4291bis out, the issue will be resolved > anyway. > > Regards > Brian > > On 05/08/2017 10:59, Toerless Eckert wrote: > > Nobody ? > > > > On Fri, Jul 28, 2017 at 11:23:28AM +0200, Toerless Eckert wrote: > >> Why if rfc6164 not tracked as an update to rfc4291 given how it explicitly refers > >> to not complying to RFC4291 specification (eg: non /64 interface identifiers) ? > >> > >> I also think to remember that one of the co-authors of rfc4291 said during prague > >> 6man that documents that do this should be tracked as updates of rfc4291. > >> > >> Cheers > >> Toerless > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Tue Aug 8 10:45: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 95CBF129ABE for ; Tue, 8 Aug 2017 10:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yLGIMyZ3mes for ; Tue, 8 Aug 2017 10:45:17 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1003D13295E for ; Tue, 8 Aug 2017 10:45:14 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CA27A58C4B1 for ; Tue, 8 Aug 2017 19:45:09 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id B709BB0C816; Tue, 8 Aug 2017 19:45:09 +0200 (CEST) Date: Tue, 8 Aug 2017 19:45:09 +0200 From: Toerless Eckert To: ipv6@ietf.org Subject: 6man: creating virtual multipoint interfaces Message-ID: <20170808174509.GA25759@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 17:45:20 -0000 I am wondering if there is some RFC i could reference that defines the following functionality specifically for IPv6. If not, i'll have to write it into a draft of mine and would welcome suggestions on some details: I have a full mesh of p2p tunnels between a set of routers, and i want to make this look like a single multiaccess subnet for IPv6. How i create these tunnels is out of scope (resolved). The tunnels would carry only IPv6 packets (not ethernet header etc..). So, a node would enable link-local multicast on this virtual multi-access subnet by just replicating it to all p2p tunnels. And now we run ND. And wonder what to put into the link-layer address field. In my case we can assume the nodes all have the same underlying L2 across which they runn the tunnels, so as long as this is ethernet and we assume unique MAC addresses, we can just use them. Otherwise we would need to come up with some other unique link-layer address. Or we could simply leave this field empty and learn which tunnel is connected to which IPv6 neighbor address by tracking the p2p tunnel frm which the Neighbor advertisements arive. Could even be any unicast packets source-address. Except that it is for a router (not having HW like an L2 switch) easier to learn source addresses from protocols explicitly punted to a control plane (like ND). Existing references i could point to ? Sugestions for the detail (link-layer address encoding, learning of neighbor tunnel ?) IMHO its pretty simple, but wanted to see i am not overlooking anything. Thanks Toerless Ikkn-Reply-To: <20170807183844.GY3889@faui40p.informatik.uni-erlangen.de> On Mon, Aug 07, 2017 at 08:38:44PM +0200, te36 wrote: > > Thanks Daniel! > > Quick browsing does not seem to show that these docs discuss what i am looking for, > so let me explain it hopefully better: > > Assume i have a p2p subnet with two routers attached. I want to use IPsec > to protect all IPv6 traffic on that subnet and make it "invisible" to all > IP protocols as much as possible. So i set up an IPsec SA between the two > and set the SPD on both sides to protect all traffic. > > So this will work fine, and i vendors are supporting it, but i am not aware > of an RFC specifying this. For example, what would you put into the Link-Layer > address option of IPv6 ND packets. I assume this would be the underlying > link-layer address (eg: ethernet address), but thats not 100% obvious. > > So, thats the simple case. Lets consider now i have 3 (or 30) routers on a LAN and > want to protect it with IPsec. Usually, i could not create multiple SAs > across a single interface (from what i have seen in products). There are > products that allow you to create a virtual IPsec subnet, but those are p2p, > eg: you create a full mesh of SAs and on every router you see two separate > virtual IPsec p2p interfaces, each operating the same as the above p2p example, > except that the implementation might be different. > > But i would rather like to see a single multiaccess subnet interface on each > router so that i can fully reflect the underlying topology. And any protocols > using multicast would continue to operate. Its not really that difficult, > as i already said in my first email: > > - Replicate multicsts into all SAs. Including ND multicasts. > - You keep a mapping table about which IPv6 nexthop belongs to which SA. > - Send unicast into the right SA based on that nexthop table. > - Populate that nexthop table from source IPv6 addresses > received from each SA. Maybe limited to received ND packets. > - Continue to populate the the underlying Link-Layer address, but > no need to maintain any link-layer mapping table (send but ignore on > receipt). > > And now i just wonder if i need to write this down into my draft, or if i can > find some existing RFC (or draft) i could refer to. Especially because the details > of learning the SA mapping are pretty arbitrarily. Eg: I think it would logically > be a lot better to have SPIs as link-layer addresses, but i wouldn't want to > invent something new just because i think it's logically better. Or i > populate the mapping table solely from the peer address of the SPI (eg: > link-local-IPv6-address of the peer on the SA). > > The definitions i am looking for does not need to be specific to IPsec. The > problem is IMHO quite orthogonal to IPsec. Eg: instead of IPsec SA, i could > equally try to protect the traffic with any other form of secure p2p tunnel. > But i wouldn't know which other IETF mailing list to ask for other contexts > (suggestions welcome). > > There is for example rfc7847, but it has a lot of surplus (;-) mobility stuff > in it, and it doesn't tackle the simple points of multicast, how to learn > next-hop mapping , eg: what to do with ND packets, etc. pp, so i think it > wouldn't help me as a reference. > > Cheers > Toerless > > On Mon, Aug 07, 2017 at 12:40:21PM -0400, Daniel Migault wrote: > > Not really sure what exactly you are looking at, but these links might be > helpful. > > > > https://tools.ietf.org/html/rfc7018 > > https://tools.ietf.org/html/rfc7791 > > https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 > > https://tools.ietf.org/html/draft-detienne-dmvpn-01 > > > > On Fri, Aug 4, 2017 at 7:37 PM, Toerless Eckert wrote: > > > > > I want to describe (in some draft) the use of a virtual multi-access > > > interface that is mapped to multiple p2p associations (eg: IPsec). > > > Which i think is a pretty standard option in industry implementations, eg: > > > in hub routers for hub & spoke deployments. > > > > > > Is there any good RFC reference that explains how this works, eg: > > > replicate ll-multicast to all p2p associations, learn peer addresses > > > from received packets or specific IPv6 signaling packets, use that > > > to send unicast into right p2p association, etc. pp. > > > > > > I could not find a good reference RFC for this ;-( > > > > > > Thanks! > > > Toerless > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > --- > tte@cs.fau.de From nobody Tue Aug 8 11: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 D79321326FB for ; Tue, 8 Aug 2017 11:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ERJG-p7OoS3J for ; Tue, 8 Aug 2017 11:41:03 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 148051326F8 for ; Tue, 8 Aug 2017 11:40:57 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id o86so17897874pfj.1 for ; Tue, 08 Aug 2017 11:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=65hCmBbvw2jgKGU4MHK1qkeDMxxXdPgOegQ7nM3YcKY=; b=m1DWcUDwdRmhKSnEdWN225t0IjSSlIehd5YLSV7F3WfOiMtFbuYEwp2QIkQkeNWdpI haufnPbAaatAlBs6Ar5nmN8ins9AO859MjLx8LljR4zeltW+5wlFJs+uqv3cbxKPhZOl 0GnVDMK9KCbmf2sjdtCbioTDqq292TT7gCeydCg8LzW9kyD0RdPFQr4iDk/69okviKr6 lUKJHz/GK6B/qYKYAst6HUYesdeugrOuR+8xJ4HeUAac22R84ptQGIcebPmYx9ITRXex IfzZEIEn4xy1ji2MokhsCQPu8iDqTbelLWaLp0MuWcSsEhN70+7t2kj3z2m8gIismZBJ kSBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=65hCmBbvw2jgKGU4MHK1qkeDMxxXdPgOegQ7nM3YcKY=; b=eSs1RzjdJRfOU8SJ5HNUAoIqHJnnJxoEcwiqOqBZDenD2Y1f/q/MqCnncRND4u6EA/ Ju1iCVNvtCMRcSvtdcP3eNsSU7FokJoyN/21ePq7ZJk+T1RQo26Ifw3k8qBj6aCOZJrk 9ZyiCIKMdXKKfZ53fcswSbGiLdIiqprPEggUC/AiABN32prMGaG5I7EkVG43Za8L907p ImS85JTOgcTCb4Iao6ipA793fcUxV60nbn0+2wmypSwSm0ZKPZEK35cjMJ3YoGI4sVgZ p7ABIrEuWN5VJ2GQuFzeyyUHl6Uk1ggjfDi8Z+Poh2lsfdmcwy428o2wbdfy0lEAR2dE Pf5Q== X-Gm-Message-State: AHYfb5iI+17mVa2PcEvRFz1DczaVnt+c6KzYMKxxxlCRB7BH0hM5ak6y 8rrREXlohhMXTo6+rHf+Jw== X-Received: by 10.84.224.141 with SMTP id s13mr5792206plj.212.1502217656157; Tue, 08 Aug 2017 11:40:56 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:b56b:82bf:999e:e730? ([2620:0:10e7:10:b56b:82bf:999e:e730]) by smtp.gmail.com with ESMTPSA id 22sm4116247pfx.73.2017.08.08.11.40.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 11:40:55 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_E81474E5-FD62-4FDC-A9A6-FEA7BADAB1B4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Section 2.4 of rfc4291bis Date: Tue, 8 Aug 2017 11:40:54 -0700 References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <97dc7ee4-422f-a15b-bb99-57b00a2f8f98@gmail.com> <23a4bdc3-86f2-c2e5-db47-adf4c4ff0459@gmail.com> <44D52701-9A28-4907-ACBD-1D4EC8BBCF17@gmail.com> <1efb9ad0-02f5-36ed-1c5f-3877c06cd4b4@gmail.com> <33BFB616-DFED-48AC-89A5-ACB441CAEC95@gmail.com> <2632FD33-75C1-422F-B815-191FBB260F9B@gmail.com> To: 6man WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 18:41:05 -0000 --Apple-Mail=_E81474E5-FD62-4FDC-A9A6-FEA7BADAB1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 8, 2017, at 09:43, David Farmer wrote: >=20 > I think your point is valid, but do you have any suggestions how to = move this forward, other than that ain't it? >=20 > I think some version of Brian's suggestion of scoping the requirement = for 64 bit IIDs to SLAAC with a recommendation for 64 bit prefixes for = subnets and on-link determination works, what do you think of that?=20 I completely share Erik=E2=80=99s view, but I=E2=80=99m not speaking for = him here, and I would invite him to answer for himself. My answer to your question is that if I-D.ietf-6man-rfc4291bis-09 cannot = achieve sufficient consensus to publish, then I=E2=80=99d prefer to see = the effort to promote RFC 4291 into the STD series abandoned. I=E2=80=99ve= come to believe that the IPv6 world can thrive without a STD number for = the IPv6 Addressing Architecture. Any further revisions to other IPv6 = documents that we want to promote to Standard can be revised so they = don=E2=80=99t make normative references to RFC 4291. In fact, that=E2=80=99= s probably a good idea on general principle given this seemingly = interminable debate. --james woodyatt > --Apple-Mail=_E81474E5-FD62-4FDC-A9A6-FEA7BADAB1B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 8, 2017, at 09:43, David Farmer <farmer@umn.edu> = wrote:

I think your point is valid, but do you = have any suggestions how to move this forward, other than that ain't = it?

I think = some version of Brian's suggestion of scoping the requirement for 64 bit = IIDs to SLAAC with a recommendation for 64 bit prefixes for subnets and = on-link determination works, what do you think of = that? 

I = completely share Erik=E2=80=99s view, but I=E2=80=99m not speaking for = him here, and I would invite him to answer for himself.

My answer to your question is that if = I-D.ietf-6man-rfc4291bis-09 cannot achieve sufficient consensus to = publish, then I=E2=80=99d prefer to see the effort to promote RFC 4291 = into the STD series abandoned. I=E2=80=99ve come to believe that the = IPv6 world can thrive without a STD number for the IPv6 Addressing = Architecture. Any further revisions to other IPv6 documents that we want = to promote to Standard can be revised so they don=E2=80=99t make = normative references to RFC 4291. In fact, that=E2=80=99s probably a = good idea on general principle given this seemingly interminable = debate.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_E81474E5-FD62-4FDC-A9A6-FEA7BADAB1B4-- From nobody Wed Aug 9 07:51: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 A165A132223 for ; Wed, 9 Aug 2017 07:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejs3yJq0eiNK for ; Wed, 9 Aug 2017 07:51:32 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A685B1321F1 for ; Wed, 9 Aug 2017 07:51:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v79EpUpL082317 for ; Wed, 9 Aug 2017 16:51:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37F4D2034C6 for ; Wed, 9 Aug 2017 16:51:30 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2EDB22028AB for ; Wed, 9 Aug 2017 16:51:30 +0200 (CEST) Received: from [132.166.84.138] ([132.166.84.138]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v79EpT3v009092 for ; Wed, 9 Aug 2017 16:51:29 +0200 Subject: Re: Section 2.4 of rfc4291bis To: ipv6@ietf.org References: <9faf9370-30cd-5789-7dce-eadc8d7f1a5b@gmail.com> <24464ADB-88A8-4C44-9E6D-47B241B489A5@gmail.com> <591EF1FC-BB62-4853-B120-880542E4F21F@gmail.com> <3DE924C8-7EB0-47C2-97E2-D5A3142A27F2@gmail.com> From: Alexandre Petrescu Message-ID: <4c5cab52-975a-cc68-3e51-0af27c643b4d@gmail.com> Date: Wed, 9 Aug 2017 16:51:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3DE924C8-7EB0-47C2-97E2-D5A3142A27F2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 14:51:35 -0000 Le 04/08/2017 à 22:48, DY Kim a écrit : > Which some? Some other than ‘standard track documents'? > > Could you please point me to? There are some I-Ds published on other purpose than this 64 dicussion, and that could hint at IIDs for SLAAC. The implementation of a Client forming an address out of a /56 or of /65 could be something like 'tcpdump|grep RA|grep prefix|grep plen && ifconfig add prefix::$RANDOM/plen eth0'. Such mechanism and draft would not break anything. Alex > > --- DY > > >> On 5 Aug 2017, at 05:34, 神明達哉 wrote: >> >> o RFC4291 and rfc4291bis also say the length of IID is 64 bits for >> some set of IPv6 addresses. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Aug 9 14:57: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 DF12B13228D for ; Wed, 9 Aug 2017 14:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7efy2EFpnJ5G for ; Wed, 9 Aug 2017 14:57:19 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EDD13226B for ; Wed, 9 Aug 2017 14:57:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v79LvHfg003458; Wed, 9 Aug 2017 14:57:17 -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 v79Lv8RG002871 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 9 Aug 2017 14:57:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 9 Aug 2017 14:57:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 9 Aug 2017 14:57:07 -0700 From: "Templin, Fred L" To: Toerless Eckert , "ipv6@ietf.org" Subject: RE: 6man: creating virtual multipoint interfaces Thread-Topic: 6man: creating virtual multipoint interfaces Thread-Index: AQHTEG4jzMHoBzDHS0G5GxzFjha1daJ8keaA Date: Wed, 9 Aug 2017 21:57:07 +0000 Message-ID: <02f135632b024a6182a8ad2202f57e82@XCH15-06-08.nw.nos.boeing.com> References: <20170808174509.GA25759@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170808174509.GA25759@faui40p.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:57:22 -0000 Hi Toerless, We have been working with point-to-multipoint tunnels (actually NBMA) for a= long time. The earliest examples were RFC2529 and RFC5214, but we have carried t= he model forward into our current AERO proposal: https://datatracker.ietf.org/doc/draft-templin-aerolink/ Of these proposals: - RFC2529 uses multicast-in-multicast encapsulation so that true multicast= is used in the underlay. - RFC5214 is unicast-only - AERO can use either multicast-in-multicast or unicast-emulated multicast = such as your message described. All of these works use IPv6 ND messaging over tunnels. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: Tuesday, August 08, 2017 10:45 AM > To: ipv6@ietf.org > Subject: 6man: creating virtual multipoint interfaces >=20 > I am wondering if there is some RFC i could reference that defines the fo= llowing > functionality specifically for IPv6. If not, i'll have to write it into > a draft of mine and would welcome suggestions on some details: >=20 > I have a full mesh of p2p tunnels between a set of routers, and i want > to make this look like a single multiaccess subnet for IPv6. How i > create these tunnels is out of scope (resolved). The tunnels would carry > only IPv6 packets (not ethernet header etc..). >=20 > So, a node would enable link-local multicast on this virtual multi-access= subnet > by just replicating it to all p2p tunnels. And now we run ND. And wonder > what to put into the link-layer address field. In my case we can assume > the nodes all have the same underlying L2 across which they runn the tunn= els, > so as long as this is ethernet and we assume unique MAC addresses, we can= just > use them. Otherwise we would need to come up with some other unique link-= layer > address. Or we could simply leave this field empty and learn which tunnel > is connected to which IPv6 neighbor address by tracking the p2p tunnel fr= m > which the Neighbor advertisements arive. Could even be any unicast packet= s > source-address. Except that it is for a router (not having HW like an L2 = switch) > easier to learn source addresses from protocols explicitly punted to a co= ntrol plane > (like ND). >=20 > Existing references i could point to ? > Sugestions for the detail (link-layer address encoding, learning of neigh= bor tunnel ?) >=20 > IMHO its pretty simple, but wanted to see i am not overlooking anything. >=20 > Thanks > Toerless >=20 > Ikkn-Reply-To: <20170807183844.GY3889@faui40p.informatik.uni-erlangen.de> >=20 > On Mon, Aug 07, 2017 at 08:38:44PM +0200, te36 wrote: > > > > Thanks Daniel! > > > > Quick browsing does not seem to show that these docs discuss what i am = looking for, > > so let me explain it hopefully better: > > > > Assume i have a p2p subnet with two routers attached. I want to use IPs= ec > > to protect all IPv6 traffic on that subnet and make it "invisible" to a= ll > > IP protocols as much as possible. So i set up an IPsec SA between the t= wo > > and set the SPD on both sides to protect all traffic. > > > > So this will work fine, and i vendors are supporting it, but i am not a= ware > > of an RFC specifying this. For example, what would you put into the Lin= k-Layer > > address option of IPv6 ND packets. I assume this would be the underlyin= g > > link-layer address (eg: ethernet address), but thats not 100% obvious. > > > > So, thats the simple case. Lets consider now i have 3 (or 30) routers o= n a LAN and > > want to protect it with IPsec. Usually, i could not create multiple SAs > > across a single interface (from what i have seen in products). There ar= e > > products that allow you to create a virtual IPsec subnet, but those are= p2p, > > eg: you create a full mesh of SAs and on every router you see two separ= ate > > virtual IPsec p2p interfaces, each operating the same as the above p2p = example, > > except that the implementation might be different. > > > > But i would rather like to see a single multiaccess subnet interface on= each > > router so that i can fully reflect the underlying topology. And any pro= tocols > > using multicast would continue to operate. Its not really that difficul= t, > > as i already said in my first email: > > > > - Replicate multicsts into all SAs. Including ND multicasts. > > - You keep a mapping table about which IPv6 nexthop belongs to which = SA. > > - Send unicast into the right SA based on that nexthop table. > > - Populate that nexthop table from source IPv6 addresses > > received from each SA. Maybe limited to received ND packets. > > - Continue to populate the the underlying Link-Layer address, but > > no need to maintain any link-layer mapping table (send but ignore o= n > > receipt). > > > > And now i just wonder if i need to write this down into my draft, or if= i can > > find some existing RFC (or draft) i could refer to. Especially because = the details > > of learning the SA mapping are pretty arbitrarily. Eg: I think it would= logically > > be a lot better to have SPIs as link-layer addresses, but i wouldn't wa= nt to > > invent something new just because i think it's logically better. Or i > > populate the mapping table solely from the peer address of the SPI (eg: > > link-local-IPv6-address of the peer on the SA). > > > > The definitions i am looking for does not need to be specific to IPsec.= The > > problem is IMHO quite orthogonal to IPsec. Eg: instead of IPsec SA, i c= ould > > equally try to protect the traffic with any other form of secure p2p tu= nnel. > > But i wouldn't know which other IETF mailing list to ask for other cont= exts > > (suggestions welcome). > > > > There is for example rfc7847, but it has a lot of surplus (;-) mobility= stuff > > in it, and it doesn't tackle the simple points of multicast, how to lea= rn > > next-hop mapping , eg: what to do with ND packets, etc. pp, so i think = it > > wouldn't help me as a reference. > > > > Cheers > > Toerless > > > > On Mon, Aug 07, 2017 at 12:40:21PM -0400, Daniel Migault wrote: > > > Not really sure what exactly you are looking at, but these links migh= t be > helpful. > > > > > > https://tools.ietf.org/html/rfc7018 > > > https://tools.ietf.org/html/rfc7791 > > > https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03 > > > https://tools.ietf.org/html/draft-detienne-dmvpn-01 > > > > > > On Fri, Aug 4, 2017 at 7:37 PM, Toerless Eckert wrote= : > > > > > > > I want to describe (in some draft) the use of a virtual multi-acces= s > > > > interface that is mapped to multiple p2p associations (eg: IPsec). > > > > Which i think is a pretty standard option in industry implementatio= ns, eg: > > > > in hub routers for hub & spoke deployments. > > > > > > > > Is there any good RFC reference that explains how this works, eg: > > > > replicate ll-multicast to all p2p associations, learn peer addresse= s > > > > from received packets or specific IPv6 signaling packets, use that > > > > to send unicast into right p2p association, etc. pp. > > > > > > > > I could not find a good reference RFC for this ;-( > > > > > > > > Thanks! > > > > Toerless > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > -- > > --- > > tte@cs.fau.de >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Aug 10 00:49: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 4E96213234E for ; Thu, 10 Aug 2017 00:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiLdvUl2PLXt for ; Thu, 10 Aug 2017 00:49:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB14131D27 for <6man@ietf.org>; Thu, 10 Aug 2017 00:49:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6ED8DA2; Thu, 10 Aug 2017 09:49:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502351386; bh=I5dj+6Hge5Y0JNDR1bN5mA4Uo3zdj5LLreoek6nZfhk=; h=Date:From:To:Subject:From; b=Uv7hAzxEl9PmK90KS7I9LVxa7Q3Me2Gi1FFAMYBl92UkMvZ0SUU+xZRJhpS2OV+sr xKa9Eg0RdDyVkb85bEhQrzcctbspmmc4m8oMBg3Bya2paisrIWUu0EqzGE5/l8/oPV eOZiWB27zmlq+NBgs4RFwqK81gQcaHShqVKdrGvc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6BE46A1 for <6man@ietf.org>; Thu, 10 Aug 2017 09:49:46 +0200 (CEST) Date: Thu, 10 Aug 2017 09:49:46 +0200 (CEST) From: Mikael Abrahamsson To: 6man@ietf.org Subject: RFC 4861 missing updated-by (was: [Editorial Errata Reported] RFC6275 (5083) (fwd)) Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 07:49:52 -0000 FYI. I decided to raise an errata against RFC6275 that seems to update RFC4861 without this being noted anywhere in either document. I am still unsure if I also need to raise an errata against RFC4861, but I think this single errata would take care of both documents gaining updates/updated-by references? ---------- Forwarded message ---------- Date: Thu, 10 Aug 2017 00:29:23 -0700 (PDT) From: RFC Errata System To: charliep@computer.org, dbj@cs.rice.edu, jari.arkko@ericsson.com, suresh.krishnan@gmail.com, terry.manderson@icann.org, julien.ietf@gmail.com, jouni.korhonen@nsn.com Cc: swmike@swm.pp.se, dmm@ietf.org, rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC6275 (5083) The following errata report has been submitted for RFC6275, "Mobility Support in IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5083 -------------------------------------- Type: Editorial Reported by: Mikael Abrahamsson Section: GLOBAL Original Text ------------- Corrected Text -------------- Notes ----- Section 7.2 of RFC6275 introduces a new flag, called the R bit. This seems to update RFC 4861 section 4.6.2. However, there is no mention in RFC6275 or in RFC4861 that this happened. 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. -------------------------------------- RFC6275 (draft-ietf-mext-rfc3775bis-13) -------------------------------------- Title : Mobility Support in IPv6 Publication Date : July 2011 Author(s) : C. Perkins, Ed., D. Johnson, J. Arkko Category : PROPOSED STANDARD Source : Mobility EXTensions for IPv6 Area : Internet Stream : IETF Verifying Party : IESG From nobody Thu Aug 10 11:07: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 9FD611323A5 for ; Thu, 10 Aug 2017 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTEkOhz8AR-y for ; Thu, 10 Aug 2017 11:07:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4121323B7 for <6man@ietf.org>; Thu, 10 Aug 2017 11:07:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 23BB02009E; Thu, 10 Aug 2017 14:09:39 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 062BE806BA; Thu, 10 Aug 2017 14:07:20 -0400 (EDT) From: Michael Richardson To: Robert Sparks cc: 6man@ietf.org Subject: Re: RFC 4861 missing updated-by (was: [Editorial Errata Reported] RFC6275 (5083) (fwd)) In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:07:22 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson wrote: > FYI. I decided to raise an errata against RFC6275 that seems to update > RFC4861 without this being noted anywhere in either document. Are we able to update the metadata on RFC4861 in response to this errata? I realize we can't re-issue 6275. Since the Updates is to make sure that readers of 4861 know about new things, the metadata 4861->6275 (which shows up in the tools page and datatracker for the old documents) is really the important direction. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmMoNcACgkQgItw+93Q 3WVF3QgArn7Rko67LPKbAVdtTwVBvQgVQlDrW27GDOiAFpKKVBD/7XCMC8xFaU6O EpS1Sg56LBFUMDzUMiR6/OPgVcofuCnA2U9Q5Oq/aXMKLpf8t+UuW+hjMI1ECxyR mxc8XjzGNS0YHgNwPkGJsnYAsNj5eaujbx7oa6WTuc6UgDE8QTyi2D0WyAEyjWf/ 2ynsT/1CNu8dLCruHsN8oKDfnmFxWa6QRFfgwlPqMZxBoYAzDZ6fAM5fWWnbn7Lc qtOrNcaQld6oDBH3OpHRQgcfWG/q7jjQMKzAMMhuPnCzpKJVi00sBXu7slxQYXRz HLJznnWLtMwMYoCDr0eFf2xZ7kV3hQ== =24jR -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 10 11: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 C69AA1323C1 for ; Thu, 10 Aug 2017 11:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlUKI-RNoK9M for ; Thu, 10 Aug 2017 11:38:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F2912009C for <6man@ietf.org>; Thu, 10 Aug 2017 11:38:45 -0700 (PDT) Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7AIcidv020325 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Aug 2017 13:38:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local Subject: Re: RFC 4861 missing updated-by To: Michael Richardson Cc: 6man@ietf.org References: <8447.1502388439@obiwan.sandelman.ca> From: Robert Sparks Message-ID: Date: Thu, 10 Aug 2017 13:38:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8447.1502388439@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:38:48 -0000 This is a question for the IESG (it's more a question of policy than it is tool capability). I'm pretty sure the question's been asked before (and the discussion led to a "no, if you want to fix this, do it with an RFC"). RjS On 8/10/17 1:07 PM, Michael Richardson wrote: > Mikael Abrahamsson wrote: > > FYI. I decided to raise an errata against RFC6275 that seems to update > > RFC4861 without this being noted anywhere in either document. > > Are we able to update the metadata on RFC4861 in response to this errata? > I realize we can't re-issue 6275. > > Since the Updates is to make sure that readers of 4861 know about new things, > the metadata 4861->6275 (which shows up in the tools page and datatracker for > the old documents) is really the important direction. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Thu Aug 10 11:39: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 79239132400 for ; Thu, 10 Aug 2017 11:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmpjqmX1Q7s9 for ; Thu, 10 Aug 2017 11:39:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470CD12009C for <6man@ietf.org>; Thu, 10 Aug 2017 11:39:49 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5836A58C4B2; Thu, 10 Aug 2017 20:39:44 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 34D3AB0C846; Thu, 10 Aug 2017 20:39:44 +0200 (CEST) Date: Thu, 10 Aug 2017 20:39:43 +0200 From: Toerless Eckert To: Michael Richardson Cc: Robert Sparks , 6man@ietf.org Subject: Re: RFC 4861 missing updated-by (was: [Editorial Errata Reported] RFC6275 (5083) (fwd)) Message-ID: <20170810183943.GR3889@faui40p.informatik.uni-erlangen.de> References: <8447.1502388439@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8447.1502388439@obiwan.sandelman.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:39:51 -0000 My https://www.rfc-editor.org/errata_search.php?eid=5080 also only describes that 6164 updates 4861, seems like the same thing. I am expecting that the metadata update will be done for both documents. Otherwise there is too much bureaucracy. On Thu, Aug 10, 2017 at 02:07:19PM -0400, Michael Richardson wrote: > > Mikael Abrahamsson wrote: > > FYI. I decided to raise an errata against RFC6275 that seems to update > > RFC4861 without this being noted anywhere in either document. > > Are we able to update the metadata on RFC4861 in response to this errata? > I realize we can't re-issue 6275. > > Since the Updates is to make sure that readers of 4861 know about new things, > the metadata 4861->6275 (which shows up in the tools page and datatracker for > the old documents) is really the important direction. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Thu Aug 10 11:42: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 406F013232D for ; Thu, 10 Aug 2017 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_df8Jc054sS for ; Thu, 10 Aug 2017 11:42:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678EB131CD7 for <6man@ietf.org>; Thu, 10 Aug 2017 11:42:37 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B373858C4ED; Thu, 10 Aug 2017 20:42:33 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A0FEEB0C846; Thu, 10 Aug 2017 20:42:33 +0200 (CEST) Date: Thu, 10 Aug 2017 20:42:33 +0200 From: Toerless Eckert To: Robert Sparks Cc: Michael Richardson , 6man@ietf.org Subject: Re: RFC 4861 missing updated-by Message-ID: <20170810184233.GS3889@faui40p.informatik.uni-erlangen.de> References: <8447.1502388439@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 18:42:39 -0000 Hmm... the way i understood it, this is just missing metadata linking the two documents. But of course i have no experience with current practices whether metadata will be fixed or not. Metadata is a lot more like what i think metadata is if it can be updated sedparately from the doc. Otherwise its a lot more like data ;-P On Thu, Aug 10, 2017 at 01:38:44PM -0500, Robert Sparks wrote: > This is a question for the IESG (it's more a question of policy than > it is tool capability). > > I'm pretty sure the question's been asked before (and the discussion > led to a "no, if you want to fix this, do it with an RFC"). > > RjS > > > On 8/10/17 1:07 PM, Michael Richardson wrote: > >Mikael Abrahamsson wrote: > > > FYI. I decided to raise an errata against RFC6275 that seems to update > > > RFC4861 without this being noted anywhere in either document. > > > >Are we able to update the metadata on RFC4861 in response to this errata? > >I realize we can't re-issue 6275. > > > >Since the Updates is to make sure that readers of 4861 know about new things, > >the metadata 4861->6275 (which shows up in the tools page and datatracker for > >the old documents) is really the important direction. > > > >-- > >Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- --- tte@cs.fau.de From nobody Thu Aug 10 13:06: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 E290413243E for ; Thu, 10 Aug 2017 13:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMOKOq9-8LwZ for ; Thu, 10 Aug 2017 13:06:05 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0527D13243C for ; Thu, 10 Aug 2017 13:06:05 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id t86so7184334pfe.2 for ; Thu, 10 Aug 2017 13:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VREML65EpvZGR6ssbazULhrUFOTAeVIWHmYJVTrBW/o=; b=jMDj5XOYsx5K+1BoU5jCti8umBJpfCA9HNJlKvK6o0U5LJWRB4VaJSHlpqzHYXgZ6x uxkcBZQq0P+TBJBoKObFz/aucWLCa+rLAvMhn69sBmJuvZ3CBP9j6nKQ0qNGqKfwlX/0 hUeetY7adrrRY65QOw4Klu6XWPASyPeXy22NDZOJm8PaWa+SZb2BmFp2D9bxMeQWwQVE /1F8g15/BeS1exApG3en0/Ijl4A0t6wDrBdhx8XhC45BFKOZnodE4CXC610PcUm5wMTp mmxueD0Y+j7oC929ZERvkcEcPY1KQRC0vA0djWvkM4UoVmWkkc41ja+gLSpFW8H+UXcy WdMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VREML65EpvZGR6ssbazULhrUFOTAeVIWHmYJVTrBW/o=; b=sKOUqe259d/+Qd477c2CyiI5jw3vdm9U4nngcbmpjZAeFd2XcXxG3lEQzboe2iyNDD A/HDwlTysCL9RqcsF47gL428jMsAEkYIQvhg37oYhaEqhkgYay0D1P5wtdSl1bsM2Six U60aryZRZyrxzMvhJkd3FLwFyfX6NDUq2zcipI59ewUrFw8Qd8pxBhrpgatC8V1rO0Md jxCfs0I4vPCdz0BYkbKlelWSuQvN4fpo7x5WVji3755pYWrHJvLALBMpoh/jkG8lZz5m VhsQ199BMeJTnkXtYH/27YPka1SSNo5Bp8QJgpWYP195nQXKV1ngv1C30Y74gpNLV4fN rs7g== X-Gm-Message-State: AHYfb5iQWtPvq/d7ByVkHdRpijVlpSBuX6bQspDF/zeXNjXBmqkJIe1/ 5uo2D6+UQbXOlu1v X-Received: by 10.98.86.70 with SMTP id k67mr13755996pfb.91.1502395564302; Thu, 10 Aug 2017 13:06:04 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t64sm11650559pgd.80.2017.08.10.13.06.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 13:06:03 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: ipv6@ietf.org References: <8447.1502388439@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> Date: Fri, 11 Aug 2017 08:06:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:06:07 -0000 On 11/08/2017 06:38, Robert Sparks wrote: > This is a question for the IESG (it's more a question of policy than it > is tool capability). I would say it's a question for the RFC Editor, who would ask for advice from the IESG since these are IETF stream documents. (It's the RFC Editor who maintains the metatdata for RFCs.) Brian > > I'm pretty sure the question's been asked before (and the discussion led > to a "no, if you want to fix this, do it with an RFC"). > > RjS > > > On 8/10/17 1:07 PM, Michael Richardson wrote: >> Mikael Abrahamsson wrote: >> > FYI. I decided to raise an errata against RFC6275 that seems to update >> > RFC4861 without this being noted anywhere in either document. >> >> Are we able to update the metadata on RFC4861 in response to this errata? >> I realize we can't re-issue 6275. >> >> Since the Updates is to make sure that readers of 4861 know about new things, >> the metadata 4861->6275 (which shows up in the tools page and datatracker for >> the old documents) is really the important direction. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . > From nobody Thu Aug 10 19:52: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 E71D8129AD3 for ; Thu, 10 Aug 2017 19:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzDqzSvCyOpN for ; Thu, 10 Aug 2017 19:52:40 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6308C129A92 for ; Thu, 10 Aug 2017 19:52:40 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id p68so15566829ywg.0 for ; Thu, 10 Aug 2017 19:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0YtuSB8gJhwemqWemNyGgmAVoS8oyAnPTHye2KUcEpE=; b=C+lnFAoRdwRLwo7c6Md3IBdR2Nq0iI3ZtNcFVW1g5iwlJGl0Agk4CUz4PRgnV6IbLY uXfZdRMNLtw21QhEjxAcNFV/z123N9WpCXiLBa3BEgzQka1c1FiHZdjeMf7Di1aIFlHL WwrjFD+v1RP+TSOmx/4g/AR+hTW5sBmdWUTR9BbF7HJGTLegz//lc7kbOT8YiQhGgKxq 5brbb7V4c17pT3+OVifHgHOWNcV3E/iTkhwQz6PT8Jzo9WMkbPit7SoY38oq3yY9t229 OSiYur0WUnXm82G2BU40u+KjyMBkaLtNK5ewvMKDWpe92tCsHv8lyTdC7o0uG2inY+B+ Stqw== 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=0YtuSB8gJhwemqWemNyGgmAVoS8oyAnPTHye2KUcEpE=; b=Pt+zWUsEQdWxcOEzFUEQ+9iaM4NHW/HtuCR3VclNa8GRwWfkEMtt/dZryrAGBjsYEV kSvH8+ONRiE8ljLhy5iCi1sB7S8gDDvwk8BddFgi38dIHGLodGekZW/XdrZ+ejwGe7Re n+OgZmopKbxYBqZ/4DL5FGPrMg+8+d9WBUzkdOLnt3xommJzfzbvNG/xX41D30MOmTiC JkSn2mhx9k4NlnvrEn/v1v+lo15jk7Y+tm34kP8q2rY3ksf31KJCwwT11SVjJnhjjPbH 5YeqHwHkwYoXLlVgeJa+PQBsMiJNyfFVRWU+pseJWAZEeRJnKVkqXeb9BCuJ9qaDvjwm tuLA== X-Gm-Message-State: AHYfb5gGIfZtRAKSDiRgElva8LcvQ0V8WRzHYmsbnih428rbv2B1QKn3 ZtQ0q99vAPCdIw== X-Received: by 10.129.156.74 with SMTP id t71mr11996089ywg.350.1502419959630; Thu, 10 Aug 2017 19:52:39 -0700 (PDT) Received: from [10.0.0.5] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id i71sm2723022ywg.47.2017.08.10.19.52.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 19:52:38 -0700 (PDT) From: Suresh Krishnan Message-Id: <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F75BE95-0796-4E8B-A24C-D2056843660C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Thu, 10 Aug 2017 22:52:36 -0400 In-Reply-To: <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> Cc: ipv6@ietf.org To: Brian E Carpenter References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 02:52:43 -0000 --Apple-Mail=_6F75BE95-0796-4E8B-A24C-D2056843660C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I had a short chat with Mikael about this during the Prague IETF. One = of the major issues I have encountered is that we do not, as a = community, have a common understanding of what the =E2=80=9CUpdates:=E2=80= =9D tag means (or even what it is supposed to mean). Until that gets = resolved, there will be no clear indication on when to mark a document = as updated and when not to. As for this Erratum, I will hold onto it = until we have a better idea on how to proceed. As an example another = document in this category is RFC4191 that I personally think should = update RFC2461/RFC4861 because of changing the RA flag bits. Similarly, = should RFC4389 update RFC4861 for the same reason as well? Thanks Suresh > On Aug 10, 2017, at 4:06 PM, Brian E Carpenter = wrote: >=20 > On 11/08/2017 06:38, Robert Sparks wrote: >> This is a question for the IESG (it's more a question of policy than = it=20 >> is tool capability). >=20 > I would say it's a question for the RFC Editor, who would ask for = advice > from the IESG since these are IETF stream documents. (It's the RFC = Editor > who maintains the metatdata for RFCs.) >=20 > Brian >=20 >>=20 >> I'm pretty sure the question's been asked before (and the discussion = led=20 >> to a "no, if you want to fix this, do it with an RFC"). >>=20 >> RjS >>=20 >>=20 >> On 8/10/17 1:07 PM, Michael Richardson wrote: >>> Mikael Abrahamsson wrote: >>>> FYI. I decided to raise an errata against RFC6275 that seems to = update >>>> RFC4861 without this being noted anywhere in either document. >>>=20 >>> Are we able to update the metadata on RFC4861 in response to this = errata? >>> I realize we can't re-issue 6275. >>>=20 >>> Since the Updates is to make sure that readers of 4861 know about = new things, >>> the metadata 4861->6275 (which shows up in the tools page and = datatracker for >>> the old documents) is really the important direction. >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> . >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 = > -------------------------------------------------------------------- --Apple-Mail=_6F75BE95-0796-4E8B-A24C-D2056843660C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,
  I had a short chat with Mikael = about this during the Prague IETF. One of the major issues I have = encountered is that we do not, as a community, have a common = understanding of what the =E2=80=9CUpdates:=E2=80=9D tag means (or even = what it is supposed to mean). Until that gets resolved, there will be no = clear indication on when to mark a document as updated and when not to. = As for this Erratum, I will hold onto it until we have a better idea on = how to proceed. As an example another document in this category is = RFC4191 that I personally think should update RFC2461/RFC4861 because of = changing the RA flag bits. Similarly, should RFC4389 update RFC4861 for = the same reason as well?

Thanks
Suresh

On Aug 10, 2017, at 4:06 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 11/08/2017 06:38, Robert = Sparks wrote:
This is a question for the IESG (it's more a question of = policy than it 
is tool capability).

I would say it's a question for the RFC Editor, = who would ask for advice
from the IESG since these are = IETF stream documents. (It's the RFC Editor
who maintains the metatdata for RFCs.)
   Brian

I'm pretty = sure the question's been asked before (and the discussion led 
to a "no, if = you want to fix this, do it with an RFC").

RjS


On 8/10/17 = 1:07 PM, Michael Richardson wrote:
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
FYI. I decided to raise an errata against = RFC6275 that seems to update
RFC4861 without this being = noted anywhere in either document.

Are we able to update the metadata on RFC4861 in response to = this errata?
I realize we can't re-issue 6275.

Since the Updates is to make sure that readers = of 4861 know about new things,
the metadata 4861->6275 = (which shows up in the tools page and datatracker for
the = old documents) is really the important direction.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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


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

= --Apple-Mail=_6F75BE95-0796-4E8B-A24C-D2056843660C-- From nobody Thu Aug 10 22:50:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC80132484 for ; Thu, 10 Aug 2017 22:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 T8v5gDzEyk2G for ; Thu, 10 Aug 2017 22:50:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF381132487 for ; Thu, 10 Aug 2017 22:50:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 02F5AA2; Fri, 11 Aug 2017 07:50:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502430640; bh=d/uO1F9fLg6Dy9MMGkbhE1+SgbzHhsTQIjcfCJw8GKo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nCZyXwIKt5ja4Q4AtPEdZw/W0Ki6IWcA2ig371C5KnOaREhrQjoyva+QaDjdQ+etQ kQKgwSAd1b1x9OFazJsDmW8W8kNryq4+V5qXP4qTcYvfEjOg94fglQe5WwSNfWlhvt m+fC7vMu8OLJlJKf7gKZCr3EOtuXb6dFaFnvHdRM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A94DEA1; Fri, 11 Aug 2017 07:50:39 +0200 (CEST) Date: Fri, 11 Aug 2017 07:50:39 +0200 (CEST) From: Mikael Abrahamsson To: Suresh Krishnan cc: Brian E Carpenter , ipv6@ietf.org Subject: Re: RFC 4861 missing updated-by In-Reply-To: <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-756275575-1502430639=:2261" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 05:50:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-756275575-1502430639=:2261 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 10 Aug 2017, Suresh Krishnan wrote: > I had a short chat with Mikael about this during the Prague IETF. One > of the major issues I have encountered is that we do not, as a > community, have a common understanding of what the “Updates:” tag means > (or even what it is supposed to mean). Until that gets resolved, there > will be no clear indication on when to mark a document as updated and > when not to. As for this Erratum, I will hold onto it until we have a > better idea on how to proceed. As an example another document in this > category is RFC4191 that I personally think should update > RFC2461/RFC4861 because of changing the RA flag bits. Similarly, should > RFC4389 update RFC4861 for the same reason as well? THanks for this. First time this was brought up was in november last year, when me and Erik Kline were notified that our proposed PIO-X bit was overlapping with the R bit. https://www.ietf.org/mail-archive/web/ipv6/current/msg25491.html I then raised this with the authors of 6275 without getting any meaningful response, I have raised it with multiple ADs as well. I find that the current situation is very dangerous, and it needs to be resolved. I don't much care if we fix it by having an IANA registry for all fields in everything, or if we fix the updated-by references, or if we have "please also read"-reference, or if we just log erratum against RFCs that seem to have no updated-by but have more recent documents that change bits in them. SOMETHING needs to happen. I wasn't told that there were things happening, that's why I wanted to "force the issue" by issuing an errata. And by writing the above text, I realise that I agree with that 4861 probably need to have some kind of "errata" against it as well, becuase the important part is that readers of 4861 finds 6275, not the other way around. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-756275575-1502430639=:2261-- From nobody Fri Aug 11 13:33: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 87E5D132698 for ; Fri, 11 Aug 2017 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSXVxYVGBnZ0 for ; Fri, 11 Aug 2017 13:33:46 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CACB1321C7 for ; Fri, 11 Aug 2017 13:33:46 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id t86so19941691pfe.2 for ; Fri, 11 Aug 2017 13:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/Sy4alq59Tfl0U01fCdxJ7fJC+Ds2lGxO2KZknDgmjA=; b=YbIpwcDPOi+mbtjGL//k/+BxHC+wNGZd6zFRzxg7RZ+eHVe+9X9ExvKu0DzPg+yxqr F2Oer8b3wmlMyKUoAfZpkvOiBIASasfirOoErSle/4wxCuE7lnIEZYxVIjd9lll9u/Zj lqllMWqYzCyxZGPLgTzUEDXzOcd7a+3UqKm6G1mucE/BpLlz2e5QIEYHWCnsCG9vqzs3 TPEZ4CGaOOoS0g0aWH2CUeoTf3wACABu1ioX8sqWZg4sv0xqdH3irILRuylJXaa4M4ze HZnCaL9k9knGHU/Pbna31e/jj/Jd54oyjGGucDUK/ZYSUnr6OHZaF5HW+pVEb9M3LVCQ 4x4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/Sy4alq59Tfl0U01fCdxJ7fJC+Ds2lGxO2KZknDgmjA=; b=t3kpK7X6tq60nUTYgzomw7yLKklSFxLOx5R3Hm38R3wP/Z8KKm4Tz5SSniiFi9m31h bSG8QlBD1cFE713TLlauqrILQxv2cTuH9aA7x1gN3uXyTHMsrXgoDcO9MmunIGvDpdrz MGkpfsr/Ssi6gecbEJ42HW5Z176JK0lvwdPUWaOznACVEk5NSo+HEoqpCOuMXaFlIJLB M19SuuyeHqiePX/nYLlCZvOd+ruzaPwTfFEL2Obml47s53w1dsT091Z1cjHGY/bCOs4L WxcxBZbxeMJKzqg1MrBaTlzt9eDMd9XfyWr+uZvs0hzEIEW575+jj14Z1HF06D441Bhy F0SQ== X-Gm-Message-State: AHYfb5iZGhb3/fbxsvhv4uP4fnU4edC1bARpd7Ay++Tmk3DnO1ltbmFm HeUkXoL9yYoNKpdu X-Received: by 10.99.96.216 with SMTP id u207mr16170488pgb.423.1502483625740; Fri, 11 Aug 2017 13:33:45 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q17sm4341405pge.71.2017.08.11.13.33.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 13:33:45 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: Mikael Abrahamsson , Suresh Krishnan Cc: ipv6@ietf.org References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> Date: Sat, 12 Aug 2017 08:33:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 20:33:49 -0000 > And by writing the above text, I realise that I agree with that 4861=20 > probably need to have some kind of "errata" against it as well,=20 That's why the RFC Editor needs to update the metadata for both RFCs. The error is the missing "updates", and that is an error in 6275. The consequence of validating that error is a change to the metadata for both RFCs. There is no error in 4861. There is a gap in its metadata. (Same situation for https://www.rfc-editor.org/errata_search.php?eid=3D50= 80) Regards Brian On 11/08/2017 17:50, Mikael Abrahamsson wrote: > On Thu, 10 Aug 2017, Suresh Krishnan wrote: >=20 >> I had a short chat with Mikael about this during the Prague IETF. One= =20 >> of the major issues I have encountered is that we do not, as a=20 >> community, have a common understanding of what the =E2=80=9CUpdates:=E2= =80=9D tag means=20 >> (or even what it is supposed to mean). Until that gets resolved, there= =20 >> will be no clear indication on when to mark a document as updated and = >> when not to. As for this Erratum, I will hold onto it until we have a = >> better idea on how to proceed. As an example another document in this = >> category is RFC4191 that I personally think should update=20 >> RFC2461/RFC4861 because of changing the RA flag bits. Similarly, shoul= d=20 >> RFC4389 update RFC4861 for the same reason as well? >=20 > THanks for this. First time this was brought up was in november last ye= ar,=20 > when me and Erik Kline were notified that our proposed PIO-X bit was=20 > overlapping with the R bit. >=20 > https://www.ietf.org/mail-archive/web/ipv6/current/msg25491.html >=20 > I then raised this with the authors of 6275 without getting any meaning= ful=20 > response, I have raised it with multiple ADs as well. >=20 > I find that the current situation is very dangerous, and it needs to be= =20 > resolved. I don't much care if we fix it by having an IANA registry for= =20 > all fields in everything, or if we fix the updated-by references, or if= we=20 > have "please also read"-reference, or if we just log erratum against RF= Cs=20 > that seem to have no updated-by but have more recent documents that cha= nge=20 > bits in them. >=20 > SOMETHING needs to happen. I wasn't told that there were things happeni= ng,=20 > that's why I wanted to "force the issue" by issuing an errata. >=20 > And by writing the above text, I realise that I agree with that 4861=20 > probably need to have some kind of "errata" against it as well, becuase= =20 > the important part is that readers of 4861 finds 6275, not the other wa= y=20 > around. >=20 From nobody Sat Aug 12 11:03: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 B22201320DC for ; Sat, 12 Aug 2017 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrCuA_gQJg3x for ; Sat, 12 Aug 2017 11:03:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B77C132063 for ; Sat, 12 Aug 2017 11:03:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 03952E21D; Sat, 12 Aug 2017 14:06:14 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2426F8076D; Sat, 12 Aug 2017 14:03:48 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Mikael Abrahamsson , Suresh Krishnan , ipv6@ietf.org Subject: Re: RFC 4861 missing updated-by In-Reply-To: <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 18:03:50 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> And by writing the above text, I realise that I agree with that 4861 >> probably need to have some kind of "errata" against it as well, > That's why the RFC Editor needs to update the metadata for both RFCs. > The error is the missing "updates", and that is an error in 6275. > The consequence of validating that error is a change to the metadata > for both RFCs. Exactly!! I think that the IESG should be able to create new forward references without publishing new documents. It should be a relatively cheap operation. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmPQwMACgkQgItw+93Q 3WX+RQf/S8833stC1BhBhniFnW/Y0XJJsJsnztstGbFmZWMaku1jBqnr5c/8KqkF dbzjrgmPUMUcXReA39My8x4szZXbQMPb3CUdbhW1zqkhrxr/6wsfxBmdtOEn29+J qZtyWJe+PpuUfGmTUuHUdaMvCRVpOj/AynBpJeSgpOljXJetQy7+wkcZc6mBf/7t DllmaSmq2YwL5wiSZ5Nevgc9YWB0NQM/O5BGEcvxV7ps1mo7N2v3weepdNDRxvi8 0vtrbw/nlQA7q0xCegtlfRFu0cz9aMhXW78HiqpCoWU2KiYWVpK1A+nQbPX0QuRy +SpZ+71LbtLv5vwWanL1Y+5nFRaTYQ== =RBvS -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 12 22:56:05 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF081326C2 for ; Sat, 12 Aug 2017 22:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 EP-zLr-aSVE3 for ; Sat, 12 Aug 2017 22:56:01 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DB3132494 for ; Sat, 12 Aug 2017 22:56:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8DF0DB0; Sun, 13 Aug 2017 07:55:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502603757; bh=xj3eNFHGmkfxRGW16mdtb5kDAESDp3NJ41g2WEN5qdo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=KN9m0kcQz6sMplePopH62X59wOE8rnAWYM9G301UIpwhMbFF8w7vGEVwJAveUN+tm 1qqpYQjF5aqGw7LMhwOwMwjsNRvkm5Eraq7/9cAwHHHidaVtjS9R81xHxBipT4YkuW FG+NZ31fGaSWEIobDeo2QgyGcm3aaEqqmrjV0Lx8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 88D94AF; Sun, 13 Aug 2017 07:55:57 +0200 (CEST) Date: Sun, 13 Aug 2017 07:55:57 +0200 (CEST) From: Mikael Abrahamsson To: Michael Richardson cc: ipv6@ietf.org Subject: Re: RFC 4861 missing updated-by In-Reply-To: <12017.1502561028@obiwan.sandelman.ca> Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 05:56:04 -0000 On Sat, 12 Aug 2017, Michael Richardson wrote: > I think that the IESG should be able to create new forward references > without publishing new documents. It should be a relatively cheap > operation. Agreed. Potentially it could be done with a 2 week last call announcement so that if anyone disagrees, their voice can be heard. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 00:27: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 4E3231200B9; Tue, 15 Aug 2017 00:27:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ot@cisco.com, suresh.krishnan@gmail.com, ipv6@ietf.org, 6man-chairs@ietf.org Subject: 6man - New Meeting Session Request for IETF 100 X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150278202523.21081.17254007844175822728.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 00:27:05 -0700 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 07:27:05 -0000 A new meeting session request has just been submitted by Ole Troan, a Chair of the 6man working group. --------------------------------------------------------- Working Group Name: IPv6 Maintenance Area Name: Internet Area Session Requester: Ole Troan Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6lo 6tisch dhc homenet intarea v6ops mtgvenue Second Priority: spring dnssd tsvarea Third Priority: nfvrg anima People who must be present: Robert M. Hinden Ole Troan Suresh Krishnan Resources Requested: Special Requests: --------------------------------------------------------- From gert@chekov.greenie.muc.de Tue Aug 1 02:27: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 558B1132CBB for ; Tue, 1 Aug 2017 02:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUTsjAGSmbKm for ; Tue, 1 Aug 2017 02:27:29 -0700 (PDT) Received: from chekov.greenie.muc.de (chekov.greenie.muc.de [IPv6:2001:608:4::ce:c0f]) (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 4E4F0131F1F for ; Tue, 1 Aug 2017 02:27:28 -0700 (PDT) Received: from chekov.greenie.muc.de (localhost [127.0.0.1]) by chekov.greenie.muc.de (8.15.2/8.15.2) with ESMTPS id v719ROPx037982 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Aug 2017 11:27:24 +0200 (CEST) (envelope-from gert@chekov.greenie.muc.de) Received: (from gert@localhost) by chekov.greenie.muc.de (8.15.2/8.15.2/Submit) id v719RO7j037981; Tue, 1 Aug 2017 11:27:24 +0200 (CEST) (envelope-from gert) Date: Tue, 1 Aug 2017 11:27:24 +0200 From: Gert Doering To: Sander Steffann Cc: ???????????? , Mark Smith , "ipv6@ietf.org" , Gert =?iso-8859-1?Q?D=F6ring?= Subject: Re: fe80::/16 on specific link layers Message-ID: <20170801092724.GX70062@greenie.muc.de> References: <93fd6e1d18f244a095906cf7af8a1ae2@XCH15-06-08.nw.nos.boeing.com> <5BE01407-FBAA-486F-A2C6-B70D6F99B3FB@steffann.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qa1NXTiqN6KSzHv0" Content-Disposition: inline In-Reply-To: <5BE01407-FBAA-486F-A2C6-B70D6F99B3FB@steffann.nl> X-mgetty-docs: http://mgetty.greenie.net/ User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 01:31:51 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 12:24:04 -0000 --qa1NXTiqN6KSzHv0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Aug 01, 2017 at 12:53:15PM +0200, Sander Steffann wrote: > >>> It would break BSD-variant implementations, which internally use the > >>> 2nd 16-bit field of link-local addresses to identify the corresponding > >>> link, e.g., fe80:1::abcd means fe80::abcd in link "#1". (It's an > >>> internal form and doesn't appear on wire). >=20 > I also remember Gert D=F6ring running into this when implementing > some OpenVPN IPv6 stuff as well, but then I guess OpenVPN does some > funny routing table manipulations and falls under that category :-) I ran into it when writing the code to figure out where a given IPv6 address is currently routed to (to be able to install a /128 host=20 route for the VPN Server via "outside interface" when all IPv6 is=20 routed "inside" the VPN). Since gateways happen to be RA-installed, I saw fe80::: route next-hops... The code currently uses what FreeBSD route.c used to do: struct sockaddr_in6 *s6 =3D (struct sockaddr_in6 *)gate; struct in6_addr gw =3D s6->sin6_addr; if (gate->sa_len =3D=3D sizeof(struct sockaddr_in6) && IN6_IS_ADDR_LINKLOCAL(&gw) ) { gw.s6_addr[2] =3D gw.s6_addr[3] =3D 0; } =2E.. just zero'ing the fields on receive-from-kernel, as we're not=20 using the scope ID directly (we use the interface name, which is delivered as RTA_IFP in the routing socket response). I said "used to do", as FreeBSD changed their interface already, delivering scope_id and not using s6_addr[2] and [3] any longer (if I remember correctly). But that's indeed a special case application, talking routing sockets directly - for us, it would not be a problem if these two fields were always zero. Other software talking to the routing socket is likely aware of the operating system variants and does whatever is needed - especially since there's differences in the data structures used=20 already today. gert --=20 USENET is *not* the non-clickable part of WWW! //www.muc.de/~ge= rt/ Gert Doering - Munich, Germany gert@greenie.muc= =2Ede fax: +49-89-35655025 gert@net.informatik.tu-muenchen= =2Ede --qa1NXTiqN6KSzHv0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGcBAEBAgAGBQJZgEl7AAoJEB2Cnv7KVigSBScL/iTP8nCJBTNY9dATFF2mSkeo hwkJ7r4tx2GckhiuTyAHQ9wu5xMikF/PZ22fnjAVygGqxMrDm+8txZgwVWLqYPs7 AfLCKQJWKXpe9lLhDNjeVJC2fNsqKfyG0jnCPqbxG5/wWcW2D90nMhJxCg6H6jdO lEP6QV+DpSjGGk5/xQXqhOkLszzsZWGXKPGGWbelq36vRmbaqePPjYKPtCkSdo/Z +yv3Mkm/hemAI7awrZvzrrNmYKAi7rYbFgTlLS/s1G29ETbc4AhcLM5zRsKX8ijA 5zlTpYfw6J2JHZZ2ZBeplDN4J7q6hT5XmrtX25aZALIQi15UzR1V9RQMMUCT2e3F BN4yyYbO1WjkrV21OVhV6XEet/t4mLfDe3Ho71G/193wDGijHQgFILcxpl/j5cOm pWsF4tbKBAhdUq2HXYAuNH9f1/fej6ZrS1mp3hq4ODZ+7oOy6nzvZ3YzYm4cs569 4Od0V2SBPHOBAx/8t65PBr1vzXZzM26J4YX69tu2kQ== =Flq5 -----END PGP SIGNATURE----- --qa1NXTiqN6KSzHv0-- From nobody Tue Aug 15 02: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 649A913203D for ; Tue, 15 Aug 2017 02:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsals6fY5Qlg for ; Tue, 15 Aug 2017 02:11:11 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91BD1204DA for ; Tue, 15 Aug 2017 02:11:11 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A80CC2D4FD1; Tue, 15 Aug 2017 09:11:05 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BC532F7137B9; Tue, 15 Aug 2017 11:11:03 +0200 (CEST) From: Ole Troan Message-Id: <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_988F99BA-D729-49CE-8890-5D14BFE6C219"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Tue, 15 Aug 2017 11:11:02 +0200 In-Reply-To: Cc: Michael Richardson , 6man WG To: Mikael Abrahamsson References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 09:11:13 -0000 --Apple-Mail=_988F99BA-D729-49CE-8890-5D14BFE6C219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't think adding a new flag in a "Reserved" field qualifies as = updating an RFC. That's what we have IANA registries for. /ot > On 13 Aug 2017, at 07:55, Mikael Abrahamsson wrote: >=20 > On Sat, 12 Aug 2017, Michael Richardson wrote: >=20 >> I think that the IESG should be able to create new forward references = without publishing new documents. It should be a relatively cheap = operation. >=20 > Agreed. Potentially it could be done with a 2 week last call = announcement so that if anyone disagrees, their voice can be heard. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_988F99BA-D729-49CE-8890-5D14BFE6C219 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 iQIcBAEBCgAGBQJZkrqnAAoJEL7aWKiYQt92VYsP/ArY3OsYSulnVSPX/vtvl+xM 5Cck80TIcoWWY79TN78jJ67gECttmsyQyi1svwjlxiUjjuJp9aop1c7nOMf3DYXY 2Yyn33B/gD8y8dNKTqzecKXxWBGSob40bp4fRuFc8M5BJBVP/BvnBo5ORL5l0i5v o38+hIf0x61LPtyjLhVNu1I94q/hpw7zQOMzNfoRJsKRFLH+/Gcnc/+NXEpst32G svGWgWh6RPqAxTjL3FEoF3X8PsEywYPfwqk6u6ea6wH386ki8asG438i4lXMloB9 V9hq7PTNbP23uDRlDZLmVpf47Oi3rTVfrbrPXHjjRCUmezptnZyG279+JaCEqaid kYoMJ5q1d8USYAVRZdMHY9mt1YtFWL/4OKdgSU7I8/G9UQEtbVYv9CSwvU7gVFHw AqReSckpXY1PfA+UZ/i77jy1SXEqAhOsezi9HDl0sKoWBqXRI/a3SSCISnotaPpy 86st1o2ydnqHrvT2y2PDxsr4K3mpjPHrhnLJfYyLUwHvD1ABL4p6wCPCc1yonMpq HRO+vVHTPccmWuT+VmvRR30okG6KpP7Rk0BIAfeywU4VUuOxVNShgFgJoFAR1rtV QzSgCW91Ax+er2yJKWuKBmtQphKrKoSBZFp6v5K5pbFDFZ4xEOC27PWPR07WEnti AN6DRQLRjK1UuXiti+Sz =Tl6M -----END PGP SIGNATURE----- --Apple-Mail=_988F99BA-D729-49CE-8890-5D14BFE6C219-- From nobody Tue Aug 15 03:41: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 D8420132026 for ; Tue, 15 Aug 2017 03:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaSZUM0JIAw6 for ; Tue, 15 Aug 2017 03:41:30 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF89B120721 for ; Tue, 15 Aug 2017 03:41:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 79A72AF; Tue, 15 Aug 2017 12:41:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502793687; bh=KlmPuk5Eo+qNraWL870aO+bblAzOBNTsSpM+vhLJzOc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TdipqCeu1XLY8TbAfJfus/UYeLjVvalbqS6NdRMumYWmj6JQ1aow0FHSQ0qnTeRj5 3LI82wzVGuTl+Sp3VqMz9tn/WCV6E0iGG9RmRbO+mT01/C7keSy4zyAvwPbAp5R/2y Y1xYJh3SHzVm6gjVjn1d5AantOtNa5zMT7FcMYCI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74F8484; Tue, 15 Aug 2017 12:41:27 +0200 (CEST) Date: Tue, 15 Aug 2017 12:41:27 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Michael Richardson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 10:41:33 -0000 On Tue, 15 Aug 2017, Ole Troan wrote: > I don't think adding a new flag in a "Reserved" field qualifies as updating an RFC. > That's what we have IANA registries for. So where is the IANA registry for the bit fields that RFC4861 standardises? Or so say it another way: If I want to use a new bit field that for instance RFC4861 specifies, how am I going to find what other RFCs has touched this, if there is no IANA registry (as far as I know there isn't, I can't find one). Someone (IETF leadership) has to put their foot down and say one of two things (or something completely different): 1. If you move reserved bits to in-sure, you update the original RFC that defined these bits as reserved. Metadata is added to the original RFC so this can be found. 2. There must be IANA registries for all bit fields, and if you change reserved bits to in-use, this must be reflected in the IANA registry. The way we do things now by not having IANA registries and not updating RFCs when changing reserved bits to in-use is extremely prone to mistakes. We missed this completely when we wrote PIO-X and it was caught because someone happened to notice it and who was into MIPv6. Or what am I missing? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 03:53: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 6D2A713208E for ; Tue, 15 Aug 2017 03:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IWPwcS2OrUN for ; Tue, 15 Aug 2017 03:53:40 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B66120721 for ; Tue, 15 Aug 2017 03:53:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 31C29AF; Tue, 15 Aug 2017 12:53:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502794418; bh=kHwfBGpyr7bArOGaAvzcvW7zI6dLohhnYnaSUFGSXQE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dnD1l8mcAiDKXZtpiz9Gd8y67FNLvMeNO2kBdE4fRPB4c5YVkuNAckHPlltR3ZxxX skKYvkiKHfeHTA78EoOg/pjEM4IXVov9zPlnfh/oTEfG6ro1AFWMhyJ26ZWYx5hxw0 QocL9z0whWbRDwRTneq7NP6C+RrxJwn/Yof5jM7A= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 168A584; Tue, 15 Aug 2017 12:53:38 +0200 (CEST) Date: Tue, 15 Aug 2017 12:53:38 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Michael Richardson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 10:53:41 -0000 On Tue, 15 Aug 2017, Mikael Abrahamsson wrote: > 1. If you move reserved bits to in-sure, you update the original RFC that Gah, I meant "in-use". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 04:02: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 CDEDB13218C for ; Tue, 15 Aug 2017 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUyb-YqRiyvJ for ; Tue, 15 Aug 2017 04:02:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2977613208E for ; Tue, 15 Aug 2017 04:02:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BB62CAF; Tue, 15 Aug 2017 13:02:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502794959; bh=zuf3J0WEdFOddsyV4utLtyy/vkpbh1ogaeU3SKNseIg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=JiyQPTGewQfQM8XEetMf0m+mX2DbatD+7BpFWtkR7m4pS86jm878jkEz7+wM1umZl y3r8rrOr1U9q581h/zriUljaO1UBhm+0ZsIJM96cl7JcTTLC14WpYnYDaTSz6qUFdJ lesQ2PvPRfrCQhjw1ebjz7WOEWQuFGq5C5H8pE7k= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B911E84; Tue, 15 Aug 2017 13:02:39 +0200 (CEST) Date: Tue, 15 Aug 2017 13:02:39 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Michael Richardson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 11:02:43 -0000 On Tue, 15 Aug 2017, Mikael Abrahamsson wrote: > 2. There must be IANA registries for all bit fields, and if you change > reserved bits to in-use, this must be reflected in the IANA registry. The closest thing I can find: https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 3 Prefix Information [RFC4861] If RFC6275 was listed there, then at least there would be a better chance of finding it. So is that the errata that should have been filed instead, that 6275 didn't send an IANA request to add it to the above item, and that this should now be sent? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 04:04: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 CE378132194 for ; Tue, 15 Aug 2017 04:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLcI8_XphFVq for ; Tue, 15 Aug 2017 04:04:28 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339681320DC for ; Tue, 15 Aug 2017 04:04:28 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 37C122D4FA1; Tue, 15 Aug 2017 11:04:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 36600F728DAB; Tue, 15 Aug 2017 13:04:24 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A3832994-668F-49B6-8AEF-E007D0C25DB5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Tue, 15 Aug 2017 13:04:23 +0200 In-Reply-To: Cc: Michael Richardson , 6man WG To: Mikael Abrahamsson References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 11:04:30 -0000 --Apple-Mail=_A3832994-668F-49B6-8AEF-E007D0C25DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, >> I don't think adding a new flag in a "Reserved" field qualifies as = updating an RFC. >> That's what we have IANA registries for. >=20 > So where is the IANA registry for the bit fields that RFC4861 = standardises? >=20 > Or so say it another way: >=20 > If I want to use a new bit field that for instance RFC4861 specifies, = how am I going to find what other RFCs has touched this, if there is no = IANA registry (as far as I know there isn't, I can't find one). >=20 > Someone (IETF leadership) has to put their foot down and say one of = two things (or something completely different): >=20 > 1. If you move reserved bits to in-sure, you update the original RFC = that defined these bits as reserved. Metadata is added to the original = RFC so this can be found. >=20 > 2. There must be IANA registries for all bit fields, and if you change = reserved bits to in-use, this must be reflected in the IANA registry. >=20 > The way we do things now by not having IANA registries and not = updating RFCs when changing reserved bits to in-use is extremely prone = to mistakes. We missed this completely when we wrote PIO-X and it was = caught because someone happened to notice it and who was into MIPv6. >=20 > Or what am I missing? As far as I can see you are correct. The resolution I would prefer in this case would be that you wrote a = draft instructing IANA to create the new PIO flags registry. Best regards, Ole --Apple-Mail=_A3832994-668F-49B6-8AEF-E007D0C25DB5 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 iQIcBAEBCgAGBQJZktU3AAoJEL7aWKiYQt92pxgQAIY2Udv37rMSinoSx6/2nNMt uEQSAxPPCjTztRzqfEH/4MD17aNeivHMkp9UP30dPNDGxZfTM1qS3ATiL6wd7jlQ 8f3MjgAsDwaAITNycinMq96OQezJRRJ2fnwbEhMfEry/KDl66HxunZaDrat37Vi0 mE1/lGv3lrKvLM7lrUwuLZqAt/AqFnDStBvENot/B6LgSbIgj9kGVPR1MQM1DFz5 IZsuB4+PQLpHZPAVcfgTFyOm81HjX5zPiTHu55RHszaS2RfdZKJbDhFAsFr3C2HR Y9b6ox2eMKAyn5MHFns3fpT5CtGGLkI/1GnJADmZJuiP58k+2/enPdG6mwL80Jrl 1/y6L9p+9zpcLcMKv8ibFz6FCVSGRlAaPyyxddfqCVxgOKllyJ9ef8Ljp4WzC6Y7 tBLHDj+Ds+edm18IWKDj+1G4SHRSCKdO4+i/vwcqKGGtLqYHtuQLgMq9ekEBnTvs gHKGI9u0HrjtxYxZ4VqrLvRhz+Ngp+RVJsj5sVygepSMM998414QDNhqzm2inZQp JWGe6LnPkPTwLJ3vlo3JIQkW8AppjWYvj2asQU+fOGKurU4/HHb0mefcatFqfgWv cJFZbtYEe7aBrD7OlFYUQa1MZolDhAp1XgJJtztBdPvgKvXNpCmjxLLwy61YAhH3 tY/nqWy5cNVergR7IBA4 =oX7u -----END PGP SIGNATURE----- --Apple-Mail=_A3832994-668F-49B6-8AEF-E007D0C25DB5-- From nobody Tue Aug 15 13:53: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 414E513263E for ; Tue, 15 Aug 2017 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLd0haNH_fuQ for ; Tue, 15 Aug 2017 13:53:17 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBE413263B for ; Tue, 15 Aug 2017 13:53:17 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id v189so12516212pgd.2 for ; Tue, 15 Aug 2017 13:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hcuqq8MX+Bje5r/MNUDfRAl/T89cbg2+Coe3G8LU/a8=; b=p4gxNxfu79GuLmjxgzy/dee1uP8rMJGGTdbmvNWLQBZtt07MKAwY5o9+QIVvmeIDno cuhBucCHmWa6LD709pA7bNvrNsbU058nb4FSOEX/22vNHeIYu7u0ChvZywv4X56Nhnry lBJKe1NDzKvMa42znZflS/XHnf/NdEeqhB2Ximnx68qQPnAz2fzr3cceeIlCPIQATvUt MOjcB1QKGaugVycm9isxeNrGA6A0bD/9w9BX4Y8IkuL3t8/rP9KGJ+38Equix+gB6vjS ISiagUp9RuAMluuNfL8x4FiFzFOwhmDVITwY6bh+AGFImrla164EN46e7JFSPH9bAhlu Cyeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hcuqq8MX+Bje5r/MNUDfRAl/T89cbg2+Coe3G8LU/a8=; b=JFv9hgM22HQ6QXqiu8Tqjqgsqrdl9fva+YaOZN7a/3Kk2p+mU+8bdZemBxdKzYmsSD jBBTolu9Azi8dAeDlaXUndAqk5OL+HhEINKUYNmOAqdIdYIbghgXyfZOuY0YkDN5UR7j eI/ks5Um9xJi7XkOhg1o8RnoEeacDwA+68PM2k3jHkRhrTeLgFX9Cj3TqP1u7LG9Kuyq WMdK5rq0naxXgIlWI3dFx7SFXyLKZBGl+PtiYJNgAALM6/bk02zMr+pc6k5PI+BNJbow hkuJZ/WtSSoJ7LUbAboJOxc3jjZ/Dm8XcmCX47QStyZPuNNni6buAiFCsLMaVPVTsFsR Kpmg== X-Gm-Message-State: AHYfb5jhzY0R8eLxMr7gQMc4N5BwBCfb4vIlfcHcV7Lmpwm4LFEcioyf 4qz6zqguW4ZJwCIL X-Received: by 10.98.93.87 with SMTP id r84mr29310495pfb.292.1502830396683; Tue, 15 Aug 2017 13:53:16 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d71sm18593875pfg.169.2017.08.15.13.53.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 13:53:15 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: Ole Troan , Mikael Abrahamsson Cc: Michael Richardson , 6man WG References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> Date: Wed, 16 Aug 2017 08:53:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 20:53:19 -0000 On 15/08/2017 23:04, Ole Troan wrote: > Mikael, > >>> I don't think adding a new flag in a "Reserved" field qualifies as updating an RFC. >>> That's what we have IANA registries for. >> >> So where is the IANA registry for the bit fields that RFC4861 standardises? >> >> Or so say it another way: >> >> If I want to use a new bit field that for instance RFC4861 specifies, how am I going to find what other RFCs has touched this, if there is no IANA registry (as far as I know there isn't, I can't find one). >> >> Someone (IETF leadership) has to put their foot down and say one of two things (or something completely different): >> >> 1. If you move reserved bits to in-sure, you update the original RFC that defined these bits as reserved. Metadata is added to the original RFC so this can be found. >> >> 2. There must be IANA registries for all bit fields, and if you change reserved bits to in-use, this must be reflected in the IANA registry. >> >> The way we do things now by not having IANA registries and not updating RFCs when changing reserved bits to in-use is extremely prone to mistakes. We missed this completely when we wrote PIO-X and it was caught because someone happened to notice it and who was into MIPv6. >> >> Or what am I missing? > > As far as I can see you are correct. > > The resolution I would prefer in this case would be that you wrote a draft instructing IANA to create the new PIO flags registry. Good idea. But Mikael does have a point: changing a "reserved" field (which is typically also specified as MBZ) to an assigned status is a substantive change to the RFC that reserved it. I wish we'd noted that in https://tools.ietf.org/html/rfc6709#section-4.2 Brian From nobody Tue Aug 15 14:13: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 9AB0B132653 for ; Tue, 15 Aug 2017 14:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V5e1qplbAHKN for ; Tue, 15 Aug 2017 14:13:27 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CD313239F for ; Tue, 15 Aug 2017 14:13:27 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 9DB772D4FD7; Tue, 15 Aug 2017 21:13:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9ACC0F7D2729; Tue, 15 Aug 2017 23:13:24 +0200 (CEST) From: Ole Troan Message-Id: <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B8FFEF62-9881-41B2-AA1E-8D51603636AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Tue, 15 Aug 2017 23:13:23 +0200 In-Reply-To: <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> Cc: Mikael Abrahamsson , Michael Richardson , 6man WG To: Brian E Carpenter References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 21:13:29 -0000 --Apple-Mail=_B8FFEF62-9881-41B2-AA1E-8D51603636AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, [...] >> As far as I can see you are correct. >>=20 >> The resolution I would prefer in this case would be that you wrote a = draft instructing IANA to create the new PIO flags registry. >=20 > Good idea. But Mikael does have a point: changing a "reserved" field = (which is typically > also specified as MBZ) to an assigned status is a substantive change = to the RFC that > reserved it. A reserved field is there for forward extensibility... How can using that extensibility (which as you state is specified as MBZ = specifically to be forward compatible) be a substantive change to the = RFC that reserved it?? > I wish we'd noted that in = https://tools.ietf.org/html/rfc6709#section-4.2 Thanks for the pointer. That section looked good to me. Best regards, Ole --Apple-Mail=_B8FFEF62-9881-41B2-AA1E-8D51603636AF 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 iQIcBAEBCgAGBQJZk2P0AAoJEL7aWKiYQt92fNgP/2Zho+11f2AcZeCxHqD+FtcU +5LQLSTl1y4XDG2XGcEzsu4XFPMK3EXV0ZcpzbOlE1QG/IYASst5mX6MqFUswKc4 KGRTS7QcJOO2izYkR26pVkcRT7aInGnzr0W+Sa5z+zjXm1l6tPHlohhxGODmUvQh IwZEwPOzF4qhYzRUpOU41dO8cWi7A4TM2+Fygl9CqsLOL0soJsixcNddUSmJO1uI H76k3cSqyZe0WtRL+C/R5bC6n06vbaCNXulHL2vUpXusHtRDfV2JTDOssOUZ82PB rvhlgRGQs7cPTxPnlp+AIoTXdObtpdSME8i1lbJdJ6AMKoe5MFEkd/AKQYw/L6zh 0v7JiofIrtNYIhP1RSHxDvcXfRK4KFzA915YMJsIbJWoT/iSVRW09yYOmBsn4eB+ hfXqJD/UsqFb2MXr/4OGppVOTf5Lus5LnOyN0oiX3cA6eYVKdg03HWDarsan4nYp poHmNfiV+wxjZqBy4m1MeKMUfGZIQZsahwq+zvXRhVSw8OR2qgExQGQX1tkYzl8a YPOYHMvl+TxqfMNx+gSubek2/izqATg+/VG4oM80Xi0Cl+zQOvuwXuaS7boTFjf9 yIjQBO0c81lUcCfmWQ1c6iP6Y+3dRrtrraRSNcZUsjrSRcuRo5n0AU6vT479t0mf 1rB+X2Zfe/1YpU+Q3m8E =0fjr -----END PGP SIGNATURE----- --Apple-Mail=_B8FFEF62-9881-41B2-AA1E-8D51603636AF-- From nobody Tue Aug 15 14:33:15 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E084132428 for ; Tue, 15 Aug 2017 14:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7gv7mknfm8Q for ; Tue, 15 Aug 2017 14:33:12 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2563613219E for ; Tue, 15 Aug 2017 14:33:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F1453AF; Tue, 15 Aug 2017 23:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502832789; bh=Iv6HT722b8Lp9lwnJMw4xhxAUCv4HxyVkTJlhRKLQ2g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iwJSvAYeLtX3frjTevhp6j6BAqEKLI0KohdCIWGb1J1ChljP5vEm92P6Qky54gXo9 dOmF1NU7vHsXIpTL+WA4BZkZvEJY1CoJ4/zMIgj0/IcCF9tTuNk2zM7tMKhhF5tW6B lo0P3I/1mHwfBm6rsFs7ldNP+24f/X5Q3TGp0JuY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EE9EE84; Tue, 15 Aug 2017 23:33:09 +0200 (CEST) Date: Tue, 15 Aug 2017 23:33:09 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Brian E Carpenter , Michael Richardson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 21:33:14 -0000 On Tue, 15 Aug 2017, Ole Troan wrote: > How can using that extensibility (which as you state is specified as MBZ > specifically to be forward compatible) be a substantive change to the > RFC that reserved it?? Because the reserved bits are no longer reserved if another RFC now says they're used for something. So for this I-D you wanted me to write. Is the request to IANA to go over 4861 and create registries for all bit fields? What other RFCs should we include in this request? Because if someone (I don't know who, IETF leadership?) has decided that "taking" bits is not an substantitive change to an RFC and that there should be no metadata updates when reserved bits are "taken", then the IANA registry is crucial for all bit fields, not just the PIO bits I was talking about here. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 15:22: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 D227813242D for ; Tue, 15 Aug 2017 15:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pHXU5myyewB for ; Tue, 15 Aug 2017 15:22:26 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72277132428 for ; Tue, 15 Aug 2017 15:22:26 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 373442D4FA1; Tue, 15 Aug 2017 22:22:25 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 18D93F7E2CAE; Wed, 16 Aug 2017 00:22:23 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F6D0319B-5AA7-4AFF-8FD9-4C634B263EE8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 00:22:22 +0200 In-Reply-To: Cc: Brian E Carpenter , Michael Richardson , 6man WG To: Mikael Abrahamsson References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 22:22:28 -0000 --Apple-Mail=_F6D0319B-5AA7-4AFF-8FD9-4C634B263EE8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, >> How can using that extensibility (which as you state is specified as = MBZ specifically to be forward compatible) be a substantive change to = the RFC that reserved it?? >=20 > Because the reserved bits are no longer reserved if another RFC now = says they're used for something. >=20 > So for this I-D you wanted me to write. Is the request to IANA to go = over 4861 and create registries for all bit fields? What other RFCs = should we include in this request? >=20 > Because if someone (I don't know who, IETF leadership?) has decided = that "taking" bits is not an substantitive change to an RFC and that = there should be no metadata updates when reserved bits are "taken", then = the IANA registry is crucial for all bit fields, not just the PIO bits I = was talking about here. with regards to change. I think the point here is that an implementor of = 4861 doesn't need to know about 6275 to implement 4861. /ot --Apple-Mail=_F6D0319B-5AA7-4AFF-8FD9-4C634B263EE8 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 iQIcBAEBCgAGBQJZk3QeAAoJEL7aWKiYQt92vqQP/20TERHZDUexrxXoFTbKHrO2 VGU9fccQRHias7ADuzRbEac2+Hehxx7YHRKXDZrSutP8bNqlWI0fKVNjMqC8M2CO pU6jojUmNW3MfzzyiBk+/e+jsWBxljPTptloPSiFQDn3Je4gUMxANnYQ0+0m1Dlu jlB8EfHUx7pfryFJTPK5YMbR6c966kRflEooj8GTLTot/rlvqu3O+3F0IcXlfG/p S17x2Rs79CLk2cen60Hs5keaATyo7GdLDSpOGGHutZgzHFWIQiaul2wxz4m1H4x2 p1FR+AfAGIAYI++fyAc93IrRSC67nezVfEjqW/iJiacerFk/T2Lr2fbUFtN7R0gK No81t2xIYgmSu6sdfnicnbPNx5pWgXP123WtAexzdUi6lxQd9lZOIQErK63yOpnZ jBG+goV6z+nu4U+Zrj1FSrJWUSGXkAD+N+eYU7N9VHHE+zDp/jQ9sl6eDHbkBU5e Qvu+k0wyAi8NGv37WNWKyMFMEgUregY2fFU6MnE4oQSktfuhR0eYYN32na09HIMn faFzx/7q6NYXwKrQ0++cS+RkBIxY72/O3jrgWkve4vizlQrU8CQn4YlRWIentVtk hu7ml+eRtbfMCBMSEyS/4FGwIIAWLHQUDFiSb0QeqmjqeV5kT1bJi/KlQM2Ulxr8 NaORfXrtNSlgJNibLVTD =ZSjo -----END PGP SIGNATURE----- --Apple-Mail=_F6D0319B-5AA7-4AFF-8FD9-4C634B263EE8-- From nobody Tue Aug 15 15:27: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 49BA613242D for ; Tue, 15 Aug 2017 15:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoPvWeXfnfDC for ; Tue, 15 Aug 2017 15:27:20 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B0FF7132428 for ; Tue, 15 Aug 2017 15:27:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 84B0E6A10D1; Tue, 15 Aug 2017 15:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1502836040; bh=Wzfq8fkkr9ifs4/XsCwPWlR6C2gSUo9ZdRi7LGx/ocA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fQRYfEB+Z7UUqDA+DDAHW4aMx3v+oLcbRqeZG3a0pg6k9hSpQuhzBu97zT7DjmbTo r8LXUeKpbRnLKfjVME/yQU+mHKkMwrkSJ3JJRE2kACzxW73tbgToshgKcoO+MRfWDl ONkRQUdcZRfM/R/WGbs0Xt3L2wi8Au6iSjXNagQY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EBB226A10C7; Tue, 15 Aug 2017 15:27:18 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: Ole Troan , Mikael Abrahamsson Cc: Michael Richardson , 6man WG References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> From: "Joel M. Halpern" Message-ID: <4ae90cdd-6d06-d15b-b3f3-2b2143d3afe7@joelhalpern.com> Date: Tue, 15 Aug 2017 18:27:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 22:27:22 -0000 I agree that an implementor of 4861 does not, technically, need to know about 6275. The more interesting problem, in the absence of a registry or updated-by flag, is how someone proposing to use one of the reserved bits in 4861 is supposed to know which bits are available? Yours, Joel On 8/15/17 6:22 PM, Ole Troan wrote: > Mikael, > >>> How can using that extensibility (which as you state is specified as MBZ specifically to be forward compatible) be a substantive change to the RFC that reserved it?? >> >> Because the reserved bits are no longer reserved if another RFC now says they're used for something. >> >> So for this I-D you wanted me to write. Is the request to IANA to go over 4861 and create registries for all bit fields? What other RFCs should we include in this request? >> >> Because if someone (I don't know who, IETF leadership?) has decided that "taking" bits is not an substantitive change to an RFC and that there should be no metadata updates when reserved bits are "taken", then the IANA registry is crucial for all bit fields, not just the PIO bits I was talking about here. > > with regards to change. I think the point here is that an implementor of 4861 doesn't need to know about 6275 to implement 4861. > > /ot > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Aug 15 15:56: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 C3224132428 for ; Tue, 15 Aug 2017 15:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJollZIAa3ak for ; Tue, 15 Aug 2017 15:56:19 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B640D132439 for ; Tue, 15 Aug 2017 15:56:19 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id u185so14193907pgb.1 for ; Tue, 15 Aug 2017 15:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VRPzldn4hdWhjvucjPWk5PWbgxBAE0GoSDNv/w4W1js=; b=qfxfCkt1hX41w9pZDL9wvT28e/8/J9Q9Fnb6BAymbGlq9uY61BO5HQtn2h+6sgArSx /IDJe02mv8Pj4mJGLwkVZvIK2tCSHozVwWs4Dv3Pi8R5NnJP9ZmfB0VAVMYP/98Mc8IF nXtP2nfBzJxMJUDQWxzhVxgGnIYUr57pENcC4d+kaJXvB5Mzh4B0qb7nCqLmZ9/Ju8W8 KsAVF37Zy1rBakn+3rdRlrUnD8voU5zJRZJzqyL2ktuG0JqEg0LuHYiExR7oZ5mAs/dp 3MUdAPXN+jteBTmYUqlSWxvnWTAUBNNVE2NRyTpFGYCRW164/7nWJ7IMmTMzAZykhBVk 0E7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VRPzldn4hdWhjvucjPWk5PWbgxBAE0GoSDNv/w4W1js=; b=Ph2966Ib62bury1oh0sq1PwrWbpKL8ot/ahQSHLXCbLFhAMuVzxOrZ9KHu01D1LJAY L4YCyo3Q1YpcLtmizU4dfKrPHlMZh6DdxNDr9aS8hvh1NDzisFTJ9lVpwhItYD/xvJyy KrSQHxI+2kp4vchL6s7LFprbwOaFITbMg39seXDlsJHXcpRbxUUmjHBGwQdrSWk4Y/9m k354r6XbFHW3Jxx6foGqbu46KMDj95QlNU0g82sUMfKtkXu+zNXg953+2zbAeDt87EGi w9b9fvqldobFxKxp6W2ApEaN3Jzc8ZETYuBenpQqdSF9+dvrXOsAqHyxtD9uCoV9KRTs MrDg== X-Gm-Message-State: AHYfb5iSbY6PqwJAU4fnxC8yCGMnLgHS123WGjkD74K2fiLh2dYoqpQT zGp6peBkrdusUGJZ X-Received: by 10.84.214.151 with SMTP id j23mr33636957pli.322.1502837778958; Tue, 15 Aug 2017 15:56:18 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q89sm19792372pfd.156.2017.08.15.15.56.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 15:56:18 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: ipv6@ietf.org References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <4ae90cdd-6d06-d15b-b3f3-2b2143d3afe7@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com> Date: Wed, 16 Aug 2017 10:56:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4ae90cdd-6d06-d15b-b3f3-2b2143d3afe7@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 22:56:22 -0000 On 16/08/2017 10:27, Joel M. Halpern wrote: > I agree that an implementor of 4861 does not, technically, need to know > about 6275. > > The more interesting problem, in the absence of a registry or updated-by > flag, is how someone proposing to use one of the reserved bits in 4861 > is supposed to know which bits are available? And how does a person *maintaining* an existing implementation of 4861 know that something has changed, so their code might be out of date? This is quite similar to one problem we tried to deal with in RFC 7045. How do product maintainers know that a new extension header has been standardised? In some ideal world, one could sign up to get a warning whenever something changes in specified IANA registries. This problem is much wider than IPv6, of course. Brian > > Yours, > Joel > > On 8/15/17 6:22 PM, Ole Troan wrote: >> Mikael, >> >>>> How can using that extensibility (which as you state is specified as MBZ specifically to be forward compatible) be a substantive change to the RFC that reserved it?? >>> >>> Because the reserved bits are no longer reserved if another RFC now says they're used for something. >>> >>> So for this I-D you wanted me to write. Is the request to IANA to go over 4861 and create registries for all bit fields? What other RFCs should we include in this request? >>> >>> Because if someone (I don't know who, IETF leadership?) has decided that "taking" bits is not an substantitive change to an RFC and that there should be no metadata updates when reserved bits are "taken", then the IANA registry is crucial for all bit fields, not just the PIO bits I was talking about here. >> >> with regards to change. I think the point here is that an implementor of 4861 doesn't need to know about 6275 to implement 4861. >> >> /ot >> >> >> >> -------------------------------------------------------------------- >> 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 Tue Aug 15 16:56: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 E6D111323AC for ; Tue, 15 Aug 2017 16:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vEXhqjmC_d13 for ; Tue, 15 Aug 2017 16:56:13 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D3E13232D for ; Tue, 15 Aug 2017 16:56:13 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3A55F34A711; Tue, 15 Aug 2017 23:56:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2B485160067; Tue, 15 Aug 2017 23:56:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 19F78160070; Tue, 15 Aug 2017 23:56:10 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9PDqn9FeECuP; Tue, 15 Aug 2017 23:56:10 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 94453160067; Tue, 15 Aug 2017 23:56:09 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7D7318277CAA; Wed, 16 Aug 2017 09:56:07 +1000 (AEST) To: Brian E Carpenter Cc: ipv6@ietf.org From: Mark Andrews References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <4ae90cdd-6d06-d15b-b3f3-2b2143d3afe7@joelhalpern.com> <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com> Subject: Re: RFC 4861 missing updated-by In-reply-to: Your message of "Wed, 16 Aug 2017 10:56:18 +1200." <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com> Date: Wed, 16 Aug 2017 09:56:07 +1000 Message-Id: <20170815235607.7D7318277CAA@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:56:15 -0000 In message <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com>, Brian E Carpenter writes: > On 16/08/2017 10:27, Joel M. Halpern wrote: > > I agree that an implementor of 4861 does not, technically, need to know > > about 6275. > > > > The more interesting problem, in the absence of a registry or updated-by > > flag, is how someone proposing to use one of the reserved bits in 4861 > > is supposed to know which bits are available? > > And how does a person *maintaining* an existing implementation of 4861 > know that something has changed, so their code might be out of date? > > This is quite similar to one problem we tried to deal with in RFC 7045. > How do product maintainers know that a new extension header has been > standardised? In some ideal world, one could sign up to get a warning > whenever something changes in specified IANA registries. Well we just poll the registries we are worried about daily and if there is a change we generate a email message. There are not a lot of companies in the world that look at these registries. > This problem is much wider than IPv6, of course. > > Brian > > > > > Yours, > > Joel > > > > On 8/15/17 6:22 PM, Ole Troan wrote: > >> Mikael, > >> > >>>> How can using that extensibility (which as you state is specified as MBZ > specifically to be forward compatible) be a substantive change to the RFC th > at reserved it?? > >>> > >>> Because the reserved bits are no longer reserved if another RFC now says > they're used for something. > >>> > >>> So for this I-D you wanted me to write. Is the request to IANA to go over > 4861 and create registries for all bit fields? What other RFCs should we inc > lude in this request? > >>> > >>> Because if someone (I don't know who, IETF leadership?) has decided that > "taking" bits is not an substantitive change to an RFC and that there should > be no metadata updates when reserved bits are "taken", then the IANA registry > is crucial for all bit fields, not just the PIO bits I was talking about her > e. > >> > >> with regards to change. I think the point here is that an implementor of 4 > 861 doesn't need to know about 6275 to implement 4861. > >> > >> /ot > >> > >> > >> > >> -------------------------------------------------------------------- > >> 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 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Aug 15 19:00: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 D9F3C13243A for ; Tue, 15 Aug 2017 19:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHAGSGpLSbYn for ; Tue, 15 Aug 2017 19:00:27 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6474132430 for ; Tue, 15 Aug 2017 19:00:27 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id 77so1687626itj.4 for ; Tue, 15 Aug 2017 19:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wvaJTmAUy7ewpn5m1mpfeF6Qk7GnvtynSKPaw1KPHI=; b=hhrlnVmbQ8Q2hsFh+KQIRT6lBRtVMIY9Vv7s+6LFBL0kpFKUqZYEYd6SHFFB556JP4 8gsHlFnbLlTCf2raxMeiidjN4S+EeVGAKicE2GGdKtGIw0GLjZ6AzkomyHpEVSJAPBih C7ZGBJ0DFfpcR/s0nbdaxvV0ngjlsACVzzheLMQArmWGaSDGTAhRzKNG8PL7p0g2FFvX AtmtPk2lJRJKl9tMzQU3VBtfdhk60pHuZZoIYGwAUBn3X4L3b+/RWUBLPujgN1WS2Jyg 6G1hln57CyczM2PmKkQznTncQLnxcN4slgonPMZzjWg+9uDUhuZD9mM9yCtirpn9yeqh iVAg== 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=2wvaJTmAUy7ewpn5m1mpfeF6Qk7GnvtynSKPaw1KPHI=; b=MHNKAI3lDZwvioHPXXUXJyVlGswc9PBESKbhgfACzFTw1Da4YG74E3mof/G7BksQ3t losaxzuGiRUKGkf260zbr+57MGiptx16SgT0Lt5TwGgUvvKAMpXlLxZfj7pNy3byVSQj 0qH/V/jdY8/ST93o8WJKqHfXJbOwowNdGK9iuQPWN/bFxLm9gUxaZ1pkiM7xxBKvsTul +ctwbXVr76u65nJ13A3nhN2fPt7cCTJIfby52qRh144+Wc0sYtJwBiJgA/cqe+THIkUf 8soEBNgicgB5QaTz80fjq540hJgddaelGj5rXB6R2zWhZgSGRv04i14ChBcckaz1vrPV N5jQ== X-Gm-Message-State: AHYfb5hmVIj4J4orcOCpnVito2ZnoproPRCOiYw77crxZP6SC7B+d4lr XmHSBWlH6I2ltg== X-Received: by 10.36.225.135 with SMTP id n129mr502407ith.160.1502848826889; Tue, 15 Aug 2017 19:00:26 -0700 (PDT) Received: from [10.0.1.130] ([199.119.129.146]) by smtp.gmail.com with ESMTPSA id s66sm26925ita.9.2017.08.15.19.00.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 19:00:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by From: Suresh Krishnan In-Reply-To: Date: Tue, 15 Aug 2017 22:00:22 -0400 Cc: Ole Troan , Michael Richardson , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <3B5B4B06-92F3-4347-B5BE-D77DC98F5F02@gmail.com> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 02:00:30 -0000 Hi Mikael, I understand and agree with your point and I made the same point about = 11 years ago regarding RA flags :-) https://www.ietf.org/mail-archive/web/ipv6/current/msg06561.html =20 Quoting from there=20 "In a slightly related note, I feel that any document which is assigned = one of these flags MUST be indicated as updating the ND specification = (RFC2461/RFC2461bis). If this is not done it is highly likely people = would assume that those bits are unallocated. e.g. RFC3775, RFC4191 and = RFC4389 use these flag bits but do not update RFC2461. So a new draft = author may wrongly assume the bit to be available for use. I saw a = presentation in the 16ng meeting where the authors were trying to reuse = the MIPv6 Home agent bit for their proposal.=E2=80=9D To be very frank, we have usually identified these issues whenever = people wanted to extend these fields, and (thankfully) have not run into = an actual conflict. I do think this is a problem that is wider in scope = than 6man and we need to solve it in a systematic manner. I think the = first step would be to have a common understanding of what an Update: is = supposed to signify and get community consensus on that so that we can = apply these rules in a consistent manner. I have now volunteered to help = out on a document in this space. Thanks Suresh > On Aug 15, 2017, at 5:33 PM, Mikael Abrahamsson = wrote: >=20 > On Tue, 15 Aug 2017, Ole Troan wrote: >=20 >> How can using that extensibility (which as you state is specified as = MBZ specifically to be forward compatible) be a substantive change to = the RFC that reserved it?? >=20 > Because the reserved bits are no longer reserved if another RFC now = says they're used for something. >=20 > So for this I-D you wanted me to write. Is the request to IANA to go = over 4861 and create registries for all bit fields? What other RFCs = should we include in this request? >=20 > Because if someone (I don't know who, IETF leadership?) has decided = that "taking" bits is not an substantitive change to an RFC and that = there should be no metadata updates when reserved bits are "taken", then = the IANA registry is crucial for all bit fields, not just the PIO bits I = was talking about here. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Aug 15 22:23: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 C2C5B1321F5 for ; Tue, 15 Aug 2017 22:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 qEBH3uz43cnd for ; Tue, 15 Aug 2017 22:23:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFCA132412 for ; Tue, 15 Aug 2017 22:23:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 177DAAF; Wed, 16 Aug 2017 07:23:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502861016; bh=yS3BxHRx8dziwBYHgW4dPlLVfdPZGJTKk7AVMSQKqv8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=NvitZUwGqrjT2Tq8gQIFJWSCAFgqYx/zPZIOhz1d6CWWP3nfIbydQHnZCI1xvClCQ zhC0HA9CvY8VPDKEnLk+m1qNioiknUDTHe8GD9E0u/B1MpDhiFWlgqsOgKkeo7WBpt n3Kmc2ovSdO5xVziGeCr8Ie+9SEf//F2VL4bLSFA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 151D984; Wed, 16 Aug 2017 07:23:36 +0200 (CEST) Date: Wed, 16 Aug 2017 07:23:36 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 05:23:42 -0000 On Wed, 16 Aug 2017, Ole Troan wrote: > with regards to change. I think the point here is that an implementor of > 4861 doesn't need to know about 6275 to implement 4861. But is this really a valid reason? Wouldn't it potentially be better for an 4861 implementation to at least be aware of the R flag, potentially? Is the implementor better kept in the dark about this, than to have to spend a minute to see if some aspect of RFC6275 might apply to it? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 01:35: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 981DC1323AD for ; Wed, 16 Aug 2017 01:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibI0r50WNLdn for ; Wed, 16 Aug 2017 01:35:32 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3081D124207 for ; Wed, 16 Aug 2017 01:35:32 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 217652D4FD0; Wed, 16 Aug 2017 08:35:30 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 26D0BF8042AD; Wed, 16 Aug 2017 10:35:33 +0200 (CEST) From: Ole Troan Message-Id: <4AF70B52-2167-40C2-AF4D-1D389E943BBE@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_98B16BC7-4F03-4951-A5FB-51C7E8112581"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 10:35:32 +0200 In-Reply-To: <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com> Cc: 6man WG To: Brian E Carpenter References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <4ae90cdd-6d06-d15b-b3f3-2b2143d3afe7@joelhalpern.com> <7f29fecd-7790-0f04-07d4-d7361d9ee0f9@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:35:34 -0000 --Apple-Mail=_98B16BC7-4F03-4951-A5FB-51C7E8112581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >> I agree that an implementor of 4861 does not, technically, need to = know >> about 6275. >>=20 >> The more interesting problem, in the absence of a registry or = updated-by >> flag, is how someone proposing to use one of the reserved bits in = 4861 >> is supposed to know which bits are available? >=20 > And how does a person *maintaining* an existing implementation of 4861 > know that something has changed, so their code might be out of date? That's the point. The 4861 implementation is not out of date. Not by = 6275 nor by PIO-X. If a 4861 implementation was required to change then an update would = have been appropriate. Cheers, Ole --Apple-Mail=_98B16BC7-4F03-4951-A5FB-51C7E8112581 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 iQIcBAEBCgAGBQJZlAPUAAoJEL7aWKiYQt92goIQAKp47uXENDtkTl+fKKvo6yNO yFFtNfOsslIcaK3RcETPPYQa8lIjITrzxqqVEnZ6TlQzYfLR0I0nIhGzCSh1P184 d5rArfKhSmtCaD6wBZ1cHtfTLzWW9H12duKkFKAAWqX7EMR977UWextgLy6GYGC+ CkF1FcAn27Vbc5/atMh1M1QlRZBNc4PtwEvROSMYIDcEh55dFkTtTK/7Isckjsu3 7ldRgJkScvApyZmygviihiNE2mvPcAcmJRwSc+WtTzuh3YWmQ6NKXVyeSHx18GbB jdQ+AS0e9McDqmyXaZqmBiq0A4Y+x+1Aj+i/aJsMkC2PCwoWbmTYsHCdzEo4z3kP ogUwwvh+7KJTtdUNm7V6IRrSC5GXcK8n424E0SwEnHn9CTrxjr6YoAHDhwHAeC8g oucrUJjcrAJNELq46x4la3p/pfzNVoGRQVp1HLFfjt4X5tC2aTkvNDM4KHqyY6ds IJUtvmaa05gkh/rCOCehhs0Ig/UYA1tiHM0h8nNSKMzhjwlT/B/pre3svVD5NyBG FShLp3fqvvczOecG2a0IPi0y6COme880js3u9qwhE+hKz8c3LB7gB/CToxw26r2F rPQGTVkI8/hD4MH6p+7siCWbXbbgqs/xx6z1wEhBuwV8XvBHEOeiKQgNI7LAvcir VHJda2gL0xq4dmz5fqTg =O47u -----END PGP SIGNATURE----- --Apple-Mail=_98B16BC7-4F03-4951-A5FB-51C7E8112581-- From nobody Wed Aug 16 01:40:18 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E75124207 for ; Wed, 16 Aug 2017 01:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g5Mnu0D40eIF for ; Wed, 16 Aug 2017 01:40:14 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9319132641 for ; Wed, 16 Aug 2017 01:40:14 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 410B32D4FD3; Wed, 16 Aug 2017 08:40:14 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 64512F805A09; Wed, 16 Aug 2017 10:40:17 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8E38180F-C122-4992-9BC4-3ACD79A77FCE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 10:40:17 +0200 In-Reply-To: Cc: 6man WG To: Mikael Abrahamsson References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:40:17 -0000 --Apple-Mail=_8E38180F-C122-4992-9BC4-3ACD79A77FCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, >> with regards to change. I think the point here is that an implementor = of 4861 doesn't need to know about 6275 to implement 4861. >=20 > But is this really a valid reason? Wouldn't it potentially be better = for an 4861 implementation to at least be aware of the R flag, = potentially? Is the implementor better kept in the dark about this, than = to have to spend a minute to see if some aspect of RFC6275 might apply = to it? If an 4861 implementation is not affected by the other specification = (6275) then I think using update is wrong. (I don't think you should make too many assumptions about the level of = darkness that implementors live in...) Cheers, Ole --Apple-Mail=_8E38180F-C122-4992-9BC4-3ACD79A77FCE 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 iQIcBAEBCgAGBQJZlATxAAoJEL7aWKiYQt92hPgQAIxtTq89gOCW6zT0Zi44hBAR AAduoLTR09yZeMNduU+dcWaaz96v5Ha3idn79VvNJaSHevK7veQhCOw7T/87rduF LwiqzdSYoqTMl5D6IRovXnBAmG1tIPBSw5ORlnkvY6B8TPsdOyrSCdGQIDWPhrTK Lx3Jv/te0ov/OIywmqdv6PIHEv98L+slBFl9TZUdWHquWlw385uh5Ok9WkqHy+NF puoAWEmk9tShNhzmy8Vta+UUDVMRg0kebj4f0fJKmSjV5W7bDibjZQT4IGO5dGvU 6LRFalREPLSCw9JUav3s4H2iOHpbKW4tOOmL7HUkl4FyUfYoSEhLzVaQ3Q7t8mja HPHHZEdx12kf6yCdeZwEWUytNMvW6vwUcmKUFkaQmhBga7rz+ocVfan+r10RfJn0 d3u7wmUdh6ez0P5t/8T6sJRLCMD6rDEDKwVvd7v6B0YazMwi/JCDwXrx5l7cRK9L Qvy3klRteTEJx4mGPUZq5eE+LlircboQtJT0B6yYWF8Ys4QATeMqpSj0KPAz5Iqh JkBdWDLjn/vHfvO6EGu0wyqAb4m1yFqdvZqKWzsQAIGxTbznC21tG0hmfW6mADsT /+ugLurfjil0AmdistzUF06NebsWc39eBGfNIumumGGaZj0LlPM7tD1jwdA1GCKO +a6WUJZk9CmOtORuDyVU =ZJfP -----END PGP SIGNATURE----- --Apple-Mail=_8E38180F-C122-4992-9BC4-3ACD79A77FCE-- From nobody Wed Aug 16 01:48: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 4F68C132677 for ; Wed, 16 Aug 2017 01:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 OxbFsHbhRZCf for ; Wed, 16 Aug 2017 01:48:10 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F84132641 for ; Wed, 16 Aug 2017 01:48:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ACB3FAF; Wed, 16 Aug 2017 10:48:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502873287; bh=aVMEBW+AMbAvgL798TPsWlvym52Epg69lR881VBpex0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=C7X41q7UQUBu+UIoTSZjdYAIuyty9POuDo8jpBWkGOpDHbfpKd3mFlSJjs8wXi7+D bry0LIZf43uPaG1OrEhpgsFI94OYkdl8pr7KNlB6roW5egz7HN/ECEMFUcuH4xoGyi Esm5OjF0WUzmNMHtMtP6MRhaJIJ0pqNR0cN43nPY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A8DDD84; Wed, 16 Aug 2017 10:48:07 +0200 (CEST) Date: Wed, 16 Aug 2017 10:48:07 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:48:12 -0000 On Wed, 16 Aug 2017, Ole Troan wrote: > > If an 4861 implementation is not affected by the other specification > (6275) then I think using update is wrong. (I don't think you should > make too many assumptions about the level of darkness that implementors > live in...) I still think there should be some kind of forward reference to the document that has assigned or changed bits. If we can't use updated-by, then we need to invent some other kind of reference. The way things are right now, things will be missed and there will be multiple uses of the same information. I'm surprised this hasn't happened more often. I especially think the risk will increase as more of the people who have been here a long time goes into retirement and their first-hand knowledge isn't available anymore. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 01:51:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F240132641 for ; Wed, 16 Aug 2017 01:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu9PN8KrqQdK for ; Wed, 16 Aug 2017 01:51:28 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F1D1323C8 for ; Wed, 16 Aug 2017 01:51:28 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 288622D4FD3; Wed, 16 Aug 2017 08:51:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 51170F808E9E; Wed, 16 Aug 2017 10:51:31 +0200 (CEST) From: Ole Troan Message-Id: <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_93F0A619-85EC-430B-BB3E-D696EF245E51"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 10:51:31 +0200 In-Reply-To: Cc: 6man WG To: Mikael Abrahamsson References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:51:30 -0000 --Apple-Mail=_93F0A619-85EC-430B-BB3E-D696EF245E51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, >> If an 4861 implementation is not affected by the other specification = (6275) then I think using update is wrong. (I don't think you should = make too many assumptions about the level of darkness that implementors = live in...) >=20 > I still think there should be some kind of forward reference to the = document that has assigned or changed bits. If we can't use updated-by, = then we need to invent some other kind of reference. I don't think that works. Think of RFC3315 as an example. Should it have a forward reference to = every DHCP option? > The way things are right now, things will be missed and there will be = multiple uses of the same information. I'm surprised this hasn't = happened more often. I especially think the risk will increase as more = of the people who have been here a long time goes into retirement and = their first-hand knowledge isn't available anymore. That's what an IANA registry is for. Don't assume implementors are idiots. The reason why they don't do what = you want are typically not because of lack of intelligence or reading = skills. ;-) Best regards, Ole --Apple-Mail=_93F0A619-85EC-430B-BB3E-D696EF245E51 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 iQIcBAEBCgAGBQJZlAeTAAoJEL7aWKiYQt92Ro4QAKj6bsJOWXLVWvSMULm6uWmG usNxFM6nJlV4v1w+xxlqp2//KqbAeLuk6wUx6xHQOA3XFCNvrK9L8AXJkdNTfStV n4lPIMiZFIApSrFh83/Ev3g/n14p8fUs64hb3lcHdEPjI/ig0W1bvy+n98pKVgeY pT1OpmyzYw+BfoQOXPAfOwFhRdgnbNY6q5H8LK1r0FTA6mNHaWXMRNrUAK/xwQaR ysmWhitjIWAl2jI7e9wErj6Tzvaj4qxcQ1giAJ0piptc+ojRwAd/FcKSeynCvJNU g5YidP5rlIV30xVekxSau1UfnBUVl9SYQT2P1ZKO8IX5uyglXfqiWyMjMXaWfy9f 84eFBUKak4zdIsOkbLDifjCFBTlmHQ/IXDPgt1d1jsIM9s+zg3i0bN9oR/TlY3Jd bN9xhqAW3zeQYQRB3G6tD85bYKFA+O6xagqTF9PgWzbQv6esuENe0BoWoeEoAM0o nUNNKhBsmY05z5GsKRLBULnrchGvguBE0VB+XiQX/6RF7mzr5QnAEPYYGVTDsSo4 guw81cUui9GJYviQLs+kGFefhPT8FWAi9e1pjsMiXnz+0ubJ5+lEp0Na1mxiOS+u 9Tgxh9QRG3EjqwIRn0idc78OP9SY+E6CKZSqlJrxekcVQlPdC5+FL//1E5isjbii gpepVFX22hMjr/Vr6iq/ =Uisy -----END PGP SIGNATURE----- --Apple-Mail=_93F0A619-85EC-430B-BB3E-D696EF245E51-- From nobody Wed Aug 16 02:18: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 34DDD1324BE for ; Wed, 16 Aug 2017 02:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CNktyYCRDg7 for ; Wed, 16 Aug 2017 02:18:36 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34D1132422 for ; Wed, 16 Aug 2017 02:18:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6BEC749; Wed, 16 Aug 2017 11:18:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502875110; bh=NSuZMINraBLcoc5BN1j Y4yWgGOtAV6znzeE24ETP7fw=; b=d14tVZBXRTCwD+TeDAtswbirAg7wOspfB20 MG1w7crdfRop1oAZYRvh/AuE+jczc/quUA+TvKpRVUOb6yL6XKDWy5rPUeDM3icp BQWYBoHU/x0fqwpUsDv0V6WnN+8ew8F0QCGJ8ZxYoqWiNtPk8OhREQ/wO2NKqjC9 C4Pee7R8= 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 qKO08uT5ZAs0; Wed, 16 Aug 2017 11:18:30 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157] (unknown [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5AC433C; Wed, 16 Aug 2017 11:18:30 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_E4018199-A80F-464F-9A7A-3F31D5B72555"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 11:18:29 +0200 In-Reply-To: <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> Cc: Mikael Abrahamsson , 6man WG To: Ole Troan References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:18:38 -0000 --Apple-Mail=_E4018199-A80F-464F-9A7A-3F31D5B72555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ole, >> I still think there should be some kind of forward reference to the = document that has assigned or changed bits. If we can't use updated-by, = then we need to invent some other kind of reference. >=20 > I don't think that works. > Think of RFC3315 as an example. Should it have a forward reference to = every DHCP option? I think there is a difference here between adding new options (where = there is a clear expectation of new options being developed and the = original RFC pointing to the registry) and using a reserved bit-field = (which changes the meaning of an existing bit from "doesn't mean = anything (yet)" to "means X"). >> The way things are right now, things will be missed and there will be = multiple uses of the same information. I'm surprised this hasn't = happened more often. I especially think the risk will increase as more = of the people who have been here a long time goes into retirement and = their first-hand knowledge isn't available anymore. >=20 > That's what an IANA registry is for. For options: yes. For bit fields: an IANA registry is not where I would = look for possible changes to each and every field. > Don't assume implementors are idiots. The reason why they don't do = what you want are typically not because of lack of intelligence or = reading skills. ;-) As an implementor I have been confused about the meaning of bits with = only Google to help in finding what it means. My personal preference = would be to have an updated-by references for such changes. I agree that = this isn't feasible for option codes and things like that because of the = possibly huge number of options, but for updates to fields I think it is = the right place. Cheers, Sander --Apple-Mail=_E4018199-A80F-464F-9A7A-3F31D5B72555 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----- iQEcBAEBCAAGBQJZlA3lAAoJEKAtA7D+JBO5yNoH/jmPoMCaI379IdUCDOJWWhjZ GkwSDJjwPtPPV42/jQBIILwZS3IKwEQ7KP72Eq+m5eUc6NAh6PJcR6D5tzz4NiFQ XjzDh4dY4IPhjqet+ZLwD20YiokdfQx6D9YZw0jB33m2gI4s2w2XvYesbqTMnMQg /lMarebUia0ROcdKqXSZRYTmA1Whl+MIH9RUuYDDxrpWQONlM/NjvJrDzedRXQFo +tROXSJa/0e2G7MNbs4jCeWmbcadNxKsdLQLPsuWHjk6nUU6oIBC53NlxyVgDNMn aAtsD19djbOL57DYu41gTBWYfE7t0OXTeEQi6neHLM11R5iOV3+wIea5wk6Zp9U= =wvby -----END PGP SIGNATURE----- --Apple-Mail=_E4018199-A80F-464F-9A7A-3F31D5B72555-- From nobody Wed Aug 16 02: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 DEEE71200B9 for ; Wed, 16 Aug 2017 02:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 VtFVKx-gFe5e for ; Wed, 16 Aug 2017 02:31:37 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D94132031 for ; Wed, 16 Aug 2017 02:31:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 20669AF; Wed, 16 Aug 2017 11:31:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502875895; bh=xavIT3o9BhBvkqY+jQcK/MiGkb5U7zVGWQ3c2pjjS3A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y9diUJLAS02edjwddJes4Tsy6qlaxEQML+eN5oEjABmNJCPDLEK2RBJKWd4tRBFbM h9CUqDuVkli5BdrIjLMdsdT05XvmDgofA1G8vE90eaNeQSqG+t0pstZ/jcrHBslP7r cn777CzZRHMnO8XXylZ5/KxMOLNMjOrgMG5y1+r0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1DC4E84; Wed, 16 Aug 2017 11:31:35 +0200 (CEST) Date: Wed, 16 Aug 2017 11:31:35 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> Message-ID: References: <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:31:39 -0000 On Wed, 16 Aug 2017, Ole Troan wrote: > Don't assume implementors are idiots. The reason why they don't do what > you want are typically not because of lack of intelligence or reading > skills. ;-) I've never assumed implementors are idiots. It seems to me that you're the one treating them as idiots, in that they can't handle an updated-by reference. My problem is that from a document writer perspective, me and Erik sat there and was looking for a reserved bit field to put a flag. We looked at 4861, saw no relevant updated-by documents, and chose one of the reserved bits. I still don't see what we could have done better as a document writer. Yet here we are, 10 months after I initially brought this up, and the IANA registry still doesn't list 6275 for the PIO option, we still have no updated-by references or anything. This is going nowhere really slowly. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 02:56: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 D921C132320 for ; Wed, 16 Aug 2017 02:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 JzLqMUhT_pyd for ; Wed, 16 Aug 2017 02:56:54 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 40CC3132063 for ; Wed, 16 Aug 2017 02:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B04EE49; Wed, 16 Aug 2017 11:56:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502877405; bh=vZr83iz2zpq450m5Jz3 VlPdIoD/Sb0xIoPcP9HUTK3w=; b=gIyMyjq+QvkVdd9xGTnPsDyk7j0aqDifCwK 1G+3vKwigXSrX7D9phv1+RZL4CMlQfA1OL5cDKovZRm2QnW0yQmLqCyv+4Thk5vu YdB1dlH2lEMEVCtnSAFAB4tE2Rb9QEqA/Efv5i4EWAv+vUBMg2QanNmIGGjX/N7L bIegKDwc= 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 8DUuuza4w4sY; Wed, 16 Aug 2017 11:56:45 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157] (unknown [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 690FC3C; Wed, 16 Aug 2017 11:56:44 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_95AFBAA2-0F91-4573-B04D-769DDC2E765B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 11:29:01 +0200 In-Reply-To: <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> Cc: Mikael Abrahamsson , 6man WG To: Ole Troan References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:56:56 -0000 --Apple-Mail=_95AFBAA2-0F91-4573-B04D-769DDC2E765B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Sorry for replying to myself. > As an implementor I have been confused about the meaning of bits with = only Google to help in finding what it means. My personal preference = would be to have an updated-by references for such changes. I agree that = this isn't feasible for option codes and things like that because of the = possibly huge number of options, but for updates to fields I think it is = the right place. After some more thought I came up with the following "definition": = defining a new option is just using the field for what it was designed = for, so that doesn't update the meaning of anything in the original RFC. = The field was specified to contain an option code, and still does. Using = a bit that was previously reserved changes the meaning of that bit and = therefore does update the original RFC. Does that make sense? Cheers, Sander --Apple-Mail=_95AFBAA2-0F91-4573-B04D-769DDC2E765B 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----- iQEcBAEBCAAGBQJZlBBdAAoJEKAtA7D+JBO5oLcH/ijrt1wSlqTHff/FiUkeSbuz IYSrxZi7ymBy5uJAsKK9TwbmuSe1QqHecpY0pLXj08N2jyGIUqr+y6jT0jATJEvW zPtWz0NcDy1iv6DVax/oFCGBg5/0N8R/74THzmW0GjH9QTnl+NbxsulARC4AifEw +kWjCJpzdhbJ1d+3r1+Jx50JOAGoOJQKN/mmGe3YLh1RqqCG5Ouxym4FlAQltUZ3 fQeJ1yi7K1tXC6sp1u3/kbh+BVkMg6AeAd3Mw2566eVEEEwy7cIEhzcxaSkau7EO Jm/dHoN0R6XNi4AkwWYNsAS60iJbCrB3A7lOQ7ywre0CzBxHCLNwnk6dyCC2RPE= =MUO7 -----END PGP SIGNATURE----- --Apple-Mail=_95AFBAA2-0F91-4573-B04D-769DDC2E765B-- From nobody Wed Aug 16 03:52:33 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98371323FC for ; Wed, 16 Aug 2017 03:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R5myRfkKPb8 for ; Wed, 16 Aug 2017 03:52:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 14F2B132139 for ; Wed, 16 Aug 2017 03:52:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dhvw4-0000EdC; Wed, 16 Aug 2017 12:52:28 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: RFC 4861 missing updated-by From: Philip Homburg Sender: pch-b7900FA3D@u-1.phicoh.com References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> In-reply-to: Your message of "Wed, 16 Aug 2017 11:29:01 +0200 ." <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> Date: Wed, 16 Aug 2017 12:52:28 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 10:52:33 -0000 >After some more thought I came up with the following "definition": = >defining a new option is just using the field for what it was designed = >for, so that doesn't update the meaning of anything in the original RFC. = >The field was specified to contain an option code, and still does. Using = >a bit that was previously reserved changes the meaning of that bit and = >therefore does update the original RFC. > >Does that make sense? The obviously bad thing is to allocate a bit in an RFC and not telling anyone about that beyond publishing the RFC. So there seem two ways around that: 1) the RFC that allocates the bit explictly updates the RFC that introduced the field. Of course this requires the rfc editor to accuratly track this. 2) the RFC that introduces the field opens an IANA registry for the field. When reading RFCs, those two seem roughly equivalent. If you read an RFC and it is updated by a few other RFC, you need to quickly skim those to see if they are relevant. If an RFC introduces an IANA registry then a quick check at IANA is in order. Of course it doesn't make sense to open lots of IANA registries on the off chance that some future RFC will need to allocate a bit. Likewise, it doesn't make sense to have an RFC that is updated by dozens of other RFCs just to allocate some bits. Given the relatively high overhead of publishing an RFC that introduces an IANA registry for RFC 4861, it may make sense to just mark RFC 4861 as updated. From nobody Wed Aug 16 03:59: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 539E5132498 for ; Wed, 16 Aug 2017 03:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 U9qOeuog97aJ for ; Wed, 16 Aug 2017 03:59:54 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E34132472 for ; Wed, 16 Aug 2017 03:59:54 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id E4E252D4FD7; Wed, 16 Aug 2017 10:59:52 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5982EF827C37; Wed, 16 Aug 2017 12:59:50 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_615B2C39-7757-4CF0-837B-F731D8485052"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 12:59:49 +0200 In-Reply-To: <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> Cc: Mikael Abrahamsson , 6man WG To: Sander Steffann References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 10:59:56 -0000 --Apple-Mail=_615B2C39-7757-4CF0-837B-F731D8485052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sander, >> As an implementor I have been confused about the meaning of bits with = only Google to help in finding what it means. My personal preference = would be to have an updated-by references for such changes. I agree that = this isn't feasible for option codes and things like that because of the = possibly huge number of options, but for updates to fields I think it is = the right place. >=20 > After some more thought I came up with the following "definition": = defining a new option is just using the field for what it was designed = for, so that doesn't update the meaning of anything in the original RFC. = The field was specified to contain an option code, and still does. Using = a bit that was previously reserved changes the meaning of that bit and = therefore does update the original RFC. >=20 > Does that make sense? I don't think that is necessary for MBZ fields. Reserved This field is unused. It MUST be initialized to zero by = the sender and MUST be ignored by the receiver. /ot --Apple-Mail=_615B2C39-7757-4CF0-837B-F731D8485052 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 iQIcBAEBCgAGBQJZlCWmAAoJEL7aWKiYQt92xFsP/RD8qHk8r+VdaUN8UeBhzj/6 VDWbmlj1r1UTECLFqNrb9kGYx11in2NBvU1f7Tp8TvVnBvDwMROb7OnHNWlP5fAB cetYSDV1dfWCktYbg7jPkFM8HPYcREz7X0e3++uYW4Cne474hPvGfpTArsIiiPz7 GGz5uohAe4rNtxlfboYP594Bj8OTNfSOBSPY8ecjKqy0kpbYNY5jf9GUmrVmhrBz YYSjsqHzKz18k14XODwxrtuP9ShtlE6/HZ1LVLX1az+VBL7Tv4wS8kB8/8JnV253 NdujmNKVZJ2bpgVduqF5w1unk6J5TETh8lkqzLwC72+KSOm7qnVmjqANJoEXUMpK qxkRBcWDlxc9McVtyUsstEPXXRbsI8TNZTuUN3QxdT4n5nwTR2xSDo/rxgxdYq+k x55e0EwVb1o8g8pPeUAPN8vNPG/IXjGONqrXl5qJyn4OaAGl+l5jIcKtJQxt3Rt4 eMv8sa0Z/JnwvPxfzjkn5YfQnmZLxX9QQNh31BvSmU9N74v6pyMU1iCW30oBWub1 ZPF2yLvEjRvPVrymryH26SuiVlu1uD4imbLkNVAX+BohN4+msqqy22PL0xKUjNB4 QLYY3nRuUDtvCWvfBzyqy56kytJU4it3skDDrCVvaooF4T1Nr9vdaUJ/K71V65eu ln3n6rMD7oVsBD6dvCjS =jZIl -----END PGP SIGNATURE----- --Apple-Mail=_615B2C39-7757-4CF0-837B-F731D8485052-- From nobody Wed Aug 16 04:12: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 65BAD13249F for ; Wed, 16 Aug 2017 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 ri4g6gSfVGIj for ; Wed, 16 Aug 2017 04:12:41 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 DD49713264B for ; Wed, 16 Aug 2017 04:12:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 802B04B; Wed, 16 Aug 2017 13:12:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1502881954; bh=ib+HqZ247gWVKOiGseAGNIK78cpW52XlEHytXgiFTc0=; b=V AkZUgWrp7fBULVaAdrrsQkOe9fUPTMIvge//7+m35Udq+HKXSkeTPpf6fLqOrSDd 4FHt3sDgIQzZUTsZYzwPVrrLCquW0jM6h/h2C1HaxEmbeho0rTUg1v9/dHKk4V7l Mz9FoOsVll46dV9OitQhlmhCFhIEmjCna8H18URk+E= 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 D1EC1E1gZDpD; Wed, 16 Aug 2017 13:12:34 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:642c:7d5d:fc80:382] (unknown [IPv6:2a02:a213:a301:7880:642c:7d5d:fc80:382]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 4896649; Wed, 16 Aug 2017 13:12:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: RFC 4861 missing updated-by X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 16 Aug 2017 13:12:33 +0200 Cc: Mikael Abrahamsson , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> To: Ole Troan Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 11:12:43 -0000 Hi, >> Does that make sense? >=20 > I don't think that is necessary for MBZ fields. >=20 > Reserved This field is unused. It MUST be initialized to zero by th= e sender and MUST be ignored by the receiver. That confirms the "updated-by" is necessary. With the definition of the new f= lags that "MUST" is overruled, and implementations are allowed to put a non-= zero value in it :) Cheers, Sander From nobody Wed Aug 16 04:40: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 9695113265D for ; Wed, 16 Aug 2017 04:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDiNcJLg0Fud for ; Wed, 16 Aug 2017 04:40:26 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F338613218C for ; Wed, 16 Aug 2017 04:40:25 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id EAC762D4FD1; Wed, 16 Aug 2017 11:40:24 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5F1F7F833039; Wed, 16 Aug 2017 13:40:23 +0200 (CEST) From: Ole Troan Message-Id: <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_91FF66BD-788A-4995-9592-4D45A8B93073"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 13:40:22 +0200 In-Reply-To: <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> Cc: Mikael Abrahamsson , 6man WG To: Sander Steffann References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 11:40:28 -0000 --Apple-Mail=_91FF66BD-788A-4995-9592-4D45A8B93073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sander, >>> Does that make sense? >>=20 >> I don't think that is necessary for MBZ fields. >>=20 >> Reserved This field is unused. It MUST be initialized to zero = by the sender and MUST be ignored by the receiver. >=20 > That confirms the "updated-by" is necessary. With the definition of = the new flags that "MUST" is overruled, and implementations are allowed = to put a non-zero value in it :) Quite the contrary. ;-) /ot --Apple-Mail=_91FF66BD-788A-4995-9592-4D45A8B93073 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 iQIcBAEBCgAGBQJZlC8nAAoJEL7aWKiYQt92JlsP/j+S9XOrngsFeQ5DhJmp13eh 19DtBBrWND8GWjlfm38qyV3vk2mrLxrjNQGpTB7YmeZ8RiFD8hhupeGuRHKR51TM 53IGpdAT9kdNSIHjZgzYeypDPeCeFJ9pgVw8BEsAqrxssRPxCPImbO00ke7+c72L AsHqt0VbFf+9r44OuHXzbkPPXapnVqh5ShlKmZextsrwRA8fgFQ7RHETjqrKoEQJ LSuSAbeZUSl3X2ZDgtidrfSfOsyHO2nsVBL3ILQYTg900z+g420dzSLY5Xm+OkSz VbNs4Vofu31NSN25ZBGXIkZVBoRAVGB6lsT0RxgXiL9BglNXb4FTyPIx1B9TpUxs pOkb0l9lyHR4p0FfsxRfwxUMiTExs7jNO5ZAtxqo0rNwbOBUGlEMjpHvZ/G6SIh+ zPcZGAIVa08Iho9wZbO/2AZu6rHDkw+qqSBc9G9DOkoxuHbuFGgrr95fKaLuzLGn 7hgJODzHyKfmXCCQ4Sz/Nt+dkx8mL2qaP+eNQAqlqNoqfuYZJXcD0PqPc79+Wcep jGfDUF5t1dopymcuKvGH2ZaVyI+qsMqCG6YS9hoZWsQR/tFSlUChQnpR4OACe8xn zZfgoEfKxLSQ8colMAXkU/nhjPqaKD8hWd+OQvI5nKE72IcaTIrTi3JnbXDf2cx7 WoBFf/oMr5Nv99NE8GCl =Qpuz -----END PGP SIGNATURE----- --Apple-Mail=_91FF66BD-788A-4995-9592-4D45A8B93073-- From nobody Wed Aug 16 04:48: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 41A89132682 for ; Wed, 16 Aug 2017 04:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 QafFM-kHLh8K for ; Wed, 16 Aug 2017 04:48:27 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 B6C81132685 for ; Wed, 16 Aug 2017 04:48:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0A9DE49; Wed, 16 Aug 2017 13:48:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502884102; bh=kbI/gonqyHrTkh0uUqb ERf4yLv9vpP8ulQAIMEqH+6k=; b=bpnVTvGL+C3MHMDVM+V+rq/kWsxakXEZlhk 5ir2jFP5doNB9bysbeKYo/NhHpvRRAClbcoN7wtj7ib0XwPJ0+BM/44V1qu4XgPs DwO/NBWI//bpZCIkDVZzk3LERMFWd92mUY4SaYBwg31ty0aGqHm59d7wlSV2lZkr WErLoZ0Y= 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 UuslmDqgh_cj; Wed, 16 Aug 2017 13:48:22 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157] (unknown [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5895A3C; Wed, 16 Aug 2017 13:48:22 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_022A09F5-62E2-4639-98AA-1D88C21F1663"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 13:48:21 +0200 In-Reply-To: <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> Cc: Mikael Abrahamsson , 6man WG To: Ole Troan References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 11:48:29 -0000 --Apple-Mail=_022A09F5-62E2-4639-98AA-1D88C21F1663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >> That confirms the "updated-by" is necessary. With the definition of = the new flags that "MUST" is overruled, and implementations are allowed = to put a non-zero value in it :) >=20 > Quite the contrary. ;-) Sorry, but I strongly disagree. Look for example at https://tools.ietf.org/html/rfc4861#section-4.2. It = explicitly states: > Reserved A 6-bit unused field. It MUST be initialized to > zero by the sender and MUST be ignored by the > receiver. This text is simply not accurate anymore after = https://tools.ietf.org/html/rfc6275#section-7.1, which explicitly is = titled "Modified Router Advertisement Message Format": > Home Agent (H) >=20 > The Home Agent (H) bit is set in a Router Advertisement to > indicate that the router sending this Router Advertisement is = also > functioning as a Mobile IPv6 home agent on this link. >=20 > Reserved >=20 > Reduced from a 6-bit field to a 5-bit field to account for the > addition of the above bit. If that isn't an update to rfc4861 then I don't know what would be... Cheers, Sander --Apple-Mail=_022A09F5-62E2-4639-98AA-1D88C21F1663 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----- iQEcBAEBCAAGBQJZlDEFAAoJEKAtA7D+JBO55jwH/3sgkveUqEAe2Hgg6mUaG+nI TjCQpPIu7pQZn2bw+HKk9GRggrHkCcUGppZAg0fK9JKP9o3dAI+rAmIepuVTw0OE WhXJbsk4tJV8FzDsgfR6zi5AVLzhJ1XF1fSG6GBL8DLvnA8fdG9obKZUO1bjD2me vcpOlL4MXZHLOPut8Ux4W2tTJyX3d5r+Z96c180+bfZPD0soE/PuqNVFLtKfZ3NE 5JaOYjmw9JLyckNMa1t5aUbH4j8ncbJ2CU8QXoUryxdIRNyNtMLQcA43KZHGr1yD +vQSRHbaSDDstI3vOziBkrjTdRsN8/pOIVkEYL8JdwKXZD3V3cVokrAXC/peQ5s= =sDDW -----END PGP SIGNATURE----- --Apple-Mail=_022A09F5-62E2-4639-98AA-1D88C21F1663-- From nobody Wed Aug 16 04:51: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 715F813265D for ; Wed, 16 Aug 2017 04:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DWT212LCQ88 for ; Wed, 16 Aug 2017 04:51:34 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27A9132682 for ; Wed, 16 Aug 2017 04:51:33 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 89E7C2D4FD1; Wed, 16 Aug 2017 11:51:33 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id F292BF836365; Wed, 16 Aug 2017 13:51:31 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A0AF66BD-4631-4DB0-88F6-95FC0A12C513"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 13:51:31 +0200 In-Reply-To: Cc: Mikael Abrahamsson , 6man WG To: Sander Steffann References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 11:51:35 -0000 --Apple-Mail=_A0AF66BD-4631-4DB0-88F6-95FC0A12C513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > If that isn't an update to rfc4861 then I don't know what would be... An update to 4861 would be something that would affect the implementor = of 4861 and changes that could be incorporated if 4861 would be updated. = that's not at all 6275. 6275 can be completely ignored from a 4861 = perspective, unless you chose to implement 6275. /ot --Apple-Mail=_A0AF66BD-4631-4DB0-88F6-95FC0A12C513 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 iQIcBAEBCgAGBQJZlDHDAAoJEL7aWKiYQt92fxYP+gMimBijXfhmuawTk58lpAEc 9b8gHECwjAQILubJbtZMN23+6sKZwGvabaklEyCEXWlpiI1tE6dBAeUSMRhPbkDC CqxgPS5tJKQFOw2O9u6Lc2UKchCUYG7sgn5zjqQyvWxff2aV1Hw/AztbPPgAtscg 1IjoCuHQyhgTSHObpQF97mArmYT9Y67cO5AbljG/inLy51vP/ehf+JUF/9IrujFk fQ3AZMIPOnsKQKsDo4OYaXdCRZJUXnZZhUSZSkowfWuGcpGFYFAiXcfxs8YkuDxB 5lkhirA524+RD6UdMQu1xx5AyNKh2u+Ga7y2/vrNzcsy9k4RtLCUz6WPSMK1G9Ek LFI7rlE0833J/ewNapAUXYme3l5MfUGVflt12YQ0B7GsBh1Qz1CrPuqsrcCQa6cC hesLS/4K82jhDbWb+hg9IOQXVZj+XNbt+QDntKfotHdOAEnaHq4OedKuIvyM6X1j RuF3faS1AoZKbdmXGEcpThDyIPZfXC9ZXU4Qixl7L5Qg7L6DEGjhKBoGGl/hTWdJ Cs+fNaBO0N1ac7ROmHJBAtz8DUG4uK7KgF4QBKSxTAWV97ojDXsc+K4u6lL2bT1L Rgf2329xS1YMAJSo8d3Cbo9eQAYoO2UCKPBq4XYV/cAoVzKp94TfB+GxogRMp92D 6DFcuTpn9vLRcOaCs4E7 =vtGb -----END PGP SIGNATURE----- --Apple-Mail=_A0AF66BD-4631-4DB0-88F6-95FC0A12C513-- From nobody Wed Aug 16 05:00:17 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05B132196 for ; Wed, 16 Aug 2017 05:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 DDyRndiEUBIg for ; Wed, 16 Aug 2017 05:00:13 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 7BB95132694 for ; Wed, 16 Aug 2017 05:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id E8E3749; Wed, 16 Aug 2017 14:00:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502884809; bh=6u4biiNFsl4AzcPtZS+ S3qOWK9+fTxA8gbkbTE54HlY=; b=pf4Qy0UuKrE7OjIbPE2KfANrAf03I8ao82M zdCDFqk0l7uwL+5YiHQlQSSL1Jd56bUxVcX/qUX3PKzy6eIu/AAO4FmJHBgZjR/+ s9gbZ2xvc8WuHjcju9qOATe6xrs9+cpjszVDQJuqqgQCBqyqFvazBKuL220jsMml qjkM2ZIU= 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 KQFNAawM4f1h; Wed, 16 Aug 2017 14:00:09 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157] (unknown [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 3CCDA3C; Wed, 16 Aug 2017 14:00:09 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_03983DA8-82D0-4705-9B50-99571F01DDA7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 14:00:07 +0200 In-Reply-To: Cc: ipv6@ietf.org To: Philip Homburg References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:00:15 -0000 --Apple-Mail=_03983DA8-82D0-4705-9B50-99571F01DDA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Philip, > Op 16 aug. 2017, om 12:52 heeft Philip Homburg = het volgende geschreven: >=20 > The obviously bad thing is to allocate a bit in an RFC and not telling = anyone > about that beyond publishing the RFC. >=20 > So there seem two ways around that: > 1) the RFC that allocates the bit explictly updates the RFC that = introduced the > field. Of course this requires the rfc editor to accuratly track this. > 2) the RFC that introduces the field opens an IANA registry for the = field. >=20 > When reading RFCs, those two seem roughly equivalent. If you read an = RFC and > it is updated by a few other RFC, you need to quickly skim those to = see if > they are relevant. If an RFC introduces an IANA registry then a quick = check > at IANA is in order. Perfect, as long as it's clear where to find such information in the = original RFC. If the author wrote explicit text on where to document = changes (IANA registry) then that should be used. If no explicit place = has been defined then all changes should be considered updates to the = original RFC so that implementors can find them. > Of course it doesn't make sense to open lots of IANA registries on the = off > chance that some future RFC will need to allocate a bit. Likewise, it = doesn't > make sense to have an RFC that is updated by dozens of other RFCs just = to > allocate some bits. Agree. In the worst case the author of the original RFC didn't = anticipate the large number of bit/codepoint/etc allocations, and a new = RFC can update the original and introduce an IANA registry. > Given the relatively high overhead of publishing an RFC that = introduces an IANA > registry for RFC 4861, it may make sense to just mark RFC 4861 as = updated. I think this would be the appropriate choice in this case. Other cases = might warrant a different choice though. I can see Ole's point for = certain cases, just not this specific one :) Cheers, Sander --Apple-Mail=_03983DA8-82D0-4705-9B50-99571F01DDA7 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----- iQEcBAEBCAAGBQJZlDPHAAoJEKAtA7D+JBO5x8AH/jdWq5DZaN78ohpB2zLM7EmF BGYL8BcYyhlIysDwyAv0FEX6jjuRtBnfB58dDKxsI0RjOQqG1vfws8yzJxDzBu2d rCsg+OFfyPhX4J4BTIuRiWGWft+wigsmvjW8ioGq5P3mpiNeLt9a226BwnkV1+U9 V/tfLK04xkMSC77RwjMV8sHeyqe3aSITgeYKSqCRFd0fZF+qic7eVAyU/qIZKrlD Oo5OfPhKWg5npG6qWhhi78Zmy0EuMYLE7ICjODOVW8vIyiIit9nKmwEUiX6Klytj X7U1SKk5xZLvSbxKif+VB9J4Yg0bV5q6N/wjxY5DLUcFE0zxBYK/8SRDG2/URO8= =NN4n -----END PGP SIGNATURE----- --Apple-Mail=_03983DA8-82D0-4705-9B50-99571F01DDA7-- From nobody Wed Aug 16 05:04: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 F2837132684 for ; Wed, 16 Aug 2017 05:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Ud5l4JcSDTdn for ; Wed, 16 Aug 2017 05:04:21 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 46FC5132196 for ; Wed, 16 Aug 2017 05:04:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 122F649; Wed, 16 Aug 2017 14:04:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1502885058; bh=fp7KMpqbLyhVqF5+eXt xJbE2YlVJEA90ghg2cp3VGRs=; b=XSLRaVzU7gy5eY5CbUQpFGlwhRU0ron2YHG qAo2nKf1fdwxM5rl+Yv+Emols/jOcPx/qRH63P3aRmefDuZM4MszmofyVgS+XaEt YCXEe4FahDQZvxF684eBp50yBeCDKapXzfouWkf9tfAlW+1wjtDVYvFJcaj5LtWu HkMYgTnI= 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 zkVo25r879Kj; Wed, 16 Aug 2017 14:04:18 +0200 (CEST) Received: from [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157] (unknown [IPv6:2a02:a213:a301:7880:b055:bbb:526f:6157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id E0E5A3C; Wed, 16 Aug 2017 14:04:17 +0200 (CEST) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <2C77CFC5-AF37-4FCF-A572-0C4C61615759@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_4887C3E1-82C6-4B71-B3B7-8283751E40F2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by Date: Wed, 16 Aug 2017 14:04:17 +0200 In-Reply-To: Cc: Mikael Abrahamsson , 6man WG To: Ole Troan References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:04:23 -0000 --Apple-Mail=_4887C3E1-82C6-4B71-B3B7-8283751E40F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ole, > Op 16 aug. 2017, om 13:51 heeft Ole Troan het = volgende geschreven: >=20 >> If that isn't an update to rfc4861 then I don't know what would be... >=20 > An update to 4861 would be something that would affect the implementor = of 4861 and changes that could be incorporated if 4861 would be updated. = that's not at all 6275. 6275 can be completely ignored from a 4861 = perspective, unless you chose to implement 6275. 6275 overrides text in 4861, it's as simple as that. If you only = consider an implementor to be someone who wants to write a minimal = implementation then you are correct. If you include all other = implementations like protocol analysers, security devices etc then it = *is* important to know that "those bits MUST be zero" isn't completely = true anymore. Cheers, Sander --Apple-Mail=_4887C3E1-82C6-4B71-B3B7-8283751E40F2 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----- iQEcBAEBCAAGBQJZlDTBAAoJEKAtA7D+JBO56kYH/iwYnMGs2SPbAw9xtmY80REN UcRs08D3j36MGq5dZBVEnWv3T4g7AdSum8Xl2Vt0hVM28tIqu4+96sBnpKc/b0zN OUc6jkBc8A3Xg+U8Pih/CPCaaDdcFtzliEFz0hSDY/Y54GkK8FGrG4YWjEI9zntU wCELgmVcchZ1dUgvhCenCNNQwTtKkM8b842nxd9yElSwQ3GBo1BiPsWaDFLRjpUo cDx2otkGCGc49/kCStnczRIRaLfRcOBrh+YBEv4qjZaCrpX+ldZvzy2KDt7tNMvE ygldxPhGpfcSWi/KSohlJ15LHmcaQt79MFety9I9pbq5P0qHtfiNwzQCL8A9Okw= =wC0d -----END PGP SIGNATURE----- --Apple-Mail=_4887C3E1-82C6-4B71-B3B7-8283751E40F2-- From nobody Wed Aug 16 05:08: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 BD14E1326A0 for ; Wed, 16 Aug 2017 05:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 tsJIhbUeiQSo for ; Wed, 16 Aug 2017 05:08:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961F813269D for ; Wed, 16 Aug 2017 05:08:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57DB6AF; Wed, 16 Aug 2017 14:08:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502885331; bh=13gSLOSfZc4Pgspce2FfALHH6lfpNZ0jkUZQP5UeI+Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Rpy5DP4DQWwuEDfdKPVfqKLlCULL9szDWmO1aNXvA1Bbebn2NHvvDCXIu7xPsk+zD XMroEIFxEz2WuUGFjFSI/V2EPV/TwFjhm/UqAmSp0wMs8SJcQX1RP9/J9C/YlRiAud fSStDph/OpgjnurPMqmaSE44px3/oaHBqDmROIHY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 550DE84; Wed, 16 Aug 2017 14:08:51 +0200 (CEST) Date: Wed, 16 Aug 2017 14:08:51 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan cc: Sander Steffann , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:08:56 -0000 On Wed, 16 Aug 2017, Ole Troan wrote: > An update to 4861 would be something that would affect the implementor > of 4861 and changes that could be incorporated if 4861 would be updated. > that's not at all 6275. 6275 can be completely ignored from a 4861 > perspective, unless you chose to implement 6275. Then we need new meta tags. Either there needs to be a "bitfield-updated-by" metatag to handle this usecase, or there needs to be an "IANA-registry-now-for-bitfields-mentioned-in-this-RFC" metatag, or both. Having no mention what so ever that reserved bits are no longer reserved is just... I don't know, I just can't graps why you think it's ok for 4861 to have no mention what so ever that some reserved bits are no longer reserved and that the MUST for them to be ZERO no longer applies. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 05:33: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 1ED6B13265D for ; Wed, 16 Aug 2017 05:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lao5GrRALQS for ; Wed, 16 Aug 2017 05:33:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD4E1320BE for ; Wed, 16 Aug 2017 05:33:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 365E6E1DB for ; Wed, 16 Aug 2017 08:35:56 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A3B448076D for ; Wed, 16 Aug 2017 08:33:17 -0400 (EDT) From: Michael Richardson To: 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:33:21 -0000 --=-=-= Content-Type: text/plain Ole Troan wrote: > A reserved field is there for forward extensibility... > How can using that extensibility (which as you state is specified as > MBZ specifically to be forward compatible) be a substantive change to > the RFC that reserved it?? The point is that it deserves an "Updates". Someone reason 4861 should be directed to read the update so that they see why the reserved bits might not be zero anymore. It might be functionality that they actually want to implement. Or not. ("MBZ" is the wrong sense, because it "security" devices get it wrong. Must send as zero and ignore upon receipt is the functionality that we want. I wish that our compliance testing suites actually checked that these reserved fields are ignored properly) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmUO40ACgkQgItw+93Q 3WXMdgf+IAnmBJ9/mmkXXcDJBcIZ+ivmqrRGpNN2JK9tEFIt3JRqonAJlbA6s2j5 nnwWWNj/vV3HNtno9bPt2u9YV2Ig35nK0T6GPsG3495smnsR9CfjJ/0CJhpnwH+t kLHWhQz9sWhDwUZ0wkIh+vJ0WJcdNMAB4HXFF+IhEj27ap2V9P6yJyY7QGOMzBpL Gs8IY7+AkaKw/cwX7gEKaao07uix3z+t/QdhZChlqCVkN05KRPbGRA2ww99fysd6 yVXrvcNrT4XS05q7vnKSYjUMfJ1Z0nFzypPhsapVIcJrDQ7LxlmF+AlASStuqPLC AH1itG2Wzt0CFZgQwdTDPfsNofgn2g== =+CrH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 05:35: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 8569F1326AF for ; Wed, 16 Aug 2017 05:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQEDf_DfRVZb for ; Wed, 16 Aug 2017 05:35:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487931326AE for ; Wed, 16 Aug 2017 05:35:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2494AE1DB; Wed, 16 Aug 2017 08:38:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B0228076D; Wed, 16 Aug 2017 08:35:53 -0400 (EDT) From: Michael Richardson To: Mikael Abrahamsson cc: Ole Troan , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:35:55 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson wrote: >> If an 4861 implementation is not affected by the other specification (6275) >> then I think using update is wrong. (I don't think you should make too many >> assumptions about the level of darkness that implementors live in...) > I still think there should be some kind of forward reference to the document > that has assigned or changed bits. If we can't use updated-by, then we need > to invent some other kind of reference. +1. I don't care how we cause the forward references to be created, but they need to be created. Updates: is appropriate. 6275 may not FORCE an 4861 implementation to change, but a 4861 implementation might WANT to change. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmUPCkACgkQgItw+93Q 3WWUnQf/UNRgMJCdpljw6ZUpQwigRU4GBaw9WYw1lAzg+/aJTb4z0L8Rjk2RFIs9 GOwuZlZp/5A1hRFZrgXp9yGUVmHHt7fBWKUVZnlCEm04hWejan7hY45Ui0TeMt82 Gpj7KbIHBtjuLAgkn/IgsNvOTUHjz4EYG8g00OCgt/gYzsDxiFesfmAn9PsXAbiX aTVHg0Vj4CscwiPF9tCp0p5ThRW0C0CO/Wwivj61X96tJ9N4XheQleUh8F1BGBay AgkkVJFnUEyPNLf9s7mjEAWEetVQ7FjJxNAiAKwUYOEz0IYit9JVdOyOAsiD9m2S hbkXy6IxCWcETsu09R59l0Ev21gcgQ== =XatE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 05:43: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 562B91326B4 for ; Wed, 16 Aug 2017 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XDYsUM_KqsPl for ; Wed, 16 Aug 2017 05:43:28 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EA812008A for ; Wed, 16 Aug 2017 05:43:27 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id v29so19882049qtv.3 for ; Wed, 16 Aug 2017 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CKHvUWfmFzq4XHiypMhP+i/S176SY50l9e3RMh4rGs4=; b=FJwc81kbhkNfalrRAy3YaXxyBEDL3f3QddtMNQgK6HM2r9xeuT8/tN+JcIbnsfT1QL 6q43YUzJ9hTGekTCrgmOZfp75O8xf66YGkCS52Ilqa8q4xn555nbCzIXUyk/E4sFtqZE mb+tcPwrbq01udsEi5k4vrdi1lXQeZ6Y6fUXI= 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=CKHvUWfmFzq4XHiypMhP+i/S176SY50l9e3RMh4rGs4=; b=dSU5M7ug36X17CDD3Ah/aRMp23FIcCao4gpedpDfNokoXUyrCxxhEAMFMZbI/eTrqT HYxWTc7azNDcqx7SQwDky67hy0ziW/t/m1fr2FUdVgpHcmHaSxQ7ykpCgqLbYJR2HxdA KtRv0k8rmCEjWcclMO2lnyXjC547z0GbOhfn8yckwDoLx5rGDJOzX6wmyytdD7xzrbaU bVUvGAQT9wjJAtRiEra81K3ZHO9GVS0sg8GVsKy4Be3YHfCFAxL1xKdbjUWRD8z4uwD8 uj+Ex8I3IepetVjTkLDV62kOX0LUiArIKDg2D4+ioXZcEebtD7IuCT1qbhBXuT1vtUeR OU6A== X-Gm-Message-State: AHYfb5iG3UvGxHU2R3aof39iA+oRp4JZn6WNKmdgMZFdCOy5Bn805xyD pJcTi2lsSURDgeFmzAkoLEmGGInhXk8N3M4= X-Received: by 10.237.36.155 with SMTP id t27mr1932090qtc.314.1502887407046; Wed, 16 Aug 2017 05:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.91 with HTTP; Wed, 16 Aug 2017 05:43:06 -0700 (PDT) In-Reply-To: <3843.1502886797@obiwan.sandelman.ca> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> From: Timothy Winters Date: Wed, 16 Aug 2017 08:43:06 -0400 Message-ID: Subject: Re: RFC 4861 missing updated-by To: Michael Richardson Cc: 6man WG Content-Type: multipart/alternative; boundary="001a113f439008f2460556de3e2e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:43:30 -0000 --001a113f439008f2460556de3e2e Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 8:33 AM, Michael Richardson wrote: > > Ole Troan wrote: > > A reserved field is there for forward extensibility... > > How can using that extensibility (which as you state is specified as > > MBZ specifically to be forward compatible) be a substantive change to > > the RFC that reserved it?? > > The point is that it deserves an "Updates". > Someone reason 4861 should be directed to read the update so that they see > why the reserved bits might not be zero anymore. It might be functionality > that they actually want to implement. Or not. > > > ("MBZ" is the wrong sense, because it "security" devices get it wrong. > Must send as zero and ignore upon receipt is the functionality that we > want. > I wish that our compliance testing suites actually checked that these > reserved fields are ignored properly) > I looked thru the IPv6 Ready Logo Test Specification for this, we test this for NAs and NSs but not RSs/RAs. I've filed a bug to update the Test Specification to check this in the next release. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR --001a113f439008f2460556de3e2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Wed, Aug 16, 2017 at 8:33 AM, Michael Richardson <<= a href=3D"mailto:mcr+ietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandelma= n.ca> wrote:

Ole Troan <otroan@employees.org<= /a>> wrote:
=C2=A0 =C2=A0 > A reserved field is there for forward extensibility... =C2=A0 =C2=A0 > How can using that extensibility (which as you state is = specified as
=C2=A0 =C2=A0 > MBZ specifically to be forward compatible) be a substant= ive change to
=C2=A0 =C2=A0 > the RFC that reserved it??

The point is that it deserves an "Updates".
Someone reason 4861 should be directed to read the update so that they see<= br> why the reserved bits might not be zero anymore.=C2=A0 It might be function= ality
that they actually want to implement.=C2=A0 Or not.


("MBZ" is the wrong sense, because it "security" device= s get it wrong.
Must send as zero and ignore upon receipt is the functionality that we want= .
I wish that our compliance testing suites actually checked that these
reserved fields are ignored properly)


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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




--

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

--001a113f439008f2460556de3e2e-- From nobody Wed Aug 16 05:48: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 E2C091326AE for ; Wed, 16 Aug 2017 05:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 0kv9WHBblJiW for ; Wed, 16 Aug 2017 05:48:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98521326BA for ; Wed, 16 Aug 2017 05:48:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B4ED9B0; Wed, 16 Aug 2017 14:48:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502887707; bh=xz8xf7zGtd1qqz5sxSXWJbHg6vUDzR0Z8yGMovS1L48=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vAugaQP4auJ5DIBBTx5ukHh75QTrSTLoOnA5Vf+jQ3c8l38yTfPm6qS6dglHAqkxv KBp3fC+RFRKmr0/3rEFMcBhsSKURuw3Nem+CEQgVCG8kd63BwC35T8lNWXMJI2joR0 uE1QBY9Kd6Kp37ehoIJ2mx/2c+JRYrtSGpxEw31Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B06C8AF; Wed, 16 Aug 2017 14:48:27 +0200 (CEST) Date: Wed, 16 Aug 2017 14:48:27 +0200 (CEST) From: Mikael Abrahamsson To: Timothy Winters cc: Michael Richardson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:48:35 -0000 On Wed, 16 Aug 2017, Timothy Winters wrote: > I looked thru the IPv6 Ready Logo Test Specification for this, we test > this for NAs and NSs but not RSs/RAs. I've filed a bug to update the > Test Specification to check this in the next release. Great takeaway from this discussion. I have personally run into problems with an implementation that did not ignore MBZ bits but instead required them to be 0. Since the sender of the packet had a bug and didn't zero them, this caused things not to work. The sender of the packet which didn't zero the bits immediately understood what the problem was and offered to correct things, however the vendor of the device that didn't ignore the bits took a lot longer to convince that they were doing something wrong. This was OSPFv3 and it had a 24 bit field in there with the remaining 8 bits being MBZ and ignored. The vendor put this into a 32 bit field and compared meaning that when the other end messed up their zeroing the reserved bits, the compare failed. I'd imagine this is not too uncommon problem. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 06: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 8CCC1126BFD for ; Wed, 16 Aug 2017 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz0shL07hKdb for ; Wed, 16 Aug 2017 06:22:36 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EA9120721 for ; Wed, 16 Aug 2017 06:22:36 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id DACDF24AEAD; Wed, 16 Aug 2017 13:21:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AFFC9160052; Wed, 16 Aug 2017 13:21:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9BF09160067; Wed, 16 Aug 2017 13:21:16 +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 tDYV6mlKLnFQ; Wed, 16 Aug 2017 13:21:16 +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 29A51160052; Wed, 16 Aug 2017 13:21:16 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id ADF72828E3BC; Wed, 16 Aug 2017 23:21:13 +1000 (AEST) To: Mikael Abrahamsson Cc: Timothy Winters , Michael Richardson , 6man WG From: Mark Andrews References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> Subject: Re: RFC 4861 missing updated-by In-reply-to: Your message of "Wed, 16 Aug 2017 14:48:27 +0200." Date: Wed, 16 Aug 2017 23:21:13 +1000 Message-Id: <20170816132113.ADF72828E3BC@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:22:38 -0000 In message , Mikael Abrahamsson writes: > On Wed, 16 Aug 2017, Timothy Winters wrote: > > > I looked thru the IPv6 Ready Logo Test Specification for this, we test > > this for NAs and NSs but not RSs/RAs. I've filed a bug to update the > > Test Specification to check this in the next release. > > Great takeaway from this discussion. I have personally run into problems > with an implementation that did not ignore MBZ bits but instead required > them to be 0. Since the sender of the packet had a bug and didn't zero > them, this caused things not to work. > > The sender of the packet which didn't zero the bits immediately understood > what the problem was and offered to correct things, however the vendor of > the device that didn't ignore the bits took a lot longer to convince that > they were doing something wrong. > > This was OSPFv3 and it had a 24 bit field in there with the remaining 8 > bits being MBZ and ignored. The vendor put this into a 32 bit field and > compared meaning that when the other end messed up their zeroing the > reserved bits, the compare failed. I'd imagine this is not too uncommon > problem. It's not just the protocol implementers that get this wrong. Firewall vendors also get this wrong by blocking packets with reserved bits set. It then takes years longer to deploy extensions that use the reserved bits. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 16 06:30: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 A42D91320D9 for ; Wed, 16 Aug 2017 06:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 jE5gB01L2wWm for ; Wed, 16 Aug 2017 06:30:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDFF13201E for ; Wed, 16 Aug 2017 06:30:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B04D5B0; Wed, 16 Aug 2017 15:30:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502890211; bh=XmRaJTyTmO7+a8RmoBp7SvPw90Dv5z8lgv0IXiqWrAg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BKF4Eqi+FNpfIFOOr/ZUfKS/aPNUhrhD5/L2ZWjv6A9G4SoYi3w7ncVDAP0+sXJmt +iY3JbIpkOXEW1raZi9GqVrxZMHd4pALtR6rpHtPbWQspJiMqpnT80tnN+RVyai1ks 1Ifl9vKX43CeBPIvjUjrWhHrXWSPrc7ZFkC4zH7A= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 98BD1AF; Wed, 16 Aug 2017 15:30:11 +0200 (CEST) Date: Wed, 16 Aug 2017 15:30:11 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <20170816132113.ADF72828E3BC@rock.dv.isc.org> Message-ID: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> <20170816132113.ADF72828E3BC@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:30:15 -0000 On Wed, 16 Aug 2017, Mark Andrews wrote: > It's not just the protocol implementers that get this wrong. Firewall > vendors also get this wrong by blocking packets with reserved bits set. > It then takes years longer to deploy extensions that use the reserved > bits. Absolutely. PIX killed ECN for many years. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 06:31: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 7808213219C for ; Wed, 16 Aug 2017 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyY8U6zIlcwG for ; Wed, 16 Aug 2017 06:31:31 -0700 (PDT) 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 158E213213F for ; Wed, 16 Aug 2017 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7GDVRPN011736; Wed, 16 Aug 2017 15:31:27 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXVcH4xtdzDLKg; Wed, 16 Aug 2017 15:31:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by From: Carsten Bormann In-Reply-To: <20170816132113.ADF72828E3BC@rock.dv.isc.org> Date: Wed, 16 Aug 2017 15:31:26 +0200 Cc: Mikael Abrahamsson , Michael Richardson , 6man WG X-Mao-Original-Outgoing-Id: 524583086.710146-3954d4ad15624bf868dc9824b759b760 Content-Transfer-Encoding: quoted-printable Message-Id: <91B11813-6CC2-4E25-992A-5CA79D8D7118@tzi.org> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> <20170816132113.ADF72828E3BC@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:31:38 -0000 We have a long tradition of misidentifying bits in packets that really = are extension points. =E2=80=9CReserved=E2=80=9D is only marginally better than =E2=80=9CMBZ=E2=80= =9D (which turns untrue with the next extension using them); both signal = to the implementer =E2=80=9CI don=E2=80=99t have to think about these = fields=E2=80=9D. To avoid those misconceptions coming up with the readers of specs, in = box notation, I like to mark those bits available as extension points = with an underscore (see Figure 5 of RFC 7400): https://tools.ietf.org/html/rfc7400#section-3.3 This does make people wonder, and maybe readers then go ahead and read = what is actually said about these bits. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 16 10:26: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 314C7126CB6 for ; Wed, 16 Aug 2017 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjHSxzV64AAk for ; Wed, 16 Aug 2017 10:26:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC35D12426E for ; Wed, 16 Aug 2017 10:26:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 02AA5E00A; Wed, 16 Aug 2017 13:29:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C07598076D; Wed, 16 Aug 2017 13:26:20 -0400 (EDT) From: Michael Richardson To: Ole Troan cc: Mikael Abrahamsson , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <289FAC54-6333-4CC3-A586-03DD7E58759A@employees.org> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <289FAC54-6333-4CC3 -A586-03DD7E58759A@employees.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 17:26:24 -0000 --=-=-= Content-Type: text/plain Ole Troan wrote: > Think of RFC3315 as an example. Should it have a forward reference to > every DHCP option? Yes. Having worked on rfc3315bis, that would have been a great thing to have. Did we need to merge them all into 3315bis? No, but we did need to look at them to see if they used some feature. Maybe we could have removed some unused feature from 3315 because it was never used. > Don't assume implementors are idiots. The reason why they don't do what > you want are typically not because of lack of intelligence or reading > skills. ;-) Implementors generally work for idiots called "Product Marketing" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmUgDwACgkQgItw+93Q 3WURLAgAhHkgXr1z39GYlKWQNsryqhfCS0y3taRFKyTO24xRhP1C5kt6MRL+UIbq puaHCfqMpDkf8I1liT3NW7pjZUCsg1jIa76a3qZ7n0Q4d8dlrBv7y6+oEI+T86mm NqM3F+tmqWaLz6XvbbMeao96HYl0sgSFGdqScQCGkppEAqFFT4F5JB/Q8EvRh1sv iG2iyRExEIgZEU9u4tMV5FVFCY9TUhI7KOBGZwhdrTDrNZvYmXU6TihPWHNNrPps 1WMJRcIpnHDApasHcbVWAIs+qcnEI5Nste94T0PBRdaqGm6yBVgp/G4S1e9iqVk2 Qm67Etl4IzCPeM1iX6VnahBy7JMlmg== =dUAX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 11:02: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 13CC9132382 for ; Wed, 16 Aug 2017 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 5GEDHEj7QIbM for ; Wed, 16 Aug 2017 11:02:42 -0700 (PDT) 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 03D3313237B for ; Wed, 16 Aug 2017 11:02:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 7CE9D622 for ; Wed, 16 Aug 2017 18:02: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 UqCzxdJreumE for ; Wed, 16 Aug 2017 13:02:41 -0500 (CDT) 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-p7.oit.umn.edu (Postfix) with ESMTPS id 3C720569 for ; Wed, 16 Aug 2017 13:02:41 -0500 (CDT) Received: by mail-vk0-f69.google.com with SMTP id s199so15968217vke.10 for ; Wed, 16 Aug 2017 11:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KN4pLK2/HjQcrWfEGYAB1B+lnHkZhU8NbJlHYF3J+r0=; b=AJJB0aYhdPd/d1jD15Parc3ypZpv2v8wMDJ99R8E7l64+8EU+HwQvuLi80azH7N4FS j0zjIm7GxGT99OjZ5wZIyCOkGHVqsB/mc1gGny1jyM/cbfO2a2Vz2AbX+6vfMtDgxPM1 Lye9bbW7c7BvqJ63ei64uQcWH18Al38fkL87yCBKtlV67XawDrFy/BiNr5gnt342Hu5r z9fAyC2heV2j4IE2VeBagOhDlcobxs9xGLjAAd4FxaEvvMR+AsqPGmaS1cwvUeOBGCQE 1mDmNEEz91NViBAMMA7EvOO0FP8CY48UfRE3jRL3gB6cb0ahDVsE8fcqomgWq26EJm+V ekmA== 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=KN4pLK2/HjQcrWfEGYAB1B+lnHkZhU8NbJlHYF3J+r0=; b=a5leMbeLm+y6J2KHtgClR3QZIf9qSgmYqV1I6txiL05jtgH9OwQn9Xu/j/CrovVg3g 0jNx0KxfjnJfR/8o3Gd00rJXMNoSSxLXKsLNQlxZef8uAZFoBURLr9WpoxjMpSkXUV/C XQtXV5rRKd+GUBTJiDodQQFDBFIxuKj+a/YS7eWshac9Qy68ch2ARfKycxPV0kppxCGh iEECyHNafSkqFkwDa6T/pO6XxgKhoWoJwmTjN9e0j06i2OYD313AaO+R8Lj1kqvg0fiO 8YyM4ZdYvkUUHMpynM475z7YTIDlodO6jVbLk2oPOPd+K3FWZqqDf3gOWaOcsU9FxdOZ rZGg== X-Gm-Message-State: AHYfb5iWWJhYwEZnqXDnWnnRG6MM3s1mCkc/shaF+tZLHjhQV4D82FAD 2qnAgR+q7A8uwMLHC3K0PeWA2TXLDX15sa2b7pnWde3CHPCwixhCth1XgfUvFQhZ2hriRwIXaLe 233P+SNEpYNw7Be4= X-Received: by 10.31.215.6 with SMTP id o6mr1542385vkg.179.1502906560518; Wed, 16 Aug 2017 11:02:40 -0700 (PDT) X-Received: by 10.31.215.6 with SMTP id o6mr1542372vkg.179.1502906560264; Wed, 16 Aug 2017 11:02:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.86.21 with HTTP; Wed, 16 Aug 2017 11:02:39 -0700 (PDT) In-Reply-To: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <78463B7D-8D4B-449A-BDC9-E05F0280046B@steffann.nl> <0D2E34F3-B6AA-4AE4-A094-8F87FBC9EFF4@steffann.nl> <4D5E5BDC-0FBD-4CE2-AB37-7EAC642ED9C3@steffann.nl> <829F6997-4AC8-400C-B981-A5D5B2FE10C2@employees.org> From: David Farmer Date: Wed, 16 Aug 2017 13:02:39 -0500 Message-ID: Subject: Re: RFC 4861 missing updated-by To: Ole Troan Cc: Sander Steffann , 6man WG Content-Type: multipart/alternative; boundary="001a114eccbca7d4630556e2b396" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:02:44 -0000 --001a114eccbca7d4630556e2b396 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 16, 2017 at 6:51 AM, Ole Troan wrote: > > If that isn't an update to rfc4861 then I don't know what would be... > > An update to 4861 would be something that would affect the implementor of > 4861 and changes that could be incorporated if 4861 would be updated. > that's not at all 6275. 6275 can be completely ignored from a 4861 > perspective, unless you chose to implement 6275. > Since RFC4861, or it's predecessors, didn't create a registry for the flags in question, it (RFC4861) is the primary and best source for the definition of those flags. If and only if, the authors of RFC4861 had created a registry for the flags would such a registry become the primary source instead. Since RFC4861 is the primary source, the subsequent creation of such a registry would need to at least be update to RFC4861 as well. Finally, RFCs and their metadata, serve more than just implementers, they may be the primary intended audience, but there are many secondary audiences, operators, developers of other (future) standards, students, etc... A change in these flags may or may not be relevant to an implementer of RFC4861, but it could be of critical importance to these other audiences, and as the primary source for the meaning of those flags, it seems quite appropriate for any and all changes in the meaning of those flags to be an update to RFC4861. 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 =============================================== --001a114eccbca7d4630556e2b396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 16, 2017 at 6:51 AM, Ole Troan <otroan@employees.org> wrote:
&g= t; If that isn't an update to rfc4861 then I don't know what would = be...

An update to 4861 would be something that would affect the implementor of 4= 861 and changes that could be incorporated if 4861 would be updated. that&#= 39;s not at all 6275. 6275 can be completely ignored from a 4861 perspectiv= e, unless you chose to implement 6275.

= Since RFC4861, or it's predecessors, didn't create a registry for t= he flags in question, it (RFC4861) is the primary and best source for the d= efinition of those flags. If and only if, the authors of RFC4861 had create= d a registry for the flags would such a registry become the primary source = instead.=C2=A0 Since RFC4861 is the primary source, the subsequent creation= of such a registry would need to at least be update to RFC4861 as well.=C2= =A0 Finally, RFCs and their metadata, serve more than just implementers, th= ey may be the primary intended audience, but there are many secondary audie= nces, operators, developers of other (future) standards, students, etc...= =C2=A0 A change in these flags may or may not be relevant to an implementer= of RFC4861, but it could be of critical importance to these other audience= s, and as the primary source for the meaning of those flags, it seems quite= appropriate for any and all changes in the meaning of those flags to be an= update to RFC4861.=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
Networking & Telecommuni= cation Services
Office of Information Technology
University of Minnes= ota=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
--001a114eccbca7d4630556e2b396-- From nobody Wed Aug 16 13:33:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0D1326F5 for ; Wed, 16 Aug 2017 13:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3gwmlUaT0zv for ; Wed, 16 Aug 2017 13:33:39 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D9E1326F3 for ; Wed, 16 Aug 2017 13:33:39 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id t80so642920pgb.5 for ; Wed, 16 Aug 2017 13:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LCp6FSXWUt83cGlMZv/7mUYxEA7ZMfXsD9j0rGoY7iI=; b=NmqUhhPZ2dVSiWCXxRjI9hfYWp2vPrMhFTM0xhIUymsecxmppMVuOWxXDUr72LUFFg bWG+9Uz7B8zI1cJOhvAgNExYRPgJ9SqhUvkRDMcARd/W9PWxthaNjai5ebfkWxpyitzB jESzGD5AcRMui+t2bMNZA4otmBjEFx1eo/091Ip+ZgjqaNi7GYVGOjFZg3S4kahf+uPC JmbEBf2x6g5Jo9WBE1CgBMcLhqJq+adPPeQYzyMZ3mxubLDw1U9RjpARMH0CknNLy2G7 VmvA4R2vHAiLMGly3Saq6pgnnjXVlvGFMGCfmXL9a32rIzhgz1ISdi1ltfakZ/rZnrpT OdZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LCp6FSXWUt83cGlMZv/7mUYxEA7ZMfXsD9j0rGoY7iI=; b=ewmto/7Ak/6DOQWQR7va3Fn/+/jpnHCl4c6rfqW5V+y/j4667ggrpaiuWpwiMTg7gp vTYm7l1nZ1dzxy7VrkU7AWigOzs2AEY8hNouvxwz1fEJqA8NBAXH9mp+v4YE6cTt0QId KCpNYINOV5EF0fGfvo2H60Cbinu5Cuzl5ahBM7R2U6wLoviQkiTIK6OLDNmNbVZ/aZaV 1XzBFCsyKFNvWNFcJ2/evOMfVIKchCoRm8NthFnRMbTByqvjuNSqTLCU1xyzBnJtVaYh +4YC7iLFBpu/4rlmtSQvVGG5kKj3jlYi1uk/FfTSgugLW2/0Lsc5bv6pXJXAjwTqueqQ hb9g== X-Gm-Message-State: AHYfb5iZj3lTWDFEx9iPqX4hpL9t2MQlu1OSSAmOrctJf4fL3vOF5KjB ad605HdnV4gMYkgX X-Received: by 10.84.224.77 with SMTP id a13mr3085106plt.43.1502915618552; Wed, 16 Aug 2017 13:33:38 -0700 (PDT) Received: from ?IPv6:2406:e007:521f:1:28cc:dc4c:9703:6781? ([2406:e007:521f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v11sm5110527pfl.101.2017.08.16.13.33.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 13:33:37 -0700 (PDT) Subject: Re: RFC 4861 missing updated-by To: Mikael Abrahamsson , Timothy Winters Cc: Michael Richardson , 6man WG References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <62b5db1b-8422-78de-6bdd-cfd817438c67@gmail.com> Date: Thu, 17 Aug 2017 08:33:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 20:33:41 -0000 On 17/08/2017 00:48, Mikael Abrahamsson wrote: > On Wed, 16 Aug 2017, Timothy Winters wrote: > >> I looked thru the IPv6 Ready Logo Test Specification for this, we test >> this for NAs and NSs but not RSs/RAs. I've filed a bug to update the >> Test Specification to check this in the next release. > > Great takeaway from this discussion. I have personally run into problems > with an implementation that did not ignore MBZ bits but instead required > them to be 0. Since the sender of the packet had a bug and didn't zero > them, this caused things not to work. > > The sender of the packet which didn't zero the bits immediately understood > what the problem was and offered to correct things, however the vendor of > the device that didn't ignore the bits took a lot longer to convince that > they were doing something wrong. Sorry to repeat myself, but that's exactly the point we made in https://tools.ietf.org/html/rfc6709#section-4.2 In other words, it's a quite general problem, and an excellent area for test suites to exercise. And IMNSHO it clearly shows why we need an "updates" for such cases, as well as an IANA registry. Implementers make mistakes, and we should use every tool we have to make this less likely. Brian > > This was OSPFv3 and it had a 24 bit field in there with the remaining 8 > bits being MBZ and ignored. The vendor put this into a 32 bit field and > compared meaning that when the other end messed up their zeroing the > reserved bits, the compare failed. I'd imagine this is not too uncommon > problem. > From nobody Wed Aug 16 14:38: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 DAA88132744 for ; Wed, 16 Aug 2017 14:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncr6ojdkZ7ZC for ; Wed, 16 Aug 2017 14:38:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 586BF132742 for ; Wed, 16 Aug 2017 14:38:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 54FFF20599; Wed, 16 Aug 2017 17:40:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7D4A58076D; Wed, 16 Aug 2017 17:38:01 -0400 (EDT) From: Michael Richardson To: Ole Troan , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:38:07 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson wrote: >> I don't think adding a new flag in a "Reserved" field qualifies as >> updating an RFC. >> That's what we have IANA registries for. > So where is the IANA registry for the bit fields that RFC4861 > standardises? Right. So either way, 4861 has errata. Either it's missing a registry, or it's missing a forward reference :-) > 1. If you move reserved bits to in-use, you update the original RFC that > defined these bits as reserved. Metadata is added to the original RFC > so this can be found. > 2. There must be IANA registries for all bit fields, and if you change > reserved bits to in-use, this must be reflected in the IANA registry. I suggest the following policy, and maybe I'm signing up to write a BCP here. a) Reserved, (Send as zero, do not examine on receive) fields are simply noted as they are now. b) The first document to do anything with that Reserved area, if it's creating new bits, or putting some new field there, Updates the original document, and creates the IANA Registry. c) Additional documents cite the Registry rather that Updates. Ole, could you get on board with that? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmUuzkACgkQgItw+93Q 3WWQCAf6AnWIOZUVCUqIHNwjoIfYqf5R9S9oxwQFAV47Y+d67nMXhq3Groz1ulx6 4RB/oiL3x5OX3mguRg3eU6ndYirk9twGiq+DwB/Md52FlhVGj9OL6TCX+YEeUds5 zHJ8lMP7xf0Jf4JW7WeXVTXroMJBm9Qkc6rcKKifbIWsGq+6FS5zVThKIUYzsRWK maeBHtCenlT0u+6Ij/YDPLp6BEyCKyTctybrDzbjfyDu2TrTyJ6Vg8/jILz+a153 IeZbPCmA8rpXExhZeVjUwiTjiDov4SRG9jWXtPZjNsPrYMIlS+Sj9Bg9Y1bwUyAv hKbUAZRg6e3nQAZ3DDoqb98//R7pRQ== =nqJX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 16 14:50: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 E4D0D13274D for ; Wed, 16 Aug 2017 14:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT65qPZ7YflT for ; Wed, 16 Aug 2017 14:50:08 -0700 (PDT) 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 978A5132031 for ; Wed, 16 Aug 2017 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7GLnwWH024549; Wed, 16 Aug 2017 23:49:58 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (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 3xXjgV4QH0zDLWj; Wed, 16 Aug 2017 23:49:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFC 4861 missing updated-by From: Carsten Bormann In-Reply-To: <4864.1502919481@obiwan.sandelman.ca> Date: Wed, 16 Aug 2017 23:49:58 +0200 Cc: Ole Troan , 6man WG X-Mao-Original-Outgoing-Id: 524612997.777307-462666f0f8ef192ae76b79eca978b532 Content-Transfer-Encoding: quoted-printable Message-Id: <338FC806-C696-44ED-A0C5-4B0B9D1A6F84@tzi.org> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <4864.1502919481@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:50:12 -0000 > I suggest the following policy, and maybe I'm signing up to write a = BCP here. >=20 > a) Reserved, (Send as zero, do not examine on receive) If you think that is what =E2=80=9CReserved=E2=80=9D means, more power = to you, but a rather common understanding of =E2=80=9CReserved=E2=80=9D = is =E2=80=9CWe may define those bits later=E2=80=9D, with the implied = conclusion that a receiving implementation simply gives up and croaks = when finding a reserved bit set. So don=E2=80=99t use the term =E2=80=9Creserved=E2=80=9D without = qualification (or, better, not at all). > fields are simply > noted as they are now. Having these =E2=80=9Ccould be used later for extension points=E2=80=9D = bits in a protocol is fine, even without a registry, because you cannot = define the registry if you don=E2=80=99t know what the structure of = these bits is going to be. > b) The first document to do anything with that Reserved area, if it's = creating > new bits, or putting some new field there, Updates the original = document, > and creates the IANA Registry. Well, any document that starts eating bits for extension points needs to = do that. The registry created for the first document that comes up may not be the = right one for the second document. (The bug here was that 4861 should have foreseen that these bits were = going to be allocated. So here, the first document would indeed simply repair that defect. But that is not true in the general case where you have scattered random = unused bits in your packet.) > c) Additional documents cite the Registry rather that Updates. Right. Once you have the right structure for the registries. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Aug 16 19:35: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 D37071323A8 for ; Wed, 16 Aug 2017 19:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLSvTJGud6FZ for ; Wed, 16 Aug 2017 19:35:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69E413217D for ; Wed, 16 Aug 2017 19:34:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C6E3203B0; Wed, 16 Aug 2017 22:37:39 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B92738007E; Wed, 16 Aug 2017 22:34:58 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: Ole Troan , 6man WG Subject: Re: RFC 4861 missing updated-by In-Reply-To: <338FC806-C696-44ED-A0C5-4B0B9D1A6F84@tzi.org> References: <8447.1502388439@obiwan.sandelman.ca> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <4864.1502919481@obiwan.sandelman.ca> <338FC806-C696-44ED-A0C5-4B0B9D1A6F84@tzi.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 02:35:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> I suggest the following policy, and maybe I'm signing up to write a = BCP here. >> >> a) Reserved, (Send as zero, do not examine on receive) > If you think that is what =E2=80=9CReserved=E2=80=9D means, more powe= r to you, but a > rather common understanding of =E2=80=9CReserved=E2=80=9D is =E2=80= =9CWe may define those bits > later=E2=80=9D, with the implied conclusion that a receiving implemen= tation > simply gives up and croaks when finding a reserved bit set. https://tools.ietf.org/html/rfc6709#section-4.2 says exactly that. > Having these =E2=80=9Ccould be used later for extension points=E2=80= =9D bits in a > protocol is fine, even without a registry, because you cannot define > the registry if you don=E2=80=99t know what the structure of these bi= ts is > going to be. Exactly. >> b) The first document to do anything with that Reserved area, if it'= s creating >> new bits, or putting some new field there, Updates the original docu= ment, >> and creates the IANA Registry. > Well, any document that starts eating bits for extension points needs > to do that. yes, but in this case, it didn't. > The registry created for the first document that comes up may not be > the right one for the second document. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmVANIACgkQgItw+93Q 3WXvIwf/ZtAKuY6SpSaH/b2UZluVsP1BValhRlB+026xCVbcA+UiDPX3dnciX7sH H056p88BzValSuODuz3UaVDP8MbYwvkwEMtsRjxtozxMAYMsQEe4K42H1OtF/Cvr Bq4NKMJ8P0UxXhItdny7DiRtABZItKGx8PuN1VavMsvOsoIzSXl1otHdQnhAOeyJ 1LVghAVClnZHhFCZCtm6/5SVOOO+U01AYhAR0ntPFxWua5tb7Z8zFAobhFZv67Yl 4dYvTbJzYYUBvQHB/ZKPLHsZqN8TM3Wg1ZgC4BOK+2g1hKtLke1MWRY7xFkx7QBA +vdmTC38dA0XXbog+mhwOwwoRXNP8Q== =2U5L -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 31 16:07: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 70AFE132F76 for ; Thu, 31 Aug 2017 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTO96iaEJu5U for ; Thu, 31 Aug 2017 16:07:29 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13915132F6F for ; Thu, 31 Aug 2017 16:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7VN7SP2035176; Thu, 31 Aug 2017 16:07:28 -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 v7VN7N2D035072 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 31 Aug 2017 16:07: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.1320.4; Thu, 31 Aug 2017 16:07:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 16:07:22 -0700 From: "Templin, Fred L" To: 6man WG Subject: ICMPv6 question Thread-Topic: ICMPv6 question Thread-Index: AdMirYG7EwN54XmxT+uCHTYv5GBqHg== Date: Thu, 31 Aug 2017 23:07:22 +0000 Message-ID: <952aab1a2c824a79b98a3f9d2b3a473a@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 23:07:30 -0000 SSBoYXZlIGEgcXVlc3Rpb24uIElmIGFuIElQVjYgaG9zdCB3aXRoIGFkZHJlc3MgMjAwMTpkYjg6 OmYwMCBhc3NpZ25lZCB0byBhbiBpbnRlcmZhY2UNCnJlY2VpdmVzIGEgcGFja2V0IHdpdGggZGVz dGluYXRpb24gYWRkcmVzcyAyMDAxOmRiODo6YmFhIG92ZXIgdGhhdCBpbnRlcmZhY2UsIHdoYXQN CnNob3VsZCBpdCBkbz8gRHJvcCB0aGUgcGFja2V0IHNpbGVudGx5LCBvciBkcm9wIGFuZCByZXR1 cm4gYW4gSUNNUHY2IERlc3RpbmF0aW9uDQpVbnJlYWNoYWJsZT8NCg0KVGhhbmtzIC0gRnJlZA0K From nobody Thu Aug 31 16:35: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 43CF8132FC5 for ; Thu, 31 Aug 2017 16:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVc1QOSW7-ib for ; Thu, 31 Aug 2017 16:35:49 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7F8132FB9 for ; Thu, 31 Aug 2017 16:35:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7VNZm5M006012; Thu, 31 Aug 2017 16:35:48 -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 v7VNZjCE006001 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 31 Aug 2017 16:35:45 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 16:35:45 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 16:35:45 -0700 From: "Manfredi, Albert E" To: "Templin, Fred L" , 6man WG Subject: RE: ICMPv6 question Thread-Topic: ICMPv6 question Thread-Index: AdMirYG7EwN54XmxT+uCHTYv5GBqHgAAw0HQ Date: Thu, 31 Aug 2017 23:35:44 +0000 Message-ID: <956f0877cf0f4d2a9e67cbf5b8bdeec6@XCH15-06-11.nw.nos.boeing.com> References: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 23:35:51 -0000 -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > I have a question. If an IPV6 host with address 2001:db8::f00 > assigned to an interface receives a packet with destination address > 2001:db8::baa over that interface, what should it do? Drop the > packet silently, or drop and return an ICMPv6 Destination > Unreachable? You said host and not router. Assuming that the prefix length is the same f= or the intended destination of the packet and for the host that received th= e packet, so the packet is not misrouted, then this sounds like what you'd = frequently expect to see in older Ethernets, either coax Ethernets or half = duplex ones that use hubs. But why didn't the Ethernet interface discard th= e packet? The MAC address should not have matched. Was it a ND failure scen= ario of some kind? (In general, I don't see why a host should send host unreachable ICMP messa= ges.) Bert From nobody Thu Aug 31 16:51: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 ECE6A13301E for ; Thu, 31 Aug 2017 16:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v14rLBOflHX4 for ; Thu, 31 Aug 2017 16:51:23 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB39132E55 for ; Thu, 31 Aug 2017 16:51:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v7VNpMlu025615; Thu, 31 Aug 2017 16:51:22 -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 v7VNpDwx025204 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 31 Aug 2017 16:51:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 16:51:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 16:51:13 -0700 From: "Templin, Fred L" To: "Manfredi, Albert E" , 6man WG Subject: RE: ICMPv6 question Thread-Topic: ICMPv6 question Thread-Index: AdMirYG7EwN54XmxT+uCHTYv5GBqHgAAw0HQAACxZAA= Date: Thu, 31 Aug 2017 23:51:12 +0000 Message-ID: References: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> <956f0877cf0f4d2a9e67cbf5b8bdeec6@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: <956f0877cf0f4d2a9e67cbf5b8bdeec6@XCH15-06-11.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 23:51:25 -0000 HI Bert, > -----Original Message----- > From: Manfredi, Albert E > Sent: Thursday, August 31, 2017 4:36 PM > To: Templin, Fred L ; 6man WG > Subject: RE: ICMPv6 question >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L >=20 > > I have a question. If an IPV6 host with address 2001:db8::f00 > > assigned to an interface receives a packet with destination address > > 2001:db8::baa over that interface, what should it do? Drop the > > packet silently, or drop and return an ICMPv6 Destination > > Unreachable? >=20 > You said host and not router. Yes - host. > Assuming that the prefix length is the same for the intended destination = of the packet and for the host > that received the packet, so the packet is not misrouted, Yes - assume that the prefix 2001:db8::/64 is assigned to the incoming inte= rface. > then this sounds like what you'd frequently expect to see in older Ethern= ets, > either coax Ethernets or half duplex ones that use hubs. But why didn't t= he Ethernet interface discard the packet? The MAC address > should not have matched. Was it a ND failure scenario of some kind? I am assuming that the bogus packet uses a correct MAC destination address but with an incorrect IPv6 destination address. So, the packet gets handed up to the IPv6 layer. > (In general, I don't see why a host should send host unreachable ICMP mes= sages.) Drop silent would make sense to me, too - but do others think an ICMP should be generated? Thanks - Fred > Bert From nobody Thu Aug 31 17:27: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 CBA2F132ED9 for ; Thu, 31 Aug 2017 17:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPKeHYVTc3oN for ; Thu, 31 Aug 2017 17:27:20 -0700 (PDT) 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 0D251132FCF for ; Thu, 31 Aug 2017 17:27:20 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id j46so3407909uag.5 for ; Thu, 31 Aug 2017 17:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xU839au7Lr9sh8LrptzGG4TwqX907Qzu7dL9bqgGewo=; b=OUz//B5+IFnZGZ+htn8GcK72kovRe8zj33Y0IeNQShYR1ulgOKJssr9Yl63Vfxc6AD M45/qd6eo+8QvJdtLSwzshLV+MSSd5TMrGexlu72YM9Xdz3fYUMlRMlm8UNK4lhIIy9Y swK3mKK1rnVe/w0PwmX30DjUvYPrDt/I7hMwsVD9w2crDgj0K4/ZBvmIUV5oea9T5db5 uXgs81h3tuv59kRAcNTbNA1Hw9Ndh30K9wta974Mh5Q7S0/w9SN5jQzti+qWRAS8eN/3 nT394T/wJ1hVY8lZFFoptyWO8imC2qA8IjYSJXf6Bzkq5YvldG7/Ej/vUZvUtoINCfbG cA4w== 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=xU839au7Lr9sh8LrptzGG4TwqX907Qzu7dL9bqgGewo=; b=hmAFdn/kgeVLU3Fb7hdwWravbfXzVoHL3O7hIH0fXufJbGmqFx7DZTMYqsr5boAnZg OElGZmsH8ARl10gO/OX5dqqUv20TdEtCGi7g/ixMhZli/V5cK2dj85i4zJ4X8yl2E9+N 8Ni08kuXnNtPxcoXboIVl5heO/PaK0pWHSAhUr7IVZbvh73QFz2ypWQEGgammcH6LvGM xQgM1FZ8p2GDlDF497jbn3UbaiEXx3ur6f/VwQPqLd0eMCSMCg1T4ggoYzErEXRfAzG2 cQnkFBmK2ly9H280aWzzqP1J+K2cadti3L3iaKFwPKbA92/RkfI/DJgWA7VKsOKH1qIt 1aJQ== X-Gm-Message-State: AHPjjUhUbhZVZpztrNOmcqZkZlS0660tUYCsfSi4bqgTZd0hqwbibjov 6eGShBbAU7oVdpYt8DdlBy4lXyIsTg== X-Google-Smtp-Source: ADKCNb7jNbm27zVEb0nCc5PDYVDdHYJucHyDCHfY45NCwJ9LRTG2P5+0Oc/7PgcjExHJi313B4nPCxyPJ8YGaFq1G6M= X-Received: by 10.176.26.173 with SMTP id j45mr162284uai.33.1504225639091; Thu, 31 Aug 2017 17:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Thu, 31 Aug 2017 17:26:48 -0700 (PDT) In-Reply-To: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> References: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Fri, 1 Sep 2017 10:26:48 +1000 Message-ID: Subject: Re: ICMPv6 question To: "Templin, Fred L" Cc: 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 00:27:22 -0000 2001:db8::f00 On 1 September 2017 at 09:07, Templin, Fred L wrote: > I have a question. If an IPV6 host with address 2001:db8::f00 assigned to an interface > receives a packet with destination address 2001:db8::baa over that interface, what > should it do? Drop the packet silently, or drop and return an ICMPv6 Destination > Unreachable? > Hmm, at face value it appears to be a simple question and the answer would be DU. Looking at RFC4443, it limits generation of DUs to routers or the packet source host: "A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)" Per RFC8200 (a.k.a. new RFC2460), we have these definitions for a router and a host router a node that forwards IPv6 packets not explicitly addressed to itself. (See Note below.) host any node that is not a router. (See Note below.) A host is therefore to ignore "IPv6 packets not explicitly addressed to itself", which I think means a host does not generate a DU for misdirected packets. I was wondering about how this could happen and I think there could be two possible causes, - incorrect ND cache entry for 2001:db8::baa2001:db8::baa, somehow with the link layer address of 2001:db8::f00 - host attached to one end of a point-to-point link, and the upstream device (likely router) is blindly forwarding packets over the p2p link assuming the destination is at the other end rather than performing ND to discover and continue to verify the presence of the specific addresses at the other end of the link (That's why I think ND should be performed on p2p links. Even a /127 configured on one end of the link doesn't guarantee the other address within the /127 is present. If a router performed ND on p2p links, it could discover the DA for a packet is not present and generate a DU for it.) Regards, Mark. > Thanks - Fred > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Aug 31 17:44:47 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B3132E6A for ; Thu, 31 Aug 2017 17:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtBaRUPH6Og2 for ; Thu, 31 Aug 2017 17:44:43 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF530132E7D for ; Thu, 31 Aug 2017 17:44:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v810igsC045206; Thu, 31 Aug 2017 17:44:43 -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 v810idXv045189 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 31 Aug 2017 17:44:39 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 31 Aug 2017 17:44:38 -0700 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Thu, 31 Aug 2017 17:44:38 -0700 From: "Manfredi, Albert E" To: "Templin, Fred L" , 6man WG Subject: RE: ICMPv6 question Thread-Topic: ICMPv6 question Thread-Index: AdMirYG7EwN54XmxT+uCHTYv5GBqHgAAw0HQAACxZAAAAdWkAA== Date: Fri, 1 Sep 2017 00:44:38 +0000 Message-ID: References: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> <956f0877cf0f4d2a9e67cbf5b8bdeec6@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 00:44:45 -0000 -----Original Message----- From: Templin, Fred L=20 > I am assuming that the bogus packet uses a correct MAC destination > address but with an incorrect IPv6 destination address. So, the packet > gets handed up to the IPv6 layer. Or maybe there's another more or less legitimate reason, Fred. Ethernet in = promiscuous mode. In which case, it's working as intended. Still, like Mark= showed aptly, a destination host wouldn't be sending host unreachable ICMP= messages. Bert From nobody Thu Aug 31 18:20:42 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C379132F0E for ; Thu, 31 Aug 2017 18:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 RcN6akklG6kt for ; Thu, 31 Aug 2017 18:20:38 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3C133087 for ; Thu, 31 Aug 2017 18:20:38 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id b8so3679088pgn.5 for ; Thu, 31 Aug 2017 18:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1pvYP3Y+8nEWP2HIs/alCGS97jWO0nrcgvBMG747oZA=; b=m1Ak0xjLH0zL0/EjKUHD9crvNLZgl0MSJxNuhtDfTeWjeRyEoofBGPvcy6Ar4G4Rvx gxthb8vv0BRAod9hdwZbsFOJ9lKfV9RK9xZv5KLZAKSjDpd1ZoObmt5KmF07kRPlFzD8 0WgnupiPKNwK2iB+HTbodwVrQBmnA+FNndEbbsaf97x5S3rrfWw2GUtd5lcdZTmSCgiG BAhV5eOo/zJ4VS7l36wN47K5jZgUAJ2XAt7Eu5KcI0sTCiQ7hymAdLw93oxdBIPqg0fT ggP2HyQigP+Dq9biNCN19f/c76I2Zb7HwmbF967wIeqCgnRMiyqB8gVxnf2SfWjtbD8Z OYug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1pvYP3Y+8nEWP2HIs/alCGS97jWO0nrcgvBMG747oZA=; b=HJNIqpcsZzWSvSQoiWHuvlMsvyPcIDveyp5zSTPIwhCrWnM7eUKD3qbkqZ6zlbqO+B hY6KtHcxR72Xbi+qkyqdhYO9PJyGaYT24Nqdg7Wu1AoNaxGRi1SzUMkR7SQjLuQAe6DB 3t3WCnSXhLkE1VtCwIL9v6iVKax0t9oIry/1RvyXanhVcEmoFY1sQEMRd513G1RKmEE4 NkJdtf2XEqORx1GvVCF4AdcGs6J8J+djlZTFFYmi09L/1rtlH8aJZH2XV+k1FIoacnHq Nm6bQq+48ACqVE3C20FBWzmPDLi6d06qxsQ8+EoXVmI3SsqOJ7WLJl/p/sJN/TvH+UD3 0p9Q== X-Gm-Message-State: AHPjjUjhhZysdOG00kkaSxS+IYFCITjfyTa6Ikt7dLMnx86qgTRvez3j BI8d4s5fuPVlKFUo X-Google-Smtp-Source: ADKCNb6CSm7M7OaYLE2OVy7DqDOaPbl1X9FxuULxBG2L+WEJEFhqSHt+aG6wcQYWJQvTaR8WDtc1dQ== X-Received: by 10.98.211.91 with SMTP id q88mr412818pfg.105.1504228837297; Thu, 31 Aug 2017 18:20:37 -0700 (PDT) Received: from ?IPv6:2406:e007:5c9e:1:28cc:dc4c:9703:6781? ([2406:e007:5c9e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a15sm1102076pfl.1.2017.08.31.18.20.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 18:20:36 -0700 (PDT) Subject: Re: ICMPv6 question To: Mark Smith , "Templin, Fred L" Cc: 6man WG References: <952aab1a2c824a79b98a3f9d2b3a473a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <862b7558-f0e5-93c9-8d93-b740af0ced6a@gmail.com> Date: Fri, 1 Sep 2017 13:20:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 01:20:40 -0000 On 01/09/2017 12:26, Mark Smith wrote: > 2001:db8::f00 > > On 1 September 2017 at 09:07, Templin, Fred L wrote: >> I have a question. If an IPV6 host with address 2001:db8::f00 assigned to an interface >> receives a packet with destination address 2001:db8::baa over that interface, what >> should it do? Drop the packet silently, or drop and return an ICMPv6 Destination >> Unreachable? >> > > Hmm, at face value it appears to be a simple question and the answer > would be DU. > > Looking at RFC4443, it limits generation of DUs to routers or the > packet source host: > > "A Destination Unreachable message SHOULD be generated by a router, or > by the IPv6 layer in the originating node, in response to a packet > that cannot be delivered to its destination address for reasons other > than congestion. (An ICMPv6 message MUST NOT be generated if a > packet is dropped due to congestion.)A Destination Unreachable > message SHOULD be generated by a router, or > by the IPv6 layer in the originating node, in response to a packet > that cannot be delivered to its destination address for reasons other > than congestion. (An ICMPv6 message MUST NOT be generated if a > packet is dropped due to congestion.)" > > > Per RFC8200 (a.k.a. new RFC2460), we have these definitions for a > router and a host > > router a node that forwards IPv6 packets not explicitly > addressed to itself. (See Note below.) > > host any node that is not a router. (See Note below.) > > > > A host is therefore to ignore "IPv6 packets not explicitly addressed > to itself", which I think means a host does not generate a DU for > misdirected packets. > > > I was wondering about how this could happen and I think there could be > two possible causes, > > - incorrect ND cache entry for 2001:db8::baa2001:db8::baa, somehow > with the link layer address of 2001:db8::f00 > > - host attached to one end of a point-to-point link, and the upstream > device (likely router) is blindly forwarding packets over the p2p link > assuming the destination is at the other end rather than performing ND > to discover and continue to verify the presence of the specific > addresses at the other end of the link (That's why I think ND should > be performed on p2p links. Even a /127 configured on one end of the > link doesn't guarantee the other address within the /127 is present. > If a router performed ND on p2p links, it could discover the DA for a > packet is not present and generate a DU for it.) You can induce this trivially with a /128 host route to 2001:db8::baa via 2001:db8::f00 (or via its LL address). I just tested this on a Windows machine, with the innocent victim being a Linux machine. TL;DR: The result was silent discard. Here's what happens in detail. I slightly obscured the GUA prefix: 1. No route installed, just sending a bogus ping: C:\windows\system32>ping 2406:e007:59ce:1::f00 Pinging 2406:e007:59ce:1::f00 with 32 bytes of data: Destination host unreachable. (In this case there was a failed Neighbor Discovery, of course.) 2. Install a host route via the GUA of the target: C:\windows\system32>route add 2406:e007:59ce:1::f00/128 2406:e007:59ce:1:5967:affa:3750:b289 OK! C:\windows\system32>ping 2406:e007:59ce:1::f00 Pinging 2406:e007:59ce:1::f00 with 32 bytes of data: Request timed out. 3. Replace that with a host route via the LLA of the target: C:\windows\system32>route delete 2406:e007:59ce:1::f00/128 2406:e007:59ce:1:5967:affa:3750:b289 OK! C:\windows\system32>route add 2406:e007:59ce:1::f00/128 fe80::9051:543a:4c9e:e93e OK! C:\windows\system32>ping 2406:e007:59ce:1::f00 Pinging 2406:e007:59ce:1::f00 with 32 bytes of data: Request timed out. I checked with WireShark, and the ICMP Echo Request messages were definitely sent to 2406:e007:59ce:1::f00 at the MAC address of the host known as 2406:e007:59ce:1:5967:affa:3750:b289 or fe80::9051:543a:4c9e:e93e, and there were no reply packets. Brian