IETF Logo Mail Archive

Re: encoding link ID in link-local addrs (Re: about violation of standards)

Ole Troan <otroan@employees.org> Wed, 24 April 2019 15:05 UTC

Return-Path: <otroan@employees.org>
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 BE44F1201A8 for <ipv6@ietfa.amsl.com>; Wed, 24 Apr 2019 08:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 x5mXKfsEJAUj for <ipv6@ietfa.amsl.com>; Wed, 24 Apr 2019 08:05:02 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE81512009C for <ipv6@ietf.org>; Wed, 24 Apr 2019 08:05:02 -0700 (PDT)
Received: from [192.168.10.190] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 3AC7BFECBEEE; Wed, 24 Apr 2019 15:05:02 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: encoding link ID in link-local addrs (Re: about violation of standards)
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <19275484-3fa5-7c4e-3624-b861ddea6e2f@gmail.com>
Date: Wed, 24 Apr 2019 17:04:59 +0200
Cc: Gyan Mishra <hayabusagsm@gmail.com>, 神明達哉 <jinmei@wide.ad.jp>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, IPv6 <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B1FBA08-3DDB-4287-B2B4-11324334B7FC@employees.org>
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>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Lo6t9JuU0eukktBEutpid0CX8rU>
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: Wed, 24 Apr 2019 15:05:05 -0000


> On 24 Apr 2019, at 16:53, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> I will add in the draft that Cisco also supports fe80:1::1.  I think I forgot that, but now that you say it I trust it too.
> 
>> 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.
> 
> I dont understand you.
> 
> You say fe80:1::1 works on Cisco, but then you say you seee no justification to allow the 54bits to change from 0.  The first 1 in fe80:1::1 means a change from 0.
> 
> So, do you mean Cisco is wrong?
> 
> Or do you mean such things are wrong and the RFC is right?

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. 
(And I am very familiar with why that particular implementation does what it does).

This has been repeated many times over the last few years. If you want this changed, please provide a problem statement. 

Ole

v2.23.0 | Report a Bug | By Email