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

神明達哉 <> Tue, 07 March 2017 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93CAD129A78 for <>; Mon, 6 Mar 2017 17:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Status: No, score=-2.369 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, URIBL_BLOCKED=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 0WwvY36tRUEP for <>; Mon, 6 Mar 2017 17:11:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3F9E1298A0 for <>; Mon, 6 Mar 2017 17:11:08 -0800 (PST)
Received: by with SMTP id 1so184296007qkl.3 for <>; Mon, 06 Mar 2017 17:11:08 -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; bh=nAgrmHEgUTaR7kqdsFArU6G/NGmKp/nTsNhO9FGo3bM=; b=d+Brf4s2+qMPUzynBSVEqjFY7Xf6lqxijqdeS/IEBejH0+2M8n7amEAAUff/hrYRU+ sx8EPajkeP+LyOvSaVU9jTaQu4y+3zVr63dWNr9cMSywgnJG92uLhS15W5Mt9F2j4sog n3+CrUCVYoBBf64Z8ZcyM+HzPtilgfjjbGA3w2JLSU/1sKxsyKeYu/sbHrU2Tf8RvOpA v1wHKeUU7ldB9f20BmIoI7QGiPksmbzAlH3YuwGUjqThD1VIlaPjMg+d/bkxfuHJlWX+ 540CzAeqsatQuBnrYEWZ0iBMsRyAjCs7G8q9E5SjkiyXmGQ0t56JS4++jSBPl2o2yrTX MWUg==
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; bh=nAgrmHEgUTaR7kqdsFArU6G/NGmKp/nTsNhO9FGo3bM=; b=L5V6YU5ujSR1dzJOpZGAzp/PfqzEnedNbbKvKJ4fsDrgp75L0xDG/RmJS1c7lzZTIz J3Yv06xOfR6gWN/W9c33sIv00wYeDCCMYINyTVBK3B1M68U4qFxKdcN4JyKdUjZS2t2H Ckd8Jk+QHhc3RXrzRDbTUDq1z+o5aP4cOfhmHDiZ4hYUXgkskR+q6cBvyOfjyTCtSlRx bYWHU4bKTsCMfhlckZ+91OFe3l3R+KORJn7wIuW1QiPfbyCSiI2Gre7G8wDy6mdLFTB5 CfoH3EN9IL6wRiXmyI7EQK0nMT5JOSmjNL42w5QShvksWJHrcnq6INgZomX0DYSJbIOC aMIg==
X-Gm-Message-State: AMke39lHFSJDPtNurJk+jeBjpKIALJrYGQ2/L4LfroIjQDZTn2oiff6TyW2kgWJ97/OVf9uWCv03p+Sd5joqvQ==
X-Received: by with SMTP id l63mr18074178qkc.149.1488849067891; Mon, 06 Mar 2017 17:11:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 6 Mar 2017 17:11:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Mon, 6 Mar 2017 17:11:07 -0800
X-Google-Sender-Auth: b_dg3CNvmVy4Tq1bfgy6FZgKymc
Message-ID: <>
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07
To: Timothy Winters <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: james woodyatt <>, 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 01:11:10 -0000

At Mon, 6 Mar 2017 19:34:43 -0500,
Timothy Winters <> wrote:

> I don't believe this test is too strict based on 4862 Section 6.3.4 "
> Similarly,
>    [ADDRCONF <>] may
> impose certain restrictions on the prefix length for
>    address configuration purposes.  Therefore, the prefix might be
>    rejected by [ADDRCONF
> <>] implementation in
> the host.  However, the
>    prefix length is still valid for on-link determination when combined
>    with other flags in the prefix option."
> Basically ND still works even if SLAAC thinks the prefix length is
> invalid.   It's really a ND test for on-link deteremination.

I'd also note that the above text didn't exist in RFC2461; it was
newly introduced in RFC4861.  If I remember it correctly the added
text was an attempt of clarifying validation for on-link determination
and validation for SLAAC are independent, as it had often been
misunderstood.  RFC4862 also tried to clarify that point, e.g., in
this text:

      [...]  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.

But this thread and another similar discussion seem to suggest that
it's still not clear enough for some people.  At least two different
readers interpret this text:

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

as the PIO MUST be ignored for all purposes including on-link
determination.  In a sense, it's not necessarily surprising - no
matter how we try to clarify a point there's always a reader that
still interprets it differently.  But if there is really a protocol
conformance test that doesn't interpret the text differently it's
really surprising to me.

The bottom line is, if there is an implementation that ignores a PIO
- with both L and A flag on, and
- with prefix length being something other than 64
- received on a link whose IID is specified to be 64 (like Ethernet)
even for on-link determination, then that implementation violates
RFC4861.  I can also assure that the document editor of RFC4862 didn't
intend such "strictness" - on the contrary, he actually tried to
clarify that's not the intent, but it looks like it's still not super

JINMEI, Tatuya