Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

神明達哉 <> Tue, 07 March 2017 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F19621294C1 for <>; Tue, 7 Mar 2017 10:36:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Status: No, score=-1.67 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, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kWVbnJUDPMum for <>; Tue, 7 Mar 2017 10:36:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C7D012948C for <>; Tue, 7 Mar 2017 10:36:49 -0800 (PST)
Received: by with SMTP id y76so18737000qkb.0 for <>; Tue, 07 Mar 2017 10:36:49 -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=nfQLOWDyQDln22iJ8paesCYCSOp/jMAhzWbz3PRP8j4=; b=OIYr1mcmjv6axN/d6zRmjsclPhCSUy5Ay/SKR/gBZ4o06zlr6dtExtDhL4vSQAXDLB +cix3nZsSnvxu9uX4t9tDdItFkdK9/zNEx+th2oWJDv+HO07QzpiYTD/ykaymQplb59B uHBvwP3968/7hDh2n/tbpAJ5clLjEoQvxDRIrXCNYtbO+tOOmryY2WuhqaT4ZOyHlGz9 txwYizm03tQa4M5LNlQ+ilUMlnr7/AsUHL2EJGQo7Omn3LtAtLQkGLckabTe4nEcPeMk 9qu8nYwpWw9diG86NA0KOmPx70yOwF7kAnWs//PNzDx5IqcjQNQ9i/3YeEp0jm4ONBil PQiw==
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=nfQLOWDyQDln22iJ8paesCYCSOp/jMAhzWbz3PRP8j4=; b=eLLRkLFgCqy6dGK4Qon+uxb25U+Z0ZL8W87af7Ph3uk7VKHLucS0ODMvMyP26aEOwi W4VG3tJF6malbcMcTzDCPJfe321I/tgJ/lZXQbsbLnQpvbrxvQTweJ/Ba44luMsOo6aM BX1d0Our/BxmncwQl0N+lq6j8DRYzFYYdf8yeENOyNotPIr4pIud03Btjy3dyZJ1tTAy RQhe1QQDiiG/FGyxVsnGbq9BprmKvhxJHV6lBFPGEvOh6ZwzUpKb5LmDMEaDuzm02iBS wrDXfNpQBgs4tgv5k8TTnNkdMLpm1R+z1sIb894aGsNSqizOelZMP2GRuqv2GmD7WeJW a8EA==
X-Gm-Message-State: AMke39k/UUBtNht4SzbII+a1u8IoZuutfpESdgvORFaPRB8vgLIINo6/yX2iRCy/8Nx0oSLNt3X2r9zVsJEuBw==
X-Received: by with SMTP id b23mr2181674qta.163.1488911808341; Tue, 07 Mar 2017 10:36:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 7 Mar 2017 10:36:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 7 Mar 2017 10:36:47 -0800
X-Google-Sender-Auth: ThIkwYXGCZfBMBqlHM9FLLQMjmQ
Message-ID: <>
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"
To: Alexandre Petrescu <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IPv6 IPv6 List <>
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 18:36:51 -0000

At Tue, 7 Mar 2017 11:44:04 +0100,
Alexandre Petrescu <> wrote:

> > 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
> >> ignored.
> Let me say that there are some interpretations of that sum from people
> struggling to make it work.  These interpretations may be surprising to
> the specifier.
> The specifier is tempted to think that that "sum" equation is a good way
> to tell everything in just one phrase.
> But some people face the problem of making that sum be 128 even though
> the plen is less than 64 and the IID is 64.

> It is the case with the fe80:://10 needing to become a fe80::/64, and it
> is also the case when PIO in RA has a P1::/63.

At least the above text from Section 5.5.3 of RFC4862 is irrelevant to
link-local addresses.  The entire Section 5.5 is about "Creation of
Global Addresses" as the title shows.  In the case of creating global
addresses, I can't think of an interpretation of 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 it allows the creation in the case of advertised plen=63 and IID
len=64.  RFC4862 requires not to do so with the MUST.  BSDs implement
it that way, and so does Linux (according to what I heard here).  I'm
also pretty sure that there's a conformance test tool like that for
"IPv6 ready logo" or USGv6 that confirms the intent of the RFC.  And
so I'm also pretty sure that other major OSes interpret the RFC as it
intends.  So, overall, I don't think it's just what a document editor
intends in his mind, but a widely accepted interpretation.

That said, there's always someone who understands any seemingly clear
text differently from the actual intent, not to mention the recent row
about EH insertion.  So I'm not surprised that there are such people.
If you think this point is so unclear for so many people, I'd suggest
you write a clarification draft or submit an errata.  If you think we
should actually allow the creation in such a case, that's a protocol
change, and I'd suggest you write a draft to update RFC4862.  With
luck, that will become the new standard.

I don't think continuing this topic in this thread brings us anywhere,
so I'll stop here.

JINMEI, Tatuya