prefix length ban for RFC4861 (Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07)

神明達哉 <> Mon, 06 March 2017 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AAEC1294F3; Mon, 6 Mar 2017 14:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0zOoQp_OtJdx; Mon, 6 Mar 2017 14:15:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B22BF129A4A; Mon, 6 Mar 2017 14:15:37 -0800 (PST)
Received: by with SMTP id p64so60174281qke.1; Mon, 06 Mar 2017 14:15:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=b5fddJlD+/t+qzAZ23iPQxx9wZ0wzni2BIcskk6OAaI=; b=CRvzA6EcNUjweNQoYwN5ty7S25BBjjbQRdDHz3j9XVSc3DbOhC0bxDEujZdH/MwHFB flXztdy0aBx9dW/b7V5eY0w3Ptpwvc4ylgQ6cn3ceBuSaQCLHsGFl2xACEJfKIcdH3mj 3s8JjczWgMBguyCQcXqDr78+Uva6cHlaX+b702uHvNsvFvIKW4IMskfBDhcpHgqlUh16 izN9fm63DzCblgPI9jqCiMKEPxOTGZIC1l7pLN6IPXkOK/XLXTL5EW4PeZkIFFAE2OrK APh2YnCOwqGXfZSM0ODDVnPDXc+t/uM737kbyEyp7IH7n8K8gT7O11klU/eGOFcC81xx PmZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=b5fddJlD+/t+qzAZ23iPQxx9wZ0wzni2BIcskk6OAaI=; b=a3HZ94d0tCR8XfswzRMlAjmIbuWyc41t94PUHQMXa0htByfTXgfsMLgetS1d/sMzx5 ZP504tlhPtXTuYe/BOTKWEacdlWuz639Oc8P1TEKCqwQDFE95gtIJ4wsfpXnj9zB7YTp zpPpZDXRB4qdy6pZfwYo1Jwmdm9oa6x1YQxz2vVRND633xrbQ0EwfZkv8usyJ0CvkNKT oU3BoVKGf7wwlrwd1ZX97LOADNmmUJlGycMdOPYKi3ZLBk5evTWnBl3GqWqbJLWQpMNx EAAYbh3UOECD+Sb5/ds60v+ugMC8gOy8S73gSsBrPP5YS/j9yfv7NugyYsb09AoR4oar SicA==
X-Gm-Message-State: AMke39l2ZbCDH6sWchGwuIBFUGCxMyr16kCjN0IWquWfzZSiH6hppMoMl+ghjR0gG1D6xYQU6Es5jKbd1I6DqQ==
X-Received: by with SMTP id d128mr16178894qkc.86.1488838536636; Mon, 06 Mar 2017 14:15:36 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Mar 2017 14:15:36 -0800 (PST)
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Mon, 6 Mar 2017 14:15:36 -0800
X-Google-Sender-Auth: -VimxPj8HUHg-uACsYXRZ0FbGpA
Message-ID: <>
Subject: prefix length ban for RFC4861 (Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07)
To: james woodyatt <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: Philip Homburg <>, 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 22:15:40 -0000

At Mon, 6 Mar 2017 12:53:19 -0800,
james woodyatt <> 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

BSD variants did NOT ignore PIO for on-link determination simply due
to its prefix length value at least at the time of the publication of
RFC4862 (actually since way before that RFC).  For example, this is
FreeBSD's implementation as of Oct 21, 2005, about two years before
RFC4862 was published:
see nd6_prelist_add() starting at line 993, and find that it only
checks the prefix length for SLAAC (lines from 1258).  At this point
the on-link determination has been completed without any check on the
prefix length (lines 1043-1056).

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

This is quite surprising to me.  Do you have any reference to such a
certification test that requires the host to ignore PIO with a non-64
prefix length for the purpose of on-link determination (i.e., for

JINMEI, Tatuya