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 09:55 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 8313D1296B4 for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 01:55:33 -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 A-Y1giCYrXpw for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 01:55:31 -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 8CEE01296A2 for <ipv6@ietf.org>; Wed, 22 Feb 2017 01:55:31 -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 v1M9tT2Q021249 for <ipv6@ietf.org>; Wed, 22 Feb 2017 10:55:29 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A3022204D77 for <ipv6@ietf.org>; Wed, 22 Feb 2017 10:55:29 +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 99EDE200CFB for <ipv6@ietf.org>; Wed, 22 Feb 2017 10:55:29 +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 v1M9tTPA014653 for <ipv6@ietf.org>; Wed, 22 Feb 2017 10:55:29 +0100
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: ipv6@ietf.org
References: <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>
Date: Wed, 22 Feb 2017 10:55:22 +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: <CAKD1Yr28iQHt0iuLvR3ndrT3Hfct=4k9dxjJeu3MAjDjOogEvA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/m43BLDYjwUNVgzJ9koSylL0P37M>
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: Wed, 22 Feb 2017 09:55:33 -0000


Le 22/02/2017 à 04:00, Lorenzo Colitti a écrit :
> On Wed, Feb 22, 2017 at 10:50 AM, Job Snijders <job@ntt.net
> <mailto:job@ntt.net>> wrote:
>
>     Those "thousands of interconnections" facilitate the communication
>     between millions of those hosts.
>
>
> 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.
>
>     Have you considered that not all interconnections are equal? The
>     type of interconnection I am mainly (but not exclusively) referring
>     to is the interconnection between Autonomous Systems to facilitate
>     the exchange of routing information using BGP-4. Autoconfiguration
>     plays no role here, everything is configured explicitly. I'd argue
>     that the use case is hardly comparable with a residential or mobile
>     connection.
>
>
> Those use cases are very well served by /127 for PNIs and /64s for
> Internet exchanges. What's left?
>
>     As pointed out in this thread, real networks use all kinds of prefix
>     lengths. Also, one doesn't renumber everything every time a new
>     document comes out - you stick to things that work for you.
>
>
> As discussed above, most links use /64.
>
>     Some vendors in this thread have admitted to strive to make things
>     work with any prefix length, why is there then still a discussion
>     that people must use /64 - when both vendors and users are not
>     always doing so, for good reasons?
>
>
> You're forgetting about host operating system developers and host users,

I think you talk about users of hosts like smartphones, situated at the
edge of the Internet, not in the core.

In straightforward IP addressing architectures ("hierarchical"), the
prefixes of routes towards the edges are naturally shorter than that 64:
e.g. prefix /60 for site, /63 for building, /64 for office desk.

In practice these hierarchical architectures are ideals hard to
implement. Because some hosts even in the core use SLAAC/Ethernet/64,
because edges expand, etc.

This makes that people need prefix lenghts of routes to lead to a
particular /64 carved out of some other prefix, instead of aggregating.
This leads to waste of publically routable space, or to the use of ULA
prefixes, or NAT66 prefixes, which have inconvenients too.

Alex

> both of which benefit substantially to having a subnet size that is
> always the same and never runs out of addresses.
>
>     I'm confident this discussion will eventually resolve itself and
>     conclude that /64 is not the only valid prefix length, rigid
>     positions rarely are attainable. Water can flow or it can crash.
>
>
> Even if you're right, the place to have that discussion is not on this
> document.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>