Re: Updated IID length text

Brian E Carpenter <> Fri, 20 January 2017 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B8CD1294F8 for <>; Fri, 20 Jan 2017 14:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NCa1jsK4Agd8 for <>; Fri, 20 Jan 2017 14:40:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A4A71294F6 for <>; Fri, 20 Jan 2017 14:40:05 -0800 (PST)
Received: by with SMTP id 204so26918921pge.0 for <>; Fri, 20 Jan 2017 14:40:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hKQFDUdoiDCLJKD0NiW4oYoXl/Wo6xd/MuQyMqHbyG0=; b=SJMMOBOeTqmcbNSl/k9oFg+IJv/ZdgbvTFDTYdyC99TuZDMJ1/cSLy2bT6roXvSTQJ 5g8wxvE+kI1qGisa8igOPy/zkjcFEEh1sqDVCa3+1IUXm/MCf6h8JHUkhxtHa4KwkX1j VdjqK4fQ8a6UHnJs6c6eaV0Rluq3PtQKJjbxCAf271bHDjCkJbmCGsqURU1dBH1h7jcG 7oHiL/UAIa5UV1V2EZy83E2VfQq58sZz0EuwNBdefaibBvfi4LM+fh45+QAjULhNbE8e 3WKunXyubzb5Y6+TlWif0c8fAWG7Gy8hSAYRUFtPF1hk0fbqi0gjiArPWi322drj1rBp DXvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=hKQFDUdoiDCLJKD0NiW4oYoXl/Wo6xd/MuQyMqHbyG0=; b=Doxbz9Wh2/rlEAHPRLpmNjVQ6PYgOB8plqalNtHSy1/FJE4MSkj4DNnvifl9J1WBV5 gMnP+MU7IbvhtNT6s3wAP+PeSsQ3qtoEWDnKpxA14eFBDq3wFbbv8g0EgA1aZl8+8bWW fWuXVCUBofAGbHaL0Ge/gKOolQEgKL9ouFzKo2QMAkWwx7rp7H84phcClY7iH/Egeqet iSqVgEQ+9dHZi3Wf+bLiPS+Ch3sKRmdxc1CX7jzAgy5NY3vwbK/Ik/LXMeg7kZBoyjoi IBPFoNdHJz9tHbcVuVQYHSHPtabQvDiDbMUvJeXB743A3d7SW4MGayRiCDNnt+BUCUid udBQ==
X-Gm-Message-State: AIkVDXLwwOOPR79N1HBpzp1pi3KQfvYFiDnAtEuPm51hCUpnSznstotVh86BpBX0GhqVZA==
X-Received: by with SMTP id m5mr19495322pgk.94.1484952004600; Fri, 20 Jan 2017 14:40:04 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id a8sm19215364pfa.19.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jan 2017 14:40:03 -0800 (PST)
Subject: Re: Updated IID length text
References: <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Sat, 21 Jan 2017 11:40:11 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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, 20 Jan 2017 22:40:06 -0000

On 20/01/2017 23:29, wrote:
> Brian,
>>>> By changing "For all unicast addresses" to "all currently allocated unicast
>>>> addresses",
>>>> Are you proposing to reverse the decision that was made back when RFC3513
>>>> updated RFC2373?
>>>> Change log:
>>>> -  Revised sections 2.4 and 2.5.6
>>>> to simplify and clarify how
>>>>      different address types  are identified.  This was done to insure
>>>>      that implementations do not build in any knowledge about global
>>>>      unicast format prefixes.  Changes include:
>>>>         o  Removed Format Prefix (FP) terminology
>>>>         o  Revised list of address types to only include exceptions to
>>>>            global unicast and a singe entry that identifies everything
>>>>            else as Global Unicast.
>>> Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes."
>>> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years.
>> Indeed. I've taken out the explicit text that people objected to, but if another /3
>> is released to IANA and the RIRs, don't we want to keep our options open?
> This isn't the right place to change the consensus that has held since 3513.

I agree with that, and it isn't my intention.

> Making this change would require a much deeper analysis of why the reasons outlined above don't apply anymore.
> You are essentially proposing to redefine the meaning of "Global Unicast".

Well, I don't agree. I was just trying to confirm that the current rule applies
to the whole of 2000::/3, without closing off future options.

Actually it might have been better if this magic number had been left out
of the addressing architecture and included in the SLAAC specification, but
it's years too late to change that.

> And please note that 4291 already has provisions for this:
> Section 2.4:
>    Future specifications may redefine one or more sub-ranges of the
>    Global Unicast space for other purposes, but unless and until that
>    happens, implementations must treat all addresses that do not start
>    with any of the above-listed prefixes as Global Unicast addresses.

Right. So 4000::1234 is clearly a unicast address, but if not used for
SLAAC, it doesn't need a defined IID length. That's where we have muddled
things a bit between the addressing architecture and the SLAAC spec.