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 21:48 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 1A419129583; Sun, 19 Feb 2017 13:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 uJoqHFadRcMS; Sun, 19 Feb 2017 13:48:15 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.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 4C1A2129588; Sun, 19 Feb 2017 13:48:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 016CA49; Sun, 19 Feb 2017 22:48:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= references:message-id:content-transfer-encoding:date:date :in-reply-to:x-mailer:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1487540890; bh=ItBSaxfSfVf0V6QNF3tKmFPppPgfON7KfvhjaWdtCmA=; b=F f1zhbbzZajoM7K0U9+WFTx5bAy1SIBxVafuXNgvQ0tqcqhC7qq7LnBUNwYX3ygRJ ElSi/mdbzWTRW869w67VNLoAM4SJxX+43MZ9K7NEhLIhfkdtDlpCxrUaaDgPKU9u Og8+cZdiMUsy9a88ZlpSfZxoUC1R1zaKH91qButOVE=
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 dxuzO2FdqJuQ; Sun, 19 Feb 2017 22:48:10 +0100 (CET)
Received: from [100.69.60.127] (unknown [188.206.77.70]) (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 652BB48; Sun, 19 Feb 2017 22:48:10 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <567281BF-DD55-4E46-9977-4575561A83C9@steffann.nl>
Date: Sun, 19 Feb 2017 22:48:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4868F7E-C970-4342-8A89-8087B9D33911@steffann.nl>
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> <567281BF-DD55-4E46-9977-4575561A83C9@steffann.nl>
To: james woodyatt <jhw@google.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZSgl2wNMdIoJK1DSkTmPpyZz6jM>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@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 21:48:17 -0000

Hi,

Sorry, replying to myself. An off-list discussion made me realise I made an error.

>>> 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.

I have to clarify this a little bit. When reading it I was focusing on the "is generally 64 bits" part. In hindsight the exceptions clause is too strict though. See below for the rest.

>> 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.

I like the SHOULD. It allows for exceptions. Such special case are recognised by the IETF and documents in standards track. Still good. There should be a clear guidelines to network operators. I have seen too many beginners mess up their addressing plans because they think they know better.

But on the other hand the text above limits exceptions to ONLY the IETF standards track, and that is too strong. Operators who know what they are doing must not be limited.

When writing my previous email I was focusing on giving guidance to operators, and thinking about inexperienced operators. When I saw that exceptions were taken into account I thought that that was good, but in hindsight the exceptions as written are too limited.

So to summarise I think we need to state that in general the IID SHOULD be 64 bits, exceptions MAY be defined, preferably in IETF standards track documents, equipment MUST allow operators to use any prefix length up to 128, and routing MUST support those prefix lengths.

Sorry if my series of messages were confusing. I'm trying to strike a balance between giving good guidance while allowing well-informed deviations, making sure that the text doesn't unnecessarily limit network operators while also protecting users so that ISPs don't start delegating them /96s "because it's more than enough and the RFC allows it" etc. (if you think that last argument is farfetched, sorry, I've seen too many ISPs start from there and only make a more reasonable addressing plan because the "/64 is the standard", so we shouldn't be too loose about that)

When reading the different arguments on this list I often find myself agreeing to most of them, even the conflicting ones, because I understand where the different viewpoints are coming from. And they are all important. It's difficult enough to try to fit everything together in my head, and I hope that this time I did a better job of writing it down in this email :)

Cheers,
Sander