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

Job Snijders <job@ntt.net> Wed, 22 February 2017 10:47 UTC

Return-Path: <job@ntt.net>
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 A647A1296D0; Wed, 22 Feb 2017 02:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 fAGdXK4ElrHK; Wed, 22 Feb 2017 02:47:03 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 869401296BD; Wed, 22 Feb 2017 02:47:03 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cgURm-0007nn-53 (job@us.ntt.net); Wed, 22 Feb 2017 10:46:59 +0000
Date: Wed, 22 Feb 2017 11:46:25 +0100
From: Job Snijders <job@ntt.net>
To: Christopher Morrow <christopher.morrow@gmail.com>, Lorenzo Colitti <lorenzo@google.com>
Message-ID: <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark>
In-Reply-To: <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com>
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> <CAL9jLaZgTp++PJ9KGHEWuPoVm6t3b8QfVDCEhz5h4fv-0fuUAA@mail.gmail.com> <CAKD1Yr3SbR=xt3RPu7+q1o14wKuUuwUc6oG+BgZtEK1O+m5sWw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
X-Readdle-Message-ID: 4936e96b-fc82-4de0-9188-ced9547deb2f@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58ad6c08_2ae8944a_d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/r0iH_RkaBK-kJ8GAQD-hQm4qndU>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@ietf.org, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@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:47:05 -0000

One of the immediate benefits of using a /126, is that it's not a /64! Also, a /126 is the smallest non-64 size with the highest likeliness to get the job done from an interoperability perspective (not the /127). Another example: when you use a /120, the advantage again is that it is not a /64, and you can make a bunch of routers talk BGP with each other on a layer-2 segment. This is why /126, /125, /124 etc end up being used.

An Addressing Architecture that does not admit this has been common practice for 15+ years, is disassociated from reality and thus inconsequential and no good. It does not follow that because you don't see enough advantages, the idea and practice are bad.

Kind regards,

Job

On 22 Feb 2017, 04:52 +0100, Lorenzo Colitti <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.