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: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD01129639 for <ietf@ietfa.amsl.com>; Wed, 22 Feb 2017 22:59:17 -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 L1lWUbQIfhQC for <ietf@ietfa.amsl.com>; Wed, 22 Feb 2017 22:59:15 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 C7F53129635 for <ietf@ietf.org>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id v200so12631479ywc.3 for <ietf@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=oZWJP9/WNa6nR6JbW+cm5aSmTsBom70OzFfJlwhRg6A=; b=wPzpYuYkL4tM0udI++X/R4WHps4FeNLcHF5BkTHAE1ZzQjMb6YHzhvnN2vUo7pqlH5 l+RK4UH0kqck7e4wt67tpFfmoE9AfDg6ZYDCUfCqJRPjw/qqSES8aN4zU2CcWDRAqtDx VrErNHrF/jlMxfmBBheb3modL8ymy5ezoO+pDwte6ePlNEfYcLsUxN3GXSdBh4WQq8D0 f4+XWr5302Ua4TY4f3c2gq0jOgpuAuYI8PLOed0vS3N3GKrL2Sl/LKTvefhXBhsJimU5 5+TCp35mcUCrRdrOd4QwY2h19pygwj2FVxGt2yZNQFmrTfLAYJgqs73fQ21ptpWtYwts RdTw==
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=oZWJP9/WNa6nR6JbW+cm5aSmTsBom70OzFfJlwhRg6A=; b=KvAGywMrKdCUPlVxfgiIaIcAAv55374F6R0bEt0CGJIULNX6JgU6D4jfLq5SzIhPNo BLFrpJlnA5JnRYQtCr/8ZJMgIZPBx3mrweVro4Y/EyUT3X2BJipgnrzxmJlBBcetB75f C7TkxfU3II9aHGALF6mUDwOppmrDF+auRPwREqtNLI4aA2WFWp5It1lfKCi7tcT5gpah 8vDLDw+ko996pfXRBMbT9+9jwOvtj5QQuZqhf3t63fIBYJ2pRTAGOJa5k4kPNFHn7d4C E9msl+pMmKWa2ZyXK7ztAkLy50baPdbgetS79wf9bN3XzgTu4Gmp2yhVQMVeuzj6HL8Z S2rg==
X-Gm-Message-State: AMke39nmvyoTPeO4goiSpP6jfUUpi8XGTMSELJ+B0Nik53oxkc/PWVr/GJDWS6xVrAlEVNHy/dYOEPJJ4DTDKfSB
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="94eb2c07dd3eecd77605492d25b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pU9cKbi5GkachLaywDalXne8whk>
Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 06:59:17 -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