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

Brian E Carpenter <> Tue, 21 February 2017 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF3BD12954F; Mon, 20 Feb 2017 17:11:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 DP1Unlfudhz7; Mon, 20 Feb 2017 17:11:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C18E6129530; Mon, 20 Feb 2017 17:11:16 -0800 (PST)
Received: by with SMTP id s67so4654887pgb.1; Mon, 20 Feb 2017 17:11:16 -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=jQRy8RdhaONXJngEmPdJTNYmkMUKFg4dVeJu/IC2s9s=; b=gD4UAYG7uvw0SGfGoM6BwqdcIpXtd0CHINBauk25DwGRnpXOa/KNOAyvrYKcSlkBUk Kf2XoL9qc0NG0AUW0tgCCaVj3mttZj0PekjEuoCVD6KaZKcwQHT03uD42BV9OXz/1wnq 9cr1VBMK7wTwSLZyeHSfHVa4T8VyrbJoRECCTLJCxV1kzzdWa+gzK7gyljrIPAjhLqFE N3Or6UjPMROOLKQjlexCxp7894xNuOyd1YA3WpJWPhL+eTW9sOBZvZnjo0VM7X8tfa1V GBPj+PmgAAPEAwG5tLhfT/zYt+bmeXeyE/H9DInxdhf7IAdTWWikhzTf0K0C5R8TjnPO H7RA==
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=jQRy8RdhaONXJngEmPdJTNYmkMUKFg4dVeJu/IC2s9s=; b=JjB7A/UdN9uEhKQBB3NnQ7/Tsn7B/ARfgpABiofmJ5ZKS7H3A6m/tl4JXutnuPxK2s kOLsNjhh0ocZ8xAmA3XOfRHQF5tRVMmNUs+V0WNcKVF1MbkwtxGs1d4M+JFGE6rh4pH9 xHwT64uQJogElZnVwlbWW/CJzjM6pDH10z6/AArS/dRjYOr9b9lyNfWFrxpYceNHxHKv 2atwGMy6L/EszeFr9ZsGNUd8xU+J5GIuWln3YLNRmSoZXfjYob3VP+UCXYsJD3gyomE5 XiHBcWkBG1QTKrqflezgYeym+UA/bsKXdPdN7FUKSyxvMtSm1BtM4i05K1M2BpRHdFLL Nf2g==
X-Gm-Message-State: AMke39ldPgh2+RRYQFlI0QrOi090svL8ccY+lBVOcEPd7pVFK6qEhkuSyuDsajEPeNkNhQ==
X-Received: by with SMTP id q4mr26886432plb.35.1487639476378; Mon, 20 Feb 2017 17:11:16 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 202sm4619456pfa.6.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 17:11:15 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Job Snijders <>,
References: <> <> <> <> <> <> <> <> <> <> <20170221001940.GB84656@Vurt.local>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 21 Feb 2017 14:11:15 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170221001940.GB84656@Vurt.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Tue, 21 Feb 2017 01:11:18 -0000

Hi Job,

On 21/02/2017 13:19, Job Snijders wrote:
> On Thu, Feb 16, 2017 at 09:40:01AM +0100, wrote:
>> There are many reasons for the 64 bit boundary.
>> - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
> Irrelevant.

Not really. They are both running code. You may not want them in
*your* network but that isn't the point. Some people want them.

And there is a lot of other running code too, not just SLAAC which is
mandatory to implement in every IPv6 host. So this actually trumps all
the other arguments: it's 64 bits because it's 64 bits.

> Also, I think we here touching upon the very heart of the issue: some
> would like to force every link on this planet to have a routable /64
> (for perhaps ideological reasons),

No. For running code and interoperability reasons. We could have settled
on 48 bits, but we didn't. But, because of interoperability, we had to
pick something.

> and some don't (for perhaps
> operational reasons).

In practice, there isn't much choice except for point to point links.
All the same, we definitely needed RFC7608 (=BCP198).
> I'm from the school of thought where unenforceable rules have no place
> in society. There already is precedent to abandon a classful addressing
> paradigm in favor of classless inter-domain routing. This implies that a
> the fixed 64 bit boundary is unattainable, as such, getting classless
> IPv6 is merely a matter of expending sufficient energy.

No. IPv6 routing is classless and always has been. RFC7608 simply re-states
it. But automatic address assignment, which is an equally important property
of IPv6, needs a default setting for portable code, and it is /64. That isn't
a matter of opinion. It's a (possibly inconvenient) truth.

> If this is the case, why proceed 4291bis while its content is contested?

What we're discussing is the exact text to describe the inconvenient
truth. I'm not aware of any generally available running code that will
be changed in even one instruction by the final text - that is indeed
a requirement for advancement to Internet Standard.