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

Sander Steffann <sander@steffann.nl> Sun, 19 February 2017 09:36 UTC

Return-Path: <sander@steffann.nl>
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 72F5612943E; Sun, 19 Feb 2017 01:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 Ih_QUwbTRdhR; Sun, 19 Feb 2017 01:36:35 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67FD129434; Sun, 19 Feb 2017 01:36:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id AFB9B49; Sun, 19 Feb 2017 10:36:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1487496989; bh=FKoTW0TBLI6aD66xGwz IQv489jA7jOFmWNQVZLaTkX0=; b=eB33Wa12p2rLcIxyxgZGJfueko6fbZve6DG zp6yzv/wfvAoiBRtexF09uOnOpbkZzgaUx7Qr1f5Yi+H461+Xe5ijDI7Fqd2NI/N KU7+u0WALz/SwyStJz2Rmg/3y4mR+6Ejy68zQHQww1qu4JlkZEiAPwfazqt+jdGC qL0lRBos=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G6UhU9HVhLQf; Sun, 19 Feb 2017 10:36:29 +0100 (CET)
Received: from [172.20.10.4] (unknown [89.200.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id B773848; Sun, 19 Feb 2017 10:36:27 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <567281BF-DD55-4E46-9977-4575561A83C9@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_2B330AC0-48BF-42F1-99A3-1EF72EB2E8D0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Sun, 19 Feb 2017 10:36:54 +0100
In-Reply-To: <BA018A61-1390-4775-ACB9-61C66D7A34FB@google.com>
To: james woodyatt <jhw@google.com>
References: <148599306190.18700.14784486605754128729.idtracker@ietfa.amsl.com> <CAN-Dau0kDiSNXsyq9-xEdS5mzLt-K+MYHqoV8aC8jDVREw8OPQ@mail.gmail.com> <8e5c950a-0957-4323-670f-f3d07f40b4df@gmail.com> <05FD5283-9A15-4819-8362-5E6B2416D617@employees.org> <CAKD1Yr3B+dw83B0+26oUqdVJE==wHUBwoWzfWBJep8f+=uM8xQ@mail.gmail.com> <d9dc153a-61a8-5976-7697-ce1ecc9c8f3f@gmail.com> <4AF83EE6-6109-491F-BE66-114724BB197B@employees.org> <m2y3x6eutl.wl-randy@psg.com> <B76B6864-5827-4AC1-9BF7-8FFF069C10F1@employees.org> <m2lgt6ed7j.wl-randy@psg.com> <4514E052-25C1-4C85-AB1D-0B53FD9DA0E1@employees.org> <CAN-Dau3VriYNUf96yZEFMMV+-4WCxBz94Lkqfg3OsCUAbVYhaw@mail.gmail.com> <660929B4-158B-453F-9B5F-6C029F9699FA@employees.org> <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com> <BA018A61-1390-4775-ACB9-61C66D7A34FB@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/B7DFtLZTgXozriX_3jxInpevPJs>
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: Sun, 19 Feb 2017 09:36:36 -0000

Hi,

> In response to various comments to this message, I’d like to propose a refinement:
> 
>> IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, in accordance with the reasoning explained in [RFC7421], the Interface ID part of host interface addresses is generally 64 bits, with exceptions only provided in special cases expressly recognized in IETF standards track documents.

Sounds good to me. It's clear on routing, it's clear on IIDs being 64 bits long except in special standards-track cases without trying to enumerate them and it provides an informational reference to explain why it should be 64 bits.

> For my personal part, I’d prefer to see a clear statement here using RFC 2119 requirements language keywords, but I recognize that consensus probably requires compromise on that point. Hence, the proposed refinement above, which does not use RFC 2119 keywords. (Here is how I would write this with keywords: “IPv6 unicast routing is based on network prefixes that MAY have any valid length up to 128 bits [BCP198]. However, in accordance with the reasoning explained in [RFC7421], the Interface ID part of host interface addresses SHOULD be 64 bits with exceptions only provided in special cases expressly recognized in IETF standards track documents.”)

I'm a bit worried that the "MAY have any valid length up to 128 bits" definition is too loose when read by router vendors, but otherwise that version sounds good as well. I like to see explicit clear guidance in standards documents.

One question: don't the texts conflict with things like policy based routing? Do we need to take that into account here?

Cheers,
Sander