Re: about violation of standards - fe80::1/128

Gyan Mishra <hayabusagsm@gmail.com> Fri, 26 April 2019 04:24 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 3CF741200F7 for <ipv6@ietfa.amsl.com>; Thu, 25 Apr 2019 21:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 1z2_xf6oZwc6 for <ipv6@ietfa.amsl.com>; Thu, 25 Apr 2019 21:24:41 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 C6B4E12004B for <ipv6@ietf.org>; Thu, 25 Apr 2019 21:24:40 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id k38so2740623qtk.2 for <ipv6@ietf.org>; Thu, 25 Apr 2019 21:24:40 -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=Nqbb9hWg1lu8XSlScExxkkrv696lzA3G91W0NS8WwGM=; b=b2Xs0aRaIctp8WSI9Mxuwblu5LBDmY2zUxibFM01uDf7ejrY+HqAvLxR0kZJqMaYr1 vggzCTQxwkPYKNWIfuBZd4O5Rvp1ay0aeSsuV9AUdKQD5pF1MVnwLm7Cp20PDCgEKjmc YvQnng3bYjbvDkwleMEaORFFX3gIyXoNat4funOlJwR+NuKAGKgY4jFI43QVb7Spgjxw UR80iL76qlawT0xPQjlsGkAeShix/IxxdDanUoNxgnybb7jowGc/EAquqheFRTjScYCA K2qvVOh0GPYnoGtnAgZ+8LX6B4n3el/5w3NP55z6wV8io79Hu0DllYn/HRTRLKwbjztC pj3Q==
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=Nqbb9hWg1lu8XSlScExxkkrv696lzA3G91W0NS8WwGM=; b=ISBtUPS8ITNC2Smps+kEMNgdWcrmV+IBRGWaOpuLOFPfcuFQnoxCRvw1ghtS6hqnRT CvrjBIExgAW8s0cV8AKo3hs0AcuGmXGqCrBiBO56tvBG7vBt2C7NtAlBTwzVjzrcdVxr U8MrSmvFAdrBvYyyeR8XyYD335cxJLfJ/5YMgk+DIqTuATedC1CEkxyZqkQAllGEZlAx wdANnljnCzwdnwjxKPmKe9as0qqDUX84P8KyuE/8+9JZNjzIb5pzYOCPlHU91MiW0ZS2 UCKo9OZ/erYfp0HiFHzruJfyxWZJ3x4Yk/gIRm85F7NdBshQGBZou9N9vWfcvn0NJQeg prZA==
X-Gm-Message-State: APjAAAWOW8VkQ0r/N0e1uLoAKNRyK15JNMO4zYrrD9FW5qVCByWzlySF cvfIWxqtWV23PnOlyiE+n1FqqL5k
X-Google-Smtp-Source: APXvYqwguWR0qGjssrkka9m7g+q/LS5YCAuhacoBqFSNqJJv/KnhoBXte4XiJW8lti1bMg4hgTXk8Q==
X-Received: by 2002:ac8:3242:: with SMTP id y2mr21114272qta.190.1556252679601; Thu, 25 Apr 2019 21:24:39 -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 g206sm12097122qkb.75.2019.04.25.21.24.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 21:24:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-A3540DE6-A1CE-4D3A-B849-CC2897FC1FD9"
Mime-Version: 1.0 (1.0)
Subject: Re: about violation of standards - fe80::1/128
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <CAJE_bqf170RceGvJvrmGkkq2tVzLx7nBi+cqQ9fU3xxmyxAE6A@mail.gmail.com>
Date: Fri, 26 Apr 2019 00:24:37 -0400
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, IPv6 <ipv6@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <E2F9B771-2FF7-47C7-9926-C7C68823269D@gmail.com>
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <CAKQ4NaWLGh3f_dN6WVNnYs9fKL8=vfpnShAK8AczPo8LE8LjFA@mail.gmail.com> <CAJE_bqdsJ74ajnCgvm+bWZk=m_Emdy46TKc=73sHG-sf9Czsdg@mail.gmail.com> <a0973403-960b-1136-514d-fd675e318824@gmail.com> <CAJE_bqf170RceGvJvrmGkkq2tVzLx7nBi+cqQ9fU3xxmyxAE6A@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KvBZpaKHIp5oM1OnqF6z-ZGan5o>
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: Fri, 26 Apr 2019 04:24:43 -0000

What I am trying to say and this is very confusing is that CISCO and other BSD Linux based OS don’t have the ability to check for valid IPv6 global unicast or link local configuration that it is following the RFC Standards as with IPv4.

So just because it works does not mean it is correct or ok or that the standards should now change because it works on various OSs that are not following the RFC that we now chant to make that now ok and standard.

We need more justification then that to change the standards.  

In one of the other threads I mentioned that if we are trying to improve or enhance the standard because we have valid future user cases that would require having a new “subnet id” 54 bit  field then it’s ok as we are improving with newer RFC revision making the older one obsolete.

For backwards compatibility the all’s 0s 54 bits would be for legacy devices supporting RFC 4291 so they are not impacted and anything on newer coder can now look at supporting the new RFC.

Gyan

Sent from my iPhone

> On Apr 24, 2019, at 10:49 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
> 
> At Wed, 24 Apr 2019 16:29:59 +0200,
> Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> > As a response, I would like to ask whether fe80::1/128 on lo is a 
> > violation of standards.
> 
> First off, assuming you refer to the behavior of BSD variants
> (including MacOS X), it's not 'lo' but 'loN' (normally just lo0 but
> can also be lo1, lo2, etc, if these are also configured).  The world
> doesn't only consist of Linux.
> 
> Secondly, again assuming it's BSD variants, it's not /128 but /64.
> 
> Third, I don't see which standard it might violate.  Could you be
> more specific?
> 
> If you simply mean whether an implementation could choose to use ::1
> as the mandatory link-local address on a loopback interface and skip
> assigning an fe80 address on it, then I'd say it should be allowed as
> we discussed off-list.  But IMO that would also require some update to
> RFC4291, which is hopefully much less controversial than using a non-0
> value in the intermediate 54-bit field.  And in any case, that doesn't
> mean assigning an fe80 address on such an interface is a violation.
> 
> --
> JINMEI, Tatuya
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------