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

Erik Kline <> Thu, 23 February 2017 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73984129636 for <>; Wed, 22 Feb 2017 22:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w55ePGCquEDs for <>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C467129631 for <>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
Received: by with SMTP id p77so12682813ywg.1 for <>; Wed, 22 Feb 2017 22:59:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id r3mr27167259ywf.0.1487833141701; Wed, 22 Feb 2017 22:59:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2017 22:58:41 -0800 (PST)
In-Reply-To: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <> <> <> <>
From: Erik Kline <>
Date: Thu, 23 Feb 2017 15:58:41 +0900
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Lorenzo Colitti <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c07dd3eeba55205492d2550"
Archived-At: <>
Cc: Randy Bush <>,, 6man WG <>, IETF-Discussion Discussion <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2017 06:59:04 -0000

On 23 February 2017 at 15:05, Lorenzo Colitti <> wrote:

> On Thu, Feb 23, 2017 at 1:28 PM, Randy Bush <> 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.