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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 25 February 2017 10:02 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 D24E5129CB2 for <ipv6@ietfa.amsl.com>; Sat, 25 Feb 2017 02:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.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, SPF_SOFTFAIL=0.665] autolearn=no 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 RqOhe3iv9RSI for <ipv6@ietfa.amsl.com>; Sat, 25 Feb 2017 02:02:58 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A39F129CB1 for <ipv6@ietf.org>; Sat, 25 Feb 2017 02:02:58 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v1PA2uU5003541; Sat, 25 Feb 2017 11:02:56 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15110205515; Sat, 25 Feb 2017 11:02:56 +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 0C896200DB8; Sat, 25 Feb 2017 11:02:56 +0100 (CET)
Received: from [132.166.84.73] ([132.166.84.73]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1PA2ths006050; Sat, 25 Feb 2017 11:02:55 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: 神明達哉 <jinmei@wide.ad.jp>
References: <20170221001940.GB84656@Vurt.local> <20170221101339.GC84656@Vurt.local> <CAKD1Yr33oQb=gMGaEM++hLgmMtxMdihiDrUihEsjs63vy8qRbA@mail.gmail.com> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <CAKD1Yr3K+SJb_4ksZ96yNypVKJE-fXopuVaXNhhKp1gkh1=QEg@mail.gmail.com> <20170222144147.GC89584@hanna.meerval.net> <7960ff2d-359f-429c-6e82-ef592f90bf53@gmail.com> <CAKD1Yr1W+AVt4Dixo9epB5VazxBsVMD+mrshwaE=n7SuX6eGDw@mail.gmail.com> <5ce34926-6bde-6410-9b1e-3f61e48e9a1d@gmail.com> <CAKD1Yr1yRTUPVTTicaTkA8fAFxHiHxdLG8ZzEHjCUDDzKg5zJg@mail.gmail.com> <CAJE_bqe=4KruMwWOnSF7RO7TOQTdx48cG_4uSPkGptkG7R4ckw@mail.gmail.com> <b1c3d744-a281-559c-3933-2ab9d2d65225@gmail.com> <CAJE_bqfSn2+1NB9v9J5oiefUbLowgOAxV426mGQZPeChKDX8zw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <9c8715b0-02e1-837e-23ff-3599b5ce446c@gmail.com>
Date: Sat, 25 Feb 2017 11:02:45 +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: <CAJE_bqfSn2+1NB9v9J5oiefUbLowgOAxV426mGQZPeChKDX8zw@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/6y3zZtKxTq7tXcHL_8WyZO054gg>
Cc: IPv6 IPv6 List <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: Sat, 25 Feb 2017 10:03:03 -0000


Le 24/02/2017 à 20:40, 神明達哉 a écrit :
> At Fri, 24 Feb 2017 15:44:55 +0100, Alexandre Petrescu
> <alexandre.petrescu@gmail.com> wrote:
>
>>>> Help he understand, then. There is widely-deployed code that
>>>> assumes that the interface ID is 64 and does not work on
>>>> anything other than 64 bit prefix lengths.
>>>
>>> Out of curiosity: which code is it, and exactly what does its
>>> assumption mean?  Does it mean, for example, it allows manual
>>> configuration of an address but requires its IID length be 64
>>> bits?
>>
>> For example - is it normal that when manually adding an address to
>> an interface w/o specifying the plen, a /64 'connected' route pops
>> there? Why 64?  I dont mind the route, but I mind the 64.
>
> I wouldn't interpret this example as such an implementation "does not
> work on anything other than 64 bit prefix lengths" in this context,
> since "64" is just the default of the implementation and can be
> "operationally" changed.  But in any case, I don't know if this
> something what Lorenzo meant.

I dont know what Lorenzo meant more precisely - and I would like to know
too.

Because I have a set of specific questions to Host programmers about how
64 is - or is not - a barrier in making e.g. a smartwatch talk to the
Internet through a smartphone.  Or how a set of in-car computers (map
database, vision camera, etc.) can be remotely updated through an
on-board LTE module.

Alex

>
> -- JINMEI, Tatuya
>