Re: disagreement on which OS should change
Gyan Mishra <hayabusagsm@gmail.com> Sat, 27 April 2019 18:10 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F54A1201A3 for <ipv6@ietfa.amsl.com>; Sat, 27 Apr 2019 11:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNLGqliSyCDt for <ipv6@ietfa.amsl.com>; Sat, 27 Apr 2019 11:10:47 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2D012011C for <ipv6@ietf.org>; Sat, 27 Apr 2019 11:10:46 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id e13so10650636itk.4 for <ipv6@ietf.org>; Sat, 27 Apr 2019 11:10:46 -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=70uJ24WDq2SrLfB/QTSMq2Kj2cdntr6gS3Y8zVeQK08=; b=uuT2V0jk9onybt2Aq6aLUVF8SLCxcVc++3yl35A8xHRU+aVxOKPopJ83SHfg6dLs55 1OMLlTkgILaC06co854Ivc1JnI2GaILiB3jh6ls0jiOymqYfNgGk1ae4LFWQaRhkxyhW A2JTIIYoRRvLppa+SuXJ1+AVBo57lGsxariu0mJAifcrDvHmjEQPEML4piEh7Fap/mFk te64e5yPnvGqZEwOajDjiuu711LNTJOhLyMdaaEGuKlbm7MwPMm1oa3auQQ5aFQbRpUe lByZANwVuFUBfrpcHBztQ/ctsOSW28tbWyzhx1ITq6WoV2snDoLKC6IhUAFZQuXAMRuz w4jQ==
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=70uJ24WDq2SrLfB/QTSMq2Kj2cdntr6gS3Y8zVeQK08=; b=Kkdl4OFYcBR4+kvCUUBSiMajZU8OrDqLMKNoxKeAPkeTiYat7Qs48YD0juFurLLu5j u9qX/HTTnKph7Yzow+jJ3j/XT0hQEeG43kaTMIesiJiJUtn9LjibL8iBkiudGfwJfNWZ US9L1FqpjCLSz5/+SPopoQ2mOnY32ZPhRMSjNkVWP3aBBMlWmZZ7vfrMR5GAAIhbSQIG wPhBu0eP4oNgkZe20j410xRksILaJ1FeWLWdkgyqk715D0TcHq8jnsgoCXGqzHdmU5W5 46HbYRIBmPxn2xZFwTSxHA+k0jk/FaZ4sKzzCWbH0O0tYLx+Hbd4aaDQMIuLfEMwnoEF gsNQ==
X-Gm-Message-State: APjAAAX4/0Vv21Nrce66mwFRt1p9jLthv174I1n+/AnyMrtja2IqEgvd 1iSgsFrk2xj8HU1srV5owYBiL7mGw7n7Ofy1N8s=
X-Google-Smtp-Source: APXvYqzcZ7hGpbxTYGH1pPdBFeE8+qNoSLeYJaLw8Z1frgwWZj+Izt81rCW1echHd+ptXJlpHS5Fmy2r/vMuVCY11Ro=
X-Received: by 2002:a02:3b24:: with SMTP id c36mr12640563jaa.52.1556388645966; Sat, 27 Apr 2019 11:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com> <CAJE_bqe8OXPWRDvXEY66gZHiBgv37OV67YB27WoEtq_VmBqieQ@mail.gmail.com> <3F852B26-FD19-445D-A8E9-94BCBB9BE7C1@gmail.com> <455C3D20-E71B-4DF4-837E-081964E3328A@gmail.com> <19275484-3fa5-7c4e-3624-b861ddea6e2f@gmail.com> <2B1FBA08-3DDB-4287-B2B4-11324334B7FC@employees.org> <CAJE_bqdg3wjbJOmB2iPij00yNXbES7Hj7WYtKH0vyY+9Lce3ow@mail.gmail.com> <6da1d50c-2835-d98e-2ab9-41cdd4d9f367@gmail.com> <CAJE_bqeahhEax1GvrgdDiCkDRhUpqu-9NpR4sYpEuqwYU==WZQ@mail.gmail.com> <96291515-b70b-5451-d3e4-e44f25cd93bb@gmail.com> <5D35DDCE-1A41-4BEA-B178-344B70AC41D4@gmail.com>
In-Reply-To: <5D35DDCE-1A41-4BEA-B178-344B70AC41D4@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 27 Apr 2019 14:10:33 -0400
Message-ID: <CABNhwV0Y38AsqOX=6NkguL_CTD=r9VcyDM7F0ArAzDrAKPDd7g@mail.gmail.com>
Subject: Re: disagreement on which OS should change
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: 神明達哉 <jinmei@wide.ad.jp>, IPv6 IPv6 List <ipv6@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000601b0c058786f8a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FZPd1aH-cG8jve6d3KDqRdi2GDM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2019 18:10:49 -0000
Alex What real world problem are we trying to solve with updating the link local address format. I don't think a valid reason for updating the standard because of OS glitches that allow using 1s in the 54 bit all 0s field of the link local prefix. I think if we don't have a real world problem we are trying to solve then if nothing is broken why fix something that is not broken. As you can see it is complicated and there are two methods of making the change but both options have their complexities and issues. Option 1: 54 bit all 0s field would be part of the 64 bit EUI station id so 118 bit field basically a 54 bit extension of the interface is. Issue with this option I see is that all hosts have the concept of 64 bit station id EUI64 or random but because of the 64 bit boundary for network prefix and station id so the 54 bits end up falling in the network prefix portion of the IPv6 address so then if those bits are set now the hosts become off net not on the same link local local subnet as other hosts and all hosts including the router need to have the same exact 54 bits set to be on now the same subnet. This option won't work as it really transforms into option #2 with slaac for link local and dad for link local subnet field Option #2 link local slaac with DAD algorithm of auto config assignment via router RA the 54 bit station id. So for this to work we would have to create a new SLAAC with DAD algorithm for this new link local subnet field. For this draft to be viable Option #2 Is the only way I see it possible. Gyan Gyan On Sat, Apr 27, 2019, 1:13 AM Gyan Mishra <hayabusagsm@gmail.com> wrote: > Alex > > I agree and that completely makes sense what you are saying. > > So with RFC 4291 all hosts for all subnets we’re actually sitting on the > same fe80::/64 even though different physical or logical interfaces and > each host was made unique by the EUI64 station id. > > So with the new draft if all hosts would sitting on the same global > unicast subnet now also sit on the same unique Link local subnet. So the > RA for Default route sent to all hosts on the subnet would be this new LInk > local set on the router > > Subnet 1: > Router A fe80:1::EUI64 bia vrrp vip fe80:1::1 ::/0 sent to host > > Router B fe80:1::EUI64 bia vrrp vip fe80:1::1 ::/0 sent to host > > Host A fe80:1::EUI64 bia > > Host B fe80:1::EUI64 bia > > > Subnet 2: > Router A fe80:2::EUI64 bia vrrp vip fe80:2::1 ::/0 sent to host > > Router B fe80:2::EUI64 bia vrrp vip fe80:2::1 ::/0 sent to host > > Host A fe80:2::EUI64 bia > > Host B fe80:2::EUI64 bia > > Gyan > > Sent from my iPhone > > > On Apr 26, 2019, at 5:11 AM, Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > > > > > > > >> Le 25/04/2019 à 18:09, 神明達哉 a écrit : > >> At Thu, 25 Apr 2019 09:41:35 +0200, > >> Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto: > alexandre.petrescu@gmail.com>> wrote: > >> > > > That an implementation allows you to do something does not mean > that > >> > > it is supported (in the product sense) nor that the RFC is wrong. > >> > > > >> > > Right, but I actually don't understand why we still have to have > this > >> > > kind of conversation. Almost all real-world implementations have > some > >> > > glitch; > >> > > >> > The problem here would be to ask which of the OSs have the glitch: the > >> > ones that support fe80:1:: or the ones that dont? > >> Obviously the former. > > > > I think it is the latter: the OSs that dont support fe80:1:: should > change. > > > > Alex > > > > > > > > ------------------------------------------------------------------------- > > If time permits: > > > > I would like to make a note here. I know that AD and Chairs read these > messages. I would like to invite consideration of these messages, if time > permits, when pondering about which way the balance tips. > > > > My reading of these discussions is that: > > > > - one person, or small group of persons, indeed highly knowledgeable, > consider fe80:1:: to be a violation of standards, an RFC to be right, one > OS to be right, manual config of LLs to be wrong. > > > > - probably more persons, or at least several persons, consider fe80:1:: > to not be a violation of standards, some other OSs to be right, manual > config of LLs to be right, 'liberal in what you accept', 'open minded'. > > > > (some person is in both categories). > > > > This is my reading of the discussion. > > > > Alex > > > > > > The question itself is nonsense to me, equal to > >> a question asking which OS has the glitch: an implementation allowing > >> to send a packet with source=::1 outside of the node, or an > >> implementation that prevents it. > >> If you don't like to consider it to be a glitch, update RFC4291. As > >> you've already seen it would be quite hard, but it's not necessarily > >> impossible. Insisting a standard violation behavior is not a glitch > >> because of the existence of the behavior is just a time wasting > >> effort. > >> -- > >> JINMEI, Tatuya > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >
- Re: about violation of standards Kerry Lynn
- about violation of standards Alexandre Petrescu
- Re: about violation of standards Suresh Krishnan
- Re: about violation of standards Kerry Lynn
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Kerry Lynn
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Mark Smith
- Re: about violation of standards Fernando Gont
- Re: about violation of standards 神明達哉
- Re: about violation of standards Pascal Thubert (pthubert)
- encoding link ID in link-local addrs (Re: about v… 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… Gyan Mishra
- Re: encoding link ID in link-local addrs (Re: abo… Gyan Mishra
- Re: about violation of standards Yucel Guven
- Re: about violation of standards 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Nick Hilliard
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Gyan Mishra
- Re: about violation of standards Ole Troan
- Globally Unique Link Local Addresses (Re: about v… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- RE: about violation of standards Pascal Thubert (pthubert)
- Re: about violation of standards Ole Troan
- Re: Globally Unique Link Local Addresses (Re: abo… Philip Homburg
- Re: Globally Unique Link Local Addresses (Re: abo… Brian E Carpenter
- Re: about violation of standards Brian E Carpenter
- Re: about violation of standards Gyan Mishra
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Gyan Mishra
- Re: Globally Unique Link Local Addresses (Re: abo… 神明達哉
- Re: about violation of standards Mikael Abrahamsson
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - security matte… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: about violation of standards - fe80::1/128 Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: about violation of standards - fe80::1/128 神明達哉
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Ole Troan
- Re: about violation of standards Nick Hilliard
- Re: about violation of standards Yucel Guven
- Re: Globally Unique Link Local Addresses (Re: abo… 神明達哉
- Re: Globally Unique Link Local Addresses (Re: abo… Brian E Carpenter
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: about violation of standards Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Alexandre Petrescu
- Re: Globally Unique Link Local Addresses (Re: abo… Alexandre Petrescu
- Re: encoding link ID in link-local addrs (Re: abo… Philip Homburg
- Re: encoding link ID in link-local addrs (Re: abo… Ole Troan
- Re: encoding link ID in link-local addrs (Re: abo… Mudric, Dusan (Dusan)
- Re: about violation of standards Yucel Guven
- Re: encoding link ID in link-local addrs (Re: abo… 神明達哉
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - fe80::1/128 Gyan Mishra
- Re: encoding link ID in link-local addrs (Re: abo… Brian E Carpenter
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Smith
- Re: about violation of standards - fe80::1/128 Pascal Thubert (pthubert)
- Re: Globally Unique Link Local Addresses (Re: abo… Mark Andrews
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: about violation of standards Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: encoding Subnet ID in link-local addrs - prob… Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Mark Smith
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Mark Smith
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: about violation of standards Yucel Guven
- Re: easy to remember addresses and /etc/hosts and… Kerry Lynn
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: about violation of standards Erik Kline
- RE: encoding Subnet ID in link-local addrs (Re: a… Manfredi (US), Albert E
- Re: Globally Unique Link Local Addresses (Re: abo… Gyan Mishra
- Reinventing Site-Locals (Re: easy to remember add… Mark Smith
- Re: Reinventing Site-Locals (Re: easy to remember… Mark Smith
- Re: Reinventing Site-Locals (Re: easy to remember… Brian E Carpenter
- Re: disagreement on which OS should change Gyan Mishra
- Re: about violation of standards Fernando Gont
- Re: disagreement on which OS should change Brian Carpenter
- Re: disagreement on which OS should change Ole Troan
- Re: disagreement on which OS should change Fernando Gont
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: easy to remember addresses and /etc/hosts and… Alexandre Petrescu
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Gyan Mishra
- Re: disagreement on which OS should change 神明達哉
- Re: disagreement on which OS should change Bob Hinden
- Re: disagreement on which OS should change Gyan Mishra
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: disagreement on which OS should change Bob Hinden
- Re: Reinventing Site-Locals Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Alexandre Petrescu
- Re: disagreement on which OS should change Tim Chown
- Re: disagreement on which OS should change Bob Hinden
- Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Philip Homburg
- Re: Wireless ND was: about violation of standards Ole Troan
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Ole Troan
- RE: Wireless ND was: about violation of standards Pascal Thubert (pthubert)
- Re: Wireless ND was: about violation of standards Philip Homburg
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- RE: encoding Subnet ID in link-local addrs (Re: a… Mudric, Dusan (Dusan)
- Re: encoding Subnet ID in link-local addrs (Re: a… Alexandre Petrescu
- Re: about violation of standards Erik Kline
- Re: about violation of standards Erik Kline