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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 22 February 2017 15:17 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9C129970 for <ietf@ietfa.amsl.com>; Wed, 22 Feb 2017 07:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.333
X-Spam-Level:
X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 U_3HWRCpX9g6 for <ietf@ietfa.amsl.com>; Wed, 22 Feb 2017 07:17:10 -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 C73831299F3 for <ietf@ietf.org>; Wed, 22 Feb 2017 07:17:09 -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 v1MFH7qF026229 for <ietf@ietf.org>; Wed, 22 Feb 2017 16:17:07 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E90BA206F4A for <ietf@ietf.org>; Wed, 22 Feb 2017 16:17:07 +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 DFEBF2033B5 for <ietf@ietf.org>; Wed, 22 Feb 2017 16:17:07 +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 v1MFH7c0032080 for <ietf@ietf.org>; Wed, 22 Feb 2017 16:17:07 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ietf@ietf.org
References: <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <75196cfa-5476-0c7b-7612-ea2e446fc6f1@gmail.com> <B4A4FFFD-A90D-4C26-BDBD-75555840CA22@employees.org> <m2wpcqeuot.wl-randy@psg.com> <44F7BEDA-CF11-4E1E-BA6F-88794DEC1AF7@employees.org> <20170221001940.GB84656@Vurt.local> <068ce975-8b1e-a7c5-abba-2bfc1d904d70@gmail.com> <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> <CAL9jLaY-7JqeNqotWsrQZ6JqNJ9NdzQT8Jt7Pd_YZwCpNgk6VQ@mail.gmail.com> <CAKD1Yr2yjH9SGtBv2pJPEtceBWo=4+vobAV1o1JBjVpcNLXmcA@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <bd63b751-6243-d5b6-93b0-afbed70a3ecd@gmail.com>
Date: Wed, 22 Feb 2017 16:17:00 +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: <CAKD1Yr2yjH9SGtBv2pJPEtceBWo=4+vobAV1o1JBjVpcNLXmcA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zDS_Di_tZ6v6yhUS09Li979jFRU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2017 15:17:12 -0000

Le 22/02/2017 à 15:17, Lorenzo Colitti a écrit :
[...]
> A fixed prefix length is also very beneficial because it allows hosts
> to extend the network indefinitely at layer 2 without giving up the
> benefits provided by autoconfiguration and end to end connectivity.

I would agree bridging can extend to some extent.  But not indefinitely.

I would argue routing extends beyond what bridging can extend.

> It means that ill-informed or ill-intentioned network administrators
>  cannot use addressing to constrain apps in a way that leads to
> suboptimal user experience.

Maybe well-intentioned admins consider DHCP too, because it does not
have that /64 limit.

I have seen DHCPv6 running fast on smartphones on cellular links.

> That sort of thing obviously does not happen in the 2914 or 15169
> backbone. It does happen in lots of other places.

2914, 15169?

Alex

>
> On Wed, Feb 22, 2017 at 1:44 PM, Christopher Morrow
> <christopher.morrow@gmail.com <mailto:christopher.morrow@gmail.com>>
>  wrote:
>
>
>
> On Tue, Feb 21, 2017 at 10:51 PM, Lorenzo Colitti <lorenzo@google.com
> <mailto:lorenzo@google.com>> wrote:
>
> On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow
> <christopher.morrow@gmail.com <mailto:christopher.morrow@gmail.com>>
>  wrote:
>
> But the configuration cost and management overhead is not
> proportional to the hosts that are served by those interconnections,
>  it is proportional to the number of interconnections. A 10x100G
> peering interconnection that serves X million hosts is one interface
>  that has to be managed.
>
>
> isn't the dicsussion here really: "If you want to use /64 go ahead,
> if you want to use /121 go for it, if you want to use SLAAC you'll
> get a /64 and like it"
>
>
> Not sure. I for one wouldn't agree with that position, because I
> don't see that /121 has enough advantages over /127 and /64 - and few
> enough downsides for general-purpose hosts - to make it a good idea
> in general.
>
>
> I don't think /121 is anymore special than /127... or /64. My point
> was we don't care what prefix people use, generally, that there are
> cases where a /64 is required and that's fine, there are cases where
> /64 isn't and people can do what they want there.  It's simple enough
> to do SLAAC/64 on lans and other places.
>
> Requiring /64 or /127 and nothing else means when you do have to do a
> /120 or something else you MAY end up fighting vendor problems
> because they made assumptions about: "only ever 64 or 127".
>
>