Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

神明達哉 <> Thu, 23 February 2017 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABCBA126D73; Thu, 23 Feb 2017 10:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, 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 CaDwxmRQnc3y; Thu, 23 Feb 2017 10:45:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FE951296EE; Thu, 23 Feb 2017 10:45:46 -0800 (PST)
Received: by with SMTP id x35so36075705qtc.2; Thu, 23 Feb 2017 10:45:46 -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=3TYZnVcPA64GExTopjankG0v6it3fbIT/QFNXhRuTMo=; b=BrllluSQMXHjiuSa2rronoq63YfhiefjK2c6WjaRtuj47YbuxAVw3EYTHUC4m/o1GK oMqL/ieWudZSs9iq0+BVXoPOEuAKd3w3htXOdDcykhRS2BKCqL7NX2g0uxDxcRmKVyJ0 0glJgE78aDDfn/Mn73oWLS9mo11mLLABG3vPwXI0juYQk+U8UYKdoPL5pBC2GqCZ6h9M lQk+iQH4FXrgLyKxIPLq87invj4kxNL6UbAX4idNQgyW07ijGfaDKd8k4JR4PcTsXKBE +tR2KTKxyPEL4IF4S9zgxLTJXfAifhWztIDznw8HqIz5IVl8dD3H0BkPcpJbAJ7dVzLk 1UJg==
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=3TYZnVcPA64GExTopjankG0v6it3fbIT/QFNXhRuTMo=; b=eBm3O5xA65dsIPIqr3g5lJQKMP56OhkoJ2iiIeEv5ygd0/F5MxeoBptoTCKhl74yxC BxTKmaQ0koSD9hMQXZ4nmDtgk604oMDhWL78bXz2pYEs/GSQHdMYxtUZsP81RiFG4xm5 t0q09rmLfGUw1ejApx4vS3sKdv7UWnr7/FV5J8ejlWzeWMePK5sKd6p72tn182sAgFFm vrTuePK0UEh71bQso+Jt/JIB3PR8cqw3mhzmhGK1wnQfVXcx78TV8F6sSdNBEHX4ShJ3 Z52LxuBn1TfwdekT1G7V1LaVOAsOvHCRNiRaig4vvZoL87Rheg3+W/hqE0Awcue8GBRn xu4Q==
X-Gm-Message-State: AMke39kbbYTZHeA6JxUSFKP4M5YYRaTp/DQKYoaVr1drdIO56MRD5GwbU+FzCER8VPVhZ2WE64g49+cdrUg5lQ==
X-Received: by with SMTP id q45mr2493297qtb.220.1487875545323; Thu, 23 Feb 2017 10:45:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 23 Feb 2017 10:45:44 -0800 (PST)
In-Reply-To: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Thu, 23 Feb 2017 10:45:44 -0800
X-Google-Sender-Auth: _Ec79NoZrxS4TrgNfa7LrHAaV1c
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:,, 6man WG <>, IETF-Discussion Discussion <>
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: Thu, 23 Feb 2017 18:45:48 -0000

At Thu, 23 Feb 2017 13:16:46 +0900,
Lorenzo Colitti <> wrote:

> Help he understand, then. There is widely-deployed code that assumes that
> the interface ID is 64 and does not work on anything other than 64 bit
> prefix lengths.

Out of curiosity: which code is it, and exactly what does its
assumption mean?  Does it mean, for example, it allows manual
configuration of an address but requires its IID length be 64 bits?
(If it means something like this, I'd also wonder how its "IID"
matters in the first place - does that implementation use the lower 64
bits for some specific purpose?)

I thought general-purpose OSes are actually quite flexible about the
length of "IIDs" (in many cases it's actually derived from the length
of on-link prefix corresponding to the address).  I know BSD variants
are intentionally flexible on this.  I also know at least some (if not
all) kernel versions of Linux are flexible.

The only example of "widely-deployed code" with such an assumption
that I know of is ISC DHCPv6 client (though I'm not sure if its latest
version still has that assumption) as described in Section 4.4 of
RFC7421.  But I guess you're referring to something else.

If you can be more specific it might help provide some clarity for the
discussion, although I'm not so optimistic that it will automagically
resolve the conflicting views we are seeing.

JINMEI, Tatuya