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

Erik Kline <ek@google.com> Thu, 23 February 2017 06:59 UTC

Return-Path: <ek@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 73984129636 for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 22:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 w55ePGCquEDs for <ipv6@ietfa.amsl.com>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 9C467129631 for <ipv6@ietf.org>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id p77so12682813ywg.1 for <ipv6@ietf.org>; Wed, 22 Feb 2017 22:59:02 -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=/AE5eJIL4N9oXnzYxwbpIM5ZuSdlY5gnfYBwLewrHwY=; b=HnlvIZqvLOXrZK5WlPFxbCCkrG07+DKV5yas7dpul82biFP/SgT7o4ixSGP1jBWClh zeSMjMJUxAeiFC9iagc8WJtSHGnq5zhyFBnNqA69c84Nqs3CMbBYLzZiqpqukdWm0Enc do/P/K8A95t/hoCLHzchhR+bTEv9xm1TUTFEy6ynq8QlseR14nPvA88de6T2eIDyNoUM mNs9795cEfEDNENdZUnKSBcQW0iUe4viknMoog+RLmQEDlMuS2FO4ZGnrAHCMAgNrzxz Ese8u9p8qvQqJ8e8g3y2WJ8HNc9xHo+1xyFmF0gW+xElM8NYeLZrssdImpzQWyAQwRFq bLJw==
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=/AE5eJIL4N9oXnzYxwbpIM5ZuSdlY5gnfYBwLewrHwY=; b=AOP6tHD4FyvLRIFC7pryU2CslUm54JavsKcc4es6W4C1TE3ZbCl6PEDg/Y1BdsPQyd 0aFKaY+tVidCTdAE+D8AiyGo6c5QWHTiHIWEL4cf5Ft27pBX0mppdbmsni8CJ0VMMctg PjuSPWeO9fOo29CPMs8MY57jsg+p8r8YPsVPmSm2gTdnn0WJ32pE6X3/9mezspxxn19N Ci1qh4vCF4ueKzj2C3ix96W3kMO7R9Yy4MmTNcPqz3pWZQi/DglD+divPn2qSVD8nM9o Vds+fighqxJnNsatkYDSr9lsxASokJPlHXZQv398HWgdaNReIIBIImO/3shAhUCu+na9 Cwcg==
X-Gm-Message-State: AMke39nP3sE0FSGVte3eRyi8xCL5n7l7b+XqVaEDHxWdmu1SWlnz3fLf/IGcBLlvouxgG7dySQCfQl8g9t4ZZU3w
X-Received: by 10.129.129.3 with SMTP id r3mr27167259ywf.0.1487833141701; Wed, 22 Feb 2017 22:59:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.207.4 with HTTP; Wed, 22 Feb 2017 22:58:41 -0800 (PST)
In-Reply-To: <CAKD1Yr3cZxsFqkLf=obAngCp5W-1EMnn4bsx-JcvaEaHOYTOCw@mail.gmail.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> <m2a89dveop.wl-randy@psg.com> <CAKD1Yr1igJiL_2BVi=RL_Wkd6V0O6WaPJ5fMS+ggVkTRAOdPXw@mail.gmail.com> <m2vas1ttsj.wl-randy@psg.com> <CAKD1Yr3cZxsFqkLf=obAngCp5W-1EMnn4bsx-JcvaEaHOYTOCw@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Thu, 23 Feb 2017 15:58:41 +0900
Message-ID: <CAAedzxoO5RgkP7cCL+bfUQEitFto6yQ7eGbLLbBU7_FD9PJPmg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07dd3eeba55205492d2550"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5nlWR-RVU_oIugnu87iBH_pW17w>
Cc: Randy Bush <randy@psg.com>, draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@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: Thu, 23 Feb 2017 06:59:04 -0000

On 23 February 2017 at 15:05, Lorenzo Colitti <lorenzo@google.com>; wrote:

> On Thu, Feb 23, 2017 at 1:28 PM, Randy Bush <randy@psg.com>; wrote:
>
>> > the IETF and 6man absolutely have the ability to change the standard,
>> > but it should follow the proper process: write a draft, get consensus,
>>
>> that is the process we are currently in.  but there seems to be serious
>> disagreement over the draft.
>>
>
> AIUI the goal of the process is to reclassify the current specification.
> That severely restricts the types of changes that are possible. That is the
> basis on which this document gained WG consensus and reached IETF last call.
>
> If we want to say that we're no longer reclassifying the current
> specification but are instead opening the door to bigger changes, then the
> document should go back to the WG for further work because the existing WG
> consensus was based on the stated goal of reclassifying the document.
>

I agree with the procedural concerns here.  Among other things, if we make
substantial changes it's hard to claim we have experience running the new
thing we've documented.

I tend to think of IID concept's primary use as: if I have the IID
::dead:beef/64 then for every new /64 PIO that's announced *I* can
reasonably expect to lay claim to prefix1::dead:beef/64,
prefix2::dead:beef/64, and so on.  (Support for this mode operations,
SLAAC, is a MUST.)

I don't personally find any major conflict when considering static and
stateful addressing.  For example, if there are 2 prefixes on a link, and
the administrators are using static addressing then prefix1::cafe and
prefix2::cafe do not in any way have to belong to the same interface on the
same host. ... at least as far as I understand it.  If prefix1 and prefix2
are each longer than /64 then each 64bit IID would still be unique--no
problems.  But if each were <=64 then it's just violating a recommendation
in the first paragraph of 2.4.1--not a big deal for the administrator that
wants to run that way.

I'm not sure if this adds anything useful to the discussion, though.
-Erik