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

james woodyatt <jhw@google.com> Fri, 17 February 2017 20:20 UTC

Return-Path: <jhw@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 64A02129692 for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 12:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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] autolearn=unavailable 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 supWzikHlhqV for <ietf@ietfa.amsl.com>; Fri, 17 Feb 2017 12:20:05 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 16DAF129B73 for <ietf@ietf.org>; Fri, 17 Feb 2017 12:20:04 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id c73so15791463pfb.0 for <ietf@ietf.org>; Fri, 17 Feb 2017 12:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EK90MEdXhL4HHJzUlMb/azjAa8pkepDCb43Feprp4Z8=; b=ZnhVO9KdwtBDk6Ll3Wbwaqlc5lYZESHETBIlUyK9/IFjfMJ0sjN+Ixsr2v/2eVo6vR UvYhaN10gU5gi5OubuSJ6ncOuV9fzyOtdl1jdVYVUMZ76Wl81VcmSq99CAHHQ6wNDhdn tV2xZgCOUDTEfeorIisHy17Wj0QEJqWM9VEpMdk2GSaTyAox9mGCZ58Y4dGFCUfCIguF FAYA0GWxrLdu7RMWido8OXDYEzgwbaDkKunRnfdYmnmEI8KlL7eD3ung5IHD1HeIkiq0 +m0Xn/7NcoeT5YVH/PNzqRk3jys3xLDr/v8SqCI/CNE5vQC67LBAy3yhZhzBWUOsqusF cmtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EK90MEdXhL4HHJzUlMb/azjAa8pkepDCb43Feprp4Z8=; b=ZD+jNwvIqtA6X3PZX3dbuQVRF70ZIanoo9+6w1g8NKGKsVdZkUiZ2V2f1Jm3cMC5JC c7oixmW6Rv3RM47MulL2MjntZ3xdQ2bbcgLPZQQJD6amydnuuxiXL/FldUAz4d1MlEMm OFK7jpSVvFowMYay+7Ig/Q+7vXX/vSZuPgcTtXIfa7r04rNJ3AokFAOZsErT+IxmrzG8 SnvB6qjB2gc6xdFc6dDvhlG1iBDY+S7a2Xwew6NcK3Q/zcWXmu+tLdSEE+WateE8kqU6 +ETBROsVRCKvCaOupumcbayobWArqoTLW8B7f75+MNEzXtqNJcK38QQMVBmTuawJbbct WUxA==
X-Gm-Message-State: AMke39kwboGz1labETzgSMWGL47DQM2lJkHjOTyEANGNSBuuc8/4iAgF+UpsSNeQwJuoR0A/
X-Received: by 10.99.99.5 with SMTP id x5mr12259540pgb.225.1487362803349; Fri, 17 Feb 2017 12:20:03 -0800 (PST)
Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id p26sm21181574pfj.23.2017.02.17.12.20.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 12:20:02 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <BA018A61-1390-4775-ACB9-61C66D7A34FB@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8DD71669-8100-418B-B9CC-802136EBDA8A"
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: Fri, 17 Feb 2017 12:20:01 -0800
In-Reply-To: <E093E86F-41F5-4485-A8D3-761831F9AAF8@google.com>
To: IETF-Discussion Discussion <ietf@ietf.org>
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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_L7aKeOuYaIS0FCmZ0Ei7LkxVXU>
Cc: 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc4291bis@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: Fri, 17 Feb 2017 20:20:06 -0000

On Feb 16, 2017, at 14:21, james woodyatt <jhw@google.com> wrote:
>> […]
>> The challenge is to find text that enforces the 64-bit boundary policy (ignoring the technical arguments for a moment), and at the same time ensures implementors do the right thing and make their code handle any prefix length. Of course these are interdependent and doing the latter makes it harder to enforce the first.
> 
> 
> I propose the following:
> 
>>>> IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID of unicast addresses is generally required to be 64 bits in length, with exceptions only provided in special cases where expressly recognized in IETF standards track documents.

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.

I disagree with the view that advancing RFC 4291 to standards track admits the opportunity to relax the applicability of the 64-bit boundary to only those cases where SLAAC is used. That would be a technical change to the specification that I’m not comfortable promoting at IETF Last Call. In support of that position, I note that the reasoning in RFC 7421 covers cases beyond just SLAAC, and I have previously written about a case not mentioned in RFC 7421, the LOWPAN_IPHC header compression scheme, which is used in various LLN schemes, e.g. IEEE 802.15.4, for compressing IPv6 addresses using the assumption that network prefixes are 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.”)


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>