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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 28 February 2017 12:04 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 85D11129536 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 04:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gC6U6SwT2915 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 04:04:19 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81D712943A for <ipv6@ietf.org>; Tue, 28 Feb 2017 04:04:18 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1SC4Gjc015043; Tue, 28 Feb 2017 13:04:16 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36644208B49; Tue, 28 Feb 2017 13:04:16 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 269E1208AD3; Tue, 28 Feb 2017 13:04:16 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1SC4FNB018397; Tue, 28 Feb 2017 13:04:15 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Mark Smith <markzzzsmith@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> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com>
Date: Tue, 28 Feb 2017 13:04:02 +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: <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4ISQKaKdtdztpx9z5yWljiyjcfk>
Cc: 6man WG <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: Tue, 28 Feb 2017 12:04:21 -0000


Le 28/02/2017 à 08:41, Mark Smith a écrit :
>
>
> On 27 Feb. 2017 21:23, "Alexandre Petrescu"
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
>
>
>
> 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.
>
>
>
> Just to be clear, consensus doesn't mean unanimous.

YEs, unanimity is at best suspicious.

> https://tools.ietf.org/html/rfc7282

Huming is an innovative way of voting compared to other voting systems.
  It's practiced in v6ops some times, maybe less in 6man.  What do you 
think?

> 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?
>
>
> Answered in RFC4291.

Well, at the risk disturbing the common wisdom, look foolish with
isolated opinion - I think an evolution is needed.

The very sense of Interface Identifier may have evolved.  The virtual
interfaces are common now, IPv6 people talk "Host ID" routinely, the
48bit MAC addresses are less and less expected unique,  EUI-64 is no
longer considered elsewhere, EUI-128 is about to appear, we need app
IDs, Virtual Machine IDs and car IDs.

The dimension of the IID may have been overly specified.

Commonly one sees something like 3 to 5 IPv6 addresses on a
single-interface (more than 2 addresses, but nowhere near 2^64).  So an
IID of 3 to 4 bits is sufficient.

Commonly one sees subnets with 2 interfaces on them (cellular ptp), WiFi
subnets or office subnets with a thousand interfaces on them (nowhere
near 2^64).  So a Host ID or an Interface ID of length 10 is sufficient.

So is this Interface ID still well-dimensioned?  Wasnt 64 too hungry?
Isnt this 64 eating out too much in the plen?

Finally, there is no advice of what bits to put between fe80:: and a
64bit the Interface ID - zeros or ones?  linux says it's a fe80::/64 and
IIRC BSD says it's a fe80::/10.  The routing entries based on that can
make for interop problems.

None of these were so obvious when the 64bit Interface ID invention came
about, I think.

Alex

> 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
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
>
>