IETF Logo Mail Archive

Re: RFC 4861 missing updated-by

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 16 August 2017 12:48 UTC

Return-Path: <swmike@swm.pp.se>
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 E2C091326AE for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 0kv9WHBblJiW for <ipv6@ietfa.amsl.com>; Wed, 16 Aug 2017 05:48:33 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98521326BA for <ipv6@ietf.org>; Wed, 16 Aug 2017 05:48:29 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B4ED9B0; Wed, 16 Aug 2017 14:48:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502887707; bh=xz8xf7zGtd1qqz5sxSXWJbHg6vUDzR0Z8yGMovS1L48=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vAugaQP4auJ5DIBBTx5ukHh75QTrSTLoOnA5Vf+jQ3c8l38yTfPm6qS6dglHAqkxv KBp3fC+RFRKmr0/3rEFMcBhsSKURuw3Nem+CEQgVCG8kd63BwC35T8lNWXMJI2joR0 uE1QBY9Kd6Kp37ehoIJ2mx/2c+JRYrtSGpxEw31Q=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B06C8AF; Wed, 16 Aug 2017 14:48:27 +0200 (CEST)
Date: Wed, 16 Aug 2017 14:48:27 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Timothy Winters <twinters@iol.unh.edu>
cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC 4861 missing updated-by
In-Reply-To: <CAOSSMjVCTMz9K-h08brgs_u5HJjtYmc7RvXrcoB71WgUrhqCLw@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1708161444230.3655@uplift.swm.pp.se>
References: <alpine.DEB.2.02.1708100947130.2261@uplift.swm.pp.se> <8447.1502388439@obiwan.sandelman.ca> <a3ed97e2-e907-6a20-0d00-6de532784f0c@nostrum.com> <826ee900-0edf-2bb4-ed35-3824b6ad8bba@gmail.com> <2664CA78-2291-46C7-ACF9-460AA3A51706@gmail.com> <alpine.DEB.2.02.1708110743410.2261@uplift.swm.pp.se> <52cae497-9539-3ba3-70b7-0bb55317f986@gmail.com> <12017.1502561028@obiwan.sandelman.ca> <alpine.DEB.2.20.1708130754510.3655@uplift.swm.pp.se> <8318F69E-BD7C-404F-9420-0FEA1340936E@employees.org> <alpine.DEB.2.20.1708151234491.3655@uplift.swm.pp.se> <F7C3A4FB-24A4-4A94-9262-FC4C1BF302B7@employees.org> <55c9de60-fdd7-f8c4-4b6d-29f4878d84da@gmail.com> <13BD69AB-B8DF-4023-85A5-813B6A62775A@employees.org> <3843.1502886797@obiwan.sandelman.ca> <CAOSSMjVCTMz9K-h08brgs_u5HJjtYmc7RvXrcoB71WgUrhqCLw@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/re3K2F6O9TV2Rsec4iVhQZWOLfw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Aug 2017 12:48:35 -0000

On Wed, 16 Aug 2017, Timothy Winters wrote:

> I looked thru the IPv6 Ready Logo Test Specification for this, we test 
> this for NAs and NSs but not RSs/RAs.  I've filed a bug to update the 
> Test Specification to check this in the next release.

Great takeaway from this discussion. I have personally run into problems 
with an implementation that did not ignore MBZ bits but instead required 
them to be 0. Since the sender of the packet had a bug and didn't zero 
them, this caused things not to work.

The sender of the packet which didn't zero the bits immediately understood 
what the problem was and offered to correct things, however the vendor of 
the device that didn't ignore the bits took a lot longer to convince that 
they were doing something wrong.

This was OSPFv3 and it had a 24 bit field in there with the remaining 8 
bits being MBZ and ignored. The vendor put this into a 32 bit field and 
compared meaning that when the other end messed up their zeroing the 
reserved bits, the compare failed. I'd imagine this is not too uncommon 
problem.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email