Re: about violation of standards
Gyan Mishra <hayabusagsm@gmail.com> Tue, 23 April 2019 00:04 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 8FE1112024F for <ipv6@ietfa.amsl.com>; Mon, 22 Apr 2019 17:04:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0JG6k0hMiYi for <ipv6@ietfa.amsl.com>; Mon, 22 Apr 2019 17:04:17 -0700 (PDT)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 47FB5120222 for <ipv6@ietf.org>; Mon, 22 Apr 2019 17:04:17 -0700 (PDT)
Received: by mail-it1-x143.google.com with SMTP id z17so545358itc.1 for <ipv6@ietf.org>; Mon, 22 Apr 2019 17:04:17 -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=FuUOgJwAxfPQWuD8w1Vmbx7HoqfdpHjtJm+dIDru6dI=; b=n7uIcvIWwaUo8I5vZxA/sDFe6huJB7G6blxx2m3jKBL+A9w4KduJ4Vg93eugWw+UEX 2zJEAMCxy6rgBA29Gn1j6ekUgRavV2XC7Dk2qUWT/B4zDtvwDeIF9RlTjzoFOz64zhjj YMXXxg9z3XO0ermktPC3HHjX8eqHD0UxKl6o3FpH6MhiaJB+xdfsF4SyikCMHngk/DXV g4o/rgiLvEFEvgEt8KFeLWgaXuhQ9XqEGeMx4wFWjun0L+jqFb/dVRWssxDKcXJlmSBg AOiwbzWFsIvij8/F39JSdEYyWsGMyL1ZocKGK5opkCXmFC8Iq/j7MuWHVvOXqIEIIp87 PbKA==
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=FuUOgJwAxfPQWuD8w1Vmbx7HoqfdpHjtJm+dIDru6dI=; b=YAAryolj4QhWreDD+7Dd1uwMdGUPGOlPd1jeWdHtLD1uW/Jq+/JARSRGiSy00OOTb4 QrZiQimBQFlkTfPydwnTWS8tfDhJfQCUvZTDvuMukRZdNQib7V/ZGaQgTQbT4ABYmprv xlO5AB3sh4uA3G6gjV/fflNXQ9UgJC3xXs7+XrAi3laNDWmwTDCbdQ+9lAAgFMF6qSzf 1sJBKZ+KJfAfGDbGQk/lMStONgk9ExHyOYmiNZMxHYuewG/fJiXeCGru1H3f1WzGrFT3 i2dA/9UoZgyzNsBokFqA1Bw9Mwje///Ze83p87i01saGjbUKn7xhVphQX7LzTQnZOZ9W oKGg==
X-Gm-Message-State: APjAAAX3R8kY3ZrnS8WvxB3o/yZSHjAFmI9mg2STFVZOLZFQNndjw8jy Ag0dx6BWJKan12WZ1vsMUzJbP+zikHdLdaHxvzA=
X-Google-Smtp-Source: APXvYqzW55H7ppLQh0g80oFvOhVmduCKmhdvhr1b9IqceDGS+v1TRSynTvM28Wmj8xiwTAezZstVQEYzpqUWYK8Zm3g=
X-Received: by 2002:a02:b0c5:: with SMTP id w5mr6156427jah.95.1555977856455; Mon, 22 Apr 2019 17:04:16 -0700 (PDT)
MIME-Version: 1.0
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <CAKQ4NaWLGh3f_dN6WVNnYs9fKL8=vfpnShAK8AczPo8LE8LjFA@mail.gmail.com> <a7ef29b1-09ff-d4da-d802-6f0ccfc2d4f3@gmail.com> <4786ccac-9633-932b-badb-ca89ab15cd73@foobar.org> <CABNhwV0oytua-OVHk3NLztOo_BYfenOAMsav5cKDR8sU6MzEmg@mail.gmail.com>
In-Reply-To: <CABNhwV0oytua-OVHk3NLztOo_BYfenOAMsav5cKDR8sU6MzEmg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 22 Apr 2019 20:04:03 -0400
Message-ID: <CABNhwV3a=5WeOGeN2BwRSTJcq_EAVH+eekoSDw3eSDFNSXehOw@mail.gmail.com>
Subject: Re: about violation of standards
To: Nick Hilliard <nick@foobar.org>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, IPv6 IPv6 List <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="000000000000699dde058727531d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HFbw7UPEvy6pg0PVKg3zNdgNmZM>
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: Tue, 23 Apr 2019 00:04:20 -0000
...this is also from one of my earlier posts at a desperate hope to put this discussion about allowing fe80:1::1 and having a consensus agreement by all that it is not allowed per RED 4291. One other comment I would like to make as far as standard and that we should not allow the OS Unix or Windows or any network operating system drive or change the standards. Here is the case and point. Cisco routers for example most all platforms these days use a Linux BSD kernel so is similar to a standalone Linux flavor server. What I have noticed and confirmed and this is from extensive IPv6 testing is that the OS for IPv4 has the capability to do subnet and mask check for valid IPv4 address coded however IPv6 due to the complexity of IPv6 with 128 bits a subnet check is done and will spit out error for router anycast if used but major loophole exists and that is that you can configure any global unicast address in the network 64 bit portion that is not valid and same goes for Link local addresses. I believe that is due the coding checks limitations within the OS to check against what is valid and what is not is so complex to code that OS allows anything to be configured even though from an IETF RFC perspective it’s not following the standard IPv6 format. For example for my CCIE studies I would always code my v6 marching v4 so v4 is let’s say 10.0.0.1/30 I would make my v6 address 10::1/126. That being said the fe80:1::1 can be coded on both Linux host and a CISCO router with Linux kernel under the hood but that does not make it correct or valid that we should now change the RFC 4291 to allow that to happen. I don’t see any justification to allowing the 54 bits in the network 64 bit portion of the link local address to be changed from all 0s. Please respond back to this email thread if you feel differently and also respond if you agree. On Mon, Apr 22, 2019, 8:00 PM Gyan Mishra <hayabusagsm@gmail.com> wrote: > I honestly cannot believe that we have been discussing or even > entertaining discussing this topic. > > The IPv6 WG was developed to define standards and not think of ways of > loopholes to violate the rules of the standard that have been developed and > especially that have been the standard for decades. Absolutely absurd!!! > > BELOW IS MY EARLIER POST > > WE SHOULD NOT AT ALL COSTS VIOLATE RFC 4291!!!!!!!!!!!!!!!!!!!!! > > There are many implementations worldwide that I have been involved in > deployment of IPv6 using a standard architecture that I deploy to all my > customers and that involves setting the station id on the link local > address so that the next hop is more intuitive and easily recognizable that > it’s your local next hop since by default all routers and hosts set the > station id to EUI64 format FFFE big stuff into the MAC address between the > 3rd and 4th octet which is “non intuitive” > > So the IPv6 addressing RFC 4291 states the 1st 10 bits used for fe80 and > the next 54 bits must be set to 0 which covers the 64 bit prefix length so > the entire station id 64 bits is open to be modified and changed as the end > user desires on any platform and that is following the current RFC > standard. > > So in Alexandre scenario with BSD setting the LL to FE80::1 would be fine > but if you did fe80:1::1 that would be setting 1s in the all 0s 54 bit > field of the station id which is not allowed. > > So as far a variable link local address I am in favor of variable and you > have the entire 64 bit station id to modify which is fine but I am > completely not in favor of violating the current standard of writing into > the 54 bit all 0s portion of the network prefix. > > 2.5.6. Link-Local IPv6 Unicast Addresses > Link-Local addresses are for use on a single link. Link-Local > addresses have the following format: > | 10 | > | bits | 54 bits | 64 bits | > +----------+-------------------------+----------------------------+ > |1111111010| 0 | interface ID | > +----------+-------------------------+----------------------------+ > Link-Local addresses are designed to be used for addressing on a > single link for purposes such as automatic address configuration, > neighbor discovery, or when no routers are present. > Routers must not forward any packets with Link-Local source or > destination addresses to other links. > > On Mon, Apr 22, 2019, 6:04 PM Nick Hilliard <nick@foobar.org> wrote: > >> Alexandre Petrescu wrote on 22/04/2019 20:38: >> > I would like to add something else: the implementation that does _not_ >> > allow the users to add fe80:1::1 (BSD) does not complain about it. It >> > silently refuses. >> >> this is expected behaviour on BSD (Kame derivatives?). fe80::/10 >> configuration is controlled by the "ifconfig XX auto_linklocal" >> directive. If auto_linklocal is configured, then the kernel will >> automatically configure the fe80::/64 prefix. You cannot configure the >> value directly. >> >> Nick >> >> -------------------------------------------------------------------- >> 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