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

神明達哉 <> Tue, 07 March 2017 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDDEA1294CC for <>; Tue, 7 Mar 2017 11:34:49 -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 FUbNjy2RBzm9 for <>; Tue, 7 Mar 2017 11:34:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 438F71294A4 for <>; Tue, 7 Mar 2017 11:34:48 -0800 (PST)
Received: by with SMTP id v125so21022724qkh.2 for <>; Tue, 07 Mar 2017 11:34:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=AhzhYgK1Y0kVM7RyoFb3Y1/xVRro3PouhrBrBiMVAOI=; b=pTcd7Up560frCpp0Le5sBxeL4xqg7rHvYcv4ABg2oVelKilxO+ZFx0hsqYUpSvowMP 2exIYaLWyo3CdL1m34pQBMpDdGM3eXPqtmDD37dI48FyTOCqRVGdBd7e0rC65VYBlrH6 1frsVz8f05GFqTkhYCZm7P0Z68CMN6hX0YPiM3PrP9kRAsa+sZHO/J0LS9lF3sHlyHpZ m0Lk8ovpMueNyJYOq6Wog7nNB7feNp9GbLuyidvYOmOOIdRmVkF3maQ3TbmgKFjs0vol yfOTue8MaTw1yuUhfy/OkRSNrks2BxbU33oGHU9ma7h97CQndWSRPGY6t37U0GI4/9/x K18w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=AhzhYgK1Y0kVM7RyoFb3Y1/xVRro3PouhrBrBiMVAOI=; b=ZU+MzB9olxaUeTuPovf+2j8KOOAbl+GLyN4q1/S2i41ehNal7HYl3ySN89POUmIfeK 9Q04qVbISP4cdu8hr744j95mOh86tGBZWsuLuEkoW61m/MhUOAOsvW5wMcXgyyRkLR/F T7BBDoITTrGs+ZQeVdMBUxZ4AqAagMxrIMOekGuKC2HR805ZeDzPlYpqFURgwDZzA/zn BZTgz12ZVuWpcOe7vDa+lstVl25sdGUJseRkf8PkmsWLS4jNFWQlpIX34ZCYWUvLIiwt iqH/u+q4ioojVTdPielVj17xJDBRR5xNVJ/MvybwAzYBNifduoAIIpv8vxXLElCXFlLV cvag==
X-Gm-Message-State: AMke39m28ICkmY4aEj6lTtGSXh4EseP8o536HAHHl+3hnKoZf9vCg1RRx5NsSqcp5aYJy85v5wiQqjwLdbqbww==
X-Received: by with SMTP id b23mr2503944qta.163.1488915287193; Tue, 07 Mar 2017 11:34:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Mar 2017 11:34:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 7 Mar 2017 11:34:46 -0800
X-Google-Sender-Auth: E6RNppaZr6slpXrRHCXvWYCbGrs
Message-ID: <>
Subject: 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: 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: Tue, 07 Mar 2017 19:34:50 -0000

At Tue, 7 Mar 2017 10:59:19 -0800,
james woodyatt <> wrote:

> > It's valid to ignore it for SLAAC, but not ND.   RFC 4861 is clear about processing the PIO for on-link determination, LwIP isn't following ND spec.
> >
> I’m happy to defer to your considerable expertise in these matters.
> Question: could you point me at the requirements language in RFC 4861 that LwIP is specifically violating? I’m confused because when I search on the phrase "Prefix Length” in the text, the relevant excerpt that seems to apply is this one:
> >>       Note: Implementations can choose to process the on-link aspects of
> >>       the prefixes separately from the stateless address
> >>       autoconfiguration aspects of the prefixes by, e.g., passing a copy
> >>       of each valid Router Advertisement message to both an "on-link"
> >>       and an "addrconf" function.  Each function can then operate
> >>       independently on the prefixes that have the appropriate flag set.
> The way I read this is that implementations MAY choose to process the Prefix Length validation differently in on-link determination and SLAAC functions, but that it doesn’t seem to be expressly REQUIRED. Sadly, there don’t seem to be any other relevant texts about the Prefix Length.

Hmm...are seeking an RFC2119 keyword REQUIRED, MUST or SHALL in
RFC4861 that would make the LwIP implementation non-compliant on this
point undeniably?  If so, I'm afraid there is no such explicit

Personally, however, the overall text both in RFC4861 and RFC4862 is
so clear that such an implementation would be considered
non-compliant.  In addition to other things pointed out in this
discussion, if RFC4862 Section 5.5.3 bullet d

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be

would be interpreted as it allows the host to ignore such a prefix
(with L=1) even for on-link determination, we'd also apply the same
logic for other cases, like this one:

    a)  If the Autonomous flag is not set, silently ignore the Prefix
      Information option.

But, I (hopefully) believe no one would ever argue that a host is
allowed to ignore a prefix with A=0 and L=1 for on-link determination
because of this bullet.  So, if you see the context rather than a
specific sentence without taking into account the context, it's also
pretty clear to me that bullet d only talks about SLAAC.

If these circumstantial evidences are really not enough to convince
LwIP implementers, maybe we should file an errata for RFC4861 and/or
4862 to clarify that point.  I believe we can at least reach a wg
consensus that it's the intent of the RFCs (I'm not sure if we can add
an RFC2119 keyword in an errata, though).

JINMEI, Tatuya