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

Mark Smith <markzzzsmith@gmail.com> Tue, 21 February 2017 19:57 UTC

Return-Path: <markzzzsmith@gmail.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 F1F481294C7; Tue, 21 Feb 2017 11:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LudjZxFQkXRO; Tue, 21 Feb 2017 11:57:25 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 9FF7012946F; Tue, 21 Feb 2017 11:57:25 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 35so90823886uak.1; Tue, 21 Feb 2017 11:57:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TtnyU7enZlorlmTYBxgfZ5Kxq2fLcjMKvtoVCQ0I+og=; b=gdavoqUO1TR2jzQZeHb7nTLAk0T5YkmaLrp22CUbFTOWzN4kwc4A2mo8ditfs1zXng g7cZKhoNDy+WEtewZ34vZRzVcQfxVxLE9yj1YVgn2w2k+N/Wpg8Na9z8E47Lvn6S/dhM dfo4ZGgQ1b+feNGlM0NktOpuAWF3NkUx85OKg2tVwyvKWk2nD287g9IgT8ww5Nvv333m 5NPKopvzlwpa5J0T0ZqJ4RY3eaDvl4fmVRAOv1LWmeQcuK7WtkeIylrWBZAP/2gKAjGr uY/StNPTP/aRUv3o+YXIzHH86Uxb+DaMgw8iQWar7tH29S4iRytc1ZZg2/ABbwaWJqHl BxOg==
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=TtnyU7enZlorlmTYBxgfZ5Kxq2fLcjMKvtoVCQ0I+og=; b=p+mTDS9vUaJs4PNDemMRkcOxMz9QWEca1ae2vu9qcUUsNzGyvIJJvRQZP9Av2Js4TF E30vHGn7gJq6BFvb20G9xOVSb4KVlb2sLvwlSiIiyaRR9J3KLlfGYK/Xx83sHR3/HK/q FgINPCWiGhfTkl/dgGN9x1IXLn/h1YQaYilxIbwSUV9p3HFVYhfAAuEb0KtSbH7Id5ZC k/2L0feve1cnopVEhe+RDDvTdGKbf2DGM49nPHRST+I/OJN+BnWRYe8M0pkvuDhLan8x Jj9p+IOgBlk+8qZR+LL4sdUKTX1+nfKfxxVH0NCFIjJjNpBoD3FTr2xpY6Al9vk14ifj z+AQ==
X-Gm-Message-State: AMke39ni0KVClAX+dac4ZG/6L8GBM8KVFh4Aoj+gpLuQwtQgreS1mUZClazrU8gJ7cSy8QGmwfTC9p8zH0c2Wg==
X-Received: by 10.176.71.234 with SMTP id w42mr5423813uac.141.1487707044712; Tue, 21 Feb 2017 11:57:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.38.2 with HTTP; Tue, 21 Feb 2017 11:56:53 -0800 (PST)
In-Reply-To: <2683353.FOTFeJBnXE@linne>
References: <m2y3x6eutl.wl-randy@psg.com> <CAKD1Yr3p=8b9Dmmb9GvGMq1u00xnE2ScmaF_a3FJXiteL=ZhBQ@mail.gmail.com> <20170221172739.GT84656@Vurt.local> <2683353.FOTFeJBnXE@linne>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 22 Feb 2017 06:56:53 +1100
Message-ID: <CAO42Z2z6K9tzYCekbyROXR7J1nB9FW53ncTRrW3p3N2P_6WyRQ@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: Karsten Thomann <karsten_thomann@linfre.de>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/j1U2YtfJxlqncG-4TTygDklzxz8>
Cc: 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: Tue, 21 Feb 2017 19:57:27 -0000

On 22 February 2017 at 06:21, Karsten Thomann <karsten_thomann@linfre.de> wrote:
> Am Dienstag, 21. Februar 2017, 18:27:39 schrieb Job Snijders:
>> On Tue, Feb 21, 2017 at 09:49:32AM +0900, Lorenzo Colitti wrote:
>> > On Tue, Feb 21, 2017 at 8:57 AM, Job Snijders <job@ntt.net> wrote:
<snip>
>>
>> -------
>>
>> OLD:
>>    IPv6 unicast routing is based on prefixes of any valid length up to
>>    128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>>    on inter-router point-to-point links.  However, the Interface ID of
>>    all unicast addresses, except those that start with the binary value
>>    000, is required to be 64 bits long.  The rationale for the 64 bit
>>    boundary in IPv6 addresses can be found in [RFC7421]
>>
>> NEW:
>>    IPv6 unicast routing is based on prefixes of any valid length up to
>>    128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
>>    of unicast addresses is required to be 64 bits long. In other use
>>    cases different prefix sizes may be required. For example [RFC6164]
>>    standardises 127 bit prefixes on inter-router point-to-point links.
>>    For most use cases, prefix lengths of 64 bits is RECOMMENDED, unless
>>    there are operational reasons not to do so.
>
> Satisfies my desired outcome of the text, but I would like to modify it:
>     IPv6 unicast routing is based on prefixes of any valid length up to
>     128 [BCP198]. When using [SLAAC], [ILNP], or [NPT66] the Interface ID
>     of unicast addresses is required to be 64 bits long. An exception is for
>     example [RFC6164] which standardises 127 bit prefixes on point-to-point
>     links. The RECOMMENDED prefix length is 64 bit,

It has to be stronger than a RECOMMENDED, because that implies it is
an arbitrary choice that won't have any protocol operational and
privacy or security impacts. That is not the case.

Have you and Job read,

"Analysis of the 64-bit Boundary in IPv6 Addressing
https://tools.ietf.org/html/rfc7421


?

(It has been referenced at some point in a version of this text
proposed I think.)

Regards,
Mark.