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

Lorenzo Colitti <> Fri, 03 March 2017 04:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20D231296EA for <>; Thu, 2 Mar 2017 20:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 SBIv3E8FRUix for <>; Thu, 2 Mar 2017 20:31:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1876012947F for <>; Thu, 2 Mar 2017 20:31:28 -0800 (PST)
Received: by with SMTP id 72so102590072uaf.3 for <>; Thu, 02 Mar 2017 20:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W/GynpDdAA5bQTljTnrGDVOXYq3QRG/0L9JFN57zUL8=; b=GMMtfo+rlZHdrVYoWkLLaIsNYuXoFB0KB2rnmXiOzLyzOfhw+rd7Y6F6CkMgNJQ0s8 f/BwowaLjRDyNeVyasURWBOsx7psHyUfE6aNqhUjMKwsiSVL8uUFuK8Wm7Dz7mYRu1x+ QhTkSKy2Tt1kmIxpB0td29UKwaPIGpFnLTLLpT/bfvWKWIUVDOMbjHAo3DM66Hlggxwt SCST2YGvrgi8e8z8uN5xArv/WM046alhW0Ji00oR2IYoNBY/eSzWkzKe47fGxlMQ7u4v 6rdpPbaSx6IkKbqof0EzmpNiIfpuTgP3R8m0PcEHbnpOTU4/HTUNWjH4LPneIFfEHoiT vCmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W/GynpDdAA5bQTljTnrGDVOXYq3QRG/0L9JFN57zUL8=; b=pctMcfgL4fN8bLYD+u9GkSSgDqm4OH/if60LSS4sVEOAElzz81TwylvBch144TaSWI nSss7T/zSl3w/LC9jq+QND3mcqOz2jS9+vAoQUqaQqiq7G/IQOcmrKBWODb/LsBCAHKx R6R13LzYq6zdmbrOyZ3agbjrKovSXf1Ts/Ep8zSGUfsp+HXPTRSpMpP/aZb4E9y+J3ns 8hJslVAJk+IG55U5oHw0wpCciWU1vRg3wt5ZAZFf+edfPyi+j7TJ1MgOykPJ6ZUM9jNY bpfzsbWsAG+u/eINi5VqLD334p55bj9HQRqsvfrqdnla3+hlmRQPBx9cDL7Tgn8uWDuz b8fg==
X-Gm-Message-State: AMke39nEN3eWuBNcDWpLnkeaxlOD+nwQDmaiSzjwBPV0lqctUNe0mDG5xz9c2zqonOER2S6Z9viJnk0p7sLgkus/
X-Received: by with SMTP id 65mr239628uas.155.1488515487100; Thu, 02 Mar 2017 20:31:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Mar 2017 20:31:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Lorenzo Colitti <>
Date: Fri, 3 Mar 2017 13:31:06 +0900
Message-ID: <>
Subject: Re: A proposal for draft-ietf-6man-rfc4291bis-07
To: Brian E Carpenter <>
Content-Type: multipart/alternative; boundary=001a11428a36da49c20549cc04ee
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: Fri, 03 Mar 2017 04:31:29 -0000

On Fri, Mar 3, 2017 at 10:29 AM, Brian E Carpenter <> wrote:

> > I think that RFC 4291 bis should not retain a constraint that has been
> applied so far, out of convenience, in the earliest stages of IPv6
> deployment.
> Agreed. And I think there are actually two things to say here:
> 3.1. Any IPv6-over-foo spec must specify a recommended IID length.
> 3.2. In the absence of such a spec, the recommended IID length is 64 bits.

I disagree that we should leave it up to IPv6-over-foo documents to specify
an IID length. If we wanted to make a statement along these lines, the
statement should be that the IID length is 64 bits unless otherwise
specified in an IPv6-over-foo document.

If were to end up making such a statement in this document, then this
document would need to formally update RFC 7934, some of whose conclusions
rest on the fact that IID lengths are currently required to be 64 bits
long, to say that IID lengths of 64 are RECOMMENDED for any network that
provides addresses to general-purpose hosts.

We would therefore have to say, in this document, that any IPv6-over-foo
document that specifies an IID shorter than 64 bits should either be
specifying a technology not used by general-purpose hosts, or should bear
the burden of explaining why the link layer it defines does not follow the
addressing best practices in RFC 7934.