Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Alexandre Petrescu <> Sun, 26 February 2017 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82FDD127076 for <>; Sun, 26 Feb 2017 10:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.826
X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.972] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IgXjmFf7OtJv for <>; Sun, 26 Feb 2017 10:55:18 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 28E88120725 for <>; Sun, 26 Feb 2017 10:55:17 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1QItFSb015650; Sun, 26 Feb 2017 19:55:15 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 59951208094; Sun, 26 Feb 2017 19:55:15 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 4BE38201B82; Sun, 26 Feb 2017 19:55:15 +0100 (CET)
Received: from [] ([]) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1QItEXb000694; Sun, 26 Feb 2017 19:55:15 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Brian E Carpenter <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Sun, 26 Feb 2017 19:55:01 +0100
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Sun, 26 Feb 2017 18:55:19 -0000

Le 25/02/2017 à 20:15, Brian E Carpenter a écrit :
> On 25/02/2017 23:02, Alexandre Petrescu wrote: ...
>> I would agree if I read "/64 was RECOMMENDED in the past".
> That would be a lie, since until now it was 'required' in the text.

I would then agree if I read "/64 was required in the past".

>> I would not agree if I read "/64 is NOT RECOMMENDED".
> But nobody is suggesting that (in RFC 2119 it is equal to SHOULD
> NOT).

A few people said that they are afraid that if we say "/64 is NOT
RECOMMENDED" then the cellular operator will only assign one /128 to one
User Terminal.

In a sense I agree with that worry.  Although that would require
operators to use DHCPv6 to assign addresses, and that is rarely the case.

But that worry should be expressed differently.

That worry should be expressed such that it requires operators to assign
a /63, or a /62, or a /61 to User Terminal.

Assigning one /64 to User Terminal is equivalent to assigning one /128
to User Terminal.  So that does not address the worry of being assigned
only one address.

The theory of 2^64 addresses being available in a /64 prefix is broken
compared to the reality of SLAAC-on-Ethernet-on-ptp-links.  This should
be explained to both operators and end users.

>> I would not agree if I read "/64 is RECOMMENDED".
> There I think you are wrong.

I think I am wrong depending on what tense we use: is it about the
future or about the past?

When we say "is RECOMMENDED" and it becomes an RFC then that will
effectively be recommended during the next 10 years or so, until next
RFC update.  I fully disagree with this plan.  It will comfort the
cellular operators to continue assigning a single /64 to one User Terminal.

> It is the value that today allows portable interoperable host
> software (on IEEE 802.1 or 802.11 media)

(for 802.1 and 802.11 media - there is much I can say here - basically
IPv6 stacks interface to EthernertII headers, no 802.1 nor 802.11, but
that's another matter; wireshark and RFC2464 show that).

I would like to add that, in addition to the Ethernet I suppose you want
to talk about by saying 802.1 and 802.11, the 64 limit is so only if
SLAAC is there too.

If one uses only Ethernet (no SLAAC) then the 64 is not set in stone.

If one uses only SLAAC (no Ethernet) then the 64 is not set in stone.

If one uses SLAAC-on-Ethernet then 64 is set in stone, and only then.

 From this, to make a general IPv6 Architecture Architecture that says
that 64 is RECOMMENDED default there is a long way.

> so it is, in fact, the only plausible default that we can suggest.
> 'Recommended' leaves plenty of space that 'required' does not.

To me RECOMMENDED and REQUIRED - capitalized or otherwise - both sound
too strong compared to simple ability to leave with 64.

If there was a word that said "CAN LIVE with 64" then I would agree with it.

But why should we suggest a plen there in the first place?

Is it because we want to be compatible to existing implementations?  If
yes then we can say that "in the past the /64 was required", and be
silent about the future.  We can also say that some existing
implementations break other standards when they want to be compatible
with a _supposed_ 64 requirement (as we both discovered with this netsh

Is it because we are afraid of cellular operator assigning only one
address?  If yes know that assigning one /64 is no different than
assigning a /128 as long as SLAAC-on-Ethernet is used on ptp links.

We can also describe what breaks on some implementations which:
(1) route a /120 to a subnet where a /64 is used
(2) locally self-configure /64 prefixes when nobody asks to


> Brian