Re: A proposal for draft-ietf-6man-rfc4291bis-07

james woodyatt <> Mon, 06 March 2017 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BC93129A0F for <>; Mon, 6 Mar 2017 13:03:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gzT-JhMlT9I7 for <>; Mon, 6 Mar 2017 13:03:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83F301294E8 for <>; Mon, 6 Mar 2017 12:53:23 -0800 (PST)
Received: by with SMTP id j5so65146583pfb.2 for <>; Mon, 06 Mar 2017 12:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LAkhfCvkpbFmOergtvsWuwYs8vptKADwE2JZWEvYyY0=; b=RTlltylGCmPyRPpbPQ529+S2u0e3k7eot+cg/qFh4egcBGc+5Kha7H5i7ra3do2Gr7 yVgdf5D4mb+xPwh1StZT/iSziEWWspN0VEriJIRW+OR0RAP8AOOVAK0I14sQp+U/gMYs ycZMuG8dWmPkuOtgCVWxfxvrQNgEA4+MI2q3ayeY8ByLb+YGLOUAqDNuFmDBGttmL4o0 omm93PAUYHADwTYf8aY3m1tAZYOl4H5T5SBjFI2LEhQ9Z2Vt/MA7Ex7FdM3m78gAdYBS oX7ClSYgvbI7Luhq8vWVq8+7unIgZQuApgdVEcMerOtmgYsoLBtKVhcm6kY4N882JS2h WQ0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LAkhfCvkpbFmOergtvsWuwYs8vptKADwE2JZWEvYyY0=; b=rYdcA3xtujAEl59tXJKwIqzzBnOh3EfCjJeZNGnfX485LyZr8Nbm+Bzysdy52e8W1Z +35KPkGWm2JHsM/rYOm1weXUS5RMH3VBHcExrIT58+C08l/mfssjEvIs2qzQlsR1CCdt AosxDwHB407JiyFzVQS+D3CKdFulbGe40izsFVUb/eQyZ2HBmYC2BLpXM7Y/It+ChGFU 7p1l1NSIwvVv3qZL1il5lTMAQhXsQ+AjWo+oBp/aBjysh7/77G10kj3zxPrOAUHENpiL fj4BQKNhTOnadlMMeyqAyHRIeCNa0RNoks+JClv2zbTqVSz25Vkfe6JAfHQCBjt+XEE9 6I0w==
X-Gm-Message-State: AMke39kHTl1Nj9XnNSRhK3qVfrvfxPd7IrG45SYFIF/JTnW62yzZdejln+nA9sBbfgR0FVrj
X-Received: by with SMTP id o7mr22923301pgd.6.1488833602979; Mon, 06 Mar 2017 12:53:22 -0800 (PST)
Received: from ([]) by with ESMTPSA id m67sm41299055pfj.32.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 12:53:22 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C982BA9C-85A3-4FEB-B399-62170047BFF0"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
Date: Mon, 6 Mar 2017 12:53:19 -0800
In-Reply-To: <>
To: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: IPv6 Operations <>, 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Mar 2017 21:03:40 -0000

On Mar 6, 2017, at 10:47, Philip Homburg <> wrote:
> Finally, the 'MUST drop' interpetation is not consistent with the
> behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where
> the 'MUST drop' interpretation comes from and if anyone ever bothered
> to check out the behavior of existing stacks.

Looking at the relevant source code for a couple of the latest BSD-variant kernels, I believe you’re right about the current behavior on those platforms. My memory of them must be outdated. I think they used to drop PIO according to a strict interpretation of RFC 4862. I distinctly remember having to implement it that way in order to pass a certification test. I believe these implementations will not any longer pass that test. (One imagines either their owners don’t care, or the test has been revised to be more lenient.)

I am however looking at a commonly used lightweight IP stack that simply ignores all PIO options unless Prefix Length = 128 - IID Length (and it safely assumes all interface identifiers are length 64 because it doesn’t support link types with other IID lengths, and it’s also unsuitable for use in the environments where IETF standards make exceptions for other IID lengths). This stack was developed entirely apart from the Linux and KAME efforts, by people who read the fine RFCs and implemented the simplest lightest-weight thing possible that is still compliant with the requirements language. That’s important for people on platforms where every byte of code and stack space is precious.

p1. I get that RFC 4862 has requirements language that annoys some participants. We are not here revising RFC 4862 however, so that’s not relevant.

p2. The stack I’m using implements SLAAC and-- for completely defensible reasons— follows the letter of RFC 4862 requirements. Its current behavior is compliant with RFC 4291, RFC 4861 and RFC 4862. It’s not exactly uncommon in the field today, and it’s not currently broken by the proposed successor to RFC 4291 with its current language about IID length.

p3. I get that people want to hold up promotion of IPv6 to Full Standard until the successor of RFC 4291 is changed to declare explicitly that the stack I’m using is in error. My opinion is this is a procedural matter, not a technical matter.

I object to the procedural step being proposed, not the technical argument. If we MUST declare the stack I’m using to be in error, then please let’s NOT do it in this draft. Can you not wait until RFC 4861 and RFC 4862 are next revised?

--james woodyatt < <>>