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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 27 February 2017 10:23 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC28129D15 for <ipv6@ietfa.amsl.com>; Mon, 27 Feb 2017 02:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3-eiPOomtCg for <ipv6@ietfa.amsl.com>; Mon, 27 Feb 2017 02:23:00 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6AE129D06 for <ipv6@ietf.org>; Mon, 27 Feb 2017 02:22:59 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1RAMv7A009857; Mon, 27 Feb 2017 11:22:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 76E1420801C; Mon, 27 Feb 2017 11:22:57 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6974B208018; Mon, 27 Feb 2017 11:22:57 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1RAMvYi008331; Mon, 27 Feb 2017 11:22:57 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAN-Dau0s04c=RV0Y8AGaxBPFui41TWPTB+5o0K2Lj-iah0An1w@mail.gmail.com> <CAL9jLaYirty22iGiEjEaYq3_KA1FZhxBTOBWuFOXQ9C-WPd5xQ@mail.gmail.com> <CAN-Dau0n6oFm538XdJOcuO1yg92BCDD3mBu5YfBVm_+g-gtcKA@mail.gmail.com> <CAL9jLaYO=uYgVfSZ0SoSe0SujJ1xgwEKE8WLzo_keJHywgXTtg@mail.gmail.com> <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <de4988be-6031-08d9-84ce-21c3fa4f9bc9@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com>
Date: Mon, 27 Feb 2017 11:22:44 +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: <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0UzAR51GFd1d6hcxp3EEFUL8iLk>
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2017 10:23:01 -0000


Le 26/02/2017 à 20:24, Brian E Carpenter a écrit :
> Aelexandre, On 27/02/2017 07:55, Alexandre Petrescu wrote: ...
>>>> 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.
>
> You didn't pay attention to my phrase "portable interoperable host
> software".
>
> I carry my laptop and my Android phone around quite a lot. I want
> them to just work when they find themselves on a new IPv6 network.
> Given that we never put in place dynamic parameterisation of the
> 802.1/802.11 IID length, that's only possible because the various
> software writers involved over the years all implemented /64. End of
> message.

I see.

We want the laptop and android to continue work that way - it is good.
But could they just rely on RFC2464?  Isn't the IPv6 Addressing
Architecture too high a promotion for just that case?

IMHO maybe we are trying to improve an earlier 4291 paragraph whose
initial intention may have been good, but is not consensual.  That par
is "All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field".

There are additional messages that circulated in private, and that have
not been posted publicly, about the validity of an "Interface ID"
altogether.  What's the meaning of an Interface Identifier when one can
have same IID on different interfaces?

Or is the laptop/android use-case actually needing a "Host
Identifier" (not an IID)?

Has the option of removing this 4291 paragraph altogether been
considered (instead of improving it)?

Alex

>
> Brian
>