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

Mark Andrews <marka@isc.org> Wed, 22 February 2017 10:15 UTC

Return-Path: <marka@isc.org>
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 E062812968C for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 02:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 KirrLBWqbGwz for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 02:15:43 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404461294ED for <ipv6@ietf.org>; Wed, 22 Feb 2017 02:15:43 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id F345F24AE08; Wed, 22 Feb 2017 10:15:38 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E27FE160048; Wed, 22 Feb 2017 10:15:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C7F3916006A; Wed, 22 Feb 2017 10:15:37 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Dg1JiJxOvClX; Wed, 22 Feb 2017 10:15:37 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DE182160048; Wed, 22 Feb 2017 10:15:36 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C7BDC64529C3; Wed, 22 Feb 2017 21:15:32 +1100 (EST)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
From: Mark Andrews <marka@isc.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> <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
In-reply-to: Your message of "Wed, 22 Feb 2017 10:55:22 +0100." <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>
Date: Wed, 22 Feb 2017 21:15:32 +1100
Message-Id: <20170222101532.C7BDC64529C3@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EDdG-KvquIqvXC6VaC7toViwTzI>
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: Wed, 22 Feb 2017 10:15:45 -0000

In message <3af95cc0-d336-f0be-bd42-aeb2319452ad@gmail.com>;, Alexandre Petrescu writes:
> 
> 
> Le 22/02/2017 =E0 04:00, Lorenzo Colitti a =E9crit :
> > 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 a straight forward addressing architecture a site gets a /48 and 
sub entities request the numbers of /64's they need and it uses a
autoconfiguring routing protocol for routing traffic.   Homes and
most sites don't need heirachical routing.  65000 routing entries
should be able to be handled even by a $15 router.

> 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

Or you just requests the prefixed you need and use a routing protocol.

 
> > 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
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org