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

Lorenzo Colitti <lorenzo@google.com> Thu, 23 February 2017 05:58 UTC

Return-Path: <lorenzo@google.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 8D5501295CA for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 21:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 245Z6sIgpdhA for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 21:58:25 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 9C9F61295EA for <ipv6@ietf.org>; Wed, 22 Feb 2017 21:58:23 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id 40so15860914uau.2 for <ipv6@ietf.org>; Wed, 22 Feb 2017 21:58:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eU9cSmJt7o57lnu+mnWjOOh4HYbS/28iWPqaOimf9W8=; b=tQiy2MlWhFsrl8vonFFKbCdjDMfi2HBMRPqHuhcf2xAw+j0SY/SGOf2+KtOPuPKolX LHrdoE4LxP10EtlKewk7sYGbK54nRhD2KdqAlnTXA6MtloO4CYIqlnhcnlT9+UqErPya d7FSRP93VpH4D1pxR9HXUUkmI0xqjYg7GXIL1ci/Ler0LEHJzfu4Up6lKLPANFxBEsZs Csj5MwX4Ym1vRx4DOt/wv+vtta+e9wt+qtnDzSv83nC1v27TOsOuG29NRWLzG73y1dhz gXCTmR+9ZqdcseAvi3L90qA5zWRvrgqBW5v+wV1/fCfAPigwPwYh9u68lzUGfk3VBf38 yx+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eU9cSmJt7o57lnu+mnWjOOh4HYbS/28iWPqaOimf9W8=; b=eh/8QHPWEH85Y/rdvoBy0CZX+p66ErdVtdJQuFrFD6i5VMvLVWgbr8Ennn+bkw4J8I 5vgX4rvQy1u7NH1IhMPy3g3+gt+p5PuOS1EHJUcq5eWLLpWDhPB7aCShe/8QBAZjKrRf e0ZLTn1x4u4aJH2U+VAKYtUjV6vYZI/578tK9nHtajbVoPoLKvRgOXZ7N0znZsbLWOxO euz6CK8l16+7cy+Oz6AX5dU6nE9SmXZyWYlOfpAJ06F4DKnMQnqy2ayQMTCIJf67WAbJ TYeqOVrVCYWLnUnprydd7UPF05JSQZTGtmcsv5lHlGYlsRL1HT6YyZUQJ6uRR/AJFCX6 tv8w==
X-Gm-Message-State: AMke39k4vGR7hMYt7fPWqiMnM9X72bgXvgiqFnrPX44kUrsAn16D58Z+arRSnhNbKx7De0Dl3yB4nW26cY0u4dHq
X-Received: by 10.176.8.4 with SMTP id a4mr2247018uaf.171.1487829502501; Wed, 22 Feb 2017 21:58:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.171.2 with HTTP; Wed, 22 Feb 2017 21:58:01 -0800 (PST)
In-Reply-To: <0f3db3bd87eb4a9ba51360d9b73751e3@XCH15-06-11.nw.nos.boeing.com>
References: <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> <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> <0f3db3bd87eb4a9ba51360d9b73751e3@XCH15-06-11.nw.nos.boeing.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 23 Feb 2017 14:58:01 +0900
Message-ID: <CAKD1Yr2o3eyuhvij4=KjsVMTor=oh5N8AWfjOCJ_jh6nSA0=Gg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Content-Type: multipart/alternative; boundary=f403045ee778fbfa8f05492c4cbd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hQPed_YIpcrMfJiBT0KNh-5_3HA>
Cc: "draft-ietf-6man-rfc4291bis@ietf.org" <draft-ietf-6man-rfc4291bis@ietf.org>, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, "6man-chairs@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: Thu, 23 Feb 2017 05:58:25 -0000

On Thu, Feb 23, 2017 at 1:39 PM, Manfredi, Albert E <
albert.e.manfredi@boeing.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. Currently that code is correct on all unicast
> > space. If you change RFC 4291, won't that code be incorrect?
>
> This shows precisely why it is urgent to update RFC 4291, to correct that
> notion of a fixed IID, before it's too late to set things straight again.
>

Ok, so you're suggesting that we drop the attempt to reclassify RFC 4291,
and instead write a new document to update it? That's a possible course of
action. It would only result in your desired outcome if there was rough
consensus to change the boundary, but as I said before, I'm not going to
oppose that course of action.


>    IPv6 unicast addresses are aggregatable with prefixes of arbitrary
>
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
>    Routing.
>
> Important point. Arbitrary length. That does not mean 64 bits.
>

Nobody is disagreeing with that text. Please refer to the earlier
clarifications in this thread and the discussion in 6man that pointed out
that *routing* based on prefix lengths != 64 is independent from *interface
IDs* being required to be 64 bits long or not.