Re: disagreement on which OS should change

Gyan Mishra <hayabusagsm@gmail.com> Sat, 27 April 2019 05:13 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 1D2DB12008F for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 22:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_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 VImPoF8NTKV0 for <ipv6@ietfa.amsl.com>; Fri, 26 Apr 2019 22:13:31 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AB812008A for <ipv6@ietf.org>; Fri, 26 Apr 2019 22:13:31 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id l199so3164616qke.8 for <ipv6@ietf.org>; Fri, 26 Apr 2019 22:13:31 -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=CIZfUzgaY8bNpUTGoVtk3yvq0R1t1MlP/Bc7jZTbbIU=; b=ZZsNdw4d1yikYzc5UyhwopMqQZAzcxejXzCMGHFl3XbNkGxlWZeArbWIGXb9FTk15h Qz+KnT72xJ9vmqRQlf5WB+tP/ot0oIGe+leK35OsShyUUm+HkMJNy0GmjgiF1Y/LPbzr RswqUQTSYR6BGss0hdgjYMGe20SUUx59q00p5yHu4zspr8cm2QRGhCMlCm8X4TCrNkUY AuHHfayjcsi5hWVnXYf161NACxI/HaRuHrIJdOBOzBKTqzhvjL4GYeottodthWixDsC5 Dw/kR8YQHWpGQQEORlS5IIFbkj6rgoi2jaDymqaPWoz7fQX7SE5JPWaKzFKw+e9F0AKv 34fw==
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=CIZfUzgaY8bNpUTGoVtk3yvq0R1t1MlP/Bc7jZTbbIU=; b=bdTuCywOEd+wPjCr/kni0EHBPHTVW+qmTUaQHPZGVxJGQK3FAO9DQy0qZz2WkUKU5H 0eZgog0TDh0hK0QLOmiVoq+lp+G/cSENXcjqBF86jqqUc7lZgRCILQezhhxdlaRVUoZR BYnRMdrqzia05RZl+eVfqXaKNll405DjAzSIoXAaE0Ft5PcWaeWI+ETomoL9Rh8gUUzC ygjgjPIKsRkDB2ERqR7te9oTRsrdOzObpm6FIujjoCT6NJ34TR4LudC5Lv4I6WtRLiRj qcZgwMo4dXIJW0W1wgxCvrYSNVaUWM3jhXhp9IvckV2pouc9yFEEwOFKfKCGO5TGREtB RmEg==
X-Gm-Message-State: APjAAAXUCp0tqGv7VwcKUxq+5HWobNAIkuofUXsb38Brx2VmtiFTEJpJ g/2TZQr19fW+usdFMlrkGIw=
X-Google-Smtp-Source: APXvYqzgbbF1bpHBprAdlZCnmmP2KnMqyYa+IDmIU2OmytQ7veegM3ogiQ3qmdumosBKdjtnq8WNzw==
X-Received: by 2002:a37:b3c5:: with SMTP id c188mr36452899qkf.97.1556342010570; Fri, 26 Apr 2019 22:13:30 -0700 (PDT)
Received: from ?IPv6:2600:1003:b026:cb23:e49e:9990:8a1e:5a22? ([2600:1003:b026:cb23:e49e:9990:8a1e:5a22]) by smtp.gmail.com with ESMTPSA id m129sm13962265qkb.55.2019.04.26.22.13.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 22:13:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: disagreement on which OS should change
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <96291515-b70b-5451-d3e4-e44f25cd93bb@gmail.com>
Date: Sat, 27 Apr 2019 01:13:28 -0400
Cc: 神明達哉 <jinmei@wide.ad.jp>, IPv6 <ipv6@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D35DDCE-1A41-4BEA-B178-344B70AC41D4@gmail.com>
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>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zEfMvStd0E4B8c47PgHHPhNLWb0>
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 05:13:33 -0000

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