Re: about violation of standards

Gyan Mishra <hayabusagsm@gmail.com> Tue, 23 April 2019 00:00 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 EBF10120266 for <ipv6@ietfa.amsl.com>; Mon, 22 Apr 2019 17:00:33 -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 6TkoQuwhXzQm for <ipv6@ietfa.amsl.com>; Mon, 22 Apr 2019 17:00:31 -0700 (PDT)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 60996120265 for <ipv6@ietf.org>; Mon, 22 Apr 2019 17:00:31 -0700 (PDT)
Received: by mail-it1-x134.google.com with SMTP id u65so20967039itc.2 for <ipv6@ietf.org>; Mon, 22 Apr 2019 17:00:31 -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=JgHFT/nItJiEWoFQaT4A9YLgKVSrBpmQlvs80Xl+19g=; b=Z3B2DZ308xyabwTogPhvUr6EvNMCoou9NID+trOGRWyItjKUVCn7U2c425UP3h1luK hadfOq3jyB9A1tSfG4gXRyWhWQ6v+5U9idgtDytxYCFTVR0XVuh8vsSSTlJ0n8hrcT0n 0SAWrA0EQRO2N1WFhg77Mruu+mOu5qDN++8NGahciGVOjkChuF0zSEcDxHBlXSVwgg1f QKrGp+i3MWJ6lOXgIGjvdqEJF3GXc/lAQv/IY2/30XPy4cAYJoZ458Y0VO/s8HyPRHfF MJsQwZ+lDro0SBJuBMHfGktljzaOHJvXKFT6gVUbb6UvYoymnzBMB0gtnn/c63JtYLg2 ivmg==
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=JgHFT/nItJiEWoFQaT4A9YLgKVSrBpmQlvs80Xl+19g=; b=FAuNEsEP25ibPd4fBeOKfLml2ILnFi2a2EterB6v2WHewQj7EWU1D20hOLnGmRnl/W 8uJY4Zf8NdosAgiMrMtteZntXC+6IROMwRI4zIvfN0n6KsE1B6i3I1PVxlHtfXg0EXaQ FaqN2PtyX8Wzc3qrSXnaeW/y4pgbyPrQLg9qr49F2d6WZlZyKz8bGqapp+Ol6DaOD+le eDP7yJHAZ+r6zI2upoVjx9zw+1q6oh6xumjSu6qTx7fEIXscExLAHOlFveSNj+voKWb1 lSuhFlmb13haw6i9yRH+whztJ4ISZtxk9zUKchozX77QTrwnuNrUMnO/YKuZ30KFGtRy qR8w==
X-Gm-Message-State: APjAAAWmROlMPdDLrCThlTCAUSc4sb+gFyFD8mgIHgfTZkCzDw1m8Os3 SUq17zamFzF7ISYgWTRIR+M+m92IeFm7kRf2aNI=
X-Google-Smtp-Source: APXvYqwZdNqhwOeY62karhekG+QcGEgcOTIE+gcB7TkmP+0G5ScvuucCDb4jibr1wX8rzWyMdvxfq1tZeus6rLVkhoA=
X-Received: by 2002:a24:6987:: with SMTP id e129mr19003itc.28.1555977630483; Mon, 22 Apr 2019 17:00:30 -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>
In-Reply-To: <4786ccac-9633-932b-badb-ca89ab15cd73@foobar.org>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 22 Apr 2019 20:00:17 -0400
Message-ID: <CABNhwV0oytua-OVHk3NLztOo_BYfenOAMsav5cKDR8sU6MzEmg@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="000000000000f1870805872745cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-kDchyU4PtPQA_1WhvMObTSo3m0>
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:00:34 -0000

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